@grant-vine/wunderkind 0.9.12 → 0.10.1

package/skills/SKILL-STANDARD.md

@@ -0,0 +1,174 @@
+# Skill Standard
+
+`skills/SKILL-STANDARD.md` is the authoritative repo-level contract for authoring and auditing Wunderkind-native skills.
+
+It is derived from `skills/write-a-skill/SKILL.md` and turns that workflow into a reusable standard for every `skills/<skill-name>/SKILL.md` file in this repository.
+
+## Purpose
+
+- Make skill selection reliable from the description alone.
+- Keep the main skill file fast to scan during runtime.
+- Push rarely needed detail into optional deep-reference files instead of bloating `SKILL.md`.
+- Tie every skill to a surviving Wunderkind owner and a clear artifact surface.
+
+## Required contract
+
+Every skill must define all of the following:
+
+1. Trigger section: the exact conditions that should activate the skill.
+2. Anti-trigger section: when the skill must not be used.
+3. Ownership metadata: the surviving Wunderkind agent responsible for stewarding the skill.
+4. Filesystem or artifact scope: the files, folders, commands, or durable outputs the skill is expected to touch.
+5. Progressive disclosure: a short overview first, then operational steps, then optional deep dives.
+6. Review gate: what must be true before the skill can be considered complete and publishable.
+
+## Description standard
+
+The frontmatter `description` is the trigger surface for the runtime. Write it trigger-first.
+
+- Start with `USE FOR:`.
+- Put the highest-signal trigger phrases in the first sentence.
+- Mention concrete repo artifacts when relevant, such as `skills/*/SKILL.md`, `.sisyphus/`, `README.md`, `tests/unit/`, or `src/`.
+- Prefer explicit task phrases over vague coaching language.
+- Keep it concise enough to scan quickly, but specific enough to disambiguate from adjacent skills.
+
+Good pattern:
+
+```md
+description: >
+  USE FOR: capability-first trigger phrases, concrete repo artifacts, and the exact
+  situations where this skill should be selected instead of a neighboring one.
+```
+
+## Standard structure
+
+Each `SKILL.md` should use this shape unless a tighter variant is clearly better:
+
+1. Frontmatter: `name`, trigger-first `description`
+2. H1 title
+3. One-paragraph overview: what the skill does and why it exists
+4. `## Primary owner`
+5. `## Filesystem scope` or `## Output target`
+6. `## When to trigger`
+7. `## Anti-triggers`
+8. `## Process` or equivalent ordered workflow
+9. Optional decision lenses, slash commands, or delegation patterns
+10. `## Hard rules`
+11. `## Review gate`
+
+## Ownership metadata
+
+Every skill must name one surviving owner from the retained topology:
+
+- `product-wunderkind`
+- `fullstack-wunderkind`
+- `marketing-wunderkind`
+- `creative-director`
+- `ciso`
+- `legal-counsel`
+
+If a removed legacy agent is still mentioned for context, the surviving steward must be explicit and the note must explain the handoff boundary.
+
+## Filesystem and artifact scope
+
+Every skill must declare what it can read, write, or produce.
+
+Typical scope patterns:
+
+- Main asset: `skills/<skill-name>/SKILL.md`
+- Optional deep references: `skills/<skill-name>/REFERENCE.md`, `skills/<skill-name>/EXAMPLES.md`
+- Optional helper scripts: `skills/<skill-name>/scripts/`
+- Durable project artifacts: `.sisyphus/notepads/`, `.sisyphus/evidence/`, `.sisyphus/triage/`, `.sisyphus/rfcs/`
+- Published docs surfaces: `README.md`, `AGENTS.md`, or repo docs folders when the skill is documentation-facing
+
+If a skill is analysis-only, say so explicitly. If it writes durable output, name the path pattern.
+
+## Progressive disclosure
+
+Keep the primary `SKILL.md` short enough for fast runtime scanning.
+
+- Put the minimum viable overview and decision rules in `SKILL.md`.
+- Move deep background, long examples, edge-case matrices, or command catalogs into optional sibling files.
+- Reference deeper files only when they add real value for rare or complex paths.
+- Prefer one clear workflow over encyclopedic prose.
+
+Use this depth ladder:
+
+1. Overview: capability, owner, and trigger surface
+2. Core workflow: ordered steps and hard rules
+3. Optional deep dive: references, examples, scripts, or research appendices
+
+## Anti-triggers
+
+Every skill must say what it is not for.
+
+Minimum expectations:
+
+- call out neighboring skills when boundary confusion is likely
+- exclude trivial tasks that do not justify skill activation
+- exclude generated output or unrelated repo areas when applicable
+- exclude removed-agent ownership assumptions
+
+## Optional deep assets
+
+Create optional sibling assets only when the main skill becomes hard to scan without them.
+
+- `REFERENCE.md`: long-form theory, policies, matrices, or terminology
+- `EXAMPLES.md`: worked examples, sample prompts, or before/after outputs
+- `scripts/`: repeatable helper automation that the skill relies on
+
+If you add a deep asset, `SKILL.md` must still stand on its own for common cases.
+
+## Review gate
+
+A skill is complete only when all of the following are true:
+
+1. The frontmatter description is trigger-first and distinguishable from neighboring skills.
+2. The surviving owner is explicit and matches the retained topology.
+3. Filesystem or artifact scope is named precisely.
+4. Anti-triggers prevent accidental overuse.
+5. The workflow follows progressive disclosure instead of dumping every detail into one file.
+6. Optional deep assets, if present, are referenced deliberately and not required for basic use.
+7. Hard rules define scope boundaries and failure conditions.
+8. The skill inventory in this file remains accurate after the change.
+9. `README.md` and `AGENTS.md` reflect ownership or inventory changes when the public surface changes.
+
+## Authoring checklist
+
+- Name the skill after the capability, not the persona.
+- Write the description as a runtime trigger surface, not marketing copy.
+- Declare the owner before describing the workflow.
+- Name the durable outputs or confirm that the skill is read-only.
+- Split rare detail into sibling files before `SKILL.md` becomes bloated.
+- Keep repo-specific language stronger than generic methodology language.
+
+## Skill inventory
+
+| Skill Name | Current Owner | Disposition | Notes |
+|---|---|---|---|
+| `agile-pm` | `product-wunderkind` | revise | Keep as a product planning skill, but update removed-agent references and align the file to the full trigger/anti-trigger standard. |
+| `compliance-officer` | `ciso` | keep | Still maps directly to security, privacy controls, and regulatory guidance under the retained topology. |
+| `code-health` | `fullstack-wunderkind` | keep | Produces severity-ranked audit reports (coupling, testability, dependency risk) as structured markdown; read-only, no automated cleanup. |
+| `db-architect` | `fullstack-wunderkind` | keep | Remains a distinct engineering specialty with clear database and migration scope. |
+| `design-an-interface` | `fullstack-wunderkind` | keep | Newly imported and already follows the intended trigger and anti-trigger shape. |
+| `experimentation-analyst` | `product-wunderkind` | revise | Reassign from removed `data-analyst`; center this skill on product experiments and feature readouts, with marketing consulted for campaign analytics. |
+| `grill-me` | `product-wunderkind` | keep | Continues to serve as the ambiguity-collapsing intake skill for product framing. |
+| `improve-codebase-architecture` | `fullstack-wunderkind` | keep | Still the right long-form RFC and architecture-boundary skill. |
+| `oss-licensing-advisor` | `legal-counsel` | keep | Clear legal specialization with no ownership ambiguity. |
+| `pen-tester` | `ciso` | keep | Remains the offensive-security counterpart to broader security analysis. |
+| `prd-pipeline` | `product-wunderkind` | keep | Core orchestrator skill for PRD, plan, and delivery flow. |
+| `security-analyst` | `ciso` | keep | Still the general defensive-security analysis skill under `ciso`. |
+| `social-media-maven` | `marketing-wunderkind` | keep | Fits the consolidated marketing remit after brand and devrel absorption. |
+| `tdd` | `fullstack-wunderkind` | revise | Reassign from removed `qa-specialist`; keep as the engineering execution skill for red-green-refactor work. |
+| `technical-writer` | `marketing-wunderkind` | revise | Reassign from removed `devrel-wunderkind`; documentation and developer-facing content now live under marketing stewardship. |
+| `triage-issue` | `product-wunderkind` | revise | Reassign from removed `support-engineer` and `qa-specialist`; product now owns front-door triage while engineering supports implementation. |
+| `ubiquitous-language` | `product-wunderkind` | keep | Continues to support product-led terminology and shared domain language. |
+| `vercel-architect` | `fullstack-wunderkind` | keep | Remains a focused platform-engineering skill with clear deployment scope. |
+| `visual-artist` | `creative-director` | keep | Still belongs under the retained design and visual-language owner. |
+| `write-a-skill` | `product-wunderkind` | revise | Keep as the practical authoring workflow, but make `skills/SKILL-STANDARD.md` the source of truth it references. |
+
+## Change policy
+
+- Do not hand-edit generated `agents/*.md` output to express skill standards.
+- Update this file whenever a skill is added, reassigned, merged, retired, or materially repurposed.
+- If a future audit decides a skill should merge or retire, record that disposition here before changing the public docs.

