Servant-Software-LLC

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/.

Run the SqlBuildingBlocks five-agent assessment team against the current GitHub issue backlog and generate a unified status + readiness report with a lightweight local findings index. Use at the start of a work session to get the current readiness picture, or after filing new issues to reassess sequencing and risks. The GitHub issues are the single source of truth for finding descriptions and rationale. The local findings index stores only execution metadata: filesExpected, dependsOn, status, wave tracking, route — for use by `/execute-tasks`.

Developer-specific knowledge for working in the SqlBuildingBlocks codebase. Use when implementing features, fixing bugs, adding grammar rules, extending logical entities, writing tests, or navigating the project structure. Covers: solution layout, Irony grammar patterns, NonTerminal hierarchy, logical entity classes, query engine, visitor pattern, grammar-specific dialects, testing patterns, and practical workflows. SELF-UPDATING: When your work changes, advances, or extends SqlBuildingBlocks in ways that affect this knowledge (new NonTerminals, logical entities, grammar rules, query engine features, etc.), you MUST update this skill to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.

Architect's lens on SqlBuildingBlocks. Use when reasoning about system shape, layer boundaries, NonTerminal seams, dialect inheritance, query-engine layering, or the evolution of the architecture itself (not day-to-day coding). Load this when: - Proposing a new grammar dialect, NonTerminal seam, or query-engine extension - Evaluating whether a change respects layer boundaries (Core vs Grammars), Create() dispatch, or consumer NuGet contracts - Reviewing designs for grammar ambiguity, dialect parity, or downstream-consumer impact - Planning the PostgreSQL or SQL Server grammar build-out Do NOT load this skill for "where is file X / how do I add a NonTerminal" -- that is `sqlbuildingblocks-dev-knowledge`. Do NOT load this for product/consumer/maturity questions -- that is `sqlbuildingblocks-domain-knowledge`. SELF-UPDATING: When your work changes, advances, or extends the architecture (new layers, new grammar dialects, query-engine layer changes, resolved architectural gaps), update this skill in the same de

QA-specific knowledge for testing the SqlBuildingBlocks library. Use when planning test strategies, evaluating coverage gaps, writing acceptance criteria, investigating regressions, designing test matrices, or assessing release readiness. Covers: test inventory, coverage analysis, risk-based testing priorities, SQL grammar test matrix, parser correctness verification, query engine testing, edge case catalog, known fragile areas, and test environment setup. SELF-UPDATING: When your work changes, advances, or extends testing in SqlBuildingBlocks (new test projects, coverage changes, discovered edge cases, resolved defects, etc.), you MUST update this skill to reflect the new state before completing your task.

SqlBuildingBlocks product knowledge for Servant Software LLC agents. Use when working on anything related to SqlBuildingBlocks: - Product strategy, roadmap, or feature planning - Technical architecture discussions or documentation - SQL grammar design, dialect support, or parser questions - Integration with consuming projects (FileBased.DataProviders, MockDB) - Understanding current maturity, gaps, or productization needs Provides: product purpose, architecture overview, asset inventory, maturity assessment, and productization gaps. SELF-UPDATING: When your work changes, advances, or extends SqlBuildingBlocks in ways that affect this knowledge (new grammars, features, assets, maturity changes, resolved gaps, etc.), you MUST update this skill and its reference files to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.

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

Charter product knowledge for all agents working in this repo. Use when working on anything related to Charter: - The deliverable model: block-structured markdown, the block catalog, the question block - The comment-in-place review loop, anchors, and the anchor→markdown source-map - The author → review → handoff workflow and the Guardrails handoff contract - The settled format decision (markdown+directives) and why not the alternatives - Load-bearing invariants, where-truth-lives, and roadmap/status Provides: the mental model, review-loop semantics, the format rationale, and pointers to the single-source-of-truth documents. SELF-UPDATING: When your work changes the deliverable model, block catalog, review-loop semantics, format decision, handoff contract, or roadmap, you MUST update the affected section(s) here before completing your task.

