@next-friday/create-app 9.7.2 → 9.8.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@next-friday/create-app",
-  "version": "9.7.2",
+  "version": "9.8.1",
   "description": "Create a Next Friday project from a template.",
   "keywords": [
     "create",

package/templates/base/SETUP.md

@@ -97,12 +97,14 @@ Replace `security@example.com` in `SECURITY.md` with the contact the security po
 - **Sources of truth (engineering lead):** for each artifact, name one system as the source of truth: this repository, an existing tool such as Jira, or, as the minimum, a link both ways (the record id in the file and the commit SHA in the record).
 - **Higher risk (engineering lead):** decide which changes count as higher risk. A tech lead or architect approves their specs and plans.
 - **Policies (each policy owner, with an engineer):** the plugin ships a default for each area, `plugins/sdlc/claude-code/skills/<area>-policy/SKILL.md` (security: OWASP ASVS 5.0.0 Level 1; UX: WCAG 2.2 Level AA; compliance: the OECD privacy principles; brand: one declared source for every brand value). Review it. To replace a default, add the organization's own rules in `.agents/skills/<area>-policy/SKILL.md` in the project: that file wins over the plugin's default, and the `CODEOWNERS` line of step 2 for that area makes the policy owner its code owner. Do not edit the plugin's copy. Then run `pnpm rules:sync`, which renders the project's own policy skill for Claude Code and Cursor. Test that the skill triggers: ask for the relevant task in different ways and confirm the skill loads each time.
-<!-- deploy:railway -->
-- **Production gate (engineering leadership, with change management and compliance):** name the release managers and add them as required reviewers on the `prod` environment, as the README's deploy section describes. `.agents/hooks/agent-production-gate.sh` blocks an agent's shell commands that dispatch a `prod` deploy, run a Railway command with `prod` as its environment, or push a release tag. It does not read MCP tools. A release manager whose own agent session must do one of these starts the agent with `RELEASE_APPROVAL` set to the approval record, for example `RELEASE_APPROVAL=CHG-123 claude`. The value lifts the gate only when it matches the extended regular expression on the first line of `.agents/release-approval-form`, shipped as `^[A-Z]+-[0-9]+$`; set that line to the form of your organization's approval records. Each gate hook appends its decisions to `.agents/logs/gate-decisions.jsonl`, which git ignores: the time, the hook, the decision, the session, and the reason for a block, and, when the production gate is lifted, the approval value and the Git user name. A record holds no command text and no path.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate (engineering leadership, with change management and compliance):** name the release managers and add them as required reviewers on the `prod` environment, as the README's deploy section describes. `.agents/hooks/agent-production-gate.sh` blocks an agent's shell commands that dispatch a `prod` deploy or push a release tag. It does not read MCP tools. A release manager whose own agent session must do one of these starts the agent with `RELEASE_APPROVAL` set to the approval record, for example `RELEASE_APPROVAL=CHG-123 claude`. The value lifts the gate only when it matches the extended regular expression on the first line of `.agents/release-approval-form`, shipped as `^[A-Z]+-[0-9]+$`; set that line to the form of your organization's approval records. Each gate hook appends its decisions to `.agents/logs/gate-decisions.jsonl`, which git ignores: the time, the hook, the decision, the session, and the reason for a block, and, when the production gate is lifted, the approval value and the Git user name. A record holds no command text and no path.
-<!-- deploy:end -->
+- **Production gate (engineering leadership, with change management and compliance):** name the release managers and add them as required reviewers on the `prod` environment, as the README's deploy section describes. `.agents/hooks/agent-production-gate.sh` blocks an agent's shell commands that dispatch a `prod`
+  <!-- deploy:railway -->
+  deploy, run a Railway command with `prod` as its environment,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  deploy
+  <!-- deploy:end -->
+  or push a release tag. It does not read MCP tools. A release manager whose own agent session must do one of these starts the agent with `RELEASE_APPROVAL` set to the approval record, for example `RELEASE_APPROVAL=CHG-123 claude`. The value lifts the gate only when it matches the extended regular expression on the first line of `.agents/release-approval-form`, shipped as `^[A-Z]+-[0-9]+$`; set that line to the form of your organization's approval records. Each gate hook appends its decisions to `.agents/logs/gate-decisions.jsonl`, which git ignores: the time, the hook, the decision, the session, and the reason for a block, and, when the production gate is lifted, the approval value and the Git user name. A record holds no command text and no path.
 - **Review (tech lead):** `.agents/review.md` names this stack's generated files to skip; add a path when the project gains a generated file, then run `pnpm rules:sync`, which renders it to `REVIEW.md` for Claude Code Review. Once a month, rate the review findings and tune `.agents/review.md`.
 - **People without Git experience:** connect GitHub to Claude (claude.ai or Cowork), so Claude commits `intent.md` for them.
 

package/templates/base/plugins/sdlc/claude-code/hooks/check-reply-shape.sh

@@ -63,10 +63,9 @@ case $mode in
     ;;
 esac
 first=$(printf '%s\n' "$reply" | awk 'NF{print; exit}')
-case $first in '**Request:**'*) ;; *) exit 0 ;; esac
+case $first in '**Answer:**'* | '**Result:**'* | '**No change:**'*) ;; *) exit 0 ;; esac
 
 last=$(printf '%s\n' "$reply" | awk 'NF{l=$0} END{print l}')
-request=$(printf '%s\n' "$reply" | grep -m1 '^\*\*Request:\*\*')
 outside_fences=$(printf '%s\n' "$reply" | awk '/^[[:space:]]*(```|~~~)/{f=!f; next} !f')
 outside_urls=$(printf '%s\n' "$outside_fences" | sed -E 's#https?://[^][:space:])>]*# #g')
 outside_code=$(printf '%s\n' "$outside_urls" | tr 'A-Z' 'a-z' \
@@ -78,15 +77,35 @@ number=$(printf '%s\n' "$outside_code" \
   | grep -Ev '[[:space:]]of[[:space:]]' | head -1 | sed -E 's/^[^#[:alnum:]]//; s/[^[:alnum:]]$//')
 problems=
 [ -n "$number" ] && problems="Replace \"$number\" with the full URL of that pull request or issue, or with \"this pull request\". "
+only_line=$(printf '%s\n' "$reply" | awk 'NF{n++} END{print n+0}')
+not_yet=$(printf '%s\n' "$outside_fences" | grep -E '^[[:space:]]*([-*+][[:space:]]+)?\*\*Not yet:\*\*')
+page_urls() {
+  grep -Eo 'https?://[^][:space:]()<>]+' \
+    | sed -E 's#[`*_"'"'"'!?.,;:]+$##; s#[?\#].*$##; s#/+$##' \
+    | tr 'A-Z' 'a-z' | sort -u
+}
 case $last in
-  '**Status:**'*)
-    if printf '%s' "$request" | grep -Eq 'https?://' \
-      && ! printf '%s' "$last" | grep -Eiq 'Next:\**[[:space:]]*[<(]?https?://[^[:space:]]+[[:space:]]*$|no next page'; then
-      problems="${problems}End the **Status:** line with \`Next: <full URL of the page where the person acts next>\`, or say \"no next page\" when none waits. "
+  '**Now:**'*)
+    now_urls=$(printf '%s\n' "$last" | page_urls)
+    now_url=$(printf '%s\n' "$now_urls" | head -1)
+    if [ "$(printf '%s\n' "$now_urls" | grep -c .)" -gt 1 ]; then
+      problems="${problems}The **Now:** line holds more than one URL. Name one thing for the person to do, with one URL. "
+    fi
+    if printf '%s' "$now_url" | grep -Eq '^https?://[^/]+/[^/]+/[^/]+/(.*/)?(pulls|issues)$'; then
+      problems="${problems}The **Now:** line links a list page. Link the one page where the person acts, or write no URL when the person has nothing to do. "
+    fi
+    if [ -n "$now_url" ] && printf '%s\n' "$not_yet" | page_urls | grep -Fxq "$now_url"; then
+      problems="${problems}The **Now:** line links the page the **Not yet:** line names. Write no URL there until the person may act on that page. "
     fi
     ;;
