Feature Planning
Purpose
Plan a feature: define its scope within the architecture, its design decisions, tasks, and tests, so it can be implemented and verified without scope creep. Produces a feature work item in ../../work-items/features/.
When to Use
- Request classified as feature (or a feature sub-part of a larger plan).
- When adding capability to an existing or planned architecture.
- Not for defect fixes (
bug-investigation) or behavior-preserving cleanup (refactor-planning).
Inputs
- Requirement baseline + success criteria.
- Architecture + repository layout.
- Existing patterns (from
existing-project-audit) for consistency.
Discovery Questions
- What exactly is in scope, and what is explicitly out?
- Which applications/modules does it touch?
- What are the acceptance criteria from the user's perspective?
- What tests prove it works (levels/tools)?
- Any security-sensitive surface (auth, payments, PII)?
Responsibilities
- Define the feature's scope and boundaries (in/out).
- Fit it to existing architecture and patterns.
- Produce tasks (via
task-planning) with acceptance criteria written as Gherkin scenarios (testing/gherkin-specifications, ../../system/GHERKIN_RULES.md) — including the required cases, one scenario each.
- Attach a testing plan (
testing-strategy) and security requirements (security-review) where relevant.
- Record the feature work item and its status.
Required Workflow
- Read requirements + architecture.
- Lock scope (in/out) and acceptance criteria.
- Identify affected apps/modules and contracts.
- Generate tasks (delegate mechanics to
task-planning).
- Attach tests + security requirements.
- Record in
../../work-items/features/.
Decision Rules
- Match existing conventions rather than introducing new patterns without cause.
- Security-sensitive features get integration/E2E tests, not just units.
- New work discovered mid-plan → propose a separate work item, don't absorb it.
Rules
- Stay within the feature's stated scope.
- Preserve unrelated behavior.
- Acceptance criteria are observable and testable.
Anti-Patterns
- Scope creep ("while I'm here…").
- Introducing a new stack/pattern for one feature.
- Shipping without acceptance criteria or tests.
Validation Checklist
Definition of Done
A recorded feature work item with locked scope, acceptance criteria, tasks, a testing plan, and any security requirements — ready for implementation under the gates.
Related Skills
task-planning, architecture-design, testing-strategy, security-review, code-review, project-orchestrator.
Related Knowledge
../../knowledge/ (domain rules, patterns).
Related References
../../references/<domain-topic>/ when the feature domain needs grounding.
Context Loading Guidance
- Requires: requirements, architecture, affected-area patterns.
- Does not require: unrelated modules, the full reference tree, other planning skills' bodies.
- May load:
task-planning, testing-strategy, security-review.
- Stop when: the feature work item is recorded.
Token Efficiency Guidance
Load only the affected modules' context. Reuse task-planning for mechanics rather than restating them. Keep the work item concise.
1---2name: feature-planning3description: Use to plan a feature work item — scoping new capability within existing (or planned) architecture, defining its phases, tasks, tests, and acceptance criteria without expanding scope. Delegates general phase/task mechanics to task-planning.4---56# Feature Planning78## Purpose910Plan a feature: define its scope within the architecture, its design decisions, tasks, and tests, so it can be implemented and verified without scope creep. Produces a feature work item in `../../work-items/features/`.1112## When to Use1314- Request classified as **feature** (or a feature sub-part of a larger plan).15- When adding capability to an existing or planned architecture.16- **Not** for defect fixes (`bug-investigation`) or behavior-preserving cleanup (`refactor-planning`).1718## Inputs1920- Requirement baseline + success criteria.21- Architecture + repository layout.22- Existing patterns (from `existing-project-audit`) for consistency.2324## Discovery Questions2526- What exactly is in scope, and what is explicitly out?27- Which applications/modules does it touch?28- What are the acceptance criteria from the user's perspective?29- What tests prove it works (levels/tools)?30- Any security-sensitive surface (auth, payments, PII)?3132## Responsibilities3334- Define the feature's **scope and boundaries** (in/out).35- Fit it to existing **architecture and patterns**.36- Produce **tasks** (via `task-planning`) with acceptance criteria written as Gherkin scenarios (`testing/gherkin-specifications`, `../../system/GHERKIN_RULES.md`) — including the required cases, one scenario each.37- Attach a **testing plan** (`testing-strategy`) and **security requirements** (`security-review`) where relevant.38- Record the feature work item and its status.3940## Required Workflow41421. Read requirements + architecture.432. Lock scope (in/out) and acceptance criteria.443. Identify affected apps/modules and contracts.454. Generate tasks (delegate mechanics to `task-planning`).465. Attach tests + security requirements.476. Record in `../../work-items/features/`.4849## Decision Rules5051- Match existing conventions rather than introducing new patterns without cause.52- Security-sensitive features get integration/E2E tests, not just units.53- New work discovered mid-plan → propose a separate work item, don't absorb it.5455## Rules5657- Stay within the feature's stated scope.58- Preserve unrelated behavior.59- Acceptance criteria are observable and testable.6061## Anti-Patterns6263- Scope creep ("while I'm here…").64- Introducing a new stack/pattern for one feature.65- Shipping without acceptance criteria or tests.6667## Validation Checklist6869- [ ] Scope (in/out) explicit.70- [ ] Affected apps/modules identified.71- [ ] Acceptance criteria observable/testable.72- [ ] Tasks generated with criteria.73- [ ] Testing plan attached.74- [ ] Security requirements attached where relevant.7576## Definition of Done7778A recorded feature work item with locked scope, acceptance criteria, tasks, a testing plan, and any security requirements — ready for implementation under the gates.7980## Related Skills8182`task-planning`, `architecture-design`, `testing-strategy`, `security-review`, `code-review`, `project-orchestrator`.8384## Related Knowledge8586`../../knowledge/` (domain rules, patterns).8788## Related References8990`../../references/<domain-topic>/` when the feature domain needs grounding.9192## Context Loading Guidance9394- **Requires:** requirements, architecture, affected-area patterns.95- **Does not require:** unrelated modules, the full reference tree, other planning skills' bodies.96- **May load:** `task-planning`, `testing-strategy`, `security-review`.97- **Stop when:** the feature work item is recorded.9899## Token Efficiency Guidance100101Load only the affected modules' context. Reuse `task-planning` for mechanics rather than restating them. Keep the work item concise.
ahtishamshahzad