@rpamis/comet 0.4.0-beta.1 → 0.4.0-beta.11

package/assets/skills/comet-any/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: comet-any
-description: "Use when the user wants to customize Comet five-phase skills, create a workflow skill, organize an existing skill, or compose skills with Workflow Node / Skill Binding / Output Schema."
+description: "Use only when explicitly invoked as /comet-any or when the user explicitly wants to customize the /comet-classic five-phase workflow or create/upgrade a workflow Skill managed by Comet Creator. Do not use for general Skill authoring, cleanup, or review."
 ---
 
 # Comet Any - Skill Creator
@@ -9,7 +9,7 @@ description: "Use when the user wants to customize Comet five-phase skills, crea
 
 Ordinary users see three starting points:
 
-- `customize existing Comet Skills`: overlay the existing five phase Skills for `open / design / build / verify / archive` without modifying the `/comet` command itself.
+- `customize /comet-classic five-phase Skills`: overlay the existing `open / design / build / verify / archive` Skills without modifying the permanent `/comet-classic` entry itself.
 - `create a new workflow Skill`: generate a new `workflow-kernel` from the goal and candidate Skills.
 - `upgrade an existing Skill`: read existing Skills and add Workflow Nodes, Skill Bindings, Output Schemas, Guardrails, Handoffs, eval, and readiness.
 
@@ -30,9 +30,9 @@ Every path compiles to one Workflow Contract:
 
 ## Protected Boundary
 
-`comet-five-phase-overlay` preserves the Comet control flow and `.comet.yaml` state semantics. In ordinary mode:
+`comet-five-phase-overlay` preserves the Comet Classic five-phase control flow and `.comet.yaml` state semantics. In ordinary mode:
 
-- `comet-five-phase-overlay` primary state comes only from `openspec/changes/<name>/.comet.yaml`; no active change or multiple active changes must block and ask the user to choose.
+- `comet-five-phase-overlay` primary state comes only from `<classic-change-dir>/.comet.yaml` bound by the Classic layout resolver; no active change or multiple active changes must block and ask the user to choose.
 - The overlay must not create `.comet/runs/<workflow>/state.json` as the Comet overlay primary state. Bundle drafts, eval evidence, and publish readiness may keep their own evidence files, but they cannot replace `.comet.yaml`.
 - `control` Nodes cannot be overridden: `open`, `execute`, `verify`, `archive`.
 - `producer` Nodes may be overridden: `design`, `plan`, but only when the replacement satisfies the matching Output Schema.
@@ -59,7 +59,7 @@ Component-library and whitebox-review requirements should produce a plan like:
 
 ```json
 {
-  "goal": "Customize existing Comet Skills with component and whitebox review requirements.",
+  "goal": "Customize /comet-classic five-phase Skills with component and whitebox review requirements.",
   "skillCreatorIntent": "customize-comet",
   "workflow": {
     "kind": "comet-five-phase-overlay",

package/assets/skills/comet-any/reference/authored-zone-example.md

@@ -62,21 +62,26 @@ Run `node "$WORKFLOW_STATE" status` to confirm the detected Node. If the script'
 - If workflow state shows a Node as complete but its expected artifacts are missing, treat the Node as incomplete and re-enter it.
 - If the user resumes mid-Node with a different topic, confirm whether to continue the current Node or start a new one.
 
-### Decision Points (must pause)
+### Decision Classification And Decision Points
+
+Classify before acting: a user decision has two or more valid options that change scope, behavior, accepted risk, or an irreversible outcome; a sole safe next action is automatic handling; a missing dependency, corrupt state, or guard failure with no valid continuation is a stop condition; `NEXT: manual` only returns control. Only the first category must pause.
 
 | Situation | Action |
 |-----------|--------|
-| First invocation, no workflow state exists | Initialize state, confirm the topic/scope with the user before starting the first Node |
-| User input is ambiguous between two Nodes | Ask the user which Node they mean; do not guess |
+| First invocation with an unambiguous topic and scope | Initialize state automatically and enter the first Node; do not pause to approve known information |
+| Topic, scope, or target Node has two or more mutually exclusive valid interpretations | Merge them into one question and let the user choose; do not guess |
 | Node requires user approval of output before advancing | Stop after recording evidence; wait for explicit confirmation |
-| Node fails its guard and the cause is unclear | Present the guard output and ask the user how to proceed |
+| Accepting a WARNING/deviation or performing an irreversible publish has a real tradeoff | Show only currently executable options and persist the choice |
+
+When a Node guard fails, inspect evidence and perform the sole safe repair first. If a missing dependency or corrupt state prevents progress, report the stop condition and recovery requirement. Escalate to the decision table only when multiple valid recovery options would change scope or risk.
 
 ### Red Flags
 
 | Agent Thought | Actual Risk |
 |--------------|-------------|
-| "The user mentioned the topic, so research is implicitly confirmed" | Mentioning ≠ confirming. Pause at the first Node boundary and confirm scope. |
+| "Every first invocation needs another confirmation" | Clear input does not need duplicate approval; ask only when mutually exclusive interpretations still change scope. |
 | "The script returned NEXT: auto, so I should immediately load the next Skill" | `NEXT: auto` means the Node is done, not that you should skip confirmation. Check if the next Node has a decision point. |
+| "The guard failed, so ask the user what to do" | Diagnose automatically and apply the sole safe repair first; if no valid action exists, report a stop condition instead of inventing options. |
 | "This looks like the same topic as last time, resume from where we left off" | Always re-read state. Conversation memory is unreliable after context compaction. |
 | "The exit check passed, so the work is good enough" | Exit checks are mechanical. Your job is to judge quality beyond the check — sparse notes, shallow analysis, or missing perspectives are not caught by scripts. |
 ```

