rsc-universal 0.1.1

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,190 @@
+---
+name: git-workflow
+description: "Use when naming or scoping a branch, writing or fixing a commit message, untangling history (rebase vs merge vs squash), or cutting a versioned release — the portable git-convention layer that works on any repo. Triggers: 'name this branch', 'is this commit message conventional?', 'rebase or merge before the PR?', 'squash these wip commits into one', 'my git log is a mess', 'tag a release', 'write release notes', 'what version should this release be?', 'clean up history before review', 'limpia el historial antes del PR', '¿qué versión le toca a esta release?', 'deja los commits en formato convencional'. Covers Conventional Commits 1.0.0, SemVer tags, branch hygiene, force-push safety, and gh pr/release mechanics. NOT the I'm-done land-it decision and pre-ship checklist (that is ship), NOT setting up an isolated checkout before coding (that is worktrees), NOT CI/CD release automation in GitHub Actions (that is deployment)."
+tags: [git, version-control, conventional-commits, semver, pull-request]
+recommends: [ship, worktrees, 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
+```
+
+## Conventional Commits grammar
+
+Write every commit to **Conventional Commits 1.0.0**. The structure:
+
+```text
+type(scope)!: subject
+
+body — what changed and why, wrapped, optional
+
+BREAKING CHANGE: description of the incompatible change
+Fixes #123
+```
+
+- `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.
+
+```text
+Bad   fix stuff
+Bad   updates
+Bad   Fixed the login bug.            (past tense, capitalized, trailing period)
+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.
+```
+
+**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 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           | conventional `type(scope): imperative subject`        |
+| 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 is conventional; `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,47 @@
+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: "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: ship
+    why: The land/merge decision and pre-ship safety checklist are ship's phase, not the conventions layer.
+  - prompt: "Set up an isolated checkout so I don't dirty main before I start coding"
+    route_to: worktrees
+    why: Workspace isolation up front, before any code is touched.
+  - 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: review
+    why: Adversarial diff reading, 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.
+      - 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.

package/skills/git-workflow/references/interactive-rebase.md

@@ -0,0 +1,89 @@
+# Interactive rebase — cleaning history before review
+
+The everyday path is one clean conventional commit per change. Reach for this only when a branch has
+accumulated scratch commits you need to collapse, reorder, reword, or drop before a PR. This is a
+private-branch operation: only rewrite history nobody else has built on.
+
+## Start the rebase
+
+```bash
+git rebase -i HEAD~4        # edit the last 4 commits
+git rebase -i main          # replay everything since main; clean the whole branch narrative
+```
+
+Git opens a todo list, oldest commit first. Each line starts with a verb you can change:
+
+| Verb         | Effect                                                            |
+|--------------|-------------------------------------------------------------------|
+| `pick`       | keep the commit as-is                                             |
+| `reword` (r) | keep the changes, edit the message (fix a non-conventional subject) |
+| `edit` (e)   | pause at this commit to amend its content                        |
+| `squash` (s) | fold into the previous commit, **combine** both messages         |
+| `fixup` (f)  | fold into the previous commit, **discard** this message          |
+| `drop` (d)   | delete the commit entirely (its changes are removed)             |
+| reorder      | move a line up/down to reorder commits                           |
+
+Typical cleanup: turn two `wip` commits into `fixup` lines under the real commit they belong to, and
+`reword` the survivor into a proper `type(scope): subject`.
+
+```text
+pick   a1b2c3d feat(auth): add PKCE flow
+fixup  d4e5f6a wip
+fixup  7g8h9i0 wip more
+```
+
+## Autosquash — the disciplined way
+
+If you mark fixups *as you go*, the rebase organizes itself:
+
+```bash
+git commit --fixup a1b2c3d          # creates "fixup! feat(auth): add PKCE flow"
+git commit --squash a1b2c3d         # same, but keeps the message for editing
+git rebase -i --autosquash main     # auto-orders the fixup!/squash! lines under their targets
+```
+
+Set `git config --global rebase.autosquash true` to make `--autosquash` the default.
+
+## The conflict loop
+
+A rebase replays commits one at a time, so a conflict can surface on any of them:
+
+```bash
+# rebase stops, reports a conflict
+git status                  # see which files conflict
+# edit the files, resolve the <<<<<<< markers
+git add <resolved-files>
+git rebase --continue       # advance to the next commit
+# repeat until the rebase finishes
+```
+
+Escape hatches:
+
+```bash
+git rebase --skip           # drop the current commit and continue (rare; you lose its changes)
+git rebase --abort          # bail out entirely — branch returns to its pre-rebase state
+```
+
+## Push the rewritten branch
+
+A rebase rewrites hashes, so the remote branch diverges. Push with the lease, never bare force:
+
+```bash
+git push --force-with-lease     # refuses if the remote moved since your last fetch
+```
+
+If `--force-with-lease` is rejected, someone pushed to your branch — fetch and reconcile before you
+overwrite anything. Do not escalate to `--force`.
+
+## Recovery — you have a net
+
+Every commit you "lost" to a rebase is still reachable until git garbage-collects it. `reflog` records
+where `HEAD` has been:
+
+```bash
+git reflog                          # find the SHA from before the rebase, e.g. HEAD@{5}
+git reset --hard a1b2c3d            # restore the branch to that exact state
+```
+
+This recovers a botched rebase, a wrong `drop`, or a reset you regret. The reflog makes interactive
+rebase safe to experiment with on a *private* branch — never on shared history.