claude-yoke

Phase 3 — Acceptance Criteria. Drives an interactive Senior-QA grill that turns an approved PRD + Tech Spec into a binding artifact organised as User Stories → Definition of Done → Acceptance Criteria → Sensor pool, plus cross-cutting Functional Requirements. Resumes the PRD + Tech Spec back to the user (≤ 25 lines), runs a 1–5 round lettered-options dialogue scoped to base quality gates, and never auto-generates the artifact silently from upstream documents. Saves to `.yoke/acceptance-criteria/<slug>.md`. Pauses for Trigger-3 ratification with the binding statement printed verbatim. Sensor pool is authored unclassified — Sr QA and Sr Staff pick which members apply per Acceptance Criterion at Phase 4 runtime.

Phase 4 — adversarial ralph loop (v3.0 council protocol). Walks sprints serially: reads `current_sprint:` from `.yoke/runtime/progress.md`, loads `.yoke/sprints/<slug>-s<current_sprint>.md` as the cycle's working set, drives every cycle through three named phases — Phase A (parallel persona Tasks behind a deterministic file-marker barrier), Phase B (bounded council loop with quiescence + LLM contradiction- detection arbiter), Phase C (cycle entry on consensus or Trigger 4 on cap-exhausted divergence). Iterates ≤8 cycles against the binding Acceptance Contract, advances the pointer and resets the cycle counter on per-sprint convergence. Sprint contracts on consensus persist to `.yoke/contracts/<slug>.md`; runtime state under `.yoke/runtime/`. At full convergence (every sprint complete), issues one final Orchestrator call with `mode=canonize` to apply the five-criteria filter and propose Model C writes to canonical memory.

Provider-agnostic facade that hands the active task's working memory to the configured canonical-memory provider. Resolves the provider via lib/canonical-memory/resolve-provider.sh, stages the active slug's archive files (prds/, fixes/, specs/, sprints/, acceptance-criteria/, contracts/, runtime/, plus config.yaml) into a fresh tmp directory shaped like .yoke/, dispatches the provider's pinned canonize skill with --working-memory <stage-path>, removes the stage on exit, and appends a single canonize: line to .yoke/runtime/progress.md. The scope is per-task: only the active slug's files are staged; sensors and other tasks' archives stay outside the hand-off. Pure dispatcher semantics — never bundles, summarizes, classifies, or pre-processes the staged tree (the provider owns those decisions); never swallows the provider's exit code. Use when: "canonize", "yoke canonize", "/yoke:canonize", "save working memory to canonical memory", or whenever /yoke:implement terminates.

Phase 1 — Fix-spec authoring (engineering shape). Runs an interactive diagnose-first dialogue (no fixed round count, safety bound 5 turns) to turn a broken-contract report into an approved fix-spec at `.yoke/fixes/<YYYY-MM-DD>-<slug>.md`. Embeds a Senior Engineer persona (literal name uniform with `/yoke:tech-spec`, disambiguated by the Mode tag). Four readiness checks (what broke / repro / expected / blast radius) gate the dialogue: 4/4 pass on the initial input skips dialogue and proceeds straight to draft; <4/4 asks ONLY the missing checks. Four narrowness proxies (component breadth / contract shape / trigger specificity / surface containment) are evaluated every dialogue turn: 4/4 silent, 3/4 writes `scope_caution: <proxy-id>` into the fix-spec frontmatter, ≤ 2/4 aborts with a re-route prompt to `/yoke:discover`. Sets `.yoke/runtime/.current` to the slug; pauses for explicit human approval (Trigger 1) before completing; chains into `/yoke:tech-spec` via the `Skill` tool with documented fallback.

Phase 2.5 — Sprint synthesis. Takes the approved Tech Spec and the ratified Acceptance Criteria for the active slug, synthesizes a task list whose entries realize the Acceptance Criteria's User Stories (US-NNN), partitions the tasks into sprints with explicit delivery objectives and binary DoD, and writes the runtime sprint bundles at `.yoke/sprints/<slug>-s<NN>.md` via `templates/sprint.md`. The skill is the single Phase 2.5 producer of sprint runtime bundles; the legacy `/yoke:tech-spec` stage 3 producer is retired in Sprint 4 of the parent PRD. After the bundle render stage, the skill renders the shared approval menu (`templates/approval-menu.md`) — Trigger 2.5 — and on `approve` / `approve_and_continue` flips every produced sprint file's frontmatter `status: draft` → `status: approved` atomically.

Reports the current task's phase + working-memory presence and the active canonical memory's health. Read-only — never modifies state. Absorbs bedrock's /healthcheck surface (graphify-out integrity, orphan entities, dangling content, old content >15 days) into a single skill. Safe to run at any frequency.

