---
requiresProjectContext: true
---

# Playbook: Feature Plan

> Agent: {{agent_name}} | Task: {{task_description}} | ID: {{task_id}}

## Context

Repo: {{repo_name}} | Org: {{ado_org}} | Project: {{ado_project}}
Team root: {{team_root}}
Project path: {{project_path}}

## Mission

A user has described a feature they want built. Your job is to create a detailed implementation plan that a separate agent will later convert into a structured PRD for automatic dispatch to the agent pool.

## The Feature Request

{{plan_content}}

## Steps

### 1. Understand the Request
- Read the feature description carefully
- Identify the core goal, constraints, and success criteria
- Note any ambiguities that need to be called out

{{#project_skills_block}}
{{project_skills_block}}

{{/project_skills_block}}
### 2. Explore the Codebase
- Read `CLAUDE.md` at repo root and relevant directories
- Map the areas of code that this feature will touch
- Identify existing patterns, conventions, and extension points
- Note dependencies and potential conflicts with in-progress work
- Build a concise context pack before planning: start with 5-15 candidate files from paths, symbols, comparable implementations, imports/callers, and tests; read the smallest useful set (usually 5-8 files) and expand only for specific unknowns

### 3. Design the Approach
- Outline the high-level architecture for the feature
- Identify what needs to be created vs modified
- Consider edge cases, error handling, and backwards compatibility
- Note any prerequisites or migrations needed
- Record non-obvious design decisions with the alternatives considered and why the chosen option best fits existing architecture

### 4. Break Down into Work Items
- Decompose into discrete, PR-sized chunks of work
- Order by dependency (foundations first)
- Estimate complexity: `small` (1 file), `medium` (2-5 files), `large` (6+ files)
- Each item should be independently testable
- Also list ideas you considered and chose **not** to include — these go in the required `## Rejected items` section so scope is declared explicitly

### 5. Write the Plan

Write the plan to: `{{team_root}}/plans/{{plan_file}}`

Use this format:

```markdown
# Plan: {{plan_title}}

{{#target_projects}}**Projects:** {{target_projects}}
<!-- minions:targetProjects={{target_projects}} -->
{{/target_projects}}{{^target_projects}}**Project:** {{project_name}}
{{/target_projects}}**Author:** {{agent_name}}
**Date:** {{date}}

## Goal
What this feature achieves and why it matters.

## Codebase Analysis
What exists today, what needs to change, key files involved.

## Approach
High-level design decisions and rationale.

## Work items

Flat numbered list, ordered by dependency in prose (not by phase). Use phases only when items genuinely block each other across PR boundaries; otherwise the plan is a flat numbered list.

### 1. <item name> (complexity: small/medium/large)
- What to build
- Files to create/modify
- Acceptance criteria

### 2. <item name> (complexity: small/medium/large)
- ...

## Rejected items

Required section. Declare scope by listing ideas you considered and chose not to include, one line per rejected item with the reason.

- <rejected idea> — <one-line reason>
- <rejected idea> — <one-line reason>

## Risks & Open Questions
- Risk or question that needs user input

## Dependencies
- External dependencies or prerequisites
```

## Important

- Do NOT create a git branch, worktree, or PR — this playbook writes minions-internal state only
- Do NOT modify any files in the project repo
- The engine will automatically chain this plan into a PRD conversion step
- Focus on being thorough but actionable — the PRD agent needs clear items to convert

## When to Stop

Your task is complete once you have written the plan file to `{{team_root}}/plans/{{plan_file}}`. Do NOT begin implementation. Stop after writing the plan.

## Team Notes
{{notes_content}}
