@hecer/yoke 1.11.0 → 1.13.0

package/canon/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -1,39 +1,39 @@
-# Glossary and context-map format
-
-## GLOSSARY.md
-
-```md
-# Glossary
-
-## Ordering
-
-**Order**
-: A customer's confirmed request for one or more products.
-  _Avoid_: Purchase, transaction
-
-**Cancellation**
-: The reversal of an entire Order before fulfillment begins.
-  _Avoid_: Refund, deletion
-```
-
-Keep each definition to one or two sentences. Define what the term is, name aliases to avoid, and
-include only concepts specific to this project's domain. Group terms when natural clusters emerge.
-
-## CONTEXT-MAP.md
-
-Create this optional file only for multiple domain contexts:
-
-```md
-# Context Map
-
-## Contexts
-
-- **Ordering**: receives and tracks customer orders
-- **Billing**: issues invoices and processes payments
-
-## Relationships
-
-- **Ordering -> Billing**: Ordering emits `OrderConfirmed`; Billing creates an invoice.
-```
-
-Name ownership and the observable relationship. Do not turn the map into an implementation dump.
+# Glossary and context-map format
+
+## GLOSSARY.md
+
+```md
+# Glossary
+
+## Ordering
+
+**Order**
+: A customer's confirmed request for one or more products.
+  _Avoid_: Purchase, transaction
+
+**Cancellation**
+: The reversal of an entire Order before fulfillment begins.
+  _Avoid_: Refund, deletion
+```
+
+Keep each definition to one or two sentences. Define what the term is, name aliases to avoid, and
+include only concepts specific to this project's domain. Group terms when natural clusters emerge.
+
+## CONTEXT-MAP.md
+
+Create this optional file only for multiple domain contexts:
+
+```md
+# Context Map
+
+## Contexts
+
+- **Ordering**: receives and tracks customer orders
+- **Billing**: issues invoices and processes payments
+
+## Relationships
+
+- **Ordering -> Billing**: Ordering emits `OrderConfirmed`; Billing creates an invoice.
+```
+
+Name ownership and the observable relationship. Do not turn the map into an implementation dump.

package/canon/skills/domain-modeling/SKILL.md

@@ -1,35 +1,35 @@
----
-name: domain-modeling
-description: Build or sharpen a project's domain language and durable decisions. Use when terminology is fuzzy or contradictory, relationships need scenario testing, the code disagrees with the stated model, or a glossary or ADR-class decision must be updated; do not trigger merely to read existing context.
----
-
-# Domain modeling
-
-Build the model actively: challenge terms, test relationships with concrete scenarios, compare the
-stated behavior with code, and record a term when it becomes settled.
-
-Yoke stores durable context under `.yoke/context/`:
-
-- `GLOSSARY.md` is the canonical language for a single domain context.
-- `CONTEXT-MAP.md` is optional and maps multiple domain contexts plus their relationships.
-- `DECISIONS.md` records durable outcomes and ADR-class trade-offs.
-
-Read the existing files before proposing vocabulary. Merely consuming their terms is a normal
-context habit, not a reason to run this skill.
-
-## Workflow
-
-1. Identify overloaded, vague, conflicting, or missing terms in the request and current glossary.
-2. Propose one canonical term and name avoidable aliases. Ask when the distinction changes behavior.
-3. Stress-test relationships with specific scenarios, especially partial, repeated, failed, and
-   cross-context cases.
-4. Compare the model with public interfaces, persistence shapes, and relevant tests. Surface a
-   contradiction instead of silently choosing one side.
-5. When a term is settled, update `GLOSSARY.md` immediately using
-   [CONTEXT-FORMAT.md](CONTEXT-FORMAT.md). Preserve unrelated entries.
-6. Update `CONTEXT-MAP.md` only when the repository contains more than one genuine domain context.
-7. Record an ADR-class decision only when all three thresholds in
-   [ADR-FORMAT.md](ADR-FORMAT.md) pass.
-
-Glossary definitions describe the domain, not its implementation. General programming concepts do
-not belong there.
+---
+name: domain-modeling
+description: Build or sharpen a project's domain language and durable decisions. Use when terminology is fuzzy or contradictory, relationships need scenario testing, the code disagrees with the stated model, or a glossary or ADR-class decision must be updated; do not trigger merely to read existing context.
+---
+
+# Domain modeling
+
+Build the model actively: challenge terms, test relationships with concrete scenarios, compare the
+stated behavior with code, and record a term when it becomes settled.
+
+Yoke stores durable context under `.yoke/context/`:
+
+- `GLOSSARY.md` is the canonical language for a single domain context.
+- `CONTEXT-MAP.md` is optional and maps multiple domain contexts plus their relationships.
+- `DECISIONS.md` records durable outcomes and ADR-class trade-offs.
+
+Read the existing files before proposing vocabulary. Merely consuming their terms is a normal
+context habit, not a reason to run this skill.
+
+## Workflow
+
+1. Identify overloaded, vague, conflicting, or missing terms in the request and current glossary.
+2. Propose one canonical term and name avoidable aliases. Ask when the distinction changes behavior.
+3. Stress-test relationships with specific scenarios, especially partial, repeated, failed, and
+   cross-context cases.
+4. Compare the model with public interfaces, persistence shapes, and relevant tests. Surface a
+   contradiction instead of silently choosing one side.
+5. When a term is settled, update `GLOSSARY.md` immediately using
+   [CONTEXT-FORMAT.md](CONTEXT-FORMAT.md). Preserve unrelated entries.
+6. Update `CONTEXT-MAP.md` only when the repository contains more than one genuine domain context.
+7. Record an ADR-class decision only when all three thresholds in
+   [ADR-FORMAT.md](ADR-FORMAT.md) pass.
+
+Glossary definitions describe the domain, not its implementation. General programming concepts do
+not belong there.

