feat(skills): worktree, plan en cedafy-claude-md — de keten brainstorm → plan → uitvoering rond

.claude/skills/README.md

@@ -0,0 +1,62 @@
+# CEDA-skills
+
+De org-brede skillcollectie. Eén map per skill, met een `SKILL.md` die de frontmatter uit de
+Agent Skills-spec draagt plus het CEDA-`metadata`-blok. Zie `skills-ontology` voor wat die
+velden betekenen en `create-skill` voor het aanmaken en valideren.
+
+```bash
+python3 .claude/skills/create-skill/scripts/validate-skill.py .claude/skills            # hele collectie
+python3 .claude/skills/create-skill/scripts/validate-skill.py .claude/skills/<naam>     # één skill
+```
+
+## Herkomst: wat we uit superpowers hebben overgenomen
+
+[superpowers](https://github.com/obra/superpowers) (MIT, © 2025 Jesse Vincent) is een
+persoonlijke plugin, geen org-tooling. Wat het team nodig heeft is daarom gevendord: een kopie
+in deze collectie, met `ceda-origin: extended` en `ceda-upstream` als onderhoudslink, zodat
+bijwerken mogelijk blijft.
+
+| CEDA-skill | Upstream | Aangepast voor CEDA |
+|---|---|---|
+| `brainstorm` | `brainstorming` | Nederlands en caveman-bondig; aannames-eerst met confidence in plaats van een vragenronde; samenvatting landt in `docs/specs/` als input voor `/plan` |
+| `plan` | `writing-plans` | Plan in `docs/plans/`; input is de samenvatting uit `docs/specs/`; taken worden issues via `/write-issue` in plaats van een losse checklist |
+| `worktree` | `using-git-worktrees` | CEDA-branchnaamgeving; detecteert eerst of je al in een worktree zit |
+
+`brainstorm` is een randgeval: de tekst is in huis geschreven (commit `19d7e2f`), maar de
+ruggengraat is die van upstream — hard gate, "te simpel bestaat niet", 2-3 aanpakken, in delen
+presenteren, self-review, doorgeven aan het plan. Daarom `extended` en niet `own`: verandert
+upstream die ruggengraat, dan is dat hier het lezen waard.
+
+## Wat we bewust niet hebben overgenomen
+
+**De reviewer-subagent-prompts.** Upstream levert `brainstorming/spec-document-reviewer-prompt.md`
+en `writing-plans/plan-document-reviewer-prompt.md`: losse prompts om een subagent de spec of
+het plan te laten nakijken. Geen van beide upstream-`SKILL.md`'s roept ze nog aan; writing-plans
+zegt zelfs expliciet *"This is a checklist you run yourself — not a subagent dispatch"*. De
+bestanden komen uit een plan van januari 2026 en zijn blijven liggen toen die review naar inline
+verhuisde. Onze self-review-stap in `brainstorm` en `plan` is die inline-versie. Overnemen zou
+een ronde terugzetten die upstream zelf geschrapt heeft.
+
+**De visual companion.** Upstream `brainstorming` heeft een browsergebaseerde metgezel voor
+mockups en diagrammen: een gids van ~300 regels plus ~1.400 regels node/bash (lokale HTTP- en
+WebSocket-server met session-key, `--open` naar een browsertab). Niet overgenomen, om vier
+redenen:
+
+1. `brainstorm` is een beslisskill; de output is een beslis-samenvatting, geen mockup. Visuele
+   keuzes horen bij `ui-designer`, `ontwerper-digitaal-product` en `vormgever-npuls-huisstijl`.
+2. Gebundelde scripts zijn oppervlak 3 uit `externe-skill-audit`. Een meegeleverde server vergt
+   een volledige audit en een expliciete `allowed-tools`-grant, in een publieke repo.
+3. Upstream noemt hem zelf *"still new and can be token-intensive"*.
+4. 1.400 gevendorde regels die we op upstream moeten blijven volgen.
+
+Wil iemand dit alsnog: eigen skill, eigen audit — niet stil aan `brainstorm` plakken.
+
+**`executing-plans` en `subagent-driven-development`.** Upstream eindigt `writing-plans` in een
+keuze tussen die twee uitvoeringsskills. Wij hebben ze niet geport; `plan` stap 8 doet de
+verkorte versie zelf (verse subagent per taak, review tussendoor). Als de uitvoering complexer
+wordt dan die stap aankan, is dit het eerste dat alsnog moet komen.
+
+---
+
+Deze pagina hoort op termijn in de gepubliceerde documentatie (`docs/`), niet in `.claude/`.
+Hij staat hier zolang de skillcollectie zelf nog geen plek in de mkdocs-navigatie heeft.

.claude/skills/brainstorm/SKILL.md

@@ -1,16 +1,40 @@
 ---
 name: brainstorm
-description: Structureer een brainstorm van idee naar getoetst besluit vóór implementatie, met een beslis-samenvatting en aanbevelingen — geen code of bestanden. Wanneer iemand een idee wil uitwerken of een besluit wil voorbereiden voordat er code of een plan komt.
+description: Structureer een brainstorm van idee naar getoetst besluit vóór implementatie, en leg dat besluit na de go vast als document dat het plan daarna kan lezen — geen code. Wanneer iemand een idee wil uitwerken of een besluit wil voorbereiden voordat er code of een plan komt. LET OP — ná de go hoort `plan`, niet dit.
+allowed-tools: Read Write Grep Glob Bash AskUserQuestion Skill
+license: MIT — afgeleid van superpowers (© 2025 Jesse Vincent)
+metadata:
+  ceda-id: ceda.brainstorm
+  ceda-version: "0.2.0"
+  ceda-type: workflow
+  ceda-subtype: ""
+  ceda-origin: extended
+  ceda-upstream: superpowers:brainstorming
+  ceda-source: https://github.com/obra/superpowers/blob/main/skills/brainstorming/SKILL.md
+  ceda-activation: command
+  ceda-binding: default
+  ceda-execution: inline
+  ceda-scope: org
+  ceda-verifies: observable
 ---
 
 # Brainstorm
 
-Structured brainstorming from an idea to a tested decision, before any implementation or plan. The output is a decision summary with recommendations — never code, files, or commits. Respond to the user in Dutch, caveman-terse.
+Structured brainstorming from an idea to a tested decision, before any implementation or plan. The output is a decision summary with recommendations — never code. Respond to the user in Dutch, caveman-terse.
+
+Shares its spine with `superpowers:brainstorming` (MIT, © 2025 Jesse Vincent). Changed for
+CEDA: Dutch and caveman-terse, assumptions-first with confidence levels instead of a question
+round, and the summary lands in `docs/specs/` as the input for `/plan`. Which parts of upstream
+are deliberately not here, and why: [`.claude/skills/README.md`](../README.md).
 
 ## Workflow
 
 When the user invokes `/brainstorm [optioneel: onderwerp]`:
 
+Create a todo per numbered step below and work them off in order. Steps that do not
+apply — no real choice in step 4, for instance — you close with one line saying why.
+The todo list is what keeps the gate from being skipped on a topic that feels simple.
+
 ### Hard gate
 
 Until an explicit go:
@@ -19,6 +43,9 @@ Until an explicit go:
 - No scaffolding, no installing dependencies, no "quick POC"
 - Do not start other skills or plan mode; the only follow-up after go is planning or building what was agreed
 
+The go lifts the gate for exactly one file: the decision summary from step 7. Nothing else
+gets written, ever, by this skill.
+
 "Too simple to brainstorm" does not exist: for simple topics the summary is a few lines, but it always comes.
 
 ### Communication
@@ -31,7 +58,13 @@ Before asserting anything, read the relevant files, docs, and recent commits. Wh
 
 ### 2. Scope check
 
-Multiple independent parts are fine.
+Does the idea cover several independent subsystems — parts that could be built, tested and
+used without each other? Say so before you ask anything else, and decompose first: name the
+parts, say how they relate, propose an order. Then brainstorm the first part through the rest
+of this workflow. Each part gets its own summary and its own `/plan`.
+
+Do not spend questions on the details of something that has to be split anyway. `plan` splits
+the same way (one plan per subsystem); deciding it here saves the round trip.
 
 ### 3. Assumptions first
 
@@ -64,8 +97,59 @@ Go? Dan [plan maken / bouwen wat hierboven staat].
 
 Wait for an explicit go. On corrections: adjust, self-review again, present again.
 
+### 8. Write the summary down
+
+Only after the go. Save the same summary — unchanged, plus a `# <onderwerp>` heading and the
+date — to `docs/specs/YYYY-MM-DD-<onderwerp>.md` and commit it.
+
+This is not bookkeeping. `plan` reads this file: it needs a decision that was already made,
+and after a context reset, a new session, or a `/worktree` in between, the chat summary is
+gone. Whatever is not in the file does not reach the plan.
+
+Does the repo have no `docs/specs/` yet? Then propose creating it — one line, with the path
+you intend to use — and create it once the user agrees. Say no, and the summary stays in the
+chat; then also say what that costs: `plan` has no input and the decision has to be repeated
+by hand.
+
+### 9. Hand over
+
+The brainstorm ends here; it does not turn into building. Two routes:
+
+| Scope of what was agreed | Next step |
+|---|---|
+| Multiple steps or multiple files | `/plan` on the spec — write the implementation plan first |
+| The diff fits in one sentence | Build it directly, no plan |
+
+Say which one it is and why in one line. Close with the literal command, path filled in, and
+send the user to a clean session for it:
+
+> Besluit staat in `docs/specs/2026-08-15-<onderwerp>.md`. Meerdere bestanden, dus eerst een
+> plan. Draai `/clear` en daarna:
+>
+> ```
+> /plan docs/specs/2026-08-15-<onderwerp>.md
+> ```
+
+Do not offer to run `/plan` yourself in this session. The plan has to be written from the file,
+by a reader without this conversation in context — that is the test of whether the summary is
+complete, and running it here skips exactly that test. The same reason the plan itself is
+executed by a fresh subagent per task.
+
+Do not ask the user to choose between planning and building when the criterion above already
+decides it.
+
+## Verificatie
+
+`ceda-verifies: observable` — the brainstorm is done when the decision summary exists as a
+file and a reader who was not part of this conversation can tell from it what was decided,
+what is an assumption, and what the next step is. Concretely: `docs/specs/<datum>-<onderwerp>.md`
+is committed, every locked decision in the chat is in it, and it names `/plan` or the one-line
+build as the follow-up.
+
 ## Important
 
-- Building starts only after an explicit go; the only follow-up is planning or building what was agreed.
+- Building starts only after an explicit go; the only follow-up is `/plan` or building what
+  was agreed. The one file this skill writes is the summary in `docs/specs/`, and only after
+  the go.
 - All user-facing output is in Dutch; keep it terse and recommendation-first.
 - Avoid the anti-patterns: working through a checklist of questions; asking what you can read yourself; premature constraints (narrowing the solution before the problem is clear); reopening locked decisions; listing options without a recommendation; multiple follow-ups without priority (one primary suggestion, alternatives secondary).

.claude/skills/cedafy-claude-md/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: cedafy-claude-md
+description: Past de CEDA-baseline voor projectinstructies toe op een repo die er al een heeft — vult aan wat ontbreekt, laat staan wat al gedekt is, en legt elke tegenstrijdigheid als keuze voor in plaats van te overschrijven. Gebruik bij "projectinstructies bijwerken", "CEDA-conform maken" of "sessie-afspraken toevoegen". LET OP — bij een nieuwe repo doet `init-repo` dit al.
+allowed-tools: Read Write Edit Grep Glob Bash AskUserQuestion
+compatibility: Requires the gh CLI to fetch the template from cedanl/.github
+metadata:
+  ceda-id: ceda.cedafy-claude-md
+  ceda-version: "0.1.0"
+  ceda-type: workflow
+  ceda-subtype: ""
+  ceda-origin: own
+  ceda-upstream: ""
+  ceda-source: werkafspraken/_claude-md-template.md
+  ceda-activation: command
+  ceda-binding: default
+  ceda-execution: inline
+  ceda-scope: org
+  ceda-verifies: observable
+---
+
+# Cedafy CLAUDE.md
+
+Bring an existing repository's `CLAUDE.md` in line with the CEDA baseline without throwing away
+what the repository already decided for itself. Insert and adjust, never replace.
+
+Is there no `CLAUDE.md` yet? Then this is a fill-in job: take the template, fill in the
+`<...>` slots from step 2, write it, done. The rest of this skill is about the harder case.
+
+## Workflow
+
+When the user invokes `/cedafy-claude-md [optional: path to the repository]`:
+
+### 1. Read both sides
+
+The template lives in `cedanl/.github`, not in the repository you are working in:
+
+```bash
+gh api repos/cedanl/.github/contents/werkafspraken/_claude-md-template.md --jq .content | base64 -d
+```
+
+`gh` must run outside the sandbox here, and `unset GITHUB_TOKEN` first — see `branch-pr`.
+
+Then read the repository's own `CLAUDE.md`, in full. Not a grep for headings: the point of this
+skill is judging what the existing text *means*, and a heading does not tell you that.
+
+### 2. Read the repository, for the slots
+
+The template has `<...>` slots. Fill them from the repository itself, not from assumptions:
+
+| Slot | Where it comes from |
+|---|---|
+| Stack, language version | `pyproject.toml`, `DESCRIPTION`, `package.json` |
+| Package manager | a `uv.lock`, `renv.lock`, `package-lock.json` |
+| Run, test, lint commands | the scripts in that same file, the CI workflow, the README |
+
+Cannot find a command? Leave the slot empty and say so at the end. An invented test command is
+worse than a missing one — it fails in a session where nobody expects it.
+
+### 3. Classify every template point
+
+Three buckets. Do this per point, not per section, because one section can be half covered.
+
+| Bucket | Meaning |
+|---|---|
+| *ontbreekt* | The current `CLAUDE.md` does not say this at all |
+| *al gedekt* | The current text says the same thing in different words |
+| *tegenstrijdig* | The current text says something else |
+
+What counts as contradictory:
+
+| Current `CLAUDE.md` | Template | Bucket |
+|---|---|---|
+| "werk gewoon op main" | worktree before the first write | tegenstrijdig |
+| "draai altijd de volledige suite" | one targeted test file | tegenstrijdig |
+| "vraag altijd eerst om bevestiging" | brainstorm before building | al gedekt |
+| an own commit flow with extra steps | no counterpart in the template | repo-eigen, leave alone |
+
+**A doubtful case counts as contradictory**, so it becomes a question. One question too many
+beats an agreement that is silently overwritten — the user wrote that line for a reason you
+cannot see from here.
+
+### 4. Insert what is missing, leave what is covered
+
+*Ontbreekt* → insert directly, in the template's wording. Do not ask; that is the whole point
+of the skill.
+
+*Al gedekt* → do nothing. A second line saying the same thing in other words makes the file
+longer and the instruction weaker.
+
+### 5. Put every contradiction to the user
+
+Per contradictory point, three options via the choice menu:
+
+1. follow the template
+2. keep the current line
+3. combine — **with the proposed combined text in the option itself**, so the choice is
+   concrete instead of a promise
+
+Four questions per call at most, so batch them. Do not ask them one at a time in chat: this is
+a fixed set of answers, and a menu is faster and yields better answers than an open question.
+
+### 6. Write and report
+
+Process the answers, leave repo-specific sections untouched, and write the file. Then report,
+in Dutch:
+
+> **Bijgewerkt:** `CLAUDE.md`
+> - Toegevoegd: <points>
+> - Overgeslagen omdat het al gedekt was: <points>
+> - Jouw keuze: <point> → <chosen>
+> - Slots die ik niet kon invullen: <slots, or "geen">
+
+## Let op: de volgorde van het bestaande bestand blijft staan
+
+The temptation is to rewrite the file into the template's order — it reads better and the diff
+looks clean. Do not. Someone put those sections in that order, and a reordering diff hides
+which lines actually changed in the review. Insert at the place where the point belongs in the
+existing structure, and add a section at the end only when there is no such place.
+
+## Verificatie
+
+`ceda-verifies: observable` — done when all three hold, checked against the diff:
+
+- every repo-specific section from before is still present, in the same order
+- every point classified as *tegenstrijdig* has a user decision behind it, none silently
+  overwritten
+- no point appears twice, once in the template's words and once in the repository's
+
+## Important
+
+- Never remove a repo-specific section, and never rewrite the file into the template's order.
+  Insert and adjust, not replace.
+- Every contradiction goes to the user. A doubtful case is a contradiction.
+- The reverse direction — noticing that a repo-specific rule actually belongs in the org
+  template — is out of scope. That needs a view of every `CLAUDE.md` at once and belongs with
+  repo-context-as-data.
+- For a repository that has no `CLAUDE.md` because it is brand new, `init-repo` writes the
+  template as part of the scaffold.

.claude/skills/init-repo/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: init-repo
-description: Initialize a new cedanl repository with the correct CEDA project structure. Use when starting a new project, creating a new repo, or scaffolding a repository.
+description: Initialize a new cedanl repository with the correct CEDA project structure. Use when starting a new project, creating a new repo, or scaffolding a repository. LET OP — voor een repo die al bestaat en alleen de projectinstructies mist is er `cedafy-claude-md`.
 ---
 
 # Initialize CEDA Repository
@@ -159,29 +159,22 @@ project-name/
 
 #### CLAUDE.md
 
-Use the template from `standards/project-structure.md`:
+Do not write this one by hand. Fetch the org baseline and fill in its `<...>` slots:
 
-```markdown
-# [Project Name]
-
-## Overview
-[description]
-
-## Standards
-Follow CEDA technical standards: https://github.com/cedanl/.github/tree/main/standards/README.md
-
-## Tech Stack
-[R or Python], key packages.
+```bash
+gh api repos/cedanl/.github/contents/werkafspraken/_claude-md-template.md --jq .content | base64 -d
+```
 
-## Project Structure
-[generated directory layout]
+Fill the slots from the answers in step 1 and the structure you just generated: one line on
+what this is, the stack and package manager, and the run/test/lint commands for the chosen
+language. Leave the `## Valkuilen` section empty — it grows per repository, on evidence.
 
-## How to Run
-[commands for install + run]
+Do **not** add a module map, an architecture description, or code style rules. Claude reads
+those from the code itself, style is a linter's job, and every line in this file is loaded in
+every session — a longer file means a file that gets half ignored.
 
-## Data
-[input/output formats, where data comes from]
-```
+An existing repository that does not have this baseline yet is a job for `/cedafy-claude-md`,
+not for this skill.
 
 #### README.md