@grant-vine/wunderkind 0.18.2 → 0.19.0

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

@@ -4,7 +4,7 @@ description: >
   USE FOR: repo-local workflow setup, issue flow selection, triage vocabulary,
   glossary/docs location setup, `.sisyphus` 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

@@ -13,7 +13,7 @@ You investigate a bug or support issue, frame repro confidence and severity, and
 
 ## 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

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.