feature-planning

Files (2)

• SKILL.md
• verification-patterns.md · references/

SKILL.md (first lines)

# Feature Planning

Transform approved feature evaluations into actionable implementation plans with built-in verification and escalation triggers.

## Execution Modes

This skill adapts to the pipeline execution mode:

| Mode | Behavior |
|------|----------|
| `full` | Full planning with detailed output |
| `fast` | Planning included in combined eval+plan (skip this skill) |
| `prototype` | Abbreviated planning (components + criteria only) |
| `spike` | Skip planning entirely |

In `fast` mode, planning is merged into the evaluator's combined output. This skill is only invoked separately in `full` and `prototype` modes.

## Input Requirements

This skill requires an approved feature evaluation containing:
- Feature description and scope
- Selected implementation option (A/B/C from evaluator)
- Anti-scope items (what NOT to build)
- Success metrics

If these are missing, request them before proceeding.

## Planning Process

### Step 1: Decompose into Components

Break the feature into implementable components:

1. List all functional pieces required
2. Identify dependencies between components
3. Order by dependency (build dependencies first)
4. Estimate effort per component (S/M/L)

Each component must be:
- **Independently testable** — Can verify it works without other components
- **Small enough** — Completable in one implementation cycle
- **Well-bounded** — Clear start and end state

### Step 2: Define Verification Contract

For each component AND for the feature as a whole, define verification criteria.

**Verification types:**
- `unit-test`: Automated test that runs in isolation
- `integration-test`: Automated test that verifies behavior in context
- `manual-test`: Human verification with specific steps
- `assertion`: Runtime check that fails loudly if violated

**Criteria rules:**
- Must be **specific and binary** — pass or fail, no "looks good"
- Must include **exact verification command or steps**
- Must be **defined before implementation** (locked during implementation)
- Can be **modified with justification** only (logged and requires rationale)

### Step 3: Define Stuck Detection

Pre-define escalation triggers:
- Same test fails N consecutive attempts
- Total failed cycles exceed threshold
- Implementation time exceeds estimate by X factor
- Circular dependency discovered
- External blocker identified

### Step 4: Document Anti-Scope

Explicitly list what will NOT be implemented. This prevents scope creep during implementation.

## Output Format

```
IMPLEMENTATION PLAN
═══════════════════

Feature: [Name]
Source: [Link to approved evaluation]
Selected option: [A/B/C from evaluator]
Total estimated effort: [S/M/L or time range]

## Verification Contract

### Acceptance Criteria (LOCKED)

Modification policy: These criteria are locked during implementation. 
To modify, provide written justification and log the change.

#### Criterion 1: [Name]
- Type: [unit-test | integration-test | manual-test | assertion]
- Pass condition: [Specific, binary condition]
- Verification command: [Exact command or steps]
- Critical: [Yes/No] — If Yes, failure = feature incomplete

#### Criterion 2: [Name]
- Type: [...]
- Pass condition: [...]
- Verification command: [...]
- Critical: [Yes/No]

[Continue for all criteria]

### Regression Checks
- [ ] Existing test suite passes: `[command]`
- [ ] [Specific existing functionality] still works: `[how to verify]`
- [ ] No new linter/type errors: `[command]`

### Manual Test Requirements (if any)
If automated testing is not possible for certain aspects:

#### Manual Test 1: [Name]
- What to test: [Specific action]
- Expected result: [What should happen]
- Edge cases to check:
  - [Edge case 1]: [Expected behavior]
  - [Edge case 2]: [Expected behavior]
- Request human verification: Yes

From autoencoders/skills, CC-BY-4.0.

More from autoencoders/skills