@next-friday/create-app 9.3.1 → 9.4.1

package/package.json

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

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

@@ -14,7 +14,7 @@ Do these steps in order.
    | :---------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- |
    | A question, or a request to explain something without changing anything                                                 | Follow [`playbooks/question.md`](playbooks/question.md).                                                                       |
    | A spec for an intent, or a path to an `intent.md`                                                                       | Follow [`playbooks/design.md`](playbooks/design.md).                                                                           |
-   | A build for a spec, a path to a `spec.md`, or a plan the engineer accepted                                              | Follow [`playbooks/build.md`](playbooks/build.md).                                                                             |
+   | A build for a spec, a path to a `spec.md`, or a plan the engineer merged                                                | Follow [`playbooks/build.md`](playbooks/build.md).                                                                             |
    | A review or check of a pull request or a branch, a failing check on a pull request, or a pull request to drive to green | Follow [`playbooks/review.md`](playbooks/review.md).                                                                           |
    | A deploy, a promotion to an environment, or a release to production                                                     | Follow [`playbooks/deploy.md`](playbooks/deploy.md).                                                                           |
    | A finding sent by a job, a monitor, or a trigger, or one the message says no person can answer questions about          | Follow [`playbooks/maintain.md`](playbooks/maintain.md).                                                                       |

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

@@ -5,11 +5,11 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 1. Find the change: the `intent/<change>/` folder whose `spec.md` or `plan.md` the request names. Its `spec.md` must be on the default branch beside its `intent.md`. In each case below, say only that, in two or three lines, and stop: write no file.
    - The request names no change, or the folder has no `spec.md` on any branch: list each `intent/*/` on the default branch that has a `spec.md` and no `plan.md`, or say that there is none.
    - The spec exists only on another branch: say that the spec is not merged yet, and name that branch.
-   - `intent/<change>/plan.md` is already on the default branch: say that the plan is merged, name the file, and say that the change is built only when each requirement of `spec.md` is checked against the tree.
+   - `intent/<change>/plan.md` is on the default branch and `spec.md` says `Status: done.`: say that the change is built, and name both files.
 
    When the request is a bug fix with no spec, none of these cases applies: follow `playbooks/fix.md` instead.
 
-2. When `intent/<change>/plan.md` exists on a branch that is not merged, check out that branch. When the request says the plan is accepted, go to step 6. Otherwise show that plan and go to step 5.
+2. When `intent/<change>/plan.md` is on the default branch, the engineer accepted it by merging its pull request: go to step 7. When it exists only on a branch that is not merged, check out that branch, show that plan, and go to step 5.
 3. Read `intent.md`, `spec.md`, the four policies, found as `playbooks/design.md` step 2 says, and the code the change touches. Start from the accepted spec, in the agent tool's plan mode when it has one, and give the plan the change's `intent.md` and `spec.md`. Then interview the engineer until they have said four things: the files the change touches, the order of the work, the tests that prove it, and each option they rule out.
    - **When all four are already said, in the request or in the files, go to step 4 in the same turn.**
    - **When one is missing, ask and stop.** Write no plan in that turn. Ask in rounds, as step 3 of `playbooks/plan.md` does: numbered questions, each with a recommended answer or "No recommendation". Wait for the answers, and build the next round on them.
@@ -21,13 +21,14 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 
    Show the whole plan and name the file only as `intent/<change>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
 
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could build from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes. When the spec classes the change as higher risk, say that a tech lead or an architect accepts the plan with the engineer.
-6. Create the branch as `playbooks/open-pr.md` says, unless step 2 checked one out. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5 or whom the request names, and commit `intent/<change>/plan.md` before any other change. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged.
-7. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow `playbooks/fix.md` steps 7 and 8: commit the failing test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
-8. 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.
-9. 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.
+5. Commit `intent/<change>/plan.md` on a new branch, unless step 2 checked one out, with the `Accepted by:` line as the template has it. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged; when an area of concern of that spec has no `Decision:` line, add it there with the decision you propose, as `playbooks/design.md` step 3 says. Push the branch and open a pull request that changes no file outside `intent/`, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When the branch already has a pull request, update that one. In plan mode, the engineer's approval lets you write the file and do this step; it is not the acceptance.
+6. **Gate: the engineer accepts the plan.** The engineer merges that pull request to accept the plan, or closes it to reject it. You never merge it, and you change no file outside `intent/` before it is merged. Revise the plan as the engineer asks; each revision is a commit on that branch. When the spec classes the change as higher risk, say that a tech lead or an architect approves that pull request before it is merged. Report the pull request's URL, or the pushed branch's name when you could not open one, keep it green as `playbooks/review.md` says, and wait.
+7. When the plan's pull request is merged, create a new branch as `playbooks/open-pr.md` says. In its first commit, set the plan's `Accepted by:` line, under its title, to the account that merged that pull request, read from the host. When that pull request has an approving review from a second person, add `Also accepted by: @<handle>.` on the next line. When you cannot read the host, confirm with `git fetch` that the plan is on the default branch, and write the handle the engineer gives; ask for it when they gave none. Never write a handle the host or the engineer did not give.
+8. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow `playbooks/fix.md` steps 8 and 9: commit the failing test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
+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 8 passes.
+**Next:** `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/design.md

@@ -8,14 +8,14 @@ This playbook turns a merged intent into the requirements and design spec.
    - `spec.md` already exists: say so and name the file.
 2. Read the four policies, every time, before you write: for each of `brand`, `security`, `compliance`, and `ux`, read the project's `.agents/skills/<area>-policy/SKILL.md` when it exists, and the plugin's default at `../../<area>-policy/SKILL.md`, relative to this playbook, otherwise. Then read the code and the docs the change touches.
 3. Write `intent/<change>/spec.md` from the template below. Use exactly the template's headings.
-   - **Request:** under the status line, quote the words of the request that started this spec.
+   - **Request:** under the status line, quote the words of the request that started this spec. End the line with `Skills at <hash>.`, the short hash of the last commit that changed the plugin's files in this repository: `git log -1 --format=%h -- plugins/sdlc`. When the plugin is not in this repository, write `Skills at unknown.`
    - **Requirements:** numbered. Each one states a result a test or a reader can check.
    - **Design:** how the change fits the existing code: the files that change, and what each one does afterwards.
    - **Policies:** one line for each of the four policies. State which rules of that policy the change must meet, each as a requirement number, or write "Does not apply" and why.
-   - **Areas of concern:** a policy rule the change cannot meet, two policies that contradict, or a decision the files do not settle. Give each one a number and the policy it comes from. Write "None" only when there are none.
+   - **Areas of concern:** a policy rule the change cannot meet, two policies that contradict, or a decision the files do not settle. Give each one a number and the policy it comes from. Under each, on a line of its own, write `Decision: <the decision you propose>.` Write "None" only when there are none.
    - **Open questions:** each open question from `intent.md`, answered with its evidence or carried forward. Write "None" only when the intent has none.
 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 resolves each area of concern with its policy owner, then merges the pull request to accept the spec, or closes it to reject it. 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.
+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.
 

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

