agentspec

Intelligent agent routing -- automatically matches tasks to the best specialist agent based on file patterns, intent keywords, and domain context. Loaded every session to give Claude explicit routing rules for all 58 AgentSpec agents.

Decides where new logic lives in the component model — agent, skill, command, KB, or template — and how to keep components in their layer, routing each decision to the right authoring resource and running the fat-to-thin refactor when a component has outgrown its layer. Loaded by the authoring flows (create-skill, create-agent, kb-build, create-kb) as their layer-decision gate. Use for "should this be an agent or a skill", "where does this logic go", adding a new component, "this agent is too big", or restructuring/refactoring an agent into skills. Do not use to author the chosen component itself — that is create-skill, create-agent, or /create-kb.

Data engineering expertise for pipelines, schemas, data quality, SQL, lakehouse, and streaming. Use PROACTIVELY when the user discusses data pipelines, ETL/ELT, schema design, dimensional modeling, data quality checks, SQL optimization, dbt models, Spark jobs, Airflow DAGs, streaming pipelines, lakehouse architecture, or data contracts.

Create Excalidraw diagram JSON files that make visual arguments. Use when the user wants to visualize workflows, architectures, or concepts.

Drafts an Architecture Decision Record (ADR) for the current repository: searches existing GitHub issues for duplicates first, applies a worthiness gate, then drafts from the context/decision/alternatives/consequences template with the standard status lifecycle, ready for publication as a GitHub issue. Use when the user asks to "create an ADR", "draft an ADR", "new ADR", "document an architecture decision", or to formalize an architecturally significant, hard-to-reverse technical choice. Do not use for routine feature or bug tracking — use `github-cr-issue`; publishing a drafted ADR to GitHub is `github-post-issue`.

Drafts the body of a well-formed, self-contained GitHub issue for the current repository from a per-type template — feature, component, task, bug, or spike — searching existing issues for duplicates before any drafting, and saving the result as an ephemeral draft ready for review and publication. Use when the user wants to create, draft, or write an issue, or asks for a feature, component, task, bug, or spike issue, or wants to turn an idea, defect report, or investigation into a tracked GitHub issue. For epic-scale initiatives it drafts a parent issue plus child issues joined by native GitHub relationships instead of an epic document. Do not use for architecture decisions — use `github-cr-adr`; to publish a draft to GitHub use `github-post-issue`.

Publishes a drafted issue or ADR to the current repository's GitHub board via gh, with guardrails, and curates the board safely. Runs a verdict-gated pre-flight before any write: duplicate search across open and closed issues, a self-containment lint, template conformance, and label validation against the live repo (human-in-the-loop for missing labels, never auto-created). Applies native parent/sub-issue relationships, assigns owners, closes (never deletes) superseded issues with a pointer comment, and deletes the local draft once the issue URL is returned. Use when the user wants to post or publish a drafted issue or ADR, apply labels, set parent/sub-issue relationships, assign an owner, or close/curate issues on the board. Do not use to draft content — use `github-cr-issue` or `github-cr-adr` first.

Build a high-assurance, source-verified knowledge base where every claim is source-cited and adversarially fact-checked before it lands. Grounds in the repo's KB house style, plans the domain, researches with an independent refutation pass, builds with kb-architect subagents, runs an independent fact-check gate, and registers the domain additively in the KB index. Use when the user wants a validated or foundational KB where every claim must be source-cited and fact-checked — "build a KB", "create a knowledge base", "validated KB", "high-assurance KB" — or when encoding researched knowledge into a reusable domain many agents will trust. This is the high-assurance mode behind the create-kb command's --validated flag; for a quick single-pass KB, run create-kb without the flag.

Runs Phase 0 of the SDD workflow: collaborative exploration that turns a raw idea into a validated approach and a BRAINSTORM document ready for requirements capture. Owns the brainstorm methodology: KB-first grounding with confidence-scored recommendations, one-question-at-a-time discovery, sample collection for LLM grounding, comparison of 2-3 approaches with trade-offs, YAGNI scope pruning, incremental validation, and the quality gate that must pass before the document is written and /define is suggested. Use when the user wants to brainstorm a feature, explore an idea, compare approaches ("should I use X or Y?"), clarify a vague request ("I want to build..."), or run Phase 0 explicitly. Not for requirements capture: when requirements are already clear and validated, or a BRAINSTORM document already exists, use sdd-define (Phase 1) instead.

