191f9f4f2a
Tighten root/core control flow, add dedicated post-mortem, web, and context-hygiene capabilities, and reduce instruction drift through clearer ownership, conflict-priority handling, and README/docs workflow alignment. This makes long-session AI behavior more deterministic while keeping the instruction system compact and maintainable.
44 lines
2.1 KiB
Markdown
44 lines
2.1 KiB
Markdown
---
|
|
name: analysis
|
|
description: Deep analysis, comparison of options, or scratchpad for technical results. Acts as the informal precursor to permanent documentation.
|
|
category: workflow
|
|
impact: high
|
|
---
|
|
|
|
# Analysis Instructions
|
|
|
|
Analysis documents are **Decision Support Tools** and **Technical Drafts**. They serve as a sandbox for the AI to explore options or store complex results before they are solidified into documentation. They live in `tmp/` which is gitignored.
|
|
|
|
## Triggering Criteria
|
|
1. **Complexity:** More than two viable technical paths exist with different trade-offs.
|
|
2. **Context Relief:** The comparison table or logic exceeds 50 lines, threatening chat context readability.
|
|
3. **Explicit Request:** The user asks for a formal analysis or "comparison doc".
|
|
|
|
## Where to write
|
|
|
|
```
|
|
tmp/<TOPIC>/<title>.md
|
|
```
|
|
`TOPIC` is a short slug describing the subject area. `<title>.md` describes what the document contains. Use lowercase and hyphens.
|
|
|
|
**CRITICAL RULE:** Do NOT create analysis files or any temporary files in the project root. Always use the `tmp/<topic>/` folder structure.
|
|
|
|
## Scope
|
|
|
|
Analysis is strictly scoped to the question asked. Do not expand into adjacent decisions unless the user asks. The purpose is to inform a decision, not to redesign the system.
|
|
|
|
## Diamond Quality Standards (AI Freedom & Utility)
|
|
While the AI has "freer hands" in the structure of an analysis, the output must remain high-utility:
|
|
- **No Fluff:** Skip LLM politeness and focus on data.
|
|
- **Visuals:** Use comparison tables over long paragraphs.
|
|
- **Directness:** Recommendations must be justified but blunt.
|
|
- **Pre-Documentation:** Structure data so it is easy to transform into formal `docs/` later.
|
|
|
|
Structure to use when relevant:
|
|
- **Context** — Max 3 sentences describing the problem. Brief description of the problem/goal.
|
|
- **Comparison Table** — Side-by-side view of viable paths.
|
|
- **Trade-offs** — Critical Pros/Cons only.
|
|
|
|
## What analysis is not
|
|
Analysis is a disposable artifact. Once a decision is made, the final result is recorded in `docs/architecture.md` (if relevant), and the analysis file is ignored.
|