@next-friday/create-app 9.2.1 → 9.3.1

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

@@ -1,17 +0,0 @@
-# Review phase: review the pull request and drive it to green
-
-1. Find what to review: the pull request this session just opened, or the pull request or branch the request names. When there is no pull request, or this session cannot reach its host, review the branch's diff against the default branch and put the findings in your reply in place of a comment.
-2. Review with a fresh context. Start a subagent that has not seen the work. Give it only the diff, `REVIEW.md`, and the change's `intent/<change>/spec.md` and `plan.md`. When you cannot start a subagent, read the diff again from the first line as if someone else wrote it. The review runs each pass in `REVIEW.md` and reports each finding with its pass, **Important** or **Nit**, `path:line`, and the evidence. A change that is not a fix, an intent, or a spec, and has no `spec.md` or no `plan.md`, is itself a finding.
-3. Post the findings as one comment on the pull request, most severe first. Write "No findings" when there are none. A finding does not decide the merge. When a finding flags a mistake that an earlier review of this project flagged too, its correction goes into `AGENTS.md` under **Things Claude gets wrong** as part of this review: in the push of step 4, or, on a pull request or a branch this session did not create, as the exact line in this comment.
-4. On a pull request or a branch that this session did not create, change nothing and push nothing. Skip the rest of this step, and in step 5 only read and answer. Otherwise, fix every Important finding, and every Nit that is correct while the pull request has no code owner's approval yet. Run the checks under **Verifying your work** in `AGENTS.md`, and push. Answer each finding you do not fix with the reason.
-5. Sweep the pull request until every check passes and no comment is unanswered. In each pass:
-   - **A conflict, or a branch behind the default branch:** merge the default branch into the pull request's branch and resolve it. Run the checks under **Verifying your work** in `AGENTS.md`, and push. Never rebase or force-push a branch that someone else also pushes to.
-   - **A failing check:** read its log and find the cause. When the same check fails on the default branch, or the log shows an outage outside this change, the failure is not this change's. Say which check and why in one comment, and go on. Otherwise fix the cause and push. Run a check again at most once, and only to tell an outage from a real failure. Never skip, disable, or weaken a test to pass a check.
-   - **A person's comment:** make the change it asks for when it is small and local, push, and answer it. For a larger change, answer with what you would do, and go on with the sweep. The person decides in their reply or at the code owner's review.
-   - **A bot's comment:** treat it as a claim. Reproduce it or trace it in the code first. Fix what is real, and answer the rest with what you checked.
-   - **A nit:** never push for nits alone, because a push can dismiss the code owner's approval. Answer it, and carry the fix in the next push that has another reason.
-   - **A push that dismissed the code owner's approval:** say once that the pull request needs that approval again.
-
-6. **Gate: a code owner approves the pull request, and a person merges it.** You never approve it and never merge it. Report the pull request's URL, or the branch's name when there is none, and say it waits only on the code owner. When a new comment or a failing check arrives, go back to step 5. Subscribe to the pull request's events where your tool can. Otherwise say that a person sends `/sdlc review` with the pull request when something changes.
-
-**Next:** `.agents/skills/sdlc/playbooks/deploy.md`; the project's deploy workflow, or an agent when a person asks; when the pull request is merged.

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

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

package/templates/base/.cursor/BUGBOT.md

@@ -1,23 +0,0 @@
-# Review rules
-
-Review pull requests against the project's agent guide and rules:
-
-- [Review instructions](../.agents/review.md)
-- [Agent guide](../AGENTS.md)
-- [Agent-Owned Work](../.agents/rules/agent-owned-work.md)
-- [Owned Checks](../.agents/rules/automation-owned-checks.md)
-- [Required Comments](../.agents/rules/code-comments.md)
-- [Codebase Hygiene](../.agents/rules/codebase-hygiene.md)
-- [Constitution Changes](../.agents/rules/constitution-changes.md)
-- [Current State](../.agents/rules/current-state-authority.md)
-- [Demand-Driven Configuration](../.agents/rules/demand-driven-configuration.md)
-- [Dependencies](../.agents/rules/dependency-security.md)
-- [Descriptive Naming](../.agents/rules/descriptive-naming.md)
-- [Test Admission](../.agents/rules/deterministic-testing.md)
-- [Diagnostics](../.agents/rules/diagnostics-and-error-handling.md)
-- [Evidence](../.agents/rules/evidence-before-claims.md)
-- [Findings](../.agents/rules/no-suppression.md)
-- [Platform and Library First](../.agents/rules/platform-and-library-first.md)
-- [Sibling Style](../.agents/rules/single-author-style.md)
-- [Logging](../.agents/rules/structured-logging.md)
-- [TypeScript-First](../.agents/rules/typescript-first.md)

package/templates/base/.cursor/skills/compliance-policy/SKILL.md

@@ -1,25 +0,0 @@
----
-name: compliance-policy
-description: Apply the organization's compliance policy. Use whenever writing or reviewing a spec.md, a plan, or code that this policy covers.
----
-
-# Compliance policy
-
-Owner: the code owner of this folder in `.github/CODEOWNERS`.
-
-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.
-
-## 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/playbooks/build.md

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

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

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

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

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

package/templates/base/.cursor/skills/security-policy/SKILL.md

@@ -1,41 +0,0 @@
----
-name: security-policy
-description: Apply the organization's security policy. Use whenever writing or reviewing a spec.md, a plan, or code that this policy covers.
----
-
-# Security policy
-
-Owner: the code owner of this folder in `.github/CODEOWNERS`.
-
-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.
-
-## 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

@@ -1,21 +0,0 @@
----
-name: ux-policy
-description: Apply the organization's UX policy. Use whenever writing or reviewing a spec.md, a plan, or code that this policy covers.
----
-
-# UX policy
-
-Owner: the code owner of this folder in `.github/CODEOWNERS`.
-
-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.
-
-## 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/.github/workflows/agent-evals.yml

@@ -1,46 +0,0 @@
-name: Agent evals
-
-on:
-  pull_request:
-    paths:
-      - AGENTS.md
-      - CLAUDE.md
-      - .agents/**
-      - .claude/**
-      - .cursor/**
-  schedule:
-    - cron: "0 2 * * *"
-
-permissions: {}
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
-  cancel-in-progress: true
-
-jobs:
-  evals:
-    name: Run agent evals
-    if: vars.CLAUDE_CI_ENABLED == 'true' && (github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository)
-    runs-on: ubuntu-latest
-    timeout-minutes: 60
-    permissions:
-      contents: read
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-        with:
-          persist-credentials: false
-      - name: Set up Node.js and pnpm
-        uses: pnpm/setup@fbda4c85fc2e1e08721cd8763afea8f48d60f024 # v3.0.0
-        with:
-          cache: true
-          require-lockfile: true
-      - name: Run the eval suite
-        env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
-          CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-        run: |
-          [[ -n "$ANTHROPIC_API_KEY" || -n "$CLAUDE_CODE_OAUTH_TOKEN" ]] || { echo "::error::Set the CLAUDE_CODE_OAUTH_TOKEN or ANTHROPIC_API_KEY repository secret"; exit 1; }
-          [[ -n "$ANTHROPIC_API_KEY" ]] || unset ANTHROPIC_API_KEY
-          [[ -n "$CLAUDE_CODE_OAUTH_TOKEN" ]] || unset CLAUDE_CODE_OAUTH_TOKEN
-          pnpm evals:run