@@ -2,7 +2,7 @@
 
 This playbook takes a defect in behaviour that already exists to a pull request. It has no intent and no spec: its plan is the only file it adds under `intent/`.
 
-1. Decide that the request qualifies. It qualifies only when the request is a defect in behaviour that already exists, and the fix adds no new behaviour and no new dependency and changes no schema and no public interface. When a condition fails, say which one in two lines and follow `playbooks/plan.md` instead.
+1. Decide that the request qualifies. It qualifies only when the request is a defect in behaviour that already exists, and the fix adds no new behaviour and no new dependency and changes no schema and no public interface. When a condition fails, say which one in two lines and follow `playbooks/plan.md` instead. When `intent/<short-description>/plan.md` for this defect is already on the default branch, the engineer accepted it by merging its pull request: go to step 7.
 2. Reproduce the defect yourself by running the code, and keep the output. Ask the person only when you can name the specific reason you cannot reach it, such as a credential or a service this session cannot use.
 3. Find the cause from what running the code shows. List the candidate causes, rule each out with a command or an observation, and never guess. Name the one cause the evidence leaves. When it leaves none, or more than one, say so and ask for what is missing.
 4. Write the plan from the template in `playbooks/build.md`. The title is `# Plan: <title> (fix)`. Use exactly the template's four headings, and keep the plan short. Name the file `intent/<short-description>/plan.md`; the folder holds only this file.
@@ -13,11 +13,12 @@ This playbook takes a defect in behaviour that already exists to a pull request.
 
    Show the whole plan and name the file only as `intent/<short-description>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
 
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could fix the defect from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes.
-6. Create the branch `fix/<short-description>` as `playbooks/open-pr.md` says. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5, and commit `intent/<short-description>/plan.md` as the first commit.
-7. Reproduce the defect as a test. Run it and check that it fails for the reason the cause gives. Commit the failing test before any fix.
-8. Make the test pass without editing it.
-9. 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.
-10. Go on in the same turn, without asking. Follow `playbooks/open-pr.md`, and then `playbooks/review.md`.
+5. Commit `intent/<short-description>/plan.md` on a new branch, with the `Accepted by:` line as the template has it, push it, and open a pull request that changes no file outside `intent/`, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. In plan mode, the engineer's approval lets you write the file and do this step; it is not the acceptance.
+6. **Gate: the engineer accepts the plan.** The engineer merges that pull request to accept the plan, or closes it to reject it. You never merge it, and you change no file outside `intent/` before it is merged. Revise the plan as the engineer asks; each revision is a commit on that branch. Report the pull request's URL, or the pushed branch's name when you could not open one, keep it green as `playbooks/review.md` says, and wait.
+7. When the plan's pull request is merged, create the branch `fix/<short-description>` as `playbooks/open-pr.md` says. In its first commit, set the plan's `Accepted by:` line, under its title, to the account that merged that pull request, read from the host. When you cannot read the host, confirm with `git fetch` that the plan is on the default branch, and write the handle the engineer gives; ask for it when they gave none. Never write a handle the host or the engineer did not give.
+8. Reproduce the defect as a test. Run it and check that it fails for the reason the cause gives. Commit the failing test before any fix.
+9. Make the test pass without editing it.
+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 9 passes.
+**Next:** `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/plan.md

@@ -3,14 +3,14 @@
 This playbook writes the intent. The build plan, `intent/<change>/plan.md`, comes later and is not written here.
 
 1. Let the originator describe the problem in their own words: what they cannot do today, who is affected, what better looks like, and what is out of scope.
-2. Read the code, the docs, and the existing `intent/` folders. Find the rest yourself: the author, for one, is `git config user.name`.
+2. Read the code, the docs, and the existing `intent/` folders. Find the rest yourself. The author is the originator's handle on the host: read it from the host when the session shows whose account it runs as, and ask for it otherwise. Never take it from `git config user.name`, which names the machine's user.
 3. Interview until the originator has said four things: the problem, the outcome, the constraints, and what is out of scope. The outcome is what the user would see.
    - **When all four are already said, go to step 4 in the same turn.**
    - **When one is missing, ask and stop.** Write no draft in that turn. Ask in rounds. Each round holds only questions that do not depend on another question in the same round. Number the questions. Each asks one thing and carries a concrete answer you recommend, worded so "yes" accepts it. A recommended answer is a fact or a choice, such as "Recommended: only the checkout page", never an instruction to the person. When you have no answer to recommend, write "No recommendation" and ask plainly. Wait for the answers, and build the next round on them.
 4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Use exactly the template's five headings. What is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**. Write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file. Show the draft as the plan, and write the file once it is approved.
 5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
 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. 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.
+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.
 