-  *) problems="${problems}End the reply with a line that starts with **Status:**; nothing may follow it. " ;;
+  '**No change:**'*)
+    [ "$only_line" -eq 1 ] || problems="${problems}End the reply with a line that starts with **Now:**; nothing may follow it. "
+    ;;
+  *) problems="${problems}End the reply with a line that starts with **Now:**; nothing may follow it. " ;;
 esac
+if [ "$(printf '%s\n' "$not_yet" | grep -c .)" -gt 1 ]; then
+  problems="${problems}The reply holds more than one **Not yet:** line. Keep one. "
+fi
 
 if [ "$changed" = true ] && ! printf '%s\n' "$outside_fences" | grep -q '^\*\*Checks:\*\*'; then
   problems="${problems}A file outside intent/ changed in this turn and the reply has no **Checks:** section. Run the checks the project names and add **Checks:** with each command and the lines of its output that show the result, or with each check that could not run and why. "

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-help/SKILL.md

@@ -6,11 +6,11 @@ disable-model-invocation: true
 
 # SDLC help
 
-1. When the message asks for work rather than how, open no project file. The whole reply is two lines: this command starts no work; and the message to send instead, which is `/sdlc:sdlc-mode` followed by their own words.
+1. When the message asks for work rather than how, open no project file. The whole reply is two lines: this command starts no work; and, on the **Now** line, the message to send instead, which is `/sdlc:sdlc-mode` followed by their own words.
 2. When the topic is unclear, ask one question with these choices: how the workflow runs and starting work, keeping `/sdlc:sdlc-mode` on for a session, fixing a defect in behaviour that already exists, who decides at each gate, a mistake the agent repeats, or company policy.
 3. Read the files the topic points to before you answer. When a file disagrees with the map below, the file is right.
-4. When the person asks about a playbook, a command, or a file that this project does not have, the whole reply is three lines: it does not exist; what exists instead, as one file path; and one message they can send next. Stop there. Do not explain the topic from other files.
-5. Otherwise answer, then give one message the person can send as is, with real words from their question and no blanks to fill in, then list the files the answer came from.
+4. When the person asks about a playbook, a command, or a file that this project does not have, the whole reply is three lines: it does not exist; what exists instead, as one file path; and, on the **Now** line, one message they can send next. Stop there. Do not explain the topic from other files.
+5. Otherwise answer, then list the files the answer came from, then give, on the **Now** line, one message the person can send as is: the word `Send` and then the whole message in a code span, with real words from their question, no blanks to fill in, and nothing the person must add.
 6. Write the reply by the reply rules in `../sdlc-mode/SKILL.md`.
 
 ## Map

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/SKILL.md

@@ -25,10 +25,10 @@ Do these steps in order.
 
    When a request both asks a question and reports a problem, use `question` and offer `plan` in one line. A problem reported with `/sdlc:sdlc-mode` is the person's ask for `plan`.
 
-   Do not start work a person did not ask for. When a message reports a problem without asking for work, answer in a few lines and give, on the **Status** line, the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
+   Do not start work a person did not ask for. When a message reports a problem without asking for work, answer in a few lines and give, on the **Now** line, the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 
-2. **Open the task list** when the session offers a task-list tool. Its first items are the matched playbook's numbered steps, copied word for word, before any other task. A step you do not do stays in the list with `skip: <reason>`. Use `skip` only for a step you decide never to do. A step marked **Gate** is never skipped. When the session offers no such tool, the steps go in the reply instead, under **Steps**, and are never left out, except for `question`. When a playbook's **Next** line chains another playbook, add that playbook's steps when you start it.
-3. **Do the playbook's steps yourself,** stopping only at a step marked **Gate**, or before an action that cannot be undone. At a step marked **Gate**, wait for the person it names. When a playbook's **Next** line says an agent runs the next file "in the same turn", read that file and continue without asking; otherwise stop at the Gate. Mark each step done in the task list as you finish it.
+2. **Open the task list** when the session offers a task-list tool. Its first items are the matched playbook's numbered steps, copied word for word, before any other task. A step you do not do stays in the list with `skip: <reason>`. Use `skip` only for a step you decide never to do. A step marked **Gate** is never skipped. When the session offers no such tool, the steps go in the reply instead, under **Steps**, and are never left out, except for `question`. When a playbook's **Hands off to** line chains another playbook, add that playbook's steps when you start it.
+3. **Do the playbook's steps yourself,** stopping only at a step marked **Gate**, or before an action that cannot be undone. At a step marked **Gate**, wait for the person it names. When a playbook's **Hands off to** line says an agent runs the next file "in the same turn", read that file and continue without asking; otherwise stop at the Gate. Mark each step done in the task list as you finish it.
 4. **Write the reply in the shape below.**
 
 ## Reply shape
@@ -37,29 +37,39 @@ Write replies a person can check. State as a fact only what you opened or ran in
 
 Name a pull request, an issue, a branch, a workflow run, or a file by its full URL on the host that holds it, never by a number or a bare name. The person often reads the reply on a phone: a URL opens the page with one tap, and a number opens nothing.
 
-When the person writes a number and a repository, build the URL before you write anything else: the repository's URL, then the host's path for the thing, such as `/pull/<number>` for a pull request or `/issues/<number>` for an issue. Use that URL where the person wrote the number, from the **Request** line on. After the first mention you may say "this pull request", with no number.
+When the person writes a number and a repository, build the URL before you write anything else: the repository's URL, then the host's path for the thing, such as `/pull/<number>` for a pull request or `/issues/<number>` for an issue. Use that URL where the person wrote the number, from the first line on. After the first mention you may say "this pull request", with no number.
 
 For example, the person writes "who must approve pull request #7 of https://host.example/acme/shop":
 
-- **Request** line: "**Request:** Who must approve https://host.example/acme/shop/pull/7, and which page to open next."
-- **Status** line: "**Status:** Not checked yet who must approve this pull request. It waits for a code owner. Next: https://host.example/acme/shop/pull/7"
+- First line: "**Answer:** Not checked yet who must approve https://host.example/acme/shop/pull/7. It waits for a code owner."
+- Last line: "**Now:** Ask a code owner to review it: https://host.example/acme/shop/pull/7"
+
+The person reads the top of a reply and its last line first, so the answer and the one thing to do are there:
 
 ```markdown
-**Request:** <the goal, the problem it solves, and the smallest change you expect to meet it, in your own words. When you cannot name the smallest change yet, say what you must learn first. For a question, only the question. Where the request holds a number, write the URL you built from it.>
+**Answer:** | **Result:** | **No change:** <one of the three, in one or two sentences. `**Answer:**` answers a question. `**Result:**` says what the work produced, or what is known so far; a reply that only asks a round of questions or stops at a gate starts with it too. `**No change:**` is for a message that no person typed, such as a finished check or a notice from the host, when it changes nothing for the person: say what happened and what the work still waits for, and send that one line as the whole reply.>
+
+**Not yet:** <only when there is something the person must not do yet, such as merging a pull request that is not whole. What, and why, in one line. At most one such line.>
+
+**Request:** <only in the first reply of a task. The goal, the problem it solves, and the smallest change you expect to meet it, in your own words. When you cannot name the smallest change yet, say what you must learn first. Where the request holds a number, write the URL you built from it.>
+
+**Done:** | **Doing:** | **Waiting for you:** <only for work that spans turns. Three short lists; leave out a list with nothing in it.>
 
 **Steps:** <only when the session has no task-list tool, and never for the `question` playbook. One line for each numbered step of the playbook: `1. <the step, copied word for word>: done | open | skip: <reason>`. When the turn ran more than one playbook, one list for each, under its file name on a line of its own, such as `playbooks/build.md`.>
 
 **Checks:** <when a step ran checks, and always when the turn changed a file outside `intent/`, whichever playbook ran. Otherwise never for the `question` playbook. Each command, then the lines of its output that show the result, copied from the output. For a check that could not run, the check and why.>
 
-<What the current step produces: the round of questions, or the whole draft. For a question or a request no row fits, the answer.>
+<What the current step produces: the round of questions, or the whole draft, and the reasons and the evidence behind the first line.>
 
-**Status:** <what is done, what comes next, and which gate it waits on and for whom, all on this one line. When there is a page where the person acts next, the line ends with `Next: <its full URL>`, and nothing follows that URL.>
+**Now:** <which gate the work waits on and for whom, then the one thing the person does now, in words that say the action, then the full URL of the page where it is done, and nothing after that URL. An action done in the chat, such as answering the questions above or sending a message, has no URL: write the action, and the message to send when there is one. When the person has nothing to do, say so and write no URL.>
 ```
 
