iurykrieger

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.

Adaptive vault reader skill. Receives a natural language question, uses graph.json as the primary index (Phase 2.0) before any glob/grep, then self-assesses whether more context is needed. Escalates to live /graphify only when graph coverage is insufficient, or to /bedrock:learn for remote content ingestion. Answers simple questions with zero graphify calls. Use when: "bedrock ask", "bedrock-ask", "/bedrock:ask", any question about the vault, "what do we know about", "who owns", "what's the status of", "tell me about", "how does it work", or any Second Brain query.

Single write point for the vault. Centralizes entity detection, textual matching, entity creation/update, and bidirectional linking. Accepts structured input (list of entities), free-form input (text, meeting notes, session context), or graphify output (graph.json + obsidian markdown from /graphify pipeline). Use when: "bedrock preserve", "bedrock-preserve", "save to vault", "record in vault", "/bedrock:preserve", or when another skill (e.g., /bedrock:learn) needs to persist entities in the vault.

Internal fetcher module for Confluence pages. Fetches content via Atlassian MCP (preferred), REST API with Basic Auth (fallback), or browser DOM extraction via Claude in Chrome (last resort) and returns Markdown. Used by /bedrock:learn and /bedrock:sync — not intended for direct user invocation.

Internal fetcher module for Google Docs and Sheets. Fetches content via MCP (preferred, when available), Google API with bearer token or public URL export (fallback), or browser DOM extraction via Claude in Chrome (last resort) and returns Markdown. Used by /bedrock:learn and /bedrock:sync — not intended for direct user invocation.

Read-only vault health diagnostic. Generates a report without modifying any files. Checks: graphify-out integrity, setup verification, orphan entities, dangling content, old content (>15 days). Safe to run at any frequency. Use when: "bedrock healthcheck", "bedrock-healthcheck", "vault health", "check vault", "vault status", "/bedrock:healthcheck".

Ingests an external data source into the Second Brain. Fetches content from Confluence, Google Docs, GitHub repositories, remote URLs, or any local file format supported by docling (DOCX, PPTX, XLSX, PDF, HTML, EPUB, images, Markdown, CSV, and more), converts non-markdown formats to markdown via docling, runs the /graphify extraction pipeline, and delegates entity persistence (including the graphify-output merge) to /bedrock:preserve. Use when: "bedrock learn", "bedrock-learn", "learn", "ingest source", "import document", "/bedrock:learn", or when the user provides a Confluence, Google Docs, or GitHub URL, a remote file URL, or a local file path to incorporate into the vault.

Initialize any folder as a Bedrock-powered Obsidian vault. Creates entity directories, copies templates, configures language and domain taxonomy, scaffolds connected example entities, and checks dependencies. Use when: "bedrock setup", "bedrock-setup", "/bedrock:setup", "initialize vault", "setup vault", "create vault", "bootstrap vault", or when a user wants to start a new Second Brain with Bedrock.

Re-synchronizes the vault with external sources. In default mode, scans the `sources` field of all entities, deduplicates URLs, fetches updated content from each source (Confluence, GDocs, GitHub, Markdown), performs incremental diff and delegates writing to /bedrock:preserve. With --people, scans actor repositories via GitHub API and identifies active contributors. With --github, detects relevant activity in repositories and correlates PRs with topics/projects via LLM semantic matching. Use when: "bedrock sync", "bedrock-sync", "/bedrock:sync", "synchronize", "update sources", "sync people", "sync github".