Skip to content

Latest commit

 

History

History
65 lines (50 loc) · 4.48 KB

AGENTS.md

File metadata and controls

65 lines (50 loc) · 4.48 KB

Architecture Context

This project uses the SDD plugin for architecture governance.

  • Architecture Decision Records are in docs/adrs/
  • Specifications are in docs/openspec/specs/
  • Product Requirements Documents are in docs/prds/

qmd Dependency

Starting with SDD plugin v5.0.0, qmd is a hard dependency — /sdd:init enforces qmd presence at setup, and every qmd-aware consumer skill (/sdd:prime, /sdd:check, /sdd:audit, /sdd:discover, /sdd:adr, /sdd:spec, /sdd:plan, /sdd:work, /sdd:review) MAY assume qmd is installed and MUST NOT include conditional fallback paths. If a skill needs to handle "qmd installed but this repo not yet indexed", it routes to /sdd:index rather than silently degrading. This invariant lets every skill be designed for hybrid retrieval rather than around its absence.

SDD Skills

Skill Purpose
/sdd:prd Create a Product Requirements Document (PRD) for a client-facing capability
/sdd:adr Create a new Architecture Decision Record (ADR) using MADR format
/sdd:spec Create a specification with requirements, scenarios, and design rationale
/sdd:list List all PRDs, architecture decisions, and specs with their status
/sdd:status Change the status of a PRD, ADR, or spec (e.g., proposed to accepted, draft to…
/sdd:docs Generate a documentation site from your ADRs and specs
/sdd:init Set up CLAUDE.md with SDD plugin references for architecture-aware sessions
/sdd:prime Load ADR and spec context into the session for architecture-aware responses
/sdd:check Quick-check code against ADRs and specs for drift
/sdd:audit Comprehensive audit of design artifact alignment across the project
/sdd:discover Discover implicit architectural decisions and spec-worthy subsystems in an…
/sdd:plan Break an existing spec into trackable issues in your issue tracker
/sdd:organize Retroactively group existing issues into tracker-native projects
/sdd:enrich Retroactively add branch naming and PR convention sections to existing issue…
/sdd:triage Triage and size tracker issues — give every open issue a verdict (OK, STALE,…
/sdd:work Pick up tracker issues and implement them in parallel using git worktrees
/sdd:review Review and merge PRs produced by the work skill using reviewer-responder agent…
/sdd:graph Build and query the SDD artifact graph
/sdd:index Index a repository's ADRs, OpenSpec specs, and source code into qmd collections…
/sdd:report-friction File a feedback issue against the SDD plugin (joestump/claude-plugin-sdd) when…
/sdd:respond Respond to review feedback on a PR — gather review comments, requested changes,…
/sdd:search Unified semantic exploration skill combining qmd hybrid retrieval with cgg call…

Run /sdd:prime [topic] at the start of a session to load relevant ADRs and specs into context.

Governing Comments

When implementing code governed by ADRs or specs, leave comments referencing the governing artifacts:

// Governing: ADR-0001 (chose JWT over sessions), SPEC-0003 REQ "Token Validation"

These comments help future sessions (and /sdd:check) trace implementation back to decisions.

Workflow

  1. Capture intent (optional, client-facing capabilities only): /sdd:prd — interrogate the request grill-first and produce a client-ready PRD for sign-off. Pure engineering decisions skip this step, and the absence of a PRD is never a finding
  2. Decide: /sdd:adr — record the architectural decision
  3. Specify: /sdd:spec — formalize requirements with RFC 2119 language
  4. Plan: /sdd:plan — break the spec into trackable issues in your tracker
  5. Enrich: /sdd:organize and /sdd:enrich — add projects and branch conventions
  6. Build: /sdd:work — pick up issues and implement in parallel using git worktrees
  7. Review: /sdd:review — review and merge PRs with spec-aware code review
  8. Validate: /sdd:check and /sdd:audit to catch drift

Session Coordination

When orchestrating multiple SDD plugin skills in a single session (e.g., running /sdd:work on several issues), use TeamCreate to coordinate agents. Do not spawn ad-hoc background agents for work that requires coordination — SendMessage only works within a Team, and isolated agents cannot see sibling file claims or type creations.