-The **Status** line is the last line of the reply.
+The **Now** line is the last line of the reply. It holds at most one URL. That URL is never a list page, such as a repository's pull requests or issues, and never a page the **Not yet** line names: a link at the end of a reply is where the person taps.
+
+State whether a pull request or an issue is open, a draft, merged, or closed only when you read it from the host in this turn. Otherwise say that its state was not checked.
 
 A step that is not finished is `open`, including one at its Gate.
 
 A reply that ends before a **Gate** step says which step stopped it and why.
 
-When the evidence shows that the change cannot be made in this project, say so under **Request**.
+When the evidence shows that the change cannot be made in this project, say so on the first line.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/build.md

@@ -28,7 +28,7 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 9. Run every check the project's agent instructions name and keep the output. Every check must pass: fix the code, and never skip, delete, or weaken a test. Then run the `verifier` subagent and fix what it reports. Start it on the model that `.agents/sdlc-models.md` names after `verify:`, at the effort on that line when the session can set one; when you cannot start a subagent, do what `../../../agents/verifier.md`, relative to this playbook, says yourself. For UI work, when the session has a browser tool, also close the loop with a visual check: start the app, give the browser tool the page and the mock the spec or the request names, screenshot, compare, and adjust, and repeat until it matches; two or three rounds is normal. When a check cannot run in this session, say which one and why, and never report it as passed.
 10. Go on in the same turn, without asking: follow `playbooks/open-pr.md`, and then `playbooks/review.md`. Pushing the branch and opening the pull request are part of this task.
 
-**Next:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 9 passes.
+**Hands off to:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 9 passes.
 
 ## Template
 

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/deploy.md

@@ -6,4 +6,4 @@
 4. Promote the commit to an environment before production only when the request asks for that environment. Do it the way `README.md` says, one environment at a time. When a deployment fails, stop: report the failing step and its log, and promote no further. When the request names production, by any name such as `prod`, go to step 5. When it names an environment the project does not have, say so and list the ones it has.
 5. **Gate: the release manager authorizes production.** Never start a production deployment, run a command that names the production environment, or push a release tag. Report the commit's SHA, the environments it has passed, the checks' results, and the exact action the release manager takes to promote it. Then wait.
 
-**Next:** `playbooks/maintain.md`; a job or a person; when monitoring or a ticket reports a finding in production.
+**Hands off to:** `playbooks/maintain.md`; a job or a person; when monitoring or a ticket reports a finding in production.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/design.md

@@ -17,7 +17,7 @@ This playbook turns a merged intent into the requirements and design spec.
 4. Commit `spec.md` on a new branch. In the same commit, set the intent's status line to `Status: accepted.`, because its pull request is merged. Push the branch, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When you cannot open a pull request from this session, say so and give the pushed branch's name.
 5. **Gate: the product owner reviews the spec.** The product owner corrects the `Decision:` line under each area of concern, with its policy owner, then merges the pull request to accept the spec and those decisions as written, or closes it to reject it. Change a `Decision:` line when they tell you its text. For a change the spec classes as higher risk, the product owner consults a tech lead before accepting. You do none of these. The spec stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the plan's commit sets it. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/build.md`; an engineer with an agent; when the product owner has merged the spec's pull request and the engineer sends `/sdlc:sdlc-mode build` with the spec's path.
+**Hands off to:** `playbooks/build.md`; an engineer with an agent; when the product owner has merged the spec's pull request and the engineer sends `/sdlc:sdlc-mode build` with the spec's path.
 
 ## Template
 

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/fix.md

@@ -21,4 +21,4 @@ This playbook takes a defect in behaviour that already exists to a pull request.
 10. Run every check the project's agent instructions name. Keep the output. When one fails, fix the code, and never skip, delete, or weaken a test. When a check cannot run in this session, say which one and why, and never report it as passed.
 11. Go on in the same turn, without asking. Follow `playbooks/open-pr.md`, and then `playbooks/review.md`.
 
-**Next:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 10 passes.
+**Hands off to:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 10 passes.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/maintain.md

@@ -15,4 +15,4 @@ This playbook starts from a finding such as an alert, a monitoring ticket, a fai
 5. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When you cannot open a pull request from this session, say so and give the pushed branch's name.
 6. **Gate: the service owner triages the finding.** The service owner merges the pull request to fix the finding now, comments on it with when the finding is scheduled and leaves it open, or closes it to dismiss it. An open pull request with no such comment is undecided: say so, and never report it as scheduled. A dismissal tunes the bands: the service owner adjusts `bands.yaml` so the same noise raises fewer findings. The service owner asks the product owner to decide a product-facing finding. You do none of these. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/design.md`; an agent; when the service owner has merged the intent's pull request and a person or a job sends `/sdlc:sdlc-mode` with the intent's path.
+**Hands off to:** `playbooks/design.md`; an agent; when the service owner has merged the intent's pull request and a person or a job sends `/sdlc:sdlc-mode` with the intent's path.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/open-pr.md

@@ -14,4 +14,4 @@ Branch from the latest `origin/main`, and open the pull request ready for review
 
 5. Go on in the same turn, without asking: follow `playbooks/review.md`.
 
-**Next:** `playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.
+**Hands off to:** `playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/plan.md

@@ -12,7 +12,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests.
 7. **Gate: the product owner accepts or rejects the intent.** The product owner merges the pull request to accept the intent, or closes it to reject it. You do neither. When the originator is not the person who merges, the originator is the pull request's author or approves it; say so when neither holds. The file stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the spec's pull request sets it. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/design.md`; an agent; when the product owner has merged the intent's pull request and a person or a job asks for the spec.
+**Hands off to:** `playbooks/design.md`; an agent; when the product owner has merged the intent's pull request and a person or a job asks for the spec.
 
 ## Template
 

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/question.md

@@ -5,4 +5,4 @@
 3. Write no file, make no commit, push nothing, and post nothing to GitHub or another service.
 4. When the answer shows work worth doing, offer it in one line, such as "Send `/sdlc:sdlc-mode write an intent for this` to start the change", and stop.
 
-**Next:** none; the person; when they send a new message.
+**Hands off to:** none; the person; when they send a new message.

package/templates/base/plugins/sdlc/claude-code/skills/sdlc-mode/playbooks/review.md