package/skills/agile-pm/SKILL.md

@@ -13,6 +13,8 @@ description: >
 
 You are an Agile Project Manager specialising in task decomposition for AI agents. Your primary objective is to structure work so that agents can operate in parallel without file conflicts.
 
+**Owned by:** wunderkind:product-wunderkind
+
 ### Core Principle: Parallel Safety via Concern Grouping
 
 "One task = one file concern = one agent. Never let two tasks share a file."
@@ -83,14 +85,14 @@ Organise a backlog into a structured sprint.
 3. **Group**: Organise tasks by concern to maximise parallel work.
 4. **Output**: A sprint table including tasks, points, file targets, dependency ordering, and stretch goals.
 
-**After the sprint plan is complete**, route user stories to `wunderkind:qa-specialist` for testability review:
+**After the sprint plan is complete**, route user stories to `wunderkind:product-wunderkind` for acceptance and testability review:
 
 ```typescript
 task(
   category="unspecified-low",
-  load_skills=["wunderkind:qa-specialist"],
-  description="Story testability review for sprint",
-  prompt="Review the user stories in the sprint plan for testability and completeness. For each story: check INVEST criteria, flag missing rejection paths, missing security boundaries, and untestable acceptance criteria. Return a story-by-story checklist with specific improvements suggested.",
+  load_skills=["wunderkind:product-wunderkind"],
+  description="Story acceptance review for sprint",
+  prompt="Review the user stories in the sprint plan for acceptance quality and testability. For each story: check INVEST criteria, flag missing rejection paths, missing security boundaries, and untestable acceptance criteria. Return a story-by-story checklist with specific improvements suggested, and call out any technical follow-up that should escalate to fullstack-wunderkind.",
   run_in_background=false
 )
 ```
