From engy
This skill should be used when the user asks to 'write a plan', 'plan implementation', 'plan milestone', 'create implementation plan', or when planning complex changes — new features, architecture changes, multi-file work, or anything with ambiguous scope. Writes a validated implementation plan using codebase-aware requirements engineering.
How this skill is triggered — by the user, by Claude, or both
Slash command
/engy:planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Write a validated implementation plan for a standalone task using a codebase-aware requirements engineering process.
Write a validated implementation plan for a standalone task using a codebase-aware requirements engineering process.
getProjectDetails(projectId) — project paths (specDir) + workspace contextlistTasks(projectId) — milestone tasks (responses include specPath)listTaskGroups(milestoneRef) — task groups within the target milestoneUse MCP to discover context, then Read/Glob/Grep for codebase exploration and spec reading.
Assess complexity before committing to the full process:
Default to full process. The simple path is the exception, not the rule.
Explore the codebase first: CLAUDE.md, project structure, existing patterns for similar features, dependencies, recent commits touching related areas. If planning a milestone, review the milestone scope, its tasks, and the parent spec for context.
Infer requirements from the request plus codebase context. For each inference, note its source (e.g., "soft deletes — matches existing User model pattern"). Consider: loading states, error handling, empty states, mobile behavior, accessibility, data persistence.
Stress-test the inferred requirements against these categories:
For each gap found, classify it:
For greenfield projects with no existing code, the Internal Pass is brief. Focus shifts to the External Pass.
Present: "Based on the codebase, I plan to [summary]. I need your input on these [N] things:"
Each question should state what was inferred and why user judgment is needed, with tradeoffs where applicable. Only surface questions the codebase cannot answer — business decisions, preferences, and ambiguous tradeoffs.
Run for up to 3 rounds. After each response, re-evaluate: did answers surface new unknowns? If everything is clear, move to Step 2. Do not ask questions for the sake of filling rounds — stop as soon as requirements are unambiguous.
Cross-check all gathered requirements (user-stated + inferred + elicited) for:
This is an internal reasoning step. If conflicts are found, present them to the user with resolution options before proceeding. If no conflicts, proceed to Step 3.
Synthesize everything into a structured plan using the appropriate template:
Test guidance: FRs define expected behavior. Implementation Sequence steps include inline test impact. These two cover most testing needs. Only add a separate Test Scenarios section (Gherkin) when the feature has complex multi-step stateful flows where temporal ordering matters and can't be captured in a single FR.
Code snippets: For non-obvious changes (e.g., reversing a sort direction, changing a filter predicate), include before/after code snippets inline with the relevant step or change row.
Before presenting the plan, review it against these checks:
If issues are found, fix them inline. Note any tradeoffs or judgment calls at the bottom of the plan for user review.
Do NOT start implementation until the user explicitly approves the plan. Present the plan and wait. Once approved, proceed with /engy:validate-plan to validate it against the parent spec before implementation. If something architectural surfaces mid-build that wasn't in the plan, stop and flag it.
# Plan: [Feature/Change Name]
## Overview
What we're changing and why. 2-3 sentences.
## Changes
### `path/to/file.ts`
What changes. Include before/after snippets for non-obvious changes.
- *Test impact:* Which tests are affected and how.
### `path/to/other-file.ts`
...
## Verification
How to confirm the change works end-to-end.
# Plan: [Feature/Change Name]
## Overview
One paragraph: what we're building, why, and the scope boundary.
## Functional Requirements
Numbered list. Each requirement is one clear behavior the system must exhibit.
Use "The system shall..." or "When [trigger], [behavior]" format.
Tag each with its source: (user request), (inferred: <reason>), (elicited).
Group by feature area if more than 5.
## Non-Functional Requirements
Only include what's relevant: performance targets, security constraints,
accessibility, compatibility, data handling, error recovery.
## Codebase Context
Key conventions, patterns, and existing infrastructure discovered during
the Internal Pass. Include file paths. Keep brief — just what's needed
to inform implementation.
## Affected Components
### `path/to/file.ts` [MODIFY]
What changes.
### `path/to/other-file.ts` [NEW]
What this new file does.
## Implementation Sequence
Ordered list of build steps. Note parallelizable steps after the list.
1. **Step name** — What to build/change. (dependencies: none | depends on step N)
- *Test impact:* Which tests are affected and how. Include before/after
snippets for non-obvious changes.
**Parallelizable:** Steps X, Y, Z have no dependencies and can run concurrently.
## Test Scenarios (optional)
Include only for complex multi-step stateful flows where temporal ordering
matters and can't be captured in a single FR. Group by feature area.
### {Feature Area}
```gherkin
Scenario: {descriptive name} (FR #{N})
Given {precondition}
When {action}
Then {expected outcome}
Explicit list of what this work does NOT include, to prevent scope creep.
Anything still ambiguous after elicitation that the user should weigh in on before implementation starts.
## Flow Position
**Previous:** `milestone-plan` | **Next:** `validate-plan`
When the plan is approved by the user, proceed with `/engy:validate-plan` to validate it against the parent spec before implementation.
npx claudepluginhub zanderadam/engy --plugin engyGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.