@damiangilgonzalez/harness 1.3.7

package/skills/gdpr-privacy/references/dsar-and-consent.md

@@ -0,0 +1,83 @@
+# DSAR runbook, LIA template & consent banner
+
+## Data-subject-rights (DSAR) runbook
+
+**The clock: one month from receipt** (Art. 12(3)). Extendable by **two further months** for complex or numerous requests — *only if* you tell the person within the first month, with reasons. Silent extension is a breach.
+
+1. **Log receipt + date.** The date the request arrives starts the clock — log it the day it lands, not the day you notice it.
+2. **Verify identity proportionately.** Confirm who they are using data you already hold where possible. Do not over-collect to verify (no passport scan to release an email you already have). Over-collection is itself a processing violation.
+3. **Route by right:**
+
+| Right | Article | What you deliver |
+|---|---|---|
+| Access | 15 | A copy of the data + purposes, recipients, retention, source, rights context |
+| Rectification | 16 | Correct inaccurate/incomplete data and tell recipients |
+| Erasure | 17 | Delete, subject to the exceptions below |
+| Restriction | 18 | Stop processing but keep storing, on stated grounds |
+| Portability | 20 | The data the person provided, in a structured, commonly used, machine-readable format |
+| Objection | 21 | Stop processing based on legitimate interest / direct marketing |
+
+4. **Apply erasure exceptions** (Art. 17(3)) — erasure is *not* absolute. Carve-outs: legal-obligation retention (e.g. tax records), establishment/exercise/defence of legal claims, and freedom of expression and information. State which exception applies and why; erase the rest.
+5. **Charge / refuse only for manifestly unfounded or excessive requests** (Art. 12(5)) — then a reasonable fee or refusal, *with reasons* and the right to complain. Default is free of charge.
+
+## Legitimate Interests Assessment (LIA) — three-part template
+
+Required (Art. 6(1)(f)) before relying on legitimate interest. Date it and keep it on file. No LIA, no legitimate-interest basis.
+
+```text
+LIA — [PURPOSE], dated [DATE], owner [NAME]
+
+1. PURPOSE TEST — Is there a legitimate interest?
+   Interest: [STATE THE INTEREST]
+   Whose: [controller's / third party's]
+   Legitimate & specific? [yes/no + why]
+
+2. NECESSITY TEST — Is the processing necessary for it?
+   Could you achieve the purpose a less-intrusive way? [yes/no]
+   If yes, you cannot rely on legitimate interest — minimise or change basis.
+
+3. BALANCING TEST — Do the individual's rights override the interest?
+   Reasonable expectations: would the person expect this? [yes/no]
+   Impact on the individual: [low/medium/high + why]
+   Safeguards (opt-out, minimisation, transparency): [LIST]
+   Conclusion: [interest prevails / does not — change basis or stop]
+```
+
+## Compliant cookie-banner config shape
+
+Three controls at equal weight; non-essential categories off until the user chooses; nothing fires before consent.
+
+```json
+{
+  "blockUntilConsent": true,
+  "controls": [
+    { "id": "accept-all", "label": "Accept all",  "weight": "primary" },
+    { "id": "reject-all", "label": "Reject all",  "weight": "primary" },
+    { "id": "customize",  "label": "Customize",   "weight": "primary" }
+  ],
+  "categories": [
+    { "id": "necessary",   "default": true,  "lockable": true,  "purpose": "strictly necessary" },
+    { "id": "analytics",   "default": false, "purpose": "usage measurement" },
+    { "id": "marketing",   "default": false, "purpose": "advertising" },
+    { "id": "preferences", "default": false, "purpose": "personalization" }
+  ],
+  "withdrawable": true,
+  "note": "ePrivacy Directive transposed per member state — confirm per-country rules"
+}
+```
+
+Key invariants: `reject-all` is present and at the same `weight` as `accept-all`; `blockUntilConsent` is `true`; only `necessary` defaults to `true`; consent is `withdrawable`.
+
+## verify.sh banlist rationale
+
+`scripts/verify.sh <artifact>` is a heuristic completeness/parity check on an emitted artifact, not a judge of legal correctness. It exists because the two most common, mechanical failures are catchable by text:
+
+- **Privacy policy** missing an Art. 13/14 load-bearing token — a lawful basis, a rights mention, a retention mention, the right to complain to a supervisory authority, a contact. These are the precise omissions the 2026 transparency enforcement action targets.
+- **Boilerplate-lie / placeholder leftovers** — unfilled `[BRACKET]`, "any and all data" catch-alls, "industry-standard security" with no Article 32 reference. These signal a blind template, not a ROPA-derived policy.
+- **Cookie banner** with an `accept` control but no `reject`/`decline`/`rebuig`/`rechazar` control — encodes the reject-as-easy-as-accept rule mechanically.
+
+It exits 0 when given no argument (never blocks) and only fails on a real artifact that violates a rule. It does not and cannot replace counsel review.
+
+---
+
+**Before relying on any DSAR decision, LIA, or banner:** have a qualified privacy counsel / your DPO review it. Drafting aid, not legal advice.

