@grant-vine/wunderkind 0.18.2 → 0.19.1

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

@@ -22,14 +22,14 @@ Read:
 - `CONTEXT.md`
 - `AGENTS.md`
 - `.wunderkind/wunderkind.config.jsonc`
-- `.sisyphus/`
+- `.omo/`
 - 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
+- `.omo/evidence/*.md` only for hard-to-reverse decisions or reviewable durable proof
 
 ## When to trigger
 
@@ -47,7 +47,7 @@ Write:
 
 ## Process
 
-1. Inspect `CONTEXT.md`, `AGENTS.md`, `.sisyphus/`, and the relevant code before asking the user anything.
+1. Inspect `CONTEXT.md`, `AGENTS.md`, `.omo/`, 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.
@@ -58,7 +58,7 @@ Write:
 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.
+4. Prefer Wunderkind-native outputs (`CONTEXT.md`, docs-output lanes, `.omo/evidence/`) over copied external layouts.
 5. If the task becomes pure docs drafting, switch to `technical-writer` instead of overextending this skill.
 
 ## Review gate

package/skills/grill-me/SKILL.md

@@ -34,8 +34,8 @@ Use this skill when the user has an idea, feature request, plan, or architecture
 
 ## 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.
+- If a PRD or plan file already exists in `.omo/`, interrogate that artifact directly.
+- If a decision is still unresolved, suggest capturing it in `.omo/notepads/` or the active PRD.
 - Product discovery usually starts here before escalating into PRD, plan, or issue generation.
 
 ## Hard rules

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

@@ -21,14 +21,14 @@ Surface architectural friction and propose **deepening opportunities** — refac
 
 Read:
 - `AGENTS.md`
-- `.sisyphus/glossary.md` if present
-- `.sisyphus/rfcs/`
+- `.omo/glossary.md` if present
+- `.omo/rfcs/`
 - existing ADR or docs folders relevant to the area
 - the code paths involved in the candidate refactor
 
 Write:
-- `.sisyphus/rfcs/<slug>.md`
-- optionally `.sisyphus/glossary.md` when the architecture discussion depends on a missing canonical term
+- `.omo/rfcs/<slug>.md`
+- optionally `.omo/glossary.md` when the architecture discussion depends on a missing canonical term
 
 ## Architecture language
 
@@ -60,7 +60,7 @@ Use these terms consistently in your analysis:
 
 ## Process
 
-1. Read the project language first: `AGENTS.md`, `.sisyphus/glossary.md`, and any relevant ADR/RFC history.
+1. Read the project language first: `AGENTS.md`, `.omo/glossary.md`, and any relevant ADR/RFC history.
 2. Explore the codebase organically and note where understanding one concept requires bouncing across too many shallow modules.
 3. Apply the **deletion test** to suspected shallow modules: if deleting the module simply moves the same complexity into every caller, it was earning its keep; if complexity vanishes, it was probably a pass-through.
 4. Present a numbered list of deepening opportunities. For each candidate include:
@@ -88,7 +88,7 @@ Use these terms consistently in your analysis:
 1. Ground every recommendation in repo evidence, not generic architecture taste.
 2. Prefer deeper modules and clearer seams over surface-level reshuffling.
 3. Show tradeoffs explicitly using locality, leverage, and testability.
-4. If the conversation depends on a missing domain term, add or update it in `.sisyphus/glossary.md` instead of letting terminology drift.
+4. If the conversation depends on a missing domain term, add or update it in `.omo/glossary.md` instead of letting terminology drift.
 5. Never recommend a rewrite without a staged migration path.
 
 ## Review gate
@@ -96,5 +96,5 @@ Use these terms consistently in your analysis:
 This skill is complete only when:
 - at least one real deepening opportunity is evidenced from the repo
 - the recommendation uses consistent seam/depth/locality language
-- an RFC exists at `.sisyphus/rfcs/<slug>.md`
+- an RFC exists at `.omo/rfcs/<slug>.md`
 - the migration path is incremental and verifiable

package/skills/prd-pipeline/SKILL.md

@@ -15,16 +15,16 @@ This skill converts product intent into a durable delivery workflow.
 
 Read `prdPipelineMode` from `.wunderkind/wunderkind.config.jsonc`.
 