@@ -107,9 +109,9 @@ Facilitate a sprint retrospective and capture actionable outcomes.
 1. Gather inputs: review the sprint plan, completed tasks, velocity, and any blockers or incidents from the sprint
 2. Identify patterns: are the same impediments recurring? Is velocity declining or erratic?
 3. Categorise findings:
-   - **Technical debt**: recurring code issues, slow tests, brittle E2E — route fixes to `wunderkind:qa-specialist`
+   - **Technical debt**: recurring code issues, slow tests, brittle E2E — route fixes to `wunderkind:fullstack-wunderkind`
    - **Process gaps**: unclear acceptance criteria, late QA, missing definition of done
-   - **Tooling**: slow builds, broken CI, environment instability — route to `wunderkind:operations-lead`
+   - **Tooling**: slow builds, broken CI, environment instability — route to `wunderkind:fullstack-wunderkind`
 4. Write action items: each must have an owner, a due date, and a measurable success criteria
 5. Prioritise: maximum 3 action items per retrospective — too many = none get done
 

package/skills/code-health/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: code-health
+description: >
+  USE FOR: code health audits, engineering hygiene assessments, coupling analysis,
+  testability reviews, dependency classification, severity-ranked findings reports,
+  and identifying systemic code quality patterns across a codebase.
+
+---
+
+# Code Health
+
+Produce a structured, evidence-based code health audit report with severity-ranked findings. This skill is an analysis and reporting tool — it does not mutate code, create GitHub issues or RFCs, or run automated cleanup tools.
+
+## Primary owner
+
+**Owned by:** wunderkind:fullstack-wunderkind
+
+This skill is owned by `fullstack-wunderkind` as the surviving steward for code quality, TDD, architecture, and engineering methods.
+
+## Output target
+
+Produce a structured markdown audit report as the response output. Do not write the report automatically to a fixed file path. If the user wants the report persisted, they can ask you to write it to a file of their choosing.
+
+## Filesystem scope
+
+- Read access: all source files, test files, config files, and dependency manifests in the project
+- Write access: none (read-only analysis; output is in-response markdown)
+- Supporting repo surfaces may include: `src/`, `tests/`, `package.json`, lock files, `tsconfig.json`, build configs
+
+## When to trigger
+
+Use this skill when:
+
+- the user explicitly requests a code health audit, engineering hygiene review, or quality assessment
+- the goal is to understand coupling, testability, or architectural debt before making changes
+- the user wants a prioritised finding list with severity levels before deciding what to fix
+- a project needs a baseline quality snapshot before a refactor or new feature sprint
+
+## Anti-triggers
+
+Do not trigger this skill for:
+
+- every normal coding task by default
+- product feature delivery (use `fullstack-wunderkind` directly)
+- architecture RFC creation or interface design (use `improve-codebase-architecture`)
+- TDD workflow support (use `tdd`)
+- docs-only or generated-file changes
+
+## Severity taxonomy
+
+Every finding must be assigned one of five severity levels:
+
+| Level | Meaning |
+|---|---|
+| `critical` | Causes data loss, security exposure, or blocking build failures; must be fixed before shipping |
+| `high` | Causes reliability failures, significant coupling, or test blindness; should be fixed promptly |
+| `medium` | Causes friction, testability problems, or hidden coupling; fix when adjacent work touches the area |
+| `low` | Minor hygiene, naming inconsistency, or low-impact debt; fix opportunistically |
+| `informational` | Observations worth noting but requiring no immediate action |
+
+**Target state:** zero `critical` and `high` findings in a healthy codebase. Medium-or-lower findings are acceptable when the agent explains the tradeoff or records a deferral rationale.
+
+## Process
+
+1. **Discover entry points.** Identify the module structure: entry files, public APIs, CLI surfaces, exported types, and build output shape. Map what callers depend on.
+
+2. **Map coupling and seam boundaries.** Trace which modules import which. Identify tight coupling (direct instantiation, shared mutable state, circular dependencies). Note where seams exist for testing and where they are absent.
+
+3. **Assess testability.** For each significant module, ask: Can this be tested in isolation? Are side effects injectable or faked? Are there untested branches with production risk? Identify coverage gaps tied to real failure modes rather than line metrics alone.
+
+4. **Classify dependencies.** Separate:
+   - Core domain logic (should be dependency-free or near-free)
+   - Infrastructure adapters (file I/O, network, database, CLI frameworks)
+   - Dev tooling (test runners, type checkers, bundlers)
+   - Transitive risk (pinned vs unpinned, maintained vs abandoned)
+
+5. **Rank findings by severity.** Assign each finding a severity level from the taxonomy above. Group by severity tier. Do not inflate severity — be honest about what is `medium` vs `high`.
+
+6. **Produce the audit report.** Write the report in the response using the report shape below.
+
+## Report shape
+
+```markdown
+# Code Health Audit — <Project or Scope>
+
+## Executive Summary
+One paragraph: overall health signal, dominant pattern, highest-priority concern.
+
+## Findings by Severity
+
+### Critical
+- **[File:Line or Module]** — Description of the finding and why it is critical.
+
+### High
+- **[File:Line or Module]** — Description.
+
+### Medium
+- **[File:Line or Module]** — Description.
+
+### Low
+- **[File:Line or Module]** — Description.
+
+### Informational
+- **[File:Line or Module]** — Observations worth noting.
+
+## Priority Action List
+Ordered list of the 3–7 highest-leverage actions to improve health.
+Each action should name the file/module and describe the change at a concrete level.
+
+## Systemic Patterns
+Recurring patterns (good or bad) that appear across multiple files/modules.
+Name the pattern, cite 2–3 examples, and note whether it is an asset or a liability.
+
+## Appendix
+Optional: dependency graph fragments, coupling diagrams, notes on external references.
+```
+
+## Hard rules
+
+1. This skill is read-only and analysis-only. Do not modify code, run cleanup tools, or generate automated fixes.
+2. Do not create GitHub issues, PRs, or RFCs as part of this workflow.
+3. Do not present the audit as a set of "pick one" options — produce findings and a priority list, then let the engineer decide what to act on.
+4. Do not inflate severity. Reserve `critical` for genuine blocking risks.
+5. Medium-or-lower findings may be explained or deferred; document the rationale when deferring.
+6. The report is produced in the response. Do not write it automatically to a fixed file path.
+7. Do not require network access to run the audit. All analysis is based on local filesystem inspection.
+
+## Review gate
+
+This skill is complete only when:
+
+1. `fullstack-wunderkind` is named as the primary owner.
+2. The severity taxonomy (`critical`, `high`, `medium`, `low`, `informational`) is defined.
+3. The six audit workflow steps are explicit.
+4. The report shape includes: Executive Summary, Findings by Severity, Priority Action List, Systemic Patterns, Appendix.
+5. The skill explicitly states it is read-only and does not mutate code or create external artifacts.
+6. No references to automated code-cleanup tools, package-manager install workflows, or any language suggesting the skill mutates code appear anywhere in the file.

