interrogate-with-docs

Stress-test proposals against a domain glossary and record decisions as ADRs.

4|Updated Jun 19, 2026
One-click install
npx skills add https://github.com/douglance/sdlc-plugin --skill interrogate-with-docs-douglance
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: interrogate-with-docs
Source: https://github.com/douglance/sdlc-plugin/tree/main/.rulesync/skills/interrogate-with-docs
Command: npx skills add https://github.com/douglance/sdlc-plugin --skill interrogate-with-docs-douglance

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Proposals often use vague or conflicting terminology and leave architectural decisions undocumented, causing confusion months later. This Skill stress-tests a plan against the project's documented domain model while updating the glossary and decision records inline as the discussion progresses. ## Core Features & Use Cases - Relentless interrogation: Asks one question at a time with a recommended answer, exploring the codebase instead of asking when possible. - Domain glossary enforcement: Challenges terms that conflict with CONTEXT.md, sharpens fuzzy language into canonical terms, and updates the glossary inline as terms are resolved. - Selective ADR creation: Offers an Architecture Decision Record only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While planning a partial order cancellation feature, the Skill notices the code cancels entire Orders, surfaces the contradiction, resolves the term 'cancellation' into CONTEXT.md, and records the chosen approach as ADR 0003. ## Quick Start Ask the assistant to interrogate your feature proposal against the project's domain model and update CONTEXT.md and ADRs as decisions are made.

Frequently Asked Questions about interrogate-with-docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I stress-test a feature proposal against my domain model?▼

Run an interrogation session that asks one question at a time with a recommended answer, exploring the codebase instead of asking when possible. Each answer is challenged against the existing CONTEXT.md glossary and contradictions with the code are surfaced immediately.

What is a CONTEXT.md file and when should I create one?▼

CONTEXT.md is a project glossary defining canonical domain terms with words to avoid, kept free of implementation details. Create it lazily at the repo root when the first term is resolved, or use CONTEXT-MAP.md when multiple bounded contexts exist.

When should I write an Architecture Decision Record?▼

Write an ADR only when all three conditions hold: the decision is hard to reverse, surprising without context, and the result of a real trade-off between genuine alternatives. If any condition is missing, skip the ADR to avoid documentation noise.

How do I handle multiple bounded contexts in one repository?▼

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships with other contexts. Each context then keeps its own CONTEXT.md glossary and context-specific docs/adr directory for local decisions.

What are the limitations of glossary-driven interrogation?▼

The approach depends on the user engaging with questions and confirming terminology, so it cannot enforce consistency autonomously. It also deliberately excludes implementation details from CONTEXT.md, so technical specifications must live elsewhere.