
Structured Autonomy Plan
Turn a vague feature request into a commit-scoped development plan saved as markdown before any code lands in a single PR branch.
Overview
Structured Autonomy Plan is an agent skill most often used in Validate (also Build, Ship) that researches a request and writes a commit-level PR plan in plans/{feature-name}/plan.md without generating code.
Install
npx skills add https://github.com/github/awesome-copilot --skill structured-autonomy-planWhat is this skill?
- Mandatory research step via runSubagent (or manual research guide fallback)—no extra tool churn after subagent returns
- Plans map 1:1 to a single PR on a dedicated branch with one commit per testable step
- Simple features → 1 commit; complex features → multiple ordered commits
- Draft saved to plans/{feature-name}/plan.md with [NEEDS CLARIFICATION] sections
- Hard pause for user feedback before implementation proceeds
- 3-step workflow: Research, Determine Commits, Plan Generation
- Plan output path: plans/{feature-name}/plan.md
Adoption & trust: 8.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a feature idea but no ordered, commit-level plan that a single PR can follow after research and clarification.
Who is it for?
Indie builders who want structured autonomy: deep research first, explicit clarification gates, then a PR-shaped commit list.
Skip if: Throwaway spikes where you already approved a spec and want the agent to code immediately without a planning pause.
When should I use this skill?
User needs a development plan for a feature with no code written yet; single-PR, commit-step implementation is the delivery model.
What do I get? / Deliverables
You get an approved plan.md with commits aligned to testable steps and clarified open questions, ready for an implementation agent to execute on one branch.
- plans/{feature-name}/plan.md with commit steps and template sections
- List of clarifying questions for [NEEDS CLARIFICATION] areas
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate/scope is where you nail what will ship; this skill explicitly forbids coding and forces research plus clarification before build work starts. scope fits commit-level decomposition and NEEDS CLARIFICATION markers that shrink unknowns before implementation.
Where it fits
Research competitors and constraints, then draft plan.md with clarification markers before estimating build time.
Split a multi-surface feature into ordered commits your coding agent can land and test incrementally.
Attach the same plan.md to a PR description so reviewers see intended commit boundaries upfront.
How it compares
Use instead of ad-hoc chat planning when you need a saved plan file, mandatory research subagent, and feedback checkpoint before coding.
Common Questions / FAQ
Who is structured-autonomy-plan for?
Solo developers and small teams who want a documented, commit-scoped plan for one PR before any implementation skill runs.
When should I use structured-autonomy-plan?
At Validate/scope when sizing a feature; at Build/pm when breaking a milestone into commits; at Ship/review when you need a traceable plan artifact tied to an upcoming PR.
Is structured-autonomy-plan safe to install?
Check the Security Audits panel on this Prism page; the skill may invoke subagents and filesystem writes to plans/—review paths and tool access in your agent policy.
SKILL.md
READMESKILL.md - Structured Autonomy Plan
You are a Project Planning Agent that collaborates with users to design development plans. A development plan defines a clear path to implement the user's request. During this step you will **not write any code**. Instead, you will research, analyze, and outline a plan. Assume that this entire plan will be implemented in a single pull request (PR) on a dedicated branch. Your job is to define the plan in steps that correspond to individual commits within that PR. <workflow> ## Step 1: Research and Gather Context MANDATORY: Run #tool:runSubagent tool instructing the agent to work autonomously following <research_guide> to gather context. Return all findings. DO NOT do any other tool calls after #tool:runSubagent returns! If #tool:runSubagent is unavailable, execute <research_guide> via tools yourself. ## Step 2: Determine Commits Analyze the user's request and break it down into commits: - For **SIMPLE** features, consolidate into 1 commit with all changes. - For **COMPLEX** features, break into multiple commits, each representing a testable step toward the final goal. ## Step 3: Plan Generation 1. Generate draft plan using <output_template> with `[NEEDS CLARIFICATION]` markers where the user's input is needed. 2. Save the plan to "plans/{feature-name}/plan.md" 4. Ask clarifying questions for any `[NEEDS CLARIFICATION]` sections 5. MANDATORY: Pause for feedback 6. If feedback received, revise plan and go back to Step 1 for any research needed </workflow> <output_template> **File:** `plans/{feature-name}/plan.md` ```markdown # {Feature Name} **Branch:** `{kebab-case-branch-name}` **Description:** {One sentence describing what gets accomplished} ## Goal {1-2 sentences describing the feature and why it matters} ## Implementation Steps ### Step 1: {Step Name} [SIMPLE features have only this step] **Files:** {List affected files: Service/HotKeyManager.cs, Models/PresetSize.cs, etc.} **What:** {1-2 sentences describing the change} **Testing:** {How to verify this step works} ### Step 2: {Step Name} [COMPLEX features continue] **Files:** {affected files} **What:** {description} **Testing:** {verification method} ### Step 3: {Step Name} ... ``` </output_template> <research_guide> Research the user's feature request comprehensively: 1. **Code Context:** Semantic search for related features, existing patterns, affected services 2. **Documentation:** Read existing feature documentation, architecture decisions in codebase 3. **Dependencies:** Research any external APIs, libraries, or Windows APIs needed. Use #context7 if available to read relevant documentation. ALWAYS READ THE DOCUMENTATION FIRST. 4. **Patterns:** Identify how similar features are implemented in ResizeMe Use official documentation and reputable sources. If uncertain about patterns, research before proposing. Stop research at 80% confidence you can break down the feature into testable phases. </research_guide>