npm - @next-friday/create-app - Versions diffs - 7.1.0 → 8.0.1 - Mend

@next-friday/create-app 7.1.0 → 8.0.1

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 (32) hide show

package/package.json CHANGED Viewed

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

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

@@ -12,7 +12,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
 7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
-**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+**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/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

@@ -12,7 +12,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
 7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
-**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+**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/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

@@ -12,7 +12,7 @@ This playbook writes the intent. The build plan, `intent/<change>/plan.md`, come
 6. Commit `intent.md` on a new branch, push it, and open a pull request ready for review, as `AGENTS.md` says for branches and pull requests.
 7. **Gate: the product owner accepts or rejects the intent.** The product owner accepts by setting `Status: accepted.` and merging the pull request, or rejects by closing it; you do neither. Report the pull request's URL, keep it green as `AGENTS.md` says, and wait.
-**Next:** `.agents/skills/write-spec/SKILL.md`; an agent; when the product owner has merged the intent's pull request and a person or a trigger asks for the spec.
+**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/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/.cursor/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/SETUP.md CHANGED Viewed

@@ -5,7 +5,7 @@ This project follows Anthropic's [AI-native SDLC Playbook](https://claude.com/re
 ## How a change flows
 1. **Plan:** the originator of an idea, a ticket, or an incident sends it with `/sdlc`, which interviews them and writes `intent/<change>/intent.md`. The product owner accepts it by merging it with `Status: accepted.`, or rejects it by closing its pull request.
