@next-friday/create-app 6.0.1 → 7.0.0

package/package.json

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

package/templates/base/.agents/skills/sdlc/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: sdlc
+description: The front door for work in this project. Matches a request to a playbook and runs it to the next human gate. Run it with /sdlc.
+disable-model-invocation: true
+---
+
+# SDLC
+
+Do these steps in order.
+
+1. **Match the request** to the first row that fits, and read that row's file before you act.
+
+   | The request                                                                      | What to do                                                                                                                                                                                                                                           |
+   | :------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+   | A question, or a request to explain or check without changing things             | Follow [`playbooks/question.md`](playbooks/question.md).                                                                                                                                                                                             |
+   | An idea, a problem, a ticket, or an incident, whether asked for or only reported | Follow [`playbooks/plan.md`](playbooks/plan.md).                                                                                                                                                                                                     |
+   | A later step: a spec, a build, a review, a deploy, or an incident fix            | Say "This step has no playbook in `/sdlc` yet" and name the step. Name the skill that covers it when one exists: `write-spec` for a spec, `babysit-pr` for a pull request you opened. Answer what you can as `playbooks/question.md` says, and stop. |
+
+   When a request both asks a question and reports a problem, use `question` and offer `plan` in one line.
+
+2. **Do the playbook's steps yourself.** Find facts in files and commands instead of asking. Stop only where the playbook says to stop; at a step marked **Gate**, which waits for the person it names and is never skipped; before an irreversible action; or for a decision no file settles. `.agents/rules/agent-owned-work.md` lists the gates and the irreversible actions.
+3. **Write the reply in the shape below,** following the **Write replies a person can check** convention in `AGENTS.md`.
+
+## Reply shape
+
+Write every part in the language of the person's message; keep paths, commands, copied step text, and a draft file's own text as they are. For `question` and for a later step, leave out **Steps** and put the answer in its place.
+
+```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.>
+
+**Steps:**
+
+1. <the first sentence of step 1 of the playbook, copied word for word>: done | open | skip: <reason>
+2. <and so on for every numbered step of the playbook>
+
+<What the current step produces: the round of questions, or the whole draft.>
+
+**Status:** <what is done, what comes next, and which gate it waits on and for whom.>
+```
+
+A step that is not finished is `open`, including one that waits at its Gate. Use `skip` only for a step you decide never to do.
+
+When the evidence shows that the change cannot be made in this project, say so under **Request**. In the `plan` playbook, the first round then asks the one question that settles where the change belongs.
+
+"new task" starts again at step 1. "don't change anything" keeps the session on `question`.

package/templates/base/.agents/skills/sdlc/playbooks/plan.md

@@ -0,0 +1,31 @@
+# Plan phase: write `intent.md`
+
+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. Never ask what a file or a command can tell you: the author, for one, is `git config user.name`.
+3. Interview until the originator has said four things: the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
+   - **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, each asks one thing, numbered, each with 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. Write the file in the language of the files already in `intent/`. 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`.
+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.
+6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner sets `Status: accepted.` or `Status: rejected.` and merges the pull request; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+## Template
+
+```markdown
+# Intent: <title>
+
+Author: <name> (<team>). Status: draft.
+
+## Problem
+
+## Proposed outcome
+
+## Affected users and systems
+
+## Constraints
+
+## Open questions
+```

package/templates/base/.agents/skills/sdlc/playbooks/question.md

@@ -0,0 +1,6 @@
+# Question
+
+1. Find the facts: read the files and run read-only commands.
+2. Answer, citing `path:line` or command output for each claim, as the **Write replies a person can check** convention in `AGENTS.md` says.
+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 write an intent for this` to start the change", and stop.

package/templates/base/.agents/skills/sdlc-help/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: sdlc-help
+description: Explains how this project's workflow runs and how to use /sdlc. It answers and starts no work. Run it with /sdlc-help.
+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 in the person's language: this command starts no work; and the message to send instead, which is `/sdlc` followed by their own words.
+2. When the topic is unclear, ask one question with these choices: how the workflow runs, starting work, who decides at each gate, fixing a mistake the agent repeats, or adjusting a 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.
+6. Write the reply as the **Write replies a person can check** convention in `AGENTS.md` says.
+
+## Map
+
+- **The loop:** intent, then spec, then plan, then build, review, and maintain. Each change keeps its files in `intent/<change>/`: `intent.md`, `spec.md`, and `plan.md` (`intent/README.md`).
+- **Starting work:** `/sdlc` matches the request to a playbook in `.agents/skills/sdlc/playbooks/`. The table in `.agents/skills/sdlc/SKILL.md` lists the playbooks this project has. The `plan` playbook writes `intent.md`; `intent/<change>/plan.md` is the later build plan.
+- **Who decides:** `.agents/rules/agent-owned-work.md` lists the human gates. `.github/CODEOWNERS` names who approves each path.
+- **A mistake the agent repeats:** add the correction to **Things Claude gets wrong** in `AGENTS.md`.
+- **Company policy:** the policy skills in `.agents/skills/`; `.github/CODEOWNERS` names each one's owner.