package/assets/skills/comet-any/reference/authoring-subagents.md

@@ -58,7 +58,7 @@ Every subagent must receive the same common context:
   the derived internal `callChain` source inventory from Skill Creator metadata.
 - `reference/resolved-skills.json` or an equivalent real Skill source summary.
 - `reference/workflow-protocol.json` or the workflow protocol that will be written there.
-- For customize existing Comet Skills, the protected boundary: `open / design / build / verify / archive`, `.comet.yaml`, decision point, verify-result-transition, and archive-delta-sync.
+- For `/comet-classic` customization, the protected boundary is `open / design / build / verify / archive`, `.comet.yaml`, decision point, verify-result-transition, and archive-delta-sync.
 - Project preferences, missing or ambiguous candidate decisions, deviation reasons, and scripts/hooks executable disclosures.
 
 ## Output Format

package/assets/skills/comet-any/reference/bundle-authoring.md

@@ -8,7 +8,7 @@ The new `plan.json` uses `workflow` as the primary input:
 
 ```json
 {
-  "goal": "Customize existing Comet Skills with component and whitebox review requirements.",
+  "goal": "Customize /comet-classic five-phase Skills with component and whitebox review requirements.",
   "skillCreatorIntent": "customize-comet",
   "workflow": {
     "kind": "comet-five-phase-overlay",
@@ -62,7 +62,7 @@ Field rules:
 
 `comet-five-phase-overlay` includes these Workflow Nodes:
 
-- `comet-five-phase-overlay` primary state comes only from `openspec/changes/<name>/.comet.yaml`; no active change or multiple active changes must block and ask the user to choose.
+- `comet-five-phase-overlay` primary state comes only from `<classic-change-dir>/.comet.yaml` bound by the Classic layout resolver; no active change or multiple active changes must block and ask the user to choose.
 - The overlay must not create `.comet/runs/<workflow>/state.json` as the Comet overlay primary state; overlay scripts only read and advance `.comet.yaml`, while other files may be draft, eval, or publish evidence.
 - `open`: control, preserves Comet intake and `.comet.yaml` initialization.
 - `design`: producer, may be overridden only when it satisfies `comet.design.v1`.

package/assets/skills/comet-any/reference/subagents/pause-points-author.md

@@ -4,7 +4,7 @@ This file is a portable lane brief, not a platform-native custom agent. If you n
 
 ## Responsibilities
 
-Design the places where the user must pause and choose, plus cross-device recovery. Pause points must be explicit user choices that cannot be bypassed by default recommendations, historical preferences, or automatic advancement.
+Design only the places where the user genuinely must choose, plus cross-device recovery. First distinguish four categories: user decision, automatic handling, stop condition, and manual handoff. Create a user pause only when two or more valid options change scope, behavior, accepted risk, or an irreversible outcome. Execute a sole safe action directly, report a missing dependency or corrupt state as a stop condition, and return control for a manual handoff. Genuine user decisions cannot be bypassed by defaults, historical preferences, or automatic advancement.
 
 Must cover:
 
@@ -15,11 +15,10 @@ Must cover:
 
 Read the common input from the main session, especially:
 
-- `confirm-generate`, `revise-proposal`, and `cancel` from the Skill Creator confirmation page.
-- Eval workload choice: `skip / quick / full eval`.
-- Human approval before installation.
-- Blockers such as unresolved candidates, ambiguity, capability gaps, and executable disclosures.
-- Runner recovery state and cross-device recovery entry.
+- `confirm-generate`, `revise-proposal`, and `cancel` from the Skill Creator confirmation page: these are user decisions that change the generated result.
+- Eval workload (`skip / quick / full eval`) and human approval before installation: treat them as decisions only when multiple valid options actually remain.
+- Missing or stale eval evidence, unresolved candidates, ambiguity, capability gaps, and executable disclosures: classify each as automatically repairable, a no-path stop condition, or a real decision with multiple recovery choices. Do not turn all blockers into pause points.
+- Runner recovery state and cross-device recovery entry: reuse persisted choices that remain valid instead of asking again on resume.
 
 Use file handoff: the main session provides paths instead of pasting large bodies of text. Do not inherit main-session history; use only this brief, common input, workflow protocol, and existing drafts.
 
@@ -33,21 +32,23 @@ model: <must explicitly specify model>
 prompt:
   You are the pause point author subagent.
   First read this brief, the common input path, workflow protocol path, Skill draft path, and report file path.
-  Start by asking questions: if user choices, blocker recovery, or cross-device state are unclear, return NEEDS_CONTEXT.
-  Do not guess or fill in missing pause points.
+  First classify each candidate as a user decision, automatic handling, stop condition, or manual handoff. If facts needed for classification are missing, return NEEDS_CONTEXT.
+  Do not guess missing choices, and do not disguise automatic repair, guard failure, capability gaps, a sole valid action, or manual handoff as a user pause.
   Only produce decision-points and recovery drafts; do not write Bundle state and do not execute candidate scripts.
   Write the full pause point draft to the report file path and return only a status summary of 15 lines or fewer.
 ```
 
 ## Output Requirements
 
