@next-friday/create-app 6.0.2 → 7.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@next-friday/create-app",
-  "version": "6.0.2",
+  "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,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 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`.
@@ -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.
 

package/templates/nestjs/AGENTS.md

@@ -36,7 +36,9 @@ 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
 

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
 

package/templates/nodejs/AGENTS.md

@@ -34,7 +34,9 @@ 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
 

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
 

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
 

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
-```