executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
waggle-memoryUse Waggle automatically as portable, local project memory during meaningful coding work; retrieve prior decisions and constraints, then store only durable outcomes.
Independent GitHub snapshot · Automated classification · Original documentation governs
Treat Waggle as memory owned by the project, not as a transcript archive or generic personal chat memory.
Before the first Waggle call in a task, choose one stable project value:
.git, such as github.com/acme/api.Reuse that value across sessions. Do not use only a directory basename because unrelated repositories can share it. Pass agent_id: "codex" and the current task/session identifier when one is available. Never mix remembered context from a different project into the answer.
prime_context once with the narrowest known scope.query_graph with the stable project scope. Start with max_nodes: 10, max_depth: 1, and retrieval_mode: "hybrid".get_related when a returned node ID needs graph context, and graph_diff when the user asks what changed.Use this threshold for every write:
Store information when forgetting it would likely cause duplicated work, a wrong future decision, or violation of an established constraint. Do not store something merely because it happened.
After a completed turn, call observe_conversation only when the turn crosses that threshold and contains durable project knowledge, such as:
Pass the actual completed user_message, the final assistant_response, and the same project, agent, and session scope used for retrieval.
Do not store greetings, acknowledgements, temporary debugging chatter, command logs, speculative thoughts, duplicate facts, aborted work, secrets, or facts cheaply recoverable from the repository unless their historical significance matters.
Prefer observe_conversation for normal completed turns. Use store_node only for an explicitly requested single atomic memory, and always include the project scope. Use store_edge when an explicit relationship materially improves the record, choosing only supported relationships: depends_on, contradicts, updates, derived_from, part_of, or relates_to. Use decompose_and_store only when the user explicitly requests unscoped bulk ingestion; it does not accept project scope.
clear_project, clear_session, or clear_all; preview with dry_run: true first.