package/skills/gdpr-privacy/references/privacy-policy-blueprint.md

@@ -0,0 +1,99 @@
+# Privacy policy blueprint (Articles 13/14)
+
+Fill-in sections for an Art. 13/14-complete privacy policy. Each carries a one-line **why required**. Replace every `[BRACKET]` — leftover brackets are a `verify.sh` failure and a signal the policy is a blind template. Write each section to match the ROPA; never describe data the product does not process.
+
+Order: controller → DPO → purposes + basis → recipients → transfers → retention → rights → complaint → automated decision-making → source.
+
+## 1. Controller identity & contact
+
+```text
+Data controller: [LEGAL ENTITY NAME], [REGISTERED ADDRESS].
+Contact: [EMAIL] / [POSTAL ADDRESS].
+EU representative (if controller is outside the EEA): [NAME / CONTACT, or "not applicable"].
+```
+Why required: Art. 13(1)(a) — the data subject must know who is responsible and how to reach them.
+
+## 2. Data Protection Officer
+
+```text
+DPO contact: [DPO EMAIL / ADDRESS, or "We have not appointed a DPO because [REASON]."]
+```
+Why required: Art. 13(1)(b) — if a DPO exists or is mandatory, their contact must be published.
+
+## 3. Purposes and lawful basis (one block per purpose)
+
+```text
+Purpose: [e.g. "Account creation and service delivery"]
+  Data used: [CATEGORIES]
+  Lawful basis: [consent | contract | legal obligation | vital interests |
+                 public task | legitimate interests]
+  If legitimate interests, the interest is: [STATE IT; LIA on file dated [DATE]]
+```
+Why required: Art. 13(1)(c) — purposes and the lawful basis *per purpose* are mandatory; legitimate interest must name the interest.
+
+## 4. Recipients / categories of recipients
+
+```text
+We share personal data with:
+  - [SUB-PROCESSOR / CATEGORY] — [purpose, e.g. "hosting", "analytics", "email"]
+  - [...]
+```
+Why required: Art. 13(1)(e) — the data subject must know who receives their data.
+
+## 5. International transfers
+
+```text
+We transfer personal data outside the EEA to: [COUNTRY / IMPORTER].
+Transfer mechanism: [2021 Standard Contractual Clauses, module [C2C|C2P|P2P|P2C] |
+                     EU-US Data Privacy Framework (importer certified [DATE]) |
+                     adequacy decision].
+Transfer impact assessment: [completed [DATE] | "not applicable, no transfer"].
+```
+Why required: Art. 13(1)(f) / 44-49 — transfers outside the EEA need a stated mechanism; SCCs without a TIA where one is needed is incomplete.
+
+## 6. Retention
+
+```text
+We retain [CATEGORY] for [PERIOD], then [delete | anonymise].
+Where no fixed period applies, the criteria are: [CRITERIA].
+```
+Why required: Art. 13(2)(a) — retention period or the criteria to set it must be disclosed; "as long as necessary" alone is not enough.
+
+## 7. Data-subject rights
+
+```text
+You have the right to: access, rectification, erasure, restriction, objection,
+and data portability, and to withdraw consent at any time where processing is
+based on consent.
+To exercise any right, contact [EMAIL/CHANNEL]. We respond within one month.
+```
+Why required: Art. 13(2)(b) + Art. 15-22 — the rights list and *how* to exercise it are mandatory.
+
+## 8. Right to lodge a complaint
+
+```text
+You have the right to lodge a complaint with a supervisory authority, in
+particular in your country of residence or work — for example [AUTHORITY NAME,
+e.g. the AEPD in Spain / the APDCAT in Catalonia / the CNIL in France].
+```
+Why required: Art. 13(2)(d) — the right to complain to a supervisory authority is a mandatory disclosure (a frequent omission `verify.sh` checks for).
+
+## 9. Automated decision-making / profiling
+
+```text
+[We do not carry out automated decision-making with legal or similarly
+significant effects. | We use automated decision-making for [PURPOSE];
+the logic is [MEANINGFUL DESCRIPTION] and the consequences are [...].]
+```
+Why required: Art. 13(2)(f) / 22 — existence and meaningful logic of automated decisions must be disclosed.
+
+## 10. Source of data (Art. 14 case only)
+
+```text
+Where we did not collect your data from you directly, the source is: [SOURCE].
+```
+Why required: Art. 14(2)(f) — when data is obtained from a third party, the source must be disclosed.
+
+---
+
+**Before publishing:** have a qualified privacy counsel or your DPO review this policy against the actual processing. This blueprint is a drafting aid, not legal advice.