@@ -1,6 +1,6 @@
 # Review phase: review the pull request and drive it to green
 
-1. Find what to review: the pull request this session just opened, or the pull request or branch the request names. When there is no pull request, or this session cannot reach its host, review the branch's diff against the default branch and put the findings in your reply in place of a comment. When a pull request exists and this session cannot post on it, the findings are not in the pull request's history: the **Status** line says that the findings are not on the pull request and that a person posts them there, step 3 stays `open`, and you do not report the review as done.
+1. Find what to review: the pull request this session just opened, or the pull request or branch the request names. When there is no pull request, or this session cannot reach its host, review the branch's diff against the default branch and put the findings in your reply in place of a comment. When a pull request exists and this session cannot post on it, the findings are not in the pull request's history: the first line says that the findings are not on the pull request, the **Now** line says that a person posts them there, step 3 stays `open`, and you do not report the review as done.
 2. Review with a fresh context. Start a subagent that has not seen the work. Give it only the diff, `REVIEW.md`, the change's `intent/<change>/spec.md` and `plan.md`, and the four policy files in force, found as `playbooks/design.md` step 2 says. When you cannot start a subagent, read the diff again from the first line as if someone else wrote it. The review runs each pass in `REVIEW.md` and reports each finding with its pass, **Important** or **Nit**, `path:line`, and the evidence. A change that is not a fix, an intent, or a spec, and has no `spec.md` or no `plan.md`, is itself a finding.
 3. Post the findings as one comment on the pull request, most severe first. Write "No findings" when there are none. A finding does not decide the merge. When a finding flags a mistake that an earlier review of this project flagged too, its correction goes into the project's agent instructions as part of this review: in the push of step 4, or, on a pull request or a branch this session did not create, as the exact line in this comment.
 4. On a pull request or a branch that this session did not create, change nothing and push nothing. Skip the rest of this step, and in step 5 only read and answer. Otherwise, fix every Important finding. Run the checks the project's agent instructions name, and push. Answer each finding you do not fix with the reason.
@@ -13,4 +13,4 @@
 
 6. **Gate: a code owner approves the pull request, and a person merges it.** You never approve it and never merge it. Report the pull request's URL, or the branch's name when there is none, and say it waits only on the code owner. When a new comment or a failing check arrives, go back to step 5. Subscribe to the pull request's events where your tool can. Otherwise say that a person sends `/sdlc:sdlc-mode review` with the pull request when something changes.
 
-**Next:** `playbooks/deploy.md`; the project's deploy workflow, or an agent when a person asks; when the pull request is merged.
+**Hands off to:** `playbooks/deploy.md`; the project's deploy workflow, or an agent when a person asks; when the pull request is merged.

package/templates/base/plugins/sdlc/claude-code/skills/setup-sdlc/SKILL.md

@@ -50,4 +50,4 @@ Do these steps in order. Run again with the same answers, the skill writes the s
 
 7. **Do the `not done` steps an agent can do:** a step whose whole work is editing a file of the repository with values the repository or the request already gives. Do not redo a `done` step. Do not edit a file the project's rules or agent settings reserve for a person, such as rules, hooks, lint, format, and commit configuration, and the agent settings themselves; list it with the exact new text and the file it goes in. Commit nothing. After each step, run its **Check** again and report the result.
 8. **List the steps a person does outside the repository,** each with who does it, from `SETUP.md`, and the full URL of the page where it is done when `SETUP.md` or the repository names one.
-9. **Write the reply** by the reply rules in `../sdlc-mode/SKILL.md`. After them, in this order: the budget line and the four role lines as written; each step of `SETUP.md` with its state; what you did; what a person does.
+9. **Write the reply** by the reply rules in `../sdlc-mode/SKILL.md`. Between the first line and the **Now** line, in this order: the budget line and the four role lines as written; each step of `SETUP.md` with its state; what you did; what a person does. The **Now** line names the first step a person does, with its URL when step 8 found one.

package/templates/base/plugins/sdlc/cursor/hooks/check-reply-shape.sh

@@ -63,10 +63,9 @@ case $mode in
     ;;
 esac
 first=$(printf '%s\n' "$reply" | awk 'NF{print; exit}')
-case $first in '**Request:**'*) ;; *) exit 0 ;; esac
+case $first in '**Answer:**'* | '**Result:**'* | '**No change:**'*) ;; *) exit 0 ;; esac
 
 last=$(printf '%s\n' "$reply" | awk 'NF{l=$0} END{print l}')
-request=$(printf '%s\n' "$reply" | grep -m1 '^\*\*Request:\*\*')
 outside_fences=$(printf '%s\n' "$reply" | awk '/^[[:space:]]*(```|~~~)/{f=!f; next} !f')
 outside_urls=$(printf '%s\n' "$outside_fences" | sed -E 's#https?://[^][:space:])>]*# #g')
 outside_code=$(printf '%s\n' "$outside_urls" | tr 'A-Z' 'a-z' \
@@ -78,15 +77,35 @@ number=$(printf '%s\n' "$outside_code" \
   | grep -Ev '[[:space:]]of[[:space:]]' | head -1 | sed -E 's/^[^#[:alnum:]]//; s/[^[:alnum:]]$//')
 problems=
 [ -n "$number" ] && problems="Replace \"$number\" with the full URL of that pull request or issue, or with \"this pull request\". "
+only_line=$(printf '%s\n' "$reply" | awk 'NF{n++} END{print n+0}')
+not_yet=$(printf '%s\n' "$outside_fences" | grep -E '^[[:space:]]*([-*+][[:space:]]+)?\*\*Not yet:\*\*')
+page_urls() {
+  grep -Eo 'https?://[^][:space:]()<>]+' \
+    | sed -E 's#[`*_"'"'"'!?.,;:]+$##; s#[?\#].*$##; s#/+$##' \
+    | tr 'A-Z' 'a-z' | sort -u
+}
 case $last in
-  '**Status:**'*)
-    if printf '%s' "$request" | grep -Eq 'https?://' \
-      && ! printf '%s' "$last" | grep -Eiq 'Next:\**[[:space:]]*[<(]?https?://[^[:space:]]+[[:space:]]*$|no next page'; then
-      problems="${problems}End the **Status:** line with \`Next: <full URL of the page where the person acts next>\`, or say \"no next page\" when none waits. "
+  '**Now:**'*)
+    now_urls=$(printf '%s\n' "$last" | page_urls)
+    now_url=$(printf '%s\n' "$now_urls" | head -1)
+    if [ "$(printf '%s\n' "$now_urls" | grep -c .)" -gt 1 ]; then
+      problems="${problems}The **Now:** line holds more than one URL. Name one thing for the person to do, with one URL. "
+    fi
+    if printf '%s' "$now_url" | grep -Eq '^https?://[^/]+/[^/]+/[^/]+/(.*/)?(pulls|issues)$'; then
+      problems="${problems}The **Now:** line links a list page. Link the one page where the person acts, or write no URL when the person has nothing to do. "
+    fi
+    if [ -n "$now_url" ] && printf '%s\n' "$not_yet" | page_urls | grep -Fxq "$now_url"; then
+      problems="${problems}The **Now:** line links the page the **Not yet:** line names. Write no URL there until the person may act on that page. "
     fi
     ;;
-  *) problems="${problems}End the reply with a line that starts with **Status:**; nothing may follow it. " ;;
+  '**No change:**'*)
+    [ "$only_line" -eq 1 ] || problems="${problems}End the reply with a line that starts with **Now:**; nothing may follow it. "
+    ;;
+  *) problems="${problems}End the reply with a line that starts with **Now:**; nothing may follow it. " ;;
 esac