package/skills/compliance-officer/SKILL.md

@@ -22,22 +22,24 @@ You are the **Compliance Officer** — a privacy and regulatory specialist who e
 
 You are a sub-skill of the CISO agent and are invoked for compliance assessments, data protection reviews, and regulatory guidance.
 
+**Owned by:** wunderkind:ciso
+
 ---
 
 ## Regional Configuration
 
-**Read `wunderkind.config.jsonc` at the start of any compliance or regulatory task.**
+**Read `.wunderkind/wunderkind.config.jsonc` at the start of any compliance or regulatory task.**
 
-Look for this file first in the project root, then in the plugin root. Key fields:
+Find this file at `.wunderkind/wunderkind.config.jsonc` in the project directory. Key fields:
 
 | Field | Effect on this skill |
 |---|---|
-| `PRIMARY_REGULATION` | The primary regulation to assess against (defaults to GDPR if blank) |
-| `SECONDARY_REGULATION` | Any additional regulation to layer on top |
-| `REGION` | Used to select applicable local regulatory nuance |
-| `INDUSTRY` | Flags sector-specific obligations (e.g. healthcare → HIPAA awareness, finance → PCI DSS) |
+| `primaryRegulation` | The primary regulation to assess against (defaults to GDPR if blank) |
+| `secondaryRegulation` | Any additional regulation to layer on top |
+| `region` | Used to select applicable local regulatory nuance |
+| `industry` | Flags sector-specific obligations (e.g. healthcare → HIPAA awareness, finance → PCI DSS) |
 
