npm - @next-friday/create-app - Versions diffs - 7.0.0 → 8.0.0 - Mend

@next-friday/create-app 7.0.0 → 8.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (57) hide show

package/package.json CHANGED Viewed

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

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

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

package/templates/base/.agents/skills/brand-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,14 @@ description: Apply the organization's brand policy. Use whenever writing or revi
 # Brand policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+This is the default; the owner adds the brand's names, colours, typefaces, and tone of voice by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## 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/.agents/skills/compliance-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,21 @@ description: Apply the organization's compliance policy. Use whenever writing or
 # Compliance policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: the eight basic principles of the [OECD Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0188) (adopted 1980, revised 2013), paragraphs 7 to 14. This is the default and names no country's law; the owner adds the laws and contracts that bind the organization by editing this file. The points below summarize those paragraphs; the standard's text governs.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. A change that collects, stores, shows, sends, or deletes no data about a person meets this policy; say "Does not apply" and why.
+2. For any other change, the spec lists each kind of personal data the change touches and answers the eight points below for it. Each answer becomes a requirement.
+   1. **Collection limitation:** what is collected, by what lawful and fair means, and how the person knows or consents.
+   2. **Data quality:** why each field is relevant to the purpose, and how it is kept accurate and up to date.
+   3. **Purpose specification:** the purpose, stated no later than the moment of collection.
+   4. **Use limitation:** who else receives the data. A use that is incompatible with the stated purpose needs the person's consent or the authority of law.
+   5. **Security safeguards:** how the data is protected against loss and against unauthorised access, destruction, use, modification, or disclosure. The security policy gives the rules.
+   6. **Openness:** where a person can read what data is held, its main purposes, and who controls it.
+   7. **Individual participation:** how a person learns whether data about them is held, gets it within a reasonable time and at no excessive charge, is given reasons when a request is denied, and challenges it; when the challenge succeeds, the data is erased, rectified, completed, or amended.
+   8. **Accountability:** who in the organization answers for these points.
+3. A point the spec cannot answer from the files is an area of concern. Never guess a legal basis.
+4. Whether a specific law applies is a decision for the owner; raise it as an area of concern.

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

@@ -10,11 +10,12 @@ 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. |
+   | 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 spec for an intent                                                             | Follow [`playbooks/design.md`](playbooks/design.md).                                                                                                                              |
+   | A later step: a build, a review, a deploy, or an incident fix                    | Say "This step has no playbook in `/sdlc` yet" and name the step. Name `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.

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

@@ -0,0 +1,37 @@
+# Design phase: write `spec.md`
+This playbook turns a merged intent into the requirements and design spec. A person or a job can start it; the steps are the same.
+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, in the language of the files already in `intent/`. Use exactly the template's headings.
+   - **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: the rules of that policy the change must meet, each as a requirement number, or "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, and 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, push it, 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, accepts the spec by setting `Status: accepted.` and merging the pull request, or rejects it by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `AGENTS.md`; an engineer; when the product owner has merged the spec's pull request, the engineer starts the build in plan mode with `intent.md` and `spec.md`.
+## Template
+```markdown
+# Spec: <title>
+From `intent/<change>/intent.md`. Status: draft.
+## Requirements
+## Design
+## Policies
+## Areas of concern
+## Open questions
+```

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

@@ -7,10 +7,12 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 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.
+4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Write the file in the language of the files already in `intent/`. Use exactly the template's five headings; what is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**; write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file: show the draft as the plan, and write the file once it is approved.
+5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
-7. **Gate: the product owner accepts or rejects the intent.** The product owner 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.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `.agents/skills/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

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

@@ -4,3 +4,5 @@
 2. Answer, citing `path:line` or command output for each claim, as the **Write replies a person can check** convention in `AGENTS.md` says.
 3. Write no file, make no commit, push nothing, and post nothing to GitHub or another service.
 4. When the answer shows work worth doing, offer it in one line, such as "Send `/sdlc write an intent for this` to start the change", and stop.
+**Next:** none; the person; when they send a new message.

package/templates/base/.agents/skills/security-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,37 @@ description: Apply the organization's security policy. Use whenever writing or r
 # Security policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: [OWASP Application Security Verification Standard 5.0.0](https://github.com/OWASP/ASVS/tree/v5.0.0/5.0/en), Level 1. This is the default; the owner replaces or tightens it by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. Find the chapters the change touches in the table below. A change that touches none meets this policy; say "Does not apply" and why.
