Claude Skills by yacb2

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",...

Use when the user wants an HTML artifact — a report, a consultation page, a dashboard, any interactive page, or even a quick throwaway page just to try it — built from the discussion or from `.context/` content and opened locally: "create an artifact for X", "make me an HTML report", "let''s discuss this in an artifact", "render X as HTML", "a simple artifact, just to test". Sub-action: the deterministic `.context/` boards — backlog, plans progress, audit inventory, coverage matrix — render f...

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 f...

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 th...

Use whenever a bug is reported and a fix is asked for, however small the fix looks, even a one-line change: the regression test comes before the edit, so do not patch the code directly on a bug report. 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", "X returns Y instead of Z, f...

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 ...

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 → plan; record a decision/ADR → decision; capture a stakeholder/client request → request; investigate/research how something works → research; document a settled system reference → reference; defer/park an idea for later → backlog; capture/draft a communication received or to s...

Use when planning or placing tests rather than writing one — 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 (Django, Vue, Playwright, Payload, Svelte). Fires on "which tests should I run", "run only the affected tests", "set up E2E for this project", ...

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...

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...

Use whenever the user asks to execute, implement, resume or continue a written plan — a `.context/plans/` document or any plan with checkboxes/phases — however small the phase looks, even a single-file edit: the plan''s checkboxes and Execution log are updated by this skill, so do not carry out the phase directly from the plan text. Fires on "implement the plan", "execute plan X", "let''s execute the plan", "continue with phase Y", "resume the plan", "run phase 1 of the plan", "run the plan p...

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 smal...

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); capt...

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 so...

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...

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 revi...

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:p...

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 a...

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 behi...

Use when about to write, add or change a test in any project — a unit, component, API or E2E test, a regression test for a bug, or tests for a change just made. Preloaded into code-writing agents (implementation and bugfix) so the authoring core is in context before the first test file is written. Fires on "write a test for", "add a regression test", "add tests for this change", "cover this with a test", "write a Playwright spec for". Not for: planning or auditing a suite, choosing which test...

Use when work touches what a screen looks like: a new screen, a redesign of an existing screen, a visual defect to fix and show fixed, or a "looks right" claim with no image behind it. Fires on "what should this screen look like", "show me every state of this list", "check it in light and dark", "prove the layout is fixed", "I need a mockup of this screen", "redesign the existing home page", "the form overflows on mobile, fix it", "dark mode is wrong on this page". A visual defect (misaligned...