@hecer/yoke 1.6.0 → 1.6.1

package/canon/loop/loop-spec.md

@@ -1,65 +1,65 @@
-# Loop Specification (Ralph + GSD)
-
-The autonomous loop is optional and toggle-able:
-
-- `yoke loop on` / `yoke loop off` — enable or disable it in `.yoke/config.yaml`.
-- `yoke loop status` — show enabled state and backlog progress.
-- `yoke loop run [--max=N] [--parallel=N] [--isolate] [--decision-policy=auto|critical] [--quality|--no-quality] [--quality-rounds=N] [--quality-minutes=N] [--quality-policy=blocking|advisory] [--quality-unbounded] [--candidates=N]` — run until the current backlog is green or a gate blocks.
-- `yoke change add --idea="..."` — queue a product change at any time, including while the loop is running.
-- `yoke loop decision` / `yoke loop answer --choice=<id>` — inspect and answer a structured critical stop.
-
-Pass `--isolate` to implement each story in a fresh git worktree. Only a verified, committed
-story is fast-forwarded to the main tree. Pass `--review` or `--reviewer=<provider>` to require
-a separate, schema-validated review. Pass `--parallel=N` to dispatch ready, non-colliding stories
-concurrently. Pass `--json` for NDJSON status on stdout.
-
-Stories may declare a reference, candidate artifact, rubric, and blocking/advisory quality policy.
-`--quality` runs a read-only blind critic plus bounded repair before review; every repair reruns the
-mechanical gates. `--candidates=N` requires quality declarations and dispatches multiple isolated
-implementations, rejects mechanically red candidates, selects one green candidate through opaque
-pairwise handles, and retains every candidate's terminal proof before cleanup. Parallel/candidate
-runs do not combine with adaptive routing.
-
-At every story boundary, Yoke consumes at most one queued change. The configured Claude,
-Codex, or Gemini provider may propose only new stories in a separate runtime file. A fresh
-coverage-review pass must account for every distinct requested outcome before Yoke validates
-strict criterion evidence, appends the stories itself, commits only the PRD, and leaves existing
-stories untouched. The request stays pending on any failure or uncovered outcome.
-
-For each story:
-
-1. Require a clean git worktree.
-2. Pick the highest-priority ready unfinished story, or claim multiple dependency-ready stories
-   whose collision areas do not overlap when parallel dispatch is enabled.
-3. Stop the line if acceptance is empty. With `verify.requireCriteria: true`, every criterion
-   must be structured. Every structured criterion, including in compatible legacy projects,
-   must use a single approved test command containing its criterion ID and no shell operators.
-4. Run a fresh configured provider to implement exactly one story. Under the `critical`
-   decision policy, only high-impact architecture, security/privacy, destructive data,
-   material cost, compliance, or irreversible choices may pause for a human decision.
-5. Run every structured criterion's targeted commands and write
-   `.yoke/proof/<story>/evidence.json`. Then run project-wide `verify.command` (or detected
-   `npm test`). Performance and audit follow when configured. If quality is enabled, collect the
-   declared artifact, run the blind critic, and repair within the configured round/time bounds.
-   Independent review follows. Any blocking failure stops the candidate.
-6. Parallel workers enqueue green candidate commits. The integrator applies one at a time and
-   reruns mechanical gates, fresh quality, and review against the integrated tree. Failed
-   integration reopens the story and retains proof.
-7. Only after all gates pass, mark the story `passes: true`, log the decision, and commit
-   atomically. A failed commit restores the PRD state.
-8. When all current stories pass, run optional `completion.command` against the integrated
-   system. Only a green result reports `complete`; otherwise the loop blocks. This readiness
-   result is ephemeral, not a release and not a freeze on future changes.
-
-A supervisor can pause the loop by creating `.yoke/loop.pause`. The running story finishes;
-the dispatcher latches the signal, stops launching new workers, lets active workers reach safe
-terminal proof/cleanup, and exits with code `3` before another story is integrated.
-
-State lives outside model context: PRD, git, and the ignored `.yoke/changes/` inbox. All are
-re-read at story boundaries, so a request queued mid-run becomes additional stories without a
-restart.
-
-## Limitations
-
-Yoke cannot infer the correct end-to-end journey command. Projects that need integrated
-readiness must configure `completion.command`, for example a Playwright journey suite.
+# Loop Specification (Ralph + GSD)
+
+The autonomous loop is optional and toggle-able:
+
+- `yoke loop on` / `yoke loop off` — enable or disable it in `.yoke/config.yaml`.
+- `yoke loop status` — show enabled state and backlog progress.
+- `yoke loop run [--max=N] [--parallel=N] [--isolate] [--decision-policy=auto|critical] [--quality|--no-quality] [--quality-rounds=N] [--quality-minutes=N] [--quality-policy=blocking|advisory] [--quality-unbounded] [--candidates=N]` — run until the current backlog is green or a gate blocks.
+- `yoke change add --idea="..."` — queue a product change at any time, including while the loop is running.
+- `yoke loop decision` / `yoke loop answer --choice=<id>` — inspect and answer a structured critical stop.
+
+Pass `--isolate` to implement each story in a fresh git worktree. Only a verified, committed
+story is fast-forwarded to the main tree. Pass `--review` or `--reviewer=<provider>` to require
+a separate, schema-validated review. Pass `--parallel=N` to dispatch ready, non-colliding stories
+concurrently. Pass `--json` for NDJSON status on stdout.
+
+Stories may declare a reference, candidate artifact, rubric, and blocking/advisory quality policy.
+`--quality` runs a read-only blind critic plus bounded repair before review; every repair reruns the
+mechanical gates. `--candidates=N` requires quality declarations and dispatches multiple isolated
+implementations, rejects mechanically red candidates, selects one green candidate through opaque
+pairwise handles, and retains every candidate's terminal proof before cleanup. Parallel/candidate
+runs do not combine with adaptive routing.
+
+At every story boundary, Yoke consumes at most one queued change. The configured Claude,
+Codex, or Gemini provider may propose only new stories in a separate runtime file. A fresh
+coverage-review pass must account for every distinct requested outcome before Yoke validates
+strict criterion evidence, appends the stories itself, commits only the PRD, and leaves existing
+stories untouched. The request stays pending on any failure or uncovered outcome.
+
+For each story:
+
+1. Require a clean git worktree.
+2. Pick the highest-priority ready unfinished story, or claim multiple dependency-ready stories
+   whose collision areas do not overlap when parallel dispatch is enabled.
+3. Stop the line if acceptance is empty. With `verify.requireCriteria: true`, every criterion
+   must be structured. Every structured criterion, including in compatible legacy projects,
+   must use a single approved test command containing its criterion ID and no shell operators.
+4. Run a fresh configured provider to implement exactly one story. Under the `critical`
+   decision policy, only high-impact architecture, security/privacy, destructive data,
+   material cost, compliance, or irreversible choices may pause for a human decision.
+5. Run every structured criterion's targeted commands and write
+   `.yoke/proof/<story>/evidence.json`. Then run project-wide `verify.command` (or detected
+   `npm test`). Performance and audit follow when configured. If quality is enabled, collect the
+   declared artifact, run the blind critic, and repair within the configured round/time bounds.
+   Independent review follows. Any blocking failure stops the candidate.
+6. Parallel workers enqueue green candidate commits. The integrator applies one at a time and
+   reruns mechanical gates, fresh quality, and review against the integrated tree. Failed
+   integration reopens the story and retains proof.
+7. Only after all gates pass, mark the story `passes: true`, log the decision, and commit
+   atomically. A failed commit restores the PRD state.
+8. When all current stories pass, run optional `completion.command` against the integrated
+   system. Only a green result reports `complete`; otherwise the loop blocks. This readiness
+   result is ephemeral, not a release and not a freeze on future changes.
+
+A supervisor can pause the loop by creating `.yoke/loop.pause`. The running story finishes;
+the dispatcher latches the signal, stops launching new workers, lets active workers reach safe
+terminal proof/cleanup, and exits with code `3` before another story is integrated.
+
+State lives outside model context: PRD, git, and the ignored `.yoke/changes/` inbox. All are
+re-read at story boundaries, so a request queued mid-run becomes additional stories without a
+restart.
+
+## Limitations
+
+Yoke cannot infer the correct end-to-end journey command. Projects that need integrated
+readiness must configure `completion.command`, for example a Playwright journey suite.