package/templates/base/.claude/skills/sdlc/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: sdlc
+description: The front door for work in this project. Matches a request to a playbook and runs it to the next human gate. Run it with /sdlc.
+disable-model-invocation: true
+---
+
+# SDLC
+
+Do these steps in order.
+
+1. **Match the request** to the first row that fits, and read that row's file before you act.
+
+   | The request                                                                      | What to do                                                                                                                                                                                                                                           |
+   | :------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+   | A question, or a request to explain or check without changing things             | Follow [`playbooks/question.md`](playbooks/question.md).                                                                                                                                                                                             |
+   | An idea, a problem, a ticket, or an incident, whether asked for or only reported | Follow [`playbooks/plan.md`](playbooks/plan.md).                                                                                                                                                                                                     |
+   | A later step: a spec, a build, a review, a deploy, or an incident fix            | Say "This step has no playbook in `/sdlc` yet" and name the step. Name the skill that covers it when one exists: `write-spec` for a spec, `babysit-pr` for a pull request you opened. Answer what you can as `playbooks/question.md` says, and stop. |
+
+   When a request both asks a question and reports a problem, use `question` and offer `plan` in one line.
+
+2. **Do the playbook's steps yourself.** Find facts in files and commands instead of asking. Stop only where the playbook says to stop; at a step marked **Gate**, which waits for the person it names and is never skipped; before an irreversible action; or for a decision no file settles. `.agents/rules/agent-owned-work.md` lists the gates and the irreversible actions.
+3. **Write the reply in the shape below,** following the **Write replies a person can check** convention in `AGENTS.md`.
+
+## Reply shape
+
+Write every part in the language of the person's message; keep paths, commands, copied step text, and a draft file's own text as they are. For `question` and for a later step, leave out **Steps** and put the answer in its place.
+
+```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.>
+
+**Steps:**
+
+1. <the first sentence of step 1 of the playbook, copied word for word>: done | open | skip: <reason>
+2. <and so on for every numbered step of the playbook>
+
+<What the current step produces: the round of questions, or the whole draft.>
+
+**Status:** <what is done, what comes next, and which gate it waits on and for whom.>
+```
+
+A step that is not finished is `open`, including one that waits at its Gate. Use `skip` only for a step you decide never to do.
+
+When the evidence shows that the change cannot be made in this project, say so under **Request**. In the `plan` playbook, the first round then asks the one question that settles where the change belongs.
+
+"new task" starts again at step 1. "don't change anything" keeps the session on `question`.

package/templates/base/.claude/skills/sdlc/playbooks/plan.md

@@ -0,0 +1,31 @@
+# Plan phase: write `intent.md`
+
+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. Never ask what a file or a command can tell you: the author, for one, is `git config user.name`.
+3. Interview until the originator has said four things: the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
+   - **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, each asks one thing, numbered, each with 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. Write the file in the language of the files already in `intent/`. 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`.
+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.
+6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner sets `Status: accepted.` or `Status: rejected.` and merges the pull request; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+## Template
+
+```markdown
+# Intent: <title>
+
+Author: <name> (<team>). Status: draft.
+
+## Problem
+
+## Proposed outcome
+
+## Affected users and systems
+
+## Constraints
+
+## Open questions
+```

package/templates/base/.claude/skills/sdlc/playbooks/question.md

@@ -0,0 +1,6 @@
+# Question
+
+1. Find the facts: read the files and run read-only commands.
+2. Answer, citing `path:line` or command output for each claim, as the **Write replies a person can check** convention in `AGENTS.md` says.
+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 write an intent for this` to start the change", and stop.

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

@@ -0,0 +1,22 @@
+---
+name: sdlc-help
+description: Explains how this project's workflow runs and how to use /sdlc. It answers and starts no work. Run it with /sdlc-help.
+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 in the person's language: this command starts no work; and the message to send instead, which is `/sdlc` followed by their own words.
+2. When the topic is unclear, ask one question with these choices: how the workflow runs, starting work, who decides at each gate, fixing a mistake the agent repeats, or adjusting a 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.
+6. Write the reply as the **Write replies a person can check** convention in `AGENTS.md` says.
+
+## Map
+
+- **The loop:** intent, then spec, then plan, then build, review, and maintain. Each change keeps its files in `intent/<change>/`: `intent.md`, `spec.md`, and `plan.md` (`intent/README.md`).
+- **Starting work:** `/sdlc` matches the request to a playbook in `.agents/skills/sdlc/playbooks/`. The table in `.agents/skills/sdlc/SKILL.md` lists the playbooks this project has. The `plan` playbook writes `intent.md`; `intent/<change>/plan.md` is the later build plan.
+- **Who decides:** `.agents/rules/agent-owned-work.md` lists the human gates. `.github/CODEOWNERS` names who approves each path.
+- **A mistake the agent repeats:** add the correction to **Things Claude gets wrong** in `AGENTS.md`.
+- **Company policy:** the policy skills in `.agents/skills/`; `.github/CODEOWNERS` names each one's owner.

package/templates/base/.cursor/BUGBOT.md

@@ -16,10 +16,8 @@ Review pull requests against the project's agent guide and rules:
 - [Test Admission](../.agents/rules/deterministic-testing.md)
 - [Diagnostics](../.agents/rules/diagnostics-and-error-handling.md)
 - [Evidence](../.agents/rules/evidence-before-claims.md)
-- [Git Workflow](../.agents/skills/git-workflow/SKILL.md)
 - [Findings](../.agents/rules/no-suppression.md)
 - [Platform and Library First](../.agents/rules/platform-and-library-first.md)
-- [Scripts](../.agents/skills/script-driven-changes/SKILL.md)
 - [Sibling Style](../.agents/rules/single-author-style.md)
 - [Logging](../.agents/rules/structured-logging.md)
 - [TypeScript-First](../.agents/rules/typescript-first.md)

package/templates/base/.cursor/skills/sdlc/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: sdlc
+description: The front door for work in this project. Matches a request to a playbook and runs it to the next human gate. Run it with /sdlc.
+disable-model-invocation: true
+---
+
+# SDLC
+
+Do these steps in order.
+
+1. **Match the request** to the first row that fits, and read that row's file before you act.
+
+   | The request                                                                      | What to do                                                                                                                                                                                                                                           |
+   | :------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+   | A question, or a request to explain or check without changing things             | Follow [`playbooks/question.md`](playbooks/question.md).                                                                                                                                                                                             |
+   | An idea, a problem, a ticket, or an incident, whether asked for or only reported | Follow [`playbooks/plan.md`](playbooks/plan.md).                                                                                                                                                                                                     |
+   | A later step: a spec, a build, a review, a deploy, or an incident fix            | Say "This step has no playbook in `/sdlc` yet" and name the step. Name the skill that covers it when one exists: `write-spec` for a spec, `babysit-pr` for a pull request you opened. Answer what you can as `playbooks/question.md` says, and stop. |
+
+   When a request both asks a question and reports a problem, use `question` and offer `plan` in one line.
+
+2. **Do the playbook's steps yourself.** Find facts in files and commands instead of asking. Stop only where the playbook says to stop; at a step marked **Gate**, which waits for the person it names and is never skipped; before an irreversible action; or for a decision no file settles. `.agents/rules/agent-owned-work.md` lists the gates and the irreversible actions.
+3. **Write the reply in the shape below,** following the **Write replies a person can check** convention in `AGENTS.md`.
+
+## Reply shape
+
+Write every part in the language of the person's message; keep paths, commands, copied step text, and a draft file's own text as they are. For `question` and for a later step, leave out **Steps** and put the answer in its place.
+
+```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.>
+
+**Steps:**
+
+1. <the first sentence of step 1 of the playbook, copied word for word>: done | open | skip: <reason>
+2. <and so on for every numbered step of the playbook>
+
+<What the current step produces: the round of questions, or the whole draft.>
+
+**Status:** <what is done, what comes next, and which gate it waits on and for whom.>
+```
+
+A step that is not finished is `open`, including one that waits at its Gate. Use `skip` only for a step you decide never to do.
+
+When the evidence shows that the change cannot be made in this project, say so under **Request**. In the `plan` playbook, the first round then asks the one question that settles where the change belongs.
+
+"new task" starts again at step 1. "don't change anything" keeps the session on `question`.

