Skill · Plan and specify
/spec$spec@planr-spec
Turn a vague product or engineering idea into a clear, measurable specification grounded in your repository, before anyone plans or builds.
/specin Claude Code. If /spec runs another command, use /planr:spec.
$specin Codex. With the OpenPlanr plugin for Codex, use $planr:spec.
@planr-specin Cursor. Cursor applies the planr-spec rule when you mention it in chat.
What it does
Shape vague product or engineering intent into a clear, measurable Protocol-compatible specification grounded in the current repository. Use when requirements need clarification before planning or implementation.
The skill reads your request, the repository instructions, existing plans, and the relevant code and tests. When a missing decision would change the scope or the behavior, it asks you, at most 3 short questions at a time, with the recommended option first. Then it writes one specification whose requirements and acceptance criteria are observable, each criterion with a stable ID.
The sections follow the specification contract the skill ships with. The reply links the saved file and ends with the exact command to plan the spec next. Walk through it in Write your first spec.
When to use it
Use it to
- Turn vague product or engineering intent into a precise specification
- Clarify requirements and acceptance criteria before planning
Not for
- Implement an existing specification
- Return project status
Example
/spec add passwordless sign-in for existing accounts. Users drop off at the password step.$spec add passwordless sign-in for existing accounts. Users drop off at the password step.@planr-spec add passwordless sign-in for existing accounts. Users drop off at the password step.What you get
.planr/specs/SPEC-001-<slug>/SPEC-001-<slug>.md---id: "SPEC-001"title: "<title>"slug: "<slug>"schemaVersion: "1.7.0"---## Context & Goal## Audience## Outcome & Measurement## Functional Requirements## Business Rules## Constraints## Evidence Expectations## Failure Modes## Rollback## Scope Boundaries## Acceptance Criteria## Declared Risk Specialists## Notes for DecompositionPrompts and commands
Pin down acceptance criteria before planning
Turn loose requirements into observable criteria with stable IDs before anyone plans the work.
Turn a rough idea into a spec
Start every feature with a specification your agent can check its work against.
Audit the plan for drift
Check that stories, tasks, statuses, and references in the planning folder still agree.