Use when you must turn a task into a reviewable plan with Charter — author a block-structured .charter.md, render/serve it for a human to annotate in the browser, then hand off plain CommonMark to Guardrails. Covers the author → review → handoff workflow and the block catalog.

The normative Charter `.charter.md` block catalog and `:::question` open/resolved schema — the single format source of truth cited by the charter authoring skill (to WRITE blocks) and by Guardrails plan-breakdown (to INTERPRET them). Use whenever you must read, write, or interpret Charter `:::` directive blocks.

QA-specific knowledge for testing the FileBased.DataProviders library. Use when planning test strategies, evaluating coverage gaps, writing acceptance criteria, investigating regressions, designing test matrices, or assessing release readiness. Covers: test inventory, coverage analysis, risk-based testing priorities, edge case catalog, cross-format test matrix, integration testing concerns, known fragile areas, and test environment setup. SELF-UPDATING: When your work changes, advances, or extends testing in FileBased.DataProviders (new test projects, coverage changes, discovered edge cases, resolved defects, etc.), you MUST update this skill to reflect the new state before completing your task.

Developer-specific knowledge for working in the FileBased.DataProviders codebase. Use when implementing features, fixing bugs, adding format providers, writing tests, or navigating the project structure. Covers: solution layout, ADO.NET provider patterns, EF Core integration, data source abstraction, file I/O pipeline, connection strings, testing patterns, and practical workflows. SELF-UPDATING: When your work changes, advances, or extends FileBased.DataProviders in ways that affect this knowledge (new projects, providers, DI registrations, testing patterns, build steps, etc.), you MUST update this skill to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.

FileBased.DataProviders product knowledge for Servant Software LLC agents. Use when working on anything related to FileBased.DataProviders: - Product strategy, roadmap, or feature planning - Technical architecture discussions or documentation - Market analysis, competitive positioning, or customer interviews - Developer experience, onboarding, or API questions - Understanding current maturity, gaps, or productization needs - Integration with MockDB, SettingsOnADO, or other consuming projects Provides: product purpose, architecture overview, asset inventory, maturity assessment, and productization gaps. SELF-UPDATING: When your work changes, advances, or extends FileBased.DataProviders in ways that affect this knowledge (new providers, features, assets, maturity changes, resolved gaps, etc.), you MUST update this skill and its reference files to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unc

Developer-specific knowledge for working in the SettingsOnADO codebase. Use when implementing features, fixing bugs, adding encryption providers, writing tests, or navigating the project structure. Covers: solution layout, single-row-per-table pattern, schema evolution, encryption, pub/sub, caching decorator, JSON specialization, testing patterns, and practical workflows. SELF-UPDATING: When your work changes, advances, or extends SettingsOnADO in ways that affect this knowledge (new projects, interfaces, patterns, build steps, etc.), you MUST update this skill to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.

SettingsOnADO product knowledge for Servant Software LLC agents. Use when working on anything related to SettingsOnADO: - Product strategy, roadmap, or feature planning - Technical architecture discussions or documentation - Developer experience, onboarding, or API questions - Integration with consuming projects (MockDB, etc.) - Understanding current maturity, gaps, or productization needs Provides: product purpose, architecture overview, asset inventory, maturity assessment, and productization gaps. SELF-UPDATING: When your work changes, advances, or extends SettingsOnADO in ways that affect this knowledge (new features, assets, maturity changes, resolved gaps, etc.), you MUST update this skill and its reference files to reflect the new state before completing your task. This keeps the knowledge accurate for future agents. Update the specific section(s) affected -- do not rewrite unchanged content.

QA-specific knowledge for testing the SettingsOnADO library. Use when planning test strategies, evaluating coverage gaps, writing acceptance criteria, investigating regressions, designing test matrices, or assessing release readiness. Covers: test inventory, coverage analysis, risk-based testing priorities, edge case catalog, schema evolution testing, encryption verification, pub/sub reliability, and test environment setup. SELF-UPDATING: When your work changes, advances, or extends testing in SettingsOnADO (new test projects, coverage changes, discovered edge cases, resolved defects, etc.), you MUST update this skill to reflect the new state before completing your task.