package/templates/base/.cursor/skills/sdlc/playbooks/plan.md

@@ -0,0 +1,31 @@
+# Plan phase: write `intent.md`
+
+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. Never ask what a file or a command can tell you: the author, for one, is `git config user.name`.
+3. Interview until the originator has said four things: the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
+   - **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, each asks one thing, numbered, each with 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. Write the file in the language of the files already in `intent/`. 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`.
+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.
+6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner sets `Status: accepted.` or `Status: rejected.` and merges the pull request; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+## Template
+
+```markdown
+# Intent: <title>
+
+Author: <name> (<team>). Status: draft.
+
+## Problem
+
+## Proposed outcome
+
+## Affected users and systems
+
+## Constraints
+
+## Open questions
+```

package/templates/base/.cursor/skills/sdlc/playbooks/question.md

@@ -0,0 +1,6 @@
+# Question
+
+1. Find the facts: read the files and run read-only commands.
+2. Answer, citing `path:line` or command output for each claim, as the **Write replies a person can check** convention in `AGENTS.md` says.
+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 write an intent for this` to start the change", and stop.

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

@@ -0,0 +1,22 @@
+---
+name: sdlc-help
+description: Explains how this project's workflow runs and how to use /sdlc. It answers and starts no work. Run it with /sdlc-help.
+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 in the person's language: this command starts no work; and the message to send instead, which is `/sdlc` followed by their own words.
+2. When the topic is unclear, ask one question with these choices: how the workflow runs, starting work, who decides at each gate, fixing a mistake the agent repeats, or adjusting a 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.
+6. Write the reply as the **Write replies a person can check** convention in `AGENTS.md` says.
+
+## Map
+
+- **The loop:** intent, then spec, then plan, then build, review, and maintain. Each change keeps its files in `intent/<change>/`: `intent.md`, `spec.md`, and `plan.md` (`intent/README.md`).
+- **Starting work:** `/sdlc` matches the request to a playbook in `.agents/skills/sdlc/playbooks/`. The table in `.agents/skills/sdlc/SKILL.md` lists the playbooks this project has. The `plan` playbook writes `intent.md`; `intent/<change>/plan.md` is the later build plan.
+- **Who decides:** `.agents/rules/agent-owned-work.md` lists the human gates. `.github/CODEOWNERS` names who approves each path.
+- **A mistake the agent repeats:** add the correction to **Things Claude gets wrong** in `AGENTS.md`.
+- **Company policy:** the policy skills in `.agents/skills/`; `.github/CODEOWNERS` names each one's owner.

package/templates/base/SETUP.md

@@ -4,12 +4,12 @@ This project follows Anthropic's [AI-native SDLC Playbook](https://claude.com/re
 
 ## How a change flows
 
-1. **Plan:** the originator of an idea, a ticket, or an incident runs `/write-intent`, which interviews them and writes `intent/<change>/intent.md`. The product owner merges it with `Status: accepted.` or `Status: rejected.`
+1. **Plan:** the originator of an idea, a ticket, or an incident sends it with `/sdlc`, which interviews them and writes `intent/<change>/intent.md`. The product owner merges it with `Status: accepted.` or `Status: rejected.`
 2. **Design:** `spec.md` is written from the accepted intent with the policy skills loaded (`write-spec` skill). The product owner resolves concerns with the policy owners.
 3. **Build:** the engineer starts in plan mode, approves the plan, and commits it as `plan.md`. A tech lead approves higher-risk plans.
 4. **Test:** the session runs **Verifying your work** in `AGENTS.md`.
 5. **Review:** Claude Code Review and Bugbot review by `REVIEW.md`. A code owner approves; the agent never does.
-6. **Deploy:** `agent-production-gate.sh` gates production.
+6. **Deploy:** once `DEPLOY_ENABLED` is `true`, each push to `main` that passes CI deploys to `dev`, and the Deploy workflow promotes a commit to `uat` and then `prod`. `agent-production-gate.sh` blocks an agent's shell commands that deploy to `prod`, run a Railway command with `prod` as its environment, or push a release tag, unless a release manager started the session with `RELEASE_APPROVAL` set.
 7. **Maintain:** larger work becomes a new `intent.md`.
 
 ## 1. First commit and push
@@ -38,7 +38,7 @@ In `.github/CODEOWNERS`, add these lines in this order. GitHub uses the last mat
 ```text
 * @your-org/your-team
 /intent/ @the-product-owner
-/.agents/skills/write-intent/ @the-lead-who-signs-off-the-intent-template
+/.agents/skills/sdlc/ @the-lead-who-signs-off-the-intent-template
 /.agents/skills/brand-policy/ @the-brand-policy-owner
 /.agents/skills/security-policy/ @the-security-policy-owner
 /.agents/skills/compliance-policy/ @the-compliance-policy-owner
@@ -94,7 +94,7 @@ Also replace the owner placeholder in `.github/zizmor.yml`.
 - **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):** write the policy in `.agents/skills/<area>-policy/SKILL.md` from the owner's source of truth, then run `pnpm rules:sync`. Test that the skill triggers: ask for the relevant task in different ways and confirm the skill loads each time. The policy owner approves every later change as its code owner.
-- **Production gate (engineering leadership, with change management and compliance):** list the approvals that must survive. A person then changes `.agents/hooks/agent-production-gate.sh` to match this project's production deploy command and approval; agent settings deny the file to agents.
+- **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`.
 - **Review (tech lead):** replace `src/gen/` in `.agents/review.md` with this project's generated paths, 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/intent/README.md

