[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-78882":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":22,"archived":23,"fork":23,"defaultBranch":24,"hasWiki":25,"hasPages":23,"topics":26,"createdAt":10,"pushedAt":10,"updatedAt":27,"readmeContent":28,"aiSummary":29,"trendingCount":16,"starSnapshotCount":16,"syncStatus":30,"lastSyncTime":31,"discoverSource":32},78882,"comet","rpamis\u002Fcomet","rpamis","Comet: agent skill harness phase-guarded automation from idea to archive","",null,"TypeScript",1117,129,5,17,0,58,420,1032,315,104.34,"MIT License",false,"master",true,[],"2026-06-12 04:01:24","\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Frpamis\u002Fcomet\u002Fblob\u002Fmaster\u002Fimg\u002Ftitle-log.png\">\n    \u003Cpicture>\n      \u003Csource srcset=\"https:\u002F\u002Fgithub.com\u002Frpamis\u002Fcomet\u002Fblob\u002Fmaster\u002Fimg\u002Ftitle-log.png\">\n      \u003Cimg src=\"https:\u002F\u002Fgithub.com\u002Frpamis\u002Fcomet\u002Fblob\u002Fmaster\u002Fimg\u002Ftitle-log.png\" alt=\"Comet logo\">\n    \u003C\u002Fpicture>\n  \u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Frpamis\u002Fcomet\u002Factions\u002Fworkflows\u002Fci.yml\">\u003Cimg alt=\"CI\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Factions\u002Fworkflow\u002Fstatus\u002Frpamis\u002Fcomet\u002Fci.yml?branch=master&style=flat-square&label=CI\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fdeepwiki.com\u002Frpamis\u002Fcomet\">\u003Cimg alt=\"DeepWiki\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FDeepWiki-rpamis%2Fcomet-blue?style=flat-square\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@rpamis\u002Fcomet\">\u003Cimg alt=\"npm version\" src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fv\u002F@rpamis\u002Fcomet?style=flat-square\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@rpamis\u002Fcomet\">\u003Cimg alt=\"npm download count\" src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fdm\u002F@rpamis\u002Fcomet?style=flat-square&label=Downloads\u002Fmo\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@rpamis\u002Fcomet\">\u003Cimg alt=\"npm weekly download count\" src=\"https:\u002F\u002Fimg.shields.io\u002Fnpm\u002Fdw\u002F@rpamis\u002Fcomet?style=flat-square&label=Downloads\u002Fwk\" \u002F>\u003C\u002Fa>\n  \u003Ca href=\".\u002FLICENSE\">\u003Cimg alt=\"License: MIT\" src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002FLicense-MIT-blue.svg?style=flat-square\" \u002F>\u003C\u002Fa>\n\u003C\u002Fp>\n\n# @rpamis\u002Fcomet\n\n```\n ██████╗ ██████╗ ███╗   ███╗███████╗████████╗\n██╔════╝██╔═══██╗████╗ ████║██╔════╝╚══██╔══╝\n██║     ██║   ██║██╔████╔██║█████╗     ██║\n██║     ██║   ██║██║╚██╔╝██║██╔══╝     ██║\n╚██████╗╚██████╔╝██║ ╚═╝ ██║███████╗   ██║\n ╚═════╝ ╚═════╝ ╚═╝     ╚═╝╚══════╝   ╚═╝\n```\n\n> 中文版：[README-zh.md](README-zh.md)\n> [B站视频介绍](https:\u002F\u002Fwww.bilibili.com\u002Fvideo\u002FBV1y4Gi6CEo1\u002F?spm_id_from=333.1387.homepage.video_card.click&vd_source=d22726fe6b108647dbebf1c5d8817377)\n\n**OpenSpec + Superpowers dual-star development workflow** — one command from idea to archive.\n\nOpenSpec handles **WHAT** (outlines, proposals, spec lifecycle, archiving). \n\nSuperpowers handles **HOW** (technical design, planning, execution, wrap-up). \n\nComet chains both into a five-phase automated pipeline.\n\n## Why Comet\n\nOpenSpec excels at managing requirements, creating proposals, managing Spec lifecycles, and archiving, but its proposals and tasks lack the detail of Superpowers brainstorming.\n\nSuperpowers generates Spec documents after brainstorming, but these documents typically lack stateful design — after completing requirements, Specs only have tasks checked off in the document, and Agents even forget to check them off. This causes the Agent to re-examine documents and project code to verify on resumption, wasting many tokens.\n\n**Comet combines the strengths of both**, integrating the core workflow into 5 phases\n\nThe main entry `\u002Fcomet` supports current Spec state detection, suitable for long tasks — after completing and closing CC midway, just `\u002Fcomet continue` and Comet will automatically read the active Spec (lists multiple for selection), dynamically identify which phase is currently executing, and continue.\n\nAt the same time, Comet provides full Spec lifecycle management. During execution, it links OpenSpec change\u002Fspec artifacts with Superpowers design and planning documents, then automates handoff, state updates, validation, and archive sync so users do not have to repeatedly remind the Agent to keep documents synchronized and connected.\n\n## What You'll Learn\n\nMany excellent Skill projects exist in the current Skill market, but they generally have preference issues — users may only like some features. For example, when using both OpenSpec and Superpowers, one might only use OpenSpec's Spec management capabilities, but prefer Superpowers' TDD-driven approach for coding.\n\nLong-term Skill users know these capabilities can be freely combined, but exactly how to do so still requires real practice. The Comet project can serve as a reference:\n\n- **How to reliably trigger nested Skills** — Not letting the Agent rely on document descriptions to perform \"look-alike Skill trigger\" operations (like writing files based on Skill descriptions), but truly triggering Skills (key feature: Skill trigger prints on CC). Comet triggers many capabilities from OpenSpec and Superpowers. How is this Prompt written?\n\n- **How to make combined Skills flow automatically across phases** — Not relying on manual intervention. Comet's 5-phase flow can automatically trigger Skills for the core process except for necessary user choices, while the state machine also protects state transition reliability.\n\n- **How to turn the Spec lifecycle into a resumable workflow** — Comet links OpenSpec change\u002Fspec artifacts with Superpowers design and planning documents, then records phase, execution mode, verification results, and archive status in `.comet.yaml`, so the Agent can resume after interruption instead of rereading documents and guessing progress.\n\n- **How to turn document synchronization from \"user reminders\" into automation** — Comet puts handoff, state updates, validation, and archive sync into scripted flows, reducing repeated prompts like \"remember to update the design doc\", \"remember to sync the spec\", and \"remember to archive the change\".\n\n- **How to design guard conditions that Agents can execute** — Comet does not simply trust the Agent saying \"done\" at phase exits. Scripts such as `comet-guard.sh`, `comet-yaml-validate.sh`, and `comet-state.sh` check tasks, state fields, verification evidence, and archive conditions before allowing the workflow to advance.\n\n- **How to distribute and install Skills across platforms** — Comet supports multiple AI coding platforms, project\u002Fglobal installation, Chinese\u002FEnglish Skill choices, and platform-specific directory differences such as Antigravity using different project-level and global paths. It can be a reference for CLI installers and Skill package structure.\n\n- **How to turn shell scripts into Agent workflow infrastructure** — Comet's scripts need to work across macOS, Linux, and Windows Git Bash while handling hashes, YAML fields, state machines, and archive flows. It shows how to move fragile workflow control out of scattered Prompt text and into testable, reusable tools.\n\n## Install\n\n```bash\nnpm install -g @rpamis\u002Fcomet\n```\n\n## Quick Start\n\n```bash\ncd your-project\ncomet init\n```\n\n`comet init` will:\n\n1. Prompt you to select AI platforms (auto-detects existing configs)\n2. Choose install scope: project-level (current directory) or global (home directory)\n3. Select language for Comet skills: English or 中文\n4. Install [OpenSpec](https:\u002F\u002Fgithub.com\u002FFission-AI\u002FOpenSpec) skills\n5. Install [Superpowers](https:\u002F\u002Fgithub.com\u002Fobra\u002Fsuperpowers) skills\n6. Deploy Comet skills (in your chosen language) to selected platforms\n7. Create `docs\u002Fsuperpowers\u002Fspecs\u002F` and `docs\u002Fsuperpowers\u002Fplans\u002F` working directories for project-scope installs\n\n> [!TIP]\n> update version\n>\n> `comet update` or `npm install -g @rpamis\u002Fcomet@latest` to get the latest features and fixes.\n\n## Support for OpenClaw and Hermes, and other AI platforms\n\n```bash\nnpx skills add rpamis\u002Fcomet\n```\n\n## Screenshots\n\n\u003Cp align=\"center\">\n  \u003Cimg src=\"https:\u002F\u002Fgithub.com\u002Frpamis\u002Fcomet\u002Fblob\u002Fmaster\u002Fimg\u002Frunner.png\" alt=\"runner\">\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">Auto-install OpenSpec & Superpowers, one-click dev environment setup\u003C\u002Fp>\n\u003Cp align=\"center\">Multi-phase Skill entry, auto-detects current Spec stage, auto-triggers core flow, manual review at key nodes\u003C\u002Fp>\n\n## Commands\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>comet init [path]\u003C\u002Fcode> — Initialize Comet workflow\u003C\u002Fsummary>\n\nInitializes OpenSpec, Superpowers, and Comet skills for selected AI coding platforms.\n\n| Option | Description |\n|--------|-------------|\n| `--yes` | Non-interactive mode, auto-select detected platforms (or all if none detected) |\n| `--scope \u003Cscope>` | Install scope: `project` or `global` |\n| `--skip-existing` | Skip already installed components |\n| `--overwrite` | Overwrite already installed components |\n| `--json` | Output structured JSON |\n\nWhen multiple existing components are found on the same platform, interactive init offers one bulk choice: overwrite all, skip all, or choose per component.\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>comet status [path]\u003C\u002Fcode> — Show active changes and next workflow command\u003C\u002Fsummary>\n\nDisplays active changes, task progress, and the recommended next Comet workflow command.\n\n| Option | Description |\n|--------|-------------|\n| `--json` | Output active changes with `nextCommand` |\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>comet doctor [path]\u003C\u002Fcode> — Diagnose Comet installation health\u003C\u002Fsummary>\n\nChecks project\u002Fglobal installation health, working directories, installed skills, scripts, and Comet state files.\n\n| Option | Description |\n|--------|-------------|\n| `--json` | Output structured diagnostic results |\n| `--scope \u003Cscope>` | Diagnose `auto`, `project`, or `global` scope (default: `auto`) |\n\n\u003C\u002Fdetails>\n\n\u003Cdetails>\n\u003Csummary>\u003Ccode>comet update [path]\u003C\u002Fcode> — Update Comet package and skills\u003C\u002Fsummary>\n\nUpdates the npm package and refreshes installed Comet skills in detected project\u002Fglobal targets.\n\n| Option | Description |\n|--------|-------------|\n| `--json` | Output npm and skill update results as JSON |\n| `--language \u003Clang>` | Override detected skill language (`en`, `zh`) |\n| `--scope \u003Cscope>` | Update only `global` or `project` scope |\n\n\u003C\u002Fdetails>\n\n| Command | Description |\n|---------|-------------|\n| `comet --help` | Show help |\n| `comet --version` | Show version |\n\n## Supported Platforms\n\n`comet init` supports 28 AI coding platforms:\n\n\u003Cdetails>\n\u003Csummary>View full platform list\u003C\u002Fsummary>\n\n| Platform | Skills Dir | Platform | Skills Dir |\n|----------|-----------|----------|-----------|\n| Claude Code | `.claude\u002F` | Cursor | `.cursor\u002F` |\n| Codex | `.codex\u002F` | OpenCode | `.opencode\u002F` |\n| Windsurf | `.windsurf\u002F` | Cline | `.cline\u002F` |\n| RooCode | `.roo\u002F` | Continue | `.continue\u002F` |\n| GitHub Copilot | `.github\u002F` | Gemini CLI | `.gemini\u002F` |\n| Amazon Q Developer | `.amazonq\u002F` | Qwen Code | `.qwen\u002F` |\n| Kilo Code | `.kilocode\u002F` | Auggie | `.augment\u002F` |\n| Kiro | `.kiro\u002F` | Lingma | `.lingma\u002F` |\n| Junie | `.junie\u002F` | CodeBuddy | `.codebuddy\u002F` |\n| CoStrict | `.cospec\u002F` | Crush | `.crush\u002F` |\n| Factory Droid | `.factory\u002F` | iFlow | `.iflow\u002F` |\n| Pi | `.pi\u002F` | Qoder | `.qoder\u002F` |\n| Antigravity | `.agents\u002F` | Bob Shell | `.bob\u002F` |\n| ForgeCode | `.forge\u002F` | Trae | `.trae\u002F` |\n\n\u003C\u002Fdetails>\n\n## Skills\n\nAfter `comet init`, three groups of skills are installed to the selected platform's `skills\u002F` directory:\n\n### Comet Skills\n\n\u003Cdetails>\n\u003Csummary>View Comet skills\u003C\u002Fsummary>\n\n| Skill | Description |\n|-------|-------------|\n| `\u002Fcomet` | Main entry — auto-detects phase and dispatches to sub-commands |\n| `\u002Fcomet-open` | Phase 1: Open a change (proposal, design, task breakdown) |\n| `\u002Fcomet-design` | Phase 2: Deep design (brainstorming, Design Doc) |\n| `\u002Fcomet-build` | Phase 3: Plan and build (implementation plan, code commits) |\n| `\u002Fcomet-verify` | Phase 4: Verify and finish (testing, verification report) |\n| `\u002Fcomet-archive` | Phase 5: Archive (delta spec sync, status annotation) |\n| `\u002Fcomet-hotfix` | Preset: Quick bug fix (skips brainstorming) |\n| `\u002Fcomet-tweak` | Preset: Small change (skips brainstorming and full plan) |\n\n\u003C\u002Fdetails>\n\n### Guard & Automation Scripts\n\n\u003Cdetails>\n\u003Csummary>View script list\u003C\u002Fsummary>\n\n| Script | Purpose |\n|--------|---------|\n| `comet-guard.sh` | Phase transition guard — validates exit conditions, `--apply` auto-updates `.comet.yaml` |\n| `comet-handoff.sh` | Design handoff — generates deterministic context packages from OpenSpec artifacts with SHA256 tracing |\n| `comet-archive.sh` | One-command archive — validates state, syncs specs, moves to archive, updates status |\n| `comet-yaml-validate.sh` | Schema validator — validates `.comet.yaml` structure and field values |\n| `comet-state.sh` | Unified state management — init\u002Fset\u002Fget\u002Fcheck\u002Fscale, agents' exclusive YAML interface |\n\n\u003C\u002Fdetails>\n\n### OpenSpec Skills\n\nSpec lifecycle management: propose, explore, sync, verify, archive, and more.\n\n### Superpowers Skills\n\nDevelopment methodology: brainstorming, TDD, subagent-driven development, code review, plan writing, and more.\n\n## Workflow\n\n```\n\u002Fcomet\n  ↓ auto-detect\n\u002Fcomet-open  -->  \u002Fcomet-design  -->  \u002Fcomet-build  -->  \u002Fcomet-verify  -->  \u002Fcomet-archive\n(OpenSpec)         (Superpowers)       (Superpowers)       (Both)           (OpenSpec)\n\n\u002Fcomet-hotfix (preset path, skips brainstorming)\n  open  -->  build  -->  verify  -->  archive\n\n\u002Fcomet-tweak (preset path, skips brainstorming and full plan)\n  open  -->  lightweight build  -->  light verify  -->  archive\n```\n\n### Five Phases\n\n| Phase | Command | Owner | Artifacts |\n|-------|---------|-------|-----------|\n| 1. Open | `\u002Fcomet-open` | OpenSpec | proposal.md, design.md, tasks.md |\n| 2. Deep Design | `\u002Fcomet-design` | Superpowers | Design Doc, delta spec |\n| 3. Plan & Build | `\u002Fcomet-build` | Superpowers | Implementation plan, code commits |\n| 4. Verify & Finish | `\u002Fcomet-verify` | Both | Verification report, branch handling |\n| 5. Archive | `\u002Fcomet-archive` | OpenSpec | delta→main spec sync, archive |\n\n### Core Principles\n\n- **Brainstorming is non-skippable** — every change must go through deep design (except hotfix\u002Ftweak)\n- **Delta specs are living documents** — freely editable during Phase 3, synced at archive\n- **Keep tasks.md in sync** — check off each task as completed\n- **Commit frequently** — one commit per task, message reflects design intent\n- **Verify before archive** — `\u002Fcomet-verify` must pass before `\u002Fcomet-archive`\n\n### State Management\n\nComet uses a decoupled state architecture with separate YAML files:\n\n| File | Owner | Purpose |\n|------|-------|---------|\n| `.openspec.yaml` | OpenSpec | Spec lifecycle, change metadata |\n| `.comet.yaml` | Comet | Workflow phase, execution mode, verification status |\n\nAll states and execution phases are updated via scripts, and each phase verifies that tasks are truly complete before advancing. Compared to storing complex state rules only in Skill text, this script-backed state machine gives Comet more reliable phase transitions, correct YAML, and easier breakpoint recovery; agents can read the current Spec situation through Comet's built-in commands.\n\n\u003Cdetails>\n\u003Csummary>View key .comet.yaml fields\u003C\u002Fsummary>\n\n**Key Fields in `.comet.yaml`:**\n\n```yaml\nworkflow: full\nphase: build\nbuild_mode: subagent-driven-development\nisolation: branch\nverify_mode: null\ndesign_doc: docs\u002Fsuperpowers\u002Fspecs\u002FYYYY-MM-DD-topic-design.md\nplan: docs\u002Fsuperpowers\u002Fplans\u002FYYYY-MM-DD-feature.md\nverify_result: pending\nverification_report: null\nbranch_status: pending\nverified_at: null\narchived: false\ndirect_override: false\nbuild_command: null\nverify_command: null\nhandoff_context: openspec\u002Fchanges\u002F\u003Cname>\u002F.comet\u002Fhandoff\u002Fdesign-context.json\nhandoff_hash: \u003Csha256>\n```\n\nIn full workflow, `build_mode`, `isolation`, and `verify_mode` may temporarily be `null`; `build_mode` and `isolation` must be resolved before `build → verify`. `verification_report` stays `null` until verification writes a report, and `verify-pass` requires that report to exist plus `branch_status: handled`. Fields after `archived` in the example are optional or script-derived: `direct_override` is only needed for full-workflow direct builds, project commands may be absent unless configured, and `handoff_context` \u002F `handoff_hash` are recorded by `comet-handoff.sh` before leaving design. Projects can configure `build_command` \u002F `verify_command` in the change or repo root, and guard will run those commands first and print failure output.\n\n\u003C\u002Fdetails>\n\n### Reliability Features\n\nComet ensures agent execution reliability through automated state transitions:\n\n\u003Cdetails>\n\u003Csummary>View reliability features\u003C\u002Fsummary>\n\n1. **Entry Verification** — Each phase validates preconditions before execution\n   - Checks file existence, state consistency, and phase transitions\n   - Outputs `[HARD STOP]` with actionable suggestions if validation fails\n\n2. **Automated State Transitions** — `comet-guard.sh --apply` updates `.comet.yaml` automatically\n   - All phase transitions (open → design\u002Fbuild → verify → archive) use `guard --apply`\n   - No manual state editing required — eliminates write-verification errors\n   - `comet-state.sh` is the agents' exclusive interface for state operations\n   - Guard and archive scripts use `comet-state.sh` internally for state management\n\n3. **Schema Validation** — `comet-yaml-validate.sh` ensures data integrity\n   - Validates required and optional fields\n   - Validates enum values, including `direct_override`\n   - Validates `design_doc`, `plan`, and `handoff_context` paths exist, plus `handoff_hash` format\n   - Detects unknown\u002Ftypos fields\n\n4. **Build Decision Enforcement** — Guard and state transitions both block skipped build choices\n   - `isolation` must be `branch` or `worktree`\n   - `build_mode` must be selected before leaving build\n   - Full workflow `build_mode: direct` requires `direct_override: true`\n\n5. **Verification Evidence** — Guard enforces proof before phase advance\n   - `verify-pass` transition requires `verification_report` pointing to an existing report file\n   - `branch_status` must be `handled` before verify can pass\n   - Guard checks `verification_report exists` and `branch_status=handled` as hard prerequisites\n   - Prevents false phase advances when verification or branch handling was skipped\n\n6. **Archive Automation** — `comet-archive.sh` handles the full archive flow in one command\n   - Validates entry state, syncs delta specs to main specs\n   - Annotates design doc and plan frontmatter\n   - Moves change to archive directory and updates `archived: true`\n   - Supports `--dry-run` for preview\n\n\u003C\u002Fdetails>\n\n## Project Structure\n\n```\nyour-project\u002F\n├── .claude\u002Fskills\u002F              # Platform skills dir (Comet + OpenSpec + Superpowers)\n│   ├── comet\u002FSKILL.md\n│   │   └── scripts\u002F\n│   │       ├── comet-guard.sh       # Phase transition guard (--apply auto-updates state)\n│   │       ├── comet-handoff.sh     # Design handoff (OpenSpec → Superpowers context tracing)\n│   │       ├── comet-archive.sh     # One-command archive automation\n│   │       ├── comet-yaml-validate.sh # Schema validator\n│   │       └── comet-state.sh       # Unified state management (init\u002Fset\u002Fget\u002Fcheck\u002Fscale)\n│   ├── comet-*\u002FSKILL.md\n│   ├── openspec-*\u002FSKILL.md\n│   └── brainstorming\u002FSKILL.md\n├── openspec\u002F                    # OpenSpec — WHAT\n│   ├── config.yaml\n│   └── changes\u002F\n│       └── \u003Cname>\u002F\n│           ├── .openspec.yaml       # OpenSpec state\n│           ├── .comet.yaml          # Comet workflow state (decoupled)\n│           ├── proposal.md\n│           ├── design.md\n│           ├── specs\u002F\u003Ccapability>\u002Fspec.md\n│           └── tasks.md\n└── docs\u002Fsuperpowers\u002F            # Superpowers — HOW\n    ├── specs\u002F                   # Design documents\n    └── plans\u002F                   # Implementation plans\n```\n\n## Development\n\nSee [CONTRIBUTING.md](CONTRIBUTING.md) for development setup, commit conventions, PR process, and guidance for adding platforms or skills.\n\nSee [CHANGELOG.md](CHANGELOG.md) for version history and updates.\n\n## Roadmap\n\nTrack our development progress and upcoming features on the [Comet Roadmap](https:\u002F\u002Fgithub.com\u002Forgs\u002Frpamis\u002Fprojects\u002F1).\n\n## Star History\n\n[![Star History Chart](https:\u002F\u002Fapi.star-history.com\u002Fsvg?repos=rpamis\u002Fcomet&type=Date)](https:\u002F\u002Fstar-history.com\u002F#rpamis\u002Fcomet&Date)\n\n## License\n\n[MIT](LICENSE.md)\n\n## Reference\n[LINUX DO - 新的理想型社区](https:\u002F\u002Flinux.do\u002F)\n","Comet 是一个基于 OpenSpec 和 Superpowers 的双星开发工作流工具，旨在通过一条命令实现从想法到归档的全流程自动化。其核心功能包括使用 OpenSpec 管理需求、提案、规范生命周期及归档；Superpowers 则负责技术设计、计划执行与总结。Comet 通过将两者结合，形成一个五阶段自动化的管道，有效解决了单独使用任一工具时面临的细节缺失和状态管理问题。适用于需要高效协作且注重文档与代码同步更新的软件开发场景，特别适合处理周期较长的任务。",2,"2026-06-11 03:57:15","CREATED_QUERY"]