feat: add CEDA workflow skills (ship, pr-reply, branch-pr, gate, actions-ci, pypi-project)

[oinkspook]

Pull Request Description

Type of Change

• New feature

Description of Changes

Voegt zes herbruikbare Claude-skills toe onder .claude/skills/, die de CEDA-werkwijze voor GitHub-repos codificeren:

• ship — de review→fix→commit→push-lus met guardrails: verifieer dat werk echt draait vóór "done", check git-state na checkouts/rebases, stage bestanden op naam (geen git add -A).
• pr-reply — reageren op PR-reviewcomments: elk comment op merites beoordelen (ook "vanuit claude"-comments tegen de echte code checken), threaded replies plaatsen, de fixing-commit-SHA citeren.
• branch-pr — een PR openen/afronden met een ingevulde template i.p.v. de lege template, en geen "WIP" in de titel.
• gate — een falende SonarCloud/CodeQL quality gate ontleden: echte defects onderscheiden van metric-artefacten (coverage-0, duplicatie, JS-false-positives) en eerlijk rapporteren wat overblijft.
• actions-ci — GitHub Actions / tests / pipelines: het reusable-workflow-patroon, uv + matrix, security scanning (bandit/semgrep/codeql/sonarcloud).
• pypi-project — PyPI-publicatie: src-layout + setuptools + uv, PEP 621 metadata, Trusted Publishing (OIDC) op v*-tags met TestPyPI-preview.

Afgeleid van de bestaande praktijk in cedanl/1cijferho, eencijfer, minio-file, sdp-tools.

Testing Instructions

Skills zijn Markdown-instructiebestanden (geen code). Verificatie:

• Frontmatter (name, description) aanwezig en geldig in elke SKILL.md.
• Geen machine-specifieke paden of persoonlijke verwijzingen.
• Interne [[skill]]-verwijzingen resolven naar bestaande skills.

Dependencies

Geen.

Additional Information

• De SDP/platform-skills (gitlab-ci, sdp-onboard, surf-sdp-helm-flux, sdp-secrets-management) komen in een aparte PR, omdat twee daarvan een bestaande auteur-review verdienen.
• styler::style_active_file() is niet van toepassing (geen R-code).

Checklist

• My code follows the project's coding standards
• I have updated the documentation accordingly (skills zijn zelf de documentatie)

🤖 Generated with Claude Code

[StevenRamondt]

@oinkspook Ik kan je skill inhoudelijk niet echt beoordelen, maar claude vind ze inhoudelijk sterk :).

Ze (ook bij andere PR overigens) wijken op een paar kleine, (onbelangrijke) puntjes af van create-skill conventies. Ik weet alleen niet of dat de absolute waarheid is (iets wat we waarschijnlijk voor deze opdracht hadden moeten vasstellen :)) en/of dat hier echt nodig is. Maar enige wat me opviel:

1. Geen ## Workflow met de regel When the user invokes /:. Bron: de structuur-template in create-skill (stap 4, "Structuur") — en create-skill/mkdocs-setup doen het zo voor.
2. Cross-skill verwijzingen met [[skill]] i.p.v. /skill-naam. Bron: create-skill, Conventies-tabel: "Verwijzingen naar andere skills → /skill-naam syntax".
3. Geen ## Important-sectie (met randvoorwaarden + wat de skill níét doet). Bron: structuur-template in create-skill (stap 4). Sommige hebben een eigen variant (## Principle, ## Guardrails), maar niet de conventienaam.
4. Enkele descriptions starten niet met een werkwoord (ship, surf-sdp-helm-flux, sdp-secrets-management). Bron: create-skill stap 5: "Begint met een werkwoord".

[oinkspook]

Bedankt Steven, scherpe review — en je punten kloppen, het zijn echte create-skill-conventies. Ik heb ze verwerkt, met één nuance die ik wil toelichten.

Punt 1 (## Workflow + "When the user invokes /naam:") — hier zit een subtiliteit. Skills komen op twee manieren binnen: expliciet (/naam) óf impliciet — Claude leest continu de description van elke skill en laadt de body automatisch zodra je vraag matcht. Dat splitst onze skills in twee soorten:

• Actie-skills (ship, pr-reply, branch-pr, gate) — een procedure die je uitvoert. Die krijgen ## Workflow met stappen, precies volgens create-skill.
• Kennis-skills (helm, docker, gitlab-ci, sram-oidc, …) — geen procedure, maar conventies/feiten die Claude's volgende actie goed maken. Die worden meestal impliciet getriggerd (je plakt een Flux-error → Claude laadt de kennis → juiste fix). Een letterlijke "When the user invokes /helm:" is daar een vierkante pen in een rond gat.

Voor die kennis-skills gebruik ik daarom een ## When this applies-sectie i.p.v. ## Workflow — zelfde intentie (wanneer is dit relevant), eerlijke bewoording. De actie-skills volgen de conventie letterlijk.

Punten 2, 3, 4 volledig overgenomen: [[skill]] → /skill-naam, een ## Important-sectie met randvoorwaarden + wat de skill níét doet, en werkwoord-first descriptions.

Goede vraag trouwens of dit harde regels moeten zijn — misschien de moeite waard om de ## When this applies-variant in create-skill zelf te documenteren, zodat toekomstige kennis-skills het ook zo doen. Wat denk je?