Read time: 8 minutes. You need no engineering skill. You need access to the repository’s pull requests (GitHub or GitLab web) and, optionally, claude.ai or Claude Code.
Requirements and design used to be two phases run by two teams. Now Claude writes the requirements-and-design spec from an accepted intent, constrained by the organisation’s policies, and you review it instead of writing it. Your two decisions are the two gates at the front of the loop: accepting an intent and accepting a spec. Both are one-click merges, and both are recorded.
| Situation | What to do |
|—|—|
| An Intent: pull request is assigned to you | read it, decide, merge or close (web UI) |
| An intent is accepted and no spec exists yet | nothing: CI opens a Spec: PR within minutes. If CI is not set up, run /sdlc:spec <change-id> in Claude Code or ask Claude in claude.ai |
| A Spec: pull request is assigned to you | resolve flagged concerns, then merge |
| “What is waiting on me?” | /sdlc:status --gate product-owner, or ask Claude “what is waiting on the product owner?” |
| Front-end work | mock the design (Figma or Claude Design) from the accepted intent and paste the link in the spec’s “User experience” section; engineering compares the build against it |
Ask: is this a real problem for real users? Are the constraints honest? Is the out-of-scope list sane?
status: draft to status: accepted, commit, merge.risk: high (money, auth, personal data, regulated data, infrastructure), a tech
lead must also approve. Ask them before merging.status: accepted, merge. That starts engineering’s plan mode. From here you review pull requests only
if you want to; the artifacts carry your decisions.The top of a spec:
## Flagged concerns
| # | Concern | Policy / skill | Owner | Decision |
| 1 | Loss adjusters are third parties; showing them claim status exposes customer PII. | security-policy | Security lead | |
| 2 | claims-core rate limit is 50 rps; a panel polling per page view could exhaust it. | secure-api-review | Platform | |
If the PR carries the label needs-human, an independent checker thought the spec should not proceed without
extra scrutiny; its reason is in the PR description.
Accept or reject intents and specs. Decide flagged concerns with their owners. Claude flags; it never decides a
policy conflict, and it never sets status: accepted.
Write the spec, run workshops to formalise requirements, or translate between analysts and designers.
/sdlc:metrics is run by your platform engineer or leadership (ask them for the report, or /sdlc:status
for your own gates); the numbers that matter to you: time from intent to spec should be hours; spec edits
after engineering starts should fall toward zero; the share of intents accepted (survival rate) tells you
whether the front of the loop is healthy.
status: literally reads accepted, and
that the CI secret ANTHROPIC_API_KEY exists (platform engineer). Fallback: /sdlc:spec <id>./sdlc:spec <id> again on the same branch). Do not accept a spec you would not hand to engineering.