/ship: fix-or-skip questions omit each finding's severity, because the shared decision-brief template has no slot for it

Open Beginner friendly
  • Is something wrong?
#3,632 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
tooling

Research direction

Start with the shared decision-brief template in ship/sections/preamble.md and compare it with the severity requirements in ship/sections/review-army.md and ship/SKILL.md. Update the template and its self-check so review-finding questions show severity and whether they block shipping; check any existing lint for rendered AskUserQuestion output if pursuing the optional lint. Done when fix-or-skip questions follow the documented review policy and identify informational findings as non-blocking.

Written by the indexing model from the issue text.

Description

S3

gstack v1.91.324.0 (53db038c), Claude Code (Claude Opus 5.5).

What happened

During /ship's pre-landing review (Step 9, pass 1), the agent asked four fix-or-skip questions, one finding or group per question.
Every one of the findings was INFORMATIONAL: none would fail a test, break production, or lose data or secrets.
None of the four questions said so.
Each followed the shared decision-brief format: D<N> title, ELI10, "Stakes if we pick wrong", Recommendation "A) Fix", Completeness (Fix 10/10 against Skip 5–6/10), pros and cons, Net.
To the reader, each one looked like a defect that had to be fixed before shipping.
The user had to stop the run and ask what each finding's severity was before answering.

The agent missed a rule the skill states.
But the skill's own structure makes that miss the likely one, so it is reported here rather than only as a model error.

Where the rule is, and where it gets lost

The rule is stated in three places:

  • ship/sections/review-army.md:45-46: "Every finding MUST include a severity, CRITICAL (blocks shipping) or INFORMATIONAL (lower severity, still actioned)".
  • ship/sections/review-army.md:520: the rendered finding line, [SEVERITY] (confidence: N/10, specialist: name) path:line — summary.
  • ship/sections/review-army.md:712-714: "present them in ONE AskUserQuestion (or one per item for 3 or fewer): each item's number, severity, problem and recommended fix with A) Fix B) Skip".

The question itself is written from the shared preamble's format (ship/sections/preamble.md, the D<N> template near line 57), and every AskUserQuestion has to use that format.
The template has no severity line, and its "Self-check before emitting" list checks the D<N> header, ELI10, Recommendation, Completeness, pros and cons and Net:, but not severity.
So the one checklist the agent runs right before asking passes a fix-or-skip question with no severity.

The template also pushes against the review policy.
ship/SKILL.md says "only a finding that would fail a test, break production, or lose data or secrets blocks a pass; the rest is a PR-body note".
But "Stakes if we pick wrong" and a Completeness score that rates Skip at 5–6/10 make a non-blocking finding read like a blocking one.
A user answering a stream of these questions without the severity has no way to tell a note from a blocker.

Suggested fix

  • Give fix-or-skip questions a required first line, before ELI10: Severity: CRITICAL|INFORMATIONAL (confidence: N/10) — blocks shipping: yes|no, and add it to the self-check list whenever the question is about a review finding.
  • When every finding in a question is INFORMATIONAL, say so in the title or ELI10 (for example "non-blocking; Skip makes it a PR-body note").
    Score Completeness on what the fix covers, not as if Skip ships a defect.
  • Optionally, have a lint over a rendered AskUserQuestion refuse a review-finding question that has no severity token, the same way the (recommended) marker is already parsed.
Dominant language
TypeScript
Stars
138k
Forks
20.5k
Avg merge
10h 55m
Merged PRs (30d)
410

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from garrytan/gstack

All issues in garrytan/gstack

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.