-If `wunderkind.config.jsonc` is absent or fields are blank, default to **GDPR as the global baseline** — it is the most comprehensive and widely adopted framework, and compliance with it satisfies most other frameworks' core requirements.
+If `.wunderkind/wunderkind.config.jsonc` is absent or fields are blank, default to **GDPR as the global baseline** — it is the most comprehensive and widely adopted framework, and compliance with it satisfies most other frameworks' core requirements.
 
 Regional guidance is **additive, never subtractive**: global best practices are never reduced for a specific region.
 
@@ -228,7 +230,7 @@ Compare current state against requirements. For each gap:
 ### `/compliance-assessment <regulation>`
 Perform a compliance assessment against the applicable regulation.
 
-**First**: read `wunderkind.config.jsonc`. If `PRIMARY_REGULATION` is set, assess against that regulation. If blank, default to GDPR. If a regulation is explicitly passed as an argument, use that regardless of config.
+**First**: read `.wunderkind/wunderkind.config.jsonc`. If `primaryRegulation` is set, assess against that regulation. If blank, default to GDPR. If a regulation is explicitly passed as an argument, use that regardless of config.
 
 Supported regulations: GDPR, POPIA, CCPA/CPRA, PIPEDA, LGPD, PDPA (Singapore/Thailand), APP (Australia).
 