package/canon/loop/prd.schema.md

@@ -1,43 +1,43 @@
-# PRD Schema
-
-The loop is driven by a continuous PRD backlog. Each story:
-
-```yaml
-- id: STORY-1
-  title: Short imperative description
-  priority: 1            # lower = higher priority
-  needs: []              # optional dependency IDs; no unknown IDs, self-links, or cycles
-  area: api              # optional collision domain for parallel scheduling
-  agent: codex           # optional claude|codex|gemini affinity
-  acceptance:
-    - id: valid-request-returns-200
-      text: The endpoint returns 200 for a valid request.
-      verify: [npm run test:valid-request-returns-200]
-    - id: invalid-request-returns-400
-      text: The endpoint returns 400 for an invalid request.
-      verify: [npm run test:invalid-request-returns-400]
-  passes: false          # Yoke-owned; true only after all gates pass and the commit lands
-```
-
-Each new story has 2–5 acceptance criteria. Every criterion has a stable `id`, observable
-behavioral `text`, and one or more executable `verify` commands. Each entry is one approved test
-command, contains the normalized criterion ID, and contains no shell control operator. Yoke runs and records each criterion separately in
-`.yoke/proof/<story>/evidence.json`; a broad green suite cannot stand in for an untested
-criterion. Legacy string criteria remain readable, but `verify.requireCriteria: true` blocks
-them.
-
-The binding is deliberately mechanical, not an oracle for product meaning: Yoke can require a
-criterion-targeted test command and a separate coverage review, but it cannot prove that arbitrary
-test code faithfully models the real world. Critical cross-component behavior therefore also
-belongs in a trusted `completion.command` journey suite.
-
-`sourceChange` is an optional Yoke-owned request ID. The change inbox uses it to append new
-stories idempotently; authors normally omit it.
-
-Stories without `needs`, `area`, or `agent` retain serial behavior. A story is ready only when
-every ID in `needs` passes. The scheduler orders ready work by priority, avoids simultaneously
-active areas, and uses `agent` as an affinity hint.
-
-The backlog is continuous, not a release object. A momentary stop condition is every story
-having `passes: true`; if configured, `completion.command` must then prove the integrated
-system before the loop reports `complete`.
+# PRD Schema
+
+The loop is driven by a continuous PRD backlog. Each story:
+
+```yaml
+- id: STORY-1
+  title: Short imperative description
+  priority: 1            # lower = higher priority
+  needs: []              # optional dependency IDs; no unknown IDs, self-links, or cycles
+  area: api              # optional collision domain for parallel scheduling
+  agent: codex           # optional claude|codex|gemini affinity
+  acceptance:
+    - id: valid-request-returns-200
+      text: The endpoint returns 200 for a valid request.
+      verify: [npm run test:valid-request-returns-200]
+    - id: invalid-request-returns-400
+      text: The endpoint returns 400 for an invalid request.
+      verify: [npm run test:invalid-request-returns-400]
+  passes: false          # Yoke-owned; true only after all gates pass and the commit lands
+```
+
+Each new story has 2–5 acceptance criteria. Every criterion has a stable `id`, observable
+behavioral `text`, and one or more executable `verify` commands. Each entry is one approved test
+command, contains the normalized criterion ID, and contains no shell control operator. Yoke runs and records each criterion separately in
+`.yoke/proof/<story>/evidence.json`; a broad green suite cannot stand in for an untested
+criterion. Legacy string criteria remain readable, but `verify.requireCriteria: true` blocks
+them.
+
+The binding is deliberately mechanical, not an oracle for product meaning: Yoke can require a
+criterion-targeted test command and a separate coverage review, but it cannot prove that arbitrary
+test code faithfully models the real world. Critical cross-component behavior therefore also
+belongs in a trusted `completion.command` journey suite.
+
+`sourceChange` is an optional Yoke-owned request ID. The change inbox uses it to append new
+stories idempotently; authors normally omit it.
+
+Stories without `needs`, `area`, or `agent` retain serial behavior. A story is ready only when
+every ID in `needs` passes. The scheduler orders ready work by priority, avoids simultaneously
+active areas, and uses `agent` as an affinity hint.
+
+The backlog is continuous, not a release object. A momentary stop condition is every story
+having `passes: true`; if configured, `completion.command` must then prove the integrated
+system before the loop reports `complete`.

