@next-friday/create-app 9.2.1 → 9.3.0

package/templates/base/.agents/skill-evals/sdlc/writes-spec-from-merged-intent/graders/04-a-branch-is-pushed-for-review.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-A new branch holding `spec.md` is pushed, and the reply either gives the pull request URL or says no pull request could be opened and names the branch

package/templates/base/.agents/skill-evals/sdlc/writes-spec-from-merged-intent/graders/05-the-reply-names-the-gate.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply names the gate that waits on the product owner

package/templates/base/.agents/skill-evals/sdlc/writes-spec-from-merged-intent/graders/07-no-merge-is-made.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-No pull request is merged

package/templates/base/.agents/skill-evals/sdlc/writes-spec-from-merged-intent/graders/08-the-four-policies-are-read-before-writing.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The trace shows the agent read the SKILL.md of each of the four policies (brand, security, compliance, and UX) before it wrote the Policies section

package/templates/base/.agents/skill-evals/sdlc/writes-spec-from-merged-intent/prompt.md

@@ -1,8 +0,0 @@
----
-tags: [skill-creator]
-max_turns: 30
-timeout_seconds: 900
-allowed_tools: [Read, Glob, Grep, Skill, Write, Edit, Bash]
----
-
-/sdlc write the spec for intent/csv-export/intent.md

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/case.yaml

@@ -1,10 +0,0 @@
-schema_version: "1.1"
-name: explains-how-to-start-work
-expected_outcome: |
-  The agent explains how to start work, gives one message the person can send as is, and lists the files the answer came from. It starts no work.
-timeout_seconds: 600
-checks:
-  - reply_matches: "/sdlc"
-  - no_file_changes
-  - no_new_commits
-  - reply_lacks: '(?:^|[\s`("''])/(?:home|tmp|root|Users|var|private)/'

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/graders/01-the-reply-says-that-work.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply says that work starts by sending the request with `/sdlc`

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/graders/02-the-reply-gives-one-example.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply gives one example message the person can send as is

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/graders/03-the-reply-lists-the-project.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply lists the project files the answer came from

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/graders/04-no-file-is-created-or.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-No file is created or changed and no commit is made

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/graders/06-every-path-in-the-reply.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-Every path in the reply starts from the project root; none starts from the machine's root

package/templates/base/.agents/skill-evals/sdlc-help/explains-how-to-start-work/prompt.md

@@ -1,8 +0,0 @@
----
-tags: [skill-creator]
-max_turns: 20
-timeout_seconds: 600
-allowed_tools: [Read, Glob, Grep, Skill, Write, Edit, Bash]
----
-
-/sdlc-help how do I start new work

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/case.yaml

@@ -1,9 +0,0 @@
-schema_version: "1.1"
-name: unknown-playbook-is-not-invented
-expected_outcome: |
-  The project has no rollback playbook. The agent says so and does not describe one.
-timeout_seconds: 600
-checks:
-  - no_file_changes
-  - no_new_commits
-  - reply_lacks: '(?:^|[\s`("''])/(?:home|tmp|root|Users|var|private)/'

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/graders/01-the-reply-says-that-this.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply says that this project has no rollback playbook in /sdlc

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/graders/02-the-reply-does-not-describe.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-After saying so, the reply stops or offers one next step; it does not go on to give rollback instructions

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/graders/03-no-file-is-created-or.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-No file is created or changed and no commit is made

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/graders/05-every-path-in-the-reply.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-Every path in the reply starts from the project root; none starts from the machine's root

package/templates/base/.agents/skill-evals/sdlc-help/unknown-playbook-is-not-invented/prompt.md

@@ -1,8 +0,0 @@
----
-tags: [skill-creator]
-max_turns: 20
-timeout_seconds: 600
-allowed_tools: [Read, Glob, Grep, Skill, Write, Edit, Bash]
----
-
-/sdlc-help how do I use the rollback playbook

package/templates/base/.agents/skill-evals/sdlc-help/work-request-is-sent-to-sdlc/case.yaml

@@ -1,10 +0,0 @@
-schema_version: "1.1"
-name: work-request-is-sent-to-sdlc
-expected_outcome: |
-  The message asks for work. The agent says to send it with /sdlc and changes nothing.
-timeout_seconds: 600
-checks:
-  - reply_matches: "/sdlc"
-  - no_file_changes
-  - no_new_commits
-  - reply_lacks: '(?:^|[\s`("''])/(?:home|tmp|root|Users|var|private)/'