package/canon/skills/executing-plans/SKILL.md

@@ -1,70 +1,70 @@
----
-name: executing-plans
-description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
----
-
-# Executing Plans
-
-## Overview
-
-Load plan, review critically, execute all tasks, report when complete.
-
-**Announce at start:** "I'm using the executing-plans skill to implement this plan."
-
-**Note:** Tell your human partner that Superpowers works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
-
-## The Process
-
-### Step 1: Load and Review Plan
-1. Read plan file
-2. Review critically - identify any questions or concerns about the plan
-3. If concerns: Raise them with your human partner before starting
-4. If no concerns: Create TodoWrite and proceed
-
-### Step 2: Execute Tasks
-
-For each task:
-1. Mark as in_progress
-2. Follow each step exactly (plan has bite-sized steps)
-3. Run verifications as specified
-4. Mark as completed
-
-### Step 3: Complete Development
-
-After all tasks complete and verified:
-- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
-- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
-- Follow that skill to verify tests, present options, execute choice
-
-## When to Stop and Ask for Help
-
-**STOP executing immediately when:**
-- Hit a blocker (missing dependency, test fails, instruction unclear)
-- Plan has critical gaps preventing starting
-- You don't understand an instruction
-- Verification fails repeatedly
-
-**Ask for clarification rather than guessing.**
-
-## When to Revisit Earlier Steps
-
-**Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
-- Fundamental approach needs rethinking
-
-**Don't force through blockers** - stop and ask.
-
-## Remember
-- Review plan critically first
-- Follow plan steps exactly
-- Don't skip verifications
-- Reference skills when plan says to
-- Stop when blocked, don't guess
-- Never start implementation on main/master branch without explicit user consent
-
-## Integration
-
-**Required workflow skills:**
-- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting
-- **superpowers:writing-plans** - Creates the plan this skill executes
-- **superpowers:finishing-a-development-branch** - Complete development after all tasks
+---
+name: executing-plans
+description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
+---
+
+# Executing Plans
+
+## Overview
+
+Load plan, review critically, execute all tasks, report when complete.
+
+**Announce at start:** "I'm using the executing-plans skill to implement this plan."
+
+**Note:** Tell your human partner that Superpowers works much better with access to subagents. The quality of its work will be significantly higher if run on a platform with subagent support (such as Claude Code or Codex). If subagents are available, use superpowers:subagent-driven-development instead of this skill.
+
+## The Process
+
+### Step 1: Load and Review Plan
+1. Read plan file
+2. Review critically - identify any questions or concerns about the plan
+3. If concerns: Raise them with your human partner before starting
+4. If no concerns: Create TodoWrite and proceed
+
+### Step 2: Execute Tasks
+
+For each task:
+1. Mark as in_progress
+2. Follow each step exactly (plan has bite-sized steps)
+3. Run verifications as specified
+4. Mark as completed
+
+### Step 3: Complete Development
+
+After all tasks complete and verified:
+- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
+- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
+- Follow that skill to verify tests, present options, execute choice
+
+## When to Stop and Ask for Help
+
+**STOP executing immediately when:**
+- Hit a blocker (missing dependency, test fails, instruction unclear)
+- Plan has critical gaps preventing starting
+- You don't understand an instruction
+- Verification fails repeatedly
+
+**Ask for clarification rather than guessing.**
+
+## When to Revisit Earlier Steps
+
+**Return to Review (Step 1) when:**
+- Partner updates the plan based on your feedback
+- Fundamental approach needs rethinking
+
+**Don't force through blockers** - stop and ask.
+
+## Remember
+- Review plan critically first
+- Follow plan steps exactly
+- Don't skip verifications
+- Reference skills when plan says to
+- Stop when blocked, don't guess
+- Never start implementation on main/master branch without explicit user consent
+
+## Integration
+
+**Required workflow skills:**
+- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting
+- **superpowers:writing-plans** - Creates the plan this skill executes
+- **superpowers:finishing-a-development-branch** - Complete development after all tasks