Skip to main content
The open phase will turn your ideas into an executable change: explore requirements, clarify scope, create proposals/designs /tasks, and initialize the Comet state. From your perspective, this is a “guided conversation” - Comet will repeatedly ask you questions to make sure you understand correctly before starting to write the document.
Normally, you only need /comet. When the project configuration selects Classic, /comet forwards to /comet-classic. It recognizes intent, reads file state, determines that the workflow is in the open phase, and invokes /comet-open. This page documents the internal phase Skill; enter it directly only when you want to control the phase manually. See How this phase is triggered.

​
How is this stage triggered

/comet-open is commonly routed automatically after /comet enters Classic. The internal /comet-classic reads the active change list and file state, builds routing context, and then runtime scoring decides which phase to enter.

​
Default: Use /comet for automatic recognition

Each time /comet-classic is called, the file state is re-read (not dependent on the dialogue history), and it is routed to the open phase under the following conditions: You just need to enter /comet and describe what you want to do. After the configuration is selected as Classic, the internal /comet-classic will determine whether a new change needs to be created and automatically connect to design after the open is completed. For details, please refer to Automatic Propulsion Mechanism

​
Manual: When is direct /comet-open needed

  • The auto-transition (auto_transition: false) is turned off - at this point, /comet-classic will stop after advancing through one stage, and you need to manually call the Skill of the next stage.
  • I just want to run the open phase alone (debugging or inserting manual reviews between phases).
Use the unified entry /comet normally; The stage command is directly invoked only during the manual control stage. **

​
Select the workspace when creating a Change

When creating a Classic change, Comet confirms the workspace before generating the OpenSpec product and state file:
  • current: Work serially in the current branch;
  • branch: Create an independent branch, but still use the current directory;
  • worktree: Create or reuse an independent worktree, suitable for parallel work or when the current directory has been modified.
If there is already a registered worktree with matching branches, Comet will directly reuse it. When the branch still exists but the worktree is missing, it will be rebuilt during the recovery process. You just need to select as prompted by /comet. Do not manually copy the change directory.

​
What will you experience

The open phase gradually generates the document through multiple rounds of dialogue and multiple pause points. Ask questions and produce documents in the language you used when triggering the workflow throughout the process.

Little Fish clarifies and confirms vague ideas and organizes them into three documents: proposal, design, and tasks.

In the

open stage, the vague ideas are filtered into three executable OpenSpec products:

​
The first step: Explore ideas and clarify requirements

Comet loads openspec-explore, and continuously asks questions around your ideas until a complete clarification summary can be compiled. It won’t take a single question-and-answer session as “enough” - it will keep asking until all five parts are clear:

​
Pause point 2: PRD split pre-check (conditional trigger)

If your input is a ** large PRD, roadmap or complete product plan **, or if ** multiple independent capabilities ** appear in the clarification summary, Comet will pause here and provide you with a ** candidate split list ** (each split item includes a suggested name, target scope, non-target, dependency order, core acceptance scenario) Then let you choose one of the three:
After splitting, Comet will not automatically advance any individual change to “design. It will pause to ask you which one you want to do first, only advancing the one you chose, keeping the rest active, and then use /comet restored.

​
Pause point 3: Workspace decision

Before creating the artifacts and .comet.yaml, Comet asks you to settle the workspace isolation method (this step cannot be postponed to build): The choice is written to isolation; the current branch of the actual working directory is recorded as bound_branch, and later entry checks block accidental branch switches. The hotfix/tweak presets default to current. Requirement clarification and naming are non-blocking: when the scope and the name are clear, Comet derives the single kebab-case English name from the requirements (for example refine-requirements-doc) and shows it directly. It only asks separately when a mutually exclusive choice would change the scope or the identity of the change, or when the name conflicts with an existing change. It will not create proposal/design/tasks before confirmation, nor will it generate them all at once using openspec-propose.

​
Step 2: Create the change structure

