Interactive exploration and requirements discovery using the knowledge store. Searches existing decisions, findings, and code before exploring new ideas. Records discoveries as research, findings, and decisions. Use when exploring options, discussing architecture, or investigating before planning.
Build live causal context about a repo. Authors non-trivial thoughts that answer WHY systems exist and behave the way they do, weaving evidence across code, cloud, practice, and knowledge graphs. Distinct from /research (which describes WHAT) — /explore answers why.
Join a hive as a worker (claim work, do it, report the result) or act as a coordinator (dispatch role-targeted work and read the outcomes). A hive is a cloud work-queue for coordinating multiple agents across machines. Use when you want agents on different machines to pass work to each other by capability/role instead…
Execute an implementation plan from the knowledge graph step by step. Updates status, verifies criteria, records thoughts about what you encounter, and charges thoughts when evidence arrives. Use after a plan has been created and approved.
Deep, research-driven review of an infrastructure changeset BEFORE any infra command runs (deploy, apply, helm upgrade, terraform apply, provision, image roll). Grounds every claim in four authorities — provider docs (web-verified), current source, the LIVE cloud graph (actual deployed state), and runtime log graphs …
Ingest design patterns from an authoritative source (book, public catalog, reference site) into the practice/design-patterns.bin library graph. Four stages — collect the source once into a raw graph, extract from it interactively with zero LLM spend, freeze a good extraction as a saved recipe when it is worth…
Orchestration discipline. Defines the team hierarchy, your role as Engineering Manager, signal routing, drift detection, and the failure modes that make you a bad manager. Loads at the brainstorm-to-execute boundary and persists through ticket execution.
Create an implementation plan in the knowledge store. Researches the codebase first, then creates a structured phased plan with success criteria. Use when starting a new feature, refactor, or multi-step task.
Propose net-new projects — new features or gap-fills in existing features — by mining past tickets and thoughts, walking the target repo for feature seams that stop short, and running web research including market/competitor analysis. Mostly non-interactive; presents 3-5 evidence-backed proposals and offers…
Record an architectural or design decision in the knowledge graph with full rationale. Use after making a significant choice that future developers should know about.
Introspect on your thought graph — examine personality, influence, tensions, blind spots, and reasoning patterns. Use for metacognition sessions, debugging reasoning, or understanding how your thinking has evolved.
Research a topic using the knowledge store. Searches code, knowledge nodes, and existing decisions to build understanding. Use when investigating how something works, exploring options, or gathering context before implementation.
Capture the session feedback loop after work is verified for real — record a reproduction/interaction guide, charge the session's reasoning with the real-world evidence, record findings, and close the ticket. Use AFTER a feature is smoke-tested and confirmed working, or an investigation is remediated — never before.
Design a test plan collaboratively. Researches what needs testing, discusses scope and criteria interactively, then creates a structured test plan with steps and pass/fail criteria.
Action rulebook for corpus checks — when a criterion is really a check, defect classes owe class checks, fixture-pair discipline, auditing and executing check-backed criteria. Not user-invocable.
Action rulebook for writing plan criteria — the evidence-bearing law (red+green execution proof required), criterion shape rules, and the forbidden-shapes catalog. Read by agents at the criterion-authoring flow step; not user-invocable.
Action rulebook for surface censuses and reuse — programmatic enumeration, counts-are-floors, caller censuses before touching symbols, and the reuse-before-new discipline. Not user-invocable.
Action rulebook for ticket creation — the blocking pre-ticket research gate, defect tickets' root-cause-check duty, the In/Out-of-Scope handoff shape, and the two mandatory project-closing tickets. Read before any createticket call. Not user-invocable.
Action rulebook for executing stored criteria — run the stored bytes from the graph, classify with pasted evidence, vacuous-pass shapes, skip-is-not-a-pass. Read at every criterion-execution flow step; not user-invocable.
Action rulebook of instrument blind spots — graph-read projection traps, shell semantics that are not inferable, recurring fabrications, measurement artifacts, tool-retry discipline. Read before the first load-bearing command of a session. Not user-invocable.
Action rulebook for causal and optimization claims — ground truth over narrative, investigation briefs carry instruments not mechanisms, measured-proposals-only with instrument anchor and variant×scale matrix. Read before relaying any causal claim or optimization proposal. Not user-invocable.
Action rulebook for plan shape — phases across context boundaries, phases are not commit units, reproduction-before-regression, perf shape, literals' hidden claims, lifecycle/crash-window obligations, critical-review structure. Not user-invocable.
★not rated 1 todayA51 tokens
Apache-2.0
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: