Design Rationale Investigation
Establish what is known about a design decision and what remains inference.
Workflow
- Define the exact decision, time window, system boundary, and question the answer will inform.
- Inspect current code and tests to establish mechanics before investigating history.
- Prefer direct evidence: decision records, commit history, linked issues, review discussions, release notes, incident records, and named documentation.
- Search only authorized sources relevant to the named decision. Ask before reading private chat, broad activity history, or unrelated repositories.
- Build competing hypotheses and test each against dates, changes, constraints, rejected alternatives, and later corrections.
- Classify every conclusion as
Direct evidence, Strong inference, Weak hypothesis, Contradiction, or Unknown.
- Recheck the current system before recommending action because historical reasons may no longer apply.
Boundaries
- Do not treat commit order, code comments, or repeated claims as proof of intent by themselves.
- Do not enumerate every available tool, data source, or conversation by default.
- Do not spawn agents or access external systems without host and user authority.
- Do not rewrite history or implementation as part of the investigation.
Output
Return Current mechanics, Timeline, Evidence, Hypotheses, Contradictions, Confidence, Expired assumptions, and Decision implications.
1---2name: design-rationale-investigation3description: Investigate why code, architecture, or an operational design exists by comparing direct historical evidence, current behavior, and competing hypotheses. Use for design history and rationale questions; do not infer intent from code shape alone or search unrelated private sources.4license: MIT5---67# Design Rationale Investigation89Establish what is known about a design decision and what remains inference.1011## Workflow12131. Define the exact decision, time window, system boundary, and question the answer will inform.142. Inspect current code and tests to establish mechanics before investigating history.153. Prefer direct evidence: decision records, commit history, linked issues, review discussions, release notes, incident records, and named documentation.164. Search only authorized sources relevant to the named decision. Ask before reading private chat, broad activity history, or unrelated repositories.175. Build competing hypotheses and test each against dates, changes, constraints, rejected alternatives, and later corrections.186. Classify every conclusion as `Direct evidence`, `Strong inference`, `Weak hypothesis`, `Contradiction`, or `Unknown`.197. Recheck the current system before recommending action because historical reasons may no longer apply.2021## Boundaries2223- Do not treat commit order, code comments, or repeated claims as proof of intent by themselves.24- Do not enumerate every available tool, data source, or conversation by default.25- Do not spawn agents or access external systems without host and user authority.26- Do not rewrite history or implementation as part of the investigation.2728## Output2930Return `Current mechanics`, `Timeline`, `Evidence`, `Hypotheses`, `Contradictions`, `Confidence`, `Expired assumptions`, and `Decision implications`.
JovaniPink