@damiangilgonzalez/harness 1.3.7

package/skills/shortform-strategy/scripts/verify.sh

@@ -0,0 +1,176 @@
+#!/usr/bin/env bash
+#
+# verify.sh — structural linter for a produced shortform strategy doc.
+#
+# WHAT IT DOES (read-only; never edits, writes, or hits the network)
+#   Static checks over ONE strategy/decisions file you point it at
+#   (markdown — e.g. docs/wiki/shortform/strategy.md):
+#     1. Required structure -> FAIL each missing:
+#        - a positioning / one-promise statement,
+#        - a cadence number (a per-week figure),
+#        - a completion / hook KPI mention,
+#        - a trend ride-or-skip rule,
+#        - at least one DATED decision record (a YYYY-MM-DD heading).
+#     2. WARN (heuristic, never fails without --strict):
+#        - cadence reads > 10/week (over the dilution ceiling),
+#        - the ledger logs only likes/views (no completion / sends / saves),
+#        - identical-creative cross-posting mentioned as a plan
+#          (Originality Score suppresses it).
+#   A clean OR empty/whitespace-only file exits 0 — never a false failure.
+#   --strict promotes warnings to a failure (for a CI gate).
+#
+# HOW TO RUN (inside YOUR project, not the skills repo)
+#   ./verify.sh docs/wiki/shortform/strategy.md
+#   ./verify.sh strategy.md --strict
+#
+# EXIT CODES
+#   0  clean, warnings only (without --strict), or empty/no-content file
+#   1  a hard failure (missing required structure) — or any warning under --strict
+#   2  bad usage (no file given, or file does not exist)
+#
+# Targets stock macOS bash 3.2: no mapfile, no associative arrays, no bc.
+
+set -euo pipefail
+
+if [ -t 1 ]; then
+  RED=$'\033[31m'; GREEN=$'\033[32m'; YELLOW=$'\033[33m'; NC=$'\033[0m'
+else
+  RED=''; GREEN=''; YELLOW=''; NC=''
+fi
+
+warn_count=0; fail_count=0
+ok()   { printf '%s[ ok ]%s %s\n' "$GREEN"  "$NC" "$*"; }
+warn() { printf '%s[warn]%s %s\n' "$YELLOW" "$NC" "$*"; warn_count=$((warn_count + 1)); }
+fail() { printf '%s[fail]%s %s\n' "$RED"    "$NC" "$*"; fail_count=$((fail_count + 1)); }
+
+usage() { sed -n '2,33p' "$0" | sed 's/^# \{0,1\}//'; }
+
+FILE=""
+STRICT=0
+while [ $# -gt 0 ]; do
+  case "$1" in
+    -h|--help) usage; exit 0 ;;
+    --strict) STRICT=1; shift ;;
+    -*) printf '%sunknown option: %s%s\n' "$RED" "$1" "$NC" >&2; usage; exit 2 ;;
+    *) if [ -z "$FILE" ]; then FILE="$1"; fi; shift ;;
+  esac
+done
+
+if [ -z "$FILE" ]; then
+  printf '%sno strategy file given%s\n' "$RED" "$NC" >&2; usage; exit 2
+fi
+if [ ! -f "$FILE" ]; then
+  printf '%sfile not found: %s%s\n' "$RED" "$FILE" "$NC" >&2; exit 2
+fi
+
+# Empty / whitespace-only file: nothing to check, do not false-fail.
+if [ ! -s "$FILE" ] || ! grep -q '[^[:space:]]' "$FILE" 2>/dev/null; then
+  ok "empty file — nothing to check"
+  exit 0
+fi
+
+printf 'shortform-strategy verify — %s\n\n' "$FILE"
+
+has() { grep -Eiq "$1" "$FILE" 2>/dev/null; }
+
+# --- 1. required structure (hard) ---------------------------------------------
+
+# Positioning / one-promise.
+if has 'position|one[- ]promise|niche|lane|for whom|who it is for'; then
+  ok "positioning / one-promise statement present"
+else
+  fail "no positioning / one-promise / lane statement found"
+fi
+
+# A cadence number: some "<n>/week" or "<n> per week" or "<n> posts a week".
+if has '[0-9]+ *(-|to|–) *[0-9]+ *(reels|posts)?/? *(per +week|/ *week|a +week|wk)'; then
+  ok "cadence number present"
+elif has '[0-9]+ *(reels|posts)? *(per +week|/ *week|a +week|/wk)'; then
+  ok "cadence number present"
+else
+  fail "no cadence number found (e.g. '4-7 Reels/week', '3-5 posts a week')"
+fi
+
+# Completion / hook KPI.
+if has 'completion|watch[- ]?time|first 3|3 ?sec|hook'; then
+  ok "completion / hook KPI present"
+else
+  fail "no completion / hook / watch-time KPI found"
+fi
+
+# Trend ride-or-skip rule.
+if has 'ride[- ]or[- ]skip|ride.*skip|skip.*trend|trend.*skip|whether to (jump|ride)|sound.*niche'; then
+  ok "trend ride-or-skip rule present"
+else
+  fail "no trend ride-or-skip rule found"
+fi
+
+# At least one dated decision record: a YYYY-MM-DD heading-ish line.
+DEC_N="$(grep -Ec '^#{1,6} *[0-9]{4}-[0-9]{2}-[0-9]{2}' "$FILE" 2>/dev/null || true)"
+DEC_N="${DEC_N:-0}"
+if [ "$DEC_N" -ge 1 ]; then
+  ok "dated decision record present (${DEC_N} found)"
+else
+  # Fall back: any dated line near a 'decision' word.
+  if grep -Eiq '[0-9]{4}-[0-9]{2}-[0-9]{2}' "$FILE" 2>/dev/null && has 'decision'; then
+    ok "dated decision record present (loose match)"
+  else
+    fail "no dated decision record (a '## YYYY-MM-DD — decision' block)"
+  fi
+fi
+
+# --- 2. heuristic warnings ----------------------------------------------------
+
+# Cadence over the ~10/week ceiling. Pull weekly figures and flag any > 10.
+CADENCE_HITS="$(grep -Eio '[0-9]+ *(reels|posts)? *(per +week|/ *week|a +week|/wk)' "$FILE" 2>/dev/null || true)"
+OVER=0
+if [ -n "$CADENCE_HITS" ]; then
+  while IFS= read -r line; do
+    [ -z "$line" ] && continue
+    n="$(printf '%s' "$line" | grep -Eo '[0-9]+' | head -1)"
+    [ -z "$n" ] && continue
+    if [ "$n" -gt 10 ]; then OVER=$((OVER + 1)); fi
+  done <<EOF
+$CADENCE_HITS
+EOF
+fi
+if [ "$OVER" -gt 0 ]; then
+  warn "cadence reads >10/week — past the dilution ceiling (consistency beats volume)"
+else
+  ok "no cadence over the ~10/week ceiling"
+fi
+
+# Ledger logs only vanity metrics.
+if has 'like|view'; then
+  if has 'completion|sends?|saves?'; then
+    ok "ledger logs completion / sends / saves (not only vanity)"
+  else
+    warn "likes/views mentioned but no completion / sends / saves — log the signals that move reach"
+  fi
+else
+  ok "no vanity-only metric set detected"
+fi
+
+# Identical-creative cross-posting as a plan.
+if has 'identical (creative|video)|same (creative|clip).*(both|all).*platform|repost.*same|cross[- ]?post.*identical'; then
+  warn "identical-creative cross-posting mentioned — Originality Score suppresses recycled content; re-cut natively"
+else
+  ok "no identical-creative cross-posting plan detected"
+fi
+
+# --- summary ------------------------------------------------------------------
+printf '\n'
+if [ "$fail_count" -gt 0 ]; then
+  printf '%s%d hard failure(s), %d warning(s)%s\n' "$RED" "$fail_count" "$warn_count" "$NC"
+  exit 1
+fi
+if [ "$warn_count" -gt 0 ]; then
+  if [ "$STRICT" -eq 1 ]; then
+    printf '%s%d warning(s) — failing under --strict%s\n' "$YELLOW" "$warn_count" "$NC"
+    exit 1
+  fi
+  printf '%s%d warning(s), 0 hard failures%s\n' "$YELLOW" "$warn_count" "$NC"
+  exit 0
+fi
+printf '%sall checks passed%s\n' "$GREEN" "$NC"
+exit 0