+2. For each chapter it touches, open that chapter's file in the standard and list every Level 1 requirement that applies to the change. Cite each as `v5.0.0-<chapter>.<section>.<requirement>`, for example `v5.0.0-8.2.1`.
+3. Each cited requirement becomes a requirement of the spec, and a test or a review step of the plan.
+4. When you cannot open the standard, name the chapters, cite no requirement number from memory, and report that as an area of concern.
+5. A Level 1 requirement the change cannot meet is an area of concern. Never drop it silently.
+6. Secrets stay out of the repository, logs, and error messages; `.env.example` holds names only.
+## Chapters
+| Chapter | Covers                              | Level 1 requirements |
+| :------ | :---------------------------------- | :------------------- |
+| V1      | Encoding and Sanitization           | 8                    |
+| V2      | Validation and Business Logic       | 4                    |
+| V3      | Web Frontend Security               | 8                    |
+| V4      | API and Web Service                 | 2                    |
+| V5      | File Handling                       | 4                    |
+| V6      | Authentication                      | 13                   |
+| V7      | Session Management                  | 6                    |
+| V8      | Authorization                       | 4                    |
+| V9      | Self-contained Tokens               | 4                    |
+| V10     | OAuth and OIDC                      | 5                    |
+| V11     | Cryptography                        | 3                    |
+| V12     | Secure Communication                | 3                    |
+| V13     | Configuration                       | 1                    |
+| V14     | Data Protection                     | 2                    |
+| V15     | Secure Coding and Architecture      | 3                    |
+| V16     | Security Logging and Error Handling | 0                    |
+| V17     | WebRTC                              | 0                    |

package/templates/base/.agents/skills/ux-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,17 @@ description: Apply the organization's UX policy. Use whenever writing or reviewi
 # UX policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), Level AA: the page satisfies all the Level A and Level AA success criteria. This is the default; the owner replaces or tightens it by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. A change with no user interface meets this policy; say "Does not apply" and why.
+2. For a change with a user interface, the spec lists the success criteria the change touches, by number and name, and each becomes a requirement.
+3. Every interactive element works with the keyboard alone, shows where the focus is, and has a name a screen reader announces.
+4. Text and meaningful graphics meet the contrast minimum, and no information is carried by colour alone.
+5. Every form field has a visible label, and every error says in text which field is wrong and how to fix it.
+6. Check the criteria that WCAG 2.2 added at Level A and AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum).
+7. Every state the user can reach is designed: loading, empty, error, and success.
+8. A criterion the change cannot meet is an area of concern. Never drop it silently.

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

@@ -5,8 +5,14 @@ description: Apply the organization's brand policy. Use whenever writing or revi
 # Brand policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+This is the default; the owner adds the brand's names, colours, typefaces, and tone of voice by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## 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/compliance-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,21 @@ description: Apply the organization's compliance policy. Use whenever writing or
 # Compliance policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: the eight basic principles of the [OECD Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0188) (adopted 1980, revised 2013), paragraphs 7 to 14. This is the default and names no country's law; the owner adds the laws and contracts that bind the organization by editing this file. The points below summarize those paragraphs; the standard's text governs.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. A change that collects, stores, shows, sends, or deletes no data about a person meets this policy; say "Does not apply" and why.
+2. For any other change, the spec lists each kind of personal data the change touches and answers the eight points below for it. Each answer becomes a requirement.
+   1. **Collection limitation:** what is collected, by what lawful and fair means, and how the person knows or consents.
+   2. **Data quality:** why each field is relevant to the purpose, and how it is kept accurate and up to date.
+   3. **Purpose specification:** the purpose, stated no later than the moment of collection.
+   4. **Use limitation:** who else receives the data. A use that is incompatible with the stated purpose needs the person's consent or the authority of law.
+   5. **Security safeguards:** how the data is protected against loss and against unauthorised access, destruction, use, modification, or disclosure. The security policy gives the rules.
+   6. **Openness:** where a person can read what data is held, its main purposes, and who controls it.
+   7. **Individual participation:** how a person learns whether data about them is held, gets it within a reasonable time and at no excessive charge, is given reasons when a request is denied, and challenges it; when the challenge succeeds, the data is erased, rectified, completed, or amended.
+   8. **Accountability:** who in the organization answers for these points.
+3. A point the spec cannot answer from the files is an area of concern. Never guess a legal basis.
+4. Whether a specific law applies is a decision for the owner; raise it as an area of concern.

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

