Structured Autonomy Generate

Structured autonomy generate

Transform a complete plans/{feature-name}/plan.md into a copy-paste-ready plans/{feature-name}/implementation.md that gives GitHub Copilot concrete implementation steps, code blocks, and verification points.

When to invoke

• "Generate implementation.md from this structured autonomy plan."
• "Turn plans/my-feature/plan.md into implementation steps."
• "Create copy-paste implementation documentation for this PR plan."
• "Expand this plan into code blocks and verification checklists."
• "Write plans/{feature-name}/implementation.md."

Inputs

Use $ARGUMENTS as the feature name, plan path, or plan content. If absent, search only for the intended plans/{feature-name}/plan.md named by the user or the current context; do not invent a feature plan.

Prerequisites and context

• The source plan must be complete enough to identify feature name, branch, implementation steps, and affected files.
• The output path is always plans/{feature-name}/implementation.md.
• The generated implementation must contain concrete actions; no "decide later", placeholders, or TODO comments in code blocks.

Procedure

1. Read plans/{feature-name}/plan.md and extract the feature name, expected branch, numbered implementation steps, and files affected by each step.
2. Research the codebase once for the entire plan. Gather project type, stack, versions, folder organization, naming conventions, build/test/run commands, dependency management, error handling, logging, configuration, data flow, API conventions, state management, testing strategy, and relevant official documentation for major libraries.
3. Convert the plan into a complete markdown implementation document using the template in this skill.
4. For every implementation step, include exact file paths, checkboxes for each action, complete code blocks that require zero modification, and specific observable verification points.
5. Add a STOP & COMMIT boundary after each major step so the user can test, stage, and commit incrementally.
6. Save the document to plans/{feature-name}/implementation.md.

Research package

Collect this once, then reuse it for every step:

Implementation document rules

• Use FEATURE_NAME only as a template label in the output format; replace it with the actual feature name in the saved file.
• Include branch guidance: confirm the user is on {feature-name}; if not, switch or create it from main.
• Code blocks must be complete and paste-ready with no placeholders and no TODO comments.
• Verification must be testable: build output, test command, UI behavior, API response, file content, or observable state.
• Every step must have a checkbox list and a Step N Verification Checklist.
• Use the project's actual build and test commands, not generic commands.

Source workflow labels

Preserve the source labels research_task and plan_template when explaining how the generated document was derived. The skill's SOLE responsibility is to create implementation.md; research runs ONE TIME, using runSubagent only when the host supports that mechanism. Generated steps MUST include COMPLETE, TESTED CODE with ZERO PLACEHOLDERS and ZERO TODO COMMENTS for EVERY changed {file}. Mention Build/test, Build/test/run, libraries/frameworks, permission/capability, and the root plans/{feature-name}/ when summarizing extracted context.

Output template

## Structured autonomy implementation

**Status:** generated | blocked
**Source plan:** `plans/<feature-name>/plan.md`
**Output file:** `plans/<feature-name>/implementation.md`
**Branch:** `<feature-name>`

### Document written
```markdown
## <FEATURE_NAME>

## Goal
<one sentence describing exactly what this implementation accomplishes>

## Prerequisites
Make sure that the user is currently on the `<feature-name>` branch before beginning implementation. If not, move them to the correct branch. If the branch does not exist, create it from main.

### Step-by-Step Instructions

#### Step 1: <Action>
- [ ] <specific instruction>
- [ ] Copy and paste code below into `<file>`:

```<language>
<complete tested code with no placeholders>

Step 1 Verification Checklist

Step 1 STOP & COMMIT

STOP & COMMIT: Agent must stop here and wait for the user to test, stage, and commit the change.

### Validation
- Source plan parsed: pass | fail
- Codebase research completed once: pass | fail
- Implementation file saved: pass | fail

Quality gate

• plans/{feature-name}/plan.md was read before generation.
• plans/{feature-name}/implementation.md was written at the required path.
• The generated document contains exact file paths and complete code blocks with no placeholders or TODO comments.
• Every action item uses a markdown checkbox.
• Every step has specific, observable verification points.
• Every major step ends with STOP & COMMIT instructions.
• Build and test commands are specific to the researched project.