Skills github awesome-copilot Structured Autonomy
structured-autonomy-plan
- Use it when:
- You want a feature planned as a single pull request before the agent writes any code.
- It does:
- Researches related code, docs and dependencies, in a subagent when it can, then splits the work into one commit or several testable ones.
- You get:
- plans/{feature-name}/plan.md: a branch name, the goal, and for each step its files, the change and how to test it.
- Then:
- It asks about every [NEEDS CLARIFICATION] marker and pauses; your feedback sends it back to research and revise.
Skill 1 of 3 in the Structured Autonomy bundle, before structured-autonomy-generate.
Its research guide still tells the agent to look at how similar features are built in ResizeMe, the app it was written for.
TL;DR
The agent acts as a planner and writes no code. It first gathers context: related features and patterns in the codebase, existing docs and architecture decisions, and the external APIs or libraries involved, reading their documentation first, through Context7 if available, and stopping once it's about 80% sure it can split the feature into testable steps. It hands this research to a subagent when it can, and otherwise does it itself. It assumes the whole feature lands as one pull request on its own branch: a simple feature becomes a single commit, a complex one several commits that each leave a testable step. The draft goes to plans/{feature-name}/plan.md, with [NEEDS CLARIFICATION] wherever it needs your input; it asks those questions and waits. Feedback sends it back through research and a revised plan. Its research guide was adapted from a specific project and still mentions ResizeMe and Windows APIs.
Summarizes the skill at 797337f.
npx skills add https://github.com/github/awesome-copilot --skill structured-autonomy-plan skills.sh pageSource on GitHubAll skills from github/awesome-copilot
- Total Downloads
- 8,800 on skills.sh, Nov 9, 2026
- Repo stars
- 40,943 github/awesome-copilot
- First seen
- Feb 25, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 11 |
| Sep 28 | 17 |
| Oct 5 | 13 |
| Oct 12 | 2 |
| Oct 19 | 0 |
| Oct 26 | 3 |
| Nov 2 | 3 |
| Nov 9 | 3 |
| Category |
Make the agent question you and write the plan down before it writes code. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A multi-step process the agent follows: interview, debug, run a TDD loop, review. |
| Effect |
Its own steps create or change files, git state or local tools. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics |
SKILL.md
From github/awesome-copilot at 797337f. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: structured-autonomy-plan
description: 'Structured Autonomy Planning Prompt'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
- Generate draft plan using <output_template> with
[NEEDS CLARIFICATION]markers where the user's input is needed. - Save the plan to "plans/{feature-name}/plan.md"
- Ask clarifying questions for any
[NEEDS CLARIFICATION]sections - MANDATORY: Pause for feedback
- If feedback received, revise plan and go back to Step 1 for any research needed
</workflow>
<output_template>
File: plans/{feature-name}/plan.md
# {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:
- Code Context: Semantic search for related features, existing patterns, affected services
- Documentation: Read existing feature documentation, architecture decisions in codebase
- Dependencies: Research any external APIs, libraries, or Windows APIs needed. Use #context7 if available to read relevant documentation. ALWAYS READ THE DOCUMENTATION FIRST.
- 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>