Guardrails

Guardrails product knowledge for all agents working in this repo. Use when working on anything related to Guardrails: - The task/guardrail/state conceptual model and the four-stage workflow - Plan-folder layout, schemas, or child-process contracts - Harness execution semantics (retry, needs-human, resume, merge) - Authoring or reviewing the plan-breakdown / guardrails-review skills - Roadmap, v2 bets, or scope questions Provides: the mental model, execution semantics, contract quick-reference, and pointers to the single-source-of-truth documents. SELF-UPDATING: When your work changes the domain model, schemas, contracts, execution semantics, or roadmap in ways that affect this knowledge, you MUST update this skill (and docs/plans/02-schemas-and-contracts.md if a contract moved) before completing your task. Update the affected section(s) only.

Break a reviewed markdown plan into a Guardrails task folder — a dependency DAG of tasks, each with an action (script or prompt) and deterministic-first guardrails — executable by the `guardrails` CLI. Use when the user says "break down this plan", "generate tasks for <plan>.md", or hands you a plan path with that intent. Input: path to a REVIEWED `.md` plan. Output: a `<plan-name>/` folder next to the plan, self-validated with `guardrails validate`, presented as a DRAFT for human review. The skill leans deterministic (tests/regex/exit codes) over prompt-judges, and INSERTS guardrail-enabling tasks the plan never mentioned (e.g. "author the unit tests" before "implement the feature").

Adversarial second pass over a generated (and possibly human-edited) Guardrails task folder: per task, find the cheapest WRONG implementation that would pass all its guardrails. Use when the user says "review this task folder", "run guardrail review on <folder>", or after /plan-breakdown produces a draft. Read-only critique by default — applies fixes only with per-finding approval, and never deletes a human-added guardrail without naming it first.

Guardrails repo development knowledge: solution layout, build/test/run commands, dotnet-tool packaging, testing conventions and gotchas, dogfooding safety rules. Use when implementing, testing, running, or packaging the harness, or onboarding an agent to the codebase. SELF-UPDATING: When your work changes the solution layout, conventions, packaging, or any fact below, you MUST update the affected section(s) before completing your task.

Cut a new NuGet release of the `ServantSoftware.Guardrails` dotnet tool. Verify the tree is fully pushed and green, pick the next version, tag it at master HEAD, and let the `release.yml` pipeline publish to NuGet.org via Trusted Publishing (OIDC — no API key to handle). Use when the maintainer says "cut a release", "publish a new version", "ship a NuGet package", or "release preview.N". MAINTAINER-ONLY: this skill is NOT packed into the shipped tool (the csproj bundles only plan-breakdown / guardrails-review / guardrails-domain-knowledge). It lives in the repo for anyone releasing Guardrails. SELF-UPDATING: if the release mechanism changes (trigger, versioning, auth, the pipeline jobs), update this skill AND `.github/workflows/release.yml` together.

Run the Guardrails agent team against the current state of the repo and produce a short, honest status + readiness report with a slug-keyed findings index. Use at the start of a work session, after a burst of multi-session work, or before deciding what to build next. The headline is the Reality Gate — three booleans from evidence, never from plans. Reports land in .claude/tasks/.