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.
Lazy senior dev mode. Forces the simplest, shortest solution that actually works: YAGNI, stdlib first, no unrequested abstractions.
Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification
A growing collection of Claude-compatible academic workflow bundles. Covers scientific figures, manuscript writing and polishing, reviewer assessment, citation retrieval, data availability, paper reading, literature search, response letters, paper-to-PPTX conversion, and evidence-grounded Chinese invention patent drafting. Rules are organized as reusable skill folders with explicit workflows and quality checks.
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