planning

Turns requirements into executable plans with dependencies and verifiable acceptance criteria.

22|Updated Sep 10, 2026
One-click install
npx skills add https://github.com/Lynricsy/HyperSkills --skill planning-lynricsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: planning
Source: https://github.com/Lynricsy/HyperSkills/tree/main/skills/planning
Command: npx skills add https://github.com/Lynricsy/HyperSkills --skill planning-lynricsy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Vague requests and hand-wavy plans cause rework, false completion claims, and scope creep. This Skill converts a request into decidable requirements, then into a step-by-step plan where every step names its dependencies, the exact command that proves it done, and the output that counts as passing. ## Core Features & Use Cases - Clarify workflow: Separates facts to look up from decisions to ask, runs already-built and already-rejected pre-checks, and records assumptions with their dependents. - Plan workflow: Produces a plan document with global constraints, non-goals, rollback points, consumes/produces signatures per step, and acceptance commands read from the repository's own Makefile, package.json, or CI workflow. - Review and track workflows: Reviews draft plans against a defect catalogue, then tracks execution with quoted command output, stop-and-revise triggers, and amend-not-regenerate revision rules. - Use Case: Given a feature issue and a repo inventory, produce a task breakdown for two engineers that freezes the API contract before parallel frontend work and front-loads the riskiest unknown as an investigation. ## Quick Start Ask the agent to turn this feature request into an executable plan with acceptance commands and dependencies for each step.

Frequently Asked Questions about planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn a vague feature request into an executable plan?

Run the clarify workflow first: look up facts in the repository, ask decision-shaped questions in one numbered round with recommendations, and write assumptions with their dependents. Then decompose into steps where each names its acceptance command and expected output.

What makes a good acceptance criterion for a task?

A good acceptance criterion is decidable: a third party can judge it true or false by running a command and reading its output. Use the repository's own commands from its Makefile, package.json, or CI workflow, never a generic 'run tests'.

When should tasks run in parallel versus sequentially?

Tasks are sequential by default; parallelism requires a per-pair argument that they share no files, schema, or generated artifacts. Producer-consumer pairs need a contract-freezing step first, and migrations or lockfile edits must always be serialized.

When should I stop executing a plan and revise it?

Stop when a premise proves false, a step's acceptance cannot be met as written, the same step fails three times, or unplanned work appears. Revise by amending the document, keeping completed steps and recording why each change was made.

Does this skill create GitHub issues or pull requests?

No. Creating issues, pull requests, milestones, or labels belongs to a GitHub-focused skill. This skill decides what the work is: requirements, decomposition, dependencies, and acceptance criteria.