-- `filesystem` — create artifacts in `.sisyphus/` via Wunderkind's bounded durable-artifact writer
+- `filesystem` — create artifacts in `.omo/` via Wunderkind's bounded durable-artifact writer
 - `github` — use `gh`-backed GitHub issues/PRD flow only when the repo is GitHub-ready
 
 If the mode is missing, treat it as `filesystem`.
 
 ## Filesystem mode targets
 
-- PRD: `.sisyphus/prds/<slug>.md`
-- Plan: `.sisyphus/plans/<slug>.md`
-- Work items: `.sisyphus/issues/<slug>-phase-N.md`
+- PRD: `.omo/prds/<slug>.md`
+- Plan: `.omo/plans/<slug>.md`
+- Work items: `.omo/issues/<slug>-phase-N.md`
 
 ## GitHub mode targets
 

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

@@ -2,9 +2,9 @@
 name: setup-wunderkind-workflow
 description: >
   USE FOR: repo-local workflow setup, issue flow selection, triage vocabulary,
-  glossary/docs location setup, `.sisyphus` conventions, and adapting
+  glossary/docs location setup, `.omo` conventions, and adapting
   Matt-style setup patterns to Wunderkind-native files like `AGENTS.md` and
-  `.sisyphus/*`.
+`.omo/*`.
 
 ---
 
@@ -22,15 +22,15 @@ Read:
 - `AGENTS.md`
 - `CONTEXT.md`
 - `.wunderkind/wunderkind.config.jsonc`