package/templates/base/.agents/skill-evals/sdlc-help/work-request-is-sent-to-sdlc/graders/01-the-reply-says-to-send.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-The reply says to send the request with `/sdlc` instead

package/templates/base/.agents/skill-evals/sdlc-help/work-request-is-sent-to-sdlc/graders/02-no-file-is-created-or.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-No file is created or changed and no commit is made

package/templates/base/.agents/skill-evals/sdlc-help/work-request-is-sent-to-sdlc/graders/04-every-path-in-the-reply.md

@@ -1,7 +0,0 @@
----
-type: llm
-focus: trace
-weight: 1
----
-
-Every path in the reply starts from the project root; none starts from the machine's root

package/templates/base/.agents/skill-evals/sdlc-help/work-request-is-sent-to-sdlc/prompt.md

@@ -1,8 +0,0 @@
----
-tags: [skill-creator]
-max_turns: 20
-timeout_seconds: 600
-allowed_tools: [Read, Glob, Grep, Skill, Write, Edit, Bash]
----
-
-/sdlc-help fix the bug on the login page

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

@@ -1,54 +0,0 @@
----
-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 something without changing anything                                                 | Follow [`playbooks/question.md`](playbooks/question.md).                                                                       |
-   | A spec for an intent, or a path to an `intent.md`                                                                       | Follow [`playbooks/design.md`](playbooks/design.md).                                                                           |
-   | A build for a spec, a path to a `spec.md`, or a plan the engineer accepted                                              | Follow [`playbooks/build.md`](playbooks/build.md).                                                                             |
-   | A review or check of a pull request or a branch, a failing check on a pull request, or a pull request to drive to green | Follow [`playbooks/review.md`](playbooks/review.md).                                                                           |
-   | A deploy, a promotion to an environment, or a release to production                                                     | Follow [`playbooks/deploy.md`](playbooks/deploy.md).                                                                           |
-   | A finding sent by a job, a monitor, or a trigger, or one the message says no person can answer questions about          | Follow [`playbooks/maintain.md`](playbooks/maintain.md).                                                                       |
-   | A defect in behaviour that already exists, which a failing test can show, to fix                                        | Follow [`playbooks/fix.md`](playbooks/fix.md).                                                                                 |
-   | An idea, a problem, a ticket, or an incident that a person describes, whether asked for or only reported                | Follow [`playbooks/plan.md`](playbooks/plan.md).                                                                               |
-   | A pull request to open for the current branch                                                                           | Follow [`playbooks/open-pr.md`](playbooks/open-pr.md).                                                                         |
-   | Anything else                                                                                                           | Say which of the rows above is closest and why it does not fit, 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. A problem reported with `/sdlc` is the person's ask for `plan`.
-
-2. **Open the task list** when the session offers a task-list tool. Its first items are the matched playbook's numbered steps, copied word for word, before any other task. A step you do not do stays in the list with `skip: <reason>`. Use `skip` only for a step you decide never to do. A step marked **Gate** is never skipped. When the session offers no such tool, the steps go in the reply instead, under **Steps**, and are never left out, except for `question`. When a playbook's **Next** line chains another playbook, add that playbook's steps when you start it.
-3. **Do the playbook's steps yourself,** stopping only as `.agents/rules/agent-owned-work.md` says. At a step marked **Gate**, wait for the person it names. When a playbook's **Next** line says an agent runs the next file "in the same turn", read that file and continue without asking; otherwise stop at the Gate. Mark each step done in the task list as you finish it.
-4. **Write the reply in the shape below.**
-
-## Reply shape
-
-Write the reply as the **Write replies a person can check** convention in `AGENTS.md` says, even when the message also holds a command, a path, or English technical terms. Only paths, commands, and a draft file's own text stay as they are.
-
-```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:** <only when the session has no task-list tool, and never for the `question` playbook. One line for each numbered step of the playbook: `1. <the step, copied word for word>: done | open | skip: <reason>`. When the turn ran more than one playbook, one list for each, under its file name on a line of its own, such as `playbooks/build.md`.>
-
-**Checks:** <only when a step ran checks, and never for the `question` playbook. Each command, then the lines of its output that show the result, copied from the output.>
-
-<What the current step produces: the round of questions, or the whole draft. For a question or a request no row fits, the answer.>
-
-**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 at its Gate.
-
-A reply that ends before a **Gate** step says which step stopped it and why. "Waiting for an instruction" is not a reason.
-
-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/build.md

@@ -1,46 +0,0 @@
-# Build phase: plan, then implement
-
-This playbook turns a merged spec into a plan the engineer accepts, and then into working code.
-
-1. Find the change: the `intent/<change>/` folder whose `spec.md` or `plan.md` the request names. Its `spec.md` must be on the default branch beside its `intent.md`. In each case below, say only that, in two or three lines, and stop: write no file.
-   - The request names no change, or the folder has no `spec.md` on any branch: list each `intent/*/` on the default branch that has a `spec.md` and no `plan.md`, or say that there is none.
-   - The spec exists only on another branch: say that the spec is not merged yet, and name that branch.
-   - `intent/<change>/plan.md` is already on the default branch: say that the plan is merged, name the file, and say that the change is built only when each requirement of `spec.md` is checked against the tree.
-
-   When the request is a bug fix with no spec, none of these cases applies: follow `.agents/skills/sdlc/playbooks/fix.md` instead.
-
-2. When `intent/<change>/plan.md` exists on a branch that is not merged, check out that branch. When the request says the plan is accepted, go to step 6. Otherwise show that plan and go to step 5.
-3. Read `intent.md`, `spec.md`, the four policies listed in `.agents/skills/sdlc/playbooks/design.md` step 2, and the code the change touches. Then interview the engineer until they have said four things: the files the change touches, the order of the work, the tests that prove it, and each option they rule out.
-   - **When all four are already said, in the request or in the files, go to step 4 in the same turn.**
-   - **When one is missing, ask and stop.** Write no plan in that turn. Ask in rounds, as step 3 of `.agents/skills/sdlc/playbooks/plan.md` does: numbered questions, each with a recommended answer or "No recommendation". Wait for the answers, and build the next round on them.
-4. Write the plan from the template below. Use exactly the template's headings. The date in the title is the date of the last commit to `intent/<change>/intent.md`: `git log -1 --format=%cs -- intent/<change>/intent.md`. An engineer who has never seen this conversation must be able to implement the change from the plan alone.
-   - **Files that change:** every file, marked new, changed, or deleted, with one line on what it does afterwards.
-   - **Order of work:** numbered steps. Each ends with the check that proves it.
-   - **Risks:** what the change could break, which step is the riskiest, and each option you chose not to take and why.
-   - **Proof:** the tests and commands that show every requirement of the spec is met, by requirement number, and the test or review step for each policy requirement the spec cites.
-
-   Show the whole plan and name the file only as `intent/<change>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
-
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could build from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes. When the spec classes the change as higher risk, say that a tech lead or an architect accepts the plan with the engineer.
-6. Create the branch as `AGENTS.md` says, unless step 2 checked one out. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5 or whom the request names, and commit `intent/<change>/plan.md` before any other change. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged.
-7. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow **Start a bug fix with a failing test** in `AGENTS.md`: commit the test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
-8. Run every check under **Verifying your work** in `AGENTS.md` and keep the output. Every check must pass: fix the code, and never skip, delete, or weaken a test. Then look for `.claude/agents/verifier.md` or `.cursor/agents/verifier.md`: when it exists, run the `verifier` subagent and fix what it reports; when you cannot start a subagent, do what that file says yourself. For UI work, when `.mcp.json` lists a `playwright` server, also close the loop with a visual check: start the app, give the browser tool the page and the mock the spec or the request names, screenshot, compare, and adjust, and repeat until it matches; two or three rounds is normal. When a check cannot run in this session, say which one and why, and never report it as passed.
-9. Go on in the same turn, without asking: follow `.agents/skills/sdlc/playbooks/open-pr.md`, and then `.agents/skills/sdlc/playbooks/review.md`. Pushing the branch and opening the pull request are part of this task.
-
-**Next:** `.agents/skills/sdlc/playbooks/open-pr.md`; an agent; in the same turn, as soon as step 8 passes.
-
-## Template
-
-```markdown
-# Plan: <title> (from intent.md <YYYY-MM-DD>)
-
-Accepted by: @<engineer>.
-
-## Files that change
-
-## Order of work
-
-## Risks
-
-## Proof
-```

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

@@ -1,40 +0,0 @@
-# Design phase: write `spec.md`
-
-This playbook turns a merged intent into the requirements and design spec.
-
-1. Find the intent: the `intent/<change>/intent.md` the request names. It must be on the default branch and have no `spec.md` beside it. In each case below, say only that, in two or three lines, and stop: write no file and add no review of the intent.
-   - The request names no intent, or the file does not exist on any branch: list each `intent/*/intent.md` on the default branch that has no `spec.md`, or say that there is none.
-   - The file exists only on another branch: say that the intent is not merged yet, and name that branch.
-   - `spec.md` already exists: say so and name the file.
-2. Read the four policies, every time, before you write: `.agents/skills/brand-policy/SKILL.md`, `.agents/skills/security-policy/SKILL.md`, `.agents/skills/compliance-policy/SKILL.md`, and `.agents/skills/ux-policy/SKILL.md`. Then read the code and the docs the change touches.
-3. Write `intent/<change>/spec.md` from the template below. Use exactly the template's headings.
-   - **Request:** under the status line, quote the words of the request that started this spec. End the line with the template's "Skills at" sentence; its commit is the output of `git log -1 --format=%h -- .agents/skills`.
-   - **Requirements:** numbered. Each one states a result a test or a reader can check.
-   - **Design:** how the change fits the existing code: the files that change, and what each one does afterwards.
-   - **Policies:** one line for each of the four policies. State which rules of that policy the change must meet, each as a requirement number, or write "Does not apply" and why.
-   - **Areas of concern:** a policy rule the change cannot meet, two policies that contradict, or a decision the files do not settle. Give each one a number, the policy it comes from, and that policy's owner from `.github/CODEOWNERS`. When `.github/CODEOWNERS` names no owner for a policy's folder, write "no owner in `.github/CODEOWNERS`" in place of the owner. Add one area of concern that says so. Write "None" only when there are none.
-   - **Open questions:** each open question from `intent.md`, answered with its evidence or carried forward. Write "None" only when the intent has none.
-4. Commit `spec.md` on a new branch. In the same commit, set the intent's status line to `Status: accepted.`, because its pull request is merged. Push the branch, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests. Put the areas of concern first in the pull request's description, under the template's first heading. When you cannot open a pull request from this session, say so and give the pushed branch's name.
-5. **Gate: the product owner reviews the spec.** The product owner resolves each area of concern with its policy owner, then merges the pull request to accept the spec, or closes it to reject it. For a change the spec classes as higher risk, the product owner consults a tech lead before accepting. You do none of these. The spec stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the plan's commit sets it. Report the pull request's URL, keep it green as `.agents/skills/sdlc/playbooks/review.md` says, and wait.
-
-**Next:** `.agents/skills/sdlc/playbooks/build.md`; an engineer with an agent; when the product owner has merged the spec's pull request and the engineer sends `/sdlc build` with the spec's path.
-
-## Template
-
-```markdown
-# Spec: <title>
-
-From `intent/<change>/intent.md`. Status: draft.
-
-Request: "<the words of the request that started this spec>". Skills at `<commit>`.
-
-## Requirements
-
-## Design
-
-## Policies
-
-## Areas of concern
-
-## Open questions
-```

package/templates/base/.agents/skills/sdlc/playbooks/open-pr.md

@@ -1,15 +0,0 @@
-# Open the pull request
-
-1. Clean the diff against the default branch. Remove debug output, commented-out code, changes the plan does not name, and comments that `.agents/rules/code-comments.md` does not allow.
-2. Do what `AGENTS.md` and `CONTRIBUTING.md` require for this kind of change. Add a release note only when they say this change needs one; most changes need none.
-3. When step 1 or 2 changed a file, run the checks under **Verifying your work** in `AGENTS.md` again. When one fails, fix the code and run it again. Commit only when they pass.
-4. Push the branch and open the pull request ready for review, as `AGENTS.md` says for branches and pull requests. When the branch already has a pull request, update that one. Fill the body from `.github/pull_request_template.md`:
-   - what changed and why, with the paths of `intent/<change>/spec.md` and `plan.md` when they exist;
-   - `Closes #<issue>` for each issue that already exists and that the change closes. When there is none, write what the template's own section asks for, and leave it out when the template has no such section. Never open an issue to get a number;
-   - each check you ran, with its result copied from the output.
-
-   When you cannot open a pull request from this session, say so, give the pushed branch's name, and go on to step 5: the review reads the pushed branch's diff. When you cannot push either, say so and go on to step 5 the same way: the review reads the local branch's diff. Neither case ends the turn.
-
-5. Go on in the same turn, without asking: follow `.agents/skills/sdlc/playbooks/review.md`.
-
-**Next:** `.agents/skills/sdlc/playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.

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

@@ -1,23 +0,0 @@
----
-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: 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 and starting work, keeping `/sdlc` on for a session, fixing a defect in behaviour that already exists, who decides at each gate, a mistake the agent repeats, or company policy.
-3. Read the files the topic points to before you answer. When a file disagrees with the map below, the file is right.
-4. When the person asks about a playbook, a command, or a file that this project does not have, the whole reply is three lines: it does not exist; what exists instead, as one file path; and one message they can send next. Stop there. Do not explain the topic from other files.
-5. Otherwise answer, then give one message the person can send as is, with real words from their question and no blanks to fill in, then list the files the answer came from.
-6. Write the reply as the **Write replies a person can check** convention in `AGENTS.md` says.
-
-## Map
-
-- **How the workflow runs, and starting work:** `intent/README.md` and the table in `.agents/skills/sdlc/SKILL.md`.
-- **Keeping `/sdlc` on for a session:** a person starts it; nothing routes work into it. In Claude Code, an invoked skill's content stays in the conversation across later turns, and after a compaction Claude Code re-attaches the most recent invocation within a token budget, so a person types `/sdlc` again only to restore the full text. In Cursor, pick `/sdlc` from the `/` menu and press Option+Enter (Mac) or Alt+Enter (Windows) instead of Enter, which makes it a custom mode that stays in context until the person exits it. Plain Enter attaches it to one message.
-- **Fixing a defect in behaviour that already exists:** `.agents/skills/sdlc/playbooks/fix.md` is the path with no intent and no spec, for a person's request: a plan an engineer accepts, then a failing test, the fix, and a pull request. A finding from a job always starts at intent. Every other change runs intent, spec, plan, then build.
-- **Who decides:** `.agents/rules/agent-owned-work.md` and `.github/CODEOWNERS`.
-- **A mistake the agent repeats:** **Things Claude gets wrong** in `AGENTS.md`.
-- **Company policy:** the policy skills in `.agents/skills/`, and `.github/CODEOWNERS` for each one's owner.

package/templates/base/.claude/skills/brand-policy/SKILL.md

@@ -1,18 +0,0 @@
----
-name: brand-policy
-description: Apply the organization's brand policy. Use whenever writing or reviewing a spec.md, a plan, or code that this policy covers.
----
-
-# Brand policy
-
-Owner: the code owner of this folder in `.github/CODEOWNERS`.
-
-This is the default; the owner adds the brand's names, colours, typefaces, and tone of voice by editing this file.
-
-## Rules
-
-1. A change with no user-visible text, colour, typeface, logo, or message meets this policy; say "Does not apply" and why.
-2. The organization's name, product names, colours, typefaces, and logo files each have one declared source in the project. The spec names that source for every brand value the change shows. When the source does not exist yet, creating it is a requirement of the spec.
-3. No code, style, email, or message the user sees holds a brand value as a literal; each reads it from that source. Project metadata such as `package.json`, `README.md`, and `LICENSE` is outside this rule.
-4. Text the user reads uses one name for one thing and the same words for the same action on every screen, and shows no internal identifier or stack trace.
-5. A brand value this file does not give, such as an exact colour or a tone of voice, is an area of concern. Never invent one.

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

@@ -1,46 +0,0 @@
-# Build phase: plan, then implement
-
-This playbook turns a merged spec into a plan the engineer accepts, and then into working code.
-
-1. Find the change: the `intent/<change>/` folder whose `spec.md` or `plan.md` the request names. Its `spec.md` must be on the default branch beside its `intent.md`. In each case below, say only that, in two or three lines, and stop: write no file.
-   - The request names no change, or the folder has no `spec.md` on any branch: list each `intent/*/` on the default branch that has a `spec.md` and no `plan.md`, or say that there is none.
-   - The spec exists only on another branch: say that the spec is not merged yet, and name that branch.
-   - `intent/<change>/plan.md` is already on the default branch: say that the plan is merged, name the file, and say that the change is built only when each requirement of `spec.md` is checked against the tree.
-
-   When the request is a bug fix with no spec, none of these cases applies: follow `.agents/skills/sdlc/playbooks/fix.md` instead.
-
-2. When `intent/<change>/plan.md` exists on a branch that is not merged, check out that branch. When the request says the plan is accepted, go to step 6. Otherwise show that plan and go to step 5.
-3. Read `intent.md`, `spec.md`, the four policies listed in `.agents/skills/sdlc/playbooks/design.md` step 2, and the code the change touches. Then interview the engineer until they have said four things: the files the change touches, the order of the work, the tests that prove it, and each option they rule out.
-   - **When all four are already said, in the request or in the files, go to step 4 in the same turn.**
-   - **When one is missing, ask and stop.** Write no plan in that turn. Ask in rounds, as step 3 of `.agents/skills/sdlc/playbooks/plan.md` does: numbered questions, each with a recommended answer or "No recommendation". Wait for the answers, and build the next round on them.
-4. Write the plan from the template below. Use exactly the template's headings. The date in the title is the date of the last commit to `intent/<change>/intent.md`: `git log -1 --format=%cs -- intent/<change>/intent.md`. An engineer who has never seen this conversation must be able to implement the change from the plan alone.
-   - **Files that change:** every file, marked new, changed, or deleted, with one line on what it does afterwards.
-   - **Order of work:** numbered steps. Each ends with the check that proves it.
-   - **Risks:** what the change could break, which step is the riskiest, and each option you chose not to take and why.
-   - **Proof:** the tests and commands that show every requirement of the spec is met, by requirement number, and the test or review step for each policy requirement the spec cites.
-
-   Show the whole plan and name the file only as `intent/<change>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
-
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could build from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes. When the spec classes the change as higher risk, say that a tech lead or an architect accepts the plan with the engineer.
-6. Create the branch as `AGENTS.md` says, unless step 2 checked one out. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5 or whom the request names, and commit `intent/<change>/plan.md` before any other change. In that commit, set the spec's status line to `Status: accepted.`, because its pull request is merged.
-7. Implement the plan in its order. After each step, run the check that proves it and fix what fails. For a bug fix, follow **Start a bug fix with a failing test** in `AGENTS.md`: commit the test on a `fix/` branch, and the gate then blocks test edits. When the work departs from the plan, change `plan.md` in the same commit. When the change meets the last requirement of `spec.md`, set `Status: done.` in `intent.md` and `spec.md`.
-8. Run every check under **Verifying your work** in `AGENTS.md` and keep the output. Every check must pass: fix the code, and never skip, delete, or weaken a test. Then look for `.claude/agents/verifier.md` or `.cursor/agents/verifier.md`: when it exists, run the `verifier` subagent and fix what it reports; when you cannot start a subagent, do what that file says yourself. For UI work, when `.mcp.json` lists a `playwright` server, also close the loop with a visual check: start the app, give the browser tool the page and the mock the spec or the request names, screenshot, compare, and adjust, and repeat until it matches; two or three rounds is normal. When a check cannot run in this session, say which one and why, and never report it as passed.
-9. Go on in the same turn, without asking: follow `.agents/skills/sdlc/playbooks/open-pr.md`, and then `.agents/skills/sdlc/playbooks/review.md`. Pushing the branch and opening the pull request are part of this task.
-
-**Next:** `.agents/skills/sdlc/playbooks/open-pr.md`; an agent; in the same turn, as soon as step 8 passes.
-
-## Template
-
-```markdown
-# Plan: <title> (from intent.md <YYYY-MM-DD>)
-
-Accepted by: @<engineer>.
-
-## Files that change
-
-## Order of work
-
-## Risks
-
-## Proof
-```

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

@@ -1,9 +0,0 @@
-# Deploy phase: take a merged change to the production gate
-
-1. Find the commit: the full SHA on the default branch that the request names, or the latest commit there. Read its CI run. When a check failed or is still running, say which one in two lines and stop. When you cannot read the CI run from this session, say so and carry on with the commit marked as not verified.
-2. Read how this project deploys: the deploy section of `README.md` and `.github/workflows/deploy.yml`, or the release workflow under `.github/workflows/` when the project releases that way. When the project has no deploy workflow, or deploying is switched off, say so in two lines and stop. When you cannot tell whether deploying is switched on, say so and carry on.
-3. Report where the commit is. For each environment, in the order the project promotes them, say whether this commit is deployed there, and give the deployment's link or the output that shows it. Read production only from the deploy workflow's run history, never with a command that names the production environment. Where you cannot read an environment, write "not read" and why.
-4. Promote the commit to an environment before production only when the request asks for that environment. Do it the way `README.md` says, one environment at a time, and read the health check after each. When a deployment fails, stop: report the failing step and its log, and promote no further. When the request names production, by any name such as `prod`, go to step 5. When it names an environment the project does not have, say so and list the ones it has.
-5. **Gate: the release manager authorizes production.** Never start a production deployment, run a command that names the production environment, or push a release tag. Report the commit's SHA, the environments it has passed, the checks' results, and the exact action the release manager takes to promote it. When the request is to return production to an earlier commit, and the project has `runbooks/rollback-deploy.md`, report that runbook's command with the earlier commit's SHA as that exact action; the release manager runs it. Then wait.
-
-**Next:** `.agents/skills/sdlc/playbooks/maintain.md`; a job or a person; when monitoring or a ticket reports a finding in production.

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

@@ -1,23 +0,0 @@
-# Fix phase: repair a defect with a plan and a failing test
-
-This playbook takes a defect in behaviour that already exists to a pull request. It has no intent and no spec: its plan is the only file it adds under `intent/`.
-
-1. Decide that the request qualifies. It qualifies only when the request is a defect in behaviour that already exists, and the fix adds no new behaviour and no new dependency and changes no schema and no public interface. When a condition fails, say which one in two lines and follow `.agents/skills/sdlc/playbooks/plan.md` instead.
-2. Reproduce the defect yourself by running the code, and keep the output. Ask the person only when you can name the specific reason you cannot reach it, such as a credential or a service this session cannot use.
-3. Find the cause from what running the code shows. List the candidate causes, rule each out with a command or an observation, and never guess. Name the one cause the evidence leaves. When it leaves none, or more than one, say so and ask for what is missing.
-4. Write the plan from the template in `.agents/skills/sdlc/playbooks/build.md`. The title is `# Plan: <title> (fix)`. Use exactly the template's four headings, and keep the plan short. Name the file `intent/<short-description>/plan.md`; the folder holds only this file.
-   - **Files that change:** every file, marked new, changed, or deleted, with one line on what it does afterwards.
-   - **Order of work:** the cause and the evidence for it, then numbered steps. Each ends with the check that proves it.
-   - **Risks:** what the fix could break, and each option you chose not to take and why.
-   - **Proof:** the test that fails today and passes once the cause is fixed, and the command that runs it.
-
-   Show the whole plan and name the file only as `intent/<short-description>/plan.md`. In plan mode you cannot write the file. Show the plan as the plan.
-
-5. **Gate: the engineer accepts the plan.** Ask whether an engineer could fix the defect from it, and for their GitHub handle when you cannot read it. Revise until they say yes. Change no code and commit nothing before that yes. In plan mode, approving the plan is that yes.
-6. Create the branch `fix/<short-description>` as `AGENTS.md` says. Set the plan's `Accepted by:` line, under its title, to the handle of the engineer who said yes in step 5, and commit `intent/<short-description>/plan.md` as the first commit.
-7. Reproduce the defect as a test. Run it and check that it fails for the reason the cause gives. Commit the failing test before any fix.
-8. Make the test pass without editing it. On a `fix/` branch, `.agents/hooks/agent-test-edit-gate.sh` blocks test edits once the failing test is committed. On a branch with another name, create `.git/bug-fix-in-progress` first, and delete it once the test passes.
-9. Run every check under **Verifying your work** in `AGENTS.md`. Keep the output. When one fails, fix the code, and never skip, delete, or weaken a test. When a check cannot run in this session, say which one and why, and never report it as passed.
-10. Go on in the same turn, without asking. Follow `.agents/skills/sdlc/playbooks/open-pr.md`, and then `.agents/skills/sdlc/playbooks/review.md`.
-
-**Next:** `.agents/skills/sdlc/playbooks/open-pr.md`; an agent; in the same turn, as soon as step 9 passes.

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

@@ -1,20 +0,0 @@
-# Maintain phase: turn a finding into `intent.md`
-
-This playbook starts from a finding such as an alert, a monitoring ticket, a failing run, or an incident. No one answers questions while it runs.
-
-1. Read the finding the request gives: what was seen, where, when, and its link or log. When the request gives no finding, say so in two lines and stop. When the finding asks for a new capability and reports no fault, say that a person sends it with `/sdlc`, and stop.
-2. Diagnose without changing anything. Read the logs, the code, and the changes merged before the finding. When `bands.yaml` names the tools for the finding's tier, use only those. Write no file outside `intent/`, start no deploy, and act only through a route that `bands.yaml` lists for that tier: `pull_request` is the pull request in step 5, and any other route is a runbook of that name. When the finding names no tier, or the project has no `bands.yaml`, use read-only tools only. When the tier's action is only to log, put the finding in your reply and stop.
-3. Write `intent/<change>/intent.md` from the template in `.agents/skills/sdlc/playbooks/plan.md`. Use exactly the template's five headings.
-   - **Problem:** the anomaly and its evidence: the number, its source, and the time.
-   - **Proposed outcome:** what the fixed system does, as its user would see it.
-   - **Open questions:** everything the evidence does not settle, including the cause when you could not prove it. Never state a cause you did not verify.
-
-   In the author line, name what started the run, such as "Author: maintain job (alert <link>). Status: draft."
-
-4. Run the confidence check. It is a check, not a person.
-   - Start a subagent that has not seen the diagnosis, give it only the finding, the logs and files you read, and `intent.md`, and have it try to disprove the **Problem** section from the evidence. When you cannot start a subagent, read the evidence again from the first line as if someone else wrote the intent.
-   - When a claim does not survive, move it under **Open questions**, and say in the pull request that the confidence check failed and on which claim.
-5. 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. Put the evidence and the confidence check's result first in its description, under the template's first heading. When you cannot open a pull request from this session, say so and give the pushed branch's name.
-6. **Gate: the service owner triages the finding.** The service owner merges the pull request to fix the finding now, leaves it open to schedule it, or closes it to dismiss it. A dismissal tunes the bands: the service owner adjusts `bands.yaml` so the same noise raises fewer findings. The service owner asks the product owner to decide a product-facing finding. You do none of these. Report the pull request's URL, keep it green as `.agents/skills/sdlc/playbooks/review.md` says, and wait.
-
-**Next:** `.agents/skills/sdlc/playbooks/design.md`; an agent; when the service owner has merged the intent's pull request and a person or a job sends `/sdlc` with the intent's path.

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

@@ -1,15 +0,0 @@
-# Open the pull request
-
-1. Clean the diff against the default branch. Remove debug output, commented-out code, changes the plan does not name, and comments that `.agents/rules/code-comments.md` does not allow.
-2. Do what `AGENTS.md` and `CONTRIBUTING.md` require for this kind of change. Add a release note only when they say this change needs one; most changes need none.
-3. When step 1 or 2 changed a file, run the checks under **Verifying your work** in `AGENTS.md` again. When one fails, fix the code and run it again. Commit only when they pass.
-4. Push the branch and open the pull request ready for review, as `AGENTS.md` says for branches and pull requests. When the branch already has a pull request, update that one. Fill the body from `.github/pull_request_template.md`:
-   - what changed and why, with the paths of `intent/<change>/spec.md` and `plan.md` when they exist;
-   - `Closes #<issue>` for each issue that already exists and that the change closes. When there is none, write what the template's own section asks for, and leave it out when the template has no such section. Never open an issue to get a number;
-   - each check you ran, with its result copied from the output.
-
-   When you cannot open a pull request from this session, say so, give the pushed branch's name, and go on to step 5: the review reads the pushed branch's diff. When you cannot push either, say so and go on to step 5 the same way: the review reads the local branch's diff. Neither case ends the turn.
-
-5. Go on in the same turn, without asking: follow `.agents/skills/sdlc/playbooks/review.md`.
-
-**Next:** `.agents/skills/sdlc/playbooks/review.md`; an agent; in the same turn, as soon as step 4 is done.

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

@@ -1,33 +0,0 @@
-# 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, the outcome, the constraints, and what is out of scope. The problem names who is affected, how often, and a number with its source. The outcome is what the user would see.
-   - **When all four are already said, go to step 4 in the same turn.**
-   - **When one is missing, ask and stop.** Write no draft in that turn. Ask in rounds. Each round holds only questions that do not depend on another question in the same round. Number the questions. Each asks one thing and carries a concrete answer you recommend, worded so "yes" accepts it. A recommended answer is a fact or a choice, such as "Recommended: only the checkout page", never an instruction to the person. When you have no answer to recommend, write "No recommendation" and ask plainly. Wait for the answers, and build the next round on them.
-4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Use exactly the template's five headings. What is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**. Write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file. Show the draft as the plan, and write the file once it is approved.
-5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
-6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
-7. **Gate: the product owner accepts or rejects the intent.** The product owner merges the pull request to accept the intent, or closes it to reject it. You do neither. The file stays `Status: draft.`: never write `Status: accepted.` in this pull request, because the spec's pull request sets it. Report the pull request's URL, keep it green as `.agents/skills/sdlc/playbooks/review.md` says, and wait.
-
-**Next:** `.agents/skills/sdlc/playbooks/design.md`; an agent; when the product owner has merged the intent's pull request and a person or a job asks for the spec.
-
-## Template
-
-```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

@@ -1,8 +0,0 @@
-# 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.