@rpamis/comet 0.3.7 → 0.3.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -21
- package/README.md +559 -539
- package/assets/manifest.json +41 -34
- package/assets/skills/comet/SKILL.md +282 -329
- package/assets/skills/comet/reference/auto-transition.md +27 -0
- package/assets/skills/comet/reference/comet-yaml-fields.md +68 -0
- package/assets/skills/comet/reference/context-recovery.md +35 -0
- package/assets/skills/comet/reference/debug-gate.md +17 -0
- package/assets/skills/comet/reference/decision-point.md +20 -0
- package/assets/skills/comet/reference/file-structure.md +28 -0
- package/assets/skills/comet/reference/subagent-dispatch.md +113 -0
- package/assets/skills/comet/rules/comet-phase-guard.en.md +99 -0
- package/assets/skills/comet/rules/comet-phase-guard.md +99 -90
- package/assets/skills/comet/scripts/comet-state.sh +62 -0
- package/assets/skills/comet-archive/SKILL.md +100 -106
- package/assets/skills/comet-build/SKILL.md +304 -316
- package/assets/skills/comet-design/SKILL.md +263 -272
- package/assets/skills/comet-hotfix/SKILL.md +204 -211
- package/assets/skills/comet-open/SKILL.md +203 -186
- package/assets/skills/comet-tweak/SKILL.md +180 -179
- package/assets/skills/comet-verify/SKILL.md +234 -240
- package/assets/skills-zh/comet/SKILL.md +269 -332
- package/assets/skills-zh/comet/reference/auto-transition.md +27 -0
- package/assets/skills-zh/comet/reference/comet-yaml-fields.md +68 -0
- package/assets/skills-zh/comet/reference/context-recovery.md +35 -0
- package/assets/skills-zh/comet/reference/debug-gate.md +17 -0
- package/assets/skills-zh/comet/reference/decision-point.md +20 -0
- package/assets/skills-zh/comet/reference/file-structure.md +28 -0
- package/assets/skills-zh/comet/reference/subagent-dispatch.md +113 -0
- package/assets/skills-zh/comet-archive/SKILL.md +100 -106
- package/assets/skills-zh/comet-build/SKILL.md +304 -316
- package/assets/skills-zh/comet-design/SKILL.md +264 -273
- package/assets/skills-zh/comet-hotfix/SKILL.md +200 -207
- package/assets/skills-zh/comet-open/SKILL.md +203 -186
- package/assets/skills-zh/comet-tweak/SKILL.md +176 -175
- package/assets/skills-zh/comet-verify/SKILL.md +232 -238
- package/bin/comet.js +3 -3
- package/dist/cli/index.js +19 -0
- package/dist/cli/index.js.map +1 -1
- package/dist/commands/init.d.ts.map +1 -1
- package/dist/commands/init.js +8 -8
- package/dist/commands/init.js.map +1 -1
- package/dist/commands/uninstall.d.ts +9 -0
- package/dist/commands/uninstall.d.ts.map +1 -0
- package/dist/commands/uninstall.js +113 -0
- package/dist/commands/uninstall.js.map +1 -0
- package/dist/commands/update.d.ts +1 -1
- package/dist/commands/update.d.ts.map +1 -1
- package/dist/commands/update.js +65 -36
- package/dist/commands/update.js.map +1 -1
- package/dist/core/codegraph.d.ts +2 -7
- package/dist/core/codegraph.d.ts.map +1 -1
- package/dist/core/codegraph.js +4 -37
- package/dist/core/codegraph.js.map +1 -1
- package/dist/core/detect.d.ts +8 -1
- package/dist/core/detect.d.ts.map +1 -1
- package/dist/core/detect.js +41 -2
- package/dist/core/detect.js.map +1 -1
- package/dist/core/openspec.d.ts +1 -1
- package/dist/core/openspec.d.ts.map +1 -1
- package/dist/core/openspec.js +40 -17
- package/dist/core/openspec.js.map +1 -1
- package/dist/core/platforms.d.ts.map +1 -1
- package/dist/core/platforms.js +14 -1
- package/dist/core/platforms.js.map +1 -1
- package/dist/core/skills.d.ts +3 -1
- package/dist/core/skills.d.ts.map +1 -1
- package/dist/core/skills.js +142 -65
- package/dist/core/skills.js.map +1 -1
- package/dist/core/superpowers.d.ts.map +1 -1
- package/dist/core/superpowers.js +1 -0
- package/dist/core/superpowers.js.map +1 -1
- package/dist/core/uninstall.d.ts +28 -0
- package/dist/core/uninstall.d.ts.map +1 -0
- package/dist/core/uninstall.js +421 -0
- package/dist/core/uninstall.js.map +1 -0
- package/dist/core/version.d.ts +31 -0
- package/dist/core/version.d.ts.map +1 -0
- package/dist/core/version.js +111 -0
- package/dist/core/version.js.map +1 -0
- package/dist/utils/file-system.d.ts +23 -0
- package/dist/utils/file-system.d.ts.map +1 -1
- package/dist/utils/file-system.js +100 -5
- package/dist/utils/file-system.js.map +1 -1
- package/package.json +69 -64
- package/scripts/postinstall.js +44 -44
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Automatic Handoff to Next Phase Protocol
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/auto-transition.md`
|
|
4
|
+
|
|
5
|
+
This protocol is shared by all comet sub-skills. It defines the automatic handoff rules after phase guard advancement.
|
|
6
|
+
|
|
7
|
+
## Terminology Distinction
|
|
8
|
+
|
|
9
|
+
"Phase advancement" is performed by guard `--apply`, which updates the `phase` field in `.comet.yaml` — this **always happens** and is independent of `auto_transition`. This protocol's "automatic handoff" only determines **whether to automatically invoke the next skill**, controlled by `auto_transition`.
|
|
10
|
+
|
|
11
|
+
## Execution
|
|
12
|
+
|
|
13
|
+
After exit conditions are met and the phase guard has advanced phase, run:
|
|
14
|
+
|
|
15
|
+
```bash
|
|
16
|
+
"$COMET_BASH" "$COMET_STATE" next <change-name>
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
The script outputs a deterministic next step based on `phase`, `workflow`, and `auto_transition`:
|
|
20
|
+
|
|
21
|
+
- `NEXT: auto` → invoke the skill pointed to by `SKILL` to enter the next phase
|
|
22
|
+
- `NEXT: manual` → do not invoke the next skill; prompt user to manually run `/<SKILL>` per `HINT`
|
|
23
|
+
- `NEXT: done` → workflow is complete, no further action needed
|
|
24
|
+
|
|
25
|
+
## Preset Routing
|
|
26
|
+
|
|
27
|
+
When `workflow: hotfix`, `phase: build` returns `comet-hotfix`; when `workflow: tweak`, it returns `comet-tweak`. All other phases (`verify`, `archive`) return standard skill names (`comet-verify`, `comet-archive`) regardless of workflow type. The "continuous execution mode" within preset skills may override `auto_transition` behavior — see the corresponding preset's `<IMPORTANT>` block.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
# .comet.yaml Field Reference
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/comet-yaml-fields.md`
|
|
4
|
+
|
|
5
|
+
This file is the field reference for the `.comet.yaml` state file. Consult on demand; not loaded inline with skills.
|
|
6
|
+
|
|
7
|
+
## Example
|
|
8
|
+
|
|
9
|
+
```yaml
|
|
10
|
+
workflow: full
|
|
11
|
+
phase: build
|
|
12
|
+
design_doc: docs/superpowers/specs/YYYY-MM-DD-topic-design.md
|
|
13
|
+
plan: docs/superpowers/plans/YYYY-MM-DD-feature.md
|
|
14
|
+
base_ref: a1b2c3d4e5f6...
|
|
15
|
+
build_mode: subagent-driven-development
|
|
16
|
+
build_pause: null
|
|
17
|
+
subagent_dispatch: confirmed
|
|
18
|
+
tdd_mode: tdd
|
|
19
|
+
isolation: branch
|
|
20
|
+
verify_mode: light
|
|
21
|
+
verify_result: pending
|
|
22
|
+
verification_report: null
|
|
23
|
+
branch_status: pending
|
|
24
|
+
created_at: 2026-05-26
|
|
25
|
+
verified_at: null
|
|
26
|
+
archived: false
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## Required Fields
|
|
30
|
+
|
|
31
|
+
| Field | Meaning |
|
|
32
|
+
|-------|---------|
|
|
33
|
+
| `workflow` | `full`, `hotfix`, or `tweak` |
|
|
34
|
+
| `phase` | Current phase: `open`, `design`, `build`, `verify`, `archive` (init sets `open`; guard handles transitions) |
|
|
35
|
+
| `design_doc` | Associated Superpowers Design Doc path; may be empty |
|
|
36
|
+
| `plan` | Associated Superpowers Plan path; may be empty |
|
|
37
|
+
| `base_ref` | Git commit SHA recorded at init for scale assessment. Used as baseline for changed-file counting when no plan exists |
|
|
38
|
+
| `build_mode` | Selected execution mode; may be empty |
|
|
39
|
+
| `build_pause` | Build phase internal pause point. `null` = no pause, `plan-ready` = plan generated, paused for user model switch |
|
|
40
|
+
| `subagent_dispatch` | `null` or `confirmed`. Only when the platform's real background subagent/Task/multi-agent dispatch capability is confirmed may `build_mode: subagent-driven-development` be written and used to leave the build phase |
|
|
41
|
+
| `tdd_mode` | `tdd` or `direct`. Full workflow must select before leaving build. `tdd` forces write-failing-test-first per task; `direct` skips TDD enforcement. hotfix/tweak default to `direct` |
|
|
42
|
+
| `isolation` | `branch` or `worktree`, workspace isolation mode. Full init may be `null` but only until `/comet-build` Step 3; hotfix/tweak default to `branch` |
|
|
43
|
+
| `verify_mode` | `light` or `full`; may be empty |
|
|
44
|
+
| `auto_transition` | `true` or `false`. Only controls whether to automatically invoke the next skill after phase guard advances phase; `false` outputs `manual` from `comet-state next`, pausing next-skill invocation but not blocking phase field updates |
|
|
45
|
+
| `verify_result` | `pending`, `pass`, or `fail` |
|
|
46
|
+
| `verification_report` | Verification report file path; must point to an existing file before verify passes |
|
|
47
|
+
| `branch_status` | `pending` or `handled`; set to `handled` after branch handling completes |
|
|
48
|
+
| `created_at` | Change creation date (auto-written at init), format `YYYY-MM-DD` |
|
|
49
|
+
| `verified_at` | Verification pass timestamp; may be empty |
|
|
50
|
+
| `archived` | Whether the change has been archived |
|
|
51
|
+
|
|
52
|
+
## Optional Fields
|
|
53
|
+
|
|
54
|
+
| Field | Meaning |
|
|
55
|
+
|-------|---------|
|
|
56
|
+
| `direct_override` | `true`/`false`. Full workflow must explicitly set to `true` to use `build_mode: direct` |
|
|
57
|
+
| `build_command` | Project build command. Guard runs this first; prints command output on failure |
|
|
58
|
+
| `verify_command` | Project verify command. Verify guard runs this first; falls back to build command when unset |
|
|
59
|
+
|
|
60
|
+
## State Machine Hard Constraints
|
|
61
|
+
|
|
62
|
+
- Before `build → verify`, `isolation` must be `branch` or `worktree`
|
|
63
|
+
- Before `build → verify`, `build_mode` must be selected
|
|
64
|
+
- `build_mode: subagent-driven-development` requires `subagent_dispatch: confirmed`
|
|
65
|
+
- Full workflow must select `tdd_mode` as `tdd` or `direct` before leaving build
|
|
66
|
+
- `build_mode: direct` defaults to `hotfix`/`tweak` only; full workflow requires `direct_override: true`
|
|
67
|
+
- `build_pause` is not an execution mode; must not be written to `build_mode`
|
|
68
|
+
- These constraints exist in both `comet-guard.sh build --apply` and `comet-state.sh transition <name> build-complete`
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# Context Compression Recovery Protocol
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/context-recovery.md`
|
|
4
|
+
|
|
5
|
+
This protocol is shared by all comet sub-skills that may trigger context compression. When the agent suspects context compression has occurred (previous conversation summarized, cannot find previously discussed content), follow this protocol to recover.
|
|
6
|
+
|
|
7
|
+
## Recovery Steps
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
"$COMET_BASH" "$COMET_STATE" check <change-name> <phase> --recover
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
The script outputs structured recovery context (phase, completed fields, pending fields, recovery action). Follow the **Recovery action** output for next steps.
|
|
14
|
+
|
|
15
|
+
## Build Phase Special Recovery
|
|
16
|
+
|
|
17
|
+
If the recovery script outputs `build_mode: subagent-driven-development`:
|
|
18
|
+
|
|
19
|
+
1. Use the Skill tool to reload the Superpowers `subagent-driven-development` skill
|
|
20
|
+
2. Re-read `comet/reference/subagent-dispatch.md` for Comet-specific extensions
|
|
21
|
+
3. Read `openspec/changes/<name>/.comet/subagent-progress.md` to recover the current task or final review, implementation commit, RED/GREEN evidence, passed reviews, unresolved feedback, and review-fix round
|
|
22
|
+
4. Do not execute tasks directly in the main session
|
|
23
|
+
5. Resume from the checkpoint's exact stage; begin implementer dispatch for the first unchecked task only when the checkpoint is missing or mismatched
|
|
24
|
+
6. After dual review and targeted checkoff verification pass, immediately continue to the next task without summarizing or asking whether to continue
|
|
25
|
+
|
|
26
|
+
## Design Phase Special Recovery
|
|
27
|
+
|
|
28
|
+
- If the user has not yet confirmed the design approach, return to brainstorming
|
|
29
|
+
- If the user has confirmed, continue creating the Design Doc
|
|
30
|
+
- On recovery, reload `brainstorm-summary.md` + handoff context files
|
|
31
|
+
|
|
32
|
+
## Verify/Archive Phase Recovery
|
|
33
|
+
|
|
34
|
+
- Verify: script outputs verification status, branch status, and recovery action
|
|
35
|
+
- Archive: if `archived: true` and archive directory exists, archival is complete — do not re-execute
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Debug Gate Protocol
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/debug-gate.md`
|
|
4
|
+
|
|
5
|
+
This protocol is shared by comet sub-skills that directly modify code, including build, hotfix, and tweak. Enter the Debug Gate when a crash, unexpected behavior, test failure, or build failure appears while running the program, tests, build, or manual verification.
|
|
6
|
+
|
|
7
|
+
## Core Rules
|
|
8
|
+
|
|
9
|
+
- Immediately use the Skill tool to load the Superpowers `systematic-debugging` skill
|
|
10
|
+
- Do not propose or implement source fixes before the root cause investigation is complete
|
|
11
|
+
|
|
12
|
+
## Four-Stage Flow
|
|
13
|
+
|
|
14
|
+
1. Reproduce and locate the root cause first by reading the full error, checking recent changes, and tracing data flow
|
|
15
|
+
2. If the root cause is a source bug, first add a minimal failing test that reproduces the crash or unexpected behavior, then modify the source
|
|
16
|
+
3. After the fix, run that failing test, related tests, and the project's build or verification commands until all pass
|
|
17
|
+
4. Keep the test, the source fix, and the tasks.md checkoff in the current change; do not replace the current change verification loop by starting a separate “write test cases” change
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Decision Point Protocol
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/decision-point.md`
|
|
4
|
+
|
|
5
|
+
This protocol is shared by all comet sub-skills that contain user decision points. Any step labeled as a blocking point or user decision point must follow this protocol.
|
|
6
|
+
|
|
7
|
+
## Core Rules
|
|
8
|
+
|
|
9
|
+
- Decision points are blocking points. Pause and wait for an explicit user choice before continuing
|
|
10
|
+
- Use the current platform's available user input or confirmation mechanism to collect the choice
|
|
11
|
+
- If the current platform has no structured question tool, ask clear options in the conversation and stop until the user replies
|
|
12
|
+
- Never substitute recommendation rules, defaults, historical preferences, or “the user would probably agree” for current confirmation
|
|
13
|
+
- Do not write state fields, execute the chosen branch, or auto-continue before the user explicitly chooses
|
|
14
|
+
|
|
15
|
+
## Minimum Presentation Requirements
|
|
16
|
+
|
|
17
|
+
- State what the current decision point is deciding
|
|
18
|
+
- Present clear options; when the user must pick one option, keep the options mutually exclusive and actionable
|
|
19
|
+
- Recommendations may explain tradeoffs, but may not replace user confirmation
|
|
20
|
+
- Only execute the corresponding commands or state updates after the user chooses
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# File Structure Reference
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/file-structure.md`
|
|
4
|
+
|
|
5
|
+
This file is the Comet project file structure reference. Consult on demand; not loaded inline with skills.
|
|
6
|
+
|
|
7
|
+
```text
|
|
8
|
+
openspec/ # OpenSpec — WHAT
|
|
9
|
+
├── config.yaml
|
|
10
|
+
├── changes/
|
|
11
|
+
│ ├── <name>/ # Active change
|
|
12
|
+
│ │ ├── .openspec.yaml
|
|
13
|
+
│ │ ├── .comet.yaml
|
|
14
|
+
│ │ ├── proposal.md # Why + What
|
|
15
|
+
│ │ ├── design.md # High-level architecture decisions
|
|
16
|
+
│ │ ├── specs/<capability>/spec.md # Delta capability spec
|
|
17
|
+
│ │ ├── .comet/handoff/ # Script-generated phase handoff packages
|
|
18
|
+
│ │ └── tasks.md # Task checklist
|
|
19
|
+
│ └── archive/YYYY-MM-DD-<name>/ # Archived
|
|
20
|
+
└── specs/<capability>/spec.md # Main specs (merged on archive via OpenSpec delta semantics)
|
|
21
|
+
|
|
22
|
+
docs/superpowers/ # Superpowers — HOW
|
|
23
|
+
├── specs/YYYY-MM-DD-<topic>-design.md # Design doc (technical RFC; annotated on archive)
|
|
24
|
+
└── plans/YYYY-MM-DD-<feature>.md # Implementation plan (file header contains change metadata)
|
|
25
|
+
|
|
26
|
+
.comet/
|
|
27
|
+
└── config.yaml # Comet project config (context_compression defaults to off; set to beta to enable)
|
|
28
|
+
```
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
# Comet Extensions for Subagent-Driven Development
|
|
2
|
+
|
|
3
|
+
Canonical path: `comet/reference/subagent-dispatch.md`
|
|
4
|
+
|
|
5
|
+
This document provides Comet-specific extensions applied **on top of** the Superpowers `subagent-driven-development` skill. The skill handles the core dispatch loop (fresh implementer per task → spec compliance review → code quality review → next task) and enforces continuous execution. This document adds Comet-specific real background dispatch, task tracking, state verification, and context recovery. If the Superpowers skill conflicts with this document, the more specific Comet constraints here take precedence.
|
|
6
|
+
|
|
7
|
+
> **⚠️ CRITICAL — No Pause Between Tasks**
|
|
8
|
+
>
|
|
9
|
+
> After a task passes both reviews and is checked off, **immediately dispatch the next task** without stopping, summarizing, or asking the user whether to continue. The user expects all tasks to execute in sequence without manual intervention. Pausing between tasks breaks the workflow and requires the user to manually resume each time.
|
|
10
|
+
>
|
|
11
|
+
> Only stop and wait for user input when:
|
|
12
|
+
> - A task is **BLOCKED** (3 review-fix rounds exhausted)
|
|
13
|
+
> - There is irreducible ambiguity that cannot be resolved from the repository, plan, or existing context
|
|
14
|
+
> - The platform lacks real background agent dispatch capability and the user must choose `executing-plans`
|
|
15
|
+
> - The user **explicitly** asks to pause
|
|
16
|
+
>
|
|
17
|
+
> This rule applies to the ENTIRE dispatch loop, not just individual tasks.
|
|
18
|
+
|
|
19
|
+
## Before Starting
|
|
20
|
+
|
|
21
|
+
1. Read the plan once, extracting the full text of all unchecked tasks in order.
|
|
22
|
+
2. Save a unique identifier for each task: the full task text after the checkbox in the plan, and the full OpenSpec task text it maps to (if any). If the text is not unique, stop and fix the plan first; never rely on "first match."
|
|
23
|
+
3. Respect dependencies; do not dispatch a task whose dependencies are not yet complete.
|
|
24
|
+
|
|
25
|
+
## Per-Task Comet Extensions
|
|
26
|
+
|
|
27
|
+
Apply these on every task, in addition to the Superpowers skill's dispatch loop:
|
|
28
|
+
|
|
29
|
+
### 0. Dispatch Enforcement (Critical)
|
|
30
|
+
|
|
31
|
+
The main session is the **coordinator only** and must NOT execute tasks directly or modify source code. The coordinator may modify only the plan, OpenSpec task, and subagent progress checkpoint for durable tracking. Never bundle multiple tasks into one agent. Dispatch a fresh background implementer agent for every task; spec reviewers, code quality reviewers, fix agents, and the final reviewer must also each use a fresh background agent:
|
|
32
|
+
|
|
33
|
+
- **Claude Code**: Use the `Agent` tool with `run_in_background: true` for each implementer, spec reviewer, code quality reviewer, fix agent, and final reviewer. Never execute tasks inline and do not accidentally enter team mode, which requires a pre-created team.
|
|
34
|
+
- **Other platforms**: Use the platform's equivalent background agent / Task / multi-agent dispatch mechanism.
|
|
35
|
+
- **Never** reuse implementers, reviewers, or fix agents across tasks or roles. Each agent gets a fresh, isolated context containing only the single task and role-specific context it needs.
|
|
36
|
+
- If the platform has no real background dispatch capability, do not proceed; pause and wait for the user to choose `build_mode: executing-plans`.
|
|
37
|
+
|
|
38
|
+
### 1. Dispatch Prompt and Return Contract
|
|
39
|
+
|
|
40
|
+
Every implementer or fix-agent prompt must include:
|
|
41
|
+
|
|
42
|
+
- The full text of the single current task, architecture background, and dependency context
|
|
43
|
+
- `Language: Use the language of the user request that triggered this workflow`
|
|
44
|
+
- The allowed file scope and prohibited modification scope
|
|
45
|
+
- The required test commands and commit requirements
|
|
46
|
+
- For a fix agent, the corresponding reviewer's complete feedback
|
|
47
|
+
|
|
48
|
+
The agent return status must be `DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT` and include implementation details, test results, commit hash, changed files, and concerns. Before review, the coordinator must verify that the commit and changed files are visible in the current worktree; on isolated-copy platforms, pull or merge the changes first.
|
|
49
|
+
|
|
50
|
+
Every reviewer prompt must include the full task, the implementation commit or diff and the RED/GREEN evidence (when `tdd_mode: tdd`). A reviewer must not review from the implementer's summary alone.
|
|
51
|
+
|
|
52
|
+
### 2. Implementer Scope Restriction
|
|
53
|
+
|
|
54
|
+
The implementer is only responsible for implementation, testing, and committing code. **The implementer must not check off plan or OpenSpec tasks**, nor update only the built-in Todo or in-chat checklists.
|
|
55
|
+
|
|
56
|
+
### 3. TDD Hard Constraint
|
|
57
|
+
|
|
58
|
+
If `tdd_mode: tdd`, every implementer and fix agent must first use the Skill tool to load the Superpowers `test-driven-development` skill, and its prompt must also inject:
|
|
59
|
+
|
|
60
|
+
```text
|
|
61
|
+
You MUST follow TDD: write a failing test first, watch it fail, then write minimal code to pass. No production code without a failing test first.
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
The implementer or fix-agent return must provide **RED failure command and failure summary**, **GREEN pass command and pass summary**; missing either piece of evidence blocks entry into review. Both spec compliance reviewer and code quality reviewer must verify RED/GREEN evidence and test coverage.
|
|
65
|
+
|
|
66
|
+
### 4. Durable Progress Checkpoint
|
|
67
|
+
|
|
68
|
+
The coordinator must maintain `openspec/changes/<name>/.comet/subagent-progress.md` and update it immediately after every dispatch, agent return, review result, review-fix round change, and task checkoff. The checkpoint must record at least:
|
|
69
|
+
|
|
70
|
+
- The unique current plan task text and mapped OpenSpec task text
|
|
71
|
+
- Current stage: `implementing | spec-review | quality-review | checkoff | done | blocked | final-review | final-fix`
|
|
72
|
+
- Implementation commit hash, changed files, and RED/GREEN evidence
|
|
73
|
+
- Review stages already passed and unresolved reviewer feedback
|
|
74
|
+
- The current task or final-review review-fix round (maximum 3)
|
|
75
|
+
|
|
76
|
+
This file stores only coordinator recovery state and does not replace plan or OpenSpec checkboxes. Retain the final record when a task completes, then replace it with the next task's record when that task begins.
|
|
77
|
+
|
|
78
|
+
### 5. Review-Fix Round Limit
|
|
79
|
+
|
|
80
|
+
Each task allows at most 3 review-fix rounds. When either reviewer finds an issue, dispatch a fresh background fix agent and restart from the corresponding review. If the task still does not pass after 3 rounds, mark it **BLOCKED**, pause, and hand the accumulated feedback to the user.
|
|
81
|
+
|
|
82
|
+
### 6. Task Checkoff and Verification
|
|
83
|
+
|
|
84
|
+
**After both reviews pass**, the main session:
|
|
85
|
+
|
|
86
|
+
1. Changes the saved unique task text from `- [ ]` to `- [x]` in the plan
|
|
87
|
+
2. If a mapping exists, also checks off the OpenSpec task
|
|
88
|
+
3. Commits this progress update
|
|
89
|
+
4. Runs targeted verification:
|
|
90
|
+
|
|
91
|
+
```bash
|
|
92
|
+
"$COMET_BASH" "$COMET_STATE" task-checkoff "$PLAN_FILE" "$PLAN_TASK_TEXT"
|
|
93
|
+
"$COMET_BASH" "$COMET_STATE" task-checkoff "openspec/changes/<name>/tasks.md" "$OPENSPEC_TASK_TEXT"
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Run the second command only when the corresponding mapping exists. The script requires the task text to appear exactly once and be checked; verification failure blocks moving to the next task.
|
|
97
|
+
|
|
98
|
+
## Wrap-up
|
|
99
|
+
|
|
100
|
+
- **AUTO-CONTINUE**: After both reviews pass and the task is checked off, immediately dispatch the next unchecked task. Do NOT summarize, do NOT ask the user whether to continue, do NOT wait for user input between tasks. This is non-negotiable — the Superpowers skill enforces continuous execution, and the CRITICAL warning at the top of this document reinforces it.
|
|
101
|
+
- After all tasks complete, switch the checkpoint to `final-review`, then dispatch a fresh background final code quality reviewer. For CRITICAL issues, switch the checkpoint to `final-fix`, record feedback and the round, dispatch a fresh background fix agent, and re-review. Final review also has a maximum of 3 rounds; when exhausted, mark the checkpoint `blocked` and pause. Non-CRITICAL findings may be accepted with rationale recorded in tasks.md.
|
|
102
|
+
- After final review passes, only the subagent dispatch loop is complete, not the Comet workflow. The coordinator must not load `finishing-a-development-branch` or pause to ask what comes next; it must return control to `comet-build` for exit checks, the phase guard, and phase handoff.
|
|
103
|
+
|
|
104
|
+
## Context Recovery
|
|
105
|
+
|
|
106
|
+
Reload the Superpowers `subagent-driven-development` skill and re-read this document. Read `openspec/changes/<name>/.comet/subagent-progress.md`, then compare it with the first unchecked task and the current worktree:
|
|
107
|
+
|
|
108
|
+
- When the checkpoint matches the unchecked task, resume from its exact recorded stage while preserving the implementation commit, RED/GREEN evidence, review stages already passed, unresolved feedback, and current review-fix round. Never reset the round or repeat an already passed stage.
|
|
109
|
+
- When the checkpoint is missing or does not match the unchecked task, create a new checkpoint for the first unchecked task and begin with implementer dispatch.
|
|
110
|
+
- When a recorded commit or file is not visible in the current worktree, pull, merge, or recover the corresponding changes before proceeding; never assume the implementation exists.
|
|
111
|
+
- When all tasks are checked and the checkpoint stage is `final-review` or `final-fix`, resume the exact final-review stage while preserving final feedback and its review-fix round; never re-enter completed tasks.
|
|
112
|
+
|
|
113
|
+
Tasks committed without dual-review approval remain unchecked and re-enter the review or fix loop according to the checkpoint.
|
|
@@ -0,0 +1,99 @@
|
|
|
1
|
+
# Comet Phase Awareness (Anti-Drift Rules)
|
|
2
|
+
|
|
3
|
+
> This rule is injected every round to prevent forgetting Comet workflow state during long context.
|
|
4
|
+
> The Hook platform additionally executes `comet-hook-guard.sh` for hard interception;
|
|
5
|
+
> this Rule is a universal soft defense line for all platforms.
|
|
6
|
+
|
|
7
|
+
## Global Rules
|
|
8
|
+
|
|
9
|
+
### Phase Awareness (Highest Priority)
|
|
10
|
+
|
|
11
|
+
When there is an active comet change (`openspec/changes/<name>/.comet.yaml` exists), **before starting any operation** you must read the `phase` field to confirm the current phase.
|
|
12
|
+
|
|
13
|
+
**Phases and allowed operations:**
|
|
14
|
+
|
|
15
|
+
| Phase | Allowed | Prohibited |
|
|
16
|
+
|-------|---------|------------|
|
|
17
|
+
| `open` | Create proposal/design/tasks, run guard | Write source code |
|
|
18
|
+
| `design` | brainstorming, create Design Doc, run guard | Write source code |
|
|
19
|
+
| `build` | Write source code, tests, execute plans | Skip user confirmation points |
|
|
20
|
+
| `verify` | Verification, branch handling | Skip failure handling |
|
|
21
|
+
| `archive` | Confirm archive, run archive script | Write source code |
|
|
22
|
+
|
|
23
|
+
### Skill Invocation (Cannot Replace with Normal Conversation)
|
|
24
|
+
|
|
25
|
+
The following operations must be loaded through the Skill tool. When Skill is unavailable, stop the workflow and prompt to install:
|
|
26
|
+
|
|
27
|
+
- **brainstorming** — design phase, build phase medium-scale spec changes
|
|
28
|
+
- **writing-plans** — build phase creating implementation plans
|
|
29
|
+
- **executing-plans** / **subagent-driven-development** — build phase execution
|
|
30
|
+
- **test-driven-development** — in `executing-plans`, the main session loads it before the first task; in `subagent-driven-development`, each background implementer and fix agent loads it
|
|
31
|
+
- **systematic-debugging** — when encountering crashes/test failures/build failures
|
|
32
|
+
- **verification-before-completion** — verify phase
|
|
33
|
+
- **using-git-worktrees** — build phase when selecting worktree isolation
|
|
34
|
+
|
|
35
|
+
### Script Execution (Cannot Skip)
|
|
36
|
+
|
|
37
|
+
- **Phase exit**: `comet-guard <name> <phase> --apply` (must see ALL CHECKS PASSED)
|
|
38
|
+
- **Compression recovery**: `comet-state check <name> <phase> --recover`
|
|
39
|
+
- **State update**: After key operations, update fields through `comet-state set`; manually editing .comet.yaml is prohibited
|
|
40
|
+
- **handoff generation**: `comet-handoff <name> design --write` (handwriting summaries is prohibited)
|
|
41
|
+
|
|
42
|
+
### User Confirmation (Cannot Auto-Skip)
|
|
43
|
+
|
|
44
|
+
The following decision points must pause to wait for explicit user selection; do not auto-fill based on recommendation rules:
|
|
45
|
+
|
|
46
|
+
- **open**: Requirements clarification completion confirmation, artifact review confirmation
|
|
47
|
+
- **design**: brainstorming proposal confirmation (Design Doc cannot be created before confirmation)
|
|
48
|
+
- **build**: plan-ready pause, isolation/build_mode/tdd_mode selection, spec large-scale change confirmation
|
|
49
|
+
- **verify**: Verification failure handling strategy, branch handling selection
|
|
50
|
+
- **archive**: Final confirmation before archiving
|
|
51
|
+
|
|
52
|
+
## Design Phase Specifics
|
|
53
|
+
|
|
54
|
+
1. First script operation = `comet-handoff <name> design --write` (loading brainstorming before generating handoff is prohibited)
|
|
55
|
+
2. brainstorming in progress: incrementally update brainstorm-summary.md (update recovery checkpoint after each clarification round or proposal iteration; unconfirmed content marked as pending/candidate)
|
|
56
|
+
3. After brainstorming completes, next step = brainstorm-summary.md finalization → Design Doc → guard
|
|
57
|
+
4. active compaction gate: after brainstorm-summary.md is finalized and before creating Design Doc, prioritize triggering host platform's native context compression; when programmatic triggering is unavailable, pause to prompt user to manually compress or confirm continuing
|
|
58
|
+
5. **Absolutely cannot start writing implementation code directly** — must first create Design Doc and pass guard
|
|
59
|
+
|
|
60
|
+
## Build Phase Specifics
|
|
61
|
+
|
|
62
|
+
1. After plan creation, must ask user to choose continue or pause (`build_pause` mechanism)
|
|
63
|
+
2. After each task acceptance, must: tasks.md checkmark → git commit (do not accumulate). `subagent-driven-development` must wait for both spec compliance and code quality reviews to pass, then the coordinator performs targeted verification by unique task text; do not use an incomplete task summary table to replace current task verification
|
|
64
|
+
3. When encountering failures, must load **systematic-debugging** skill; do not propose source code fixes before root cause is located
|
|
65
|
+
4. spec change grading: small changes edit directly | medium changes load brainstorming | large changes pause and wait for user confirmation to split
|
|
66
|
+
|
|
67
|
+
## Verify Phase Specifics
|
|
68
|
+
|
|
69
|
+
1. First step run `comet-state scale <name>` to determine verification level
|
|
70
|
+
2. After verification fails, list failed items and wait for user selection; CRITICAL must be fixed
|
|
71
|
+
3. After 3 consecutive failures, must let user choose to accept deviation or continue fixing
|
|
72
|
+
|
|
73
|
+
## Context Compression Recovery
|
|
74
|
+
|
|
75
|
+
If context compression is suspected (previous conversation was summarized, previous discussion cannot be found), immediately run:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
"$COMET_BASH" "$COMET_STATE" check <name> <phase> --recover
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
Decide next step according to the script's **Recovery action** output.
|
|
82
|
+
|
|
83
|
+
**Special attention to `build_mode`**: If recovery script outputs `build_mode: subagent-driven-development`, you are the coordinator, not the executor. Must:
|
|
84
|
+
1. Use the Skill tool to reload the Superpowers `subagent-driven-development` skill
|
|
85
|
+
2. Re-read `comet/reference/subagent-dispatch.md` for Comet-specific extensions
|
|
86
|
+
3. Read `openspec/changes/<name>/.comet/subagent-progress.md` to recover the exact stage, evidence, and review-fix round
|
|
87
|
+
4. Do not execute tasks directly in the main session
|
|
88
|
+
5. Resume from the checkpoint; start from the first unchecked task only when it is missing or mismatched
|
|
89
|
+
6. Already committed but not yet passed both reviews tasks remain unchecked; continue review/fix loop
|
|
90
|
+
7. After dual review and targeted checkoff verification pass, immediately continue to the next task without summarizing or asking whether to continue
|
|
91
|
+
|
|
92
|
+
## Automatic Transition After Phase Exit
|
|
93
|
+
|
|
94
|
+
After guard `--apply` succeeds, must invoke the next phase's skill:
|
|
95
|
+
|
|
96
|
+
- open → `comet-design` (full) / `comet-build` (hotfix/tweak)
|
|
97
|
+
- design → `comet-build`
|
|
98
|
+
- build → `comet-verify`
|
|
99
|
+
- verify → `comet-archive`
|
|
@@ -1,90 +1,99 @@
|
|
|
1
|
-
# Comet 阶段感知(防漂移规则)
|
|
2
|
-
|
|
3
|
-
> 此规则每轮注入,防止长上下文时遗忘 Comet 流程状态。
|
|
4
|
-
> Hook 平台额外执行 `comet-hook-guard.sh` 进行硬性拦截;
|
|
5
|
-
> 此 Rule 是所有平台通用的软性防线。
|
|
6
|
-
|
|
7
|
-
## 全局规则
|
|
8
|
-
|
|
9
|
-
### 阶段感知(最高优先级)
|
|
10
|
-
|
|
11
|
-
有活跃 comet change 时(`openspec/changes/<name>/.comet.yaml` 存在),**每次开始执行操作前**必须读取 `phase` 字段确认当前阶段。
|
|
12
|
-
|
|
13
|
-
**阶段与允许操作:**
|
|
14
|
-
|
|
15
|
-
| 阶段 | 允许 | 禁止 |
|
|
16
|
-
|------|------|------|
|
|
17
|
-
| `open` | 创建 proposal/design/tasks, 运行 guard | 写源代码 |
|
|
18
|
-
| `design` | brainstorming, 创建 Design Doc, 运行 guard | 写源代码 |
|
|
19
|
-
| `build` | 写源代码、测试、执行计划 | 跳过用户确认点 |
|
|
20
|
-
| `verify` | 验证、branch handling | 跳过失败处理 |
|
|
21
|
-
| `archive` | 确认归档、运行归档脚本 | 写源代码 |
|
|
22
|
-
|
|
23
|
-
### Skill 调用(不可用普通对话替代)
|
|
24
|
-
|
|
25
|
-
以下操作必须通过 Skill 工具加载,Skill 不可用时应停止流程并提示安装:
|
|
26
|
-
|
|
27
|
-
- **brainstorming** — design 阶段、build 阶段中等规模 spec 变更
|
|
28
|
-
- **writing-plans** — build 阶段创建实现计划
|
|
29
|
-
- **executing-plans** / **subagent-driven-development** — build 阶段执行
|
|
30
|
-
- **test-driven-development** —
|
|
31
|
-
- **systematic-debugging** — 遇到崩溃/测试失败/构建失败时
|
|
32
|
-
- **verification-before-completion** — verify 阶段
|
|
33
|
-
- **using-git-worktrees** — build 阶段选择 worktree 隔离时
|
|
34
|
-
|
|
35
|
-
### 脚本执行(不可跳过)
|
|
36
|
-
|
|
37
|
-
- **阶段退出**: `comet-guard <name> <phase> --apply`(必须看到 ALL CHECKS PASSED)
|
|
38
|
-
- **压缩恢复**: `comet-state check <name> <phase> --recover`
|
|
39
|
-
- **状态更新**: 关键操作后通过 `comet-state set` 更新字段,禁止手工编辑 .comet.yaml
|
|
40
|
-
- **handoff 生成**: `comet-handoff <name> design --write`(禁止手写摘要)
|
|
41
|
-
|
|
42
|
-
### 用户确认(不可自动跳过)
|
|
43
|
-
|
|
44
|
-
以下决策点必须暂停等待用户明确选择,不得根据推荐规则自动填写:
|
|
45
|
-
|
|
46
|
-
- **open**: 需求澄清完成确认、artifact 评审确认
|
|
47
|
-
- **design**: brainstorming 方案确认(确认前不得创建 Design Doc)
|
|
48
|
-
- **build**: plan-ready 暂停、isolation/build_mode/tdd_mode 选择、spec 大规模变更确认
|
|
49
|
-
- **verify**: 验证失败处理策略、branch handling 选择
|
|
50
|
-
- **archive**: 归档前最终确认
|
|
51
|
-
|
|
52
|
-
## Design 阶段专项
|
|
53
|
-
|
|
54
|
-
1. 第一个脚本操作 = `comet-handoff <name> design --write`(未生成 handoff 禁止加载 brainstorming)
|
|
55
|
-
2. brainstorming in progress: incrementally update brainstorm-summary.md(每轮澄清或方案迭代后增量更新恢复检查点,未确认内容标注为待确认/候选)
|
|
56
|
-
3. brainstorming 完成后下一步 = brainstorm-summary.md 定稿 → Design Doc → guard
|
|
57
|
-
4. active compaction gate: brainstorm-summary.md 定稿后、创建 Design Doc 前,优先触发宿主平台原生上下文压缩;无法程序化触发时暂停提示用户手动压缩或确认继续
|
|
58
|
-
5. **绝对不能直接开始写实现代码** — 必须先创建 Design Doc 并通过 guard
|
|
59
|
-
|
|
60
|
-
## Build 阶段专项
|
|
61
|
-
|
|
62
|
-
1. plan 创建后必须询问用户选择继续或暂停(`build_pause` 机制)
|
|
63
|
-
2. 每个 task
|
|
64
|
-
3. 遇到失败必须加载 **systematic-debugging** skill,根因未定位前不得提出源码修复
|
|
65
|
-
4. spec 变更分级: 小改直接编辑 | 中改加载 brainstorming | 大改暂停等用户确认拆分
|
|
66
|
-
|
|
67
|
-
## Verify 阶段专项
|
|
68
|
-
|
|
69
|
-
1. 第一步运行 `comet-state scale <name>` 确定验证级别
|
|
70
|
-
2. 验证失败后列出失败项等用户选择,CRITICAL 必须修
|
|
71
|
-
3. 连续 3 次失败后必须让用户选择接受偏差或继续修
|
|
72
|
-
|
|
73
|
-
## 上下文压缩恢复
|
|
74
|
-
|
|
75
|
-
如果怀疑发生上下文压缩(之前对话被摘要、找不到之前讨论的内容),立即运行:
|
|
76
|
-
|
|
77
|
-
```bash
|
|
78
|
-
"$COMET_BASH" "$COMET_STATE" check <name> <phase> --recover
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
按脚本输出的 **Recovery action** 决定下一步。
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
1
|
+
# Comet 阶段感知(防漂移规则)
|
|
2
|
+
|
|
3
|
+
> 此规则每轮注入,防止长上下文时遗忘 Comet 流程状态。
|
|
4
|
+
> Hook 平台额外执行 `comet-hook-guard.sh` 进行硬性拦截;
|
|
5
|
+
> 此 Rule 是所有平台通用的软性防线。
|
|
6
|
+
|
|
7
|
+
## 全局规则
|
|
8
|
+
|
|
9
|
+
### 阶段感知(最高优先级)
|
|
10
|
+
|
|
11
|
+
有活跃 comet change 时(`openspec/changes/<name>/.comet.yaml` 存在),**每次开始执行操作前**必须读取 `phase` 字段确认当前阶段。
|
|
12
|
+
|
|
13
|
+
**阶段与允许操作:**
|
|
14
|
+
|
|
15
|
+
| 阶段 | 允许 | 禁止 |
|
|
16
|
+
|------|------|------|
|
|
17
|
+
| `open` | 创建 proposal/design/tasks, 运行 guard | 写源代码 |
|
|
18
|
+
| `design` | brainstorming, 创建 Design Doc, 运行 guard | 写源代码 |
|
|
19
|
+
| `build` | 写源代码、测试、执行计划 | 跳过用户确认点 |
|
|
20
|
+
| `verify` | 验证、branch handling | 跳过失败处理 |
|
|
21
|
+
| `archive` | 确认归档、运行归档脚本 | 写源代码 |
|
|
22
|
+
|
|
23
|
+
### Skill 调用(不可用普通对话替代)
|
|
24
|
+
|
|
25
|
+
以下操作必须通过 Skill 工具加载,Skill 不可用时应停止流程并提示安装:
|
|
26
|
+
|
|
27
|
+
- **brainstorming** — design 阶段、build 阶段中等规模 spec 变更
|
|
28
|
+
- **writing-plans** — build 阶段创建实现计划
|
|
29
|
+
- **executing-plans** / **subagent-driven-development** — build 阶段执行
|
|
30
|
+
- **test-driven-development** — `executing-plans` 由主会话在第一个 task 前加载;`subagent-driven-development` 由每个后台 implementer 和修复 agent 加载
|
|
31
|
+
- **systematic-debugging** — 遇到崩溃/测试失败/构建失败时
|
|
32
|
+
- **verification-before-completion** — verify 阶段
|
|
33
|
+
- **using-git-worktrees** — build 阶段选择 worktree 隔离时
|
|
34
|
+
|
|
35
|
+
### 脚本执行(不可跳过)
|
|
36
|
+
|
|
37
|
+
- **阶段退出**: `comet-guard <name> <phase> --apply`(必须看到 ALL CHECKS PASSED)
|
|
38
|
+
- **压缩恢复**: `comet-state check <name> <phase> --recover`
|
|
39
|
+
- **状态更新**: 关键操作后通过 `comet-state set` 更新字段,禁止手工编辑 .comet.yaml
|
|
40
|
+
- **handoff 生成**: `comet-handoff <name> design --write`(禁止手写摘要)
|
|
41
|
+
|
|
42
|
+
### 用户确认(不可自动跳过)
|
|
43
|
+
|
|
44
|
+
以下决策点必须暂停等待用户明确选择,不得根据推荐规则自动填写:
|
|
45
|
+
|
|
46
|
+
- **open**: 需求澄清完成确认、artifact 评审确认
|
|
47
|
+
- **design**: brainstorming 方案确认(确认前不得创建 Design Doc)
|
|
48
|
+
- **build**: plan-ready 暂停、isolation/build_mode/tdd_mode 选择、spec 大规模变更确认
|
|
49
|
+
- **verify**: 验证失败处理策略、branch handling 选择
|
|
50
|
+
- **archive**: 归档前最终确认
|
|
51
|
+
|
|
52
|
+
## Design 阶段专项
|
|
53
|
+
|
|
54
|
+
1. 第一个脚本操作 = `comet-handoff <name> design --write`(未生成 handoff 禁止加载 brainstorming)
|
|
55
|
+
2. brainstorming in progress: incrementally update brainstorm-summary.md(每轮澄清或方案迭代后增量更新恢复检查点,未确认内容标注为待确认/候选)
|
|
56
|
+
3. brainstorming 完成后下一步 = brainstorm-summary.md 定稿 → Design Doc → guard
|
|
57
|
+
4. active compaction gate: brainstorm-summary.md 定稿后、创建 Design Doc 前,优先触发宿主平台原生上下文压缩;无法程序化触发时暂停提示用户手动压缩或确认继续
|
|
58
|
+
5. **绝对不能直接开始写实现代码** — 必须先创建 Design Doc 并通过 guard
|
|
59
|
+
|
|
60
|
+
## Build 阶段专项
|
|
61
|
+
|
|
62
|
+
1. plan 创建后必须询问用户选择继续或暂停(`build_pause` 机制)
|
|
63
|
+
2. 每个 task 验收后必须: tasks.md 打勾 → git commit(不得积攒)。`subagent-driven-development` 必须等 spec compliance 与 code quality 两个审查都通过,再由协调者按任务唯一文本定向勾选和验证;不得用未完成任务总表代替当前任务验证
|
|
64
|
+
3. 遇到失败必须加载 **systematic-debugging** skill,根因未定位前不得提出源码修复
|
|
65
|
+
4. spec 变更分级: 小改直接编辑 | 中改加载 brainstorming | 大改暂停等用户确认拆分
|
|
66
|
+
|
|
67
|
+
## Verify 阶段专项
|
|
68
|
+
|
|
69
|
+
1. 第一步运行 `comet-state scale <name>` 确定验证级别
|
|
70
|
+
2. 验证失败后列出失败项等用户选择,CRITICAL 必须修
|
|
71
|
+
3. 连续 3 次失败后必须让用户选择接受偏差或继续修
|
|
72
|
+
|
|
73
|
+
## 上下文压缩恢复
|
|
74
|
+
|
|
75
|
+
如果怀疑发生上下文压缩(之前对话被摘要、找不到之前讨论的内容),立即运行:
|
|
76
|
+
|
|
77
|
+
```bash
|
|
78
|
+
"$COMET_BASH" "$COMET_STATE" check <name> <phase> --recover
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
按脚本输出的 **Recovery action** 决定下一步。
|
|
82
|
+
|
|
83
|
+
**特别注意 `build_mode`**:若恢复脚本输出 `build_mode: subagent-driven-development`,你是协调者,不是执行者。必须:
|
|
84
|
+
1. 使用 Skill 工具重新加载 Superpowers `subagent-driven-development` 技能 (Use the Skill tool to reload the Superpowers `subagent-driven-development` skill)
|
|
85
|
+
2. 读取 `comet/reference/subagent-dispatch.md` 获取 Comet 专属扩展 (re-read `comet/reference/subagent-dispatch.md` for Comet-specific extensions)
|
|
86
|
+
3. 读取 `openspec/changes/<name>/.comet/subagent-progress.md` 恢复精确阶段、证据和审查-修复轮次 (Read `openspec/changes/<name>/.comet/subagent-progress.md` to recover the exact stage, evidence, and review-fix round)
|
|
87
|
+
4. 禁止在主会话中直接执行 task (Do not execute the pending task directly in the main window)
|
|
88
|
+
5. 按检查点恢复;缺失或不匹配时才从第一个未勾选 task 开始
|
|
89
|
+
6. 已提交但未通过双审查的 task 保持未勾选,继续审查/修复循环
|
|
90
|
+
7. task 通过双审查和定向勾选验证后立即继续下一个 task,不得总结或询问是否继续
|
|
91
|
+
|
|
92
|
+
## 阶段退出后自动过渡
|
|
93
|
+
|
|
94
|
+
guard `--apply` 成功后,必须调用下一阶段的 skill:
|
|
95
|
+
|
|
96
|
+
- open → `comet-design`(full)/ `comet-build`(hotfix/tweak)
|
|
97
|
+
- design → `comet-build`
|
|
98
|
+
- build → `comet-verify`
|
|
99
|
+
- verify → `comet-archive`
|