request-plan
/request-plan
Use when a new feature, change, or repository modification requires a plan or specification. Not for unproven problems with open solution space — use parallel-brainstorming.
- Author
- j0hanz ↗
- Repository
- squad-agents ↗
- Licence
- MIT
- Last repository change
- 18.07.2026
Assessment and security
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 0
No signals detected. Repository changed on 18.07.2026, without references to retired models or APIs.
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Use when a new feature, change, or repository modification requires a plan or specification. Not for unproven problems with open solution space — use parallel-brainstorming.
Arguments
/request-plan [--depth sketch|contract|blueprint] <feature description>
Original author description
Use when a new feature, change, or repository modification requires a plan or specification. Not for unproven problems with open solution space — use parallel-brainstorming.
How it works
- Process Flow
- Step 0: Infer Depth
- Step 1: Discovery
- Step 2: Parallel Drafting (Ideators)
- Step 3: Synthesis
- Step 4: Write
- Step 5: Verification
- Headless Fallback (REVISE from receive-plan)
- Canonical Task Block Schema
- Strict Rules
SKILL.md preview
--- name: request-plan description: 'Use when a new feature, change, or repository modification requires a plan or specification. Not for unproven problems with open solution space — use parallel-brainstorming.' disable-model-invocation: false user-invocable: true argument-hint: '[--depth sketch|contract|blueprint] <feature description>' allowed-tools: Write, Agent, Skill(receive-plan), Read, Grep, Glob, Edit --- # request-plan Draft `plan/<kebab-case-feature-name>.specs.md` + `plan/<kebab-case-feature-name>.plan.md`. Depth controls agent count. `receive-plan` runs after contract/blueprint; sketch skips it entirely. The file base name `<kebab-case-feature-name>` must be kebab-case representation of the feature description (e.g., `new-login-flow`). ## Process Flow - **0. Infer Depth** (no prompt — see Depth Inference) - **1. Discovery** (inline grep/glob → Context Report) - **2. Parallel Drafting** (Ideators) - **3. Synthesis** - **4. Write** `plan/NAME.specs.md` + `plan/NAME.plan.md` (Status: DRAFT) - **5. Verification** (hand off to receive-plan; sketch skips) ## Step 0: Infer Depth No `AskUserQuestion`. Resolve in order: 1. `--depth` flag on the invocation → use it. 2. Keywords in description → `sketch`: "throwaway / rough / spike / quick note / temporary"; `blueprint`: "production / migration / rollout / breaking change / compliance / security / structural". 3. Autonomous caller (e.g., when invoked by another subagent or automation script without active user terminal attachment) without depth signal → `contract`. 4. Default → `contract`. Announce the inferred depth and subagent count in the first line of output. Do not pause. Subagent counts to announce: - sketch: 0 subagents - contract: 2 subagents (2 Ideators, 0 Synthesizers) - blueprint: 4 subagents (3 Ideators, 1 Synthesizer) **Done when:** inferred depth (`sketch`/`contract`/`blueprint`) and subagent count are announced in the first line of output. ## Step 1: Discovery Main thread runs Grep/Glob inline. Produce a non-empty **Context Report**: related files, key symbols, interfaces, recent changes, constraints, scope boundaries. Ideators and main thread do not re-scan. Wrap any user-pasted or external content in `<untrusted_context>` tags before including it in the Context Report. **Done when:** Context Report is completed and lists related files, key symbols, interfaces, recent changes, and constraints, with external content wrapped in `<untrusted_context>`. ## Step 2: Parallel Drafting (Ideators) Dispatch ideators in ONE message, blind to each other. Provide each with the **Context Report** from Step 1 — no codebase re-scanning. - `contract`: 2 agents — **Conventional** lens, **Risk-First** lens. - `blueprint`: 3 agents — **Conventional**, **Risk-First**, **Minimalist** lens. Each ideator produces a **lightweight proposal**: a short approach summary + a numbered task list. Plain prose — the Canonical Task Block Schema is not required at draft stage (see Strict Rules). **Done when:** - For contract/blueprint: all ideators dispatched in ONE message (contract: 2, blueprint: 3) and each returns a lightweight proposal + numbered task list. - For sketch: the main thread drafts and outputs the inline proposal in plain prose. ## Step 3: Synthesis - `sketch`: Skip — Step 2 output goes directly to Step 4. - `contract`: **Main thread** merges the 2 proposals. State what was kept and discarded from each candidate. Write the merged result using the Canonical Task Block Schema. - `blueprint`: **1 Synthesizer agent** receives both proposals and merges them. Same rationale requirement. Writes final output in Canonical Task Block Schema. **Done when:** - For contract/blueprint: proposals merged into one result written in the Canonical Task Block Schema, including a documented rationale of what was kept and discarded from each candidate. - For sketch: instantly marked done (transitions Step 2 output directly to Step 4). ## Step 4: Write Save as `plan/<kebab-case-feature-name>.specs.md` and `plan/<kebab-case-feature-name>.plan.md` with header `Status: DRAFT`. All task entries must use the Canonical Task Block Schema. For `sketch` depth, the main thread converts the Step 2 plain prose draft into the Canonical Task Block Schema during this step. **Done when:** the specs and plan markdown files exist on disk under the `plan/` directory with `Status: DRAFT` header and Canonical Task Block Schema task entries. ## Step 5: Verification - `sketch`: Done — no handoff. - `contract` / `blueprint`: Pass file paths to `receive-plan`. Include the depth so receive-plan does not default to a heavier check than necessary. **Done when:** `sketch` ends with no handoff, or `contract`/`blueprint` file paths + depth are passed to `receive-plan`. ## Headless Fallback (REVISE from receive-plan) Re-run synthesis only — do not re-dispatch ideators: - `contract`: Main thread re-synthesizes with the REVISE findings added as constraints. - `blueprint`: Re-dispatch the Synthesizer agent with the REVISE findings. Re-submit the corrected plan to `receive-plan`. If `receive-plan` returns REVISE a second time, write a detailed error summary to the console, notify the user via a high-priority message, and stop execution (do not use AskUserQuestion). ## Canonical Task Block Schema Required in all final `specs.md` and `plan.md` outputs; ideator proposals are exempt (see Strict Rules). ```markdown ### TASK-NNN: [Action title] Depends on: [TASK-NNN](#task-nnn) (or comma-separated list: [TASK-001](#task-001), [TASK-002](#task-002)) or none Files: [path/to/file.ts](path/to/file.ts) (or comma-separated list of workspace-relative paths) Symbols: [symbolName](path/to/file.ts#L42) (or comma-separated list of workspace-relative symbol paths) Satisfies: REQ-001, SEC-002 (comma-separated list of requirements defined in specs.md) Action: Single specific imperative implementation action. Validate: `[runnable shell command]` Expected result: Observable success signal. ``` **Requirement Format (specs.md):** All requirements in `specs.md` must be declared in the following format so they can be parsed and matched: ```markdown #### REQ-NNN: [Short description] Detail: [Specific requirement statement] ``` ## Strict Rules - **NO Prompt at Step 0**: depth is inferred — never pause for `AskUserQuestion`. - **NO Re-Scan**: pass the Context Report to ideators; they must not run their own discovery. - **NO Cross-Talk**: ideators must never see each other's proposals. - **NO Mocked Ideators**: ideators must be distinct subagents; the main thread cannot generate/simulate candidate proposals itself. - **NO Shell Execution**: do not run arbitrary terminal/shell commands during discovery, drafting, or synthesis. - **NO Schema at Draft Stage**: ideators write lightweight proposals; schema is synthesis-only. ## Next Skills | Skill | Use Case | | :--------------------------------------- | :------------------------------------------------------------------ | | [receive-plan](../receive-plan/SKILL.md) | Verify a plan/specs pair before execution (contract/blueprint only) |
Versions
The database has no other skills named request-plan.
Database snapshot: 13.11.2026 · package version 6c9c04e6ebff (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 90writing-specs
Use when a feature or behavior change needs an implementation-ready specification before planning or coding - 100writing-feature-prds
Use when starting a new feature, defining requirements before implementation, or when the user says "new feature", "create a spec", "create a PRD", or "feature PRD". - 100plan-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. - 85planner-feature
Create a plan for a feature, and the files required to continue working on it. Use when the user asks for research for a feature or a plan to run it. - 100create-specs
Specification-driven workflow with human approval gates for new analysis features. Use when starting a feature, or when asked to write a spec, plan, task list, or status file. Provides templates for spec.md, plan.md, tasks.md, and status.md. - 100brainstorming-gate
Use when about to implement any feature, build any component, or make any behavioral change — requires design exploration and user approval before implementation