yacb2
UserDeveloper experience toolkit for organizing AI coding assistant ecosystems — skills, documentation structure, and project context.
Categories
Indexed Skills (19)
aidex-loop
Use when the user wants to design, scaffold, or choose an agentic LOOP that repeats one task until a check passes — iterate-until-green automation, a long-running unattended build, or picking which loop engine fits — landing as a written `.context/loops/` loop-spec (goal + verifiable stop condition + guardrails + chosen engine) before the loop runs. Fires on "design a loop for X", "set up a loop to keep building until tests pass", "make a loop that iterates until green", "loop until the build is clean", "which loop should I use". Not for: one-shot multi-agent fan-out across N different targets, which repeats nothing (aidex-workflow); executing an existing loop right now (hand off to the ralph-loop plugin, /loop, or /goal); one-off tasks with no stop condition; planning multi-step work without a loop (aidex-plan); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-workflow
Use when the user wants to design or scaffold a one-shot multi-agent fan-out / decomposition orchestration — review code across N dimensions, migrate N call-sites in parallel, research N sources, or split an implementation into parallel agents with per-agent model/effort assignment — landing as a written `.context/workflows/` workflow-spec (goal + fan-out shape + per-agent model table + gate policy) before the Workflow runs. Fires on "design a workflow to review X across N angles", "fan out agents to migrate every call-site", "orchestrate a multi-agent review of X", "decompose this into parallel agents with different models". Not for: executing a written multi-phase plan (aidex-plan-exec — there is a plan doc); repeat-until-a-check-passes automation (aidex-loop); planning multi-step work without orchestration (aidex-plan); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-audit
Use when the user wants to assess the state of a feature, flow, or module — a UX, security, performance, or accessibility audit; cataloging bugs, gaps, and opportunities; retesting open findings; escalating a finding to the backlog; or updating audit methodology. Fires on "I want to do a UX / security / performance / accessibility audit", "before we ship I want to audit X", "audit the X flow or module", "catalog the state of X", "list bugs and gaps in X", "retest open findings", "register a finding under audit X", "escalate finding <id> to backlog", and /aidex-audit commands. Not for: auditing the Claude Code setup itself like skills or MEMORY.md (aidex); creating plans (aidex-plan) or decisions (aidex-decision); generic backlog items not from a finding (aidex-backlog).
aidex-backlog
Use when the user wants to capture or defer something for later without acting on it now, or to work the existing backlog as a board. Fires on "add to the backlog", "add to the backlog the idea of X", "park this for later", "defer this one", "shelve the X idea", "queue this for later", "track this for later", "we'll do this later", "move finding <id> to the backlog", "show me the backlog", "list open backlog items". Also owns the board itself, not just intake: "triage the backlog", "sweep the open items", "do a backlog sweep", "define these items", "which of these are already done", "what can we close quickly", "run these as a work-list", and /aidex-backlog commands. Not for: plans (aidex-plan), decisions (aidex-decision), references (aidex-reference); auditing project state (aidex-audit); ecosystem audits (aidex).
aidex-plan-exec
Use when the user asks to execute, implement, or continue a written multi-phase plan — typically a `.context/plans/` document or any plan with checkboxes/phases. Fires on "implement the plan", "execute plan X", "let's execute the plan", "continue with phase Y", "resume the plan", "run the plan phase by phase". Enforces between-phase discipline: code-review, commit, handoff when context grows. Not for: creating the plan itself (aidex-plan); one-shot tasks with no phases; bug fixes (aidex-bugfix); pure refactors with no plan document.
aidex-comm
Use when the user wants to log or draft a real communication with a person — capture an email/WhatsApp that was received, log a meeting or call that happened, or draft a message/email to send — as a written `.context/communications/` entry, kept in the communication's native language. Fires on "log this email", "save the email the client sent", "capture this WhatsApp from X", "record the call with X", "log the meeting with X", "draft an email to X", "write a reply to the client", "save this thread", and /aidex-comm commands. Not for: capturing a stakeholder/product requirement to act on (aidex-request); recording a decision/ADR (aidex-decision); planning multi-step work (aidex-plan); deferring an idea (aidex-backlog); research notes (aidex-research); references (aidex-reference); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-plan
Use when implementation work should become a written `.context/` plan before coding starts — either multi-phase work (a feature build, a migration, a refactor spanning backend/frontend/infra) or a single scoped change where only the file list and acceptance criteria need pinning down; a triage step picks which. Fires on "create a plan for X", "let's plan X", "I want to plan X", "we need to plan X", "plan the migration of X", "let's build a multi-phase plan", "implement X minimally", "a small scoped change to X", "just the minimum to ship X". Not for: fixing a bug or regression, which needs a failing test (aidex-bugfix); deferring or parking an idea for later (aidex-backlog); ADRs (aidex-decision), requests (aidex-request), research (aidex-research), or references (aidex-reference); ecosystem audits (aidex); project-state audits (aidex-audit); direct implementation with no plan doc.
aidex-worktree
Use when the user wants to create, run or tear down a git worktree with its own isolated environment (database, ports, containers), or when a project has no worktree setup yet and one needs bootstrapping by investigating the repo topology and verifying the compose stack can run twice — "set up a worktree for X", "create an isolated worktree", "spin up a second environment", "tear down the worktree", "how do we do worktrees on this project", "my worktrees are leaving Docker images/volumes behind", "worktree ports collide", first-time worktree setup. Also fires when aidex-plan/aidex-plan-exec/aidex-loop reach their Isolation step. Not for: planning multi-step work (aidex-plan); designing a loop (aidex-loop); a single-repo code-only checkout with no services (native EnterWorktree).
aidex-reference
Use when the user wants to document how an existing, settled part of the system works as an evergreen `.context/references/` module — architecture, configuration, an operational runbook, a how-it-works guide. Fires on "create a reference for X", "document how X works", "write up the X architecture", "document the X configuration", "write a runbook for X", "what is documented and what is missing". Not for: planning multi-step work (aidex-plan); recording a decision/ADR (aidex-decision); capturing a stakeholder request (aidex-request); investigating something not yet settled (aidex-research); deferring/parking an idea (aidex-backlog); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-review
Use when the user wants code reviewed as it stands — a module, a feature, a path, or the whole app — rather than a diff or a pull request. Covers correctness/bug hunting, simplification and dead code, exploitable security defects, and performance waste, and it first proposes which finder agents are worth launching and what they will cost. Fires on "review this module", "review the X feature", "find bugs in this module", "what dead code is in X", "can this module be simplified", "security review of this code", "review the whole app", "review the changes since Friday / this weekend" (the changes pick the modules, reviewed as they stand). Not for: reviewing a diff, branch, or PR (the built-in /code-review, /simplify and /security-review already do that); auditing a running system against Lighthouse/OWASP program methodology (aidex-audit); fixing a specific known bug (aidex-bugfix).
aidex-dash
Use when the user wants an interactive HTML dashboard/render/board of `.context/` data — the backlog board, a plan's progress, an audit inventory, the coverage matrix — or says "render X as HTML", "generate the dashboard", "show this as a page". Not for: authoring content (the markdown stays canon); publishing without being asked.
aidex-conventions
NOT auto-invoked. Shared documentation-canon hub for the aidex-* family — holds the .context/ convention references (references/*.md) that the single-purpose sibling skills delegate into. Routing — plan multi-step work → aidex-plan; record a decision/ADR → aidex-decision; capture a stakeholder/client request → aidex-request; investigate/research how something works → aidex-research; document a settled system reference → aidex-reference; defer/park an idea for later → aidex-backlog; capture/draft a communication received or to send → aidex-comm; check a skill against house conventions → aidex-skill. This skill is the canon home, not an entry point; the siblings are the entry points.
aidex
Use when the user wants to audit, organize, clean up, or health-check their Claude Code setup — a messy or inconsistent .context/, a bloated or stale MEMORY.md, broken symlinks in .claude/skills, unused or misplaced skills, dead CLAUDE.md links, plugins inflating idle context, or "my project opens heavy / wastes context". Also fires on "audit my project", "organize my ecosystem", "what skills do I have", "check my project's health", "I think I have broken symlinks", "my .context/ is a mess", "my new project has no .context / help me start with aidex", and the /aidex command. Not for: creating .context/ docs (aidex-plan, aidex-decision, aidex-reference, aidex-research, aidex-request); project-state audits like UX or security (aidex-audit); backlog items (aidex-backlog).
aidex-decision
Use when the user has made an architectural, technical, or product decision and wants it recorded as a written `.context/decisions/` ADR — what was chosen, why, the alternatives, and the consequences — so the team does not re-litigate it later. Fires on "we decided X", "document this decision", "write an ADR", "record the decision to X", "log why we chose X", "we settled on X, write it up". Not for: planning multi-step work (aidex-plan); deferring or parking an idea for later (aidex-backlog); capturing a stakeholder/client request (aidex-request), research notes (aidex-research), or a settled reference (aidex-reference); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-request
Use when the user relays an incoming stakeholder, client, or product request that should be captured as a written `.context/requests/` item before anyone acts on it — a feature ask, a requirement from a meeting, user feedback to formalize. Fires on "the client asked for X", "the stakeholder wants X", "capture this as a request", "log this requirement", "we got a request to add X". Not for: planning multi-step work (aidex-plan); recording a decision/ADR (aidex-decision); investigating how something works (aidex-research); documenting a settled reference (aidex-reference); deferring/parking an idea (aidex-backlog); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-research
Use when the user needs to investigate, explore, or spike on how something works and the findings should land as written `.context/research/` notes before any plan or implementation. Fires on "research how X works", "investigate X", "spike on X", "look into how X is done", "I need to understand X before planning". Not for: planning multi-step work once the approach is known (aidex-plan); recording a decision/ADR (aidex-decision); capturing a stakeholder request (aidex-request); documenting a settled, stable reference (aidex-reference); deferring/parking an idea (aidex-backlog); ecosystem audits (aidex); project-state audits (aidex-audit).
aidex-skill
Use when the user wants an existing or in-progress skill checked or structured against THIS project's house skill conventions — "what are our skill conventions", "review this skill against our standards", "does this skill follow our patterns", "structure this skill the way we do", "audit this skill's front-matter/description for our rules". Not for: creating a skill from scratch, optimizing a skill's description for triggering, or running skill evals (all skill-creator); planning (aidex-plan); decisions (aidex-decision); requests (aidex-request); research (aidex-research); references (aidex-reference); ecosystem audits (aidex).
aidex-coverage
Use when writing, placing, or running tests in any project — which layer a behaviour belongs in ("unit or E2E for X", "component test or browser test"), which tests to run for a change instead of the whole suite, when to extract a fixture, setting up an isolated disposable E2E environment, or the per-project testing profile and the stack pack it names for the concrete test shapes (Django, Vue, Playwright, Payload, Svelte). Fires on "write a test for", "add a regression test", "which tests should I run", "run only the affected tests", "set up E2E for this project", "generate test-e2e.sh", "how do we test this stack". Not for: running a coverage audit, the module map / coverage matrix, tracking a finding, or suite-speed measurement — all of that is aidex-audit's test-coverage playbook.
aidex-bugfix
Use when fixing a bug, resolving a reported issue, or when something is broken and needs a test-driven fix — investigate root cause, write a failing regression test (RED), implement the minimum fix, confirm the test passes (GREEN), then commit test and fix together. Fires on "fix this bug", "this is broken", "it's not working", "there's a regression", "resolve this issue", or a reference to a bug report. Not for: planning multi-step work (aidex-plan); executing a written plan phase-by-phase (aidex-plan-exec); recording why a fix was chosen as an ADR (aidex-decision); pure refactors with no bug.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.