@@ -19,7 +19,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 ```markdown
 # Intent: <title>
 
-Author: <name> (<team>). Status: draft.
+Author: @<handle> (<team>). Status: draft.
 
 ## Problem
 

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

@@ -14,7 +14,7 @@ Do these steps in order.
    | :---------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- |
    | A question, or a request to explain something without changing anything                                                 | Follow [`playbooks/question.md`](playbooks/question.md).                                                                       |
    | A spec for an intent, or a path to an `intent.md`                                                                       | Follow [`playbooks/design.md`](playbooks/design.md).                                                                           |
-   | A build for a spec, a path to a `spec.md`, or a plan the engineer accepted                                              | Follow [`playbooks/build.md`](playbooks/build.md).                                                                             |
+   | A build for a spec, a path to a `spec.md`, or a plan the engineer merged                                                | Follow [`playbooks/build.md`](playbooks/build.md).                                                                             |
    | A review or check of a pull request or a branch, a failing check on a pull request, or a pull request to drive to green | Follow [`playbooks/review.md`](playbooks/review.md).                                                                           |
    | A deploy, a promotion to an environment, or a release to production                                                     | Follow [`playbooks/deploy.md`](playbooks/deploy.md).                                                                           |
    | A finding sent by a job, a monitor, or a trigger, or one the message says no person can answer questions about          | Follow [`playbooks/maintain.md`](playbooks/maintain.md).                                                                       |

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

@@ -5,11 +5,11 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 1. Find the change: the `intent/<change>/` folder whose `spec.md` or `plan.md` the request names. Its `spec.md` must be on the default branch beside its `intent.md`. In each case below, say only that, in two or three lines, and stop: write no file.
    - The request names no change, or the folder has no `spec.md` on any branch: list each `intent/*/` on the default branch that has a `spec.md` and no `plan.md`, or say that there is none.
    - The spec exists only on another branch: say that the spec is not merged yet, and name that branch.
-   - `intent/<change>/plan.md` is already on the default branch: say that the plan is merged, name the file, and say that the change is built only when each requirement of `spec.md` is checked against the tree.
+   - `intent/<change>/plan.md` is on the default branch and `spec.md` says `Status: done.`: say that the change is built, and name both files.
 
    When the request is a bug fix with no spec, none of these cases applies: follow `playbooks/fix.md` instead.
 
-2. When `intent/<change>/plan.md` exists on a branch that is not merged, check out that branch. When the request says the plan is accepted, go to step 6. Otherwise show that plan and go to step 5.
+2. When `intent/<change>/plan.md` is on the default branch, the engineer accepted it by merging its pull request: go to step 7. When it exists only on a branch that is not merged, check out that branch, show that plan, and go to step 5.
 3. Read `intent.md`, `spec.md`, the four policies, found as `playbooks/design.md` step 2 says, and the code the change touches. Start from the accepted spec, in the agent tool's plan mode when it has one, and give the plan the change's `intent.md` and `spec.md`. Then interview the engineer until they have said four things: the files the change touches, the order of the work, the tests that prove it, and each option they rule out.
    - **When all four are already said, in the request or in the files, go to step 4 in the same turn.**
    - **When one is missing, ask and stop.** Write no plan in that turn. Ask in rounds, as step 3 of `playbooks/plan.md` does: numbered questions, each with a recommended answer or "No recommendation". Wait for the answers, and build the next round on them.
@@ -21,13 +21,14 @@ This playbook turns a merged spec into a plan the engineer accepts, and then int
 
    Show the whole plan and name the file only as `intent/<change>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
 
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could build from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes. When the spec classes the change as higher risk, say that a tech lead or an architect accepts the plan with the engineer.
-6. Create the branch as `playbooks/open-pr.md` says, unless step 2 checked one out. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5 or whom the request names, and commit `intent/<change>/plan.md` before any other change. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged.
-7. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow `playbooks/fix.md` steps 7 and 8: commit the failing test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
-8. 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.
-9. 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.
+5. Commit `intent/<change>/plan.md` on a new branch, unless step 2 checked one out, with the `Accepted by:` line as the template has it. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged; when an area of concern of that spec has no `Decision:` line, add it there with the decision you propose, as `playbooks/design.md` step 3 says. Push the branch and open a pull request that changes no file outside `intent/`, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. When the branch already has a pull request, update that one. In plan mode, the engineer's approval lets you write the file and do this step; it is not the acceptance.
+6. **Gate: the engineer accepts the plan.** The engineer merges that pull request to accept the plan, or closes it to reject it. You never merge it, and you change no file outside `intent/` before it is merged. Revise the plan as the engineer asks; each revision is a commit on that branch. When the spec classes the change as higher risk, say that a tech lead or an architect approves that pull request before it is merged. Report the pull request's URL, or the pushed branch's name when you could not open one, keep it green as `playbooks/review.md` says, and wait.
+7. When the plan's pull request is merged, create a new branch as `playbooks/open-pr.md` says. In its first commit, set the plan's `Accepted by:` line, under its title, to the account that merged that pull request, read from the host. When that pull request has an approving review from a second person, add `Also accepted by: @<handle>.` on the next line. When you cannot read the host, confirm with `git fetch` that the plan is on the default branch, and write the handle the engineer gives; ask for it when they gave none. Never write a handle the host or the engineer did not give.
+8. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow `playbooks/fix.md` steps 8 and 9: commit the failing test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
+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 8 passes.
+**Next:** `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/design.md

@@ -8,14 +8,14 @@ This playbook turns a merged intent into the requirements and design spec.
    - `spec.md` already exists: say so and name the file.
 2. Read the four policies, every time, before you write: for each of `brand`, `security`, `compliance`, and `ux`, read the project's `.agents/skills/<area>-policy/SKILL.md` when it exists, and the plugin's default at `../../<area>-policy/SKILL.md`, relative to this playbook, otherwise. Then read the code and the docs the change touches.
 3. Write `intent/<change>/spec.md` from the template below. Use exactly the template's headings.
-   - **Request:** under the status line, quote the words of the request that started this spec.
+   - **Request:** under the status line, quote the words of the request that started this spec. End the line with `Skills at <hash>.`, the short hash of the last commit that changed the plugin's files in this repository: `git log -1 --format=%h -- plugins/sdlc`. When the plugin is not in this repository, write `Skills at unknown.`
    - **Requirements:** numbered. Each one states a result a test or a reader can check.
    - **Design:** how the change fits the existing code: the files that change, and what each one does afterwards.
    - **Policies:** one line for each of the four policies. State which rules of that policy the change must meet, each as a requirement number, or write "Does not apply" and why.
-   - **Areas of concern:** a policy rule the change cannot meet, two policies that contradict, or a decision the files do not settle. Give each one a number and the policy it comes from. Write "None" only when there are none.
+   - **Areas of concern:** a policy rule the change cannot meet, two policies that contradict, or a decision the files do not settle. Give each one a number and the policy it comes from. Under each, on a line of its own, write `Decision: <the decision you propose>.` Write "None" only when there are none.
    - **Open questions:** each open question from `intent.md`, answered with its evidence or carried forward. Write "None" only when the intent has none.
 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 resolves each area of concern with its policy owner, then merges the pull request to accept the spec, or closes it to reject it. 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.
+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.
 

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

@@ -2,7 +2,7 @@
 
 This playbook takes a defect in behaviour that already exists to a pull request. It has no intent and no spec: its plan is the only file it adds under `intent/`.
 
-1. Decide that the request qualifies. It qualifies only when the request is a defect in behaviour that already exists, and the fix adds no new behaviour and no new dependency and changes no schema and no public interface. When a condition fails, say which one in two lines and follow `playbooks/plan.md` instead.
+1. Decide that the request qualifies. It qualifies only when the request is a defect in behaviour that already exists, and the fix adds no new behaviour and no new dependency and changes no schema and no public interface. When a condition fails, say which one in two lines and follow `playbooks/plan.md` instead. When `intent/<short-description>/plan.md` for this defect is already on the default branch, the engineer accepted it by merging its pull request: go to step 7.
 2. Reproduce the defect yourself by running the code, and keep the output. Ask the person only when you can name the specific reason you cannot reach it, such as a credential or a service this session cannot use.
 3. Find the cause from what running the code shows. List the candidate causes, rule each out with a command or an observation, and never guess. Name the one cause the evidence leaves. When it leaves none, or more than one, say so and ask for what is missing.
 4. Write the plan from the template in `playbooks/build.md`. The title is `# Plan: <title> (fix)`. Use exactly the template's four headings, and keep the plan short. Name the file `intent/<short-description>/plan.md`; the folder holds only this file.
@@ -13,11 +13,12 @@ This playbook takes a defect in behaviour that already exists to a pull request.
 
    Show the whole plan and name the file only as `intent/<short-description>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
 
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could fix the defect from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes.
-6. Create the branch `fix/<short-description>` as `playbooks/open-pr.md` says. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5, and commit `intent/<short-description>/plan.md` as the first commit.
-7. Reproduce the defect as a test. Run it and check that it fails for the reason the cause gives. Commit the failing test before any fix.
-8. Make the test pass without editing it.
-9. 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.
-10. Go on in the same turn, without asking. Follow `playbooks/open-pr.md`, and then `playbooks/review.md`.
+5. Commit `intent/<short-description>/plan.md` on a new branch, with the `Accepted by:` line as the template has it, push it, and open a pull request that changes no file outside `intent/`, as the opening paragraph of `playbooks/open-pr.md` says for branches and pull requests. In plan mode, the engineer's approval lets you write the file and do this step; it is not the acceptance.
+6. **Gate: the engineer accepts the plan.** The engineer merges that pull request to accept the plan, or closes it to reject it. You never merge it, and you change no file outside `intent/` before it is merged. Revise the plan as the engineer asks; each revision is a commit on that branch. Report the pull request's URL, or the pushed branch's name when you could not open one, keep it green as `playbooks/review.md` says, and wait.
+7. When the plan's pull request is merged, create the branch `fix/<short-description>` as `playbooks/open-pr.md` says. In its first commit, set the plan's `Accepted by:` line, under its title, to the account that merged that pull request, read from the host. When you cannot read the host, confirm with `git fetch` that the plan is on the default branch, and write the handle the engineer gives; ask for it when they gave none. Never write a handle the host or the engineer did not give.
+8. Reproduce the defect as a test. Run it and check that it fails for the reason the cause gives. Commit the failing test before any fix.
+9. Make the test pass without editing it.
+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 9 passes.
+**Next:** `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/plan.md

@@ -3,14 +3,14 @@
 This playbook writes the intent. The build plan, `intent/<change>/plan.md`, comes later and is not written here.
 
 1. Let the originator describe the problem in their own words: what they cannot do today, who is affected, what better looks like, and what is out of scope.
-2. Read the code, the docs, and the existing `intent/` folders. Find the rest yourself: the author, for one, is `git config user.name`.
+2. Read the code, the docs, and the existing `intent/` folders. Find the rest yourself. The author is the originator's handle on the host: read it from the host when the session shows whose account it runs as, and ask for it otherwise. Never take it from `git config user.name`, which names the machine's user.
 3. Interview until the originator has said four things: the problem, the outcome, the constraints, and what is out of scope. The outcome is what the user would see.
    - **When all four are already said, go to step 4 in the same turn.**
    - **When one is missing, ask and stop.** Write no draft in that turn. Ask in rounds. Each round holds only questions that do not depend on another question in the same round. Number the questions. Each asks one thing and carries a concrete answer you recommend, worded so "yes" accepts it. A recommended answer is a fact or a choice, such as "Recommended: only the checkout page", never an instruction to the person. When you have no answer to recommend, write "No recommendation" and ask plainly. Wait for the answers, and build the next round on them.
 4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Use exactly the template's five headings. What is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**. Write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file. Show the draft as the plan, and write the file once it is approved.
 5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
 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. 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.
+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.
 
@@ -19,7 +19,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 ```markdown
 # Intent: <title>
 
-Author: <name> (<team>). Status: draft.
+Author: @<handle> (<team>). Status: draft.
 
 ## Problem
 

package/templates/base/scripts/check-plan.ts

@@ -3,30 +3,15 @@ import {existsSync, mkdtempSync, readdirSync, readFileSync, rmSync, writeFileSyn
 import path from "node:path";
 import {tmpdir} from "node:os";
 
-type BranchChanges = {
-  changedPaths: string[];
-  headCommit: string;
-  mergeBase: string;
-};
-
-type SelfTestCase = {
-  expectedMessagePart?: string;
-  name: string;
-  problems: string[];
-};
-
 const defaultBranch = "origin/main";
 const intentDirectory = "intent";
-const planFileName = "plan.md";
-const specFileName = "spec.md";
-const intentFileName = "intent.md";
-const proofHeading = "## Proof";
-const requirementsHeading = "## Requirements";
-const acceptancePlaceholder = "@<engineer>";
 const statusLineLimit = 5;
 const acceptedByPrefix = "Accepted by: ";
-const acceptedByPattern = /^Accepted by: @[\dA-Za-z][\dA-Za-z-]*\.$/;
-const requiredHeadings = ["## Files that change", "## Order of work", "## Risks", proofHeading];
+
+type PlanMerge = {
+  approvers: string[];
+  mergedBy: string;
+};
 
 /**
  * Run git in the current directory.
@@ -40,52 +25,6 @@ function runGit(gitArguments: string[]): string {
   }).trim();
 }
 
-/**
- * Find what this branch changed since it left the default branch.
- * @returns The merge base, HEAD, and the changed paths, or undefined when the default branch is not available.
- */
-function findBranchChanges(): BranchChanges | undefined {
-  try {
-    const mergeBase = runGit(["merge-base", "HEAD", defaultBranch]);
-
-    return {
-      mergeBase,
-      headCommit: runGit(["rev-parse", "HEAD"]),
-      changedPaths: runGit(["diff", "--name-only", `${mergeBase}...HEAD`])
-        .split("\n")
-        .filter(changedPath => changedPath !== ""),
-    };
-  } catch {
-    return undefined;
-  }
-}
-
-/**
- * Tell whether a plan must name its accepting engineer: the branch changes a file outside `intent/`.
- * @param branchChanges What the branch changed, or undefined when no merge base was found.
- * @returns False when there is no merge base or HEAD is the default branch tip.
- */
-function requiresAcceptance(branchChanges: BranchChanges | undefined): boolean {
-  return (
-    branchChanges !== undefined &&
-    branchChanges.mergeBase !== branchChanges.headCommit &&
-    branchChanges.changedPaths.some(changedPath => !changedPath.startsWith(`${intentDirectory}/`))
-  );
-}
-
-/**
- * Say why the acceptance rule cannot run.
- * @param branchChanges What the branch changed, or undefined when no merge base was found.
- * @returns A problem when the default branch is not available, otherwise undefined.
- */
-function describeMissingDefaultBranch(
-  branchChanges: BranchChanges | undefined,
-): string | undefined {
-  return branchChanges === undefined
-    ? `${defaultBranch} cannot be found, so the "${acceptedByPrefix}" rule cannot be applied; run "git fetch origin main" to apply it`
-    : undefined;
-}
-
 /**
  * Blank every line of a fenced code block, keeping line numbers.
  * @param lines Document lines.
@@ -148,6 +87,214 @@ function readSection(maskedLines: string[], heading: string): string[] | undefin
   return bounds === undefined ? undefined : maskedLines.slice(...bounds);
 }
 
+const concernsHeading = "## Areas of concern";
+const decisionPrefix = "Decision: ";
+const decisionPattern = /^ *Decision: \S/mu;
+const alsoAcceptedByPrefix = "Also accepted by: ";
+const hostTokenVariable = "GH_TOKEN";
+const hostRepositoryPath = "repos/{owner}/{repo}";
+const authorPrefix = "Author: ";
+const authorPattern = /^Author: @[\dA-Za-z][\w-]*[ .]/;
+const alsoAcceptedByPattern = /^Also accepted by: @([\dA-Za-z][\w-]*)\.$/;
+
+type BranchChanges = {
+  changedPaths: string[];
+  headCommit: string;
+  mergeBase: string;
+};
+
+type SelfTestCase = {
+  expectedMessagePart?: string;
+  name: string;
+  problems: string[];
+};
+
+/**
+ * Find a plan that this branch adds together with a change outside `intent/`.
+ * @param isMerged Whether the default branch already holds the plan.
+ * @param isAcceptanceRequired Whether the branch changes a file outside `intent/`.
+ * @returns At most one message.
+ */
+function findUnmergedPlanProblems(isMerged: boolean, isAcceptanceRequired: boolean): string[] {
+  return isMerged || !isAcceptanceRequired
+    ? []
+    : [
+        `the plan is not on ${defaultBranch} and this branch changes a file outside ${intentDirectory}/; an engineer accepts a plan by merging the pull request that holds only it, so open that pull request and build on a new branch after it is merged`,
+      ];
+}
+
+/**
+ * Compare the plan's accepting handles with the host's record of its pull request.
+ * @param maskedLines Plan lines with fenced code blocks emptied.
+ * @param planMerge Who merged the pull request that last changed the plan, and who approved it.
+ * @returns One message per handle the host does not confirm.
+ */
+function findHostAcceptanceProblems(maskedLines: string[], planMerge: PlanMerge): string[] {
+  const acceptedLine = maskedLines.slice(1).find(line => line.trim() !== "") ?? "";
+  const accepter = acceptedLine.trimEnd().slice(acceptedByPrefix.length + 1, -1);
+  const secondAccepter = readSecondAccepter(maskedLines)?.toLowerCase();
+  const merger = planMerge.mergedBy.toLowerCase();
+  const approvers = planMerge.approvers.map(approver => approver.toLowerCase());
+
+  const mergerProblems =
+    accepter.toLowerCase() === merger
+      ? []
+      : [
+          `the "${acceptedByPrefix}" line names @${accepter}, and the host shows that @${planMerge.mergedBy} merged the plan's pull request; write the account that merged it`,
+        ];
+
+  const isSecondConfirmed =
+    secondAccepter === undefined ||
+    (secondAccepter !== merger && approvers.includes(secondAccepter));
+
+  return isSecondConfirmed
+    ? mergerProblems
+    : [
+        ...mergerProblems,
+        `the "${alsoAcceptedByPrefix}" line names a second person, and the host shows no approving review from that account on the plan's pull request; write "${alsoAcceptedByPrefix}@<handle>." with the account that approved it`,
+      ];
+}
+
+/**
+ * Find each numbered area of concern in a spec that carries no decision.
+ * @param specText Spec content.
+ * @returns At most one message, which names the numbers.
+ */
+function findDecisionProblems(specText: string): string[] {
+  const undecidedNumbers = (
+    readSection(maskFencedBlocks(splitLines(specText)), concernsHeading) ?? []
+  )
+    .join("\n")
+    .split(/^(?=\d+\. )/mu)
+    .filter(concern => /^\d+\. /u.test(concern) && !decisionPattern.test(concern))
+    .map(concern => /^\d+/u.exec(concern)?.[0]);
+
+  return undecidedNumbers.length === 0
+    ? []
+    : [
+        `area of concern ${undecidedNumbers.join(", ")} has no "${decisionPrefix}<the decision>." line under it; write the proposed decision there, and the product owner corrects it before merging the spec`,
+      ];
+}
+
+/**
+ * Find an intent whose author is not a handle on the host.
+ * @param intentText Intent content.
+ * @returns At most one message.
+ */
+function findAuthorProblems(intentText: string): string[] {
+  const authorLine = splitLines(intentText).find(line => line.startsWith(authorPrefix));
+
+  return authorLine !== undefined && authorPattern.test(authorLine)
+    ? []
+    : [
+        `the "${authorPrefix}" line holds no handle; write "${authorPrefix}@<handle> (<team>)." with the originator's account on the host`,
+      ];
+}
+
+/**
+ * Ask the host who merged the pull request that last changed a plan on the default branch, and who approved it.
+ * @param mergeBase The commit this branch left the default branch at.
+ * @param planPath Path of the plan.
+ * @returns The merging account and the approving accounts, or undefined when no host token is set.
+ * @throws {Error} When a token is set and git or the host's tool fails.
+ */
+function readPlanMerge(mergeBase: string, planPath: string): PlanMerge | undefined {
+  if (process.env[hostTokenVariable] === undefined || process.env[hostTokenVariable] === "") {
+    return undefined;
+  }
+
+  const commit = runGit(["log", "-1", "--format=%H", mergeBase, "--", planPath]);
+  const pullRequest = runHost(`${hostRepositoryPath}/commits/${commit}/pulls`, ".[0].number");
+  const pullRequestPath = `${hostRepositoryPath}/pulls/${pullRequest}`;
+  const mergedBy = runHost(pullRequestPath, ".merged_by.login");
+  const approvedFilter = '.[] | select(.state == "APPROVED") | .user.login';
+  const approvers = runHost(`${pullRequestPath}/reviews`, approvedFilter);
+
+  return {
+    mergedBy,
+    approvers: approvers.split("\n").filter(approver => approver !== ""),
+  };
+}
+
+/**
+ * Call the host's API through its command-line tool.
+ * @param apiPath Path after `gh api`.
+ * @param filter The jq filter applied to the answer.
+ * @returns Trimmed standard output.
+ */
+function runHost(apiPath: string, filter: string): string {
+  return execFileSync("gh", ["api", apiPath, "--jq", filter], {
+    encoding: "utf8",
+    stdio: ["ignore", "pipe", "pipe"],
+  }).trim();
+}
+
+/**
+ * Read the handle on the plan's `Also accepted by:` line.
+ * @param maskedLines Plan lines with fenced code blocks emptied.
+ * @returns The handle, an empty string when the line is malformed, or undefined when there is no such line.
+ */
+function readSecondAccepter(maskedLines: string[]): string | undefined {
+  const line = maskedLines.find(planLine => planLine.startsWith(alsoAcceptedByPrefix));
+
+  return line === undefined ? undefined : (alsoAcceptedByPattern.exec(line.trimEnd())?.[1] ?? "");
+}
+
+const planFileName = "plan.md";
+const specFileName = "spec.md";
+const intentFileName = "intent.md";
+const proofHeading = "## Proof";
+const requirementsHeading = "## Requirements";
+const acceptancePlaceholder = "@<engineer>";
+const acceptedByPattern = /^Accepted by: @[\dA-Za-z][\w-]*\.$/;
+const requiredHeadings = ["## Files that change", "## Order of work", "## Risks", proofHeading];
+
+/**
+ * Find what this branch changed since it left the default branch.
+ * @returns The merge base, HEAD, and the changed paths, or undefined when the default branch is not available.
+ */
+function findBranchChanges(): BranchChanges | undefined {
+  try {
+    const mergeBase = runGit(["merge-base", "HEAD", defaultBranch]);
+
+    return {
+      mergeBase,
+      headCommit: runGit(["rev-parse", "HEAD"]),
+      changedPaths: runGit(["diff", "--name-only", `${mergeBase}...HEAD`])
+        .split("\n")
+        .filter(changedPath => changedPath !== ""),
+    };
+  } catch {
+    return undefined;
+  }
+}
+
+/**
+ * Tell whether a plan must name its accepting engineer: the branch changes a file outside `intent/`.
+ * @param branchChanges What the branch changed, or undefined when no merge base was found.
+ * @returns False when there is no merge base or HEAD is the default branch tip.
+ */
+function requiresAcceptance(branchChanges: BranchChanges | undefined): boolean {
+  return (
+    branchChanges !== undefined &&
+    branchChanges.mergeBase !== branchChanges.headCommit &&
+    branchChanges.changedPaths.some(changedPath => !changedPath.startsWith(`${intentDirectory}/`))
+  );
+}
+
+/**
+ * Say why the acceptance rule cannot run.
+ * @param branchChanges What the branch changed, or undefined when no merge base was found.
+ * @returns A problem when the default branch is not available, otherwise undefined.
+ */
+function describeMissingDefaultBranch(
+  branchChanges: BranchChanges | undefined,
+): string | undefined {
+  return branchChanges === undefined
+    ? `${defaultBranch} cannot be found, so the "${acceptedByPrefix}" rule cannot be applied; run "git fetch origin main" to apply it`
+    : undefined;
+}
+
 /**
  * Quote each heading and join them for a message.
  * @param headings Heading texts.
@@ -520,6 +667,26 @@ function createChangeFolder(fileNames: string[]): string {
 const fixPlanFolder = createChangeFolder([planFileName]);
 const intentOnlyFolder = createChangeFolder([intentFileName, planFileName]);
 const specOnlyFolder = createChangeFolder([specFileName, planFileName]);
+const onePlanLines = splitLines(buildPlan({}));
+
+const twoPlanLines = splitLines(
+  buildPlan({
+    accepted: `${engineerLine}\n${alsoAcceptedByPrefix}@lead.`,
+  }),
+);
+
+/**
+ * Build the host's record of a plan's pull request, for a self-test.
+ * @param mergedByLogin The account that merged it.
+ * @param approvers The accounts that approved it.
+ * @returns The record.
+ */
+function hostRecord(mergedByLogin: string, approvers: string[]): PlanMerge {
+  return {
+    approvers,
+    mergedBy: mergedByLogin,
+  };
+}
 
 const selfTestCases: SelfTestCase[] = [
   {
@@ -843,6 +1010,80 @@ const selfTestCases: SelfTestCase[] = [
       false,
     ),
   },
+  {
+    name: "a plan added together with code",
+    expectedMessagePart: `is not on ${defaultBranch}`,
+    problems: findUnmergedPlanProblems(false, true),
+  },
+  {
+    name: "a plan added alone",
+    problems: findUnmergedPlanProblems(false, false),
+  },
+  {
+    name: "a plan that is on the default branch, built with code",
+    problems: findUnmergedPlanProblems(true, true),
+  },
+  {
+    name: "the accepting handle is the account that merged, in another letter case",
+    problems: findHostAcceptanceProblems(onePlanLines, hostRecord("Engineer", [])),
+  },
+  {
+    name: "the accepting handle is not the account that merged",
+    expectedMessagePart: "@someone-else merged",
+    problems: findHostAcceptanceProblems(onePlanLines, hostRecord("someone-else", [])),
+  },
+  {
+    name: "the second accepter approved the plan's pull request",
+    problems: findHostAcceptanceProblems(twoPlanLines, hostRecord("engineer", ["lead"])),
+  },
+  {
+    name: "the second accepter gave no approving review",
+    expectedMessagePart: "no approving review",
+    problems: findHostAcceptanceProblems(twoPlanLines, hostRecord("engineer", [])),
+  },
+  {
+    name: "the second accepter is the account that merged",
+    expectedMessagePart: "no approving review",
+    problems: findHostAcceptanceProblems(
+      splitLines(
+        buildPlan({
+          accepted: `${engineerLine}\n${alsoAcceptedByPrefix}@engineer.`,
+        }),
+      ),
+      hostRecord("engineer", ["engineer"]),
+    ),
+  },
+  {
+    name: "every area of concern has a decision",
+    problems: findDecisionProblems(
+      `${concernsHeading}\n\n1. A.\n   ${decisionPrefix}yes.\n2. B.\n   ${decisionPrefix}no.\n\n## Open questions\n`,
+    ),
+  },
+  {
+    name: "a spec with no area of concern",
+    problems: findDecisionProblems(`${concernsHeading}\n\nNone\n\n## Open questions\n`),
+  },
+  {
+    name: "an area of concern has no decision",
+    expectedMessagePart: "area of concern 2 has no",
+    problems: findDecisionProblems(
+      `${concernsHeading}\n\n1. A.\n   ${decisionPrefix}yes.\n2. B.\n\n## Open questions\n`,
+    ),
+  },
+  {
+    name: "a decision line with no text is not a decision",
+    expectedMessagePart: "area of concern 1 has no",
+    problems: findDecisionProblems(`${concernsHeading}\n\n1. A.\n   ${decisionPrefix}\n`),
+  },
+  {
+    name: "an intent whose author is a handle",
+    problems: findAuthorProblems("# Intent: A\n\nAuthor: @originator (Team). Status: draft.\n"),
+  },
+  {
+    name: "an intent whose author is a name",
+    expectedMessagePart: "holds no handle",
+    problems: findAuthorProblems("# Intent: A\n\nAuthor: A Person (Team). Status: draft.\n"),
+  },
 ];
 
 /**
@@ -945,17 +1186,27 @@ function findPlanLines(planPaths: string[]): string[] {
         `${planPath}: the file does not exist; pass the path of an existing ${planFileName}`,
     );
 
-  const checkedLines = planPaths
+  const changedPlanPaths = planPaths
     .filter(planPath => existsSync(planPath))
     .filter(
       planPath =>
         branchChanges === undefined ||
         readDefaultBranchFile(branchChanges.mergeBase, planPath) !==
           readFileSync(planPath, "utf8").trim(),
-    )
-    .flatMap(planPath => findPlanFileLines(planPath, isAcceptanceRequired));
+    );
 
-  return [...missingBranchLines, ...missingLines, ...checkedLines];
+  const checkedLines = changedPlanPaths.flatMap(planPath =>
+    findPlanFileLines(planPath, isAcceptanceRequired),
+  );
+
+  const acceptanceLines =
+    branchChanges === undefined
+      ? []
+      : changedPlanPaths.flatMap(planPath =>
+          findPlanAcceptanceLines(planPath, branchChanges.mergeBase, isAcceptanceRequired),
+        );
+
+  return [...missingBranchLines, ...missingLines, ...checkedLines, ...acceptanceLines];
 }
 
 /**
@@ -972,6 +1223,78 @@ function readDefaultBranchFile(mergeBase: string, filePath: string): string | un
   }
 }
 
+/**
+ * Check that a plan this branch builds was accepted by a merge, and by whom.
+ * @param planPath Path of the plan.
+ * @param mergeBase The commit this branch left the default branch at.
+ * @param isAcceptanceRequired Whether the branch changes a file outside `intent/`.
+ * @returns One line per problem.
+ */
+function findPlanAcceptanceLines(
+  planPath: string,
+  mergeBase: string,
+  isAcceptanceRequired: boolean,
+): string[] {
+  const isOnDefaultBranch = readDefaultBranchFile(mergeBase, planPath) !== undefined;
+  const unmergedProblems = findUnmergedPlanProblems(isOnDefaultBranch, isAcceptanceRequired);
+
+  if (!isAcceptanceRequired || unmergedProblems.length > 0) {
+    return unmergedProblems.map(message => `${planPath}: ${message}`);
+  }
+
+  const planMerge = readPlanMerge(mergeBase, planPath);
+
+  if (planMerge === undefined) {
+    process.stdout.write(
+      `${planPath}: the "${acceptedByPrefix}" handle was not checked against the host; set ${hostTokenVariable} and install gh to check who merged the plan's pull request\n`,
+    );
+
+    return [];
+  }
+
+  const planLines = splitLines(readFileSync(planPath, "utf8"));
+
+  return findHostAcceptanceProblems(maskFencedBlocks(planLines), planMerge).map(
+    message => `${planPath}: ${message}`,
+  );
+}
+
+/**
+ * Report each spec this branch adds or changes that leaves an area of concern undecided, and each intent it adds whose author is not a handle.
+ * @param changeFolders The `intent/<change>` folders.
+ * @returns One line per problem.
+ */
+function findRecordLines(changeFolders: string[]): string[] {
+  const branchChanges = changeFolders.length > 0 ? findBranchChanges() : undefined;
+
+  if (branchChanges === undefined) {
+    return [];
+  }
+
+  return changeFolders.flatMap(folder => {
+    const specPath = path.join(folder, specFileName);
+    const intentPath = path.join(folder, intentFileName);
+    const specText = readSpec(specPath);
+
+    const specProblems =
+      specText === undefined ||
+      readDefaultBranchFile(branchChanges.mergeBase, specPath) === specText.trim()
+        ? []
+        : findDecisionProblems(specText);
+
+    const authorProblems =
+      existsSync(intentPath) &&
+      readDefaultBranchFile(branchChanges.mergeBase, intentPath) === undefined
+        ? findAuthorProblems(readFileSync(intentPath, "utf8"))
+        : [];
+
+    return [
+      ...specProblems.map(message => `${specPath}: ${message}`),
+      ...authorProblems.map(message => `${intentPath}: ${message}`),
+    ];
+  });
+}
+
 /**
  * Report each intent and spec that this branch marks accepted before its pull request merged.
  * @param changeFolders The `intent/<change>` folders.
@@ -1034,6 +1357,7 @@ if (selfTestFailures.length > 0) {
     ...findPlanLines(planPaths),
     ...findMissingPlanLines(changeFolders),
     ...findAcceptedStatusLines(changeFolders),
+    ...findRecordLines(changeFolders),
   ];
 
   if (problemLines.length > 0) {

package/templates/nestjs/.github/workflows/ci.yml

@@ -62,6 +62,9 @@ jobs:
     if: needs.changes.outputs.full_verification == 'true'
     runs-on: ubuntu-latest
     timeout-minutes: 20
+    permissions:
+      contents: read
+      pull-requests: read # Needed by plan:check to read who merged the plan's pull request.
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
@@ -78,6 +81,8 @@ jobs:
       - name: Check agent gates
         run: pnpm gates:check
       - name: Check plans
+        env:
+          GH_TOKEN: ${{ github.token }} # plan:check reads who merged the plan's pull request.
         run: pnpm plan:check
       - name: Check bands
         run: pnpm bands:check

package/templates/nestjs/AGENTS.md

@@ -34,7 +34,7 @@ The `verifier` subagent starts the app with `pnpm start:dev`. It exercises the c
 1. **Put unit tests next to the code as `src/**/*.test.ts` and end-to-end tests in `test/` as `*.e2e.test.ts`.** `vitest.config.ts` and `vitest.e2e.config.ts` collect only those patterns.
 2. **Read configuration from environment variables and fail when one is missing**, as `parsePort` does. Document each variable in `.env.example`.
 3. **Log through Nest's `Logger`.** It goes to the `ConsoleLogger` set in `src/main.ts`.
-4. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. Commit the approved plan as `intent/<change>/plan.md` with an `Accepted by:` line naming the engineer, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
+4. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. The plan, `intent/<change>/plan.md`, gets a pull request of its own, and the engineer accepts it by merging that pull request, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
 5. **Start a bug fix with a failing test.** A bug fix has no intent and no spec; its plan, `intent/<short-description>/plan.md`, is accepted by an engineer before any code changes. Reproduce the bug as a test, confirm it fails for the reason you expect, and commit it on a `fix/` branch. Then `.agents/hooks/agent-test-edit-gate.sh` blocks test edits by itself: make the test pass without editing it. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
 6. **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 end with the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 7. **Branch from the latest `origin/main`, and open the pull request ready for review.** Name the branch `<type>/<short-description>` and fill the body from `.github/pull_request_template.md`. `.github/workflows/ci.yml` runs full verification only on a pull request that is not a draft. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.

package/templates/nextjs/.github/workflows/ci.yml

@@ -62,6 +62,9 @@ jobs:
     if: needs.changes.outputs.full_verification == 'true'
     runs-on: ubuntu-latest
     timeout-minutes: 20
+    permissions:
+      contents: read
+      pull-requests: read # Needed by plan:check to read who merged the plan's pull request.
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
@@ -78,6 +81,8 @@ jobs:
       - name: Check agent gates
         run: pnpm gates:check
       - name: Check plans
+        env:
+          GH_TOKEN: ${{ github.token }} # plan:check reads who merged the plan's pull request.
         run: pnpm plan:check
       - name: Check bands
         run: pnpm bands:check

package/templates/nextjs/AGENTS.md

@@ -34,7 +34,7 @@ The `verifier` subagent starts the app with `pnpm dev`. It exercises the changed
 1. **Put unit tests next to the code as `app/**/*.test.{ts,tsx}` and Playwright end-to-end tests in `test/` as `*.e2e.test.ts`.** Vitest collects only the first pattern.
 2. **Component tests need a DOM test environment, and Vitest runs in Node.js.** Add that environment with the first component test.
 3. **Read configuration from environment variables and fail when one is missing.** Document each variable in `.env.example`.
-4. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. Commit the approved plan as `intent/<change>/plan.md` with an `Accepted by:` line naming the engineer, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
+4. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. The plan, `intent/<change>/plan.md`, gets a pull request of its own, and the engineer accepts it by merging that pull request, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
 5. **Start a bug fix with a failing test.** A bug fix has no intent and no spec; its plan, `intent/<short-description>/plan.md`, is accepted by an engineer before any code changes. Reproduce the bug as a test, confirm it fails for the reason you expect, and commit it on a `fix/` branch. Then `.agents/hooks/agent-test-edit-gate.sh` blocks test edits by itself: make the test pass without editing it. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
 6. **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 end with the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 7. **Branch from the latest `origin/main`, and open the pull request ready for review.** Name the branch `<type>/<short-description>` and fill the body from `.github/pull_request_template.md`. `.github/workflows/ci.yml` runs full verification only on a pull request that is not a draft. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.

package/templates/nodejs/.github/workflows/ci.yml

@@ -62,6 +62,9 @@ jobs:
     if: needs.changes.outputs.full_verification == 'true'
     runs-on: ubuntu-latest
     timeout-minutes: 20
+    permissions:
+      contents: read
+      pull-requests: read # Needed by plan:check to read who merged the plan's pull request.
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
@@ -78,6 +81,8 @@ jobs:
       - name: Check agent gates
         run: pnpm gates:check
       - name: Check plans
+        env:
+          GH_TOKEN: ${{ github.token }} # plan:check reads who merged the plan's pull request.
         run: pnpm plan:check
       - name: Check bands
         run: pnpm bands:check

package/templates/nodejs/AGENTS.md

@@ -33,7 +33,7 @@ The `verifier` subagent starts the app with `pnpm start:dev`. It exercises the c
 
 1. **Put tests next to the code as `src/**/*.test.ts`.** Vitest collects only that pattern.
 2. **Read configuration from environment variables and fail when one is missing**, as `parsePort` does. Document each variable in `.env.example`; `pnpm start` and `pnpm start:dev` load `.env`.
-3. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. Commit the approved plan as `intent/<change>/plan.md` with an `Accepted by:` line naming the engineer, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
+3. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. The plan, `intent/<change>/plan.md`, gets a pull request of its own, and the engineer accepts it by merging that pull request, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
 4. **Start a bug fix with a failing test.** A bug fix has no intent and no spec; its plan, `intent/<short-description>/plan.md`, is accepted by an engineer before any code changes. Reproduce the bug as a test, confirm it fails for the reason you expect, and commit it on a `fix/` branch. Then `.agents/hooks/agent-test-edit-gate.sh` blocks test edits by itself: make the test pass without editing it. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
 5. **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 end with the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 6. **Branch from the latest `origin/main`, and open the pull request ready for review.** Name the branch `<type>/<short-description>` and fill the body from `.github/pull_request_template.md`. `.github/workflows/ci.yml` runs full verification only on a pull request that is not a draft. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.

package/templates/payload/.github/workflows/ci.yml

@@ -79,6 +79,9 @@ jobs:
       DATABASE_URL: postgres://postgres:postgres@localhost:5432/payload
       PAYLOAD_SECRET: ci-only-secret
       APP_URL: http://localhost:3000
+    permissions:
+      contents: read
+      pull-requests: read # Needed by plan:check to read who merged the plan's pull request.
     steps:
       - name: Checkout repository
         uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
@@ -95,6 +98,8 @@ jobs:
       - name: Check agent gates
         run: pnpm gates:check
       - name: Check plans
+        env:
+          GH_TOKEN: ${{ github.token }} # plan:check reads who merged the plan's pull request.
         run: pnpm plan:check
       - name: Check bands
         run: pnpm bands:check

package/templates/payload/AGENTS.md

@@ -37,7 +37,7 @@ The `verifier` subagent starts the app with `pnpm dev`, which needs a PostgreSQL
 2. **Put unit tests next to the code as `src/**/*.test.{ts,tsx}` and Playwright end-to-end tests in `test/` as `*.e2e.test.ts`.** Vitest collects only the first pattern.
 3. **Component tests need a DOM test environment, and Vitest runs in Node.js.** Add that environment with the first component test.
 4. **Read configuration through `requireEnvironment` in `src/environment.ts`.** Document each variable in `.env.example`.
-5. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. Commit the approved plan as `intent/<change>/plan.md` with an `Accepted by:` line naming the engineer, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
+5. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. The plan, `intent/<change>/plan.md`, gets a pull request of its own, and the engineer accepts it by merging that pull request, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
 6. **Start a bug fix with a failing test.** A bug fix has no intent and no spec; its plan, `intent/<short-description>/plan.md`, is accepted by an engineer before any code changes. Reproduce the bug as a test, confirm it fails for the reason you expect, and commit it on a `fix/` branch. Then `.agents/hooks/agent-test-edit-gate.sh` blocks test edits by itself: make the test pass without editing it. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
 7. **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 end with the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 8. **Branch from the latest `origin/main`, and open the pull request ready for review.** Name the branch `<type>/<short-description>` and fill the body from `.github/pull_request_template.md`. `.github/workflows/ci.yml` runs full verification only on a pull request that is not a draft. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.

package/templates/turborepo/.github/workflows/ci.yml

@@ -104,6 +104,7 @@ jobs:
     permissions:
       contents: read
       id-token: write # Needed to exchange GitHub OIDC for a Turborepo Remote Cache token.
+      pull-requests: read # Needed by plan:check to read who merged the plan's pull request.
     services:
       postgres:
         image: postgres:17.11-alpine@sha256:266d3c257594e195b309ae9d1805e54c788f1d7b375f56bf6c367aac6c917e7b
@@ -156,6 +157,8 @@ jobs:
       - name: Check agent gates
         run: pnpm gates:check
       - name: Check plans
+        env:
+          GH_TOKEN: ${{ github.token }} # plan:check reads who merged the plan's pull request.
         run: pnpm plan:check
       - name: Check bands
         run: pnpm bands:check

package/templates/turborepo/AGENTS.md

@@ -39,7 +39,7 @@ The `verifier` subagent starts the app with `pnpm dev`, which needs a PostgreSQL
 2. **Put unit tests next to the code and Playwright end-to-end tests in `apps/app/test/` and `apps/backoffice/test/` as `*.e2e.test.ts`.** Vitest collects `apps/app/app/**/*.test.{ts,tsx}` and `apps/backoffice/src/**/*.test.{ts,tsx}`.
 3. **Component tests need a DOM test environment, and Vitest runs in Node.js.** Add that environment with the first component test.
 4. **Read backoffice configuration through `requireEnvironment` in `apps/backoffice/src/environment.ts`.** Document each variable in `.env.example`.
-5. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. Commit the approved plan as `intent/<change>/plan.md` with an `Accepted by:` line naming the engineer, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
+5. **Start from the accepted spec, in plan mode** (Cursor: Plan Mode). Give the plan the change's `intent/<change>/intent.md` and `spec.md`. The plan, `intent/<change>/plan.md`, gets a pull request of its own, and the engineer accepts it by merging that pull request, as `playbooks/build.md` of the `sdlc-mode` skill in `plugins/sdlc/claude-code/` describes.
 6. **Start a bug fix with a failing test.** A bug fix has no intent and no spec; its plan, `intent/<short-description>/plan.md`, is accepted by an engineer before any code changes. Reproduce the bug as a test, confirm it fails for the reason you expect, and commit it on a `fix/` branch. Then `.agents/hooks/agent-test-edit-gate.sh` blocks test edits by itself: make the test pass without editing it. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
 7. **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 end with the message that would start it: `/sdlc:sdlc-mode` followed by their own words.
 8. **Branch from the latest `origin/main`, and open the pull request ready for review.** Name the branch `<type>/<short-description>` and fill the body from `.github/pull_request_template.md`. `.github/workflows/ci.yml` runs full verification only on a pull request that is not a draft. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.