メニュー
Stores and retrieves session-scoped context blobs in the KG so work survives across turns/agents. Use to persist or recall working context — "remember this for the session", "store/get context", "list session context".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | kg-context |
| skill_type | skill |
| description | Stores and retrieves session-scoped context blobs in the KG so work survives across turns/agents. Use to persist or recall working context — "remember this for the session", "store/get context", "list session context". |
| license | MIT |
| tags | ["graph-os","context","session"] |
| tier | core |
| metadata | {"author":"Genius","version":"0.1.0"} |
Condensed intent-surface note (Seam 8). Under the default intent surface (
MCP_TOOL_MODE=intent),graph_contextis held back from the default tool list (nothing removed — REST +_execute_toolstill reach it exactly as documented below). Two ways to use this skill unchanged: (1)load_tools(tools=["graph_context"])once per session (as below), then proceed exactly as documented; or (2) call theaskintent verb with the same natural-language request — the resolver routes tograph_contextfor you and returns the result plus a routing justification. SetMCP_TOOL_MODE=condensed/verbose/bothto expose the granular tools eagerly instead.
graph_context is a small session-anchored key/value store backed by ContextBlob nodes. Actions: put (store content under a session_id/key, optional ttl_s), get (by context_id), list (by session). Stored blobs are linked to a Session node for reliable id-anchored retrieval.
load_tools(tools=["graph_context"]), then graph_context(action="put", content="...", session_id="s1").POST /graph/context with {"action": "put", "content": "...", "session_id": "s1"}.graph_context(action="put", content="user prefers efficient mode", session_id="s1", key="prefs")
graph_context(action="list", session_id="s1")
Turns the manual "validate a fleet package/skill, run its tests, delegate a grounded task to it, hunt for known bug-classes, and feed findings back into the KG" process into a SELF-HOSTED, delegation-ready capability the local LLM runs against ANY target — a fleet agent under agent-packages/agents/*, the agent-utilities package itself, or a universal-skill / agent-utilities skill. Composes existing primitives (graph_orchestrate execute_agent, graph_write, graph_feedback, pytest via the tier4 pattern, deterministic structural/bug-class scans) rather than re-implementing them. Use when asked to "validate <target>", "test this agent/skill end to end", "bug-hunt the fleet", "run ecosystem validation", or to set up continuous automated fleet validation via the loop engine or the scheduler.
Evolve the agent-utilities repository by implementing the latest research concepts against it. Orchestrates research-scanner → kg-ingest → comparative-analysis → SDD implementer into a unified pipeline. Queries the KG for hot topics, finds relevant papers, ingests them, runs comparative analysis, and generates SDD plans with constitution-mandated artifact requirements baked in. Can run as a background daemon (every 60 minutes) via the KG engine's evolution cycle. Triggers on "evolve agent-utilities", "run evolution pipeline", "find and implement research", "research-driven development", "auto-evolve", "evolution scan". Also includes AST-based wiring sweep for concept traceability, dead code detection, and import graph analysis. Triggers on "wiring sweep", "concept audit", "dead code analysis", "traceability check", "code health".
Runs UQL — the epistemic-graph engine's native cross-modal Unified Query Language — a single pipelined text query that composes graph traversal, vector/ANN ranking, BM25 text search, relational (DataFusion) filtering, bi-temporal AS-OF/WINDOW, OWL reasoning, federation, and epistemic belief/evidence ops over ONE snapshot with no impedance mismatch between modalities. Use when a question spans more than one modality in one breath — "find docs about X, then rank by similarity to this vector, then only the ones live as of last month", "traverse citations then diversify the top results", "what supports this claim, discounted by our confidence at the time" — or whenever you'd otherwise chain several separate Cypher/SQL/vector calls by hand.
Tamper-evident audit ledger (G23): verifies the engine's hash-chained durable-mutation audit log and reconstructs "what happened to entity X" from the KG's own :ToolCall provenance. Use for "verify the audit chain", "is our audit log tamper-evident", "has anything mutated entity X and in what order", "reverse-index the tool calls that touched this node".
Compliance posture rollup + redacted bulk export — joins the tamper-evident hash-chained audit ledger with governance node counts (Control/Policy/Risk/ ComplianceRequirement/ComplianceGate/Regulation/Assessment/Incident/Finding/... already ingested from CISO Assistant + the TRM portfolio-intelligence engine) into one auditor-facing view, and bulk-exports a redacted subgraph via the engine's own disclosure_level (Full/Skeleton/ExistenceOnly) redaction. Use for "what's our compliance posture", "is the audit chain intact", "export these controls redacted for an auditor", "how many open compliance gaps do we have".
Answers a question and returns its full epistemic justification, not just the row — calibrated confidence + provenance/evidence refs + bitemporal valid/tx time (the KnowledgeBatch "currency upgrade"), the belief's justification tree (Asserted / DerivedSupport / DerivedContradiction / BayesianUpdate), the acceptance capstone (believed? since when? on what evidence? what would flip it?), a bitemporal what-changed diff between two transaction times, and — when policy hid something — which rows were denied and why. Use when an answer alone isn't enough — "why do we believe this", "how confident are we and why", "what would invalidate this", "what changed between these two points in time", "why was this row filtered out".