-Return a pause point draft that explains:
+Return a classification table first, then describe genuine user pause points:
 
+- Which category each candidate belongs to and the evidence for that classification.
 - The trigger condition for every pause point.
 - The choices available to the user.
 - Which Node each choice enters.
 - Where pause point evidence is written.
-- During recovery, how to show current Node, blocking reason, suggested next step, and options.
+- How automatic handling advances directly, and how stop conditions report recovery requirements without inventing options.
+- During recovery, how to show the current Node, blocking reason, suggested next step, and real options while reusing persisted choices.
 
 Pause points must fit the current workflow protocol, not merely list original Comet pause points.
 
@@ -56,8 +57,10 @@ Pause points must fit the current workflow protocol, not merely list original Co
 Before returning, check:
 
 - Every user pause point has trigger condition, options, next Node, and evidence location.
+- Every pause has at least two currently executable valid options; adjacent choices that can be answered together are merged, and a sole valid value creates no pause.
+- Guard failures, deterministic retries, state reconciliation, capability gaps, and `NEXT: manual` are classified according to their actual semantics instead of defaulting to user questions.
 - Default recommendations, historical preferences, and automatic advancement cannot bypass required pause points.
-- The recovery summary can show current Node, blocking reason, suggested next step, and options.
+- The recovery summary can show the current Node, blocking reason, suggested next step, and real options without re-asking choices that remain valid.
 - Cross-device recovery does not rely on current-session memory.
 - Pause points fit the current composed Skill instead of copying original Comet pause points.
 

