comet

对照当前仓库契约、源码、Runtime、测试和安装行为，验证并分类 Comet GitHub Issue。用户询问 Issue 是否真实、可复现、重复、已实现、属于配置问题，或是否适合后续处理时使用。

在隔离范围内，通过所属 Native 或 Classic workflow、匹配风险的测试、生成 Runtime 检查和谨慎交付，实施已确认的 Comet GitHub Issue 或 review 阻塞项。用户明确要求修复已验证的 Issue 或 PR 问题时使用。

基于当前代码库，将本地 Comet 想法、观察到的回归或改进提案整理为聚焦的 GitHub Issue 草稿。用户要求把本地调查转换为 Issue、后续 Issue、Bug、Feature 或维护任务时使用。

使用 PR 当前准确 head、失败 job 日志、本地复现边界和可合并状态，诊断 Comet PR 的 GitHub Actions 与覆盖率检查。PR 出现 CI 报错、Codecov 问题、过期检查或无法解释的红色 job 时使用。

在保留已确认语义、仓库结构、子模块边界和聚焦验证的前提下，同步 Comet 中英文文档、README、Skill、发布说明和网站页面。文档变更需要保持双语，或中文措辞需要英文对应版本时使用。

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when you have a spec or requirements for a multi-step task, before touching code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

Use when implementing any feature or bugfix, before writing implementation code

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when executing implementation plans with independent tasks in the current session

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.

Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.

Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.

Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.

Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.