package/skills/gdpr-privacy/scripts/verify.sh

@@ -0,0 +1,84 @@
+#!/usr/bin/env bash
+# verify.sh — Art. 13/14 completeness + reject-parity + boilerplate-lie check
+# for a GDPR artifact (privacy policy / cookie-banner config / DPA / LIA).
+# Read-only. Takes the artifact file as $1.
+# No argument => prints usage and exits 0 (never blocks when not given an artifact).
+# Exits non-zero only when a real artifact violates a rule.
+set -euo pipefail
+
+artifact="${1:-}"
+
+if [ -z "$artifact" ]; then
+  echo "usage: verify.sh <artifact-file>"
+  echo "Checks a GDPR artifact for: missing Art. 13/14 disclosures in a privacy"
+  echo "policy, placeholder/boilerplate-lie leftovers, and a cookie banner that"
+  echo "has an accept control but no equally-available reject control."
+  echo "No file given — nothing to check."
+  exit 0
+fi
+
+if [ ! -f "$artifact" ]; then
+  echo "verify.sh: not a file: $artifact" >&2
+  exit 2
+fi
+
+fail=0
+
+# --- Detect artifact type loosely by content (case-insensitive). ---
+is_policy=0
+if grep -niE 'privacy|personal data|pol[ií]tica de privacidad|pol[ií]tica de privacitat' "$artifact" >/dev/null; then
+  is_policy=1
+fi
+is_banner=0
+if grep -niE 'cookie' "$artifact" >/dev/null && grep -niE 'accept|aceptar|acceptar' "$artifact" >/dev/null; then
+  is_banner=1
+fi
+
+# --- Privacy-policy completeness: each load-bearing Art. 13/14 token. ---
+if [ "$is_policy" -eq 1 ]; then
+  missing=""
+  grep -niE 'lawful basis|legal basis|legitimate interest|consent|base (legal|jur[ií]dica)|contract' "$artifact" >/dev/null || missing="$missing lawful-basis"
+  grep -niE 'right to|data[- ]subject right|access|erasure|rectification|portability|derechos' "$artifact" >/dev/null || missing="$missing data-subject-rights"
+  grep -niE 'retention|retain|conservaci[óo]n|how long|retenci[óo]' "$artifact" >/dev/null || missing="$missing retention"
+  grep -niE 'supervisory authorit|lodge a complaint|reclamaci[óo]n|autoridad de control|autoritat de control' "$artifact" >/dev/null || missing="$missing complaint-to-supervisory-authority"
+  grep -niE 'contact|email|e-mail|address|contacto|contacte|@' "$artifact" >/dev/null || missing="$missing contact"
+  if [ -n "$missing" ]; then
+    echo "FAIL: privacy policy is missing required Art. 13/14 element(s):$missing"
+    fail=1
+  fi
+fi
+
+# --- Boilerplate-lie / placeholder leftovers (any artifact). ---
+if grep -nE '\[[A-Z0-9 _./-]+\]' "$artifact" >/dev/null; then
+  echo "FAIL: unfilled [BRACKET] placeholder(s) — finish the artifact:"
+  grep -nE '\[[A-Z0-9 _./-]+\]' "$artifact" | sed 's/^/  /'
+  fail=1
+fi
+
+if grep -niE 'any and all (data|information)' "$artifact" >/dev/null; then
+  echo "FAIL: 'any and all data' catch-all — describe only what is actually processed:"
+  grep -niE 'any and all (data|information)' "$artifact" | sed 's/^/  /'
+  fail=1
+fi
+
+if grep -niE 'industry[- ]standard security' "$artifact" >/dev/null; then
+  if ! grep -niE 'article 32|art\.? *32' "$artifact" >/dev/null; then
+    echo "FAIL: 'industry-standard security' with no Article 32 reference — cite Art. 32 and the actual measures:"
+    grep -niE 'industry[- ]standard security' "$artifact" | sed 's/^/  /'
+    fail=1
+  fi
+fi
+
+# --- Cookie banner: accept present but no reject control. ---
+if [ "$is_banner" -eq 1 ]; then
+  if ! grep -niE 'reject|decline|rebuig|rebutjar|rechazar|rechazo' "$artifact" >/dev/null; then
+    echo "FAIL: cookie banner has an accept control but no reject/decline control —"
+    echo "      reject must be as easy as accept (add an equal-weight Reject-all)."
+    fail=1
+  fi
+fi
+
+if [ "$fail" -eq 0 ]; then
+  echo "OK: $artifact passed Art. 13/14 completeness, placeholder, and reject-parity checks."
+fi
+exit "$fail"