-2. **Design:** `spec.md` is written from the accepted intent with the policy skills loaded (`write-spec` skill). The product owner resolves concerns with the policy owners.
+2. **Design:** `spec.md` is written from the accepted intent with the policy skills loaded (send the intent's path with `/sdlc`). The product owner resolves concerns with the policy owners.
 3. **Build:** the engineer starts in plan mode, approves the plan, and commits it as `plan.md`. A tech lead approves higher-risk plans.
 4. **Test:** the session runs **Verifying your work** in `AGENTS.md`.
 5. **Review:** Claude Code Review and Bugbot review by `REVIEW.md`. A code owner approves; the agent never does.
@@ -93,13 +93,13 @@ Also replace the owner placeholder in `.github/zizmor.yml`.
 - **Sources of truth (engineering lead):** for each artifact, name one system as the source of truth: this repository, an existing tool such as Jira, or, as the minimum, a link both ways (the record id in the file and the commit SHA in the record).
 - **Higher risk (engineering lead):** decide which changes count as higher risk. A tech lead or architect approves their specs and plans.
-- **Policies (each policy owner, with an engineer):** write the policy in `.agents/skills/<area>-policy/SKILL.md` from the owner's source of truth, then run `pnpm rules:sync`. Test that the skill triggers: ask for the relevant task in different ways and confirm the skill loads each time. The policy owner approves every later change as its code owner.
+- **Policies (each policy owner, with an engineer):** each `.agents/skills/<area>-policy/SKILL.md` ships a default (security: OWASP ASVS 5.0.0 Level 1; UX: WCAG 2.2 Level AA; compliance: the OECD privacy principles; brand: one declared source for every brand value). Review it, replace or add the organization's own rules, then run `pnpm rules:sync`. Test that the skill triggers: ask for the relevant task in different ways and confirm the skill loads each time. The policy owner approves every later change as its code owner.
 - **Production gate (engineering leadership, with change management and compliance):** name the release managers and add them as required reviewers on the `prod` environment, as the README's deploy section describes. `.agents/hooks/agent-production-gate.sh` blocks an agent's shell commands that dispatch a `prod` deploy, run a Railway command with `prod` as its environment, or push a release tag. It does not read MCP tools. A release manager whose own agent session must do one of these starts the agent with `RELEASE_APPROVAL` set to the approval record, for example `RELEASE_APPROVAL=CHG-123 claude`.
 - **Review (tech lead):** replace `src/gen/` in `.agents/review.md` with this project's generated paths, then run `pnpm rules:sync`, which renders it to `REVIEW.md` for Claude Code Review. Once a month, rate the review findings and tune `.agents/review.md`.
 - **People without Git experience:** connect GitHub to Claude (claude.ai or Cowork), so Claude commits `intent.md` for them.
 ## 7. Later, as the guardrails mature
-- Run the `write-spec` skill by hand first, then as an organization-level slash command, then as a job that commits `spec.md` as a pull request when an `intent.md` merges.
+- Send the intent's path with `/sdlc` by hand first, then as an organization-level slash command, then as a job that commits `spec.md` as a pull request when an `intent.md` merges.
 - Make auto mode the default for routine work: a tight `spec.md`, a small blast radius, and code the tests already cover.
 - Replace `bands.yaml` with this project's metric, add a unit-tested detection script that reads it, and add the trigger that runs it.

package/templates/base/intent/README.md CHANGED Viewed

@@ -4,7 +4,7 @@ This folder is the intent home. Every change starts here as an `intent.md`, and
 - Each change has its own folder, `intent/<change>/`, where `<change>` is a short kebab-case name. The folder holds `intent.md` (Plan), then `spec.md` (Design), then `plan.md` (Build).
 - **Plan.** An idea, a ticket, or an incident becomes `intent.md`, written by sending the idea with `/sdlc`, which interviews the originator. The originator corrects the draft before it is committed, and the product owner reviews it in its pull request. Merging its pull request records the decision: `Status: accepted.` accepts it, and `Status: rejected.` rejects it.
-- **Design.** The `write-spec` skill turns the accepted `intent.md` into `spec.md`, committed alongside it. The product owner reviews the spec against the idea and resolves each area of concern with its policy owner. Accepting the spec starts the build.
+- **Design.** Sending the intent's path with `/sdlc` turns the accepted `intent.md` into `spec.md`, committed alongside it. The product owner reviews the spec against the idea and resolves each area of concern with its policy owner. Accepting the spec starts the build.
 - **Build.** The engineer starts in plan mode with `intent.md` and `spec.md`, and commits the approved plan as `plan.md`. When implementation departs from the plan, `plan.md` changes in the same commit.
 ## Which file holds what

package/templates/nestjs/.github/pull_request_template.md CHANGED Viewed

@@ -2,7 +2,7 @@
 ## Why
-<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. Link a related issue with `Closes #123`. -->
+<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. When an issue already exists, link it with `Closes #123`; do not open an issue only to get a number. -->
 ## What changed

package/templates/nextjs/.github/pull_request_template.md CHANGED Viewed

@@ -2,7 +2,7 @@
 ## Why
-<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. Link a related issue with `Closes #123`. -->
+<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. When an issue already exists, link it with `Closes #123`; do not open an issue only to get a number. -->
 ## What changed

package/templates/nodejs/.github/pull_request_template.md CHANGED Viewed

@@ -2,7 +2,7 @@
 ## Why
-<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. Link a related issue with `Closes #123`. -->
+<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. When an issue already exists, link it with `Closes #123`; do not open an issue only to get a number. -->
 ## What changed

package/templates/payload/.github/pull_request_template.md CHANGED Viewed

@@ -2,7 +2,7 @@
 ## Why
-<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. Link a related issue with `Closes #123`. -->
+<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. When an issue already exists, link it with `Closes #123`; do not open an issue only to get a number. -->
 ## What changed

package/templates/turborepo/.github/pull_request_template.md CHANGED Viewed

@@ -2,7 +2,7 @@
 ## Why
-<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. Link a related issue with `Closes #123`. -->
+<!-- The problem and the approach in 1-3 short sentences. No SHAs or rebase history. When an issue already exists, link it with `Closes #123`; do not open an issue only to get a number. -->
 ## What changed

package/templates/base/.agents/skills/write-spec/SKILL.md DELETED Viewed

@@ -1,12 +0,0 @@
----
-name: write-spec
-description: Produce spec.md, the requirements and design spec, from an accepted intent.md. Use when a person or a trigger asks for the spec of an accepted intent.md.
----
-# Write spec.md
-Read the `intent.md` the user names, and follow this prompt:
-> Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.
-Write `spec.md` alongside that `intent.md`, in the same folder. Answer each open question from `intent.md`, or carry it forward. Commit it and open a pull request; the product owner accepts the spec by merging it.

package/templates/base/.claude/skills/write-spec/SKILL.md DELETED Viewed

@@ -1,12 +0,0 @@
----
-name: write-spec
-description: Produce spec.md, the requirements and design spec, from an accepted intent.md. Use when a person or a trigger asks for the spec of an accepted intent.md.
----
-# Write spec.md
-Read the `intent.md` the user names, and follow this prompt:
-> Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.
-Write `spec.md` alongside that `intent.md`, in the same folder. Answer each open question from `intent.md`, or carry it forward. Commit it and open a pull request; the product owner accepts the spec by merging it.

package/templates/base/.cursor/skills/write-spec/SKILL.md DELETED Viewed

@@ -1,12 +0,0 @@
----
-name: write-spec
-description: Produce spec.md, the requirements and design spec, from an accepted intent.md. Use when a person or a trigger asks for the spec of an accepted intent.md.
----
-# Write spec.md
-Read the `intent.md` the user names, and follow this prompt:
-> Read the attached intent.md and produce a requirements and design spec for integrating it into our existing codebase. Apply the skills available to you so the plan conforms to our brand guidelines, security policies and UX standards. Document the spec fully as spec.md, ready to hand to the engineering team. Describe clearly any areas of concern, especially where you cannot satisfy contradicting policies.
-Write `spec.md` alongside that `intent.md`, in the same folder. Answer each open question from `intent.md`, or carry it forward. Commit it and open a pull request; the product owner accepts the spec by merging it.