What problem does it solve?
When planning a new feature or fix in dotCMS, engineers risk violating existing architectural decisions because ADRs live in a separate private repository. This Skill surfaces the relevant Architecture Decision Records before planning begins, so existing decisions are treated as binding input rather than discovered after the fact.
Core Features & Use Cases
- Keyword-based ADR lookup: Derives search keywords from the current feature spec (subsystem, technologies, data stores) or accepts them as arguments, then queries the dotCMS/platform-adrs repository via the gh CLI.
- Status-aware summarization: Reads matching ADR bodies and distinguishes accepted ADRs (binding) from proposed ones (directional), flagging likely conflicts that must be resolved in the plan.
- Read-only by design: Never creates, edits, or commits ADRs; new decisions are only recorded as proposals in the plan's Proposed ADRs section.
- Use Case: Before running /speckit-plan on a feature touching Elasticsearch indexing, invoke this Skill to pull all search-related ADRs and fold them into the plan's ADR Alignment gate.
Quick Start
Run the speckit-adr-context skill with keywords like "search elasticsearch" to list the ADRs relevant to your current feature before planning.