# Plan Feature

> Use when the user says "plan a feature", "design this", "how should we build", or before writing code for any non-trivial feature. Produces an approved task breakdown before implementation begins — plan first, build second.

- **Type:** Skill
- **Install:** `agentstack add skill-arozumenko-sdlc-skills-plan-feature`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [arozumenko](https://agentstack.voostack.com/s/arozumenko)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [arozumenko](https://github.com/arozumenko)
- **Source:** https://github.com/arozumenko/sdlc-skills/tree/main/bundles/test-automation/skills/plan-feature

## Install

```sh
agentstack add skill-arozumenko-sdlc-skills-plan-feature
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

## Feature Planning: Understand → Investigate → Plan → Approve

**Core philosophy:** plan before you build. The cheapest bugs are the ones
you prevent during planning.

## The seven steps

```
1. Understand the request
2. Investigate current state
3. Clarify unknowns
4. Feasibility analysis
5. Define acceptance criteria
6. Implementation plan
7. Get approval
```

### 1. Understand the request

Know exactly what's being asked before investigating. Ask yourself:

- **What** is being requested? (feature, change, improvement)
- **Who** benefits? (end user, developer, ops)
- **Why** now? (business driver, user feedback, tech debt)
- **What does done look like?** (measurable outcome)

If the request is vague, ask clarifying questions *before* investigating —
don't dig into code for a direction that might change.

### 2. Investigate current state

Understand what exists before proposing changes. Grep for relevant terms,
read existing implementation, look for patterns to follow and code to reuse,
check git history for prior context. Document what already exists, what needs
to change vs. what's new, existing patterns, and technical constraints.

### 3. Clarify unknowns

Resolve ambiguity before committing to a plan. Common unknowns: scope,
integration, performance, security, edge cases. When presenting options to
the user, lay out the trade-offs — don't force a pick without context.

### 4. Feasibility analysis

Assess effort, risk, and trade-offs. Build an impact table (area → impact →
files affected), a risk table (risk → likelihood → impact → mitigation), and
a dependency list (external, internal, blocking).

### 5. Define acceptance criteria

Testable definition of done, in Given/When/Then format. Every AC must be
pass/fail — no "should be intuitive." Cover happy path, error cases, and
edge cases. Include performance criteria when relevant.

### 6. Implementation plan

Ordered list of tasks with dependencies, grouped into phases. For each task
define: what to build (not how — that's the developer's job), interface
contract, acceptance criteria it satisfies, and which role owns it
(python-dev, js-dev, qa-engineer). Call out parallel opportunities and the
critical path.

### 7. Get approval

Alignment before implementation begins. Present summary, scope, task count,
top risks, dependencies, acceptance criteria, and the plan. Ask explicitly:
"Ready to proceed?" Don't start implementation until approved — plans are
cheap, implementation is expensive.

## Templates & recipes

All the investigation commands, feasibility table layouts, AC format, plan
template, and approval presentation live in
[references/templates.md](references/templates.md). Load that file when you
need the exact format.

## Anti-Patterns

- Don't plan in a vacuum — investigate the codebase first
- Don't propose solutions without understanding constraints
- Don't skip acceptance criteria — they're the contract with the developer
- Don't create monolithic tasks — break into parallel-friendly pieces
- Don't assume requirements — ask when ambiguous

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [arozumenko](https://github.com/arozumenko)
- **Source:** [arozumenko/sdlc-skills](https://github.com/arozumenko/sdlc-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-arozumenko-sdlc-skills-plan-feature
- Seller: https://agentstack.voostack.com/s/arozumenko
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.