@@ -3,6 +3,21 @@
 This folder is the intent home. Every change starts here as an `intent.md`, and its record stays here. Git history keeps the author, the time, and every revision of each file.
 
 - Each change has its own folder, `intent/<change>/`, where `<change>` is a short kebab-case name. The folder holds `intent.md` (Plan), then `spec.md` (Design), then `plan.md` (Build).
-- **Plan.** An idea, a ticket, or an incident becomes `intent.md`, written with the `write-intent` skill. The product owner reviews and corrects it before it is committed. Merging its pull request records the decision: `Status: accepted.` accepts it, and `Status: rejected.` rejects it.
+- **Plan.** An idea, a ticket, or an incident becomes `intent.md`, written by sending the idea with `/sdlc`, which interviews the originator. The originator corrects the draft before it is committed, and the product owner reviews it in its pull request. Merging its pull request records the decision: `Status: accepted.` accepts it, and `Status: rejected.` rejects it.
 - **Design.** The `write-spec` skill turns the accepted `intent.md` into `spec.md`, committed alongside it. The product owner reviews the spec against the idea and resolves each area of concern with its policy owner. Accepting the spec starts the build.
 - **Build.** The engineer starts in plan mode with `intent.md` and `spec.md`, and commits the approved plan as `plan.md`. When implementation departs from the plan, `plan.md` changes in the same commit.
+
+## Which file holds what
+
+The bullets above say who writes and who decides each file. What each file answers:
+
+| File        | Answers                                                                                                    |
+| :---------- | :--------------------------------------------------------------------------------------------------------- |
+| `intent.md` | The problem, the outcome wanted, the users and systems it affects, its constraints, and its open questions |
+| `spec.md`   | What to build and how it is designed: requirements, design, and areas of concern                           |
+| `plan.md`   | How to make the change: the files that change, the order of the work, and the tests that prove it          |
+
+## Where a technology choice goes
+
+- **A choice already made**, such as a required framework or service, goes into the intent's **Constraints**. The spec designs within it.
+- **A choice to weigh**, such as two libraries or two approaches, goes into the intent's **Proposed outcome** as a proposal or into its **Open questions**. The spec compares the options in its design, with sources, and the product owner accepts or corrects the choice in review.

package/templates/nestjs/AGENTS.md

@@ -36,13 +36,16 @@ If a test fails, fix the code, not the test.
 4. **Log through Nest's `Logger`.** It goes to the `ConsoleLogger` set in `src/main.ts`.
 5. **Start from the accepted spec, in plan mode.** Claude Code starts every session in plan mode (`.claude/settings.json`); in Cursor, switch to Plan Mode before the first edit. Give the plan the change's `intent/<change>/intent.md` and `spec.md`, and have it name the files that change, the order of the work, and the tests that prove it. Commit the approved plan as `intent/<change>/plan.md`. When implementation departs from the plan, update `plan.md` in the same commit.
 6. **Start a bug fix with a failing test.** Reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Then create `.git/bug-fix-in-progress`, so `.agents/hooks/agent-test-edit-gate.sh` blocks test edits, and make the test pass without editing it. Delete `.git/bug-fix-in-progress` when the fix is done.
-7. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+7. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. When a message reports a problem without asking for work, answer in a few lines and end with the message that would start the work: `/sdlc` followed by their own words. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+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. Drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Rebase and `git push --force-with-lease` only branches you own. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.
+9. **Write replies a person can check.** Reply in the language the person wrote in. Write paths from the project root, such as `README.md:12`, never from the machine's root. State as a fact only what you opened or ran in this turn, and say what you ran; mark anything else as inferred or not checked. Answer what was asked and stop: leave out tools, services, and steps the request does not need, and never hand the person a check you could run. Send nothing outside the session, such as a message to another session or a service, unless a task step says to.
 
 ## Things Claude gets wrong
 
 When Claude makes a mistake twice, add the correction here.
 
 - **Agent shell gate**: `.agents/hooks/agent-shell-gate.sh` blocks a shell command that writes to a protected path such as `.agents`, `.cursor`, `.claude/rules`, or `.husky`. It also blocks merging or approving a pull request, approving a deployment, and gh aliases, and asks the person before an irreversible git command such as a force push or a hard reset. It is a convenience, not a security boundary: CI and code-owner review are the boundary.
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` (`gh workflow run` or a workflow dispatch with `environment=prod`), a Railway CLI command that names `prod` with `-e`, `--environment`, or `railway environment`, and a release tag push, unless a release manager started the session with `RELEASE_APPROVAL` set. 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. It is a convenience, not a security boundary: the `prod` environment's required reviewers and Railway credentials are the boundary.
 
 ## Related documentation
 

package/templates/nestjs/README.md

@@ -53,7 +53,7 @@ On Vercel, the zero-configuration NestJS preset takes precedence over the `Docke
    - the `RAILWAY_SERVICE` variable: the service name;
    - the `APP_URL` variable: the public `https://` URL.
 
-   Limit `dev`, `uat`, and `prod` to the `main` branch and add required reviewers. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
+   Limit `dev`, `uat`, and `prod` to the `main` branch. Add the release managers as required reviewers on `prod` only; `dev` deploys on every push to `main`, so a reviewer there would hold each push. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
 
 3. Set the repository variable `DEPLOY_ENABLED` to `true`. Each push to `main` that passes CI then deploys to `dev`.
 4. Promote with **Actions → Deploy → Run workflow**, giving the environment and the full commit SHA. The workflow requires a successful CI run on `main` for that commit and a successful deployment to the previous environment, then waits for `/health`.