package/skills/git-workflow/SKILL.md

@@ -0,0 +1,214 @@
+---
+name: git-workflow
+description: "Use when naming or scoping a branch, writing or fixing a commit message, picking the gitmoji for a commit, untangling history (rebase versus merge versus squash), or cutting a versioned release — the portable git-convention layer for any repo. Covers gitmoji + Conventional Commits, SemVer tags, branch hygiene, force-push safety and gh pr/release mechanics. NOT the land-it decision and pre-ship checklist (that is `ship`), NOT an isolated checkout before coding (that is `worktrees`), NOT CI/CD release automation (that is `deployment`)."
+tags: [git, version-control, conventional-commits, gitmoji, semver, pull-request]
+recommends: [deployment, github-actions]
+origin: risco
+---
+
+# git-workflow — the grammar and hygiene of version control
+
+Git history is a message to the next human who reads `git log`, runs `git blame` on a broken line,
+or bisects a regression at 2am. That human is usually future-you. **Every rule in this skill exists
+to make the next reader's job faster**, not to make this moment cheaper. A repo with legible branch
+names, conventional commits, and a clean linear narrative is a repo you can reason about; a repo with
+`wip`, `fix stuff`, and force-pushed shared history is one you fight.
+
+This is the **portable convention layer**. It is independent of any SDD phase or CI platform — it is
+the grammar that `../ship/SKILL.md`, `../worktrees/SKILL.md`, and `../deployment/SKILL.md` all lean on.
+It does not decide *whether to land* the work (that is ship) and it does not automate releases in a
+pipeline (that is deployment). It tells you how to name, commit, untangle, and tag — correctly.
+
+## Branch naming
+
+Name a branch from its *intent*, prefixed by its kind, as a kebab-case slug. Keep it short-lived:
+hours to days, not weeks. Long branches drift from `main` and turn into merge pain.
+
+| Prefix       | Use for                                      | Why                                              |
+|--------------|----------------------------------------------|--------------------------------------------------|
+| `feat/`      | a new capability                             | matches the `feat` commit type; signals a MINOR  |
+| `fix/`       | a bug fix                                     | matches `fix`; signals a PATCH                    |
+| `hotfix/`    | an urgent fix landing straight to production  | flags "skip the slow path" to reviewers          |
+| `chore/`     | tooling, deps, config — no product behavior  | keeps non-feature noise out of the feature log   |
+| `docs/`      | documentation only                            | reviewers can fast-track, no test gate needed    |
+| `refactor/`  | restructure without behavior change           | sets the expectation: tests stay green, no new behavior |
+
+Slug rules: derive it from the issue title or the one-sentence intent, lowercase, dash-separated, no
+spaces or `/` inside the slug. Optionally suffix the issue number.
+
+```text
+Bad   my-stuff            (kind unknown, intent unknown)
+Bad   eric-branch-2       (names the author and a counter, not the work)
+Good  feat/oauth-pkce-flow
+Good  fix/expired-refresh-token-401
+Good  chore/bump-node-22
+```
+
+## Commit grammar — gitmoji + Conventional Commits
+
+Write every commit to **Conventional Commits 1.0.0**, opened by a **gitmoji**. The structure:
+
+```text
+<gitmoji> type(scope)!: subject
+
+body — what changed and why, wrapped, optional
+
+BREAKING CHANGE: description of the incompatible change
+Fixes #123
+```
+
+- The **gitmoji is mandatory** and comes first — the intention of the change, readable in one glyph
+  when you scan `git log --oneline`. `type` is what tooling reads; the emoji is what humans read.
+- `type` is mandatory. `scope` in parentheses is optional. `!` before the colon marks a breaking change.
+- Subject: imperative mood ("add", not "added"/"adds"), ≤72 chars, no trailing period.
+- Body explains *why*, not *what the diff already shows*. Separate from subject by a blank line.
+- Footers go last. `Fixes #123` / `Closes #123` in the body auto-closes that issue when the PR merges.
+
+Type → SemVer effect:
+
+| Type                              | SemVer bump | Notes                                              |
+|-----------------------------------|-------------|----------------------------------------------------|
+| `feat`                            | MINOR       | a new capability                                   |
+| `fix`                             | PATCH       | a bug fix                                           |
+| `docs`, `chore`, `refactor`, `test`, `build`, `ci`, `perf`, `style`, `revert` | none | allowed, but no implicit version bump              |
+| any type with `!` or a `BREAKING CHANGE:` footer | **MAJOR** | overrides the above regardless of type             |
+
+`BREAKING CHANGE` **must be uppercase** in the footer; the type/scope units are case-insensitive but
+write them lowercase by convention.
+
+Type → gitmoji, the everyday set (the full 75-emoji table, and *why* the emoji never replaces the
+type, are in **`references/gitmoji.md`**):
+
+| Type       | gitmoji | Type       | gitmoji | Type      | gitmoji |
+|------------|---------|------------|---------|-----------|---------|
+| `feat`     | ✨      | `refactor` | ♻️      | `build`   | 📦️      |
+| `fix`      | 🐛      | `test`     | ✅      | `style`   | 🎨      |
+| `docs`     | 📝      | `perf`     | ⚡️      | `revert`  | ⏪️      |
+| `chore`    | 🔧      | `ci`       | 👷      | breaking  | 💥      |
+
+Pick by **intention**, not by which file changed, and prefer the specific one: 🚑️ for a production
+hotfix, 🩹 for a trivial non-critical fix, 🔥 for a deletion, 🚚 for a rename, ⬆️ for a dep bump,
+🔖 for a release commit.
+
+```text
+Bad   fix stuff
+Bad   updates
+Bad   Fixed the login bug.            (past tense, capitalized, trailing period)
+Bad   fix(auth): reject expired refresh tokens        (no gitmoji)
+Bad   ✨ added a search endpoint                       (gitmoji but no type → no derivable bump)
+Good  🐛 fix(auth): reject expired refresh tokens
+Good  ✨ feat(api): add /v2/search endpoint with cursor paging
+Good  ♻️ refactor(parser): extract token scanner, no behavior change
+```
+
+A breaking change, both forms equivalent:
+
+```text
+💥 feat(api)!: drop the legacy /v1 search endpoint
+
+BREAKING CHANGE: /v1/search is removed; callers must migrate to /v2/search.
+```
+
+If the repo runs a **strict** conventional parser (commitlint, semantic-release) it anchors the type
+at position 0 and rejects the emoji prefix. Either widen its `headerPattern` — the config is in
+`references/gitmoji.md` — or move the emoji behind the header (`feat(api): ✨ add cursor paging`),
+which every parser accepts. Both forms satisfy this convention; dropping the gitmoji does not.
+
+**Authorship is always Eric.** Never add a `Co-Authored-By: Claude` trailer, never a
+"Generated with" footer, never any line crediting an AI tool — in a commit *or* a PR body. The work
+is Eric's; the agent is a tool, like the compiler.
+
+## History hygiene — rebase, merge, or squash?
+
+Decide by who else has the commits. The lease rule below is non-negotiable.
+
+| Situation                                            | Do this                                              | Why                                                        |
+|------------------------------------------------------|------------------------------------------------------|------------------------------------------------------------|
+| Private branch, only you have it, want linear history | `git rebase main`, then `git push --force-with-lease`| rebase rewrites hashes; safe because nobody built on them  |
+| Branch others have pulled / built on                  | `git merge main` — **never** rebase it               | rebase changes every hash; collaborators' work diverges    |
+| Noisy PR (many `wip` commits)                         | squash-merge into one gitmoji + conventional commit            | `main` gets one meaningful entry, not 9 scratch commits    |
+| Already pushed, shared, *and* you rewrote it          | **STOP** — coordinate, or `git revert` instead       | force-pushing shared history breaks everyone downstream     |
+
+After a rebase, push with `--force-with-lease`, never bare `--force`:
+
+```bash
+git push --force-with-lease   # refuses if the remote moved since you fetched — catches a teammate's push
+git push --force              # blindly overwrites — can erase a teammate's commits
+```
+
+The interactive cleanup loop (`rebase -i`, `fixup`/`squash`/`reword`/`drop`, `--autosquash`,
+the conflict→continue cycle, and recovery via `git reflog`) is a long branchy procedure — see
+**`references/interactive-rebase.md`** rather than reaching for it on every commit.
+
+## Releases
+
+Derive the version bump from the commit log, never by guessing. Scan the commits since the last tag:
+
+- any `BREAKING CHANGE:` / `!` → **MAJOR** (`v1.4.2` → `v2.0.0`)
+- otherwise any `feat:` → **MINOR** (`v1.4.2` → `v1.5.0`)
+- otherwise only `fix:`/others → **PATCH** (`v1.4.2` → `v1.4.3`)
+
+Tag with the `vMAJOR.MINOR.PATCH` form, annotated, then create the release with auto-generated notes:
+
+```bash
+git tag -a v2.0.0 -m "v2.0.0"
+git push origin v2.0.0
+gh release create v2.0.0 --generate-notes              # notes via the GitHub Release Notes API
+gh release create v2.0.0 --generate-notes --draft      # stage notes, publish later
+gh release create v2.0.0-rc.1 --generate-notes --prerelease
+```
+
+GitHub auto-assigns the "latest" label by semver order unless you set it. With release immutability
+enabled, **a published release's tag cannot be edited or deleted** — get the version right before you
+publish.
+
+```text
+Bad   added a feature + a breaking config change, tagged v1.5.0   (breaking change → must be MAJOR)
+Good  same changes → v2.0.0, bump derived from the BREAKING CHANGE footer in the log
+```
+
+Automating any of this on tag push (a `release.yml` workflow, OIDC to a registry) is **deployment** —
+see `../deployment/SKILL.md`. This skill covers the manual/local release act.
+
+## PR mechanics — then hand off to ship
+
+Open the PR with autofilled title/body from the commits, against the right base:
+
+```bash
+gh pr create --fill --base main          # title/body from commits; --base falls back to repo default
+```
+
+Put `Fixes #123` in the body to link and auto-close the issue on merge. A PR body should let the
+reviewer understand the change without reading every line of the diff.
+
+The **decision to land** — direct-merge vs PR vs park, the pre-ship safety checklist, the actual
+merge — belongs to `../ship/SKILL.md`. This skill only makes the branch, commits, and PR body clean
+enough to hand over. Setting up the isolated checkout *before* you start coding is
+`../worktrees/SKILL.md`.
+
+## Anti-patterns
+
+| Anti-pattern                                          | Why it hurts                                              | Instead                                              |
+|-------------------------------------------------------|-----------------------------------------------------------|------------------------------------------------------|
+| `git push --force` on a shared branch                 | silently erases teammates' commits                        | `--force-with-lease`, or don't rewrite shared history |
+| `git commit -m "wip"` / `"fix"` / `"updates"`         | the log carries zero signal for the next reader           | `<gitmoji> type(scope): imperative subject`           |
+| Commit message with no gitmoji                         | `git log --oneline` reads as a wall of undifferentiated text | pick the intention's emoji (`references/gitmoji.md`) |
+| Mixing unrelated changes in one commit                | can't revert or review one concern in isolation           | one logical change per commit                         |
+| Long-lived branch (weeks)                             | diverges from `main`, merge becomes a battle              | short-lived; rebase or merge `main` in often          |
+| Hand-computing the semver bump                        | breaking change shipped as a MINOR → broken downstream    | derive the bump from the commit log                   |
+| Rebasing a public/shared branch                       | rewrites hashes others built on                           | merge shared branches; rebase only private ones       |
+| Committing generated/secret files                     | leaks credentials, bloats history irreversibly            | `.gitignore`; rotate any secret that slipped in       |
+| `BREAKING CHANGE` lowercase                            | tooling won't detect it → wrong (too-low) bump            | uppercase `BREAKING CHANGE:` in the footer            |
+| PR with no description                                | reviewer reverse-engineers intent from the diff           | `--fill` plus a why, link the issue                   |
+| Tagging a release with no notes                       | users can't tell what changed                             | `gh release create --generate-notes`                  |
+| `Co-Authored-By: Claude` / "Generated with" footer    | forges authorship onto a tool                             | author is always Eric; no AI attribution              |
+
+## Checklist — before a PR or a release
+
+- [ ] Working tree clean (`git status`), no stray or generated files staged.
+- [ ] Branch rebased on / merged with current `main`; no avoidable conflicts.
+- [ ] Every commit carries its gitmoji **and** a conventional header; `wip`/scratch commits squashed away.
+- [ ] No secrets, no AI-attribution trailers.
+- [ ] PR body explains the why and links the issue (`Fixes #`).
+- [ ] (Release) version bump **derived from the commit log**, tag is `vX.Y.Z`, annotated.
+- [ ] (Release) `gh release create vX.Y.Z --generate-notes`; version confirmed before publishing (immutable once published).

