124 lines
3.8 KiB
Markdown
124 lines
3.8 KiB
Markdown
|
.kiro/steering/memoria.md
|
||
|
|
|
||
|
|
```markdown
|
||
|
|
---
|
||
|
|
inclusion: always
|
||
|
|
---
|
||
|
|
|
||
|
|
You have access to a long-term memory and codebase intelligence system via the In-Memoria MCP server.
|
||
|
|
|
||
|
|
## Goals
|
||
|
|
- Reduce session amnesia by reusing durable project knowledge.
|
||
|
|
- Prefer retrieval before guessing.
|
||
|
|
- Keep memory high-signal, accurate, and project-scoped.
|
||
|
|
- Treat long-term memory as an engineering asset, not chat history.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Global Ordering Rule (Hard Constraint)
|
||
|
|
|
||
|
|
For any non-trivial task:
|
||
|
|
- Do NOT perform reasoning, design, or code generation
|
||
|
|
- UNTIL readiness and retrieval steps (0 and 1) have been evaluated.
|
||
|
|
|
||
|
|
Skipping steps is allowed only if explicitly justified.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Tool Policy (What to use, when)
|
||
|
|
|
||
|
|
### 0) Readiness check (mandatory first step)
|
||
|
|
Before working on any non-trivial task:
|
||
|
|
- Use `get_learning_status` to determine whether codebase intelligence exists and is fresh.
|
||
|
|
- If no intelligence exists or it is stale, use `auto_learn_if_needed`.
|
||
|
|
- If this is a new project or first-time setup, use `quick_setup`.
|
||
|
|
|
||
|
|
Do NOT proceed until readiness is confirmed.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 1) Retrieval before reasoning (default behavior)
|
||
|
|
When continuing prior work, implementing a feature, or answering
|
||
|
|
“how does this project do X”:
|
||
|
|
|
||
|
|
- Prefer `get_semantic_insights` and/or `get_pattern_recommendations`.
|
||
|
|
- Use `predict_coding_approach` when choosing an implementation strategy.
|
||
|
|
- Use `get_developer_profile` only to align with established conventions or preferences.
|
||
|
|
|
||
|
|
Do NOT assume solutions when relevant memory may exist.
|
||
|
|
|
||
|
|
#### Do NOT use intelligence tools when:
|
||
|
|
- The task is a small, local refactor.
|
||
|
|
- The change is purely mechanical or well-scoped.
|
||
|
|
- The exact behavior is already verified and understood.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 2) Codebase grounding (only when evidence is required)
|
||
|
|
Use codebase analysis tools only when answers require direct confirmation
|
||
|
|
from the repository:
|
||
|
|
|
||
|
|
- `get_project_structure` for navigation and boundaries.
|
||
|
|
- `search_codebase` to find relevant usages.
|
||
|
|
- `get_file_content` to confirm exact implementation details.
|
||
|
|
- `analyze_codebase` for broad architectural or pattern discovery.
|
||
|
|
- `generate_documentation` only when explicitly asked to produce repo-based docs.
|
||
|
|
|
||
|
|
Avoid broad scans unless necessary.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 3) Writing memory (high-signal only)
|
||
|
|
|
||
|
|
Persist only durable, reusable information:
|
||
|
|
- Finalized architectural or design decisions.
|
||
|
|
- Stable conventions, constraints, and workflows.
|
||
|
|
- Repeated corrections or clearly established preferences.
|
||
|
|
|
||
|
|
#### How to write:
|
||
|
|
- Prefer `contribute_insights` for explicit, structured, durable knowledge.
|
||
|
|
- Use `auto_learn_if_needed` only when learning state is uncertain.
|
||
|
|
|
||
|
|
#### Never write memory when:
|
||
|
|
- The task is exploratory or brainstorming.
|
||
|
|
- Multiple alternatives are still under consideration.
|
||
|
|
- Decisions have not been confirmed as final.
|
||
|
|
- Information is transient, speculative, or session-specific.
|
||
|
|
|
||
|
|
#### If uncertain whether something should be persisted:
|
||
|
|
- Summarize the candidate insight first.
|
||
|
|
- Ask for explicit confirmation before writing memory.
|
||
|
|
|
||
|
|
#### Do NOT store:
|
||
|
|
- Raw logs or verbose transcripts.
|
||
|
|
- Secrets, credentials, tokens, or personal data.
|
||
|
|
- Transient chat, debugging noise, or speculative ideas.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 4) Operational and health checks
|
||
|
|
When tool calls are slow, failing, or results appear stale or inconsistent:
|
||
|
|
- Use `get_system_status`.
|
||
|
|
- Use `get_intelligence_metrics`.
|
||
|
|
- Use `get_performance_status`.
|
||
|
|
|
||
|
|
Do not retry blindly without checking system state.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Safety and Governance
|
||
|
|
|
||
|
|
- Do not read or analyze unrelated files.
|
||
|
|
- Ask for confirmation before large-scale analysis or broad file reads.
|
||
|
|
- Minimize scope and tool usage by default.
|
||
|
|
- Maintain strict project boundaries for all memory operations.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Guiding Principle
|
||
|
|
|
||
|
|
Long-term memory is a shared engineering resource.
|
||
|
|
Optimize for correctness, durability, and future reuse — not convenience.
|
||
|
|
|
||
|
|
|
||
|
|
```
|