package/templates/nextjs/AGENTS.md

@@ -36,7 +36,9 @@ If a test fails, fix the code, not the test.
 4. **Read configuration from environment variables and fail when one is missing.** Document each variable in `.env.example`.
 5. **Start from the accepted spec, in plan mode.** Claude Code starts every session in plan mode (`.claude/settings.json`); in Cursor, switch to Plan Mode before the first edit. Give the plan the change's `intent/<change>/intent.md` and `spec.md`, and have it name the files that change, the order of the work, and the tests that prove it. Commit the approved plan as `intent/<change>/plan.md`. When implementation departs from the plan, update `plan.md` in the same commit.
 6. **Start a bug fix with a failing test.** Reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Then create `.git/bug-fix-in-progress`, so `.agents/hooks/agent-test-edit-gate.sh` blocks test edits, and make the test pass without editing it. Delete `.git/bug-fix-in-progress` when the fix is done.
-7. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+7. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. When a message reports a problem without asking for work, answer in a few lines and end with the message that would start the work: `/sdlc` followed by their own words. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+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. Drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Rebase and `git push --force-with-lease` only branches you own. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.
+9. **Write replies a person can check.** Reply in the language the person wrote in. Write paths from the project root, such as `README.md:12`, never from the machine's root. State as a fact only what you opened or ran in this turn, and say what you ran; mark anything else as inferred or not checked. Answer what was asked and stop: leave out tools, services, and steps the request does not need, and never hand the person a check you could run. Send nothing outside the session, such as a message to another session or a service, unless a task step says to.
 
 ## Things Claude gets wrong
 
@@ -44,6 +46,7 @@ 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.
 - **Agent shell gate**: `.agents/hooks/agent-shell-gate.sh` blocks a shell command that writes to a protected path such as `.agents`, `.cursor`, `.claude/rules`, or `.husky`. It also blocks merging or approving a pull request, approving a deployment, and gh aliases, and asks the person before an irreversible git command such as a force push or a hard reset. It is a convenience, not a security boundary: CI and code-owner review are the boundary.
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` (`gh workflow run` or a workflow dispatch with `environment=prod`), a Railway CLI command that names `prod` with `-e`, `--environment`, or `railway environment`, and a release tag push, unless a release manager started the session with `RELEASE_APPROVAL` set. 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. It is a convenience, not a security boundary: the `prod` environment's required reviewers and Railway credentials are the boundary.
 
 ## Related documentation
 

package/templates/nextjs/README.md

@@ -49,7 +49,7 @@ On Vercel, deploy without the image; the Next.js preset takes precedence over th
    - the `RAILWAY_SERVICE` variable: the service name;
    - the `APP_URL` variable: the public `https://` URL.
 
-   Limit `dev`, `uat`, and `prod` to the `main` branch and add required reviewers. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
+   Limit `dev`, `uat`, and `prod` to the `main` branch. Add the release managers as required reviewers on `prod` only; `dev` deploys on every push to `main`, so a reviewer there would hold each push. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
 
 3. Set the repository variable `DEPLOY_ENABLED` to `true`. Each push to `main` that passes CI then deploys to `dev`.
 4. Promote with **Actions → Deploy → Run workflow**, giving the environment and the full commit SHA. The workflow requires a successful CI run on `main` for that commit and a successful deployment to the previous environment, then waits for `/health`.

package/templates/nodejs/AGENTS.md

@@ -34,13 +34,16 @@ If a test fails, fix the code, not the test.
 3. **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`.
 4. **Start from the accepted spec, in plan mode.** Claude Code starts every session in plan mode (`.claude/settings.json`); in Cursor, switch to Plan Mode before the first edit. Give the plan the change's `intent/<change>/intent.md` and `spec.md`, and have it name the files that change, the order of the work, and the tests that prove it. Commit the approved plan as `intent/<change>/plan.md`. When implementation departs from the plan, update `plan.md` in the same commit.
 5. **Start a bug fix with a failing test.** Reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Then create `.git/bug-fix-in-progress`, so `.agents/hooks/agent-test-edit-gate.sh` blocks test edits, and make the test pass without editing it. Delete `.git/bug-fix-in-progress` when the fix is done.
-6. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+6. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. When a message reports a problem without asking for work, answer in a few lines and end with the message that would start the work: `/sdlc` followed by their own words. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+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. Drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Rebase and `git push --force-with-lease` only branches you own. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.
+8. **Write replies a person can check.** Reply in the language the person wrote in. Write paths from the project root, such as `README.md:12`, never from the machine's root. State as a fact only what you opened or ran in this turn, and say what you ran; mark anything else as inferred or not checked. Answer what was asked and stop: leave out tools, services, and steps the request does not need, and never hand the person a check you could run. Send nothing outside the session, such as a message to another session or a service, unless a task step says to.
 
 ## Things Claude gets wrong
 
 When Claude makes a mistake twice, add the correction here.
 
 - **Agent shell gate**: `.agents/hooks/agent-shell-gate.sh` blocks a shell command that writes to a protected path such as `.agents`, `.cursor`, `.claude/rules`, or `.husky`. It also blocks merging or approving a pull request, approving a deployment, and gh aliases, and asks the person before an irreversible git command such as a force push or a hard reset. It is a convenience, not a security boundary: CI and code-owner review are the boundary.
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` (`gh workflow run` or a workflow dispatch with `environment=prod`), a Railway CLI command that names `prod` with `-e`, `--environment`, or `railway environment`, and a release tag push, unless a release manager started the session with `RELEASE_APPROVAL` set. 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. It is a convenience, not a security boundary: the `prod` environment's required reviewers and Railway credentials are the boundary.
 
 ## Related documentation
 

package/templates/nodejs/README.md

@@ -49,7 +49,7 @@ docker run --env PORT=3000 --publish 3000:3000 app
    - the `RAILWAY_SERVICE` variable: the service name;
    - the `APP_URL` variable: the public `https://` URL.
 
