@hecer/yoke 1.5.1 → 1.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/plugin.json +1 -1
- package/.codex-plugin/plugin.json +1 -1
- package/CHANGELOG.md +29 -14
- package/README.md +56 -35
- package/canon/context/GLOSSARY.md +11 -0
- package/canon/manifest.yaml +36 -30
- package/canon/skills/ATTRIBUTION.md +28 -0
- package/canon/skills/codebase-design/DEEPENING.md +15 -0
- package/canon/skills/codebase-design/DESIGN-IT-TWICE.md +12 -0
- package/canon/skills/codebase-design/SKILL.md +39 -0
- package/canon/skills/document-release/SKILL.md +5 -0
- package/canon/skills/domain-modeling/ADR-FORMAT.md +19 -0
- package/canon/skills/domain-modeling/CONTEXT-FORMAT.md +39 -0
- package/canon/skills/domain-modeling/SKILL.md +35 -0
- package/canon/skills/no-ai-slop/SKILL.md +103 -0
- package/canon/skills/no-ai-slop/eval.md +43 -0
- package/canon/skills/resolving-merge-conflicts/SKILL.md +18 -0
- package/canon/skills/writing-for-agents/SKILL-MECHANICS.md +27 -0
- package/canon/skills/writing-for-agents/SKILL.md +42 -0
- package/dist/canon/manifest.js +2 -0
- package/dist/canon/skill-package.js +113 -0
- package/dist/canon/validate.js +16 -1
- package/dist/context/command.js +4 -1
- package/dist/context/context.js +6 -0
- package/dist/loop/dispatcher.js +1 -1
- package/dist/loop/loop.js +26 -0
- package/dist/loop/parallel-command.js +3 -0
- package/dist/loop/run-command.js +11 -0
- package/dist/loop/watchdog.js +28 -11
- package/dist/loop/worker.js +11 -0
- package/dist/retrofit/apply.js +22 -7
- package/dist/retrofit/command.js +4 -1
- package/dist/retrofit/config.js +4 -0
- package/dist/retrofit/context-actions.js +1 -1
- package/dist/retrofit/detect.js +2 -0
- package/dist/retrofit/planners/claude.js +2 -6
- package/dist/retrofit/planners/codex.js +3 -7
- package/dist/retrofit/planners/gemini.js +11 -1
- package/dist/retrofit/report.js +5 -0
- package/dist/retrofit/skill-actions.js +66 -0
- package/dist/retrofit/ui-detect.js +83 -0
- package/dist/scan/gate.js +36 -0
- package/docs/PUBLISHING.md +2 -2
- package/docs/superpowers/plans/2026-08-20-automatic-ui-design-gate.md +59 -0
- package/docs/superpowers/plans/2026-08-20-capability-skills-and-context.md +51 -0
- package/docs/superpowers/plans/2026-08-20-complete-skill-packages-and-invocation.md +59 -0
- package/docs/superpowers/plans/2026-08-20-windows-reliability-and-release.md +67 -0
- package/docs/superpowers/specs/2026-08-20-skill-capabilities-and-reliability-design.md +391 -0
- package/gemini-extension.json +1 -1
- package/package.json +4 -4
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
|
|
3
3
|
"name": "yoke",
|
|
4
4
|
"displayName": "Yoke",
|
|
5
|
-
"version": "1.
|
|
5
|
+
"version": "1.6.0",
|
|
6
6
|
"description": "Cross-agent coding harness: one curated skill canon (TDD, brainstorming, plans, reviews, shipping, design verification) plus mechanical safety gates and an autonomous loop via the yoke CLI.",
|
|
7
7
|
"author": { "name": "HECer", "url": "https://github.com/HECer" },
|
|
8
8
|
"homepage": "https://github.com/HECer/yoke#readme",
|
package/CHANGELOG.md
CHANGED
|
@@ -1,24 +1,39 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
-
## Unreleased
|
|
4
|
-
|
|
5
|
-
## 1.
|
|
6
|
-
|
|
7
|
-
### Fixed
|
|
8
|
-
- Serena MCP configurations generated by Yoke no longer open the local web dashboard automatically on every startup.
|
|
9
|
-
|
|
10
|
-
## 1.5.0 — 2026-08-16
|
|
3
|
+
## Unreleased
|
|
4
|
+
|
|
5
|
+
## 1.6.0 — 2026-08-20
|
|
11
6
|
|
|
12
7
|
### Added
|
|
13
|
-
-
|
|
8
|
+
- The canon now includes `no-ai-slop`, `domain-modeling`, `codebase-design`, `resolving-merge-conflicts`, and `writing-for-agents`, with their supporting templates and evaluation material. Source adaptations are credited in `canon/skills/ATTRIBUTION.md`.
|
|
9
|
+
- UI projects receive an automatic design-quality gate with configurable `design.mode` (`off`, `auto`, or `on`) and score budget. Detection uses package dependencies, UI source files, and configured smoke flows.
|
|
10
|
+
- Durable context now includes a project glossary and can expose an optional bounded-context map.
|
|
11
|
+
|
|
12
|
+
### Changed
|
|
13
|
+
- Retrofit installs complete skill packages for Claude, Codex, and Gemini instead of copying only `SKILL.md`. Local resources, binary files, and executable bits are preserved where supported.
|
|
14
|
+
- Every canon skill declares `invocation: auto|manual`; retrofit maps that policy to Claude frontmatter, Codex `agents/openai.yaml`, and Gemini's generated automatic-skill index.
|
|
15
|
+
- Canon validation rejects missing local Markdown resources, unsafe package entries, symlinks, and provider metadata that conflicts with the manifest.
|
|
16
|
+
|
|
17
|
+
### Fixed
|
|
18
|
+
- Windows provider cleanup now treats a successful `taskkill` as a request and confirms that the recorded PID has stopped before deleting its ownership record.
|
|
19
|
+
|
|
20
|
+
## 1.5.1 — 2026-08-17
|
|
21
|
+
|
|
22
|
+
### Fixed
|
|
23
|
+
- Serena MCP configurations generated by Yoke no longer open the local web dashboard automatically on every startup.
|
|
24
|
+
|
|
25
|
+
## 1.5.0 — 2026-08-16
|
|
26
|
+
|
|
27
|
+
### Added
|
|
28
|
+
- Failed verify, executable-criterion, performance, configured custom-audit, and completion gates now produce deterministic byte-bounded previews and preserve large complete stdout/stderr in content-addressed `.yoke/artifacts/` files with SHA-256 references.
|
|
14
29
|
- Projects can tune `output.previewBytes` and `output.artifactThresholdBytes`; existing projects use backward-compatible 2 KiB/8 KiB defaults.
|
|
15
30
|
- A deterministic local benchmark verifies signal retention, preview bounds, compression measurement, and artifact digest round-trips without making provider-token claims.
|
|
16
31
|
|
|
17
|
-
### Security
|
|
18
|
-
- Output artifact paths sanitize story identifiers, stay below a project-local root, use user-only file modes where supported, and are excluded from Yoke's clean-tree and story-commit operations even in upgraded projects. Raw artifacts are never injected automatically and documentation warns that project commands may emit secrets or personal data.
|
|
19
|
-
- Gate command capture is capped at 16 MiB per stdout/stderr stream. Quota overflow fails closed and labels retained evidence as truncated instead of risking unbounded memory or claiming partial output is complete.
|
|
20
|
-
|
|
21
|
-
## 1.4.0 — 2026-08-15
|
|
32
|
+
### Security
|
|
33
|
+
- Output artifact paths sanitize story identifiers, stay below a project-local root, use user-only file modes where supported, and are excluded from Yoke's clean-tree and story-commit operations even in upgraded projects. Raw artifacts are never injected automatically and documentation warns that project commands may emit secrets or personal data.
|
|
34
|
+
- Gate command capture is capped at 16 MiB per stdout/stderr stream. Quota overflow fails closed and labels retained evidence as truncated instead of risking unbounded memory or claiming partial output is complete.
|
|
35
|
+
|
|
36
|
+
## 1.4.0 — 2026-08-15
|
|
22
37
|
|
|
23
38
|
### Added
|
|
24
39
|
- `yoke loop run --parallel=N` now executes dependency-ready, non-colliding stories through real provider subprocess workers, isolated worktrees, leased claims, and a FIFO integration queue with fresh integrated-system gates.
|
package/README.md
CHANGED
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
# 🐂 Yoke
|
|
4
4
|
|
|
5
|
-
<!-- yoke:version:start -->1.
|
|
6
|
-
<!-- yoke:tests:start -->
|
|
7
|
-
<!-- yoke:skills:start -->
|
|
5
|
+
<!-- yoke:version:start -->1.6.0<!-- yoke:version:end -->
|
|
6
|
+
<!-- yoke:tests:start -->1014<!-- yoke:tests:end -->
|
|
7
|
+
<!-- yoke:skills:start -->34<!-- yoke:skills:end -->
|
|
8
8
|
<!-- yoke:agents:start -->Claude | Codex | Gemini<!-- yoke:agents:end -->
|
|
9
9
|
|
|
10
10
|
### One harness, three agents — and zero trust in "done."
|
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
[](#-license)
|
|
18
18
|

|
|
19
19
|

|
|
20
|
-

|
|
21
21
|

|
|
22
22
|

|
|
23
23
|
|
|
@@ -25,14 +25,14 @@
|
|
|
25
25
|
|
|
26
26
|
</div>
|
|
27
27
|
|
|
28
|
-
> **TL;DR** — `yoke setup .` asks six questions and installs the native harness for your agent. `yoke new my-app --idea="..."` bootstraps a project and drafts its story backlog. `yoke loop run my-app --isolate --review` then implements it behind hard gates: **clean tree → acceptance criteria → your real tests green → an independent model approves → commit**. Add `--parallel=N` for dependency-aware workers, or declare a reference and add `--quality` for a bounded critic/repair gauntlet. If any blocking gate is red, nothing is committed. Proof lives in `.yoke/proof/<story>/`.
|
|
29
|
-
|
|
30
|
-
Yoke 1.5 keeps failed gate output compact without throwing evidence away: deterministic previews
|
|
31
|
-
retain actionable failures and final summaries, while large complete stdout/stderr remains available
|
|
32
|
-
in private, content-addressed local artifacts. Existing projects keep their serial behavior and use
|
|
33
|
-
safe 2 KiB preview / 8 KiB artifact defaults unless configured otherwise.
|
|
34
|
-
|
|
35
|
-
Yoke 1.4 adds opt-in parallel workers and a bounded, reference-driven quality gauntlet without
|
|
28
|
+
> **TL;DR** — `yoke setup .` asks six questions and installs the native harness for your agent. `yoke new my-app --idea="..."` bootstraps a project and drafts its story backlog. `yoke loop run my-app --isolate --review` then implements it behind hard gates: **clean tree → acceptance criteria → your real tests green → an independent model approves → commit**. Add `--parallel=N` for dependency-aware workers, or declare a reference and add `--quality` for a bounded critic/repair gauntlet. If any blocking gate is red, nothing is committed. Proof lives in `.yoke/proof/<story>/`.
|
|
29
|
+
|
|
30
|
+
Yoke 1.5 keeps failed gate output compact without throwing evidence away: deterministic previews
|
|
31
|
+
retain actionable failures and final summaries, while large complete stdout/stderr remains available
|
|
32
|
+
in private, content-addressed local artifacts. Existing projects keep their serial behavior and use
|
|
33
|
+
safe 2 KiB preview / 8 KiB artifact defaults unless configured otherwise.
|
|
34
|
+
|
|
35
|
+
Yoke 1.4 adds opt-in parallel workers and a bounded, reference-driven quality gauntlet without
|
|
36
36
|
changing existing serial loop defaults. See [the 1.4 migration guide](docs/MIGRATING-TO-1.4.md)
|
|
37
37
|
for the new flags, configuration, cleanup behavior, and review-verdict contract.
|
|
38
38
|
|
|
@@ -81,7 +81,7 @@ $ ls reading-app/.yoke/proof/STORY-2/
|
|
|
81
81
|
home.png list.png # photographic evidence, labelled per story
|
|
82
82
|
```
|
|
83
83
|
|
|
84
|
-
Every claim in that transcript is enforced by code paths with tests behind them —
|
|
84
|
+
Every claim in that transcript is enforced by code paths with tests behind them — 1014 of them, and this repo was built by its own loop and gates ([how it was built](#-why--how-it-was-built)).
|
|
85
85
|
|
|
86
86
|
## 🚀 Quickstart
|
|
87
87
|
|
|
@@ -164,7 +164,7 @@ Yoke's CLI is deterministic and chainable by design: an agent (or a shell `&&`)
|
|
|
164
164
|
| `yoke prd draft [dir] --idea= [--runner=] [--force]` | Idea → 5–12 stories with testable acceptance criteria | `0` · `1` invalid/guarded · `2` agent unavailable |
|
|
165
165
|
| `yoke prd check [dir]` | PRD lint gate (schema, dependencies, cycles, duplicate ids, acceptance) | `0` valid · `1` violations |
|
|
166
166
|
| `yoke change add\|status [dir] [--idea=]` | Queue a change at any time; the loop turns it into append-only stories at the next safe boundary | `0` · `1` invalid inbox/request |
|
|
167
|
-
| `yoke context init\|status [dir]` | Durable context layer (`PROJECT/DECISIONS/KNOWLEDGE.md`) | `0` |
|
|
167
|
+
| `yoke context init\|status [dir]` | Durable context layer (`PROJECT/DECISIONS/KNOWLEDGE/GLOSSARY.md`, optional `CONTEXT-MAP.md`) | `0` |
|
|
168
168
|
| `yoke loop on\|off\|status\|decision\|answer\|resume\|run\|cleanup [dir]` | Autonomous loop; `run` supports `--parallel=N`, bounded reference-driven `--quality`, and blind `--candidates=N` selection; `--max=N` creates an intentional batch cap; `cleanup` retains worktrees unless `--remove-worktrees` is explicit | run: `0` complete · `1` blocked/cap · `2` not runnable / already locked · `3` paused |
|
|
169
169
|
| `yoke review [dir] [--reviewer=] [--base=] [--focus=] [--json] [--allow-self-review]` | An independent model writes a schema-valid verdict | `0` approved · `1` findings/invalid verdict · `2` no independent reviewer |
|
|
170
170
|
| `yoke audit [dir] [--json]` | Dependency, high-confidence secret, and sensitive-change audit | `0` green · `1` blocking findings · `2` not runnable |
|
|
@@ -216,9 +216,9 @@ Three layers — **Canon** (`yoke validate`) → **Retrofit** (`yoke retrofit`)
|
|
|
216
216
|
|
|
217
217
|
| Agent | Artifacts |
|
|
218
218
|
|---|---|
|
|
219
|
-
| **Claude** | `.claude/skills
|
|
220
|
-
| **Codex** | `.agents/skills/`, `AGENTS.md`, `RTK.md`, `.codex/config.toml`, native hooks, reusable `.codex/agents/*.toml`, and package plugin metadata |
|
|
221
|
-
| **Gemini** | `GEMINI.md`, `.gemini/commands/*.toml
|
|
219
|
+
| **Claude** | Complete skill packages under `.claude/skills/` (including referenced resources), `AGENTS.md`, `CLAUDE.md`, `.mcp.json` (code-graph + Playwright), and an rtk `PreToolUse` hook when WSL is available |
|
|
220
|
+
| **Codex** | Complete skill packages under `.agents/skills/`, per-skill implicit-invocation policy, `AGENTS.md`, `RTK.md`, `.codex/config.toml`, native hooks, reusable `.codex/agents/*.toml`, and package plugin metadata |
|
|
221
|
+
| **Gemini** | Complete skill packages under `.gemini/skills/`, an auto-invocation index, `GEMINI.md`, `.gemini/commands/*.toml`, and `.gemini/settings.json` (MCP + `AGENTS.md` context) |
|
|
222
222
|
|
|
223
223
|
> **rtk integration:** Claude receives its PreToolUse hook; Codex receives a native hook adapter around `rtk hook check`; Gemini retains instruction-mode fallback where its CLI has no equivalent command-rewrite lifecycle.
|
|
224
224
|
|
|
@@ -231,12 +231,17 @@ Three layers — **Canon** (`yoke validate`) → **Retrofit** (`yoke retrofit`)
|
|
|
231
231
|
> instructions (tech stack, workflow, `@`-includes) inside it. Works in any yoke-written file;
|
|
232
232
|
> content *outside* the markers is still replaced (and backed up under `.yoke/backup/`).
|
|
233
233
|
|
|
234
|
-
## 🧰 What's in the canon —
|
|
234
|
+
## 🧰 What's in the canon — 34 skills
|
|
235
235
|
|
|
236
236
|
`yoke retrofit` installs all of these into each agent natively. Provenance is credited in [`canon/skills/ATTRIBUTION.md`](canon/skills/ATTRIBUTION.md).
|
|
237
237
|
|
|
238
238
|
To stop overlapping skills from auto-invoking against each other, `canon/AGENTS.md` carries a **skill routing & precedence** block (methodology before role; one canonical entrypoint per concern — e.g. pre-merge code review is always `review`), emitted into all three agents.
|
|
239
239
|
|
|
240
|
+
Each manifest entry also declares `invocation: auto|manual`. Retrofit translates that intent into
|
|
241
|
+
the provider's native controls: Claude disables model invocation for manual skills, Codex writes
|
|
242
|
+
`agents/openai.yaml`, and Gemini lists only automatic skills in its generated index. Validation
|
|
243
|
+
rejects conflicting package metadata and broken local Markdown links before anything is installed.
|
|
244
|
+
|
|
240
245
|
**Process / methodology** — *superpowers-derived discipline (13)*
|
|
241
246
|
|
|
242
247
|
| Skill | What it does |
|
|
@@ -267,7 +272,7 @@ To stop overlapping skills from auto-invoking against each other, `canon/AGENTS.
|
|
|
267
272
|
| `retro` | Engineering retrospective from commit history |
|
|
268
273
|
| `document-release` | Post-ship documentation sync (README / CHANGELOG / …) |
|
|
269
274
|
|
|
270
|
-
**Yoke-native** — *authored or adapted for this harness (
|
|
275
|
+
**Yoke-native** — *authored or adapted for this harness (14)*
|
|
271
276
|
|
|
272
277
|
| Skill | What it does |
|
|
273
278
|
|---|---|
|
|
@@ -280,6 +285,11 @@ To stop overlapping skills from auto-invoking against each other, `canon/AGENTS.
|
|
|
280
285
|
| `workflow` | The default order of operations, from idea to deploy |
|
|
281
286
|
| `unslop-ui` | Detect & remove AI-slop design tells (purple gradients, neon glow, emoji-icons…) |
|
|
282
287
|
| `visual-verification` | Widen verify to design-scan + the built-in `yoke flow-smoke` gate (screenshot proofs; video on failure) |
|
|
288
|
+
| `no-ai-slop` | Detect and edit generic AI prose while preserving the author's voice; includes its evaluation rubric |
|
|
289
|
+
| `domain-modeling` | Model boundaries, invariants, vocabulary, context maps, and decision records before implementation |
|
|
290
|
+
| `codebase-design` | Explore architecture, deepen a chosen design, and compare two viable approaches when tradeoffs matter |
|
|
291
|
+
| `resolving-merge-conflicts` | Resolve conflicts by reconstructing intent, then verify the integrated result |
|
|
292
|
+
| `writing-for-agents` | Write compact agent instructions with explicit triggers, constraints, resources, and checks |
|
|
283
293
|
|
|
284
294
|
## 🌱 Zero to 100: `yoke new` + `yoke prd`
|
|
285
295
|
|
|
@@ -328,7 +338,9 @@ flowchart LR
|
|
|
328
338
|
C -- yes --> D[agent implements<br/>one story]
|
|
329
339
|
D --> E{suite + criterion<br/>proof green?}
|
|
330
340
|
E -- no --> X
|
|
331
|
-
E -- yes -->
|
|
341
|
+
E -- yes --> V{UI design<br/>within budget?}
|
|
342
|
+
V -- no --> X
|
|
343
|
+
V -- yes --> F{reviewer<br/>approves?}
|
|
332
344
|
F -- no --> X
|
|
333
345
|
F -- yes --> G[commit + mark passes:true<br/>+ proof in .yoke/proof/]
|
|
334
346
|
G --> I
|
|
@@ -599,7 +611,7 @@ be fast" is a vibe the loop cannot enforce. Yoke makes it mechanical, at two lev
|
|
|
599
611
|
|
|
600
612
|
### Artifact-backed gate output: compact context, complete local evidence
|
|
601
613
|
|
|
602
|
-
Failed verify, executable-criterion, performance, configured custom-audit, and completion commands can emit thousands of
|
|
614
|
+
Failed verify, executable-criterion, performance, configured custom-audit, and completion commands can emit thousands of
|
|
603
615
|
low-signal lines. Yoke keeps the model-visible failure summary deterministic and bounded while
|
|
604
616
|
preserving large raw stdout/stderr below `.yoke/artifacts/`:
|
|
605
617
|
|
|
@@ -619,16 +631,16 @@ for example:
|
|
|
619
631
|
|
|
620
632
|
An agent can read that ordinary file when the preview is insufficient; nothing is injected into
|
|
621
633
|
later stories automatically. Repeated identical failures reuse the same content-addressed path.
|
|
622
|
-
Successful gate output is discarded as before. This affects only commands executed by Yoke's own
|
|
623
|
-
gates. It does **not** intercept tool output generated internally by Claude Code, Codex, or Gemini,
|
|
624
|
-
so benchmark ratios for this feature are not provider-token or billing claims.
|
|
625
|
-
|
|
626
|
-
Command capture is capped at 16 MiB per stdout/stderr stream. Exceeding that quota fails the gate
|
|
627
|
-
closed and stores the captured prefix with a `[truncated output: ...]` marker; Yoke never labels
|
|
628
|
-
partial evidence as full output.
|
|
629
|
-
|
|
630
|
-
Yoke treats `.yoke/artifacts/` as local, non-committable runtime state and excludes it from its
|
|
631
|
-
clean-tree and story-commit operations; `yoke retrofit` also adds it to `.gitignore`. Raw command output is intentionally stored
|
|
634
|
+
Successful gate output is discarded as before. This affects only commands executed by Yoke's own
|
|
635
|
+
gates. It does **not** intercept tool output generated internally by Claude Code, Codex, or Gemini,
|
|
636
|
+
so benchmark ratios for this feature are not provider-token or billing claims.
|
|
637
|
+
|
|
638
|
+
Command capture is capped at 16 MiB per stdout/stderr stream. Exceeding that quota fails the gate
|
|
639
|
+
closed and stores the captured prefix with a `[truncated output: ...]` marker; Yoke never labels
|
|
640
|
+
partial evidence as full output.
|
|
641
|
+
|
|
642
|
+
Yoke treats `.yoke/artifacts/` as local, non-committable runtime state and excludes it from its
|
|
643
|
+
clean-tree and story-commit operations; `yoke retrofit` also adds it to `.gitignore`. Raw command output is intentionally stored
|
|
632
644
|
without redaction so it remains valid evidence and may therefore contain credentials, personal
|
|
633
645
|
data, or other sensitive text emitted by project commands. Inspect artifacts before sharing them.
|
|
634
646
|
|
|
@@ -693,8 +705,14 @@ Unit tests don't catch a blank page, an unwired route, or generic AI-slop design
|
|
|
693
705
|
- **`unslop-ui` + `visual-verification` skills** — the design rubric, plus how to compose a verify
|
|
694
706
|
pipeline (`types → units → design-scan → flow-smoke`).
|
|
695
707
|
|
|
696
|
-
|
|
697
|
-
|
|
708
|
+
Retrofit adds `design: { mode: auto, max: 4 }` when it detects UI dependencies, UI source files,
|
|
709
|
+
or configured smoke flows. In `auto` mode the loop runs the design scan after functional verify and
|
|
710
|
+
before performance/audit; `on` forces it for any project and `off` disables it. Existing explicit
|
|
711
|
+
settings are preserved. `flow-smoke` remains an explicit project verify step because Yoke cannot
|
|
712
|
+
infer how to start each application's server.
|
|
713
|
+
|
|
714
|
+
`unslop-ui` is the visual-design skill. `no-ai-slop` is separate: it reviews prose for generic AI
|
|
715
|
+
patterns and edits only confirmed problems while preserving meaning and voice.
|
|
698
716
|
|
|
699
717
|
*Tell set informed by the MIT-licensed [vibecoded-design-tells](https://github.com/JCarterJohnson/vibecoded-design-tells) research.*
|
|
700
718
|
|
|
@@ -739,8 +757,11 @@ Yoke keeps durable, cross-session context so a fresh-context agent is never blin
|
|
|
739
757
|
- `PROJECT.md` — the north star (goal, constraints, non-goals, success criteria).
|
|
740
758
|
- `DECISIONS.md` — an append-only ledger. The loop adds an entry per completed story; you and agents add the *why*.
|
|
741
759
|
- `KNOWLEDGE.md` — reusable gotchas and conventions.
|
|
760
|
+
- `GLOSSARY.md` — the project's canonical terms, meanings, and aliases.
|
|
761
|
+
- `CONTEXT-MAP.md` — optional bounded-context relationships for projects that need domain mapping.
|
|
742
762
|
|
|
743
|
-
`yoke retrofit` scaffolds
|
|
763
|
+
`yoke retrofit` scaffolds the four core files non-destructively; your edits are never overwritten.
|
|
764
|
+
It reports `CONTEXT-MAP.md` when the optional file already exists.
|
|
744
765
|
The loop reads them into every agent + reviewer prompt and logs decisions back on each story's
|
|
745
766
|
commit. Decision history is explicitly delimited as untrusted reference data, so stored text is
|
|
746
767
|
never treated as fresh instructions. Manage the files directly with `yoke context init` and `yoke context status`. The
|
|
@@ -835,7 +856,7 @@ release provenance.
|
|
|
835
856
|
## 🧪 Development
|
|
836
857
|
|
|
837
858
|
```bash
|
|
838
|
-
npm test # vitest (
|
|
859
|
+
npm test # vitest (1014 tests)
|
|
839
860
|
npm run build # tsc, no emit errors
|
|
840
861
|
npm run yoke -- validate canon
|
|
841
862
|
```
|
package/canon/manifest.yaml
CHANGED
|
@@ -1,42 +1,48 @@
|
|
|
1
1
|
name: yoke-canon
|
|
2
|
-
version: 1.
|
|
2
|
+
version: 1.6.0
|
|
3
3
|
agents: [claude, codex, gemini]
|
|
4
4
|
skills:
|
|
5
|
-
- { id: tdd, path: skills/tdd, kind: methodology }
|
|
6
|
-
- { id: yoke-retrofit, path: skills/yoke-retrofit, kind: methodology }
|
|
7
|
-
- { id: yoke-workflow, path: skills/yoke-workflow, kind: methodology }
|
|
8
|
-
- { id: minimal-code, path: skills/minimal-code, kind: methodology }
|
|
9
|
-
- { id: maintaining-context, path: skills/maintaining-context, kind: methodology }
|
|
5
|
+
- { id: tdd, path: skills/tdd, kind: methodology, invocation: auto }
|
|
6
|
+
- { id: yoke-retrofit, path: skills/yoke-retrofit, kind: methodology, invocation: auto }
|
|
7
|
+
- { id: yoke-workflow, path: skills/yoke-workflow, kind: methodology, invocation: auto }
|
|
8
|
+
- { id: minimal-code, path: skills/minimal-code, kind: methodology, invocation: auto }
|
|
9
|
+
- { id: maintaining-context, path: skills/maintaining-context, kind: methodology, invocation: auto }
|
|
10
10
|
# superpowers skills (kind: methodology)
|
|
11
|
-
- { id: brainstorming, path: skills/brainstorming, kind: methodology }
|
|
12
|
-
- { id: writing-plans, path: skills/writing-plans, kind: methodology }
|
|
13
|
-
- { id: executing-plans, path: skills/executing-plans, kind: methodology }
|
|
14
|
-
- { id: subagent-driven-development, path: skills/subagent-driven-development, kind: methodology }
|
|
15
|
-
- { id: systematic-debugging, path: skills/systematic-debugging, kind: methodology }
|
|
16
|
-
- { id: verification-before-completion, path: skills/verification-before-completion, kind: methodology }
|
|
17
|
-
- { id: using-git-worktrees, path: skills/using-git-worktrees, kind: methodology }
|
|
18
|
-
- { id: requesting-code-review, path: skills/requesting-code-review, kind: methodology }
|
|
19
|
-
- { id: receiving-code-review, path: skills/receiving-code-review, kind: methodology }
|
|
20
|
-
- { id: dispatching-parallel-agents, path: skills/dispatching-parallel-agents, kind: methodology }
|
|
21
|
-
- { id: finishing-a-development-branch, path: skills/finishing-a-development-branch, kind: methodology }
|
|
22
|
-
- { id: writing-skills, path: skills/writing-skills, kind: methodology }
|
|
11
|
+
- { id: brainstorming, path: skills/brainstorming, kind: methodology, invocation: auto }
|
|
12
|
+
- { id: writing-plans, path: skills/writing-plans, kind: methodology, invocation: auto }
|
|
13
|
+
- { id: executing-plans, path: skills/executing-plans, kind: methodology, invocation: auto }
|
|
14
|
+
- { id: subagent-driven-development, path: skills/subagent-driven-development, kind: methodology, invocation: auto }
|
|
15
|
+
- { id: systematic-debugging, path: skills/systematic-debugging, kind: methodology, invocation: auto }
|
|
16
|
+
- { id: verification-before-completion, path: skills/verification-before-completion, kind: methodology, invocation: auto }
|
|
17
|
+
- { id: using-git-worktrees, path: skills/using-git-worktrees, kind: methodology, invocation: auto }
|
|
18
|
+
- { id: requesting-code-review, path: skills/requesting-code-review, kind: methodology, invocation: auto }
|
|
19
|
+
- { id: receiving-code-review, path: skills/receiving-code-review, kind: methodology, invocation: auto }
|
|
20
|
+
- { id: dispatching-parallel-agents, path: skills/dispatching-parallel-agents, kind: methodology, invocation: auto }
|
|
21
|
+
- { id: finishing-a-development-branch, path: skills/finishing-a-development-branch, kind: methodology, invocation: auto }
|
|
22
|
+
- { id: writing-skills, path: skills/writing-skills, kind: methodology, invocation: auto }
|
|
23
23
|
# gstack skills (kind: role)
|
|
24
|
-
- { id: review, path: skills/review, kind: role }
|
|
25
|
-
- { id: ship, path: skills/ship, kind: role }
|
|
26
|
-
- { id: health, path: skills/health, kind: role }
|
|
27
|
-
- { id: retro, path: skills/retro, kind: role }
|
|
28
|
-
- { id: document-release, path: skills/document-release, kind: role }
|
|
29
|
-
- { id: plan-ceo-review, path: skills/plan-ceo-review, kind: role }
|
|
30
|
-
- { id: plan-eng-review, path: skills/plan-eng-review, kind: role }
|
|
24
|
+
- { id: review, path: skills/review, kind: role, invocation: auto }
|
|
25
|
+
- { id: ship, path: skills/ship, kind: role, invocation: auto }
|
|
26
|
+
- { id: health, path: skills/health, kind: role, invocation: auto }
|
|
27
|
+
- { id: retro, path: skills/retro, kind: role, invocation: auto }
|
|
28
|
+
- { id: document-release, path: skills/document-release, kind: role, invocation: auto }
|
|
29
|
+
- { id: plan-ceo-review, path: skills/plan-ceo-review, kind: role, invocation: auto }
|
|
30
|
+
- { id: plan-eng-review, path: skills/plan-eng-review, kind: role, invocation: auto }
|
|
31
31
|
# authored workflow skill (kind: methodology)
|
|
32
|
-
- { id: workflow, path: skills/workflow, kind: methodology }
|
|
32
|
+
- { id: workflow, path: skills/workflow, kind: methodology, invocation: auto }
|
|
33
33
|
# visual & design verification (kind: methodology)
|
|
34
|
-
- { id: unslop-ui, path: skills/unslop-ui, kind: methodology }
|
|
35
|
-
- { id: visual-verification, path: skills/visual-verification, kind: methodology }
|
|
34
|
+
- { id: unslop-ui, path: skills/unslop-ui, kind: methodology, invocation: auto }
|
|
35
|
+
- { id: visual-verification, path: skills/visual-verification, kind: methodology, invocation: auto }
|
|
36
36
|
# zero-to-100 bootstrap (kind: methodology)
|
|
37
|
-
- { id: authoring-prd, path: skills/authoring-prd, kind: methodology }
|
|
37
|
+
- { id: authoring-prd, path: skills/authoring-prd, kind: methodology, invocation: auto }
|
|
38
38
|
# measured efficiency (kind: methodology)
|
|
39
|
-
- { id: performance, path: skills/performance, kind: methodology }
|
|
39
|
+
- { id: performance, path: skills/performance, kind: methodology, invocation: auto }
|
|
40
|
+
# prose, domain, and codebase capabilities
|
|
41
|
+
- { id: no-ai-slop, path: skills/no-ai-slop, kind: methodology, invocation: auto }
|
|
42
|
+
- { id: domain-modeling, path: skills/domain-modeling, kind: methodology, invocation: auto }
|
|
43
|
+
- { id: codebase-design, path: skills/codebase-design, kind: methodology, invocation: auto }
|
|
44
|
+
- { id: resolving-merge-conflicts, path: skills/resolving-merge-conflicts, kind: methodology, invocation: auto }
|
|
45
|
+
- { id: writing-for-agents, path: skills/writing-for-agents, kind: methodology, invocation: auto }
|
|
40
46
|
policy:
|
|
41
47
|
- { path: policy/gates.md }
|
|
42
48
|
- { path: policy/roles.md }
|
|
@@ -50,6 +50,34 @@ was copied.
|
|
|
50
50
|
|
|
51
51
|
---
|
|
52
52
|
|
|
53
|
+
## no-ai-slop
|
|
54
|
+
|
|
55
|
+
**Source:** https://github.com/petergyang/no-ai-slop
|
|
56
|
+
|
|
57
|
+
**Copyright:** Copyright (c) 2026 Peter Yang
|
|
58
|
+
|
|
59
|
+
**Skills adapted:** no-ai-slop and its evaluation checklist
|
|
60
|
+
|
|
61
|
+
Yoke preserves the upstream Edit and Detect modes, voice-preserving workflow, named-pattern
|
|
62
|
+
approach, and no-authorship-guess boundary. The adaptation adds Yoke's precise-domain-term rule,
|
|
63
|
+
portable package wording, and a shorter evaluation checklist.
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## mattpocock/skills
|
|
68
|
+
|
|
69
|
+
**Source:** https://github.com/mattpocock/skills
|
|
70
|
+
|
|
71
|
+
**Copyright:** Copyright (c) 2026 Matt Pocock
|
|
72
|
+
|
|
73
|
+
**Skills adapted:** domain-modeling, codebase-design, resolving-merge-conflicts,
|
|
74
|
+
writing-for-agents, and their supporting references
|
|
75
|
+
|
|
76
|
+
The adaptations use `.yoke/context/` as Yoke's durable context location, preserve Yoke's existing
|
|
77
|
+
authorization and verification rules, and remove provider-specific metadata from Canon source.
|
|
78
|
+
|
|
79
|
+
---
|
|
80
|
+
|
|
53
81
|
## MIT License
|
|
54
82
|
|
|
55
83
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Deepening
|
|
2
|
+
|
|
3
|
+
Classify dependencies before moving shallow behavior behind one interface.
|
|
4
|
+
|
|
5
|
+
1. **In-process:** pure computation or in-memory state. Merge and test through the new interface.
|
|
6
|
+
2. **Local-substitutable:** a real local stand-in exists, such as an in-memory filesystem. Test the
|
|
7
|
+
module with that stand-in; the seam can remain internal.
|
|
8
|
+
3. **Remote but owned:** define a port at the seam. Use the production transport adapter and an
|
|
9
|
+
in-memory test adapter.
|
|
10
|
+
4. **True external:** inject a narrow port for the third-party dependency and test with a controlled
|
|
11
|
+
adapter.
|
|
12
|
+
|
|
13
|
+
Replace shallow implementation tests with tests at the deepened interface once equivalent
|
|
14
|
+
observable coverage exists. Avoid layering both suites indefinitely. If a test must change for an
|
|
15
|
+
internal refactor, it is probably reaching past the interface.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Design it twice
|
|
2
|
+
|
|
3
|
+
Use this only for a consequential interface with more than one credible shape.
|
|
4
|
+
|
|
5
|
+
1. State constraints, dependency categories, required invariants, error modes, and the current
|
|
6
|
+
seam. A small sketch may clarify the problem but must not preselect the answer.
|
|
7
|
+
2. Produce at least two materially different interfaces. When parallel agents are authorized and
|
|
8
|
+
available, one can minimize surface area while another optimizes the common caller or adapter
|
|
9
|
+
flexibility. Otherwise, explore the alternatives sequentially.
|
|
10
|
+
3. For each design, show caller usage, hidden implementation, adapters, and trade-offs.
|
|
11
|
+
4. Compare designs by depth, locality, seam placement, migration cost, and verification surface.
|
|
12
|
+
5. Recommend one design or a concrete hybrid. Do not leave the user with an unranked menu.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: codebase-design
|
|
3
|
+
description: Design or improve deep modules, small interfaces, real seams, and public-interface tests. Use when shaping a module, placing a dependency seam, evaluating shallow pass-through layers, improving testability, or comparing architecture alternatives; do not force unrelated refactors.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Codebase design
|
|
7
|
+
|
|
8
|
+
Design deep modules: substantial behavior behind a small interface, placed at a real seam and
|
|
9
|
+
tested through that interface. Optimize for caller leverage and maintainer locality.
|
|
10
|
+
|
|
11
|
+
## Vocabulary
|
|
12
|
+
|
|
13
|
+
- **Module:** anything with one interface and an implementation, from a function to a package.
|
|
14
|
+
- **Interface:** everything a caller must know: types, invariants, ordering, errors, configuration,
|
|
15
|
+
and relevant performance behavior.
|
|
16
|
+
- **Implementation:** the behavior hidden inside a module.
|
|
17
|
+
- **Depth:** useful behavior per unit of interface a caller must learn.
|
|
18
|
+
- **Seam:** a place where behavior can change without editing the caller at that place.
|
|
19
|
+
- **Adapter:** a concrete implementation that satisfies an interface at a seam.
|
|
20
|
+
- **Leverage:** capability callers gain from a small interface.
|
|
21
|
+
- **Locality:** change, knowledge, bugs, and verification concentrated in one place.
|
|
22
|
+
|
|
23
|
+
Use these terms consistently. Prefer **seam** over the overloaded word **boundary** when discussing
|
|
24
|
+
replaceable behavior.
|
|
25
|
+
|
|
26
|
+
## Design checks
|
|
27
|
+
|
|
28
|
+
- Reduce methods and parameters when callers do not need the exposed choice.
|
|
29
|
+
- Hide repeated orchestration, invariants, and error handling inside the module.
|
|
30
|
+
- Apply the deletion test: deleting a useful module should make its complexity reappear across its
|
|
31
|
+
callers. A layer whose complexity simply vanishes was probably a pass-through.
|
|
32
|
+
- Treat the interface as the test surface. Tests should survive internal refactors.
|
|
33
|
+
- Accept dependencies at real seams instead of constructing hard-to-replace externals internally.
|
|
34
|
+
- Introduce a seam for demonstrated variation. Production plus a meaningful test adapter can make
|
|
35
|
+
two real adapters; a single speculative adapter does not.
|
|
36
|
+
- Return observable results where practical instead of requiring tests to inspect internal state.
|
|
37
|
+
|
|
38
|
+
For dependency-specific deepening, read [DEEPENING.md](DEEPENING.md). For a consequential interface
|
|
39
|
+
with several plausible shapes, read [DESIGN-IT-TWICE.md](DESIGN-IT-TWICE.md).
|
|
@@ -18,6 +18,11 @@ You are running the `document-release` workflow. This runs **after `ship`** (cod
|
|
|
18
18
|
|
|
19
19
|
You are mostly automated. Make obvious factual updates directly. Stop and ask only for risky or subjective decisions.
|
|
20
20
|
|
|
21
|
+
For prose changes, use `no-ai-slop` in Detect mode before editing, then make only the named,
|
|
22
|
+
voice-preserving fixes that apply. Check the result against that skill's `eval.md`. This review is
|
|
23
|
+
advisory, not a mechanical release gate; factual accuracy and the writer's intended meaning take
|
|
24
|
+
priority over stylistic uniformity.
|
|
25
|
+
|
|
21
26
|
**Only stop for:**
|
|
22
27
|
- Risky/questionable doc changes (narrative, philosophy, security, removals, large rewrites)
|
|
23
28
|
- VERSION bump decision (if not already bumped)
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# ADR-class decision format
|
|
2
|
+
|
|
3
|
+
Append a concise entry to `.yoke/context/DECISIONS.md` only when the choice is:
|
|
4
|
+
|
|
5
|
+
1. hard to reverse;
|
|
6
|
+
2. surprising without context; and
|
|
7
|
+
3. the result of a real trade-off.
|
|
8
|
+
|
|
9
|
+
Use this shape:
|
|
10
|
+
|
|
11
|
+
```md
|
|
12
|
+
## YYYY-MM-DD — ADR: Short decision title
|
|
13
|
+
|
|
14
|
+
Context: one sentence describing the constraint or trade-off.
|
|
15
|
+
Decision: one sentence stating the chosen direction and why.
|
|
16
|
+
```
|
|
17
|
+
|
|
18
|
+
Add considered options or consequences only when a future maintainer would otherwise repeat the
|
|
19
|
+
same investigation. Easy, obvious, or no-alternative choices stay out of the decision log.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Glossary and context-map format
|
|
2
|
+
|
|
3
|
+
## GLOSSARY.md
|
|
4
|
+
|
|
5
|
+
```md
|
|
6
|
+
# Glossary
|
|
7
|
+
|
|
8
|
+
## Ordering
|
|
9
|
+
|
|
10
|
+
**Order**
|
|
11
|
+
: A customer's confirmed request for one or more products.
|
|
12
|
+
_Avoid_: Purchase, transaction
|
|
13
|
+
|
|
14
|
+
**Cancellation**
|
|
15
|
+
: The reversal of an entire Order before fulfillment begins.
|
|
16
|
+
_Avoid_: Refund, deletion
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Keep each definition to one or two sentences. Define what the term is, name aliases to avoid, and
|
|
20
|
+
include only concepts specific to this project's domain. Group terms when natural clusters emerge.
|
|
21
|
+
|
|
22
|
+
## CONTEXT-MAP.md
|
|
23
|
+
|
|
24
|
+
Create this optional file only for multiple domain contexts:
|
|
25
|
+
|
|
26
|
+
```md
|
|
27
|
+
# Context Map
|
|
28
|
+
|
|
29
|
+
## Contexts
|
|
30
|
+
|
|
31
|
+
- **Ordering**: receives and tracks customer orders
|
|
32
|
+
- **Billing**: issues invoices and processes payments
|
|
33
|
+
|
|
34
|
+
## Relationships
|
|
35
|
+
|
|
36
|
+
- **Ordering -> Billing**: Ordering emits `OrderConfirmed`; Billing creates an invoice.
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
Name ownership and the observable relationship. Do not turn the map into an implementation dump.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: domain-modeling
|
|
3
|
+
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.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Domain modeling
|
|
7
|
+
|
|
8
|
+
Build the model actively: challenge terms, test relationships with concrete scenarios, compare the
|
|
9
|
+
stated behavior with code, and record a term when it becomes settled.
|
|
10
|
+
|
|
11
|
+
Yoke stores durable context under `.yoke/context/`:
|
|
12
|
+
|
|
13
|
+
- `GLOSSARY.md` is the canonical language for a single domain context.
|
|
14
|
+
- `CONTEXT-MAP.md` is optional and maps multiple domain contexts plus their relationships.
|
|
15
|
+
- `DECISIONS.md` records durable outcomes and ADR-class trade-offs.
|
|
16
|
+
|
|
17
|
+
Read the existing files before proposing vocabulary. Merely consuming their terms is a normal
|
|
18
|
+
context habit, not a reason to run this skill.
|
|
19
|
+
|
|
20
|
+
## Workflow
|
|
21
|
+
|
|
22
|
+
1. Identify overloaded, vague, conflicting, or missing terms in the request and current glossary.
|
|
23
|
+
2. Propose one canonical term and name avoidable aliases. Ask when the distinction changes behavior.
|
|
24
|
+
3. Stress-test relationships with specific scenarios, especially partial, repeated, failed, and
|
|
25
|
+
cross-context cases.
|
|
26
|
+
4. Compare the model with public interfaces, persistence shapes, and relevant tests. Surface a
|
|
27
|
+
contradiction instead of silently choosing one side.
|
|
28
|
+
5. When a term is settled, update `GLOSSARY.md` immediately using
|
|
29
|
+
[CONTEXT-FORMAT.md](CONTEXT-FORMAT.md). Preserve unrelated entries.
|
|
30
|
+
6. Update `CONTEXT-MAP.md` only when the repository contains more than one genuine domain context.
|
|
31
|
+
7. Record an ADR-class decision only when all three thresholds in
|
|
32
|
+
[ADR-FORMAT.md](ADR-FORMAT.md) pass.
|
|
33
|
+
|
|
34
|
+
Glossary definitions describe the domain, not its implementation. General programming concepts do
|
|
35
|
+
not belong there.
|