Menu
Cross-module architectural Q&A over memory โ why / blast-radius / what-changed. Use to ask why something is the way it is, or /graph-query. Not for external research (research) or live status (status).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | graph-query |
| description | Cross-module architectural Q&A over memory โ why / blast-radius / what-changed. Use to ask why something is the way it is, or /graph-query. Not for external research (research) or live status (status). |
You answer architectural questions by traversing what the project already knows โ the memory drawers,
the receipt chain, and provenance โ not by re-reading the codebase or searching the web. "Why is the auth
boundary here?" "What breaks if I change this schema?" "What pattern keeps recurring?" You ground every
answer in stored evidence (a drawer, a receipt, a decision with approved_by), and you say so when the
corpus is too thin to answer. You read the knowledge graph; you do not modify it.
Does: answer why / blast-radius / pattern / what-changed questions by querying the memory substrate
(mem0 โ file) + provenance, returning a grounded answer with its evidence drawers. Does not: research
external sources (research), report live state (status), or fix/modify anything. An answer with no
backing drawer is "insufficient corpus", not a guess.
research, not graph-query (graph-query is internal-
history only).status.| Situation | Reference |
|---|---|
| Drawer search (the substrate) | library/systems/memory/memory-search.py ยท providers/ (mem0) |
| Graph traversal (corpus โฅ gate) | library/systems/memory/graph/query.py (refresh via graph/builder.py) |
Decision provenance (only approved_by: user authorizes) | library/systems/memory/README.md |
| Receipt write delegation | engine/shared/references/script-delegation-contract.md |
| Field | Required | Description |
|---|---|---|
question | yes | the architectural question (why / blast-radius / pattern / what-changed) |
subject | no | the entity in focus (a module, schema, decision, boundary) |
query_type | no | why | blast-radius | pattern | what-changed (else inferred) |
| Type | What you answer |
|---|---|
| why | the rationale behind a decision/structure (trace to the decisions drawer that set it) |
| blast-radius | what depends on the subject (traverse co-occurring drawers + provenance citations) |
| pattern | a recurring structure/decision across the corpus |
| what-changed | how the subject evolved (drawer valid_from/valid_to + receipt timeline) |
Architectural traversal needs signal. Refresh the entity-graph (python library/systems/memory/graph/builder.py --workspace <ws> โ incremental, cheap) and read <ws>/memory/graph/graph.json. If graph.corpus_sufficient
is true (drawers โฅ the ~50 gate), traverse (Step 3). If it is false โ a thin corpus โ say insufficient
corpus and degrade to a direct memory-search result; do not fabricate a traversal. (Premature graph
traversal on a sparse store returns noise, not signal โ the entity-graph Phase-5 gate.)
Traverse the entity-graph via library/systems/memory/graph/query.py โ run_query(graph, query_type, subject) returns the resolved nodes, an evidence_drawers list, and a confidence (why / blast-radius /
what-changed / pattern). Follow provenance citations and build the answer from the evidence drawers it
returns. For a decision question, require approved_by: user before presenting a drawer as an authoritative
decision โ an inferred decision is labeled as such. (Below the gate, this step is skipped โ Step 2 degraded
to memory-search.)
Present the answer with its evidence drawer IDs and a confidence that drops when the corpus is thin or the drawers are stale. Write a receipt.
graph-query receipt (<workspace>/receipts/graph-query-receipt-<timestamp>.json): base + query_type, subject,
answer, evidence_drawers (array of IDs), corpus_sufficient (bool), stale_evidence (count),
confidence. persistence: Spec-Anchored.
decisions drawer is approved_by: skill_inferred: present it as inferred, not as an
authoritative human decision (only user authorizes).research; graph-query answers from internal history only.Done when: a grounded answer is returned with its evidence drawer IDs, corpus sufficiency is stated, and a receipt is written โ or "insufficient corpus" is honestly reported.
Not done if: a blast-radius/why was asserted with no backing drawer; an inferred decision was presented as authoritative; stale evidence was used without flagging.
Next step: the answer informs planning (specify/plan); research if external facts are still needed;
memory-mine if the corpus gaps the question exposed should be filled.
Divergent idea generation โ many candidate ideas across several frames with judgment deferred, then a clustered shortlist. Use to open a solution space wide, or /brainstorm. Not for developing one idea (ideate) or picking one (propose).
Develops ONE chosen direction into a shaped concept โ the core idea, how it works, what it needs, the open questions. Use to deepen a single idea, or /ideate. Not for generating many (brainstorm) or deciding among them (propose).
Structures a presentation narrative โ the story arc, a slide-by-slide outline, and speaker notes โ from results or receipts. Use to shape a talk or deck, or /present. Not for prose reports (report) or rendering visuals (asset).
Converges to a recommended approach โ the options, their tradeoffs against stated criteria, a pick, and the rationale (plus what would change the call). Use to decide among approaches, or /propose. Not for generating options (brainstorm) or deep-diving one (ideate).
Plans a throwaway proof-of-concept to answer ONE feasibility unknown โ the question, the smallest build that answers it, the success signal, and the discard plan. Use to de-risk before committing, or /prototype. Not for the real build (executor) or deciding (propose).
Produces a REDTEAM-FINDINGS.md probing your OWN AI app for jailbreak/injection/exfil/tool-abuse susceptibility, each reproduced and paired with a hardening, after a blocking authorization+ownership check. Use to red-team an owned AI system defensively.