@@ -10,11 +10,12 @@ 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. |
+   | 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 spec for an intent                                                             | Follow [`playbooks/design.md`](playbooks/design.md).                                                                                                                              |
+   | A later step: a build, a review, a deploy, or an incident fix                    | Say "This step has no playbook in `/sdlc` yet" and name the step. Name `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.

package/templates/base/.claude/skills/sdlc/playbooks/design.md ADDED Viewed

@@ -0,0 +1,37 @@
+# Design phase: write `spec.md`
+This playbook turns a merged intent into the requirements and design spec. A person or a job can start it; the steps are the same.
+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, in the language of the files already in `intent/`. Use exactly the template's headings.
+   - **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: the rules of that policy the change must meet, each as a requirement number, or "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, and 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, push it, 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, accepts the spec by setting `Status: accepted.` and merging the pull request, or rejects it by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `AGENTS.md`; an engineer; when the product owner has merged the spec's pull request, the engineer starts the build in plan mode with `intent.md` and `spec.md`.
+## Template
+```markdown
+# Spec: <title>
+From `intent/<change>/intent.md`. Status: draft.
+## Requirements
+## Design
+## Policies
+## Areas of concern
+## Open questions
+```

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

@@ -7,10 +7,12 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 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.
+4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Write the file in the language of the files already in `intent/`. Use exactly the template's five headings; what is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**; write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file: show the draft as the plan, and write the file once it is approved.
+5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
-7. **Gate: the product owner accepts or rejects the intent.** The product owner 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.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `.agents/skills/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

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

@@ -4,3 +4,5 @@
 2. Answer, citing `path:line` or command output for each claim, as the **Write replies a person can check** convention in `AGENTS.md` says.
 3. Write no file, make no commit, push nothing, and post nothing to GitHub or another service.
 4. When the answer shows work worth doing, offer it in one line, such as "Send `/sdlc write an intent for this` to start the change", and stop.
+**Next:** none; the person; when they send a new message.

package/templates/base/.claude/skills/security-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,37 @@ description: Apply the organization's security policy. Use whenever writing or r
 # Security policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: [OWASP Application Security Verification Standard 5.0.0](https://github.com/OWASP/ASVS/tree/v5.0.0/5.0/en), Level 1. This is the default; the owner replaces or tightens it by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. Find the chapters the change touches in the table below. A change that touches none meets this policy; say "Does not apply" and why.
+2. For each chapter it touches, open that chapter's file in the standard and list every Level 1 requirement that applies to the change. Cite each as `v5.0.0-<chapter>.<section>.<requirement>`, for example `v5.0.0-8.2.1`.
+3. Each cited requirement becomes a requirement of the spec, and a test or a review step of the plan.
+4. When you cannot open the standard, name the chapters, cite no requirement number from memory, and report that as an area of concern.
+5. A Level 1 requirement the change cannot meet is an area of concern. Never drop it silently.
+6. Secrets stay out of the repository, logs, and error messages; `.env.example` holds names only.
+## Chapters
+| Chapter | Covers                              | Level 1 requirements |
+| :------ | :---------------------------------- | :------------------- |
+| V1      | Encoding and Sanitization           | 8                    |
+| V2      | Validation and Business Logic       | 4                    |
+| V3      | Web Frontend Security               | 8                    |
+| V4      | API and Web Service                 | 2                    |
+| V5      | File Handling                       | 4                    |
+| V6      | Authentication                      | 13                   |
+| V7      | Session Management                  | 6                    |
+| V8      | Authorization                       | 4                    |
+| V9      | Self-contained Tokens               | 4                    |
+| V10     | OAuth and OIDC                      | 5                    |
+| V11     | Cryptography                        | 3                    |
+| V12     | Secure Communication                | 3                    |
+| V13     | Configuration                       | 1                    |
+| V14     | Data Protection                     | 2                    |
+| V15     | Secure Coding and Architecture      | 3                    |
+| V16     | Security Logging and Error Handling | 0                    |
+| V17     | WebRTC                              | 0                    |

package/templates/base/.claude/skills/ux-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,17 @@ description: Apply the organization's UX policy. Use whenever writing or reviewi
 # UX policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/), Level AA: the page satisfies all the Level A and Level AA success criteria. This is the default; the owner replaces or tightens it by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. A change with no user interface meets this policy; say "Does not apply" and why.
+2. For a change with a user interface, the spec lists the success criteria the change touches, by number and name, and each becomes a requirement.
+3. Every interactive element works with the keyboard alone, shows where the focus is, and has a name a screen reader announces.
+4. Text and meaningful graphics meet the contrast minimum, and no information is carried by colour alone.
+5. Every form field has a visible label, and every error says in text which field is wrong and how to fix it.
+6. Check the criteria that WCAG 2.2 added at Level A and AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum).
+7. Every state the user can reach is designed: loading, empty, error, and success.
+8. A criterion the change cannot meet is an area of concern. Never drop it silently.

