comet

Use when Comet must decide whether a bounded semantic review packet contains a personal memory worth creating, updating, forgetting, or skipping.

Comet Native workflow. Use when the user explicitly invokes /comet-native, asks to start or resume a Native change, or the entry routes to Native.

Create a Classic change, clarify its requirements, and obtain user confirmation. Use when the user invokes /comet-open or Classic enters Open or resumes initialization.

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.

Comet workflow entry. Use when the user invokes /comet or asks to use Comet without choosing Native or Classic; load Native or Classic from project configuration.

Create or upgrade a Comet Classic workflow Skill via Comet Creator. Not for general Skill authoring, cleanup, or review.

Archive and deliver a Classic change. Use when the user invokes /comet-archive or Classic Runtime enters Archive or resumes delivery.

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

Plan, implement, and accept Classic tasks. Use when the user invokes /comet-build or Classic Runtime enters Build or returns to Build for repairs.

Comet Classic workflow entry. Use when the user explicitly invokes /comet-classic, asks to start or resume Classic, or resume-probe returns auto_resume for one unambiguously recoverable active Classic change.

Complete the Classic technical design and obtain user confirmation. Use when the user invokes /comet-design or Classic Runtime enters Design.

将 Comet GitHub 维护请求路由到基于证据的 PR 审阅、Issue 分诊、本地想法收集、CI 诊断或 Issue 实施流程。用户提到 Comet GitHub Issue/PR 但未指定流程，或询问下一步如何处理时使用。

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

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

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

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

以只读、证据优先的方式审阅 Comet 社区 PR，包括最新 diff、关联 Issue、review thread 状态、可合并性和 CI。用户要求审阅 PR、判断评论是否仍然有效，或准备简洁的合并阻塞评论时使用。

Use the Classic preset to repair a localized defect. Use when the user explicitly invokes /comet-hotfix, selects hotfix, or resumes workflow: hotfix.

根据真实版本和分支范围准备 Comet 发布或发布说明更新，保持 Changelog 面向用户、双语网站文档一致、生成资产已验证，并明确 Git 交付边界。Beta、hotfix、版本检查、发布说明或发布就绪检查时使用。

Manually review the implementation diff for the current Comet change. Report correctness, security, and edge-case issues without advancing the workflow.

通过区分过期配置与源码缺陷，并执行真实打包 Runtime 路径，诊断 Comet Hook、安装、路由、平台、生成 Runtime 或生命周期行为。Hook 或安装报告可能涉及配置、生成资产漂移、不支持的平台或跨项目归属问题时使用。

在保护无关脏改动、关联 worktree、子模块和用户明确边界的前提下，提交、推送、合并或完成范围明确的 Comet 变更。用户要求提交、推送、合并回目标分支、清理 worktree 或交付已准备好的改动时使用。

Use the Classic preset for a lightweight adjustment within one change. Use when the user explicitly invokes /comet-tweak, selects tweak, or resumes workflow: tweak.

Verify a Classic change and record the results. Use when the user invokes /comet-verify or Classic Runtime enters Verify.

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

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

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

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Archive multiple completed changes at once. Use when archiving several parallel changes.

Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.

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.

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.

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.

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

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.

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.

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

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 completing tasks, implementing major features, or before merging to verify work meets requirements

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

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

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

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 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 you have a spec or requirements for a multi-step task, before touching code

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