Implementation discipline for producing verifiable evidence during build work. Replaces "I did it" claims with durable proof artifacts. Use when building features, fixing bugs, or implementing any planned work where verification matters. Triggers on: build mode with strict verification, "prove it works", "show evidence", TDD cycle, implementation with acceptance criteria, any task with frozen criteria. Do NOT use for planning (use planning skill) or post-work verification (use verify skill).
Usage methodology for the pi-verify verification system. When and how to use /freeze and /verify effectively. Covers acceptance criteria format, reviewer mechanics, interpreting verdicts, and integration patterns. Triggers on: /freeze, /verify, "verify this", "check if done", "are we done", "review the work", "verification", "independent review", "blind review". Do NOT use during implementation (use proof-of-work) or during planning (use planning skill).
DoD-aware planning methodology that produces self-contained, verifiable task plans. Every task gets acceptance criteria a blind reviewer can verify, references for context, constraints, non-goals, and danger zones. Use when creating or updating plans via plan_tasks, Plannotator, babysitter, or plain markdown. Triggers on: plan creation, task planning, "plan this", "create tasks", "break this down", acceptance criteria, Definition of Done, DoD, "what does done mean", freeze criteria. Do NOT use for executing/implementing tasks — this skill is for planning phase only.
Write correct BAML code for structured LLM output via pi-baml. Use when authoring dynamic BAML for baml_exec or creating .baml files for the functions registry. Covers type system, prompt patterns, and conventions. Triggers on: BAML, baml_exec, baml_run, .baml file, structured LLM output, typed output, output schema, PiClient, ctx.output_format, @description, @alias, Jinja prompt. Do NOT use for configuring pi-baml settings, understanding BAML runtime internals, or non-pi-baml BAML projects.
Manage, search, annotate, and connect repositories using pi-repos tools. Use when working across multiple repos, discovering architecture patterns, needing context from external projects, searching across codebases, or persisting knowledge about repos for future sessions. Triggers on: repos_annotate, repos_search, repos_add, repos_reference, repos_group, cross-repo, multi-repo, repo management, clone, annotate a repo, register a repo, group workspace, connections, references. Do NOT use for: general git operations (use github skill), creating worktrees (use repos wt directly).