+if [ "$(printf '%s\n' "$not_yet" | grep -c .)" -gt 1 ]; then
+  problems="${problems}The reply holds more than one **Not yet:** line. Keep one. "
+fi
 
 if [ "$changed" = true ] && ! printf '%s\n' "$outside_fences" | grep -q '^\*\*Checks:\*\*'; then
   problems="${problems}A file outside intent/ changed in this turn and the reply has no **Checks:** section. Run the checks the project names and add **Checks:** with each command and the lines of its output that show the result, or with each check that could not run and why. "

package/templates/base/plugins/sdlc/cursor/skills/sdlc-help/SKILL.md

@@ -6,11 +6,11 @@ disable-model-invocation: true
 
 # SDLC help
 
-1. When the message asks for work rather than how, open no project file. The whole reply is two lines: this command starts no work; and the message to send instead, which is `/sdlc:sdlc-mode` followed by their own words.
+1. When the message asks for work rather than how, open no project file. The whole reply is two lines: this command starts no work; and, on the **Now** line, the message to send instead, which is `/sdlc:sdlc-mode` followed by their own words.
 2. When the topic is unclear, ask one question with these choices: how the workflow runs and starting work, keeping `/sdlc:sdlc-mode` on for a session, fixing a defect in behaviour that already exists, who decides at each gate, a mistake the agent repeats, or company policy.
 3. Read the files the topic points to before you answer. When a file disagrees with the map below, the file is right.
-4. When the person asks about a playbook, a command, or a file that this project does not have, the whole reply is three lines: it does not exist; what exists instead, as one file path; and one message they can send next. Stop there. Do not explain the topic from other files.
-5. Otherwise answer, then give one message the person can send as is, with real words from their question and no blanks to fill in, then list the files the answer came from.
+4. When the person asks about a playbook, a command, or a file that this project does not have, the whole reply is three lines: it does not exist; what exists instead, as one file path; and, on the **Now** line, one message they can send next. Stop there. Do not explain the topic from other files.
+5. Otherwise answer, then list the files the answer came from, then give, on the **Now** line, one message the person can send as is: the word `Send` and then the whole message in a code span, with real words from their question, no blanks to fill in, and nothing the person must add.
 6. Write the reply by the reply rules in `../sdlc-mode/SKILL.md`.
 
 ## Map

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/SKILL.md

@@ -25,10 +25,10 @@ Do these steps in order.
 
    When a request both asks a question and reports a problem, use `question` and offer `plan` in one line. A problem reported with `/sdlc:sdlc-mode` is the person's ask for `plan`.
 
-   Do not start work a person did not ask for. When a message reports a problem without asking for work, answer in a few lines and give, on the **Status** line, the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
+   Do not start work a person did not ask for. When a message reports a problem without asking for work, answer in a few lines and give, on the **Now** line, the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 
-2. **Open the task list** when the session offers a task-list tool. Its first items are the matched playbook's numbered steps, copied word for word, before any other task. A step you do not do stays in the list with `skip: <reason>`. Use `skip` only for a step you decide never to do. A step marked **Gate** is never skipped. When the session offers no such tool, the steps go in the reply instead, under **Steps**, and are never left out, except for `question`. When a playbook's **Next** line chains another playbook, add that playbook's steps when you start it.
-3. **Do the playbook's steps yourself,** stopping only at a step marked **Gate**, or before an action that cannot be undone. At a step marked **Gate**, wait for the person it names. When a playbook's **Next** line says an agent runs the next file "in the same turn", read that file and continue without asking; otherwise stop at the Gate. Mark each step done in the task list as you finish it.
+2. **Open the task list** when the session offers a task-list tool. Its first items are the matched playbook's numbered steps, copied word for word, before any other task. A step you do not do stays in the list with `skip: <reason>`. Use `skip` only for a step you decide never to do. A step marked **Gate** is never skipped. When the session offers no such tool, the steps go in the reply instead, under **Steps**, and are never left out, except for `question`. When a playbook's **Hands off to** line chains another playbook, add that playbook's steps when you start it.
+3. **Do the playbook's steps yourself,** stopping only at a step marked **Gate**, or before an action that cannot be undone. At a step marked **Gate**, wait for the person it names. When a playbook's **Hands off to** line says an agent runs the next file "in the same turn", read that file and continue without asking; otherwise stop at the Gate. Mark each step done in the task list as you finish it.
 4. **Write the reply in the shape below.**
 
 ## Reply shape
@@ -37,29 +37,39 @@ Write replies a person can check. State as a fact only what you opened or ran in
 
 Name a pull request, an issue, a branch, a workflow run, or a file by its full URL on the host that holds it, never by a number or a bare name. The person often reads the reply on a phone: a URL opens the page with one tap, and a number opens nothing.
 
-When the person writes a number and a repository, build the URL before you write anything else: the repository's URL, then the host's path for the thing, such as `/pull/<number>` for a pull request or `/issues/<number>` for an issue. Use that URL where the person wrote the number, from the **Request** line on. After the first mention you may say "this pull request", with no number.
+When the person writes a number and a repository, build the URL before you write anything else: the repository's URL, then the host's path for the thing, such as `/pull/<number>` for a pull request or `/issues/<number>` for an issue. Use that URL where the person wrote the number, from the first line on. After the first mention you may say "this pull request", with no number.
 
 For example, the person writes "who must approve pull request #7 of https://host.example/acme/shop":
 
-- **Request** line: "**Request:** Who must approve https://host.example/acme/shop/pull/7, and which page to open next."
-- **Status** line: "**Status:** Not checked yet who must approve this pull request. It waits for a code owner. Next: https://host.example/acme/shop/pull/7"
+- First line: "**Answer:** Not checked yet who must approve https://host.example/acme/shop/pull/7. It waits for a code owner."
+- Last line: "**Now:** Ask a code owner to review it: https://host.example/acme/shop/pull/7"
+
+The person reads the top of a reply and its last line first, so the answer and the one thing to do are there:
 
 ```markdown
-**Request:** <the goal, the problem it solves, and the smallest change you expect to meet it, in your own words. When you cannot name the smallest change yet, say what you must learn first. For a question, only the question. Where the request holds a number, write the URL you built from it.>
+**Answer:** | **Result:** | **No change:** <one of the three, in one or two sentences. `**Answer:**` answers a question. `**Result:**` says what the work produced, or what is known so far; a reply that only asks a round of questions or stops at a gate starts with it too. `**No change:**` is for a message that no person typed, such as a finished check or a notice from the host, when it changes nothing for the person: say what happened and what the work still waits for, and send that one line as the whole reply.>
+
+**Not yet:** <only when there is something the person must not do yet, such as merging a pull request that is not whole. What, and why, in one line. At most one such line.>
+
+**Request:** <only in the first reply of a task. The goal, the problem it solves, and the smallest change you expect to meet it, in your own words. When you cannot name the smallest change yet, say what you must learn first. Where the request holds a number, write the URL you built from it.>
+
+**Done:** | **Doing:** | **Waiting for you:** <only for work that spans turns. Three short lists; leave out a list with nothing in it.>
 
 **Steps:** <only when the session has no task-list tool, and never for the `question` playbook. One line for each numbered step of the playbook: `1. <the step, copied word for word>: done | open | skip: <reason>`. When the turn ran more than one playbook, one list for each, under its file name on a line of its own, such as `playbooks/build.md`.>
 
 **Checks:** <when a step ran checks, and always when the turn changed a file outside `intent/`, whichever playbook ran. Otherwise never for the `question` playbook. Each command, then the lines of its output that show the result, copied from the output. For a check that could not run, the check and why.>
 
-<What the current step produces: the round of questions, or the whole draft. For a question or a request no row fits, the answer.>
+<What the current step produces: the round of questions, or the whole draft, and the reasons and the evidence behind the first line.>
 
-**Status:** <what is done, what comes next, and which gate it waits on and for whom, all on this one line. When there is a page where the person acts next, the line ends with `Next: <its full URL>`, and nothing follows that URL.>
+**Now:** <which gate the work waits on and for whom, then the one thing the person does now, in words that say the action, then the full URL of the page where it is done, and nothing after that URL. An action done in the chat, such as answering the questions above or sending a message, has no URL: write the action, and the message to send when there is one. When the person has nothing to do, say so and write no URL.>
 ```
 
