@synoikia/create-plugin 0.7.0 → 0.8.1

package/templates/repo/claude/_claude/skills/plugin-development/references/typescript.md

@@ -1,31 +0,0 @@
-# TypeScript
-
-The compiler settings are in `tsconfig.base.json`: strict, `noUncheckedIndexedAccess`, `verbatimModuleSyntax`, `NodeNext` modules. Don't change them per plugin.
-
-## Imports and modules
-
-- Use `import type` for anything used only as a type. Put a `.js` extension on every relative import.
-- Relative paths only, no path aliases. Node built-ins with the `node:` prefix.
-- A plugin's `src/` keeps the layout of the others: `index.ts` calls `runPlugin()`, `plugin.ts` builds the handlers with `definePlugin`, and `auth.ts` signs the requests. A `client.ts` talks to the upstream, and a `catalog.ts` turns discovery and `plugin.yaml` into operations. Add a file only when a second concern appears.
-- Plugin-facing types (`PluginHandlers`, `OperationDescriptor`, …) come from `@synoikia/plugin-sdk`. Don't redeclare them.
-
-## Upstream data is `unknown`
-
-- Type responses, events and specs as `unknown` and narrow them with `isPlainObject`, `requireString`, `requireField` or a small type guard. No `any`.
-- Avoid `as`. When a cast is needed (a library gap, a record already checked), keep it next to the check that makes it true. `x!` is fine only right after a check or for a test fixture.
-- `satisfies` to check an object literal against a type without widening it.
-- With `noUncheckedIndexedAccess`, handle the `undefined` from `arr[i]` and `record[key]` (`?.`, `??`, an early return) rather than asserting it away.
-- A shape the code doesn't recognize fails closed: redact it or throw, don't pass it on.
-
-## Errors
-
-- Throw `PluginError` with an `ErrorCodes` value for failures core should see. Use `upstreamError` and `errorMessage` to map upstream failures. Messages name the operation and the cause, never a secret or a raw upstream body.
-- Return a discriminated union (`{ ok: true; … } | { ok: false; reason: … }`) for an expected outcome the caller branches on. Don't add a generic `Result<T, E>` type or library.
-- `catch (err)` gives `unknown`: narrow with `instanceof` or use `errorMessage(err)`.
-
-## Functions and data
-
-- Prefer plain functions and object literals. Use a class only for a client with state (a connection, a session, pending requests).
-- Small pure helpers over clever generics. Add a type parameter only when two real callers need it.
-- Fixed sets of values: an `as const` array and a union derived from it, never an `enum`.
-- Constants that are policy (limits, timeouts) live in `plugin.yaml` when they are plugin settings, else `UPPER_SNAKE` at the top of the module that owns them.

package/templates/repo/claude/_claude/skills/release-plugin/SKILL.md

