Skip to main content
Comet Native can accept a file, attachment, PRD link, or local document and turn its requirements into complete target Specs that can be implemented and verified. When the document already defines the goal, scope, behavior, and failure paths, Native does not repeat question-by-question clarification. After you confirm the final requirements summary, it enters Build and continues through implementation, checks, independent verification, and Archive. This path lets you choose how requirements take shape. You can use Native’s built-in Sequential or Batch clarification, or complete a deeper discussion with Grill me with docs and deliver the resulting document to Comet. Native connects those existing decisions to a stable, long-horizon execution workflow.

​
Use a document as the Native requirements entry point

You can provide requirements in several forms: State what the document is for when you start:
You can express the goal directly when providing a link:

​
Native turns the source into formal requirements

Native does more than preserve a summary. It splits the source by headings, paragraphs, lists, tables, code blocks, examples, constraints, and links, then records each source unit as:
  • complete: the content was read in full and classified;
  • partial: only part of the content was read, so valid requirements may still be missing;
  • unavailable: the current platform or permissions cannot access it.
Native then generates and synchronizes three types of formal content: Every executable source unit must enter the complete target Specs and map to at least one acceptance item. Background information and non-goals keep their classifications and reasons without becoming implementation tasks. When a newer document corrects an older requirement, Native marks the old unit as superseded and points to the active replacement.

​
Skip question-by-question clarification when the document is complete

Native first investigates facts it can determine from the repository, tools, and runtime environment. After mapping the source, it skips Sequential or Batch questions when all of the following are true:
  • all accessible content has been read in full;
  • every active requirement is covered by the Specs and acceptance scope;
  • the document provides one executable interpretation of the goal, scope, default behavior, and failure results;
  • the document does not contain conflicting requirements;
  • repository facts and project rules reveal no additional user choices;
  • no partial, unavailable, unmapped, or unconfirmed blockers remain.
At that point, Native has completed requirements understanding and Spec generation. It can skip question-by-question clarification and present the final requirements summary directly. The summary covers the goal, scope, key decisions, acceptance items, and non-goals. The Runtime allows the Change to enter Build only after you explicitly confirm it.
“Skip clarification” means skipping unnecessary question rounds. Final requirements confirmation remains in place so you can verify that the generated Specs match the document before the Runtime begins long-horizon execution.

​
Ask only about gaps in the document

Document length does not prove that requirements are complete. The following conditions create a [blocking] item:
  • the link requires a login that the current Agent cannot use;
  • the file is damaged, cannot be parsed, or was only partially read;
  • two sections give different answers for the same behavior;
  • wording such as “support failed-request retries” omits semantics that would change user-visible results;
  • an active requirement has not been mapped to a Spec or acceptance item;
  • the material may be debugging evidence, review input, or implementation reference, and its requirements purpose is unclear.
Native asks only about these gaps. It does not repeat questions the document already answers. After a gap is resolved, Native immediately writes the answer into brief.md, the complete target Specs, and acceptance items before moving to final confirmation. If a link is inaccessible, export the source as a file and deliver it to the current conversation. A summary cannot replace the complete source because omitted tables, examples, or constraints may still change the target behavior.

​
Use Grill me with docs for your preferred clarification flow

Native’s clarification protocol is useful when you want to develop requirements from an initial goal. If you prefer the intensive questioning style of Grill me with docs, use it first to discuss product decisions, failure paths, unstated assumptions, and non-goals, then produce a complete document. Deliver that document to Comet afterward:
Comet Native does not depend on Grill me with docs, and external documents do not need to follow a Comet-specific template. Native treats the file as a requirements source, checks its coverage, ambiguity, and acceptance completeness, then takes over the remaining workflow. You can replace the upstream clarification method while continuing to use Native’s Runtime, state recovery, and verification gates.

​
Use Native as a long-horizon task executor

After confirming the document, you can focus on the final result instead of manually advancing the workflow. Native continues by:
  • creating or binding the branch, worktree, and Change workspace;
  • choosing implementation methods within the Specs and maintaining task progress;
  • running required checks and submitting a verifiable Builder candidate;
  • starting a fresh read-only Verifier to inspect the result against acceptance items;
  • returning to Build after failed verification and rechecking the affected scope;
  • recovering from project state after a session interruption, context compression, or device change;
  • completing Archive and the confirmed delivery action after Verify passes.
Native still pauses for new user decisions, inaccessible requirements sources, execution blockers, and final delivery choices. The Agent and Runtime handle ordinary implementation decisions, state transitions, and recovery work.

​
Choose an entry point based on requirements maturity

Native provides its own clarification flow and also accepts requirements you have already developed. You can start Comet with a single goal or a mature document; both paths enter the same recoverable, acceptance-driven execution workflow. Continue reading: Which decisions need your confirmation, Sequential and Batch clarification, Native Loop, and Continuous progression and stable recovery points.
Last modified on August 31, 2026