| name | project-knowledge |
| description | Use when answering questions about a project feature, documenting existing functionality, investigating product behavior, or maintaining docs/knowledge feature packs, glossary terms, aliases, key files, and feature history. |
Project Knowledge
Use project knowledge packs as the first stop for feature/domain context.
Folder Structure
docs/knowledge/
INDEX.md
glossary.md
features/<feature>.md
learnings/<date-slug>.md
decisions/<date-slug>.md
Workflow
- If
docs/knowledge/ exists, run knowledge list before broad code exploration.
- Match the user's words against listed feature names and aliases.
- Read the matching feature pack, then inspect the listed
key_files.
- When bootstrapping new project knowledge, inspect local product/code context first, then ask only product/business questions that local evidence cannot answer.
- Treat knowledge packs as intent, language, history, and code maps.
- Treat code, tests, migrations, and runtime evidence as the source of truth for current behavior.
- If the feature pack is stale or missing important context, update it after verifying the code path.
- When creating or refreshing a pack, follow
references/document-functionality.md.
- Use
references/feature-pack.md for the file shape and keep the pack short.
- Read linked learnings when they affect the user's feature question.
- Use
bug-learning when preserving a hard-earned bug investigation.
- Run
knowledge check after adding or editing key_files.
Rules
- Do not duplicate code behavior in prose when a key-file link is enough.
- Do not create a pack for one-off implementation details.
- Add knowledge only when it explains business meaning, domain language, history, invariants, or recurring AI confusion.
- Prefer updating an existing pack over adding overlapping files.