package/canon/manifest.yaml

@@ -1,59 +1,59 @@
-name: yoke-canon
-version: 1.6.0
-agents: [claude, codex, gemini]
-skills:
-  - { id: tdd, path: skills/tdd, kind: methodology, invocation: auto }
-  - { id: yoke-retrofit, path: skills/yoke-retrofit, kind: methodology, invocation: auto }
-  - { id: yoke-workflow, path: skills/yoke-workflow, kind: methodology, invocation: auto }
-  - { id: minimal-code, path: skills/minimal-code, kind: methodology, invocation: auto }
-  - { id: maintaining-context, path: skills/maintaining-context, kind: methodology, invocation: auto }
-  # superpowers skills (kind: methodology)
-  - { id: brainstorming, path: skills/brainstorming, kind: methodology, invocation: auto }
-  - { id: writing-plans, path: skills/writing-plans, kind: methodology, invocation: auto }
-  - { id: executing-plans, path: skills/executing-plans, kind: methodology, invocation: auto }
-  - { id: subagent-driven-development, path: skills/subagent-driven-development, kind: methodology, invocation: auto }
-  - { id: systematic-debugging, path: skills/systematic-debugging, kind: methodology, invocation: auto }
-  - { id: verification-before-completion, path: skills/verification-before-completion, kind: methodology, invocation: auto }
-  - { id: using-git-worktrees, path: skills/using-git-worktrees, kind: methodology, invocation: auto }
-  - { id: requesting-code-review, path: skills/requesting-code-review, kind: methodology, invocation: auto }
-  - { id: receiving-code-review, path: skills/receiving-code-review, kind: methodology, invocation: auto }
-  - { id: dispatching-parallel-agents, path: skills/dispatching-parallel-agents, kind: methodology, invocation: auto }
-  - { id: finishing-a-development-branch, path: skills/finishing-a-development-branch, kind: methodology, invocation: auto }
-  - { id: writing-skills, path: skills/writing-skills, kind: methodology, invocation: auto }
-  # gstack skills (kind: role)
-  - { id: review, path: skills/review, kind: role, invocation: auto }
-  - { id: ship, path: skills/ship, kind: role, invocation: auto }
-  - { id: health, path: skills/health, kind: role, invocation: auto }
-  - { id: retro, path: skills/retro, kind: role, invocation: auto }
-  - { id: document-release, path: skills/document-release, kind: role, invocation: auto }
-  - { id: plan-ceo-review, path: skills/plan-ceo-review, kind: role, invocation: auto }
-  - { id: plan-eng-review, path: skills/plan-eng-review, kind: role, invocation: auto }
-  # authored workflow skill (kind: methodology)
-  - { id: workflow, path: skills/workflow, kind: methodology, invocation: auto }
-  # visual & design verification (kind: methodology)
-  - { id: unslop-ui, path: skills/unslop-ui, kind: methodology, invocation: auto }
-  - { id: visual-verification, path: skills/visual-verification, kind: methodology, invocation: auto }
-  # zero-to-100 bootstrap (kind: methodology)
-  - { id: authoring-prd, path: skills/authoring-prd, kind: methodology, invocation: auto }
-  # measured efficiency (kind: methodology)
-  - { id: performance, path: skills/performance, kind: methodology, invocation: auto }
-  # prose, domain, and codebase capabilities
-  - { id: no-ai-slop, path: skills/no-ai-slop, kind: methodology, invocation: auto }
-  - { id: domain-modeling, path: skills/domain-modeling, kind: methodology, invocation: auto }
-  - { id: codebase-design, path: skills/codebase-design, kind: methodology, invocation: auto }
-  - { id: resolving-merge-conflicts, path: skills/resolving-merge-conflicts, kind: methodology, invocation: auto }
-  - { id: writing-for-agents, path: skills/writing-for-agents, kind: methodology, invocation: auto }
-policy:
-  - { path: policy/gates.md }
-  - { path: policy/roles.md }
-loop:
-  spec: loop/loop-spec.md
-  prdSchema: loop/prd.schema.md
-tools:
-  - { id: rtk, path: tools/rtk.md }
-  - { id: graphify, path: tools/graphify.md }
-  - { id: playwright-mcp, path: tools/playwright-mcp.md }
-  - { id: serena, path: tools/serena.md }
-  # optional companions (external installers; documented wiring only)
-  - { id: claude-mem, path: tools/claude-mem.md }
-  - { id: ui-ux-pro-max, path: tools/ui-ux-pro-max.md }
+name: yoke-canon
+version: 1.6.1
+agents: [claude, codex, gemini]
+skills:
+  - { id: tdd, path: skills/tdd, kind: methodology, invocation: auto }
+  - { id: yoke-retrofit, path: skills/yoke-retrofit, kind: methodology, invocation: auto }
+  - { id: yoke-workflow, path: skills/yoke-workflow, kind: methodology, invocation: auto }
+  - { id: minimal-code, path: skills/minimal-code, kind: methodology, invocation: auto }
+  - { id: maintaining-context, path: skills/maintaining-context, kind: methodology, invocation: auto }
+  # superpowers skills (kind: methodology)
+  - { id: brainstorming, path: skills/brainstorming, kind: methodology, invocation: auto }
+  - { id: writing-plans, path: skills/writing-plans, kind: methodology, invocation: auto }
+  - { id: executing-plans, path: skills/executing-plans, kind: methodology, invocation: auto }
+  - { id: subagent-driven-development, path: skills/subagent-driven-development, kind: methodology, invocation: auto }
+  - { id: systematic-debugging, path: skills/systematic-debugging, kind: methodology, invocation: auto }
+  - { id: verification-before-completion, path: skills/verification-before-completion, kind: methodology, invocation: auto }
+  - { id: using-git-worktrees, path: skills/using-git-worktrees, kind: methodology, invocation: auto }
+  - { id: requesting-code-review, path: skills/requesting-code-review, kind: methodology, invocation: auto }
+  - { id: receiving-code-review, path: skills/receiving-code-review, kind: methodology, invocation: auto }
+  - { id: dispatching-parallel-agents, path: skills/dispatching-parallel-agents, kind: methodology, invocation: auto }
+  - { id: finishing-a-development-branch, path: skills/finishing-a-development-branch, kind: methodology, invocation: auto }
+  - { id: writing-skills, path: skills/writing-skills, kind: methodology, invocation: auto }
+  # gstack skills (kind: role)
+  - { id: review, path: skills/review, kind: role, invocation: auto }
+  - { id: ship, path: skills/ship, kind: role, invocation: auto }
+  - { id: health, path: skills/health, kind: role, invocation: auto }
+  - { id: retro, path: skills/retro, kind: role, invocation: auto }
+  - { id: document-release, path: skills/document-release, kind: role, invocation: auto }
+  - { id: plan-ceo-review, path: skills/plan-ceo-review, kind: role, invocation: auto }
+  - { id: plan-eng-review, path: skills/plan-eng-review, kind: role, invocation: auto }
+  # authored workflow skill (kind: methodology)
+  - { id: workflow, path: skills/workflow, kind: methodology, invocation: auto }
+  # visual & design verification (kind: methodology)
+  - { id: unslop-ui, path: skills/unslop-ui, kind: methodology, invocation: auto }
+  - { id: visual-verification, path: skills/visual-verification, kind: methodology, invocation: auto }
+  # zero-to-100 bootstrap (kind: methodology)
+  - { id: authoring-prd, path: skills/authoring-prd, kind: methodology, invocation: auto }
+  # measured efficiency (kind: methodology)
+  - { id: performance, path: skills/performance, kind: methodology, invocation: auto }
+  # prose, domain, and codebase capabilities
+  - { id: no-ai-slop, path: skills/no-ai-slop, kind: methodology, invocation: auto }
+  - { id: domain-modeling, path: skills/domain-modeling, kind: methodology, invocation: auto }
+  - { id: codebase-design, path: skills/codebase-design, kind: methodology, invocation: auto }
+  - { id: resolving-merge-conflicts, path: skills/resolving-merge-conflicts, kind: methodology, invocation: auto }
+  - { id: writing-for-agents, path: skills/writing-for-agents, kind: methodology, invocation: auto }
+policy:
+  - { path: policy/gates.md }
+  - { path: policy/roles.md }
+loop:
+  spec: loop/loop-spec.md
+  prdSchema: loop/prd.schema.md
+tools:
+  - { id: rtk, path: tools/rtk.md }
+  - { id: graphify, path: tools/graphify.md }
+  - { id: playwright-mcp, path: tools/playwright-mcp.md }
+  - { id: serena, path: tools/serena.md }
+  # optional companions (external installers; documented wiring only)
+  - { id: claude-mem, path: tools/claude-mem.md }
+  - { id: ui-ux-pro-max, path: tools/ui-ux-pro-max.md }

