Comet Native

Comet Native

Native saves complete requirements, progress, and acceptance results in the project. The Agent works only on the phase specified by Runtime. After each action, read the latest continuation and follow it until the task is complete, a user decision is needed, or an external dependency blocks progress.

Required rules

• Continue confirmed implementation, document repairs, evidence reuse, and recovery. Pause for new decisions, authorization, or external information. Use current continuation commands, templates, and packages; correct inputs within the same task.
• Treat .comet/config.yaml, the current change, comet-state.yaml, and formal artifacts on disk as authoritative; chat memory is supplementary. Among formal workflow files, the Agent edits only the brief, complete target Specs, association delta.yaml, and children.yaml. Runtime owns state, check results, reports, locks, and transactions.
• Advance through the public comet native CLI on PATH; do not ask the user to run commands manually. If the command is unavailable, report an incomplete installation and stop. Consult comet native <command> --help for arguments.
• Create changes with the CLI; use returned paths and follow denial commands or targets before retrying. Custom and non-Comet writes stay neutral.
• The Builder submits code as the candidate implementation. Each iteration requires a new read-only Verifier to assess every acceptance item independently. Assessing every item does not mean rerunning every command: reuse Runtime check records that still match the current candidate and add only missing or invalidated checks. Failed, blocked, unexecuted, and timed-out work cannot count as passed.
• Run confirmation commands only after the user explicitly confirms the complete Shape, accepts the final result, or selects the relevant delivery option. Reuse confirmed scope and user choices saved by Runtime. Authorization for Archive, merge, push, PR creation, and workspace cleanup is not interchangeable.
• This Skill and Runtime provide the Native workflow without an external Skill dependency. The Agent chooses implementation methods that preserve confirmed requirements and constraints.

Start or resume

1. If the name is known, run comet native select <change-name> --json. When an active change exists, enter the returned workspace.projectRoot; select returns the same discovery and state information as status, so a separate status call is not needed. Otherwise run comet native status --json. Let Runtime locate the workspace; ask the user only when multiple workspaces match equally well.
2. If there is no matching active change, select isolation and create it using workspace selection, then enter preparation.projectRoot. If preparation fails, preserve any branches and directories already created and address the reported cause.
3. After entering the workspace and obtaining phase, retrieve context once using memory integration. Expand details only when needed, record actual use outcomes, handle Project Memory and Personal Memory separately at task completion, and call comet task --complete as specified there.

Never save task summaries, progress, command output, or test results as Personal Memory; complete the learning check.

Project experience and personal preferences are stored separately: before task completion, write project-validated and reusable experience to Project Memory with comet knowledge remember; only user preferences and stable collaboration habits go to Personal Memory. See memory integration for the commands and completion conditions.

Read only what the action needs

Read the section for the current action. Follow links within it only when their stated conditions apply; do not load the entire command reference or all references at once.

• Shape: read and follow clarification, using Sequential or Batch steps according to project configuration. For large requests, follow its Supervisor decomposition and confirmation link before final confirmation.
• Before editing the brief, Specs, or children.yaml, or checking an acceptance report, read formal artifacts. A file, attachment, link, or local path supplied as a requirements source requires source-document full coverage. Material used only for debugging, evidence gathering, review, or implementation reference does not trigger this automatically.
• Before first filling a Runtime template or returning a result through returnAction, read filling command inputs.
• Before submitting a Builder candidate, read Builder handoff. Before launching, adding checks for, or waiting on a Verifier, read Verify protocol.
• When state contains childSummary, read Supervisor coordination before dispatching, receiving results, or integrating. Handle only children listed in readyChildren and Supervisor coordination actions.
• If fields are unclear, input is rejected, a Verifier is unavailable, execution fails, or external information is missing, read command inputs and exceptions. For normal actions, use Runtime's returned commands and templates directly.
• When waiting for external input, follow external input and monitoring; continue independent work. For interruption, a device change, repeated lack of progress, concurrency conflicts, failed migration, or damaged state, read fault recovery.

Shape

Investigate facts that can be established without the user. Ask only about decisions that change user-visible outcomes and cannot be inferred reliably. For simple requests, list unresolved questions and dependencies; maintain a decision tree only when several decisions affect one another. Before asking under native.clarification_mode, save this round's unresolved questions in the brief. Immediately copy confirmed conclusions into the relevant brief sections and complete target Specs. Keep unanswered parts [blocking].

Complete when requirements sources are fully processed within the coverage boundary and classified by purpose, all outcome-affecting decisions and assumptions are resolved, no [blocking] remains, the user explicitly confirms the outcome, scope, key decisions, all acceptance items, and non-goals, and Runtime has entered Build.

New or reconfirmed briefs need outcome, scope, non-goals, and acceptance examples. Add constraints, decisions, open questions, or special verification requirements when applicable. Runtime also checks formal paths and a complete target Spec or concrete no-product-behavior-change reason. Repair reported artifacts and rerun continuation. Existing later-phase changes retain progress until Shape.

Build ↔ Verify Loop

After the Builder submits a candidate, Runtime runs required checks and a new read-only Verifier assesses it. On failure, return to Build, repair, and resubmit. Once every item passes, wait for the user to accept the result.

iteration counts implementation submissions; attempt counts Verifier launches for the same candidate. Runtime updates all counters. When consecutive failures or lack of progress reach configured limits, follow the latest instructions to wait for a user decision or address the blocker.