package/skills/git-workflow/evals/README.md

@@ -0,0 +1,10 @@
+# Evals — git-workflow
+
+These are routing and capability checks for the `git-workflow` skill. Run them with the repo's eval
+harness: load `cases.yaml`, fire each `should_trigger` and `should_not_trigger` prompt at the router,
+and confirm the trigger ones select `git-workflow` while the negatives route to their stated sibling
+(`ship`, `worktrees`, `deployment`, `review`). For the `capability` entry, give the scenario to the
+skill and judge the produced commit plan, semver bump, and `gh release create` command against the
+`must_include` rubric — the bump is MAJOR, the breaking change uses an uppercase `BREAKING CHANGE:`
+footer, the push uses `--force-with-lease`, and there is no AI-attribution trailer. No code is
+executed and the skill emits no artifact, so this is a judgment pass, not a build.

package/skills/git-workflow/evals/cases.yaml

@@ -0,0 +1,52 @@
+skill: git-workflow
+
+should_trigger:
+  - prompt: "Is this commit message conventional? 'fixed the login bug'"
+    why: Core Conventional Commits grammar check — past tense, no type, capitalized; the skill rewrites it.
+  - prompt: "Should I rebase or merge this feature branch before opening the PR?"
+    why: History-strategy decision — rebase private / merge shared — owned by the hygiene decision table.
+  - prompt: "My git log is full of wip commits, clean it up before review"
+    why: Non-obvious phrasing; routes to squash/interactive-rebase to collapse scratch commits.
+  - prompt: "What version should this release be — we added a new endpoint and a breaking config change?"
+    why: SemVer bump derived from the commit log; breaking change forces MAJOR.
+  - prompt: "Limpia el historial y deja los commits en formato convencional antes del PR"
+    why: Spanish trigger covering history cleanup plus conventional-commit formatting.
+  - prompt: "Name a branch for the OAuth PKCE work"
+    why: Branch-naming convention — feat/ prefix plus kebab slug from intent.
+  - prompt: "Which gitmoji goes on this commit — I deleted a deprecated module"
+    why: Gitmoji selection by intention (🔥 remove code, not ♻️ refactor); the commit-grammar layer owns the emoji.
+  - prompt: "Mi commitlint rechaza el commit por el emoji delante del type"
+    why: Spanish; the strict-parser escape hatch (widen headerPattern or move the emoji behind the header) lives in this skill.
+  - prompt: "Tag v2.1.0 and write the release notes"
+    why: Release mechanics — annotated tag plus gh release create --generate-notes.
+
+should_not_trigger:
+  - prompt: "I'm done and verified, land this work into main"
+    route_to: none
+    why: The land/merge decision and pre-ship safety checklist have no dedicated shipping skill in this catalog; git-workflow only owns the conventions layer.
+  - prompt: "Set up an isolated checkout so I don't dirty main before I start coding"
+    route_to: none
+    why: Workspace isolation up front, before any code is touched, has no dedicated skill in this catalog.
+  - prompt: "Write a GitHub Actions workflow that publishes a release on tag push"
+    route_to: deployment
+    why: CI/CD release automation, not the manual/local release act.
+  - prompt: "Review this diff for bugs before we merge"
+    route_to: code-review
+    why: Adversarial diff reading is code-review's job, not git mechanics.
+  - prompt: "Containerize the app and deploy it to Coolify"
+    route_to: deployment
+    why: Build and deploy mechanics to a platform.
+
+capability:
+  - scenario: >
+      A private feature branch has 4 messy commits: one adds a feature, one removes a deprecated
+      config flag (a breaking change), and two are "wip". Produce (a) a clean conventional-commit
+      plan, (b) the correct semver bump for the next release, and (c) the gh release create command.
+    must_include:
+      - Collapses the two "wip" commits via squash or fixup and explains why (one meaningful entry in main).
+      - Identifies a feat commit and a BREAKING CHANGE footer written in uppercase.
+      - Every proposed commit message opens with a gitmoji (✨ for the feature, 💥 for the breaking removal) before the conventional header.
+      - Bump is MAJOR because of the breaking change, with a tag of the form vX.0.0.
+      - Uses gh release create vX.0.0 --generate-notes (or an equivalent that produces notes).
+      - Uses git push --force-with-lease (not bare --force) for the post-rebase push.
+      - Does NOT add a Claude Co-Authored-By or "Generated with" footer; authorship stays Eric.