@@ -1,42 +0,0 @@
----
-name: release-plugin
-description: Prepare a plugin release by bumping its version in manifest.json and package.json together, and optionally its minimum Synoikia version. Use when asked to release, publish, ship or bump the version of a plugin.
----
-
-# Release a plugin
-
-A release is a version bump merged to `main`. The Release workflow (`.github/workflows/release.yml`) then packs, signs, verifies and publishes every plugin whose manifest version isn't in the published index yet (see `RELEASING.md`). Nothing is published from a branch, and nothing here needs the signing key.
-
-## Steps
-
-1. **Pick the version** with semver against the last release (`git log --oneline -- plugins/<id>` shows what changed):
-   - patch: fixes, catalog corrections, wording.
-   - minor: new operations, connection fields or capabilities, compatible with existing instances. Also any `plugin.yaml` change that unlocks an operation, drops a `sensitiveParams`/`sensitiveResult` rule or overrides a classification to read. Call it out in the PR.
-   - major: a change that breaks existing instances, such as a renamed operation key, a removed connection field or a changed binding.
-
-   Released versions are immutable, so never reuse one. If the published index already has the version, `synoikia-plugin repo pack` skips the plugin and nothing is released.
-
-2. **Bump both files to the same version.** `synoikia-plugin check` (in the plugin's tests) and `repo pack` fail if they differ.
-   - `plugins/<id>/manifest.json` → `version`
-   - `plugins/<id>/package.json` → `version`
-
-3. **Minimum Synoikia version.** Only when the change needs a core feature that older Synoikia releases lack, add it to `package.json`:
-
-   ```json
-   "synoikia": { "minCoreVersion": "x.y.z" }
-   ```
-
-   Otherwise the manifest's `sdk` range decides which Synoikia versions can install it. If the plugin now needs a newer SDK, bump these ranges together, then run `pnpm install`:
-   - the `sdk` range in `manifest.json`
-   - the `@synoikia/plugin-sdk`, `@synoikia/core` and `@synoikia/create-plugin` ranges in `package.json`
-
-4. **Verify** that what will be packed builds and passes:
-
-   ```sh
-   pnpm --filter ./plugins/<id> test
-   pnpm typecheck && pnpm lint && pnpm format:check
-   ```
-
-5. In the PR description, name the plugin, the version, the user-visible changes and any `minCoreVersion`. Merging it publishes the release.
-
-Never touch `minisign.pub`, the `MINISIGN_SECRET_KEY` steps in the workflow, or the `index` release.

package/templates/workflow/base/_githooks/pre-commit

@@ -1,3 +0,0 @@
-#!/bin/sh
-# Refuses credential files by name, then scans the staged changes with gitleaks when it is installed.
-exec pnpm run --silent workflow pre-commit

package/templates/workflow/base/_githooks/pre-push

@@ -1,4 +0,0 @@
-#!/bin/sh
-# Runs the workflow checks that CI runs, except the red check. ALLOW_WORKFLOW=1 skips them once.
-[ "${ALLOW_WORKFLOW:-}" = "1" ] && exit 0
-exec pnpm run --silent workflow pre-push

package/templates/workflow/base/_github/workflows/workflow.yml

@@ -1,45 +0,0 @@
-# Written by `synoikia-plugin workflow sync`. Edit the template in via-justa/synoikia-core instead.
-name: Workflow
-
-on:
-  pull_request:
-    types: [opened, edited, synchronize, reopened, ready_for_review, labeled, unlabeled]
-
-permissions:
-  contents: read
-
-jobs:
-  workflow:
-    runs-on: ubuntu-latest
-    env:
-      BACKFILL: ${{ contains(github.event.pull_request.labels.*.name, 'backfill') && '--backfill' || '' }}
-      BASE: ${{ github.event.pull_request.base.sha }}
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          ref: ${{ github.event.pull_request.head.sha }}
-          fetch-depth: 0
-          persist-credentials: false
-      - uses: pnpm/action-setup@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version-file: .nvmrc
-          cache: pnpm
-      - run: pnpm install --frozen-lockfile
-      - run: pnpm workflow check-branch
-      - run: pnpm workflow check-features --base "$BASE" $BACKFILL
-      - run: pnpm workflow check-prose --base "$BASE" --pr-body
-      - run: pnpm workflow check-security-line --base "$BASE"
-      - run: pnpm workflow check-phases --base "$BASE" --red-green $BACKFILL
-
-  gitleaks:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-        with:
-          fetch-depth: 0
-          persist-credentials: false
-      - uses: gitleaks/gitleaks-action@ff98106e4c7b2bc287b24eaf42907196329070c7 # v2.3.9
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          GITLEAKS_ENABLE_COMMENTS: false

package/templates/workflow/base/docs/workflow.md

@@ -1,100 +0,0 @@
-# Workflow
-
-This repository builds every change spec first and test first. The rules below bind every contributor. CI checks them on each pull request. The git hooks run the same checks before a commit and a push.
-
-`synoikia-plugin workflow sync` writes this file from `@synoikia/create-plugin`. Do not edit it here. Change the template in `via-justa/synoikia-core` instead.
-
-## Steps
-
-One change is one slice: one rule of one feature, with three scenarios at most. Each slice gets its own branch and pull request.
-
-1. **Spec.** Write the scenarios in a feature file. Commit them as `spec: …`.
-2. **Architecture and plan.** Write the build plan: the slices in order, and the existing code each one reuses. Put it in the pull request description. Place the slice in the model in `docs/architecture/` when it adds or moves a part. Commit as `arch: …`.
-3. **Red.** Write the step definitions. Run the scenarios and see them fail because the behavior is missing. Commit as `test: …`.
-4. **Green.** Write the least code that makes the scenarios pass. Use existing code that does the same work. Commit as `feat: …` or `fix: …`.
-5. **Refactor.** Clean up with the scenarios green. Extract code that duplicates the same behavior into one shared function. Commit as `refactor: …`.
-6. **Pull request.** Push and open the pull request. Fill in the template.
-
-## Commits
-
-Each commit belongs to one phase. Its subject starts with the phase, and it changes only the files of that phase.
-
-| Prefix                 | Changes                                                            |
-| ---------------------- | ------------------------------------------------------------------ |
-| `spec:`                | Feature files only                                                 |
-| `arch:`                | The architecture model only                                        |
-| `test:`                | Step definitions, the World and unit tests only                    |
-| `feat:` `fix:`         | Code. Not feature files and not the model                          |
-| `refactor:`            | Code with the scenarios green. Not feature files and not the model |
-| `docs:` `chore:` `ci:` | Documents, tooling and CI. Not feature files and not the model     |
-
-A `feat:` or `fix:` commit that changes product code needs a `test:` commit before it. CI checks out that `test:` commit and runs its feature files. They must fail there. CI then runs them at the head of the branch, where they must pass.
-
-A requirement that turns out wrong while you build is not worked around. Change it in its own `spec:` commit, where the reviewer sees it.
-
-Pull requests merge by rebase, so every commit lands on `main`. A `spec:` or `test:` commit is red by design. Skip it in `git bisect` with `git bisect skip`.
-
-## Branches
-
-A branch name is `<component>/<summary>` in lowercase kebab-case. The summary is two to four words about the whole change: `core/auth-refactoring`.
-
-- The component is the package or plugin where the most important change lands, or `ci`, `docs`, `skills` or `deps`.
-- Do not use generated names, random words, session IDs or dates.
-- After a pull request merges, start follow-up work on a new branch.
-
-## Feature files
-
-Feature files live in `features/<domain>/<feature>.feature` inside the package or plugin they specify. Steps and the World live next to them, in `features/**/*.ts`.
-
-- **One feature per file, with an `@id:<kebab-case>` tag.** Other files refer to the feature by this id. The id never changes after a push.
-- **Every scenario is in a `Rule:`.** A rule groups the scenarios that show one business rule.
-- **Write outcomes, not solutions.** Say what someone can do and what they see. Do not name screens, clicks, endpoints, status codes, wire formats or tables.
-- **Write short scenarios.** Use five steps at most, with one `When` and one `Then`. A `Background:` has four steps at most.
-- **Use real values from the World.** Name the World's things, not a category. Write `Given the instance "nas-01" has 3 pools`, not `Given an instance with pools`.
-- **Write what someone can see in a `Then`.** Name what the admin, the agent or the upstream service observes, not an internal verdict.
-- **Use the field's standard terms and the glossary's words.** Use each term with one meaning.
-- **Tags.** Use only `@id:<kebab-case>`, `@backlog`, `@long-running` and `@exclusive`. `@backlog` marks a scenario not built yet, `@long-running` a slow scenario, and `@exclusive` a scenario that must run alone in its test process.
-- **No comments.** Put an explanation in the feature narrative.
-
-Scenarios run in vitest through quickpickle. They drive the product through its real interface: the MCP endpoints, the Admin API, the plugin entry or the portal in a browser. They never call internal services and never mock internal modules.
-
-## Tests
-
-Feature files are the only behavior tests. A new `*.test.ts` file must be a pure-function unit test in a `test/unit/` directory. Do not test libraries, frameworks or third-party APIs.
-
-## Writing
-
-All prose follows ASD-STE100 Simplified Technical English. This includes documents, skills, feature files and pull request descriptions.
-
-- Write short sentences: 20 words at most for an instruction, 25 for a description.
-- Write one instruction per sentence. Use the active voice and approved plain words.
-- Do not use semicolons. Write two sentences.
-- Do not use em dashes.
-- Write one topic per paragraph.
-- Do not repeat a fact. Link to the place that states it.
-- Prefer tables and lists to long paragraphs.
-
-## Security
-
-- Do not commit credential files. The pre-commit hook refuses `.env` files, private keys and secret files by name. CI runs gitleaks on every pull request.
-- A pull request that changes a security path needs a line of its own in its description: `Security audit: <boundary and findings>` or `Security audit: none. <why>`. The paths are in `synoikia.workflow.securityPaths` in the root `package.json`.
-
-## Checks
-
-Install the git hooks once per clone:
-
-```sh
-pnpm hooks:install
-```
-
-The hooks run the `workflow` script of the branch that you have checked out. Before you check out a pull request from someone you do not trust, read its changes to `.githooks/` and `package.json`.
-
-| Command                                    | Checks                                                       |
-| ------------------------------------------ | ------------------------------------------------------------ |
-| `pnpm workflow check-branch`               | The branch name                                              |
-| `pnpm workflow check-phases --base main`   | Commit prefixes and phases. `--red-green` runs the red check |
-| `pnpm workflow check-features --base main` | Feature files, the slice size and new test files             |
-| `pnpm workflow check-prose --base main`    | The writing rules on added lines                             |
-| `pnpm workflow pre-push`                   | All of the above, as the pre-push hook runs them             |
-
-A pull request labelled `backfill` specifies behavior that exists already. Its scenarios pass at once, so CI skips the red check and the slice size for it.

package/templates/workflow/claude/_claude/hooks/guard-branch.mjs

@@ -1,73 +0,0 @@
-// PreToolUse hook: denies git commands that create or push a branch whose name breaks docs/workflow.md › Branches.
-import { spawnSync } from 'node:child_process';
-
-let input = '';
-for await (const chunk of process.stdin) input += chunk;
-const { tool_input: toolInput = {}, cwd } = JSON.parse(input || '{}');
-const command = String(toolInput.command ?? '');
-
-const currentBranch = () =>
-  spawnSync('git', ['symbolic-ref', '-q', '--short', 'HEAD'], {
-    cwd: process.env.CLAUDE_PROJECT_DIR ?? cwd,
-    encoding: 'utf8',
-  }).stdout.trim();
-const names = new Set();
-for (const part of command.split(/&&|\|\|?|;|\n/)) {
-  const words = part
-    .trim()
-    .split(/\s+/)
-    .filter((w, i, all) => !/^\d*[<>]/.test(w) && !/^\d*[<>]+&?$/.test(all[i - 1] ?? ''));
-  const at = words.findIndex((w) => !/^[A-Za-z_][A-Za-z0-9_]*=/.test(w));
-  if (words[at] !== 'git') continue;
-  const [sub, ...args] = words.slice(at + 1).filter((w, i, all) => !(i > 0 && all[i - 1] === '-C') && w !== '-C');
-  const plain = args.filter((a) => !a.startsWith('-'));
-  if ((sub === 'checkout' || sub === 'switch') && args.some((a) => /^-[bcBC]$/.test(a)))
-    names.add(args[args.findIndex((a) => /^-[bcBC]$/.test(a)) + 1]);
-  else if (
-    sub === 'branch' &&
-    plain.length &&
-    !args.some((a) => /^-(?:d|D|l|a|r|v|vv|-list|-show-current|-delete)$/.test(a))
-  )
-    names.add(args.some((a) => /^-[mM]$/.test(a)) ? plain.at(-1) : plain[0]);
-  else if (sub === 'push' && !args.some((a) => a === '-d' || a === '--delete')) {
-    const refs = plain.slice(1).map((ref) => (ref.includes(':') ? ref.split(':').pop() : ref));
-    for (const ref of refs.length ? refs : ['HEAD']) names.add(ref === 'HEAD' ? currentBranch() : ref);
-  }
-}
-
-const clean = (n) =>
-  n
-    .replace(/^\+/, '')
-    .replace(/^refs\/heads\//, '')
-    .replace(/^['"]|['"]$/g, '');
-const denied = [];
-const unchecked = [];
-for (const name of [...names]
-  .filter(Boolean)
-  .map(clean)
-  .filter((n) => n && n !== 'HEAD')) {
-  if (!/^[A-Za-z0-9._/-]+$/.test(name)) {
-    denied.push(`${name}: use letters, digits, ".", "_", "-" and "/" only`);
-    continue;
-  }
-  const r = spawnSync('pnpm', ['run', '--silent', 'workflow', 'check-branch', name], {
-    cwd: process.env.CLAUDE_PROJECT_DIR ?? cwd,
-    encoding: 'utf8',
-  });
-  const out = `${r.stderr}${r.stdout}`.trim();
-  if (r.status === 0) continue;
-  if (out.startsWith('check-branch:')) denied.push(out.replace(/^check-branch: /gm, `${name}: `));
-  else unchecked.push(`${name}: ${out.split('\n')[0] ?? 'the check did not run'}`);
-}
-const decide = (permissionDecision, permissionDecisionReason) =>
-  console.log(
-    JSON.stringify({
-      hookSpecificOutput: { hookEventName: 'PreToolUse', permissionDecision, permissionDecisionReason },
-    }),
-  );
-if (denied.length)
-  decide(
-    'deny',
-    `Branch name breaks docs/workflow.md › Branches. Use <component>/<two to four words>.\n${denied.join('\n')}`,
-  );
-else if (unchecked.length) decide('ask', `Could not check the branch name:\n${unchecked.join('\n')}`);

package/templates/workflow/claude/_claude/skills/architect/SKILL.md

@@ -1,44 +0,0 @@
----
-name: architect
-description: >-
-  Plan the build and place it in the LikeC4 model in docs/architecture, by interviewing the user on each design
-  decision, layer by layer in arc42's views. Use it after the spec and before code, for every task. It replaces
-  plan mode: its build plan says which slices come in which order.
----
-
-# Architect
-
-**In:** the feature files of the task, with the first slice selected.
-**Out:** the build plan, and the task placed in the LikeC4 model in `docs/architecture/` with an `arch:` commit.
-
-Write only the model and the plan. Do not write code or diagram files.
-
-1. **Read the model.** If there is no model, this slice starts it, with just enough to place the slice.
-2. **Ask the design into the model, layer by layer.** Follow arc42's order: context and scope, then the building blocks level by level, then deployment. Ask in rounds, as `change-workflow` says. Write each answer into the model before the next round.
-3. **Send behavior questions back.** A question about what the product does belongs to the spec. Return it to `requirements-engineer`. Do not settle it in the model.
-4. **Write the build plan.** List the slices in order. For each slice, give its rule, the parts of the model it changes, and the slices it needs first. Name the existing code that each slice reuses or extracts. Ask the user about the order in one last round.
-5. **Push.** When no question is open and the user agrees, commit the model as `arch: …` and push. Put the build plan in the pull request description. Later slices update the plan in their own pull requests.
-
-## Rules for the model
-
-- Views follow arc42. Goals and quality live in the feature files.
-- A box with parts of its own gets a view at the next level.
-- A building-block view holds its subject's children and their direct neighbors. An element appears at one level only in a view.
-- Add a dynamic view only for a complex sequence: many elements, an order that matters, an asynchronous hand-off or a failure path. Never add one for each scenario.
-- **State a fact once.** A description says what an element is, in one sentence. What it does to another element is a relation. How a story runs is the feature file.
-- Applications share no storage. One application reaches another only through its API.
-- Model your own parts. A library you use is a technology line. A package you write is a `library` element.
-- Names come from the field's standard. Ask, as `change-workflow` says.
-- The design document links the views. It does not repeat them.
-
-## Layout
-
-- `likec4.config.mjs`: the project and its summary.
-- `models/base-model.c4`: element kinds, people, external systems, the system and its applications.
-- `models/<part>.c4`: one file for each container or package. Each file extends its parent.
-- `models/deployment.c4`: where each part runs.
-- `views/views.c4`: every view.
-
-## Done when
-
-No question is open, the user agrees the build plan, and the model places the next slice.

package/templates/workflow/claude/_claude/skills/change-workflow/SKILL.md

@@ -1,70 +0,0 @@
----
-name: change-workflow
-description: >-
-  How to carry a change from request to merged PR: size it, plan it, then run one slice at a time through
-  requirements, architecture and build, spec first and test first. Use it at the start of every task that will
-  change code, config, CI, tests or docs in this repo, even when the request is a question, a bug report or
-  "just do X", and before writing a plan. Examples: add a feature, an operation or an endpoint; fix a bug;
-  refactor a module; migrate a library; change the schema, auth or the gate; bump versions; "can you clean up
-  X". Not for questions that change nothing (explain, review, estimate), or for PR babysitting on a PR that
-  already exists.
----
-
-# Change workflow
-
-**The user decides. You build what the user decided.** The rules for specs, commits, branches, tests and prose are in `docs/workflow.md`. Read it before the first step. This skill says how you run them.
-
-## 1. Size the task
-
-| Small                                              | Big                                                     |
-| -------------------------------------------------- | ------------------------------------------------------- |
-| One concern in one package or plugin               | Several concerns, packages or plugins                   |
-| One rule, three scenarios at most                  | More than one slice                                     |
-| No security path in `CLAUDE.md`, or a one-line fix | A security path, an API contract, the SDK or the schema |
-
-Check the request against the repo before you plan. If the work is done already or the premise is wrong, show the evidence and ask what the user meant. If you are not sure of the size, treat the task as big.
-
-Do not use plan mode. The requirements and architecture steps are the plan:
-
-- `requirements-engineer` specifies the whole task wide. Every scenario outside the first slice gets `@backlog`.
-- `architect` places the task in the model and writes the build plan: the slices in order, with what each one needs first.
-- The user agrees the spec and the plan before any code. Each slice is then one pull request into `main`.
-
-## 2. Run one slice
-
-1. **Branch.** Create a branch from `main` with a name that passes `pnpm workflow check-branch`. Do not use a session's generated branch name.
-2. **Requirements.** Use `requirements-engineer`. Its output is the feature file and a `spec:` commit.
-3. **Architecture.** Use `architect`. Its output is the build plan and, when the slice adds or moves a part, an `arch:` commit.
-4. **Build.** Use `developer`. Its output is the `test:`, `feat:` or `fix:` and `refactor:` commits and a ready pull request.
-
-Move to the next step only when the user agrees that the current step is done. Skipping a step is the user's decision. Propose it and wait for a clear yes.
-
-## 3. Ask in rounds
-
-**Facts are yours. Decisions are the user's.** Find what the code, the specs and the model can tell you. Ask about everything that someone could decide in a different way.
-
-- Ask with `AskUserQuestion`, four questions at most for each call. Put your recommendation first and mark it "(Recommended)".
-- Write each answer into the file before you ask the next round.
-- Names come from the field's standard. Offer two or three terms with their source and ask. Do not pick a name silently.
-
-## 4. Subagents
-
-Subagents keep your context small. They do not change the structure of the work.
-
-- You own the slice, the branch, the commits and the pull request. Phases run in order, never in parallel.
-- You run the interviews and write the feature file yourself.
-- Give a subagent one bounded task with fixed inputs. Example: "Write the steps for `features/gate/deny.feature`. They must fail on a missing behavior, not on missing glue."
-- The subagent returns a short summary and its diff. You run the scenarios, check red or green, and make the commit.
-- The history must look the same as a run without subagents. CI checks the phases.
-
-## 5. The pull request
-
-- Open the pull request as a draft after the `spec:` commit. Watch it with `subscribe_pr_activity` until it merges or closes.
-- Run the repo's checks (`CLAUDE.md` › Commands) and `pnpm workflow pre-push` before each push.
-- Run the `security-reviewer` subagent when the diff touches a security path. Put its `Security audit:` line in the pull request description.
-- Mark the pull request ready only when every scenario of the slice is green and CI is green on its head.
-- When the change touches a user interface, send screenshots of each changed page and state before the pull request goes ready. Cover light and dark mode, and desktop and mobile width when the layout changed.
-
-## 6. Long tasks
-
-A task that runs for more than about an hour needs tool calls that run without approval. If the session is not in Auto mode, say so and suggest **Auto** in the mode menu next to the prompt box. Do not change the mode yourself.

package/templates/workflow/claude/_claude/skills/developer/SKILL.md

@@ -1,57 +0,0 @@
----
-name: developer
-description: >-
-  Build one slice test first: the Gherkin scenarios run as the tests through quickpickle in vitest, against the
-  product's real interface, red then green then refactor. Audit a slice that crosses a trust boundary, then mark
-  the PR ready. Use it once the user agreed the feature file and, when needed, the model.
----
-
-# Developer
-
-**In:** the feature file, the model in `docs/architecture/` and the design document.
-**Out:** working code for the slice, and its pull request marked ready.
-
-**Build only a small slice.** The slice is the scenarios that are not `@backlog` and not green yet: one rule, three scenarios at most. If there are more, or none, stop. Ask the user to select a slice with `requirements-engineer`.
-
-**The spec, the model and the design document win over the prompt.** If they are missing, contradict each other or say nothing about what you need, stop and ask the user.
-
-**The spec is read-only.** A scenario that is wrong or cannot be built goes back to `requirements-engineer`. Never change the feature file to make it pass.
-
-## The World
-
-The feature files are what runs. Quickpickle runs them in vitest. The steps drive the product through its real interface:
-
-- the MCP endpoints and the Admin API over HTTP
-- a plugin through the core harness
-- the portal in a browser with Playwright
-
-Steps never call internal services and never mock internal modules.
-
-The World sets up what the scenarios name, from synthetic data. It uses the product's test entry points, such as `@synoikia/core/testing` and `startFakeHttp`. If the World needs a new entry point, add it to the product's testing API in its own `test:` commit. A fake identity provider is an example.
-
-## Loop
-
-1. **Run the slice. See it red.** The undefined steps are the work list.
-2. **Write the next scenario's steps.** Keep them plain, specific to the scenario and with their values written out. Run them. They must fail because the behavior is missing, not because the glue is broken. Commit as `test: …`.
-3. **Write the least code that makes the scenario pass.** Search first for code that does the same work: a helper, a service, a schema or a component. Use it. Commit as `feat: …` or `fix: …`.
-4. **Refactor** with the scenario green. Find code that duplicates the same behavior, in this slice or in existing code. Extract it into one shared function and make each caller use it. Commit as `refactor: …`.
-5. **Repeat** until every scenario of the slice is green.
-
-## Unit tests
-
-Write a unit test only for a pure function that is worth a check of its own. Put it in `test/unit/`. Never test a library, a framework or a third-party API.
-
-## Audit
-
-Run the `security-reviewer` subagent when the slice crosses a trust boundary. Examples are an entry point, auth, crypto, secrets, TLS, the sandbox, the permission gate, dependencies and CI. Untrusted input that reaches an interpreter is one too. Fix a confirmed finding test first. Put the result in the pull request description on a line of its own:
-
-- `Security audit: <the boundary and what the review found>`
-- `Security audit: none. <why the slice crosses no boundary>`
-
-## Pull request
-
-Run `pnpm workflow pre-push` and the repo's checks. Push and mark the pull request ready. Its description names the scenarios it makes green.
-
-## Done when
-
-Every scenario of the slice is green and the suite passes. There is no code that the scenarios do not need, and no code that does the same work twice. The audit ran if it was needed, and the pull request is ready.

package/templates/workflow/claude/_claude/skills/requirements-engineer/SKILL.md

@@ -1,59 +0,0 @@
----
-name: requirements-engineer
-description: >-
-  Turn a rough idea, a bug report or existing behavior into a Gherkin feature file by interviewing the user one
-  scenario at a time, and cut it into thin slices. Use it to specify what to build before any design or code,
-  and to backfill a spec for behavior that exists already.
----
-
-# Requirements engineer
-
-**In:** a rough idea, a bug report, or a part of the design document to backfill.
-**Out:** a feature file in `features/<domain>/<feature>.feature` and a `spec:` commit.
-
-The feature file rules are in `docs/workflow.md` › Feature files. Read them first.
-
-## Requirements come from the user
-
-Ask for the requirements. Do not invent them, and do not read them out of the code. Code shows what exists, not what should exist. A spec copied from code keeps its accidents.
-
-In **backfill** mode, the design document and the existing tests are the source. Turn each statement into a scenario and show it to the user. The user confirms, changes or removes it. Label the pull request `backfill`.
-
-## Plan wide, build small
-
-Specify as much as the user wants. Before the push, the user selects the slice to build next: one rule, three scenarios at most. Tag every other scenario `@backlog`.
-
-Recommend the thinnest slice yourself, and say what you left out:
-
-- **The simplest case first.** One actor, one value, the case that ends well.
-- **One rule.** Include the case that it refuses, because that case states the rule.
-- **The extras last.** Speed, configuration and rare edges are slices of their own.
-
-Split further by SPIDR: spike, path, interface, data, rules.
-
-Put everything the slice does not need in a `@backlog` scenario. Nothing gets lost, and nothing rides along.
-
-## One scenario at a time
-
-Never write a second scenario before the user agrees the first. A file with scenarios the user has not seen one by one is a guess.
-
-1. **Find where it lives.** Read the `features/` folders first. If a feature covers the behavior already, extend that file.
-2. **Get one example.** Ask what happened, or what would happen: who did what, to what, and what they saw. Write it with its values. Then find the wording that makes it general.
-3. **Ask what else is true.** Ask for the case that is refused, the case where nothing arrives, and the case that goes the other way. A slice where every scenario ends well states no rule.
-4. **Ask only what the product does.** The folders and the wording are yours. How it gets built is the architect's.
-
-## The World
-
-The World is the set of synthetic things that the scenarios run in: instances, plugins, agents, roles and their values. Build it in the first slices and grow it slice by slice. People appear by role or by a made-up number, never by a real name. Later scenarios name the World's things, never placeholders.
-
-## Changing a rule
-
-When you remove or loosen a rule, list every scenario, skill line and document that names it. Change them all in the same slice. Ask the user whether stored data breaks under the new rule.
-
-## Push
-
-Read the file again against the rules and ask about what you find in one last round. When the user agrees, commit as `spec: …`, push and open a draft pull request.
-
-## Done when
-
-No question is open, the user agrees the spec, and the user selected the slice to build.

package/templates/workflow/claude/_claude/skills/technical-writing/SKILL.md

@@ -1,35 +0,0 @@
----
-name: technical-writing
-description: >-
-  How to write prose in this repo: ASD-STE100 Simplified Technical English, short sentences, no semicolons, no
-  em dashes, one topic per paragraph, no repetition. Use it before you write or change any document, README,
-  design section, skill, feature file, commit message body or pull request description.
----
-
-# Technical writing
-
-The rules are in `docs/workflow.md` › Writing. `pnpm workflow check-prose` checks the mechanical ones. This skill says how to apply them.
-
-## Sentences
-
-- Write 20 words at most in an instruction and 25 at most in a description.
-- Write one instruction in each sentence. Start an instruction with a verb: "Run the checks", not "The checks should be run".
-- Use the active voice and simple tenses: present, past and future.
-- Use approved plain words. Write "use", not "utilize". Write "start", not "commence". Write "show", not "demonstrate".
-- Use a term with one meaning only. Use the glossary's terms where a glossary exists.
-- Do not use semicolons. Write two sentences.
-- Do not use em dashes. Write two sentences, or use a colon before a list or an example.
-
-## Paragraphs and structure
-
-- Write one topic in each paragraph. Start the paragraph with its topic.
-- Use a table or a list when you compare items or give steps.
-- Give the steps of a procedure as a numbered list, one action for each step.
-- Do not repeat a fact. State it in one place and link to that place.
-- Describe what is true now. Put history in commit messages and pull requests.
-
-## Check your text
-
-1. Read each sentence. Cut each word that adds nothing.
-2. Split each sentence that holds two statements.
-3. Run `pnpm workflow check-prose --base main`.