skills

You MUST use this when configuring tsconfig, resolving compiler errors, debugging slow type-checking, fixing module resolution or ESM/CJS issues, hardening strictness, migrating JavaScript or a new compiler major, or setting up type-checking in monorepos. Not for general feature work in TypeScript code.

You MUST use this when work is about to be called complete, done, fixed, ready, or mergeable - before a completion claim, a merge or pull request, a branch finish, or a handoff report.

You MUST use this when configuring, writing, debugging, running, migrating, or auditing Vitest tests in JavaScript/TypeScript projects - Vite, Vue, Nuxt, React, Next.js, Node libraries, workspaces, coverage, mocks, snapshots, flaky tests, CI parity, or Jest migration.

You MUST use this when interacting with or testing local web applications with Playwright - verifying frontend functionality, debugging UI behavior, capturing browser screenshots, or viewing browser console logs.

You MUST use this when verified development work needs an integration decision - before merging, pushing, opening a pull request, preserving a branch for handoff, discarding work, or removing a workspace - covering which finish options the actual environment allows, which base branch the evidence supports, whether the verification verdict still applies to the current tree, and whether the workspace is provably ours to clean up.

User-invoked via /commit-all only. Gathers the working tree into a single commit on the current branch, no push.

You MUST use this when writing or substantively editing prose in a project (docs, READMEs, UI copy) and when asked to audit, score, or clean up dash usage - it enforces the plain hyphen over typographic dashes in English text.

You MUST use this when investigating bugs, regressions, failing tests, build or integration failures, flaky behavior, performance anomalies, or other unexpected technical behavior.

You MUST use this when building, styling, debugging, or optimizing Apache ECharts charts in JavaScript, React, or Vue - setup, lifecycle, responsive resizing, theming, large datasets, streaming, SSR, and symptoms like a blank chart or broken resize. Not for choosing chart types or for other charting libraries.

You MUST use this when creating, redesigning, reviewing, or polishing a user interface - landing pages, product and dashboard screens, marketing surfaces, component work, visual and UX critique, and design-quality passes over existing frontend code. Not for driving a browser to verify that a local web app works, which belongs to web-debug.

You MUST use this when development work needs a decision about where it will run - before implementing a plan, starting risky or long multi-file work, dispatching parallel or subagent work units, or reproducing a bug in a clean environment - covering whether isolation is needed, reusing existing isolation, and selecting a harness-native workspace, a Git worktree, or safe work in place.

You MUST use this when an implementation plan already exists and is to be executed directly by the current agent in this session - after choosing inline execution over subagent orchestration, or when resuming an interrupted execution - covering which plan details went stale against the current tree, which failures are ordinary work rather than blockers, how deep each task must be verified, and what fresh evidence closes the plan.

You MUST use this when auditing, improving, restructuring, or maintaining a repository's agent instruction and context architecture - AGENTS.md, CLAUDE.md and its variants, .claude/rules/, the instruction layer of SKILL.md files, or docs linked from them - including reducing always-loaded context cost, finding stale, duplicated, or conflicting instructions, and keeping Claude Code or Codex project memory aligned with the codebase. Not for documentation written for human readers, and not for authoring or revising a skill itself.

You MUST use this when writing or substantively editing prose in a project (docs, READMEs, marketing copy) and when asked to audit, score, or clean up negative parallelism, the "it's not just X, it's Y" construction. Not for ordinary factual negation.

You MUST use this when several units of work might run concurrently through agents - independent investigations, specialist reviews, repository analyses, or plan tasks that look unrelated - covering whether they are genuinely independent, which mutable state needs isolation, how wide the wave should be, and how results are reconciled before integration.

You MUST use this when an approved design or settled requirements need a detailed multi-step implementation plan before code changes begin.

You MUST use this when a completed or partially committed implementation needs an independent code review against explicit requirements, a defined task scope, and the actual Git diff, including committed and working-tree changes.

You MUST use this when code-review findings, PR comments, CI review output, or reviewer suggestions need technical validation before any fix or disposition, including feedback from human reviewers, subagents, GitHub, static-analysis tools, or external review systems.

You MUST use this when a request needs design decisions before code - new features, product or UX behavior, architecture changes, unclear success criteria, or two materially different approaches. Explicitly specified mechanical refactors, localized fixes with known expected behavior, and single-outcome config changes go straight to implementation.

You MUST use this when creating, improving, evaluating, or optimizing an agent skill, deciding whether a workflow needs a reusable skill, defining its capability, trigger boundary, architecture, output contract, verification tier, eval strategy, baseline, or evidence, or deciding whether to split, merge, simplify, retire, or replace a skill. This includes underspecified questions about making a repeated workflow a skill, choosing verification for a proposed skill, or showing evidence that an improvement changed behavior. When any of these craft decisions are present, invoke skill-crafting before answering or asking for clarification. Route AGENTS.md, CLAUDE.md, or SKILL.md instruction-architecture maintenance to maintaining-agent-context, settled implementation plans to plan-crafting, and code behavior fixes to tdd.

You MUST use this when a sufficiently concrete implementation plan is to be executed through scoped subagents rather than inline - after choosing subagent execution, or when resuming an interrupted orchestration - covering how each task brief is scoped, which risk level drives implementer and review strength, what independent verification the controller owns before accepting a task, and when a stalled fix loop escalates.

You MUST use this when implementing a behavior change - a feature, a bug fix, or a refactor whose contract is checkable - especially when a test could fail for a setup reason, assert the wrong boundary, pass without proving the requirement, or cross module, API, external, state, security, or visual boundaries. Not for purely mechanical edits with no observable behavior.