package/assets/skills/comet-any/reference/subagents/reference-author.md

@@ -20,7 +20,7 @@ Read the common input from the main session, especially:
 - Resolved Skill name, source, description, hash, references, rules, scripts, and hooks.
 - `sourceSummaries`, which must come from real `SKILL.md` bodies and direct references.
 - Project preferences, missing or ambiguous candidate handling, deviation reasons, and executable disclosures.
-- The five-phase Comet semantics preserved when users customize existing Comet Skills.
+- The five-phase Comet semantics preserved when users customize `/comet-classic`.
 
 Use file handoff: the main session provides paths instead of pasting large bodies of text. Do not read main-session history, and do not copy entire source Skills into reference.
 

package/assets/skills/comet-any/reference/subagents/script-author.md

@@ -22,7 +22,7 @@ Read the common input from the main session, especially:
 - `workflow.kind`, `workflow.nodes`, `engineMode`, and `runnerMode` from `plan.json`, plus the
   derived internal `callChain` source inventory from Skill Creator metadata
 - `reference/resolved-skills.json`
-- Protected `.comet.yaml` semantics when users customize existing Comet Skills; `comet-five-phase-overlay` primary state comes only from `openspec/changes/<name>/.comet.yaml` and must not create `.comet/runs/<workflow>/state.json` as the Comet overlay primary state.
+- Protected `.comet.yaml` semantics when users customize `/comet-classic`; `comet-five-phase-overlay` primary state comes only from `<classic-change-dir>/.comet.yaml` bound by the Classic layout resolver and must not create `.comet/runs/<workflow>/state.json` as the Comet overlay primary state.
 
 Use file handoff: the main session provides paths instead of pasting large bodies of text. Do not read main-session history or ask the user to restate content already written to artifacts.
 

package/assets/skills/comet-any/reference/subagents/skill-core-author.md

@@ -94,7 +94,7 @@ Return internal Node Skill drafts that show:
 - If the Node goal is not complete, continue working instead of exiting because a checklist is exhausted.
 - Automatic advancement must come from script outputs `NEXT:` and `SKILL:`, not agent guesses.
 - Nested Skill calls use only Skill names, not provider prefixes.
-- When users customize existing Comet Skills, preserve `open / design / build / verify / archive` and `.comet.yaml` semantics.
+- When users customize `/comet-classic`, preserve `open / design / build / verify / archive` and `.comet.yaml` semantics.
 - For arbitrary Skill composition, organize the result as a Comet-like multi-Node workflow.
 
 Forbidden:

package/assets/skills/comet-any/reference/subagents/skill-reviewer.md

@@ -62,15 +62,17 @@ Any of these must produce blocking findings:
   Node Skill, or a subagent handoff Node does not require the implementation subagent prompt to load that
   Skill.
 - User pause points are missing, or can be bypassed by defaults.
+- Deterministic repair, guard failure, state reconciliation, a capability gap, a sole valid action, or `NEXT: manual` is treated as a user pause by default; or adjacent choices that can be answered together are split into serial confirmations.
+- The entry Skill frontmatter description does not identify it as the managed workflow entry/resume router, or an internal Node Skill description allows ordinary tasks to trigger it without explicit invocation or entry/runtime routing.
 - English Skills mix in Chinese process sentences.
 - Nested Skill calls use provider prefixes.
 - User-visible `SKILL.md` leaks generated audit sections, source hashes, or internal metadata.
-- Customizing existing Comet Skills replaces or removes `open / design / build / verify / archive`, `.comet.yaml`, decision point, verify-result-transition, or archive-delta-sync.
+- Customizing `/comet-classic` replaces or removes `open / design / build / verify / archive`, `.comet.yaml`, decision point, verify-result-transition, or archive-delta-sync.
 - Arbitrary Skill composition is missing automatic advancement, script guards, user pause points, recovery, or current draft hash eval evidence.
 
 ## Severity
 
-- Critical: makes the generated Skill unusable, unrecoverable, unauditable, or breaks protected `/comet` semantics.
+- Critical: makes the generated Skill unusable, unrecoverable, unauditable, or breaks protected `/comet-classic` semantics.
 - Important: makes the Node flow, script guards, pause points, Skill calls, or evidence chain untrustworthy; must be fixed before ready.
 - Minor: clarity, naming, or maintainability improvements that do not block ready.
 

