codex-skills

Use when a user message needs Chinese-first intent inference, low-confidence collaborative clarification, routing, workflow weight control, skill choice, review/testing/planning/debugging/evaluation routing, proactive multi-thread collaboration or conflict coordination, continuation handling, execution permission inference, or protection from process over-escalation.

Use when active development or explicit refactoring has concrete code-structure risk: a source file is accumulating independently changing responsibilities, a class/component/function is hard to navigate or test, repeated changes touch distant sections, or the user asks to split a giant file; do not use for line count alone, generated/vendor/migration/schema/fixture files, or cohesive modules that remain easier to maintain together.

Use when the user explicitly enables an automated same-project multi-thread development loop that keeps peer Codex tasks progressing, recovers conflicts or stale coordination, integrates verified work into local main, and closes cleanup without repeated gates; do not use before opt-in, for one-off coordination, remote publication without permission, or subagent creation.

Use when existing independent Codex App threads work in the same project and need peer advice, collaboration proposals, shared progress awareness, ownership arbitration, conflict pause/resume, discussion, merge coordination, status exchange, or handoff through native thread tools without creating subagents.

Use when a verified or integrated software change has concrete temporary artifacts, generated noise, stale claims, merged local branches, or disposable worktrees to clean, or when the user explicitly asks to remove development residue or old branches.

Use when the user or project rules explicitly request project-local memory/dashboard initialization or updates, or when an existing `.docs/project-memory/` is needed for cross-session recovery, durable decisions, blockers, parallel-agent coordination, or formal handoff; do not auto-initialize or sync it for ordinary development.

Use when two or more existing, independent Codex App threads in the same project can help each other finish their own tasks through peer negotiation, shared-contract alignment, dependency exchange, conflict reduction, or coordinated local integration; do not use to create or command subagents, transfer ownership, or add ceremony to unrelated work.

Use when an explicit performance goal, measurable regression, unresolved hot path, large workload, concurrency/cache/streaming decision, or latency/throughput/CPU/memory/I/O/bundle budget needs profiling and evidence-backed optimization; do not use for routine development, speculative cleanup, or an already-located N+1/local inefficiency whose batch fix and deterministic count verification are clear to the current owner.

Use when an observed bug, correctness regression, failing test, build failure, abnormal behavior, or unresolved root cause needs Chinese-first diagnosis and bounded repair; obvious local inefficiency found during feature work stays with its owner, while measurable performance work uses ccdawn-performance-engineering.

Use when an already-defined new behavior or high-risk implementation contract needs a failing test before implementation, or the user explicitly requests TDD; diagnosed bugs stay with ccdawn-bug-review, while simple or mechanical work uses targeted verification.

Use when aligned requirements need a persistent or reviewable implementation plan, including a compact task graph only when independent deliverables, owners, dependencies, risk gates, or verification contracts make splitting valuable.

Use when the user explicitly requests review of a PR, diff, branch, commit range, merge readiness, or review feedback, or when a high-risk change has reached an explicit pre-integration review gate; do not trigger merely because ordinary development finished.

Use when CCDawn workflow needs a Chinese-first review of an entire repository, codebase, architecture, technical debt, test coverage, risk modules, maintainability, onboarding state, or project health before planning, refactoring, takeover, or prioritization.

Use when the user explicitly requests a repository/subsystem simplification audit, dependency-bloat review, or ranked removal plan, or when concrete evidence makes structural complexity the primary investigation; do not substitute it for ordinary project health review.

Use when the user explicitly asks whether a diff, PR, branch, commit range, or proposed patch is over-engineered or can be made smaller, or when concrete evidence makes removable complexity the primary review question; do not attach it to every code review.

Use when a complex feature has an unresolved reuse decision and external projects, libraries, standards, examples, or in-project modules could materially change architecture, dependencies, scope, or implementation; do not use for routine work already covered by local patterns or standard platform capabilities.

Use when repeated work is governed by an explicit metric, active baseline, candidate comparison, promotion gate, leaderboard feedback, or submission iteration; do not use for a one-off research check that its current owner can execute directly.

Use when a frontend task primarily concerns cross-component design tokens, semantic theming, component APIs, variants and states, shared primitives, Storybook or library governance, Figma-to-code consistency, or a staged design-system migration; do not use for a single page, isolated styling fix, visual direction, or review-only task without a systemic ownership problem.

Use when the user explicitly requests an open-ended, persistent iteration policy with evidence-based next-step selection and stop conditions, and no domain-specific research, score, development, or coordination owner already controls the loop.

Use when a CCDawn task needs a new or revised UI/UX direction, information architecture, interaction model, responsive behavior, accessibility decision, or implementable interface contract; do not use for review-only findings, production implementation of an accepted contract, backend work, or mechanical frontend edits.

Use when a UI task primarily needs a distinctive but context-appropriate visual direction, brand expression, typography, color system, composition, imagery, iconography, or motion language before implementation; do not use for information architecture, routine product UI, design-system governance, implementation of an accepted direction, or review-only findings.

Use when AI/ML research engineering needs baseline reproduction, hypothesis-driven experiments, ablations, evaluation design, findings synthesis, research direction selection, plateau recovery, or a reproducible loop from a paper/repository/research question to evidence-backed results.

Use when coordinating an end-to-end research competition or benchmark program across multiple lifecycle stages such as rules, data, baseline, experiments, claims, and submission; use a stage owner directly for isolated work.

Use when an AI/ML research result, baseline promotion, ablation conclusion, benchmark claim, paper claim, surprising finding, or high-cost next experiment needs an evidence-focused rigor review before it is accepted, generalized, published, or used to redirect the research program.

Use when an aligned UI contract or established project pattern needs production frontend implementation across components, layouts, interaction states, responsive behavior, accessibility, or runtime browser verification; do not use when the primary uncertainty is product direction, visual identity, design-system governance, or review-only findings.

Use when completed work needs formal cross-stage or cross-session synthesis, resumed-task closure, durable handoff evidence, deferred-risk accounting, or an independent PR/release evidence package that the current owner's concise final response cannot represent.

Use when CCDawn workflow needs a Chinese-first evaluation adapter and no more specific existing skill already owns the review, debugging, PR, planning, feedback, verification, or goal task.

Use when an existing page, component, screenshot, UI flow, visual change, or frontend implementation needs a Chinese-first UX, visual hierarchy, interaction-state, responsive, accessibility, design-system, or browser-runtime review; use as support for UI-focused PR review, and do not trigger for creating a new design or implementing already accepted fixes.

Use when optimizing, benchmarking, packaging, comparing baselines, handling online score feedback, or coordinating parallel agents for a Huawei Algorithm Challenge 37 NSLB workspace identified by its solver and score-loop artifacts.

Use when the user wants context-aware concept collision, unknown concept generation, divergent thinking, creative ideation, concept invention, paradigm exploration, unusual alternatives, product ideas, research concepts, strategy concepts, story concepts, or surprising but useful options.