Comet Native

Native stores requirements, complete target specifications, current progress, and acceptance conclusions in the project. After completing each phase, it returns to the Runtime to read the next step, and currently only processes the phase specified by the Runtime.

Hard Boundaries

```
.comet/config.yaml
```
, current change,
```
comet-state.yaml
```
, and official Markdown files in the disk are the basis for work; chat memory is only for assistance.
Runtime manages workflow status, local tasks, logs, locks, and transactions; all phase advancements are completed via the
```
comet native
```
command exposed in the PATH.
If the command is unavailable, report incomplete Comet installation and stop. Parameters and output are subject to
```
comet native <command> --help
```
.
Builder submits candidates, and a new read-only Verifier subagent or independent Agent task makes acceptance judgments.
The main Native workflow is completed by this Skill and Runtime, and does not depend on any external Skill.

Start or Resume

When the change name is known, directly run
```
comet native status <change-name> --details --json
```
; only run
```
comet native status --json
```
when the name is unknown, then query the detailed status of the change after determining the target.
Only execute the pagination command in
```
nextPageArgs
```
when the current phase requires a complete acceptance list; only run
```
show
```
or read the corresponding brief/Spec when editing or checking the official content.
When an active change exists, enter the returned
```
workspace.projectRoot
```
and
```
select
```
. Let the user choose only when there are multiple reasonable candidates.
Create a change only when there is no corresponding active change, and use the product directory specified in the configuration.

Create Change

First determine the lowercase kebab-case name, then decide whether to use the current directory, create a branch, or create a worktree according to the Workspace Selection Reference.

The CLI will complete branch or worktree binding, maintain repository local exclusion rules, check the configuration, and create a state that can be restored across devices. Then enter the

preparation.projectRoot

returned by the command.

If the preparation is not completed, retain the already created resources, display the failure reason in

preparation

, and continue according to the recovery direction given by the Runtime or user.

On-Demand Reading

After confirming the phase, only read the required reference:

Shape: Must read and execute the Clarification Reference;
Read the Artifact Reference when actually editing the brief/complete target specifications or viewing the acceptance report;
During normal advancement, directly execute the command given by Runtime in
```
continuation
```
. Only read the Command Reference when the returned field meaning is unclear, command input is rejected, Verifier cannot be started, Verifier execution reports an error, or Verifier requires the user to supplement information;
Only read the Recovery Reference when the task cannot continue due to process interruption, missing local status after switching devices, no progress for consecutive rounds, concurrency conflicts, failed migration from old versions, or damaged status.

Shape

First investigate the facts that can be determined from the repository, tools, and operating environment; independent facts can be assigned to subagents for investigation. Maintain the decision tree according to

native.clarification_mode

and the Clarification Reference, and only hand over decisions that will change user-visible results and cannot be reliably inferred to the user.

Immediately synchronize the confirmed user-visible decisions and important constraints to Decisions, brief, and complete target specifications; keep ordinary implementation choices in implementation and testing, and only enter formal requirements when they affect user-visible behavior. Acceptance items must be specific, observable, and non-repetitive.

Unresolved issues remain marked as

[blocking]

; do not modify the project implementation when there are blocking items. Completion criteria: All choices that affect user-visible results and unstated assumptions have been processed, there are no

[blocking]

items, the user explicitly confirms the goal, scope, key decisions, acceptance items, and non-goals, and the Runtime has entered Build. Only use commands with

--confirmed

in subsequent instructions to advance after the user explicitly confirms.

Build ↔ Verify Loop

Build and Verify form a bounded acceptance loop: Builder submits candidates, Runtime performs necessary checks, and then a new read-only Verifier conducts acceptance. When acceptance fails, return to Build, complete modifications, and submit the next round of candidates; when all items pass, enter Archive.

iteration

represents the round of implementation candidates, and

attempt

represents the number of times Verifier is started for the same candidate. When consecutive failures occur, there is no actual progress, or Verifier execution errors occur multiple times, Runtime will enter a waiting for user or blocked state at the budget upper limit. All counts are updated by Runtime, and Agent only executes the latest

continuation

Build

When implementing for the first time, read the current brief, complete target specifications, and all acceptance items. If Verify fails and returns to Build, first handle the failed items pointed out by Verifier, problems that prevent continued verification, and failed checks; recheck the complete specifications and all acceptance items before submitting again to avoid only fixing error points and missing other requirements.

When requirements change, first determine the attribution:

Current requirements only have missing implementations: Return to Build from Verify or Archive using
```
--return-to-build
```
;
User-visible behavior or acceptance standards change: Return to Shape, update official artifacts, and reconfirm;
Unrelated to current requirements: Reserve for another change.

When the user explicitly supplements the current scope, handle it according to the same rules.

After completing the candidate, submit a streamlined Builder handoff summary according to the input template provided by Runtime in

continuation

, including: what was done in this round, which acceptance items were handled, which development-phase checks were actually run or not run, and what known limitations remain.

This handoff is stored in

comet-state.yaml

, does not generate a separate file, and does not mean acceptance has been passed. Runtime will hand it over to Verifier, and Builder only needs to submit it once.

Completion criteria: The implementation and related checks reach an acceptable state, all acceptance items have been rechecked, and Runtime accepts the handoff and enters Verify.

Verify

When Runtime requires starting the Verifier (

dispatch-verifier

), first fill the test and check commands that need to be run for the current candidate into

inputOptions.template

, and Runtime will execute them uniformly. Runtime will reuse completed checks; whether to retry or supplement checks is subject to the latest

continuation

After Runtime returns

verifierDispatch

, immediately start a new read-only Verifier subagent. If the platform does not support subagents, start a new Agent task separate from the Builder session.

Verifier first reads the acceptance items, brief, complete target Spec, actual implementation, and Runtime check results, and finally uses the Builder handoff as an investigation clue to maintain independent acceptance judgments.

Verifier remains read-only. If existing checks are insufficient, list the additional checks that need to be run in

inputOptions.template

returned by Runtime, and Runtime will execute them and return the results to Verifier.

Verifier must finally mark each item as

passed

failed

, or

blocked

, with no omissions or duplicates. When items fail or cannot be verified, write the reasons that can be directly handled in the next round of Build. When Verifier cannot be started, Verifier execution errors occur, or external information is missing, handle according to the Command Reference and latest

continuation

Completion criteria: Runtime has accepted the complete Verifier results and clearly enters one of the states: Build, Archive,

await-user

blocked

, or

done

Subsequent Instructions

Only process the latest

continuation

after each command:

```
continue
```
: Execute
```
commandArgs
```
and fill
```
inputOptions
```
according to the template;
```
await-user
```
: Wait for the listed user decisions;
```
blocked
```
: First handle the listed blocking reasons or recovery actions;
```
done
```
: End.

After executing commands that modify the status, re-query the detailed status of the change to confirm the current phase, acceptance loop, status version, and working directory. Only run

show

when official content is needed.

comet-native

NPX Install

Tags

SKILL.md Content (Chinese)