Expeed-Software

auditing-plan-fidelity

Use after plan execution and before code review — compares the actual diff to the plan and produces a drift audit report.

AI & Automation Listed

authoring-claude-md

Use when scaffolding or updating a repo's CLAUDE.md — auto-detects stack, infers existing conventions for brownfield repos, merges with the baselines.

AI & Automation Listed

brainstorming

Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores intent, requirements, and design before implementation. Brownfield-aware.

capturing-learnings

Use whenever a team learns something new — a gotcha, a convention, an incident, a pattern — and route it to the right durable location automatically.

Web & Frontend Listed

designing-ui

Use for UI design and development tasks — guides design-first, accessible, production-grade UI work with intentional aesthetics. Works with or without a formal design system.

executing-handoff-plans

Use when you have a written plan to execute — runs tasks in order, flags any deviation inline, and refuses to improvise.

AI & Automation Listed

exploring-codebase

Use when joining an unfamiliar repo or before making non-trivial changes in one — produces a structured mental model of entry points, components, data flow, and tests.

Use before executing a plan — puts the work in an isolated, gated workspace. At minimum a feature branch (so the review gate applies, since the hooks skip protected branches), or a dedicated worktree for heavier isolation. Run it first, before executing-handoff-plans or orchestrating-execution.

orchestrating-execution

Use when executing a written plan task-by-task in the current session by dispatching a fresh subagent per task, with exloom's review run as a gate between tasks. For solo or team work where you want speed plus a review panel on every task.

planning-for-handoff

Use when you have a spec or requirements for a multi-step task — produces a handoff-ready plan that someone other than the author can execute without ambiguity.

proving-done

Use before saying work is done, fixed, passing, or ready to ship (and before committing or opening a PR) — run exloom's eight-item evidence checklist and show real command output instead of asserting success.

requesting-review

Use when opening a pull request or marking work ready for review — produces a standard PR body with plan link, deviations, and test evidence.

review-gate

Use when closing work — when claiming done / complete / ready / shipping / about to push or open a PR — or when reviewing quality of a change before merge. Runs the tiered review gate (L1 code review, smoke test, proof the change is tested, adversarial review with cross-layer contract check, a recovery plan for Tier 3) and refuses to mark complete until the tier's required evidence is in `.claude/reviews/<branch>.md`.

reviewing-code

Use when reviewing a pull request or someone else's code — applies your org's consistency checklist with severity ratings and flags conflicts with existing repo conventions.

reviewing-plans

Use before handing off a plan to someone else — verifies the plan is unambiguous, complete, and executable by a non-author.

security-review

Use when reviewing a change for security before shipping — especially code that touches user input, auth, tenancy, secrets, data exposure, deserialization, external calls, cryptography, or dependencies, and especially AI-generated code. Runs real scanners plus a category review and produces evidence-backed findings. A first-pass aid, not a security guarantee.

switching-projects

Use when a developer is moving from one project to another — loads the new project's conventions, auto-detects differences from the previous project, produces a delta report with concrete trip-up warnings.

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior before proposing fixes. Root-cause first, never patch symptoms.

test-driven-development

Use when implementing any feature or bugfix — write the failing test first, then the minimal code to pass it, then refactor. Enforces design-through-testing discipline.

using-exloom

Use when starting work that will produce a commit — names the exloom skills and review commands and when each applies.

capturing-story-context

Use when starting test-case work from a user story, before any generation — fetches the story, numbers its acceptance criteria, and confirms navigation and dependencies with QA.

generating-test-cases

Use after story context is captured, to produce the test-case set — assesses complexity, applies test-design techniques, and audits coverage before QA sees it.

publishing-test-cases

Use when approved test cases need to be created on the board and linked to the story.

reviewing-test-coverage

Use when a QA engineer is reviewing generated test cases, requesting changes, or approving them for publication — also captures what QA's corrections teach about the application.