Comet Any

Investigate real Skills for the user's goal, then author the application's documents, workflow, and business implementation. Use comet creator to preserve the plan and progress. After each stage, read the current action and continue until completion, a user decision, or an external capability blocker.

The Agent writes the entry Skill, business Rule, execution ports, and validators. The SDK preserves the documents, appends execution protocol and common protection rules, and assembles Runtime. Business Rules describe business constraints; Runtime and Guard control actions, approval, and write permissions. Installation uses formal SDK distribution.

Start or resume

1. When the creation name is known, run comet creator status <name> --project <project> --json, then comet creator next <name> --project <project> --json. Preserve the original name and Run; after interruption, inspect the original Action and do not repeat completed work.
2. For a new creation, read comet creator guide --project <project> --json. Determine the goal and installation location from the user's description; ask only about choices that cannot be investigated and would change the result. Start with comet creator start <name> --project <project> --goal <user-goal> --install-target <relative-directory> --host codex|claude-code --json.
3. Before the first claim or action submission, read Creation actions and recovery. Use the returned Action, attempt, inputHash, and the current host session identifier; when the current action lacks a required capability, report the blocker and preserve the current work.

Analysis and plan

The host investigates and authors during analyze. When delegation is needed, carry the original goal, current action, scope, and fixed dependencies.

1. Discover candidates with comet creator candidates --project <project> --json; read each candidate's SKILL.md, scripts, and necessary resources. Inspect actual inputs, outputs, authorization, host capabilities, completion conditions, failures, and recovery. Do not infer capability from a name or modify third-party originals.

2. For every Skill required by the plan:

   Immediately execute: Use the Skill tool to load the <skill-name> skill. Skipping this step is prohibited.

   After the skill loads, use its actual content to complete the adapter contract and content hash. Skills that approve or publish on their own must declare those capabilities and side effects.

3. Choose the starting point the user needs: add steps, guidance, and review to Native; compose Classic at allowed positions in full, hotfix, and tweak; or declare a standalone workflow's order, branches, joins, child workflows, and bounded repair. Include user interaction, shared-understanding confirmation, and implementation steps in Runtime.

4. Write the complete entry Skill: its frontmatter name equals the application id, and description states when it applies. The body explains inputs, dependency Skill calls, interaction and approval, artifacts, acceptance, failure, and recovery. Business Rules constrain the actual business behavior. Put detailed material in references when needed and state when to read it.

5. Return the documents using the reference's documents structure, together with the workflow and business ports. Declare manifest.artifactContracts for each execution stage: real file references, content requirements, and necessary business validators, or noArtifactsReason when no file is required. Supply a positive artifactTests case for every required-artifact stage; business validators also need negative cases that pass the generic file checks. Clarify unknown requirements before authoring. See Creation actions and recovery for the structure. Complete missing documents, implementations, validators, dependencies, or capabilities in the analysis; use revise and reconfirm when a plan already exists.

Confirmation, validation, and delivery

1. When next reaches plan confirmation, show the complete documents, content hashes, actual steps, Skill bindings, artifacts, checks, failure paths, and capability limits. Explain that Eval is optional after compilation.
2. After the user explicitly approves the current plan, submit the user decision for the current confirm-plan. A hash only identifies the plan; having a hash does not grant authorization. Rejection preserves the current work; use revise for plan changes and repeat affected confirmation and validation.
3. Continue calling next to compile, load the application, and verify required artifacts. In isolated directories, the SDK checks that positive cases complete and automatically constructs missing-file, empty-file, and changed-content cases, verifying that rejected results preserve the original Action. Actual business validators must reject their negative cases. These local checks must pass before installation; skipping model Eval does not skip them. On failure, preserve the current work, correct the plan or artifacts, and resume the original Action.
4. At confirm-eval, show the Agent, model, case count, interaction turns, and total timeout, then let the user choose evaluate, skip, or revise. After evaluate, call next to execute and save the report. Retry reuses the original cases; revisions prefer them. Failed or incomplete evaluation stops at review-eval; show the report and uncovered paths, then let the user choose retry, revise, or explicitly skip. Skipping retains the actual status.
5. Before installation, show the export directory, platform entry, fixed dependencies, Runtime, Rule/Hook configuration, conflicts, and Eval status; preview does not write the installation target. Use an install-target export directory separate from platform entries, such as .comet/creator/exports/<application-name>. After the user explicitly approves the current preview, submit confirm-install; Creator exports and formally installs the application. Follow the reference's recovery steps after preview failure or interrupted installation. Changes to the target, dependencies, files, configuration, or evaluation report require confirmation again.
6. Deliver package and entry locations, actual checks, the Eval report, unexecuted items, and limits. Report actual Skill loading, Rule configuration, Hook execution, SDK Run, and business assertions separately; installed configuration does not establish that a Hook has activated.

Recovery boundaries

• Continue with the original Run ID, current Action/Wait, and input hash; do not reuse stale requests.
• Reconcile uncertain execution against the original experiment, process, or artifacts. Preserve the current work and block when reconciliation is unavailable; do not retry blindly.
• Inject credentials only through the execution environment, never into plans, source, generated packages, Runs, or reports.