AI Agent Workflow Collection

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

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 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 a verified or integrated software change has concrete temporary artifacts, generated noise, stale claims, merged local branches, disposable worktrees, or a known PR lifecycle state that requires deferred or post-merge local closeout, or when the user explicitly asks to remove development residue or old branches.

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