-The **Status** line is the last line of the reply.
+The **Now** line is the last line of the reply. It holds at most one URL. That URL is never a list page, such as a repository's pull requests or issues, and never a page the **Not yet** line names: a link at the end of a reply is where the person taps.
+
+State whether a pull request or an issue is open, a draft, merged, or closed only when you read it from the host in this turn. Otherwise say that its state was not checked.
 
 A step that is not finished is `open`, including one at its Gate.
 
 A reply that ends before a **Gate** step says which step stopped it and why.
 
-When the evidence shows that the change cannot be made in this project, say so under **Request**.
+When the evidence shows that the change cannot be made in this project, say so on the first line.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/build.md

@@ -28,7 +28,7 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 9. Run every check the project's agent instructions name and keep the output. Every check must pass: fix the code, and never skip, delete, or weaken a test. Then run the `verifier` subagent and fix what it reports. Start it on the model that `.agents/sdlc-models.md` names after `verify:`, at the effort on that line when the session can set one; when you cannot start a subagent, do what `../../../agents/verifier.md`, relative to this playbook, says yourself. For UI work, when the session has a browser tool, also close the loop with a visual check: start the app, give the browser tool the page and the mock the spec or the request names, screenshot, compare, and adjust, and repeat until it matches; two or three rounds is normal. When a check cannot run in this session, say which one and why, and never report it as passed.
 10. Go on in the same turn, without asking: follow `playbooks/open-pr.md`, and then `playbooks/review.md`. Pushing the branch and opening the pull request are part of this task.
 
-**Next:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 9 passes.
+**Hands off to:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 9 passes.
 
 ## Template
 

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/deploy.md

@@ -6,4 +6,4 @@
 4. Promote the commit to an environment before production only when the request asks for that environment. Do it the way `README.md` says, one environment at a time. When a deployment fails, stop: report the failing step and its log, and promote no further. When the request names production, by any name such as `prod`, go to step 5. When it names an environment the project does not have, say so and list the ones it has.
 5. **Gate: the release manager authorizes production.** Never start a production deployment, run a command that names the production environment, or push a release tag. Report the commit's SHA, the environments it has passed, the checks' results, and the exact action the release manager takes to promote it. Then wait.
 
-**Next:** `playbooks/maintain.md`; a job or a person; when monitoring or a ticket reports a finding in production.
+**Hands off to:** `playbooks/maintain.md`; a job or a person; when monitoring or a ticket reports a finding in production.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/design.md

@@ -17,7 +17,7 @@ This playbook turns a merged intent into the requirements and design spec.
 4. Commit `spec.md` on a new branch. In the same commit, set the intent's status line to `Status: accepted.`, because its pull request is merged. Push the branch, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When you cannot open a pull request from this session, say so and give the pushed branch's name.
 5. **Gate: the product owner reviews the spec.** The product owner corrects the `Decision:` line under each area of concern, with its policy owner, then merges the pull request to accept the spec and those decisions as written, or closes it to reject it. Change a `Decision:` line when they tell you its text. For a change the spec classes as higher risk, the product owner consults a tech lead before accepting. You do none of these. The spec stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the plan's commit sets it. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/build.md`; an engineer with an agent; when the product owner has merged the spec's pull request and the engineer sends `/sdlc:sdlc-mode build` with the spec's path.
+**Hands off to:** `playbooks/build.md`; an engineer with an agent; when the product owner has merged the spec's pull request and the engineer sends `/sdlc:sdlc-mode build` with the spec's path.
 
 ## Template
 

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/fix.md

@@ -21,4 +21,4 @@ This playbook takes a defect in behaviour that already exists to a pull request.
 10. Run every check the project's agent instructions name. Keep the output. When one fails, fix the code, and never skip, delete, or weaken a test. When a check cannot run in this session, say which one and why, and never report it as passed.
 11. Go on in the same turn, without asking. Follow `playbooks/open-pr.md`, and then `playbooks/review.md`.
 
-**Next:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 10 passes.
+**Hands off to:** `playbooks/open-pr.md`; an agent; in the same turn, as soon as step 10 passes.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/maintain.md

