brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
pr-to-specAnalyze code changes and detect intent drift using the pr-to-spec CLI — converts a branch, staged edits, or recent commits into a structured, agent-consumable spec. Use when declaring intent before a change, checking a finished change for drift against that intent, or generating a spec for agent review. Trigger with "/pr-to-spec", "pr-to-spec scan", "pr-to-…
Independent GitHub snapshot · Automated classification · Original documentation governs
Convert code changes into structured, agent-consumable specs with intent
drift detection. The workflow is: declare what a change is supposed to do
(intent set), make the changes, then check — the CLI produces a spec of
what actually changed plus drift signals against the declared intent, wrapped
in a versioned JSON envelope any agent can consume.
pr-to-spec CLI on PATH (it ships with this plugin; standalone install
and MCP-server usage are covered in the repo README).Analyze current branch changes vs main and output a structured spec.
pr-to-spec scan --branch main --json
Use --diff N to scan last N commits, or --staged for staged changes only.
Scan current changes AND check for drift against declared intent.
pr-to-spec check --json
Returns exit code 3 if drift is detected, 2 if high-risk, 0 if clean.
Declare what this change is supposed to do.
pr-to-spec intent set --goal "Add rate limiting to API" --scope "src/middleware/**" --forbid "src/db/**" --max-risk medium
Show the current intent declaration.
pr-to-spec intent show --json
All --json output is wrapped in the agent protocol envelope:
{
"version": 1,
"command": "check",
"status": "drift_detected",
"exit_code": 3,
"signals": [...],
"spec": {...},
"intent": {...}
}
The spec field is the structured description of what changed, intent is
the declared intent (when one exists), and signals carries the drift and
risk findings that produced the status and exit_code.
Interpret exit codes — they are the contract:
| Code | Meaning |
|---|---|
| 0 | Clean — no issues |
| 1 | Error |
| 2 | High-risk changes detected |
| 3 | Drift detected |
--forbid pattern, or diverged from the declared goal. Stop and
investigate before continuing; either fix the change or re-declare intent
deliberately.--max-risk
ceiling. Review the signals array for which risk flags fired.check, malformed arguments). The message on stderr says
which; fix the invocation rather than the code.Full declare → change → check loop:
pr-to-spec intent set --goal "Add rate limiting to API" --scope "src/middleware/**" --forbid "src/db/**" --max-risk medium
# ...make the changes...
pr-to-spec check --json # exit 0 = clean, 2 = high-risk, 3 = drift
Wire it into a project's CLAUDE.md so every significant change runs the loop:
## Change Validation
Before any significant code change:
1. Set intent: `pr-to-spec intent set --goal "..." --scope "..." --max-risk medium`
2. After changes: `pr-to-spec check --json` — exit 3 means drift, investigate before continuing