package/templates/base/.cursor/skills/brand-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,14 @@ description: Apply the organization's brand policy. Use whenever writing or revi
 # Brand policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+This is the default; the owner adds the brand's names, colours, typefaces, and tone of voice by editing this file.
-This policy is not written yet. Report that as an area of concern.
+## 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/.cursor/skills/compliance-policy/SKILL.md CHANGED Viewed

@@ -5,8 +5,21 @@ description: Apply the organization's compliance policy. Use whenever writing or
 # Compliance policy
-Owner: <the named policy owner>
+Owner: the code owner of this folder in `.github/CODEOWNERS`.
-Source of truth: <where the written policy lives>
+Standard: the eight basic principles of the [OECD Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0188) (adopted 1980, revised 2013), paragraphs 7 to 14. This is the default and names no country's law; the owner adds the laws and contracts that bind the organization by editing this file. The points below summarize those paragraphs; the standard's text governs.
-This policy is not written yet. Report that as an area of concern.
+## Rules
+1. A change that collects, stores, shows, sends, or deletes no data about a person meets this policy; say "Does not apply" and why.
+2. For any other change, the spec lists each kind of personal data the change touches and answers the eight points below for it. Each answer becomes a requirement.
+   1. **Collection limitation:** what is collected, by what lawful and fair means, and how the person knows or consents.
+   2. **Data quality:** why each field is relevant to the purpose, and how it is kept accurate and up to date.
+   3. **Purpose specification:** the purpose, stated no later than the moment of collection.
+   4. **Use limitation:** who else receives the data. A use that is incompatible with the stated purpose needs the person's consent or the authority of law.
+   5. **Security safeguards:** how the data is protected against loss and against unauthorised access, destruction, use, modification, or disclosure. The security policy gives the rules.
+   6. **Openness:** where a person can read what data is held, its main purposes, and who controls it.
+   7. **Individual participation:** how a person learns whether data about them is held, gets it within a reasonable time and at no excessive charge, is given reasons when a request is denied, and challenges it; when the challenge succeeds, the data is erased, rectified, completed, or amended.
+   8. **Accountability:** who in the organization answers for these points.
+3. A point the spec cannot answer from the files is an area of concern. Never guess a legal basis.
+4. Whether a specific law applies is a decision for the owner; raise it as an area of concern.

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

@@ -10,11 +10,12 @@ 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. |
+   | 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 spec for an intent                                                             | Follow [`playbooks/design.md`](playbooks/design.md).                                                                                                                              |
+   | A later step: a build, a review, a deploy, or an incident fix                    | Say "This step has no playbook in `/sdlc` yet" and name the step. Name `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.

package/templates/base/.cursor/skills/sdlc/playbooks/design.md ADDED Viewed

@@ -0,0 +1,37 @@
+# Design phase: write `spec.md`
+This playbook turns a merged intent into the requirements and design spec. A person or a job can start it; the steps are the same.
+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, in the language of the files already in `intent/`. Use exactly the template's headings.
+   - **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: the rules of that policy the change must meet, each as a requirement number, or "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, and 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, push it, 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, accepts the spec by setting `Status: accepted.` and merging the pull request, or rejects it by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `AGENTS.md`; an engineer; when the product owner has merged the spec's pull request, the engineer starts the build in plan mode with `intent.md` and `spec.md`.
+## Template
+```markdown
+# Spec: <title>
+From `intent/<change>/intent.md`. Status: draft.
+## Requirements
+## Design
+## Policies
+## Areas of concern
+## Open questions
+```

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

@@ -7,10 +7,12 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 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.
+4. Write `intent/<change>/intent.md` from the template below, where `<change>` is a short kebab-case name. Write the file in the language of the files already in `intent/`. Use exactly the template's five headings; what is out of scope goes under **Proposed outcome**. Anything else that is unknown, unverified, or not yet decided goes under **Open questions**; write "None" only when nothing is, and never list what the originator already answered. Show the whole draft, and name the file only as `intent/<change>/intent.md`. In plan mode you cannot write the file: show the draft as the plan, and write the file once it is approved.
+5. **Gate: the originator corrects the draft.** Ask whether it matches what they meant, and revise until they say yes. Commit nothing, push nothing, and open no pull request before that yes. In plan mode, the originator approving the plan is that yes.
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
-7. **Gate: the product owner accepts or rejects the intent.** The product owner 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.
+7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
+**Next:** `.agents/skills/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

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

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