Total Skills
9
Skills published by iurykrieger with real stars/downloads and source-aware metadata.
Total Skills
9
Total Stars
0
Total Downloads
0
Comparison chart based on real stars and downloads signals from source data.
tech-spec
0
acceptance-criteria
0
ack-sensors
0
discover
0
drift-sense
0
implement
0
status
0
consolidate-sensors
0
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.
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.
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`.
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.
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.
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.