@@ -15,4 +15,4 @@ This playbook starts from a finding such as an alert, a monitoring ticket, a fai
 5. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When you cannot open a pull request from this session, say so and give the pushed branch's name.
 6. **Gate: the service owner triages the finding.** The service owner merges the pull request to fix the finding now, comments on it with when the finding is scheduled and leaves it open, or closes it to dismiss it. An open pull request with no such comment is undecided: say so, and never report it as scheduled. A dismissal tunes the bands: the service owner adjusts `bands.yaml` so the same noise raises fewer findings. The service owner asks the product owner to decide a product-facing finding. You do none of these. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/design.md`; an agent; when the service owner has merged the intent's pull request and a person or a job sends `/sdlc:sdlc-mode` with the intent's path.
+**Hands off to:** `playbooks/design.md`; an agent; when the service owner has merged the intent's pull request and a person or a job sends `/sdlc:sdlc-mode` with the intent's path.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/open-pr.md

@@ -14,4 +14,4 @@ Branch from the latest `origin/main`, and open the pull request ready for review
 
 5. Go on in the same turn, without asking: follow `playbooks/review.md`.
 
-**Next:** `playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.
+**Hands off to:** `playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/plan.md

@@ -12,7 +12,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests.
 7. **Gate: the product owner accepts or rejects the intent.** The product owner merges the pull request to accept the intent, or closes it to reject it. You do neither. When the originator is not the person who merges, the originator is the pull request's author or approves it; say so when neither holds. The file stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the spec's pull request sets it. Report the pull request's URL, keep it green as `playbooks/review.md` says, and wait.
 
-**Next:** `playbooks/design.md`; an agent; when the product owner has merged the intent's pull request and a person or a job asks for the spec.
+**Hands off to:** `playbooks/design.md`; an agent; when the product owner has merged the intent's pull request and a person or a job asks for the spec.
 
 ## Template
 

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/question.md

@@ -5,4 +5,4 @@
 3. Write no file, make no commit, push nothing, and post nothing to GitHub or another service.
 4. When the answer shows work worth doing, offer it in one line, such as "Send `/sdlc:sdlc-mode write an intent for this` to start the change", and stop.
 
-**Next:** none; the person; when they send a new message.
+**Hands off to:** none; the person; when they send a new message.

package/templates/base/plugins/sdlc/cursor/skills/sdlc-mode/playbooks/review.md

@@ -1,6 +1,6 @@
 # Review phase: review the pull request and drive it to green
 
-1. Find what to review: the pull request this session just opened, or the pull request or branch the request names. When there is no pull request, or this session cannot reach its host, review the branch's diff against the default branch and put the findings in your reply in place of a comment. When a pull request exists and this session cannot post on it, the findings are not in the pull request's history: the **Status** line says that the findings are not on the pull request and that a person posts them there, step 3 stays `open`, and you do not report the review as done.
+1. Find what to review: the pull request this session just opened, or the pull request or branch the request names. When there is no pull request, or this session cannot reach its host, review the branch's diff against the default branch and put the findings in your reply in place of a comment. When a pull request exists and this session cannot post on it, the findings are not in the pull request's history: the first line says that the findings are not on the pull request, the **Now** line says that a person posts them there, step 3 stays `open`, and you do not report the review as done.
 2. Review with a fresh context. Start a subagent that has not seen the work. Give it only the diff, `REVIEW.md`, the change's `intent/<change>/spec.md` and `plan.md`, and the four policy files in force, found as `playbooks/design.md` step 2 says. When you cannot start a subagent, read the diff again from the first line as if someone else wrote it. The review runs each pass in `REVIEW.md` and reports each finding with its pass, **Important** or **Nit**, `path:line`, and the evidence. A change that is not a fix, an intent, or a spec, and has no `spec.md` or no `plan.md`, is itself a finding.
 3. Post the findings as one comment on the pull request, most severe first. Write "No findings" when there are none. A finding does not decide the merge. When a finding flags a mistake that an earlier review of this project flagged too, its correction goes into the project's agent instructions as part of this review: in the push of step 4, or, on a pull request or a branch this session did not create, as the exact line in this comment.
 4. On a pull request or a branch that this session did not create, change nothing and push nothing. Skip the rest of this step, and in step 5 only read and answer. Otherwise, fix every Important finding. Run the checks the project's agent instructions name, and push. Answer each finding you do not fix with the reason.
@@ -13,4 +13,4 @@
 
 6. **Gate: a code owner approves the pull request, and a person merges it.** You never approve it and never merge it. Report the pull request's URL, or the branch's name when there is none, and say it waits only on the code owner. When a new comment or a failing check arrives, go back to step 5. Subscribe to the pull request's events where your tool can. Otherwise say that a person sends `/sdlc:sdlc-mode review` with the pull request when something changes.
 
-**Next:** `playbooks/deploy.md`; the project's deploy workflow, or an agent when a person asks; when the pull request is merged.
+**Hands off to:** `playbooks/deploy.md`; the project's deploy workflow, or an agent when a person asks; when the pull request is merged.

package/templates/base/plugins/sdlc/cursor/skills/setup-sdlc/SKILL.md

@@ -50,4 +50,4 @@ Do these steps in order. Run again with the same answers, the skill writes the s
 
 7. **Do the `not done` steps an agent can do:** a step whose whole work is editing a file of the repository with values the repository or the request already gives. Do not redo a `done` step. Do not edit a file the project's rules or agent settings reserve for a person, such as rules, hooks, lint, format, and commit configuration, and the agent settings themselves; list it with the exact new text and the file it goes in. Commit nothing. After each step, run its **Check** again and report the result.
 8. **List the steps a person does outside the repository,** each with who does it, from `SETUP.md`, and the full URL of the page where it is done when `SETUP.md` or the repository names one.
-9. **Write the reply** by the reply rules in `../sdlc-mode/SKILL.md`. After them, in this order: the budget line and the four role lines as written; each step of `SETUP.md` with its state; what you did; what a person does.
+9. **Write the reply** by the reply rules in `../sdlc-mode/SKILL.md`. Between the first line and the **Now** line, in this order: the budget line and the four role lines as written; each step of `SETUP.md` with its state; what you did; what a person does. The **Now** line names the first step a person does, with its URL when step 8 found one.

package/templates/nestjs/AGENTS.md

@@ -45,12 +45,18 @@ The `verifier` subagent starts the app with `pnpm start:dev`. It exercises the c
 
 When Claude makes a mistake twice, add the correction here.
 
-<!-- deploy:railway -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod`, runs a Railway CLI command that names `prod`, or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool or a Railway command without `-e` or `--environment` passes it.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool passes it.
-<!-- deploy:end -->
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to
+  <!-- deploy:railway -->
+  `prod`, runs a Railway CLI command that names `prod`,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  `prod`
+  <!-- deploy:end -->
+  or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set to a value that matches the extended regular expression on the first line of `.agents/release-approval-form`. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool
+  <!-- deploy:railway -->
+  or a Railway command without `-e` or `--environment`
+  <!-- deploy:end -->
+  passes it.
 - **Issues**: open an issue only to hand work to another person, never to give a pull request a number to close. A pull request closes an issue that already exists with `Closes #<issue>`.
 - **What belongs in the repository**: files, commit messages, and pull requests hold the change, its reason, and the checks. Write no date, log, history, mistake count, token figure, or session note into a file.
 - **Sourced requirements**: add a requirement to an intent, spec, or plan only when a person decided it or a named source says it. This includes a requirement a review bot suggests. When no person decided it and no source says it, leave it out and answer the thread with that.

package/templates/nestjs/CONTRIBUTING.md

@@ -45,8 +45,15 @@ Agent rules live in `.agents/rules/` with their scope in `.agents/rules.json`. A
 
 ## Pull requests
 
+<!-- deploy:railway -->
 We use trunk-based development. `main` is the only long-lived branch, and every deploy promotes a commit from `main` (see the Deploy section in the README).
 
+<!-- deploy:end -->
+<!-- deploy:none -->
+We use trunk-based development. `main` is the only long-lived branch.
+
+<!-- deploy:end -->
+
 - Branch from `main` and merge back within a day or two. Do not create `develop` or release branches.
 - Merge unfinished work behind a feature flag or keep it unreachable instead of holding a long-lived branch.
 - Pull requests are squash-merged, so the pull request title becomes the commit on `main`.

package/templates/nextjs/AGENTS.md

@@ -46,12 +46,18 @@ The `verifier` subagent starts the app with `pnpm dev`. It exercises the changed
 When Claude makes a mistake twice, add the correction here.
 
 - **First end-to-end run**: run `pnpm exec playwright install chromium` once. `pnpm test:e2e` starts the development server unless one is already running.
-<!-- deploy:railway -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod`, runs a Railway CLI command that names `prod`, or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool or a Railway command without `-e` or `--environment` passes it.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool passes it.
-<!-- deploy:end -->
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to
+  <!-- deploy:railway -->
+  `prod`, runs a Railway CLI command that names `prod`,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  `prod`
+  <!-- deploy:end -->
+  or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set to a value that matches the extended regular expression on the first line of `.agents/release-approval-form`. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool
+  <!-- deploy:railway -->
+  or a Railway command without `-e` or `--environment`
+  <!-- deploy:end -->
+  passes it.
 - **Issues**: open an issue only to hand work to another person, never to give a pull request a number to close. A pull request closes an issue that already exists with `Closes #<issue>`.
 - **What belongs in the repository**: files, commit messages, and pull requests hold the change, its reason, and the checks. Write no date, log, history, mistake count, token figure, or session note into a file.
 - **Sourced requirements**: add a requirement to an intent, spec, or plan only when a person decided it or a named source says it. This includes a requirement a review bot suggests. When no person decided it and no source says it, leave it out and answer the thread with that.

package/templates/nextjs/CONTRIBUTING.md

@@ -45,8 +45,15 @@ Agent rules live in `.agents/rules/` with their scope in `.agents/rules.json`. A
 
 ## Pull requests
 
+<!-- deploy:railway -->
 We use trunk-based development. `main` is the only long-lived branch, and every deploy promotes a commit from `main` (see the Deploy section in the README).
 
+<!-- deploy:end -->
+<!-- deploy:none -->
+We use trunk-based development. `main` is the only long-lived branch.
+
+<!-- deploy:end -->
+
 - Branch from `main` and merge back within a day or two. Do not create `develop` or release branches.
 - Merge unfinished work behind a feature flag or keep it unreachable instead of holding a long-lived branch.
 - Pull requests are squash-merged, so the pull request title becomes the commit on `main`.

