justinjdev

Multi-task orchestrator. Coordinates agent teammates (led by Gandalf) running /quest (code) or /scout (research) workflows. Use when you have multiple independent tasks to run in parallel.

Use for any non-trivial task. Orchestrates the Research-Plan-Implement cycle with compaction between phases, integrating council, lembas, gather-lore, and warden. Enforces discipline and phase gates.

Post-fellowship retrospective analysis. Collects gate history, palantir alerts, and quest metrics to surface patterns and interactively recommend configuration improvements.

Use AFTER writing code and BEFORE submitting a PR. Simulates a strict code reviewer by comparing changes against reference files and documented conventions. Catches "we don't do it that way" feedback before your human reviewer does.

Fetches GitHub issue context for quest spawning. Parses issue references, retrieves structured data via gh, and produces branch suggestions and PR keywords. Used standalone or as input to quest orchestration.

Research & analysis workflow. Investigates questions, gathers findings, optionally validates with a fresh subagent. Produces a report — no code, no PRs, no commits. Use standalone or as a fellowship teammate.

Use at the start of any non-trivial task. Loads focused, task-relevant context by reading CLAUDE.md, scanning for related files, and producing a structured Session Context block. Invoked automatically by quest or standalone via /council.

Use between workflow phases or when context feels bloated. Compresses the current conversation into a structured summary capturing task, findings, files, state, and next steps. Invoke standalone or automatically between quest phases.

Use when reviewing code for structural quality — factoring, coupling, cohesion, abstraction levels, information hiding, and simplicity. Adversarial: challenges every design decision, not just obvious violations.

Use when reviewing code for security — authentication, authorization, input validation, injection, data exposure, cryptography, or trust boundaries. Adversarial: assumes the attacker has read your code and is actively looking for a way in.

Use when reviewing code for performance — database queries, network calls, collection processing, caching, concurrency, or code on hot paths. Adversarial: finds the scaling assumptions that will collapse under real load.

Use when reviewing tests or test coverage — unit tests, integration tests, test suites, or PRs that include tests. Adversarial: finds the bugs the tests would miss, not just the tests that are missing.

Use when reviewing code or designs for production reliability — failure modes, operational risk, silent failures, recovery difficulty, and incident scenarios. Adversarial: imagines the worst production incident this code could cause and works backwards.

Autonomous performance optimization loop for shire. Proposes code changes, benchmarks, keeps improvements, reverts failures. Runs indefinitely.