Execution methodology for SDD Phase 3 (Build): turn a completed DESIGN into working, verified code. Covers KB-first knowledge resolution, task extraction from the file manifest, dependency ordering, specialist agent delegation (including the data engineering delegation map), per-file and full-run verification, recording autonomous decisions in the BUILD_REPORT, upstream status transitions, and the handoff to Phase 4. Use when asked to "execute the build", "implement from the design", or run "Phase 3" on a DESIGN_{FEATURE}.md. Not for creating the architecture itself — that is sdd-design — and not for archiving a finished feature — that is sdd-ship.

Phase 1 of the SDD workflow: capture and validate requirements in one pass. Owns the full Define methodology — classify the input (BRAINSTORM document, meeting notes, email thread, conversation, or direct request), extract entities (problem, users, MoSCoW goals, success criteria, acceptance tests, constraints, out of scope, assumptions), gather technical and data engineering context, calculate the clarity score against the 12/15 gate, fill gaps with targeted questions, and generate the DEFINE document from the shared template with correct status transitions. Use when the user wants to capture requirements, define the feature, structure project scope, or compute a clarity score — "capture requirements", "define the feature", "clarity score", "Phase 1", /define. Do not use for open-ended exploration of ideas and approaches (that is sdd-brainstorm, Phase 0) or for architecture and technical specification (that is sdd-design, Phase 2).

Create the architecture and technical specification for a defined feature — Phase 2 of the SDD workflow. Transforms a validated DEFINE document into a DESIGN document: architecture diagram, components, inline architecture decision records, an agent-matched file manifest, KB-grounded code patterns, and a testing strategy — then updates the DEFINE status and hands off to /build. Use when requirements are captured and technical design is needed — "design the architecture", "technical design", "Phase 2", or /design pointed at a DEFINE_*.md file. Not for capturing or clarifying requirements (that is sdd-define, Phase 1) and not for implementing code (that is sdd-build, Phase 3).

Update an existing SDD phase document (BRAINSTORM/DEFINE/DESIGN) mid-stream with full cascade awareness: classify the change (additive, modifying, removing, architectural), apply it with a version bump and change note, walk the cascade rules for downstream impact, and confirm with the user before applying any cascading edits. Owns the SDD change-management methodology: cascade rules, version-tracking and status-field obligations, and the iterate-vs-restart thresholds. Use when the user wants to update the requirements or design mid-stream — "requirements changed", "the design needs to change", "cascade the change" — or any existing phase document must change after downstream work has started. Do not use for a brand-new feature or a fundamentally different problem: a different problem, different users, or a change beyond roughly half the document calls for sdd-brainstorm/sdd-define instead of an iterate.

Archive a completed feature and close the SDD cycle (Phase 4): verify the build is truly complete, archive every phase artifact, capture lessons learned, update all phase documents to Shipped, and clean the working folders. Carries the full ship methodology — verification order, ship readiness matrix, the concrete archive procedure, status transitions, lessons-learned categories, quality gate, and the end-of-cycle handoff. Executed by ship-agent and the /ship command; loadable directly when closing a feature by hand. Use when completed work needs closing: "ship the feature", "archive the completed feature", "Phase 4", "lessons learned", "finalize the feature". Not for implementation work — writing code, completing tasks, or fixing failing tests is Phase 3; use sdd-build. Shipping starts only after the build report shows 100% completion.

Spec-Driven Development workflow guidance for structured feature development. Use PROACTIVELY when the user discusses building features, planning implementations, capturing requirements, designing architectures, or shipping completed work. Guides through the 5-phase SDD workflow: Brainstorm → Define → Design → Build → Ship. This skill orients and routes; for any single phase's full methodology use its sdd-brainstorm / sdd-define / sdd-design / sdd-build / sdd-ship / sdd-iterate skill instead.

Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, diff review, plan review, project recap, comparison table, or any visual explanation of technical concepts. Also use proactively when you are about to render a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead.