Tighten plan

You refine plan.md and tasks.md one issue at a time. spec.md is the source of truth. You do not edit the spec. You do not answer new product questions.

Do not offer a single menu (“fix the whole review”). That hides per-finding decisions.

Do not patch until the user picks a resolution for the current issue (or a batch of P#: letter answers). suggest is not a patch. send-to-spec is not a plan patch.

Find the spec folder

Use the folder the user @-mentions. Otherwise the most recently edited tree under docs/specs/ excluding _template/. If several, ask which slug. Expected headings: this skill’s assets/plan.md and assets/tasks.md.

Need spec.md, plan.md, and tasks.md. If plan/tasks are missing, stop (/crav1-plan-from-spec).

Read those three. Note diagrams.md / adr/ / export/openspec/ if present. Read docs/system/security.md and a Security section on the spec when those exist. Check rules: crav1-plan-from-spec references/checks.md (drop-in: .claude/skills/crav1-plan-from-spec/references/checks.md; plugin: sibling skills/crav1-plan-from-spec/references/checks.md).

Also read the latest crav1-plan-reviewer-agent / /crav1-review-plan output in this chat. Those findings become issues. Do not collapse them into one “apply reviewer notes” action.

Build the issue list (no edits)

Number issues P1, P2, … Each issue is one plan/task defect.

Sources, in order:

1. Numbered P#s already listed by the plan reviewer in this chat (preserve meaning; split if they bundled two problems). Keep their plan vs spec tag.
2. Fresh read of plan.md / tasks.md against spec.md (add only what the reviewer missed)

Typical plan shapes:

• T# too big to verify alone (“add authentication”)
• Missing verify: kind, missing named checks, or missing (spec: …)
• An algorithm with one happy check and no corner cases
• Behavior that already works, with no regression check
• Two parts meet, with no integration test for that edge
• A kept security check with no task and no “covered by T#”
• Load or speed goal the spec did not state
• Smoke after deploy, chaos, or fuzzing for its own sake, or test code in the plan
• Task or approach step invents behavior the spec does not require
• Acceptance / REQ with no task (or task with no spec line)
• Files likely touched wrong, missing, or not (proposed) when there is no repo
• ## Linter missing, or it never says whether this repo has a linter or checker for the code the tasks will touch
• Plan treats a kept-open spec question as decided

Spec tag: the plan is fine or cannot be honest until spec.md changes. Do not “fix” that by writing product behavior into the plan.

Skip nitpicks. Merge duplicates. Prefer fewer sharp issues.

If no plan issues remain (spec-tagged ones only, or none): say so. Next: spec-tagged → /crav1-tighten-spec / /crav1-resolve-open-questions; else new chat, /crav1-build-tasks with plan.md, tasks.md, and spec.md attached.

When ## Linter says this repo has no linter or checker for the code the tasks will touch, do not name those Build commands. Stop before Build. The user decides to add the linter or to go on without one. Do not install one. When they already chose to go on without one in this turn, the Build next step applies, and the plan still says none. A plan that already says none is not a P# by itself.

Walk one issue at a time

Walk plan-tagged P#s here. When the current item is spec-tagged: do not offer plan patches. Tell them /crav1-tighten-spec or /crav1-resolve-open-questions for that finding, mark it skipped-for-plan, advance.

Index (every turn, short)

Remaining P# titles only. Mark the current one. Note plan vs spec.

Current issue (full)

For only the current plan P#:

1. Finding — one or two sentences. Quote the plan/task line.
2. Why it matters — verify-ability, extra scope, or silent spec decision.
3. Options — 2–4 mutually exclusive plan resolutions, then suggest. Use the questions tool when available. Always keep suggest. Add ask / keep / send-to-spec when they fit.

Every option: letter, name, what changes, impact (which T#s / files). Never add a product feature as a “fix.”

4. How to answer: A / B / … or a batch: P1 A, P3 C. Unmentioned issues stay for later.

Stop. Do not edit. Do not preview a full patched plan.

If they already answered this P# with a patch letter in the same message, skip the menu and execute. If they asked for a suggestion, follow When they pick suggest.

When they pick suggest

Do not patch. Stay on this P#. Name the letter you would pick and why (2–4 sentences). Re-offer the same patch letters, with the suggested one first and its label ending in (Recommended) (letters do not change). At most one alternate suggestion, then they must pick a patch letter, ask, keep, or send-to-spec.

After a choice

1. Patch only plan.md and/or tasks.md as that resolution allows. Never spec.md.
2. Recap Added / Removed / Still open for this P#.
3. If export/openspec/design.md or tasks.md exist, update them to match (same tasks, no extra scope) when the resolution changed tasks.
4. Advance to the next unanswered P#. If none remain, give the empty-queue next steps above.

Do not start the next issue’s patch in the same turn unless they batched.

Resolution catalog (per plan issue)

Id	Name	What it does	Typical impact
split-task	Split this T#	Replace one oversized task with independently verifiable T#s. Renumber if needed; fix the trace table.	tasks.md (+ plan.md trace / approach if it named the old id).
add-verify	Add verify	Name the kind and the checks on verify: (one or many; not one test per kind). Add (spec: …) if missing.	That T# line, unless trace also lacked the spec id.
add-cases	Name the cases	When the spec describes an algorithm, name several checks, including corner cases of the behavior it already states.	That T# verify note.
add-regression	Name the regression	Name checks that would fail if behavior that already works broke.	That T# verify note, or one new T# and the trace.
add-integration	Name the boundary	When two parts meet, name an integration test for that edge.	That T# or one new T#. A system test of the whole path does not replace it.
cover-security	Cover the security check	Map a kept check from docs/system/security.md or the spec Security section to a T#, or mark “covered by T#”.	Trace row; a new T# only when no task already proves that check.
drop-scope	Drop extra scope	Remove the step/T# that is not in the spec (or move it to plan Out of scope).	Smaller task list; trace still covers remaining acceptance.
fix-trace	Fix trace	Map acceptance/REQ ↔ T#. Add a covering task or mark “covered by T#”.	plan.md Trace table; maybe one new T#.
retarget-files	Fix files likely touched	Correct paths; mark (proposed) if no repo. Do not invent a new architecture.	plan.md Files section.
name-linter	Name the linter	Search the repo. When it has a linter or checker for the code the tasks will touch, name the tool and the command under ## Linter, and say Build leaves that check green. When it does not, write that. Do not install one.	plan.md Linter section.
park-risk	Park as risk	Plan was treating a kept-open question as decided. Remove that decision from tasks; list it under Risks.	No silent product answer.
send-to-spec	Send to spec	This is a spec defect or a new product question. Do not patch the plan.	No disk change here. Next: /crav1-tighten-spec or /crav1-resolve-open-questions.
keep	Keep as written	Accept the cost (usually untestable or extra scope).	No disk change. Rare; say the cost.
suggest	Get a suggestion	Recommend one offered patch letter. No edits.	Stay on this P#. Always offer.
ask	Ask, don’t patch	At most 3 questions about this issue.	Retry this P#.

Do not offer apply-notes for the whole review.

Reviewed line

plan.md may have Reviewed: <date>, P# open: <n> under its title, written by /crav1-review-plan. After each patched P#, and when a P# is dropped as not an issue, lower <n> to the number of reviewer P#s still open. Keep the date. A P# the user leaves open stays counted. When there is no Reviewed: line, do not add one: only /crav1-review-plan records a review. This line is the only plan.md change this skill makes outside the picked patches.

Hard rules

• Prefer splitting or dropping over adding product scope.
• Never edit spec.md, diagrams, or ADRs. Never write application code.
• Never resolve an Open question by encoding an answer in a T#.
• Do not start implement/complete-task in this chat unless they explicitly asked after plan issues are done. When ## Linter says there is no linter, that ask is the choice to go on without one. Do not install a linter.
• Do not run /crav1-review-pr. Specify does not name the linter.
• Do not patch “to be helpful” when they have not chosen a plan patch (suggest and send-to-spec are not plan patches).