Load openspec-new-change. The complete workflow ** does not load by default ** openspec-propose (generate all at once), and is only allowed when you explicitly request it. Comet uses the ** standard product loop ** to generate Proposals → designs → tasks one by one:
  1. Refresh status: openspec status --change "<name>" --json
  2. Obtain the instruction: openspec instructions proposal|design|tasks --change "<name>" --json
  3. Read dependencies, follow template and instruction, apply context/rules constraints (** Do not copy to the document content **), write to resolvedOutputPath
  4. Refresh the status for confirmation after each artifact
If openspec instructions fails, returns invalid JSON, or does not provide a usable resolvedOutputPath, Comet will stop immediately and report the OpenSpec error. It will not fall back to a hard-coded document structure, because that would bypass project rules. The Change name must be the kebab-case name you confirmed. Comet will not expand or narrow the scope on its own.

​
Step 3: Entry status verification + content integrity check

Then, confirm one by one that the three files exist and are not empty: proposal (background/objective/scope), design (architecture decision/selection/data flow), and tasks (task description). If any one is missing or empty, Comet will not continue but return to the creation step.

​
Pause point 4: Review the three documents and confirm

Comet presents the summaries of three documents to you (the background and target scope of the proposal, the architecture decision selection of the design, the number of tasks and key tasks of the Tasks), and then asks you to ** choose one ** :

​
Exit: Advance to the next stage

--apply is essential - without it, .comet.yaml will stop at phase: open, and the next stage of the entrance check will fail. full workflow advances to phase: design; hotfix/tweak directly jumps to phase: build (skips design).

​
The invoked skill

The complete workflow defaults and does not load , , openspec-propose (Generate all artifacts at once). It is only allowed when explicitly requested by the user.

​
Product

The following figure uses <classic-root> to represent the current Classic OpenSpec root directory: The default for new projects is docs/openspec/, and for projects that retain the old layout, it is openspec/. The actual position is determined by classic.artifact_layout in .comet/config.yaml.
<classic-root>/changes/<name>/
.openspec.yaml
.comet.yaml
proposal.md
design.md
tasks.md
Initialize the Comet state

​
Idempotence: It can be safely repeated

All operations in the open phase can be safely repeated. If .comet.yaml already exists in phase: open and all three products are present, Comet will ** skip the completed steps ** and continue from the first missing step. This ensures that even if you call /comet again after an interruption, the state will not be disrupted.

​
Pause points at a glance

There are 3 pause points in the open phase (globally numbered 2-4, with a total of 10 in the entire five-stage workflow. See Five-stage Pause Points and User Selection points ) : Requirement clarification and naming are non-blocking by default: when the scope and the name are clear, Comet derives the single kebab-case English name from the requirements and shows it directly; it only asks separately when a mutually exclusive choice would change the scope or the identity of the change. All pause points follow the Decision Point Protocol - Comet cannot replace your explicit choice with recommendation rules, default values, or “users should agree”

​
Q&A

Do not bypass with /opsx:new - it only creates OpenSpec artifacts and does not create .comet.yaml. change will fall outside the Comet state machine. Re-run /comet; After entering the Classic configuration, the status will be completed through /comet-open.
It must be kebab-case English (lowercase letters, numbers, hyphens). Chinese or non-compliant names are converted to kebab-case; when only one name exists, Comet uses and shows it directly, and only reports and asks you to choose when there are multiple candidates or a conflict with an existing change.
Comet will immediately stop the creation of the artifact and report the OpenSpec The error will not revert to a hard-coded document structure. Check the OpenSpec CLI Is it normal? Does template/instruction/dependencies meet the requirements?
Not necessarily. The split pre-check will give you one choice among three options (split/keep one/adjust the plan). You can choose to keep it as one change, but you need to record the reasons for not splitting it in the document.

​
Next step

  • After the design phase ](/en/phases/design)-OPEN is completed, proceed to in-depth design
  • Detailed explanation of the pause points of the five-stage pause point and the user selection point ](/en/concepts/decision-points)-open
  • The complete mechanism of large PRD splitting ](/en/guides/prd-splitting)-STEP 1a
  • How does the automatic propulsion mechanism ](/en/concepts/auto-transition)-OPEN automatically connect to design after completion
Last modified on September 4, 2026