package/skills/show-me/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: show-me
+description: "Use when the user needs to see how something works instead of reading about it: picks the smallest visual that carries the point — pseudocode, call tree, file tree, component tree, Mermaid, a shaped diff, or one HTML page. NOT visual identity (that is `design-loop`), NOT slides (that is `presentations`), NOT a from-zero explainer (that is `eli5`)."
+tags: [show-me, explain, diagram, visual, mermaid, diff, call-tree, ensename]
+recommends: [eli5, presentations, technical-writing, codebase-onboarding]
+profiles: [minimal, core, ui, full]
+origin: risco
+---
+
+# show-me — the smallest picture that answers the question
+
+A second paragraph never fixes the first one. Pick the smallest view that makes the point, put two
+lines of prose beside it, stop.
+
+## The contract
+
+1. **One form, chosen on purpose.** Read what the question is *about*, pick the matching form from
+   the table, draw that. Several forms in one answer is the failure mode, not thoroughness.
+2. **Only the parts that answer the question.** Keep the calls, files, props, states and boundaries
+   the user asked about. Everything else is noise that hides the answer.
+3. **Prose shrinks to fit.** No preamble, no "here is a diagram of". The picture leads; the words
+   caption it.
+4. **Real names.** Actual paths, actual function and component names, actual state values. A diagram
+   of `ServiceA → ServiceB` explains nothing.
+5. **Say so when there is nothing to draw.** A topic with no shape gets a straight answer in prose.
+   A decorative diagram costs the reader time and buys nothing.
+
+## Pick the form from what the topic is
+
+| The question is about | Draw | Why this one |
+| --- | --- | --- |
+| Logic, an algorithm, a decision | pseudocode | branches read top-down; syntax would distract |
+| What calls what at runtime | call tree | shows order and nesting, which prose loses |
+| UI structure | component tree, with state and module boundaries | ownership is the answer most of the time |
+| Which file is responsible for what | shallow file tree with one comment per entry | depth hides the point; one level shows it |
+| Interaction, control flow, data flow between pieces | Mermaid sequence or flow diagram | two-way traffic over time needs an axis |
+| What changes in a shape that already exists | `diff`, in the shape of the topic | the reader keeps their bearings |
+| Layout, visual state, a dense comparison | one self-contained HTML page | text cannot hold it |
+| Nothing with a shape | prose | see contract rule 5 |
+
+```text
+on(save)
+  if content is unchanged
+    return cached result
+  write new content
+  return fresh result
+```
+
+```text
+submitForm
+  createSession
+    persistPrompt
+    launchAgent
+  navigateToSession
+```
+
+```tsx
+<SessionPage> (apps/example/src/routes/session.tsx)
+  useSessionEvents()
+  <SessionToolbar>
+    <RunSkillButton> (packages/ui)
+```
+
+```text
+src/
+├── commands/       # parses user actions
+├── sessions/       # owns session state
+└── transport/      # sends API requests
+```
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant UI
+    participant Daemon
+    User->>UI: choose command
+    UI->>Daemon: send expanded prompt
+    Daemon-->>UI: stream result
+```
+
+## The diff rule
+
+Use `diff` when the surrounding shape already exists and the point is what moves. **Match the diff
+to the topic**: a component change is a component diff, a layout change is a file-tree diff, a
+control-flow change is a pseudocode diff. A unified source diff for a structural change makes the
+reader rebuild the structure in their head.
+
+```diff
+ src/
+ ├── commands/
++│   └── show-me.ts       # expands the slash command
+ ├── sessions/
+-└── transport.ts
++└── transport/
++    ├── client.ts
++    └── stream.ts
+```
+
+```diff
+ on(save)
+-  write content
++  if content is unchanged
++    return cached result
++  write new content
++  invalidate cache
+```
+
+Show the whole block instead of a diff when most of it is new, when the omitted context would hide
+ownership or order, or when the user needs something copyable.
+
+## When it earns an HTML page
+
+Layout, visual state, a side-by-side comparison, or a concept too dense for a text diagram. One
+page, self-contained, real labels and real data, readable on a phone and on a desktop. Inherit the
+product's colours, type and spacing from where it lives; this skill borrows an identity, it never
+invents one. Then open it:
+
+```bash
+open path/to/show-me-<topic>.html
+```
+
+## Anti-patterns
+
+| Anti-pattern | Why it fails | Do this instead |
+| --- | --- | --- |
+| Ship four forms because each adds a little | The reader now has to pick; that was your job | One form, the smallest that answers it |
+| Diagram the whole system when asked about one path | The answer is in there somewhere, which is the same as absent | Draw the path, drop the rest |
+| Placeholder names (`ModuleA`, `doThing`) | Nothing maps back to the codebase | Real paths and real identifiers |
+| A unified source diff for a structural change | Forces the reader to rebuild the shape | Diff in the shape of the topic |
+| Mermaid for a layout question | Boxes and arrows cannot show visual space | One HTML page |
+| A diagram to look thorough | Costs attention, adds nothing | Answer in prose and say why there is nothing to draw |
+
+## Where this ends
+
+- The visual **identity** of an interface, a landing page or a poster is `design-loop` and `design`.
+- A **deck** someone presents from is `presentations`.
+- **Zero prior knowledge**, big pictures, few words, is `eli5`.
+- Restructuring a document, a README or a reference is `technical-writing`.
+- A guided tour of an unfamiliar repository is `codebase-onboarding`; this skill draws the pieces it
+  finds, it does not run the tour.

package/skills/show-me/evals/README.md

@@ -0,0 +1,23 @@
+# Evals — show-me
+
+Two claims are under test: that "show me / I don't get it / draw me" routes here without stealing
+design, deck or beginner-explainer work, and that the loaded skill answers with **one** well-chosen
+visual instead of more prose.
+
+## Triggering
+
+Load only `show-me` and run every `should_trigger` and `should_not_trigger` prompt in 3–5 fresh
+sessions. A positive passes when `show-me` loads in a majority of trials. A negative passes when it
+stays quiet and the declared `route_to` skill is the genuine owner. Require at least 90% accuracy.
+
+The negatives that matter most are `eli5` and `design-loop`: both are adjacent enough that a sloppy
+description pulls them in. Re-run these two after any description edit.
+
+## Capability
+
+Run the scenario in two fresh conditions, without the skill and with it, same source discussion and
+one grader. Score each `must_include` point over three trials. The with-skill condition must satisfy
+at least 80% of the rubric and beat the baseline by at least 20 percentage points.
+
+The discriminating point is **form choice**: a baseline answer typically produces prose plus a
+generic box diagram. Count "picked one form, and the right one" strictly.

package/skills/show-me/evals/cases.yaml

@@ -0,0 +1,61 @@
+skill: show-me
+
+# `show-me` owns one move: the smallest visual that answers the question being
+# asked, placed inside the conversation. It does not own visual identity, decks,
+# teaching material for a beginner, or restructuring a document.
+should_trigger:
+  - prompt: "No entiendo cómo funciona el login. Enséñamelo."
+    why: "An explicit ask to be shown rather than told, about a mechanism that has a shape to draw."
+
+  - prompt: "Can you show me visually how these three services talk to each other?"
+    why: "Interaction between pieces over time is the canonical Mermaid sequence case."
+
+  - prompt: "Draw me the component tree of this page so I can see which component owns the form state."
+    why: "UI structure with an ownership question is the component-tree form, named outright."
+
+  - prompt: "Antes de tocar nada, qué archivo es responsable de qué en src/?"
+    why: "File responsibility maps to the shallow file tree; the user wants the shape before editing."
+
+  - prompt: "I read your explanation twice and still don't get the order things happen in. Picture?"
+    why: "A second failed prose attempt is the trigger this skill exists for; runtime order is a call tree."
+
+  - prompt: "Show me what would change in the folder layout if we split transport.ts into a module."
+    why: "A change to an existing shape is the shaped-diff case, with the diff in the topic's own form."
+
+  - prompt: "Explícame con un diagrama qué pasa cuando el usuario cancela a mitad del pago."
+    why: "An edge path through a flow, explicitly requested as a diagram."
+
+should_not_trigger:
+  - prompt: "Design the landing page for our new pricing tier, it should look premium."
+    route_to: "design-loop"
+    why: "Visual identity and composition are owned by the design area; show-me explains, it does not design."
+
+  - prompt: "Build me a 12-slide deck to present the roadmap to the board on Thursday."
+    route_to: "presentations"
+    why: "A deck someone presents from is presentations; this skill draws inside the conversation."
+
+  - prompt: "Explain how a database index works to someone who has never programmed, like they're five."
+    route_to: "eli5"
+    why: "Zero prior knowledge with big pictures and few words is eli5's contract, not the smallest in-context visual."
+
+  - prompt: "Reorganise this README into a proper tutorial and an API reference."
+    route_to: "technical-writing"
+    why: "Restructuring a document is technical-writing; a diagram inside it would be at most one paragraph of the job."
+
+  - prompt: "Walk me through this whole unfamiliar repo: what it does, how it's built, where to start."
+    route_to: "codebase-onboarding"
+    why: "A guided tour of an unknown codebase is its own skill; show-me only draws the pieces once they are known."
+
+  - prompt: "Build a dashboard with our monthly revenue and churn charts."
+    route_to: "dashboard"
+    why: "A standing analytics surface is dashboard; this is not an explanation of a mechanism."
+
+capability:
+  - scenario: "The user asks, after a dense prose answer, why saving a document sometimes does not trigger a re-render. The real cause is a cache check inside the save handler plus a subscription set up after navigation. Show them."
+    must_include:
+      - "picks one form rather than stacking several, and the form matches the topic (control flow or call tree, not a file tree)"
+      - "uses the real handler, cache and subscription names from the discussion instead of placeholders"
+      - "shows only the path involved in the bug, not the whole module"
+      - "puts at most two lines of prose beside the visual, with no 'here is a diagram of' preamble"
+      - "marks what changes with a diff in the topic's own shape if it proposes a fix"
+      - "does not produce an HTML page for something a text diagram already carries"

package/skills/simplify-code/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: simplify-code
+description: "Use when correct working code is unnecessarily hard to read, change or verify and needs behaviour-preserving simplification in a bounded scope. Characterizes the observable contract, removes accidental complexity one concept at a time and proves equivalence. NOT fixing a failure (`superpowers:systematic-debugging`), NOT read-only diff judgment (`code-review`)."
+tags: [code-simplification, refactoring, readability, complexity, behavior-preservation]
+recommends: [code-review, performance]
+profiles: [core, ui, full]
+origin: risco
+---
+
+# simplify-code — fewer moving parts, same contract
+
+Use this when the code already works and the desired change is easier reasoning, not new behaviour. The output is a smaller or clearer implementation plus proof that callers cannot tell the difference.
+
+Default scope is the files or symbols the user named, or the recently changed slice. Expanding into adjacent cleanup requires a concrete dependency and must be stated. Never “clean the whole repository” as a side effect.
+
+## The equivalence loop
+
+```text
+BOUND → CHARACTERIZE → BASELINE → REDUCE → VERIFY → EXPLAIN
+```
+
+### 1. BOUND the work
+
+Record:
+
+- target files/symbols and why they are difficult;
+- callers and public interfaces that must remain stable;
+- generated/vendor code and project-marked protected regions to leave alone;
+- performance, ordering, compatibility or serialization constraints;
+- unrelated dirty-worktree changes that belong to someone else.
+
+Respect protected regions through repository instructions and explicit comments. Do not hide them by rewriting files on disk, swapping placeholders in and out, or relying on a cleanup hook to restore them later.
+
+### 2. CHARACTERIZE the observable contract
+
+Tests are necessary but may be incomplete. Write down what must remain the same:
+
+- return values and data shapes;
+- thrown/rejected error types, messages when contractual, and timing;
+- ordering, deduplication and mutation behaviour;
+- I/O, logs, analytics and other side effects;
+- async/concurrency semantics;
+- hot-path allocations or latency when performance is part of the contract.
+
+If the behaviour cannot be stated or observed, add characterization tests before refactoring. When the current behaviour is a bug, stop and route to `superpowers:systematic-debugging`; simplification must not smuggle in a fix.
+
+### 3. BASELINE current evidence
+
+Run the narrow tests first and preserve their output. Then run type/lint/build checks appropriate to the slice. For a performance-sensitive path, capture a representative benchmark under named conditions. A baseline proves what “same” means and prevents a cleaner-looking regression.
+
+### 4. REDUCE one source of accidental complexity
+
+Prefer changes with a visible reasoning payoff:
+
+- remove dead branches, duplicate calculations or needless state;
+- replace nested control flow with guard clauses when ordering stays identical;
+- extract a name for a real concept, not every three lines;
+- collapse pass-through wrappers that enforce no policy;
+- replace clever compact expressions with direct ones;
+- make data flow single-directional and ownership explicit;
+- reuse an existing local abstraction when it is simpler than both copies.
+
+Change one concept at a time and inspect the diff. Complexity moved into a new helper, generic abstraction or dependency is not removed. Lines of code are supporting evidence, never the target.
+
+Do not redesign a public API, rename unrelated symbols, update formatting across untouched files, add features, change error policy, or create a speculative framework “for future reuse.”
+
+### 5. VERIFY after every coherent step
+
+Run the focused characterization tests, then the relevant repository gate. Compare benchmark conditions when applicable; keep a performance claim only when the difference exceeds normal run-to-run noise. Review the diff specifically for contract drift and accidental scope growth.
+
+If a step is neutral or worse for understandability, revert **that step only** using a targeted edit. Never use `git reset --hard`, overwrite the working tree, or discard unrelated user changes. Do not commit automatically.
+
+### 6. EXPLAIN the gain
+
+Report:
+
+- scope simplified;
+- complexity removed, not merely relocated;
+- observable contract preserved;
+- tests/checks/benchmark run and results;
+- anything intentionally left complex and the invariant that justifies it.
+
+“Cleaner” is too vague. Prefer: “removed three mutable states and one duplicate parse; preserved error type/message, insertion order and one-read I/O semantics; 18 focused tests plus full typecheck pass.”
+
+## Stop rule
+
+Stop when another edit would trade one defensible style for another without lowering the number of states, branches, concepts or proof obligations. Readability has diminishing returns. A bounded, verified improvement is done even if neighbouring legacy code remains ugly.
+
+## Anti-patterns
+
+| Smell | Correction |
+|---|---|
+| A failing behaviour is “cleaned up” | Diagnose with `superpowers:systematic-debugging`; simplification must not smuggle in a fix. |
+| A read-only review starts editing | Keep verdict work in `code-review`. |
+| A speed hunch justifies a refactor | `performance` measures first; preserve a benchmark when speed is contractual. |
+| An odd public behaviour is silently normalized | Preserve it until a behaviour change is explicitly authorized. |
+| Cleanup commits, pushes, resets or deploys on its own | These are separate authorized operations; use targeted edits only. |
+
+## Orientación (siempre)
+
+Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ✅ qué hiciste · 🧭 por qué · ➡️ siguiente, terminando en pregunta), calibrado al dial de `docs/wiki/harness/user-profile.md`. **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el “¿instalo la skill que falta?”.)

package/skills/simplify-code/evals/README.md

@@ -0,0 +1,3 @@
+# Evals — simplify-code
+
+The cases distinguish correct-but-complex code from debugging, review, verification, performance and API redesign. The capability case requires an explicit behavioural contract, characterization baseline, one-concept reductions, full evidence and safe worktree handling.

package/skills/simplify-code/evals/cases.yaml

@@ -0,0 +1,42 @@
+skill: simplify-code
+
+should_trigger:
+  - prompt: "This parser works and its tests are green, but the nested branches are impossible to follow; simplify it without changing behavior."
+    why: "Correct code needs bounded behaviour-preserving simplification."
+  - prompt: "Simplifica esta función, pero conserva exactamente errores, orden y efectos laterales."
+    why: "Spanish request explicitly names observable contract preservation."
+  - prompt: "The feature is done; now remove the accidental complexity from only the files we changed."
+    why: "Post-feature bounded cleanup is the default scope."
+  - prompt: "Fes el codi menys enginyós i més directe, amb tests de caracterització abans de tocar-lo."
+    why: "Catalan request for characterization-led simplification."
+  - prompt: "Collapse these pass-through wrappers and duplicate state if callers cannot observe a difference."
+    why: "Specific removable complexity with an equivalence condition."
+  - prompt: "Refactor this hot path for clarity, but keep the benchmark and allocation profile within noise."
+    why: "Performance is part of the observable simplification contract."
+
+should_not_trigger:
+  - prompt: "The parser throws on valid quoted values; reproduce the bug and fix it."
+    route_to: external:superpowers-systematic-debugging
+    why: "Behaviour is incorrect, so diagnosis via superpowers' systematic-debugging precedes any cleanup."
+  - prompt: "Review this pull request and list correctness issues, but do not edit it."
+    route_to: code-review
+    why: "Read-only spec-less diff judgment."
+  - prompt: "Verify the finished SDD implementation against every acceptance criterion."
+    route_to: external:superpowers-verification-before-completion
+    why: "Evidence gate via superpowers' verification-before-completion rather than code editing."
+  - prompt: "The page is slow; profile Core Web Vitals and fix the measured bottleneck."
+    route_to: performance
+    why: "Measured speed work owns the task."
+  - prompt: "Redesign the public API and migrate all callers to the new contract."
+    route_to: api-design
+    why: "The requested behaviour/interface change is not simplification."
+
+capability:
+  - scenario: "Simplify an 80-line configuration parser whose current tests cover the happy path but whose callers depend on comment handling, quoting, numeric conversion, insertion order and ignored malformed lines."
+    must_include:
+      - "Bounds the target and inspects callers, dirty-worktree state, generated code, and explicit protected regions without mutating files to hide content."
+      - "States the observable contract including return shape, ignored input, type conversion, order, errors and side effects."
+      - "Adds characterization cases for uncovered contract edges and records a green baseline before refactoring."
+      - "Removes one source of complexity at a time without adding features, redesigning public APIs, or relocating complexity into speculative abstractions."
+      - "Runs focused tests plus relevant lint/type/build gates after coherent steps and compares a benchmark when performance is contractual."
+      - "Uses targeted edits for a bad step and never resets, auto-commits, pushes, deploys, or discards unrelated changes."

package/skills/sitios-calidad-premio/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: sitios-calidad-premio
+description: "Art-direct and implement marketing, editorial, portfolio, and landing sites that are distinctive and motion-rich, with original imagery inspired by references, standout heroes, GSAP choreography, a single smooth-scroll engine, optional Three.js shaders, honest icon and logo sourcing, photographic avatars, accessibility, and performance safeguards. Use when asked for an award-quality, premium, cinematic, interactive, high-concept, or motion-driven website."
+tags: ["award-site", "gsap", "webgl", "art-direction"]
+profiles: [ui, full]
+---
+
+# Construir sitios de calidad de premio
+
+Construye un sitio cohesionado y memorable donde la idea visual, el material, la tipografia y el movimiento cuenten la misma historia. Trata "calidad de premio" como un liston de aceptacion, nunca como una afirmacion de haber ganado un premio o un reconocimiento.
+
+## 1. Fija la direccion de arte
+
+- Inspecciona por completo el material de referencia del usuario antes de implementar. Extrae solo rasgos de alto nivel: jerarquia, ritmo, contraste, tratamiento de imagen y principios de movimiento.
+- Genera una identidad, layout, sistema de textos, imagenes y lenguaje de interaccion materialmente nuevos. Nunca reutilices, calques ni reproduzcas de cerca assets, capturas, codigo fuente, identidad o textos de la referencia.
+- Selecciona y nombra al menos una skill de diseno web compatible que tengas instalada. Sigue el conjunto relevante mas pequeno y evita combinar sistemas esteticos sin relacion.
+- Escribe una direccion compacta antes de picar codigo: tesis visual, asset focal del hero, jerarquia tipografica, sistema de color, secuencia de secciones, narrativa de movimiento, motor de scroll suave elegido, decision sobre Three.js y plan de procedencia de assets.
+
+## 2. Construye un sistema de assets honesto
+
+- Genera imagenes originales de hero o de proyecto cuando mejoren materialmente el concepto. Usa material con licencia adecuada cuando sea mas fuerte, y deja constancia de la procedencia en el codigo del sitio.
+- No dibujes ilustraciones con SVG, CSS o rutas de canvas escritas por el modelo. Usa recortes PNG transparentes originales, generados o con licencia adecuada, para los elementos ilustrativos. Si se permiten marcas de marca simples, iconos de interfaz, graficos de datos y un canvas de shader justificado.
+- Usa fotografias para todos los avatares. Prefiere fotos aportadas o con licencia adecuada; nunca entregues iniciales, cabezas ilustradas, siluetas sin rostro ni personas generadas presentadas como clientes, empleados o avaladores reales.
+- Usa iconos Solar a traves de Iconify para los simbolos de interfaz. Usa los logos SVG de Iconify solo para marcas reales legitimas en contextos veraces. Usa Logo Ipsum solo para especimenes de marcas ficticias declarados explicitamente como tales, nunca como prueba de clientes. Omite el muro de logos cuando no exista prueba honesta.
+- Define relaciones de aspecto deliberadas, comportamiento de recorte, texto alternativo, comportamiento de carga y respaldos para material que falte. Evita imagenes de archivo genericas, mockups copiados, marcas de agua y material decorativo sin papel narrativo.
+
+## 3. Compon el hero
+
+- Haz del primer viewport el momento mas fuerte del sitio. Combina un mensaje claro y un CTA con imagen original, video, interaccion que responde al puntero o una escena justificada de Three.js.
+- Crea una secuencia de introduccion coreografiada con GSAP para el hero. Manten la navegacion, el mensaje principal y el CTA legibles y usables antes de que termine la animacion.
+- Haz que los efectos de puntero sean aditivos. Soporta tactil, teclado, punteros gruesos, perdida de foco de la ventana y cambios de visibilidad sin dejar la interfaz a medias.
+- Disena un primer fotograma estatico que siga estando completo cuando no haya JavaScript, ni reproduccion de medios, ni WebGL, ni movimiento.
+
+## 4. Construye el sistema de movimiento
+
+- Usa GSAP como sistema de animacion principal.
+- Evalua Lenis y Locomotive Scroll y elige exactamente uno como unico motor de scroll suave del sitio. Nunca instales ni inicialices los dos. Conecta bien el motor elegido a GSAP ScrollTrigger, refresca las mediciones tras cambios de material y de fuentes, y destruyelo en la limpieza.
+- Saltate el scroll suave y las lineas de tiempo con scrub bajo `prefers-reduced-motion: reduce`. Renderiza los estados finales de inmediato en vez de limitarte a acortar las animaciones.
+- Coreografia la pagina seccion a seccion. Revela los titulares importantes palabra a palabra con un escalonado contenido, y luego secuencia el texto de apoyo y el material.
+- Preserva un nombre accesible sin partir para el texto escalonado. Oculta a la tecnologia asistiva las palabras decorativas partidas, nunca partas enlaces ni marcado en linea con significado, y manten el contenido sin partir visible sin JavaScript.
+- Usa CSS para los estados simples de hover, foco y pulsacion. Reserva ScrollTrigger para las secuencias con scrub o fijadas que lo justifiquen, y evita que dos sistemas controlen la misma propiedad.
+
+## 5. Anade Three.js solo con proposito
+
+- Usa Three.js y shaders WebGL propios cuando la profundidad espacial, la transicion de textura, el desplazamiento o la respuesta al puntero apoyen materialmente la direccion de arte. No metas un shader como ruido decorativo de fondo.
+- Dale al canvas una unica responsabilidad clara y mantenlo subordinado al contenido semantico y a los controles.
+- Limita la densidad de pixeles del dispositivo, pausa el renderizado fuera de pantalla o cuando el documento esta oculto, estrangula la entrada de puntero y evita reservar memoria en cada fotograma.
+- Aporta un poster estatico y sustituye el canvas por completo bajo movimiento reducido o si falla WebGL.
+- Libera fotogramas de animacion, observadores, listeners, targets de render, texturas, geometrias, materiales y el renderer. Maneja la perdida de contexto sin romper el contenido de la pagina.
+
+## 6. Alcanza el liston de calidad
+
+- Construye una pagina semantica completa, no un concepto de solo hero. Incluye navegacion responsive, progresion coherente de secciones, contenido concreto de conversion, CTA final, pie, estados robustos de formularios o controles cuando existan, y foco de teclado visible.
+- Exige una idea de direccion de arte distintiva, un primer viewport memorable, tipografia y espaciado disciplinados, recortes de imagen intencionados, transiciones coreografiadas y comportamiento refinado de hover, foco, activo, carga, deshabilitado, error, tactil y movimiento reducido.
+- Preserva el rendimiento con material responsive, carga diferida por debajo del pliegue, transforms acotados, desenfoque limitado, trabajo de canvas con tope y nada animandose continuamente fuera de pantalla.
+- Rechaza las manchas de degradado genericas, las rejillas bento ornamentales, el cristal aplicado en todas partes, los layouts de componente de plantilla, los testimonios falsos, las colaboraciones inventadas, el teatro del muro de logos y el movimiento sin papel narrativo.
+- Nunca describas el resultado como premiado ni reconocido salvo que el usuario aporte evidencia verificable.
+
+## 7. Valida antes de entregar
+
+- Ejecuta la construccion de produccion y arregla cada fallo.
+- Revisa la pagina en tamanos de escritorio y movil cuando se pida validacion en navegador o haga falta para resolver un bloqueo.
+- Verifica la navegacion por teclado, el foco visible, el comportamiento tactil, el contenido sin JavaScript, los respaldos estaticos de material y el comportamiento con `prefers-reduced-motion`.
+- Comprueba que solo hay un motor de scroll suave instalado e inicializado, que la integracion con ScrollTrigger es correcta y que todos los recursos de animacion y WebGL se liberan.
+- Busca en el contenido renderizado y en el codigo marcadores sin sustituir, identidad copiada de la referencia, afirmaciones sin respaldo, logos enganosos, material sin acreditar y texto partido inaccesible.
+- Reporta la skill de diseno web elegida, las fuentes de los assets, el stack de movimiento, la decision sobre Three.js, la validacion realizada y cualquier limitacion que quede.

package/skills/sitios-calidad-premio/evals/cases.yaml

@@ -0,0 +1,32 @@
+skill: sitios-calidad-premio
+
+should_trigger:
+  - prompt: "Quiero una web premium con coreografia de scroll y GSAP."
+    why: "Disparador directo de sitios-calidad-premio."
+  - prompt: "Construye un sitio editorial cinematografico con heroes que destacan."
+    why: "Disparador directo de sitios-calidad-premio."
+  - prompt: "Necesito un portafolio interactivo de alto concepto."
+    why: "Disparador directo de sitios-calidad-premio."
+  - prompt: "Art-direct an award-quality marketing site with original imagery and motion."
+    why: "Disparador directo de sitios-calidad-premio."
+  - prompt: "Anade shaders de Three.js opcionales a esta landing."
+    why: "Disparador directo de sitios-calidad-premio."
+
+should_not_trigger:
+  - prompt: "Construye un formulario interno sencillo sin enfasis visual."
+    route_to: "none"
+    why: "Fuera del alcance de sitios-calidad-premio."
+  - prompt: "Escribe tests unitarios para el backend."
+    route_to: "none"
+    why: "Fuera del alcance de sitios-calidad-premio."
+  - prompt: "Revisa la accesibilidad basica de un dashboard interno."
+    route_to: "mejor-accesibilidad"
+    why: "Revisar la accesibilidad es el trabajo de mejor-accesibilidad, no de sitios-calidad-premio."
+  - prompt: "Genera un CRUD simple sin diseno especial."
+    route_to: "none"
+    why: "Fuera del alcance de sitios-calidad-premio."
+
+capability:
+  - scenario: "El usuario pide un sitio de calidad de premio, cinematografico o guiado por movimiento."
+    must_include:
+      - "GSAP"