@grant-vine/wunderkind 0.16.0 → 0.18.2

package/skills/diagnose/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: diagnose
+description: >
+  USE FOR: deterministic bug diagnosis, reproducible failure loops, ranked
+  hypotheses, focused instrumentation, root-cause isolation, and deciding the
+  smallest proving regression surface before implementation starts.
+
+---
+
+# Diagnose
+
+Adapted from Matt Pocock's `diagnose` skill for Wunderkind's engineering, triage, and
+incident-debugging workflow.
+
+## Primary owner
+
+**Owned by:** wunderkind:fullstack-wunderkind
+
+This skill is explicitly owned by `fullstack-wunderkind`.
+
+Use it when the fault is still unclear and engineering must isolate the defect before
+committing to a fix path.
+
+## Filesystem scope
+
+This skill is diagnosis-first. It reads the nearest repro surface and may write to:
+
+- `src/` files only when adding temporary or minimal proving instrumentation
+- `tests/unit/` or the nearest test surface when pinning the failure with a regression
+- `.sisyphus/notepads/` or `.sisyphus/evidence/` when the diagnosis trail must persist
+- `skills/diagnose/SKILL.md` for doctrine maintenance
+
+## When to trigger
+
+Use this skill for:
+
+- bugs that are real but not yet isolated
+- flaky behavior that needs a deterministic repro loop
+- incidents where the likely failing layer is still uncertain
+- regressions where several competing root-cause hypotheses exist
+- product or support handoffs that still need engineering diagnosis before TDD execution
+
+## Anti-triggers
+
+Do not trigger this skill for:
+
+- straightforward fixes where the broken contract and code path are already obvious
+- pure feature work with no defect investigation
+- architecture redesign discussions better served by `design-an-interface` or `improve-codebase-architecture`
+- work that is already in a clear red-green-refactor loop; use `tdd` there instead
+
+## Process
+
+1. Restate the observed failure as a single testable contract.
+2. Build the smallest deterministic repro loop possible.
+3. List the leading hypotheses in ranked order.
+4. Add the minimum instrumentation or probe that can eliminate one hypothesis at a time.
+5. Identify the failing layer: contract, implementation, fixture, dependency, or environment.
+6. Once the root cause is isolated, define the smallest regression surface that should stay green after the fix.
+7. Hand off into `tdd` or direct implementation only after the diagnosis path is stable.
+
+## Diagnostic doctrine
+
+- Prefer deterministic repro over intuition.
+- Change one variable at a time while investigating.
+- Remove temporary instrumentation once the root cause is proven unless it provides lasting operational value.
+- Name the failing layer explicitly before proposing a fix.
+- If the evidence points to auth, authorization, or another security-control boundary, escalate to `ciso` instead of normalizing it as an ordinary bug.
+
+## Hard rules
+
+1. Do not jump to broad rewrites before a repro loop exists.
+2. Do not batch multiple hypotheses into one opaque instrumentation change.
+3. Do not call a problem fixed until the proving regression surface is named.
+4. If the defect becomes clearly behavior-driven, transition into `tdd` instead of keeping diagnosis open-ended.
+
+## Review gate
+
+This skill is complete only when:
+
+1. `fullstack-wunderkind` ownership is explicit.
+2. The workflow is diagnosis-first rather than implementation-first.
+3. The process includes deterministic repro, ranked hypotheses, minimal instrumentation, and a named regression surface.
+4. The boundary with `tdd`, `ciso`, and architecture skills is explicit.