package/canon/policy/gates.md

@@ -1,7 +1,7 @@
-# Stop-the-Line Gates
-
-These gates are enforced mechanically by the Loop (Baustein C) and expected of every agent run.
-
-- **DoD gate:** Implementation may not begin until Definition of Done / Acceptance Criteria for the unit of work exist and are recorded (e.g., in the PRD story).
-- **Green-tests gate:** A unit of work is not complete until its tests pass.
-- **Clean-worktree gate:** No dispatch into a dirty or conflicted git worktree.
+# Stop-the-Line Gates
+
+These gates are enforced mechanically by the Loop (Baustein C) and expected of every agent run.
+
+- **DoD gate:** Implementation may not begin until Definition of Done / Acceptance Criteria for the unit of work exist and are recorded (e.g., in the PRD story).
+- **Green-tests gate:** A unit of work is not complete until its tests pass.
+- **Clean-worktree gate:** No dispatch into a dirty or conflicted git worktree.

package/canon/policy/roles.md

@@ -1,9 +1,9 @@
-# Role Separation
-
-The agent that performs a role must not also perform a conflicting one:
-
-- **Implementer ≠ Reviewer** — implementation is not self-reviewed.
-- **Implementer ≠ Merger** — the implementer does not merge their own change.
-- **Implementer ≠ Security auditor** — security is not self-audited.
-
-In the Loop, these map to separate iterations with fresh context.
+# Role Separation
+
+The agent that performs a role must not also perform a conflicting one:
+
+- **Implementer ≠ Reviewer** — implementation is not self-reviewed.
+- **Implementer ≠ Merger** — the implementer does not merge their own change.
+- **Implementer ≠ Security auditor** — security is not self-audited.
+
+In the Loop, these map to separate iterations with fresh context.