Phase 2 — Technical specification (design doc). Turns an approved PRD into a single-file design doc at `.yoke/specs/<slug>.md` carrying the twelve canonical H2 sections (Context and Scope; Goals and Non-Goals; System Context; Architecture; Stack and Dependencies; APIs and Data Model; Non-Functional Requirements; Alternatives Considered; Trade-offs; Cross-cutting Concerns; Technical Use Cases; Open Questions). Negotiates stack via host-project auto-detection plus a curated market menu by feature category, queries canonical memory for applicable architectural patterns first and falls back to `WebSearch` only when fewer than the configured threshold of pattern entities is returned. Phase 2 NEVER writes any sprint file and NEVER emits a `### Task <ID>` anchor — sprint partition + task breakdown are owned by Phase 3 (`/yoke:acceptance-criteria`). Pauses for Trigger 2 approval, which marks only the spec.

Acknowledges every sensor available for the host project (catalog mode), verifies that every sensor referenced by an Acceptance Contract has a well-formed `.yoke/sensors/<id>.md` file (readiness mode), or creates / updates those sensor files from the contract's `## Sensors registry` block (upsert mode). Deterministic node — no agentic spawning. Output is structured YAML on stdout; diagnostics go to stderr. Sorted output is byte-identical across consecutive invocations on the same project.

Phase 1 — Discovery. Runs an interactive dialogue (1–5 rounds) to turn an idea into an approved PRD with introduction/overview, goals, product invariants, functional requirements (FR-N), non-goals, technical considerations, risks, success metrics, and open questions. User stories (US-###) are authored downstream in `/yoke:acceptance-criteria` (Phase 3) — the PRD captures product intent and cross-cutting FRs; story-level decomposition with DoD and Acceptance Criteria belongs to the Senior-QA grill, not the Product-Manager grill. Saves to `.yoke/prds/<YYYY-MM-DD>-<slug>.md` and sets `.yoke/runtime/.current` to the slug. Pauses for explicit human approval (Trigger 1) before completing.

Phase 6 — continuous drift sensing across codebase, canonical memory, and historical traces. Three modes (--target codebase | canonical-memory | traces). Findings emitted as structured YAML; deprecation propositions go through Model C (typically medium-impact). Runs manually or via the scheduled GitHub Actions workflow at `.github/workflows/yoke-drift-sense.yml`.

Distills the active task's runtime evidence (verdicts under `.yoke/runtime/.judge-verdicts/`, durations under `.yoke/runtime/progress.md`) back into the durable per-sensor files at `.yoke/sensors/<id>.md`. Append-only on the body (`## Known issues`, `## Frequent errors`, and for inferential sensors `## Calibration`); each appended bullet carries a `(cycle N, fix-instruction X)` citation that doubles as the idempotence key. Frontmatter `token_cost` and `time_cost` are recalibrated only when observed-mean delta exceeds 5%. Reads `.yoke/config.yaml` for `sensor_consolidation: review | auto | skip` (default `review`); `skip` is a silent no-op. No arguments.

Provider-agnostic facade for reading the active canonical memory. Resolves the configured provider via lib/canonical-memory/resolve-provider.sh, then dispatches the user's query to the provider's pinned search skill (e.g. /bedrock:ask for the bedrock provider) per providers.yaml. Pure read — never writes, never caches, never reformats. Source-agnostic: callable from any host project regardless of active-task state. Use when: "search canonical memory", "ask the vault", "/yoke:search-canonical-memory", or whenever a Yoke caller needs a read against the configured canonical-memory provider.

Initial setup for a host project that wants to use Yoke. At v2.0.0, /yoke:bootstrap is the single entry point through which a host project's `.yoke/config.yaml :: canonical_memory.provider` lands. Two flows are supported: (Flow A) legacy detection and migration — when the project is on Yoke v1.x, bootstrap detects either `<plugin_dir>/memories.json` or a v1.x-shaped `.yoke/config.yaml` lacking the `provider:` key, preserves `url`/`name`/`default_branch` as passthrough keys, defaults the migrated provider to `bedrock`, and removes `memories.json` after final confirmation; (Flow B) fresh bootstrap — bootstrap reads the curated provider list from the plugin's `providers.yaml`, prompts (or non-interactively selects via `--provider`), warns when the selected provider's `requires.plugin` is not installed, and writes `.yoke/config.yaml`. Idempotent. /yoke:bootstrap is the only Yoke skill that does NOT source `lib/yoke-prelude.sh` — it is the migration entry point.