By iurykrieger
Governed adversarial development for AI agents — v5.0 dual Phase-1 entry path (`/yoke:discover` for product-shaped tasks, `/yoke:fix` for engineering-shaped fixes) atop the v4.0 acceptance-criteria QA cutover and the v3.0 agent council protocol. Phase 1 now offers two authoring entrypoints producing interchangeable Phase-1 artifacts (`.yoke/prds/<slug>.md` or `.yoke/fixes/<slug>.md`); downstream skills read whichever exists via `wm_phase1_artifact_path` without branching on the artifact kind. Phase 3 produces a binding Acceptance Criteria document organised as User Stories → Definition of Done → Acceptance Criteria → Sensor pool, authored through an interactive Senior-QA grill. Three runtime persona subagents (Sr Eng, Sr QA, Sr Staff) spawn in parallel each cycle behind a deterministic sync barrier (Phase A), exchange réplicas inside a bounded council loop with a contradiction-detection arbiter (Phase B), and either advance on consensus or escalate Trigger 4 on cap-exhausted divergence (Phase C). Sensor selection per Acceptance Criterion is a runtime council decision, not an authoring-time tag. All inside a binding human contract. Canonical-memory reads and writes dispatch through providers.yaml to a peer plugin (claude-bedrock is the reference implementation); pluggable canonical-memory providers ship via the documented working-memory contract. The Orchestrator subagent survives in canonize-only mode at full-run termination. Manifesto: yoke.md.
Contradiction-detection arbiter spawned by `/yoke:implement` between réplica rounds that produced at least one réplica. Reads the merged view of every persona's slice plus the round's réplica subset; emits exactly one structured JSON verdict matching the spec's `### Contradiction-detection arbiter` schema (round, consensus, contradictions[], tone_only_pairs[]). Read-only; never writes any file. Cites concepts/yoke-pattern-roles for the role contract and concepts/yoke-conventions for the structured-sensor-output contract.
Termination subagent — sole writer of canonical memory under Model C. Single mode (canonize): at /yoke:implement full-run loop termination (every sprint complete), invoke /yoke:canonize via the Skill tool to apply the five-criterion cascade, classify Model C impact, and open Model C-classified PRs. Spawned exactly once per /yoke:implement run, in a single foreground Task call from the coordinator after the council protocol's per-cycle phases (A/B/C) have walked every sprint to convergence.
Inferential-sensor runtime subagent. Spawned by `/yoke:implement` (skills/implement/SKILL.md) per applicable (criterion, inferential sensor) pairing inside the per-cycle background batch. Read-only; never writes host code; never reads progress.md, contracts.md, or canonical memory. The prompt, rubric, and verdict schema this agent applies are not embedded here — they are read at spawn time from the sensor's calibration template (canonical instance: `templates/sensors/semantic-judge.md`). Emits exactly one structured JSON verdict (criterion / sensor / status / location / fix_instruction / evidence / confidence / supporting_quotes).
Council persona — Senior Engineer. Phase A author of working code that closes the next failing Acceptance Criterion(s); owner of happy-path unit tests for any new code path. Phase B participant in council ponderation. Reads canonical memory only by invoking /yoke:search-canonical-memory via the Skill tool. Never writes canonical memory. Never authors acceptance-criteria-anchored tests (that is Sr QA's anti-scope).
Council persona — Senior QA. Phase A author of acceptance-criteria-anchored tests under tests/acceptance/<contract-slug>/, and judge of computational + inferential sensor verdicts against the binding Acceptance Criteria document's `### Validation` blocks. Phase B participant in council ponderation. Reads canonical memory only by invoking /yoke:search-canonical-memory via the Skill tool. Never writes canonical memory. Never modifies production code (that is Sr Eng's surface).
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.
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.
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.
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.
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.
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimUses power tools
Uses Bash, Write, or Edit tools
Based on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Second Brain automation for Obsidian vaults — entity management, ingestion, compression, and sync via Claude Code skills
npx claudepluginhub iurykrieger/claude-yokeComprehensive skill pack with 66 specialized skills for full-stack developers: 12 language experts (Python, TypeScript, Go, Rust, C++, Swift, Kotlin, C#, PHP, Java, SQL, JavaScript), 10 backend frameworks, 6 frontend/mobile, plus infrastructure, DevOps, security, and testing. Features progressive disclosure architecture for 50% faster loading.
Develop, test, build, and deploy Godot 4.x games with Claude Code. Includes GdUnit4 testing, web/desktop exports, CI/CD pipelines, and deployment to Vercel/GitHub Pages/itch.io.
Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review
Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification
Harness-native ECC plugin for engineering teams - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses
Access thousands of AI prompts and skills directly in your AI coding assistant. Search prompts, discover skills, save your own, and improve prompts with AI.