@next-friday/create-app 6.0.2 → 7.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@next-friday/create-app",
-  "version": "6.0.2",
+  "version": "7.1.0",
   "description": "Create a Next Friday project from a template.",
   "keywords": [
     "create",
@@ -74,6 +74,7 @@
     "format": "prettier --write --cache .",
     "format:check": "prettier --check --cache . && editorconfig-checker",
     "gates:check": "node scripts/check-agent-gates.ts",
+    "human-gates:check": "node scripts/check-human-gates.ts",
     "knip": "knip",
     "lint": "eslint . --fix --cache --max-warnings=0 --no-inline-config",
     "lint:check": "eslint . --cache --max-warnings=0 --no-inline-config",
@@ -86,6 +87,6 @@
     "test:coverage": "vitest run --coverage",
     "test:watch": "vitest",
     "typecheck": "tsc --noEmit -p tsconfig.json",
-    "verify": "pnpm suppressions:check && pnpm rules:check && pnpm gates:check && pnpm lint:check && pnpm format:check && pnpm sort-package-json:check && pnpm typecheck && pnpm test:coverage && pnpm knip && pnpm build && pnpm check:publint"
+    "verify": "pnpm suppressions:check && pnpm rules:check && pnpm gates:check && pnpm human-gates:check && pnpm lint:check && pnpm format:check && pnpm sort-package-json:check && pnpm typecheck && pnpm test:coverage && pnpm knip && pnpm build && pnpm check:publint"
   }
 }

package/templates/base/.agents/rules/constitution-changes.md

@@ -2,4 +2,4 @@
 
 The constitution is the set of files that agent settings deny to agents: rules, hooks, lint, format, and commit configuration, and the agent settings themselves. It is company policy.
 
-A developer changes the constitution through a dedicated issue, never inside a feature pull request. When a task needs a constitution change, propose it to the user, reference that issue, and wait for it to merge before the task depends on it.
+The constitution changes in a pull request like any other change, and a code owner approves it in review. Agent settings stop an agent from editing these files. When a task needs a constitution change, write the exact new text and the files it goes in on the pull request; a person commits it to that branch.

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,33 @@
+# 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`. 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 `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+
+## 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,8 @@
+# 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.
+
+**Next:** none; the person; when they send a new message.

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,33 @@
+# 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`. 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 `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+
+## 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,8 @@
+# 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.
+
+**Next:** none; the person; when they send a new message.

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,33 @@
+# 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`. 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 `AGENTS.md` says for branches and pull requests.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+
+**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+
+## 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,8 @@
+# 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.
+
+**Next:** none; the person; when they send a new message.

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,7 +4,7 @@ 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 accepts it by merging it with `Status: accepted.`, or rejects it by closing its pull request.
 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`.
@@ -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

package/templates/base/intent/README.md

@@ -3,7 +3,7 @@
 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.