-   Limit `dev`, `uat`, and `prod` to the `main` branch and add required reviewers. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
+   Limit `dev`, `uat`, and `prod` to the `main` branch. Add the release managers as required reviewers on `prod` only; `dev` deploys on every push to `main`, so a reviewer there would hold each push. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
 
 3. Set the repository variable `DEPLOY_ENABLED` to `true`. Each push to `main` that passes CI then deploys to `dev`.
 4. Promote with **Actions → Deploy → Run workflow**, giving the environment and the full commit SHA. The workflow requires a successful CI run on `main` for that commit and a successful deployment to the previous environment, then waits for `/health`.

package/templates/payload/AGENTS.md

@@ -39,7 +39,9 @@ If a test fails, fix the code, not the test.
 5. **Read configuration through `requireEnvironment` in `src/environment.ts`.** Document each variable in `.env.example`.
 6. **Start from the accepted spec, in plan mode.** Claude Code starts every session in plan mode (`.claude/settings.json`); in Cursor, switch to Plan Mode before the first edit. Give the plan the change's `intent/<change>/intent.md` and `spec.md`, and have it name the files that change, the order of the work, and the tests that prove it. Commit the approved plan as `intent/<change>/plan.md`. When implementation departs from the plan, update `plan.md` in the same commit.
 7. **Start a bug fix with a failing test.** Reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Then create `.git/bug-fix-in-progress`, so `.agents/hooks/agent-test-edit-gate.sh` blocks test edits, and make the test pass without editing it. Delete `.git/bug-fix-in-progress` when the fix is done.
-8. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+8. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. When a message reports a problem without asking for work, answer in a few lines and end with the message that would start the work: `/sdlc` followed by their own words. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+9. **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. Drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Rebase and `git push --force-with-lease` only branches you own. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.
+10. **Write replies a person can check.** Reply in the language the person wrote in. Write paths from the project root, such as `README.md:12`, never from the machine's root. State as a fact only what you opened or ran in this turn, and say what you ran; mark anything else as inferred or not checked. Answer what was asked and stop: leave out tools, services, and steps the request does not need, and never hand the person a check you could run. Send nothing outside the session, such as a message to another session or a service, unless a task step says to.
 
 ## Things Claude gets wrong
 
@@ -47,6 +49,7 @@ 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`.
 - **Agent shell gate**: `.agents/hooks/agent-shell-gate.sh` blocks a shell command that writes to a protected path such as `.agents`, `.cursor`, `.claude/rules`, or `.husky`. It also blocks merging or approving a pull request, approving a deployment, and gh aliases, and asks the person before an irreversible git command such as a force push or a hard reset. It is a convenience, not a security boundary: CI and code-owner review are the boundary.
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` (`gh workflow run` or a workflow dispatch with `environment=prod`), a Railway CLI command that names `prod` with `-e`, `--environment`, or `railway environment`, and a release tag push, unless a release manager started the session with `RELEASE_APPROVAL` set. 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. It is a convenience, not a security boundary: the `prod` environment's required reviewers and Railway credentials are the boundary.
 
 ## Related documentation
 

package/templates/payload/README.md

@@ -73,7 +73,7 @@ On Vercel, deploy without the image; the Next.js preset takes precedence over th
    - the `RAILWAY_SERVICE` variable: the service name;
    - the `APP_URL` variable: the public `https://` URL.
 
-   Limit `dev`, `uat`, and `prod` to the `main` branch and add required reviewers. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
+   Limit `dev`, `uat`, and `prod` to the `main` branch. Add the release managers as required reviewers on `prod` only; `dev` deploys on every push to `main`, so a reviewer there would hold each push. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
 
 3. Set the repository variable `DEPLOY_ENABLED` to `true`. Each push to `main` that passes CI then deploys to `dev`.
 4. Promote with **Actions → Deploy → Run workflow**, giving the environment and the full commit SHA. The workflow requires a successful CI run on `main` for that commit and a successful deployment to the previous environment, then waits for `/health`.

package/templates/turborepo/AGENTS.md

@@ -41,7 +41,9 @@ If a test fails, fix the code, not the test.
 5. **Read backoffice configuration through `requireEnvironment` in `apps/backoffice/src/environment.ts`.** Document each variable in `.env.example`.
 6. **Start from the accepted spec, in plan mode.** Claude Code starts every session in plan mode (`.claude/settings.json`); in Cursor, switch to Plan Mode before the first edit. Give the plan the change's `intent/<change>/intent.md` and `spec.md`, and have it name the files that change, the order of the work, and the tests that prove it. Commit the approved plan as `intent/<change>/plan.md`. When implementation departs from the plan, update `plan.md` in the same commit.
 7. **Start a bug fix with a failing test.** Reproduce the bug as a test, run it, and confirm it fails for the reason you expect. Commit that test. Then create `.git/bug-fix-in-progress`, so `.agents/hooks/agent-test-edit-gate.sh` blocks test edits, and make the test pass without editing it. Delete `.git/bug-fix-in-progress` when the fix is done.
-8. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+8. **Start work only when a person asks or a trigger runs it, and stop only at the human gates, before an irreversible action, or for a decision only a person can make.** A question or a statement gets an answer, not a file, a commit, or a pull request. When a message reports a problem without asking for work, answer in a few lines and end with the message that would start the work: `/sdlc` followed by their own words. Once a task starts, carry it to the next gate without asking; `.agents/rules/agent-owned-work.md` lists the gates.
+9. **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. Drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Rebase and `git push --force-with-lease` only branches you own. Never merge a pull request: a person merges it with `--squash` after code owner approval, bottom-up for a stack of pull requests.
+10. **Write replies a person can check.** Reply in the language the person wrote in. Write paths from the project root, such as `README.md:12`, never from the machine's root. State as a fact only what you opened or ran in this turn, and say what you ran; mark anything else as inferred or not checked. Answer what was asked and stop: leave out tools, services, and steps the request does not need, and never hand the person a check you could run. Send nothing outside the session, such as a message to another session or a service, unless a task step says to.
 
 ## Things Claude gets wrong
 