package/assets/skills/comet-any/reference/subagents/workflow-entry-author.md

@@ -20,7 +20,7 @@ Quality bar: the `comet/SKILL.md` Decision Core (see `reference/authored-zone-ex
 
 - **Semantic current-Node detection** — how to determine which Node the user is in, beyond just running the script. Model comet's Step 0 (detect intent from user message, check Node order, handle "belongs to earlier/later Node" conflicts) + Step 1 (read state, trust files over stale state).
 - **Resume and drift rules** — what to do when context resumes (re-detect from scratch, never trust conversation history), when state says DONE but artifacts are missing, when the user's topic shifts mid-Node.
-- **Decision points** — explicit table of situations that MUST pause for user confirmation (first invocation scope, ambiguous Node, user approval required, guard failure).
+- **Decision classification and decision points** — first distinguish user decisions, automatic handling, stop conditions, and manual handoffs, then tabulate only genuine user choices. A clear first invocation, an objectively repairable guard failure, a sole valid next action, and `NEXT: manual` must not manufacture confirmation.
 - **Red flags** — the "agent thought → actual risk" pattern that catches self-deception (e.g., "user mentioned the topic so research is confirmed" → mentioning ≠ confirming).
 
 A Decision Core without these four sections is a stub, not a Decision Core. The entry is the most-loaded file — it is what makes the Skill feel intelligent or mechanical.
@@ -35,7 +35,7 @@ Read the common input from the main session, especially:
 - Node order, Required Skill Calls, and recovery paths from
   `reference/workflow-protocol.json`.
 - The script author's `status`, `init`, `next`, `NEXT:`, `SKILL:`, and guard contracts.
-- The open / design / build / verify / archive boundary that must be preserved when users customize existing Comet Skills.
+- The open / design / build / verify / archive boundary that must be preserved when users customize `/comet-classic`.
 
 Use file handoff: the main session provides paths instead of pasting large bodies of text. Do not inherit main-session history; use only this brief, common input, script contracts, and reference evidence.
 
@@ -49,10 +49,10 @@ model: <must explicitly specify model>
 prompt:
   You are the workflow entry author subagent.
   First read this brief, the common input path, script contract path, workflow protocol path, and report file path.
-  Start by asking questions: if startup routing, recovery paths, current-Node detection, or user pause points are unclear, return NEEDS_CONTEXT.
+  First classify user decisions, automatic handling, stop conditions, and manual handoffs. If startup routing, recovery paths, current-Node detection, or genuine user choices are unclear, return NEEDS_CONTEXT.
   Do not guess or fill in missing flow details.
   Only write the entry SKILL.md draft; do not write internal Node Skills, Bundle state, or execute candidate scripts.
-  The Decision Core MUST include four subsections: ### Automatic Node Detection (Step 0 intent detection + Step 1 state read + resume rules), ### Decision Points (explicit pause table), ### Red Flags (agent thought → actual risk table). A Decision Core without these is a stub.
+  The Decision Core MUST include four subsections: ### Automatic Node Detection (Step 0 intent detection + Step 1 state read + resume rules), ### Decision Classification And Decision Points (genuine user choices only), ### Red Flags (agent thought → actual risk table). Do not list guard failures, deterministic repair, a sole valid action, or manual handoff as a user decision. A Decision Core without these is a stub.
   Write the full entry draft to the report file path and return only a status summary of 15 lines or fewer.
 ```
 
@@ -64,10 +64,10 @@ The entry draft must show:
 - If not started, initialize state before querying `next`.
 - Only after scripts output `NEXT: auto` and `SKILL: <node-skill>` should the agent load that single Node Skill.
 - The Node route table is reference only; it must not use "immediately execute" or "must load" execution directives.
-- When users customize existing Comet Skills, the entry must list Required Skill Calls as Node-local obligations,
+- When users customize `/comet-classic`, the entry must list Required Skill Calls as Node-local obligations,
   not as an immediate execution checklist.
-- User pause points, recovery paths, and reference files are visible.
-- When users customize existing Comet Skills, preserve the open / design / build / verify / archive main path and Guardrails.
+- User decisions, automatic handling, stop conditions, manual handoffs, recovery paths, and reference files are visible. Pause only when at least two real valid options remain, and merge adjacent choices.
+- When users customize `/comet-classic`, preserve the open / design / build / verify / archive main path and Guardrails.
 
 Forbidden:
 
@@ -85,6 +85,7 @@ Before returning, check:
 - The entry has no immediate-load checklist for Node Skills.
 - The Node route is reference, not execution steps.
 - Automatic advancement references script outputs `NEXT:` and `SKILL:`.
+- A clear first invocation initializes directly, guard failures are diagnosed automatically or reported as stop conditions, and `NEXT: manual` only returns control; none is presented as a fabricated user decision.
 - User-visible English prose is consistent and does not mix in Chinese process sentences.
 
 ## Required Claim

package/assets/skills/comet-archive/SKILL.md

@@ -1,59 +1,72 @@
 ---
 name: comet-archive
-description: "Use when a Comet change has passed verification and needs archive confirmation, delta spec merge, or archive-phase recovery."
+description: "Use only when explicitly invoked as /comet-archive or routed by the root Comet skill/runtime to the archive phase; confirm archive, merge delta specs, and finish the branch."
 ---
 
 # Comet Phase 5: Archive (Archive)
 
+Before starting or recovering, read and follow `comet/reference/classic-layout.md`. Every OpenSpec CLI call in this file must use the adapter, and every file path must use the `<classic-*>` logical roots bound by that protocol.
+
 ## Prerequisites
 
 - Verification passed (Phase 4 complete)
-- Branch handled
-- `verify_result: pass` in `openspec/changes/<name>/.comet.yaml`
+- Archive commit and branch handling are still pending (`branch_status: pending`)
+- `verify_result: pass` in `<classic-change-dir>/.comet.yaml`
 
 ## Steps
 
 ### 0. Output Language Constraint
 
-Archive summaries and lifecycle closure notes must use the configured Comet artifact language from `"$COMET_BASH" "$COMET_STATE" get <name> language`.
+Archive summaries and lifecycle closure notes must use the configured Comet artifact language from `comet state get <name> language`.
 
 ### 0. Entry State Verification (Entry Check)
 
-Locate scripts via `comet/reference/scripts.md`, then run entry verification. When resuming from any entry point, first run the recovery check in `comet/reference/context-recovery.md`:
+Use the stable `comet` CLI described in `comet/reference/scripts.md`, then run entry verification. When resuming from any entry point, first run the recovery check in `comet/reference/context-recovery.md`:
 
 ```bash
-node "$COMET_STATE" check <name> archive
+comet state select <change-name>
+comet state check <name> archive
 ```
 
 Proceed to Step 1 after verification passes. The script outputs specific failure reasons when verification fails.
 
-### 1. Final Archive Confirmation (Blocking Point)
+If the `select` / `check` output is `BLOCKED` because `bound_branch` does not match the current branch, immediately pause under `comet/reference/decision-point.md` and let the user choose one option: switch back to the bound branch and rerun entry verification, or run `comet state rebind <change-name>` after the user explicitly confirms the current branch should take over this change, then rerun entry verification. Do not switch branches or rebind on your own.
+
+### 1. Final Archive and Delivery Confirmation (Blocking Point)
 
-After entry verification passes, **must follow the `comet/reference/decision-point.md` protocol to pause and wait for the user to confirm whether to archive immediately**. Must not run `node "$COMET_ARCHIVE" "<change-name>"` before user confirmation.
+After entry verification passes, first read `comet state get <change-name> isolation`, then **follow the `comet/reference/decision-point.md` protocol to pause and wait for the user to confirm whether to archive and deliver remotely now**. Must not run `comet state transition <change-name> archive-confirm` or `comet archive "<change-name>"` before user confirmation.
 
 Before confirmation, show the user a brief summary:
 - Change name
 - Verification report path and result
-- Branch handling status
+- Current branch/workspace and attribution summary for pre-existing dirty changes
 - Irreversible actions this archive will perform: merge main specs with OpenSpec delta semantics, annotate design doc / plan, and move the change to the archive directory
+- Remote delivery to perform after archive: push the current bound branch only, or push and then create a PR
 
 The user confirmation question must be presented as a single-select question with these options:
-- "Confirm archive" — immediately run the archive script to complete spec merge and change movement
-- "Needs adjustment or re-verification" — do not archive; run `node "$COMET_STATE" transition <change-name> archive-reopen` to return to `phase: verify`, then invoke `/comet-verify`. If verification confirms fixes are needed, follow `/comet-verify`'s verification-failure decision flow back to `/comet-build`
-- "Do not archive yet" — do not archive; keep the current `phase: archive` state and wait for the user to invoke `/comet-archive` again later
+- "Confirm archive and push now" — complete archive, create the only archive commit, and push the current bound branch
+- "Confirm archive, push now, and create a PR" — complete archive, create the only archive commit, push the current bound branch, and create a PR
+- "Needs adjustment or re-verification" — do not archive; run `comet state transition <change-name> archive-reopen` to return to `phase: verify`, then invoke `/comet-verify`. If verification confirms fixes are needed, follow `/comet-verify`'s verification-failure decision flow back to `/comet-build`
+- "Do not archive yet" — do not run `archive-confirm` or the archive command; keep the active change, `phase: archive`, and `branch_status: pending`, then wait for the user to invoke `/comet-archive` again later
+
+Only after the user selects one of the first two immediate-delivery choices, record that choice and immediately run:
+
+```bash
+comet state transition <change-name> archive-confirm
+```
 
-Only after the user selects "Confirm archive" may Step 2 continue. After the user selects "Needs adjustment or re-verification", must first run the `archive-reopen` state transition; do not edit `.comet.yaml` manually.
+If the transition returns a non-zero exit code, report the error and stop. Only after the transition succeeds may Step 2 continue. After the user selects "Needs adjustment or re-verification", must first run the `archive-reopen` state transition; do not edit `.comet.yaml` manually. After the user selects "Do not archive yet", stop immediately; do not archive, commit, push, or set `branch_status` to `handled`.
 
 ### 2. Execute Archive
 
-Run the archive script to automatically complete all steps:
+Run the archive script:
 
 ```bash
-node "$COMET_ARCHIVE" "<change-name>"
+comet archive "<change-name>"
 ```
 
 The script automatically executes:
-1. Entry state validation (phase=archive, verify_result=pass, archived=false)
+1. Entry state validation (phase=archive, verify_result=pass, archive_confirmation=confirmed, archived=false)
 2. Design doc frontmatter annotation (archived-with, status)
 3. Plan frontmatter annotation (archived-with)
 4. OpenSpec archive for delta-merge semantics and moving the change to the archive directory
@@ -62,6 +75,7 @@ The script automatically executes:
 
 If script returns non-zero exit code, report error and stop.
 If script returns zero exit code, archive is complete.
+
 The summary `X/Y steps succeeded` counts real executed steps and does not double-count delta spec sync or document annotation.
 
 The script calls OpenSpec archive to merge `ADDED/MODIFIED/REMOVED/RENAMED` delta semantics into main specs, then verifies main specs do not contain delta-only section headings.
@@ -75,36 +89,65 @@ Spec lifecycle completes here:
 brainstorming → delta spec → implementation → verification → main spec merge → design doc annotation → archive
 ```
 
-### 4. Commit the Archive Changes
+### 4. Commit Archive Changes with Exact Paths
 
 The archive script only moves files and merges the spec; it does not commit. After archiving, the worktree holds these uncommitted changes:
-- The change directory moved from `openspec/changes/<name>/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`
+- The change directory moved from `<classic-change-dir>/` to `<classic-archive-root>/YYYY-MM-DD-<name>/`
 - The main spec content merged via delta semantics
 - Archive metadata annotations on the design doc / plan
 
-**You must prompt the user to commit these archive changes**, otherwise the archived result stays in the worktree. After showing the pending files, suggest:
+First persist the confirmed delivery choice into archived state, then run the final archive guard:
 
 ```bash
-git add -A
+comet state set <change-name> branch_status handled
+comet guard <change-name> archive
+```
+
+Here, `handled` means only that the user confirmed how to deliver this complete archive commit remotely. It does not mean that push or PR creation has succeeded. Stop without committing or performing remote operations if the state write or guard fails.
+
+After archive, read `git status --short` and compare it with the pre-archive dirty-worktree attribution baseline. Stage only paths attributable to this change: the original active path, actual archive path printed by the command, the archived `.comet.yaml` updated to `branch_status: handled`, main specs changed by this delta, and archive metadata on this Design Doc/Plan. Stop if any path cannot be attributed.
+
+Use explicit pathspecs, then inspect the staged diff. Never stage the whole repository or mix the user's pre-existing changes into the archive commit:
+
+```bash
+git add -- <individually verified archive paths...>
+git diff --cached --stat
 git commit -m "chore: archive <change-name>"
 ```
 
-If branch handling (phase 4) chose not to merge into the main branch yet, finish up via the selected option (merge / PR / keep branch) together with this commit.
+Stop if the commit fails or the staged diff contains unrelated paths.
+
+### 5. Deliver the Archive Commit and Complete
+
+After the archive commit succeeds, perform only the remote delivery method the user confirmed in Step 1:
+
+- "Confirm archive and push now": push the current bound branch once.
+- "Confirm archive, push now, and create a PR": push the current bound branch once, then create a PR using the current platform's available GitHub capability. The explicit Step 1 choice authorizes PR creation; do not substitute another branch disposition.
+
+If push fails, report the error and retain the current selection record; do not clear selection or report completion. Within the current task, retry only that same push. If PR creation fails, the branch already contains the complete archive commit; report the error and retain the current selection record. Within the current task, retry only PR creation. Do not automatically switch, delete, rebase, or rewrite branches after failure.
+
+Only after every remote delivery operation selected by the user succeeds may you run `comet state clear-selection` and report the Classic workflow complete.
+
+Archive no longer invokes Superpowers `finishing-a-development-branch`. Local merge, keeping a branch for later, or postponing push does not immediately produce final remote state, so the user must choose "Do not archive yet" in Step 1 rather than choosing it after archive.
 
 ## Exit Conditions
 
 - Archive script executed successfully (exit code 0)
-- Archive directory `openspec/changes/archive/YYYY-MM-DD-<change-name>/` exists
+- Archive directory `<classic-archive-root>/YYYY-MM-DD-<change-name>/` exists
 - Archived `.comet.yaml` contains `archived: true`
+- Archived `branch_status: handled` is included in the only archive commit
+- `comet guard <change-name> archive` passes
+- The only archive commit was pushed successfully using the delivery method confirmed before archive; if the user selected PR creation, the PR was created successfully
+- Current selection was cleared after remote delivery succeeded
 
-The archive script moves `openspec/changes/<name>/` to `openspec/changes/archive/YYYY-MM-DD-<name>/`.
+The archive script moves `<classic-change-dir>/` to `<classic-archive-root>/YYYY-MM-DD-<name>/`.
 
-> **WARNING**: After successful archive, **do not run** `node "$COMET_GUARD" <change-name> archive` against the old active change name; the active directory no longer exists. Doing so will cause the guard to error with "change directory not found". Archive completeness is determined by script exit code and archived directory state.
+`comet guard <change-name> archive` resolves the actual archive directory from the original change name; do not construct a dated archive path manually.
 
 ## Complete
 
-Comet workflow complete. To start new work, invoke `/comet` or `/comet-open`.
+Comet Classic workflow complete. To start new Classic work, invoke `/comet-classic` or `/comet-open`.
 
 ## Context Compression Recovery
 
-Follow `comet/reference/context-recovery.md` with phase set to `archive`. If `archived: true` and archive directory exists, archival is complete — do not re-execute archive operations.
+Follow `comet/reference/context-recovery.md` with phase set to `archive`. If `archived: true` and the archive directory exists, do not re-execute archive operations. Retry the same push or PR creation only when the current task context explicitly records the remote delivery method selected in Step 1. This Skill does not promise automatic recovery after the user leaves the flow and changes branch topology independently.