This project has a knowledge graph at graphify-out/ with god nodes, community structure, and cross-file relationships.
When the user types /graphify, use the installed graphify skill or instructions before doing anything else.
Rules:
- For codebase questions, first run
graphify query "<question>"when graphify-out/graph.json exists. Usegraphify path "<A>" "<B>"for relationships andgraphify explain "<concept>"for focused concepts. These return a scoped subgraph, usually much smaller than GRAPH_REPORT.md or raw grep output. - Dirty graphify-out/ files are expected after hooks or incremental updates; dirty graph files are not a reason to skip graphify. Only skip graphify if the task is about stale or incorrect graph output, or the user explicitly says not to use it.
- If graphify-out/wiki/index.md exists, use it for broad navigation instead of raw source browsing.
- Read graphify-out/GRAPH_REPORT.md only for broad architecture review or when query/path/explain do not surface enough context.
- After modifying code, run
graphify update .to keep the graph current (AST-only, no API cost).
When creating, revising, or reviewing a product/engineering specification, SDD, or implementation RFC:
- Read
.agents/skills/product-specification/SKILL.mdin full before drafting. - Apply the canonical quality standard in
specs/README.md. - Start new specifications from
specs/_template.md, adapting sections to the risk and scope instead of deleting a concern silently. - Treat GitHub issues, pull requests, comments, checks, and Job Summaries as product UI whenever users or maintainers interact with them.
- Include concrete flows, diagrams, representative UI/content examples, a numeric test budget, documentation work, configuration boundaries, and executable acceptance criteria whenever applicable.
- Consult
specs/catalog.jsonand the relevant catalogued SDD before changing a product capability. Update the SDD, catalog evidence, tests, and user documentation together when the public or architectural contract changes. - Run
pnpm run validate:specificationsfor every specification or catalog change. Regeneratespecs/CATALOG.mdwithpnpm run generate:specificationsafter editing catalog metadata.
Before repository work, use the copilot-repository-workflow skill and read .copilot/AGENT_GUIDE.md. Managed remote branches are owned by the GitHub Action.