joe-bag-of-tricks

Use when starting creative work - creating features, building components, adding functionality, or modifying behavior. Also use when in plan mode and the user asks to brainstorm or design. Explores user intent, requirements and design before implementation.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when you have a bd task hierarchy to execute in a separate session with review checkpoints

Use when implementation is complete and all tests pass - handles the push, PR creation, and CI verification workflow

The shared operating contract for SDD implementer subagents — scope boundaries, escalation, self-review, and report format. Preloaded into the implementer-mechanical, implementer, and implementer-complex agents via their `skills:` frontmatter; not intended for direct use.

Use when completing code changes that affect user workflows, CLI flags, prerequisites, or project structure. Use proactively after feature implementation before session close.

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable

Use when a technical decision is being discussed or has been made - choosing between approaches, selecting libraries, establishing conventions, or making trade-offs

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when verifying a web UI in a browser - proving a page renders, a flow works, or capturing screenshots after a frontend change

Use when completing development work, before creating PRs, or on-demand to audit code changes for security vulnerabilities across any tech stack

Use when executing implementation plans with independent tasks in the current session

Reach for this the moment something that should work is failing and needs diagnosing or fixing — whether the user reports it or your own command, test, or build fails mid-task: a raised error or exception, a stack trace, a failing or wrong-valued test, a crash, a build or CI/Docker step that won't complete, output that's NaN/null/garbage, or behavior that broke after an upgrade, dependency bump, or code change. It's the default response to any concrete malfunction, and it applies hardest exactly when it feels unnecessary: when the fix looks like an obvious one-liner, when a fix was already proposed or tried and it still breaks, or when a bad value must be chased to its upstream source. Invoke it before editing or theorizing, to find the true root cause instead of patching a symptom. Not for abstract "what does this error/concept mean" questions, refactoring or speeding up code that already works, adding error handling to healthy code, or documenting an already-fixed bug.

Use when implementing any feature or bugfix, before writing implementation code

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when starting any conversation - ensures available skills are discovered and invoked before responding

Use when a UI feature batch is finished but a human has not seen it yet - catches truncated text, crowding, cryptic labels, weak hierarchy, and broken empty states before they are reported

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs

Use when creating, editing, or evaluating whether to create a custom subagent — including any behavior change to an existing agent definition under agents/.

Use when you have a spec or requirements for a multi-step task, before touching code. Also use when entering or already in plan mode — all planning in this project goes through bd (beads) issue hierarchies.

Use when creating new skills, editing existing skills, or verifying skills work before deployment