-- `.sisyphus/`
+- `.omo/`
 - docs-output settings if present
 - GitHub readiness signals when issue flow might use GitHub
 
 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`
+- `.omo/glossary.md`
+- `.omo/triage/README.md`
 
 ## When to trigger
 
@@ -56,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`, `CONTEXT.md`, `.wunderkind/`, `.sisyphus/`, and GitHub readiness.
+2. Summarize what already exists in `AGENTS.md`, `CONTEXT.md`, `.wunderkind/`, `.omo/`, 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.
@@ -74,21 +74,21 @@ Add or update a compact section summarizing:
 
 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`
+### `.omo/triage/README.md`
 
 Record the canonical triage vocabulary and where issue/triage artifacts should live.
 
-### `.sisyphus/glossary.md`
+### `.omo/glossary.md`
 
 Create or refresh the shared domain glossary if terminology setup is part of the session.
 
 ## Hard rules
 
 1. Preserve existing repo conventions where possible; do not flatten them into generic defaults.
-2. Prefer Wunderkind-native locations (`AGENTS.md`, `CONTEXT.md`, `.sisyphus/*`) over Matt's `docs/agents/*` layout.
+2. Prefer Wunderkind-native locations (`AGENTS.md`, `CONTEXT.md`, `.omo/*`) 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`, the compact shared context in `CONTEXT.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 `.omo/triage/`, and glossary ownership/location is no longer ambiguous.

package/skills/tdd/SKILL.md

@@ -27,7 +27,7 @@ This skill reads the changed implementation plus its nearest test surface and ma
 - `tests/unit/` and colocated `*.test.ts` files
 - `src/` files whose public behavior is under test
 - `skills/tdd/SKILL.md` for doctrine maintenance
-- `.sisyphus/notepads/` or `.sisyphus/evidence/` when a test strategy or defect trail needs to persist
+- `.omo/notepads/` or `.omo/evidence/` when a test strategy or defect trail needs to persist
 
 ## Runtime context
 

package/skills/triage-issue/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: triage-issue
 description: >
-  USE FOR: bug triage, issue investigation, support handoff,
+  USE FOR: bug triage, external PR triage, issue investigation, support handoff,
   incident reproduction, defect documentation, issue scoping,
   support-to-engineering transitions, acceptance clarity, backlog-ready issue shaping.
 
@@ -11,9 +11,11 @@ description: >
 
 You investigate a bug or support issue, frame repro confidence and severity, and produce a durable handoff artifact before implementation begins. Engineering owns root-cause diagnosis and fix implementation; product owns intake quality and acceptance clarity.
 
+If the repo treats external pull requests as an intake surface, triage them with the same discipline: verify the claim, identify the affected contract, and write the next-step brief before anyone starts implementation or merge work.
+
 ## Output mode
 
-- Default: write findings to `.sisyphus/triage/<slug>.md`
+- Default: write findings to `.omo/triage/<slug>.md`
 - If `prdPipelineMode` is `github` and GitHub workflow readiness is confirmed, GitHub issue output is acceptable
 
 ## Required sections
@@ -27,10 +29,12 @@ You investigate a bug or support issue, frame repro confidence and severity, and
 
 ## Workflow
 
-1. Assess and frame repro confidence from available evidence
-2. Frame severity and acceptance criteria from observable behavior
-3. Capture a safe fix direction for engineering handoff
-4. Hand off to fullstack-wunderkind with test-first guidance and clear acceptance criteria
+1. Gather the current issue or PR context, including prior notes, reproduction clues, and the nearest affected code paths.
+2. Check whether the requested behavior already exists or was previously rejected so intake does not create duplicate work.
+3. Assess and frame repro confidence from available evidence, and verify the claim where possible before shaping the handoff.
+4. Frame severity and acceptance criteria from observable behavior.
+5. Capture a safe fix direction for engineering handoff.
+6. Hand off to fullstack-wunderkind with test-first guidance and clear acceptance criteria.
 
 ## Wunderkind ownership
 
@@ -45,3 +49,4 @@ You investigate a bug or support issue, frame repro confidence and severity, and
 2. Record evidence before proposing a fix.
 3. Acceptance criteria must describe observable behavior.
 4. Prefer durable filesystem artifacts over ephemeral chat summaries.
+5. For GitHub-backed triage comments, prepend a clear AI-generated disclaimer before posting user-visible notes.

package/skills/ubiquitous-language/SKILL.md

@@ -3,7 +3,7 @@ name: ubiquitous-language
 description: >
   USE FOR: glossary maintenance, shared terminology cleanup, naming alignment,
   canonical terms, alias resolution, domain-language drift, and explicit updates
-  to `.sisyphus/glossary.md`.
+to `.omo/glossary.md`.
 
 ---
 
@@ -17,7 +17,7 @@ Maintain a shared domain glossary so humans and agents keep using the same words
 
 ## Output target
 
-Write or update `.sisyphus/glossary.md`.
+Write or update `.omo/glossary.md`.
 
 ## When to trigger
 
@@ -46,7 +46,7 @@ Write or update `.sisyphus/glossary.md`.
 2. Extract candidate terms and detect collisions or synonym drift.
 3. Choose canonical terms where the evidence is strong.
 4. Mark unresolved ambiguity explicitly instead of forcing false consensus.
-5. Update `.sisyphus/glossary.md` incrementally.
+5. Update `.omo/glossary.md` incrementally.
 
 ## Formatting guidance
 
@@ -66,4 +66,4 @@ Add an `## Open Questions` section when needed.
 
 ## Review gate
 
-This skill is complete only when `.sisyphus/glossary.md` reflects the canonical term decisions and unresolved ambiguities are clearly flagged.
+This skill is complete only when `.omo/glossary.md` reflects the canonical term decisions and unresolved ambiguities are clearly flagged.

package/skills/write-a-skill/SKILL.md

@@ -26,8 +26,8 @@ technical validation.
 
 - Main asset: `skills/<skill-name>/SKILL.md`
 - Optional references: `skills/<skill-name>/REFERENCE.md`, `skills/<skill-name>/EXAMPLES.md`
-- Supporting evidence: `.sisyphus/evidence/`
-- Durable learnings: `.sisyphus/notepads/`
+- Supporting evidence: `.omo/evidence/`
+- Durable learnings: `.omo/notepads/`
 
 `skills/SKILL-STANDARD.md` is the authoritative skill-writing standard for this repo.
 New and revised skills must follow it: trigger-first descriptions, explicit surviving ownership,
@@ -72,5 +72,5 @@ Do not use this skill for:
 1. Skills are authored in `skills/*/SKILL.md`, not in generated `agents/` output.
 2. Every skill must name its owner, trigger surface, and filesystem scope.
 3. Do not copy external skills verbatim; adapt them to Wunderkind personas and artifacts.
-4. If a workflow produces durable project knowledge, store it in `.sisyphus/`.
+4. If a workflow produces durable project knowledge, store it in `.omo/`.
 5. Keep the main skill tight enough to scan quickly during agent selection.