package/skills/docs-with-grill/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: docs-with-grill
+description: >
+  USE FOR: context-aware documentation grilling, Matt-style grill-with-docs adaptation,
+  repo-aware questioning, `CONTEXT.md` maintenance, validating domain language against
+  code and docs, and preparing Wunderkind-native docs follow-up without copying
+  external filesystem layouts verbatim.
+
+---
+
+# Docs With Grill
+
+Stress-test a docs topic, feature description, or product plan against the actual repo, then capture the compact shared context in Wunderkind-native artifacts before the final docs writing begins.
+
+## Primary owner
+
+**Owned by:** wunderkind:product-wunderkind
+
+## Filesystem scope
+
+Read:
+- `CONTEXT.md`
+- `AGENTS.md`
+- `.wunderkind/wunderkind.config.jsonc`
+- `.sisyphus/`
+- docs-output settings if present
+- relevant source files that answer the question more accurately than the user can
+
+Write:
+- `CONTEXT.md`
+- docs-output lanes only when the user explicitly wants docs generated or refreshed
+- `.sisyphus/evidence/*.md` only for hard-to-reverse decisions or reviewable durable proof
+
+## When to trigger
+
+- A feature, workflow, or docs topic needs Matt-style `grill-with-docs` behavior, but adapted to Wunderkind.
+- The docs are drifting because the compact shared context is stale, missing, or contradictory.
+- A maintainer wants one-question-at-a-time interrogation before drafting guides, PRDs, or docs-output updates.
+- The request needs repo inspection plus documentation framing, not just plain writing.
+
+## Anti-triggers
+
+- Do not use this for trivial copyedits or small wording cleanups.
+- Do not use this when the final task is already clear and only polished docs drafting remains — route that to `technical-writer`.
+- Do not invent Matt's `CONTEXT.md` + `docs/adr/*` layout beyond the literal `CONTEXT.md` file adopted by this repo.
+- Do not replace `setup-wunderkind-workflow`; setup still owns the wider workflow contract.
+
+## Process
+
+1. Inspect `CONTEXT.md`, `AGENTS.md`, `.sisyphus/`, and the relevant code before asking the user anything.
+2. Ask one sharp question at a time only when the repo cannot answer it.
+3. Keep a running picture of: product/domain summary, core workflows, shared language, important constraints, and open questions.
+4. Update `CONTEXT.md` only when the clarified context becomes stable enough to help future work.
+5. If the user also wants documentation output, hand off to the appropriate docs-writing lane after the context is no longer ambiguous.
+
+## Hard rules
+
+1. Repo truth beats user memory when the code clearly answers the question.
+2. `CONTEXT.md` must stay compact — summarize, do not dump transcripts.
+3. Ask one question at a time; do not unload a questionnaire.
+4. Prefer Wunderkind-native outputs (`CONTEXT.md`, docs-output lanes, `.sisyphus/evidence/`) over copied external layouts.
+5. If the task becomes pure docs drafting, switch to `technical-writer` instead of overextending this skill.
+
+## Review gate
+
+This skill is complete only when the docs/topic ambiguity has been collapsed, `CONTEXT.md` reflects the clarified shared context when needed, and any follow-on docs-writing path is now clear enough to execute without another discovery loop.

package/skills/setup-wunderkind-workflow/SKILL.md

@@ -20,6 +20,7 @@ Establish the repo-local workflow contract that other Wunderkind skills depend o
 
 Read:
 - `AGENTS.md`
+- `CONTEXT.md`
 - `.wunderkind/wunderkind.config.jsonc`
 - `.sisyphus/`
 - docs-output settings if present
@@ -27,6 +28,7 @@ Read:
 
 Write:
 - `AGENTS.md` (update or add a compact workflow-contract section)
+- `CONTEXT.md` (compact current product/domain context for future docs and grilling work)
 - `.sisyphus/glossary.md`
 - `.sisyphus/triage/README.md`
 
@@ -54,7 +56,7 @@ Walk these one at a time, not all at once:
 ## Process
 
 1. Explore the current repo state before proposing anything.
-2. Summarize what already exists in `AGENTS.md`, `.wunderkind/`, `.sisyphus/`, and GitHub readiness.
+2. Summarize what already exists in `AGENTS.md`, `CONTEXT.md`, `.wunderkind/`, `.sisyphus/`, and GitHub readiness.
 3. Present one setup decision at a time, with a short explainer and a recommended default.
 4. Show the user the draft workflow contract before writing.
 5. Write the agreed contract into Wunderkind-native locations.
@@ -68,6 +70,10 @@ Add or update a compact section summarizing:
 - triage vocabulary
 - glossary / architecture-doc locations
 
+### `CONTEXT.md`
+
+Create or refresh the compact shared context file that future docs-grilling, planning, and handoff workflows should read first. Keep it short, current, and domain-focused.
+
 ### `.sisyphus/triage/README.md`
 
 Record the canonical triage vocabulary and where issue/triage artifacts should live.
@@ -79,10 +85,10 @@ Create or refresh the shared domain glossary if terminology setup is part of the
 ## Hard rules
 
 1. Preserve existing repo conventions where possible; do not flatten them into generic defaults.
-2. Prefer Wunderkind-native locations (`AGENTS.md`, `.sisyphus/*`) over Matt's `docs/agents/*` layout.
+2. Prefer Wunderkind-native locations (`AGENTS.md`, `CONTEXT.md`, `.sisyphus/*`) over Matt's `docs/agents/*` layout.
 3. Confirm each decision with the user before writing.
 4. Keep the written contract concise enough that other skills can read it quickly.
 
 ## Review gate
 
-This skill is complete only when the repo has an explicit, readable workflow contract in `AGENTS.md`, triage conventions are written under `.sisyphus/triage/`, and glossary ownership/location is no longer ambiguous.
+This skill is complete only when the repo has an explicit, readable workflow contract in `AGENTS.md`, the compact shared context in `CONTEXT.md`, triage conventions are written under `.sisyphus/triage/`, and glossary ownership/location is no longer ambiguous.