best-copilot

Use when an agent needs the shared best-copilot contract for source priority, runtime adapters, init gates, work modes, dispatch packets, review, verification, memory, spec, state persistence, or closeout.

Use inside repo-init-scan after the official stage whenever scaffold verification, bounded repair, or `best-copilot.md` rewrite is still needed.

Use when coordinating large, ambiguous, cross-module, multi-agent, planning, dispatch, fan-in, closeout, or workflow-evolution work as the Senior Project Expert.

Use when maintaining requirements, design, tasks, ADRs, execution-plan state, closeout records, or memory/spec recovery as the Specification Writer.

Use when an approved tasks.md from a Spec Bundle, or a compact approved small-work plan, should be executed by fresh-context specialist subagents, with each task receiving implementation, spec-compliance review, code-quality review, and verification before closure. DO NOT USE FOR: missing plans, brainstorming, or simple single-file edits.

Create the target repository's local spec skeleton and reusable requirements/design/tasks templates. Use from repo-init-scan during first substantial plugin use, or from spec-writing flows when `spec/INDEX.md` or `spec/templates` is missing. Do not overwrite active project specs.

Use when owning full-stack architecture, SDD design brainstorming, backend/frontend integration, service boundaries, data models, API contracts, runtime behavior, mainline implementation strategy, parallel decomposition, or Developer/Frontend Designer-code review as the Technical Architect.

Use when a MEDIUM/LARGE task needs concrete implementation tasks with files, dependencies, acceptance checks, and verification. DO NOT USE FOR: tiny single-file changes or unresolved design direction.

Use when reviewing code diffs, implementation changes, agent/skill/instruction customization, targeted re-review, review feedback intake, review handoff preparation, or medium/large feature design before implementation. Covers correctness, spec compliance, security, performance, maintainability, frontend UX behavior, test adequacy, and multi-lane design risks.

Create the target repository's local AI instruction scaffold during first-use bootstrap. Use from repo-init-scan when `.github/instructions`, runtime adapters such as `AGENTS.md` / `CLAUDE.md`, or the neutral project facts scaffold are missing. Do not use to overwrite existing project-specific rules.

Use before implementation to review a Spec Bundle, design direction, or execution plan for readiness, traceability, scope discipline, multi-lane design risks, and TDD/verification feasibility. DO NOT USE FOR: implemented-code review or small already-frozen edits.

Use this skill for top-level/PM planning gates that need design exploration and explicit direction confirmation before specs or code for MEDIUM/LARGE work. Use when a request is ambiguous, has multiple route-changing options, or needs direction lock-in. DO NOT USE FOR: direct specialist invocation, clear small isolated changes, or already-confirmed specs.

Use when writing or reviewing Java code involving Tongdun/Alibaba Java rules, exceptions, logging, SQL/MyBatis, security, middleware, concurrency, virtual threads, JVM JIT performance, or project layering.

Use to prepare a minimal context packet for a delegated subtask or to consume a frozen packet without re-reading unrelated files.

Use when multiple frozen subtasks have non-overlapping write sets and can be implemented or reviewed in parallel.

Use after meaningful task closeout, repeated failure, review loops, stale triggers, or user feedback that an agent/skill/workflow should improve. Turns verified signals into auditable, bounded evolution proposals for agents, skills, memory, and README guidance. DO NOT USE FOR: speculative prompt tweaks without evidence, direct autonomous rewrites, or changing user-facing behavior without PM review.

Use when performing functional verification, regression risk assessment, code review, test sufficiency judgment, or merge-readiness review as the Quality Assurance Expert.

Use when target files are unknown, repeated search is becoming expensive, an agent is about to do broad repo-wide scanning, or a regex search is being considered. DO NOT USE FOR: explicit user paths or already frozen files_involved.

Use before repo-init-scan to cheaply decide whether a target repository already satisfies the current best-copilot init contract by reading only the root `best-copilot.md` sentinel.

Use after repo-init-gate fails, or when explicit reinitialization/repair is requested, to orchestrate the official init stage and the manual fallback stage.

Compatibility entrypoint for runtimes that resolve the Senior Project Expert name as a skill instead of the Senior Project Expert agent. Runs the same init preflight before PM/coordinator workflow.

Create the target repository's local memory skeleton after repo init. Use from repo-init-scan during first substantial plugin use, when `memories/repo` is missing, or when MEDIUM/LARGE work needs persistent recovery state. Do not store active project memory in the plugin package.

Use before claiming work is done, fixed, passing, or ready. Requires a final evidence check and residual-risk statement.

Use when executing an already approved multi-step implementation plan or tasks.md with checkpoints, verification evidence, and per-task review. Requires current execution confirmation when the packet is part of PM orchestration. DO NOT USE FOR: brainstorming, spec writing, or one tiny isolated edit.

Use when implementing or reviewing pages, components, interactions, responsive layouts, browser behavior, visual quality, or frontend performance as the Frontend Designer.

Use when requirements or spec are clear and the implementation should be a minimal, repo-pattern-compatible diff. DO NOT USE FOR: unclear direction, broad redesign, or tasks without enough file/context evidence.

Use inside repo-init-scan to try a target-local `init` skill, Claude `/init`, or `copilot init`, normalize official init output into `.github/instructions/project.instructions.md`, and decide whether manual fallback is still needed.

Use when implementing a frozen subtask, staying inside assigned files, or reviewing Technical Architect-owned code as the Developer.

Use when concrete failure evidence requires root-cause analysis, minimal patching, and regression proof as the Root Cause Fixer.

Use when reviewing authentication, authorization, dependencies, configuration, release surfaces, sensitive data, logging, validation, CORS, secrets, or external-service risk as the Security Reviewer.

Use after implementation and required verification when PM/coordinator must choose merge, pull request, preserve, discard, or workspace cleanup handling for the current branch.

Use when writing or reviewing Python code, fixing lint/docstring/import/naming/exception/type annotation issues, unifying team style, or migrating `.py` files toward Google style.

Use before approved implementation plans or substantial feature/fix work when workspace isolation, branch provenance, setup baseline, or worktree safety must be decided.

Use after code or configuration changes to prove the changed behavior with minimal sufficient commands, HTTP/browser checks, or static evidence. DO NOT USE FOR: purely speculative review without a concrete change.

Use when page, component, form, table, dashboard, responsive layout, or UI review work needs product-quality implementation guardrails. DO NOT USE FOR: backend-only changes or scripts with no user-visible surface.

Use when failure evidence already exists and the likely file set is narrow. Finds the root cause and guides the smallest safe fix.

Use when a bug, failing test, incident, or unexpected behavior has unknown cause and scope is not yet frozen.

Use when adding behavior or fixing a bug where a focused failing test can be written first.

Use after frontend page, component, style, route, form, or interaction changes to verify browser behavior and visual quality with real evidence.