package/canon/skills/ATTRIBUTION.md

@@ -1,99 +1,99 @@
-# Attribution
-
-The skills in this directory are ported from two MIT-licensed open-source projects.
-Their content is used under the terms of the MIT License reproduced below.
-
----
-
-## gstack
-
-**Source:** https://github.com/garrytan/gstack
-
-**Skills ported:** review, ship, health, retro, document-release, plan-ceo-review,
-plan-eng-review
-
----
-
-## superpowers
-
-**Source:** https://github.com/obra/superpowers
-
-**Skills ported:** tdd (from test-driven-development), brainstorming, writing-plans,
-executing-plans, subagent-driven-development, systematic-debugging,
-verification-before-completion, using-git-worktrees, requesting-code-review,
-receiving-code-review, dispatching-parallel-agents, finishing-a-development-branch,
-writing-skills
-
----
-
-## vibecoded-design-tells (research credit)
-
-**Source:** https://github.com/JCarterJohnson/vibecoded-design-tells (MIT © 2026 Carter Johnson)
-
-The `unslop-ui` rubric and the `yoke design-scan` tell set are **informed by** this data-ranked
-study of AI-generated-UI tells. Yoke implements the idea **natively in TypeScript** and copies no
-code or data — credited here in the spirit of the MIT license.
-
----
-
-### gstack (cross-model review, idea credit)
-
-The interactive `yoke review` command is inspired by gstack's `/codex` skill
-(https://github.com/garrytan/gstack, MIT © Garry Tan) — an independent second-model
-review with a pass/fail gate. Yoke's implementation is native and cross-agent; no code
-or data was copied.
-
-Likewise, the browser-QA-as-gate idea behind gstack's `/qa` skill is natively
-re-implemented as `yoke flow-smoke` — cross-agent, with a proof-artifact contract
-(screenshots always, video kept on failure, under `.yoke/proof/<story>/`); no code
-was copied.
-
----
-
-## no-ai-slop
-
-**Source:** https://github.com/petergyang/no-ai-slop
-
-**Copyright:** Copyright (c) 2026 Peter Yang
-
-**Skills adapted:** no-ai-slop and its evaluation checklist
-
-Yoke preserves the upstream Edit and Detect modes, voice-preserving workflow, named-pattern
-approach, and no-authorship-guess boundary. The adaptation adds Yoke's precise-domain-term rule,
-portable package wording, and a shorter evaluation checklist.
-
----
-
-## mattpocock/skills
-
-**Source:** https://github.com/mattpocock/skills
-
-**Copyright:** Copyright (c) 2026 Matt Pocock
-
-**Skills adapted:** domain-modeling, codebase-design, resolving-merge-conflicts,
-writing-for-agents, and their supporting references
-
-The adaptations use `.yoke/context/` as Yoke's durable context location, preserve Yoke's existing
-authorization and verification rules, and remove provider-specific metadata from Canon source.
-
----
-
-## MIT License
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+# Attribution
+
+The skills in this directory are ported from two MIT-licensed open-source projects.
+Their content is used under the terms of the MIT License reproduced below.
+
+---
+
+## gstack
+
+**Source:** https://github.com/garrytan/gstack
+
+**Skills ported:** review, ship, health, retro, document-release, plan-ceo-review,
+plan-eng-review
+
+---
+
+## superpowers
+
+**Source:** https://github.com/obra/superpowers
+
+**Skills ported:** tdd (from test-driven-development), brainstorming, writing-plans,
+executing-plans, subagent-driven-development, systematic-debugging,
+verification-before-completion, using-git-worktrees, requesting-code-review,
+receiving-code-review, dispatching-parallel-agents, finishing-a-development-branch,
+writing-skills
+
+---
+
+## vibecoded-design-tells (research credit)
+
+**Source:** https://github.com/JCarterJohnson/vibecoded-design-tells (MIT © 2026 Carter Johnson)
+
+The `unslop-ui` rubric and the `yoke design-scan` tell set are **informed by** this data-ranked
+study of AI-generated-UI tells. Yoke implements the idea **natively in TypeScript** and copies no
+code or data — credited here in the spirit of the MIT license.
+
+---
+
+### gstack (cross-model review, idea credit)
+
+The interactive `yoke review` command is inspired by gstack's `/codex` skill
+(https://github.com/garrytan/gstack, MIT © Garry Tan) — an independent second-model
+review with a pass/fail gate. Yoke's implementation is native and cross-agent; no code
+or data was copied.
+
+Likewise, the browser-QA-as-gate idea behind gstack's `/qa` skill is natively
+re-implemented as `yoke flow-smoke` — cross-agent, with a proof-artifact contract
+(screenshots always, video kept on failure, under `.yoke/proof/<story>/`); no code
+was copied.
+
+---
+
+## no-ai-slop
+
+**Source:** https://github.com/petergyang/no-ai-slop
+
+**Copyright:** Copyright (c) 2026 Peter Yang
+
+**Skills adapted:** no-ai-slop and its evaluation checklist
+
+Yoke preserves the upstream Edit and Detect modes, voice-preserving workflow, named-pattern
+approach, and no-authorship-guess boundary. The adaptation adds Yoke's precise-domain-term rule,
+portable package wording, and a shorter evaluation checklist.
+
+---
+
+## mattpocock/skills
+
+**Source:** https://github.com/mattpocock/skills
+
+**Copyright:** Copyright (c) 2026 Matt Pocock
+
+**Skills adapted:** domain-modeling, codebase-design, resolving-merge-conflicts,
+writing-for-agents, and their supporting references
+
+The adaptations use `.yoke/context/` as Yoke's durable context location, preserve Yoke's existing
+authorization and verification rules, and remove provider-specific metadata from Canon source.
+
+---
+
+## MIT License
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.