@@ -50,6 +52,7 @@ 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`.
 - **Agent shell gate**: `.agents/hooks/agent-shell-gate.sh` blocks a shell command that writes to a protected path such as `.agents`, `.cursor`, `.claude/rules`, or `.husky`. It also blocks merging or approving a pull request, approving a deployment, and gh aliases, and asks the person before an irreversible git command such as a force push or a hard reset. It is a convenience, not a security boundary: CI and code-owner review are the boundary.
+- **Production gate**: `.agents/hooks/agent-production-gate.sh` blocks a shell command that deploys to `prod` (`gh workflow run` or a workflow dispatch with `environment=prod`), a Railway CLI command that names `prod` with `-e`, `--environment`, or `railway environment`, and a release tag push, unless a release manager started the session with `RELEASE_APPROVAL` set. 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. It is a convenience, not a security boundary: the `prod` environment's required reviewers and Railway credentials are the boundary.
 
 ## Related documentation
 

package/templates/turborepo/README.md

@@ -79,7 +79,7 @@ On Vercel, deploy an app without its image. The Next.js preset takes precedence
    - the `APP_URL` variable: the public Next.js `https://` URL;
    - the `BACKOFFICE_URL` variable: the public backoffice `https://` URL.
 
-   Limit `dev`, `uat`, and `prod` to the `main` branch and add required reviewers. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
+   Limit `dev`, `uat`, and `prod` to the `main` branch. Add the release managers as required reviewers on `prod` only; `dev` deploys on every push to `main`, so a reviewer there would hold each push. Environment secrets and variables in a private repository need GitHub Pro, Team, or Enterprise; required reviewers in a private repository need GitHub Enterprise.
 
 3. Set the repository variable `DEPLOY_ENABLED` to `true`. Each push to `main` that passes CI then deploys to `dev`. The workflow compares the commit with the last GitHub deployment to that environment and runs `railway up` only for services whose packages changed. A promotion through `uat` or `prod` uses the same comparison against the commit last deployed there, so several commits still ship every changed service. The first deploy to an environment ships both services.
 4. Promote with **Actions → Deploy → Run workflow**, giving the environment and the full commit SHA. The workflow requires a successful CI run on `main` for that commit and a successful deployment to the previous environment, then waits for `/health` on each service it uploaded.

package/templates/base/.agents/skills/git-workflow/SKILL.md

@@ -1,15 +0,0 @@
----
-name: git-workflow
-description: Trunk-based branches, commits, and pull requests. Use when creating a branch, committing, pushing, or opening, updating, or merging a pull request.
----
-
-# Git Workflow
-
-The repository uses trunk-based development.
-
-- Branch from the latest `origin/main`, in a worktree or a new branch named `<type>/<short-description>`. `main` is the only long-lived branch. The Git hooks block commits and pushes on it, except the first commit and push that create `main` in a new repository.
-- Write commit messages in the format that `@next-friday/commitlint-config-friday` defines. The `commit-msg` hook rejects anything else.
-- When work ends in a pull request, push its branch and open the pull request ready for review without asking. CI skips drafts. Work that does not end in one, such as an investigation or a prototype, opens none.
-- Fill the pull request body from `.github/pull_request_template.md`.
-- After you open a pull request, report its URL and drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Never approve or merge it: a code owner approves, and a person merges with `--squash`, bottom-up for a stack.
-- Rebase and `git push --force-with-lease` only branches you own.

package/templates/base/.agents/skills/script-driven-changes/SKILL.md

@@ -1,12 +0,0 @@
----
-name: script-driven-changes
-description: Change many files with a script, not by hand. Use when a change repeats one pattern across more than a few files, or needs a one-off script.
----
-
-# Scripts
-
-When a change repeats one pattern across more than a few files, run a script. Derive facts from the toolchain (TypeScript compiler API, `git`), not by reading files by eye. Edit by hand when the change needs judgment in one place.
-
-Commit a script when a reviewer needs to rerun it or when the work outlives the session, and add it as a `package.json` script so knip counts it as an entry. Keep any other one-off script in a temporary directory outside the repository, and remove a committed script when its workflow ends. Fail on unmapped input. Back up before a destructive run.
-
-Print summaries: counts, first errors. Verify what owned checks omit, such as the running app.

package/templates/base/.agents/skills/write-intent/SKILL.md

@@ -1,31 +0,0 @@
----
-name: write-intent
-description: Write intent.md, the proto-spec that starts a change, by interviewing the originator. Run it with /write-intent.
-disable-model-invocation: true
----
-
-# Write intent.md
-
-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. Interview them in rounds until no decision is left to guess. Each round, ask every question whose prerequisites are already settled, numbered, each with your recommended answer, worded so "yes" accepts it. Then wait for the answers, and build the next round on them. Aim at the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
-3. Find facts yourself: read the code, the docs, and the existing `intent/` folders before you ask, and never ask what a file can tell you. Put only decisions to the originator. When they cannot answer one yet, record it as an open question instead of guessing.
-4. Write the result as `intent/<change>/intent.md`, where `<change>` is a short kebab-case name, using the template below. Show the whole draft, and ask whether it matches what they meant. Revise it until they say it does.
-5. When the originator confirms the draft, commit `intent.md` and open a pull request. The product owner accepts it by merging the pull request, or rejects it by setting `Status: rejected.` and merging.
-
-## Template
-
-```markdown
-# Intent: <title>
-
-Author: <name> (<team>). Status: draft.
-
-## Problem
-
-## Proposed outcome
-
-## Affected users and systems
-
-## Constraints
-
-## Open questions
-```

package/templates/base/.claude/skills/git-workflow/SKILL.md

@@ -1,15 +0,0 @@
----
-name: git-workflow
-description: Trunk-based branches, commits, and pull requests. Use when creating a branch, committing, pushing, or opening, updating, or merging a pull request.
----
-
-# Git Workflow
-
-The repository uses trunk-based development.
-
-- Branch from the latest `origin/main`, in a worktree or a new branch named `<type>/<short-description>`. `main` is the only long-lived branch. The Git hooks block commits and pushes on it, except the first commit and push that create `main` in a new repository.
-- Write commit messages in the format that `@next-friday/commitlint-config-friday` defines. The `commit-msg` hook rejects anything else.
-- When work ends in a pull request, push its branch and open the pull request ready for review without asking. CI skips drafts. Work that does not end in one, such as an investigation or a prototype, opens none.
-- Fill the pull request body from `.github/pull_request_template.md`.
-- After you open a pull request, report its URL and drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Never approve or merge it: a code owner approves, and a person merges with `--squash`, bottom-up for a stack.
-- Rebase and `git push --force-with-lease` only branches you own.