@@ -291,12 +293,12 @@ Plan must cover:
 7. **Remediate**: fix the root cause
 8. **Review**: postmortem, update ROPA, improve controls
 
-**When the breach has a technical containment component**, delegate immediately to `wunderkind:operations-lead`:
+**When the breach has a technical containment component**, delegate immediately to `wunderkind:fullstack-wunderkind`:
 
 ```typescript
 task(
   category="unspecified-high",
-  load_skills=["wunderkind:operations-lead"],
+  load_skills=["wunderkind:fullstack-wunderkind"],
   description="Containment steps for data breach incident",
   prompt="A data breach has been detected. Implement containment: isolate affected systems, revoke exposed credentials/tokens, disable compromised accounts, capture logs for forensic preservation, and confirm blast radius. Return: actions taken, systems affected, credentials rotated, and estimated scope of exposed data.",
   run_in_background=false
@@ -352,4 +354,4 @@ When a data subject request arrives:
 4. **Data minimisation is a design constraint**: the question at design time is "what data do we actually need?" not "what data might be useful?"
 5. **Rights are operational, not theoretical**: having a privacy policy that mentions rights is not the same as having the ability to fulfil a SAR within the required timeline
 6. **No cross-border transfer without a mechanism**: data cannot leave a jurisdiction without an appropriate transfer mechanism (adequacy decision, SCCs, BCRs)
-7. **Config-first**: always read `wunderkind.config.jsonc` before starting any compliance assessment — assess against the right regulation for the project's jurisdiction
+7. **Config-first**: always read `.wunderkind/wunderkind.config.jsonc` before starting any compliance assessment — assess against the right regulation for the project's jurisdiction

package/skills/db-architect/SKILL.md

@@ -12,6 +12,8 @@ description: >
 You are a PostgreSQL database architect specialising in schema design, Drizzle ORM,
 Neon DB, query optimisation, and safe schema migrations.
 
+**Owned by:** wunderkind:fullstack-wunderkind
+
 ---
 
 ## Destructive Action Protocol

package/skills/design-an-interface/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: design-an-interface
+description: >
+  USE FOR: high-complexity API design, module boundary design, interface comparison,
+  design-it-twice exploration, and choosing between competing abstractions before
+  implementation. Use when the shape of an interface is the main engineering risk.
+
+---
+
+# Design an Interface
+
+Adapted from Matt Pocock's benchmark skill for Wunderkind's engineering workflow.
+
+## Primary owner
+
+**Owned by:** wunderkind:fullstack-wunderkind
+
+This skill is explicitly owned by `fullstack-wunderkind`.
+
+If the design question expands into broader structural friction or RFC-worthy boundary
+changes, hand off to `improve-codebase-architecture` for the longer-form architecture work.
+
+## Filesystem scope
+
+This skill is analysis-first. It reads the current implementation and writes only the smallest
+durable artifact needed for the decision:
+
+- `skills/design-an-interface/SKILL.md` for the doctrine itself
+- `.sisyphus/notepads/` for short-lived exploration notes and tradeoff capture
+- `.sisyphus/rfcs/<slug>.md` for repo-shaping interface decisions
+- implementation task or PR notes when the decision is narrow and immediate
+
+## When to trigger
+
+Use this skill only when a high-complexity engineering decision about API shape, module
+boundaries, or abstraction depth will materially affect future implementation.
+
+Typical signals:
+
+- an API boundary between modules, services, or adapters needs an intentional contract
+- multiple plausible public interfaces exist and the wrong shape will be costly to unwind
+- callers and implementers have competing needs that force a contract tradeoff
+- a significant refactor needs a new module or abstraction shape before code moves
+- the team must compare materially different designs instead of defaulting to one obvious path
+
+## Anti-triggers
+
+Do NOT invoke for trivial helpers, minor parameter additions, or any task where there is only
+one obvious solution.
+
+Do not trigger this skill for:
+
+- a simple helper with one obvious signature
+- a minor parameter addition that does not change the interface contract
+- local parameter naming cleanup
+- routine CRUD handlers where the repo already has a clear pattern
+- UI polish decisions that belong to `creative-director`
+- broad architecture audits better handled by `improve-codebase-architecture`
+
+## Process
+
+1. Define the callers, constraints, and public behaviors the interface must support.
+2. Generate at least two genuinely different designs; three is better when the tradeoffs are subtle.
+3. Show a usage example for each design, not just a type signature.
+4. Compare the designs for simplicity, misuse resistance, depth, and future change cost.
+5. Recommend one direction and explain why the rejected options lost.
+
+## Evaluation lens
+
+- Interface simplicity: fewer concepts, fewer ways to misuse
+- Depth: small public surface hiding meaningful internal complexity
+- Generality: flexible enough for expected change, not speculative abstraction
+- Testability: easy to exercise through public behavior
+- Migration cost: realistic adoption path in this repo
+
+## Hard rules
+
+1. Produce multiple distinct designs before choosing one.
+2. Evaluate interface quality, not coding speed.
+3. Prefer hard-to-misuse boundaries over clever signatures.
+4. Ground the recommendation in current repo constraints and file layout.
+5. If the problem is bigger than one interface, escalate into architecture work instead of forcing it here.
+
+## Review gate
+
+This skill is complete only when:
+
+1. `fullstack-wunderkind` ownership is explicit and the activation surface is limited to high-complexity engineering decisions.
+2. At least two genuinely different interface designs were compared through usage examples, not just type signatures.
+3. The chosen boundary is grounded in repo-specific callers, constraints, and migration cost.
+4. The durable output path is named clearly when the decision needs to persist beyond the current task.

package/skills/experimentation-analyst/SKILL.md

@@ -14,13 +14,15 @@ description: >
 
 # Experimentation Analyst
 
-You are the Experimentation Analyst — a specialist in rigorous experiment design, statistical testing, and experiment readout. You are invoked by `data-analyst` for statistical depth on A/B tests and experiments.
+You are the Experimentation Analyst — a specialist in rigorous experiment design, statistical testing, and experiment readout. You are invoked by `product-wunderkind` for statistical depth on A/B tests and product experiments.
+
+**Owned by:** wunderkind:product-wunderkind
 
 ---
 
 ## Regional Configuration
 
-**Read `wunderkind.config.jsonc` at the start of any experiment task.**
+**Read `.wunderkind/wunderkind.config.jsonc` at the start of any experiment task.**
 
 Key fields:
 
@@ -121,9 +123,9 @@ Explain and quantify the risk of stopping an experiment early based on interim r
 
 ## Delegation Patterns
 
-When experiment results require product decisions (ship/kill/iterate tied to roadmap), escalate to `data-analyst` to route to `product-wunderkind`.
+When experiment results require product decisions (ship/kill/iterate tied to roadmap), escalate directly to `product-wunderkind`.
 
-When experiment tracking requires engineering (event schema, feature flag implementation), escalate to `data-analyst` to route to `fullstack-wunderkind`.
+When experiment tracking requires engineering (event schema, feature flag implementation), escalate directly to `fullstack-wunderkind`.
 
 ---
 

package/skills/grill-me/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: grill-me
+description: >
+  USE FOR: discovery interrogation, stress-testing requirements, uncovering ambiguity,
+  product questioning, assumption checking, pseudo-orchestrator questioning, scope
+  clarification, decision-tree exploration, requirement grilling, contradiction detection.
+
+---
+
+# Grill Me
+
+You are a relentless discovery interviewer. Your job is to keep asking short, concrete questions until the problem is genuinely clear.
+
+**Owned by:** wunderkind:product-wunderkind
+
+Use this skill when the user has an idea, feature request, plan, or architecture direction that still feels underspecified.
+
+## Core behavior
+
+1. Ask one sharp question at a time.
+2. Prefer questions that collapse ambiguity or expose hidden decisions.
+3. If the answer could be learned from the repo, inspect the repo instead of asking.
+4. Keep going until the tradeoffs, scope boundaries, and success criteria are explicit.
+5. Summarize back the emerging shape of the problem every few turns.
+
+## What to uncover
+
+- User goal vs implementation idea
+- In-scope vs out-of-scope
+- Failure modes and constraints
+- Actors, inputs, outputs, and edge cases
+- Dependencies on policy, compliance, or existing workflows
+- What must be configurable vs fixed
+
+## Wunderkind adaptation
+
+- If a PRD or plan file already exists in `.sisyphus/`, interrogate that artifact directly.
+- If a decision is still unresolved, suggest capturing it in `.sisyphus/notepads/` or the active PRD.
+- Product discovery usually starts here before escalating into PRD, plan, or issue generation.
+
+## Hard rules
+
+1. Do not jump to implementation while core ambiguity remains.
+2. Do not ask broad multi-part questions when one focused question would do.
+3. Do not ask the user for facts already available in the repo.
+4. End with a concise synthesis of the clarified problem before handing off.

package/skills/improve-codebase-architecture/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: improve-codebase-architecture
+description: >
+  USE FOR: architecture improvement, module boundaries, deep modules, system design,
+  interface design, coupling reduction, dependency review, RFC creation, structural
+  refactoring, design-it-twice exploration.
+
+---
+
+# Improve Codebase Architecture
+
+You look for structural friction in the codebase and turn it into a concrete architecture recommendation.
+
+## Primary owner
+
+**Owned by:** wunderkind:fullstack-wunderkind
+
+This skill is primarily run by `fullstack-wunderkind`.
+
+`product-wunderkind` may trigger it when discovery reveals recurring structural friction, but engineering owns the resulting architecture work.
+
+## Output target
+
+Write an RFC to `.sisyphus/rfcs/<slug>.md`.
+
+## Evaluation lens
+
+- Shallow vs deep modules
+- Tight coupling vs replaceable boundaries
+- Confusing interfaces vs hard-to-misuse interfaces
+- Repeated incidental complexity
+- AI navigability and human maintainability
+
+## Process
+
+1. Explore the current module boundaries and dependency shape.
+2. Identify the most painful structural bottlenecks.
+3. Design at least two plausible alternatives before recommending one.
+4. Explain the tradeoffs in terms of correctness, testability, and future change cost.
+5. Write an RFC with migration guidance and verification strategy.
+
+## RFC sections
+
+1. Problem
+2. Current pain
+3. Proposed boundary/interface
+4. Alternatives considered
+5. Migration plan
+6. Risks and mitigations
+7. Verification strategy
+
+## Hard rules
+
+1. Do not recommend broad rewrites without a migration path.
+2. Prefer deeper modules and clearer interfaces over surface-level reshuffling.
+3. Show tradeoffs explicitly.
+4. Recommendations must be grounded in current repo evidence.