package/templates/nodejs/AGENTS.md

@@ -44,12 +44,18 @@ The `verifier` subagent starts the app with `pnpm start:dev`. It exercises the c
 
 When Claude makes a mistake twice, add the correction here.
 
-<!-- deploy:railway -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod`, runs a Railway CLI command that names `prod`, or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool or a Railway command without `-e` or `--environment` passes it.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool passes it.
-<!-- deploy:end -->
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to
+  <!-- deploy:railway -->
+  `prod`, runs a Railway CLI command that names `prod`,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  `prod`
+  <!-- deploy:end -->
+  or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set to a value that matches the extended regular expression on the first line of `.agents/release-approval-form`. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool
+  <!-- deploy:railway -->
+  or a Railway command without `-e` or `--environment`
+  <!-- deploy:end -->
+  passes it.
 - **Issues**: open an issue only to hand work to another person, never to give a pull request a number to close. A pull request closes an issue that already exists with `Closes #<issue>`.
 - **What belongs in the repository**: files, commit messages, and pull requests hold the change, its reason, and the checks. Write no date, log, history, mistake count, token figure, or session note into a file.
 - **Sourced requirements**: add a requirement to an intent, spec, or plan only when a person decided it or a named source says it. This includes a requirement a review bot suggests. When no person decided it and no source says it, leave it out and answer the thread with that.

package/templates/nodejs/CONTRIBUTING.md

@@ -44,8 +44,15 @@ Agent rules live in `.agents/rules/` with their scope in `.agents/rules.json`. A
 
 ## Pull requests
 
+<!-- deploy:railway -->
 We use trunk-based development. `main` is the only long-lived branch, and every deploy promotes a commit from `main` (see the Deploy section in the README).
 
+<!-- deploy:end -->
+<!-- deploy:none -->
+We use trunk-based development. `main` is the only long-lived branch.
+
+<!-- deploy:end -->
+
 - Branch from `main` and merge back within a day or two. Do not create `develop` or release branches.
 - Merge unfinished work behind a feature flag or keep it unreachable instead of holding a long-lived branch.
 - Pull requests are squash-merged, so the pull request title becomes the commit on `main`.

package/templates/payload/AGENTS.md

@@ -49,12 +49,18 @@ The `verifier` subagent starts the app with `pnpm dev`, which needs a PostgreSQL
 When Claude makes a mistake twice, add the correction here.
 
 - **Database for `pnpm dev` and end-to-end tests**: both need a PostgreSQL database in `DATABASE_URL` and `PAYLOAD_SECRET` in `.env`; the README lists every variable. Run `pnpm exec playwright install chromium` once before the first `pnpm test:e2e`.
-<!-- deploy:railway -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod`, runs a Railway CLI command that names `prod`, or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool or a Railway command without `-e` or `--environment` passes it.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool passes it.
-<!-- deploy:end -->
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to
+  <!-- deploy:railway -->
+  `prod`, runs a Railway CLI command that names `prod`,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  `prod`
+  <!-- deploy:end -->
+  or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set to a value that matches the extended regular expression on the first line of `.agents/release-approval-form`. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool
+  <!-- deploy:railway -->
+  or a Railway command without `-e` or `--environment`
+  <!-- deploy:end -->
+  passes it.
 - **Issues**: open an issue only to hand work to another person, never to give a pull request a number to close. A pull request closes an issue that already exists with `Closes #<issue>`.
 - **What belongs in the repository**: files, commit messages, and pull requests hold the change, its reason, and the checks. Write no date, log, history, mistake count, token figure, or session note into a file.
 - **Sourced requirements**: add a requirement to an intent, spec, or plan only when a person decided it or a named source says it. This includes a requirement a review bot suggests. When no person decided it and no source says it, leave it out and answer the thread with that.

package/templates/payload/CONTRIBUTING.md

@@ -46,8 +46,15 @@ Agent rules live in `.agents/rules/` with their scope in `.agents/rules.json`. A
 
 ## Pull requests
 
+<!-- deploy:railway -->
 We use trunk-based development. `main` is the only long-lived branch, and every deploy promotes a commit from `main` (see the Deploy section in the README).
 
+<!-- deploy:end -->
+<!-- deploy:none -->
+We use trunk-based development. `main` is the only long-lived branch.
+
+<!-- deploy:end -->
+
 - Branch from `main` and merge back within a day or two. Do not create `develop` or release branches.
 - Merge unfinished work behind a feature flag or keep it unreachable instead of holding a long-lived branch.
 - Pull requests are squash-merged, so the pull request title becomes the commit on `main`.

package/templates/turborepo/AGENTS.md

@@ -52,12 +52,18 @@ When Claude makes a mistake twice, add the correction here.
 
 - **Next.js docs live per app**: this Next.js version differs from your training data. Read the guide in `apps/app/node_modules/next/dist/docs/` or `apps/backoffice/node_modules/next/dist/docs/` before writing Next.js code; the workspace root has no `next` package.
 - **Database for `pnpm dev` and end-to-end tests**: the backoffice needs a PostgreSQL database in `DATABASE_URL` and `PAYLOAD_SECRET` in `.env`; the README lists every variable. Run `pnpm --filter ./apps/app exec playwright install chromium` once before the first `pnpm test:e2e`.
-<!-- deploy:railway -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod`, runs a Railway CLI command that names `prod`, or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool or a Railway command without `-e` or `--environment` passes it.
-<!-- deploy:end -->
-<!-- deploy:none -->
-- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set. Any value lifts the gate except an empty value, `0`, `false`, and `no`, in any letter case. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool passes it.
-<!-- deploy:end -->
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to
+  <!-- deploy:railway -->
+  `prod`, runs a Railway CLI command that names `prod`,
+  <!-- deploy:end -->
+  <!-- deploy:none -->
+  `prod`
+  <!-- deploy:end -->
+  or pushes a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set to a value that matches the extended regular expression on the first line of `.agents/release-approval-form`. Report what is ready to promote instead. When a gated command appears only inside a message, write the text to a file with your file-editing tool, not a shell heredoc, and pass it with `git commit -F <file>` or `gh pr create --body-file <file>`. The gate reads only shell commands, so an MCP tool
+  <!-- deploy:railway -->
+  or a Railway command without `-e` or `--environment`
+  <!-- deploy:end -->
+  passes it.
 - **Issues**: open an issue only to hand work to another person, never to give a pull request a number to close. A pull request closes an issue that already exists with `Closes #<issue>`.
 - **What belongs in the repository**: files, commit messages, and pull requests hold the change, its reason, and the checks. Write no date, log, history, mistake count, token figure, or session note into a file.
 - **Sourced requirements**: add a requirement to an intent, spec, or plan only when a person decided it or a named source says it. This includes a requirement a review bot suggests. When no person decided it and no source says it, leave it out and answer the thread with that.

package/templates/turborepo/CONTRIBUTING.md

@@ -47,8 +47,15 @@ Agent rules live in `.agents/rules/` with their scope in `.agents/rules.json`. A
 
 ## Pull requests
 
+<!-- deploy:railway -->
 We use trunk-based development. `main` is the only long-lived branch, and every deploy promotes a commit from `main` (see the Deploy section in the README).
 
+<!-- deploy:end -->
+<!-- deploy:none -->
+We use trunk-based development. `main` is the only long-lived branch.
+
+<!-- deploy:end -->
+
 - Branch from `main` and merge back within a day or two. Do not create `develop` or release branches.
 - Merge unfinished work behind a feature flag or keep it unreachable instead of holding a long-lived branch.
 - Pull requests are squash-merged, so the pull request title becomes the commit on `main`.