package/templates/base/.claude/skills/script-driven-changes/SKILL.md

@@ -1,12 +0,0 @@
----
-name: script-driven-changes
-description: Change many files with a script, not by hand. Use when a change repeats one pattern across more than a few files, or needs a one-off script.
----
-
-# Scripts
-
-When a change repeats one pattern across more than a few files, run a script. Derive facts from the toolchain (TypeScript compiler API, `git`), not by reading files by eye. Edit by hand when the change needs judgment in one place.
-
-Commit a script when a reviewer needs to rerun it or when the work outlives the session, and add it as a `package.json` script so knip counts it as an entry. Keep any other one-off script in a temporary directory outside the repository, and remove a committed script when its workflow ends. Fail on unmapped input. Back up before a destructive run.
-
-Print summaries: counts, first errors. Verify what owned checks omit, such as the running app.

package/templates/base/.claude/skills/write-intent/SKILL.md

@@ -1,31 +0,0 @@
----
-name: write-intent
-description: Write intent.md, the proto-spec that starts a change, by interviewing the originator. Run it with /write-intent.
-disable-model-invocation: true
----
-
-# Write intent.md
-
-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. Interview them in rounds until no decision is left to guess. Each round, ask every question whose prerequisites are already settled, numbered, each with your recommended answer, worded so "yes" accepts it. Then wait for the answers, and build the next round on them. Aim at the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
-3. Find facts yourself: read the code, the docs, and the existing `intent/` folders before you ask, and never ask what a file can tell you. Put only decisions to the originator. When they cannot answer one yet, record it as an open question instead of guessing.
-4. Write the result as `intent/<change>/intent.md`, where `<change>` is a short kebab-case name, using the template below. Show the whole draft, and ask whether it matches what they meant. Revise it until they say it does.
-5. When the originator confirms the draft, commit `intent.md` and open a pull request. The product owner accepts it by merging the pull request, or rejects it by setting `Status: rejected.` and merging.
-
-## Template
-
-```markdown
-# Intent: <title>
-
-Author: <name> (<team>). Status: draft.
-
-## Problem
-
-## Proposed outcome
-
-## Affected users and systems
-
-## Constraints
-
-## Open questions
-```

package/templates/base/.cursor/skills/git-workflow/SKILL.md

@@ -1,15 +0,0 @@
----
-name: git-workflow
-description: Trunk-based branches, commits, and pull requests. Use when creating a branch, committing, pushing, or opening, updating, or merging a pull request.
----
-
-# Git Workflow
-
-The repository uses trunk-based development.
-
-- Branch from the latest `origin/main`, in a worktree or a new branch named `<type>/<short-description>`. `main` is the only long-lived branch. The Git hooks block commits and pushes on it, except the first commit and push that create `main` in a new repository.
-- Write commit messages in the format that `@next-friday/commitlint-config-friday` defines. The `commit-msg` hook rejects anything else.
-- When work ends in a pull request, push its branch and open the pull request ready for review without asking. CI skips drafts. Work that does not end in one, such as an investigation or a prototype, opens none.
-- Fill the pull request body from `.github/pull_request_template.md`.
-- After you open a pull request, report its URL and drive it until it is green and waits only on code owner approval, as `babysit-pr` describes. Never approve or merge it: a code owner approves, and a person merges with `--squash`, bottom-up for a stack.
-- Rebase and `git push --force-with-lease` only branches you own.

package/templates/base/.cursor/skills/script-driven-changes/SKILL.md

@@ -1,12 +0,0 @@
----
-name: script-driven-changes
-description: Change many files with a script, not by hand. Use when a change repeats one pattern across more than a few files, or needs a one-off script.
----
-
-# Scripts
-
-When a change repeats one pattern across more than a few files, run a script. Derive facts from the toolchain (TypeScript compiler API, `git`), not by reading files by eye. Edit by hand when the change needs judgment in one place.
-
-Commit a script when a reviewer needs to rerun it or when the work outlives the session, and add it as a `package.json` script so knip counts it as an entry. Keep any other one-off script in a temporary directory outside the repository, and remove a committed script when its workflow ends. Fail on unmapped input. Back up before a destructive run.
-
-Print summaries: counts, first errors. Verify what owned checks omit, such as the running app.

package/templates/base/.cursor/skills/write-intent/SKILL.md

@@ -1,31 +0,0 @@
----
-name: write-intent
-description: Write intent.md, the proto-spec that starts a change, by interviewing the originator. Run it with /write-intent.
-disable-model-invocation: true
----
-
-# Write intent.md
-
-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. Interview them in rounds until no decision is left to guess. Each round, ask every question whose prerequisites are already settled, numbered, each with your recommended answer, worded so "yes" accepts it. Then wait for the answers, and build the next round on them. Aim at the problem (who, how often, and a number with its source), the outcome as the user would see it, the constraints, and what is out of scope.
-3. Find facts yourself: read the code, the docs, and the existing `intent/` folders before you ask, and never ask what a file can tell you. Put only decisions to the originator. When they cannot answer one yet, record it as an open question instead of guessing.
-4. Write the result as `intent/<change>/intent.md`, where `<change>` is a short kebab-case name, using the template below. Show the whole draft, and ask whether it matches what they meant. Revise it until they say it does.
-5. When the originator confirms the draft, commit `intent.md` and open a pull request. The product owner accepts it by merging the pull request, or rejects it by setting `Status: rejected.` and merging.
-
-## Template
-
-```markdown
-# Intent: <title>
-
-Author: <name> (<team>). Status: draft.
-
-## Problem
-
-## Proposed outcome
-
-## Affected users and systems
-
-## Constraints
-
-## Open questions
-```