> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Customize Native with Any

> Add team guidance and candidate review Skills while retaining Native verification and archive requirements.

Your team develops with Comet Native and wants Builder to follow team conventions, with an additional security review after candidate checks pass. Use `/comet-any` to create a separate Native extension application, then use its installed entry.

This tutorial adds authentication security review. Prepare real Skills, confirm the extension plan, validate reports and failure paths, then install and try the application. The creation Agent adapts the Skills and writes the application; you do not need to write SDK code first.

## Where Native can be customized

Tell Any where you want to add work. It selects the extension scope and prepares contracts. Scope names below help you review the plan; you do not need to write SDK configuration.

| Location | Supported customization | Example request | Retained conditions |
| - | - | - | - |
| Builder guidance | Add team conventions, methods, or domain knowledge. | “Follow our authentication error and test conventions.” | Builder retains the original implementation responsibility. |
| After ordinary candidate checks pass (candidate) | Add review or business checks for this candidate. | “Require a security report without blocking findings.” | Original checks, independent Verifier, and candidate binding remain. |
| After Supervisor parent candidate checks pass (parent) | Review the complete parent task. | “Check that children cover all parent requirements.” | A single child result does not replace parent acceptance. |
| After Supervisor child checks pass (child) | Add specialized checks per child. | “Each interface-related child produces a compatibility report.” | Bind checks to that child's candidate and workspace. |
| After Supervisor integration checks pass (integration) | Check the current integrated result. | “Check cross-module interfaces and end-to-end behavior after merging.” | Keep original integration checks; do not reuse pre-merge results. |
| Added step artifacts and acceptance | Define required reports and business conditions. | “Every permission check needs evidence; unchecked items cannot pass.” | Original Native acceptance requirements remain. |
| Added check failure handling | Define blockers, repair requirements, and revalidation. | “Repair the current candidate and review the new one.” | Follow Native recovery and retain original records. |
| Shape, original independent Verifier, user decisions, and Archive | No direct replacement or arbitrary step insertion. | “Skip independent verification and archive directly” is outside supported scope. | Keep requirements confirmation, independent verification, decisions, and archive rules. |

candidate covers ordinary changes; parent, child, and integration cover corresponding Supervisor results. Multiple scopes can be combined with separate inputs and evidence. They do not provide arbitrary timing controls.

Customization changes guidance and adds work in your extension application. Installing it does not turn the default `/comet-native` entry into another workflow. Do not manually edit installed core Skills or generated Runtime files.

## 1. Prepare team Skills

Complete [Comet installation](/en/quickstart.md) and run `comet doctor`. Use Codex or Claude Code with the actual capabilities required by Creator.

This example assumes these project directories exist:

```text theme={null}
team-skills/
  implementation-guide/
    SKILL.md
  auth-security-review/
    SKILL.md
    references/checklist.md
```

Replace the example paths with actual directories. Implementation guidance should cover authentication input checks, error responses, and tests. The review Skill must inspect candidate changes and produce a conclusion, findings, and evidence; a security-related name does not prove those capabilities.

Disclose required test commands, network services, and tools. An unavailable tool is a blocker, not a default finding of no issues.

## 2. Describe the extension to Any

Enter this in the project's Agent session:

```text theme={null}
/comet-any
Name this creation native-team-review and create a Native extension application.
Read the actual content of ./team-skills/implementation-guide and ./team-skills/auth-security-review.
Use implementation guidance for this project's authentication work without replacing Native Builder.
Add security review after ordinary Native candidate checks pass, bound to this candidate and its formal requirements.
Cover input validation, permission checks, sensitive information, and failure responses.
Write reports/auth-security-review.md with Scope, Conclusion, Findings, and Evidence sections.
Unchecked requirements, missing evidence, or unresolved blocking issues must prevent acceptance.
On review failure, return to candidate repair; review the new candidate again.
Retain Native's independent Verifier, user decisions, and Archive requirements.
Show the complete plan, local acceptance samples, and Codex project installation preview for separate confirmation.
```

The Agent investigates dependencies and explains which content supplies guidance, which Skill executes a check, and which host capabilities are missing. If output does not meet the requirements, request an explicit adaptation or revise a Skill you maintain.

## 3. Inspect the candidate review plan

| Item | Expected in this example |
| - | - |
| Base workflow | Native extension retaining implementation, checks, independent verification, and archive. |
| Placement | Candidate scope for ordinary candidates, without automatically covering all Supervisor work. |
| Review input | Current candidate, formal requirements, actual changes, and readable check results. |
| Guidance use | Builder reads conventions; guidance does not replace independent verification. |
| Actual report | A fixed project path, required sections, and real content. |
| Business conditions | Checked requirements with evidence; blockers or unchecked items fail. |
| Failure handling | Preserve the workspace and check the repaired candidate again. |

Read the complete entry Skill, business rules, and validation conditions before deciding. A summary saying “add security review” is insufficient to establish scope or blocking conditions.

For Supervisor, specify whether checks cover each child, the parent candidate, or the integration result. Declare separate inputs and reports for different scopes. One child's passing record cannot serve as acceptance for the entire parent task.

## 4. Validate reports and repair paths

Creator compiles the pinned application and checks artifacts in a temporary project. Require at least these samples:

| Sample | Expected behavior |
| - | - |
| Every requirement checked with evidence and no blockers. | Accept extension results and continue the original Native path. |
| Complete sections but no evidence for permission checks. | Reject through business validation, even though the format is valid. |
| Missing, empty, or hash-mismatched report. | Reject through file validation. |
| Changed candidate with an old report. | Old review cannot establish acceptance for the new candidate. |

Local acceptance validates declared checks, not the real security Skill's judgment quality. If choosing model Eval, include a candidate with an authentication defect and check detection and repair behavior. Models and real hosts that were not tested remain unverified; see [application evaluation](/en/eval/applications.md).

## 5. Install and use the custom entry

The example exports to `.comet/creator/exports/native-team-review/`. Installation also lists platform entries, pinned dependencies, and Rules/Hooks; use actual returned paths. Check entry conflicts and required host activation before confirming.

Load the new entry listed in the target platform and provide a small task:

```text theme={null}
Use the installed native-team-review application to add login input length validation.
Acceptance includes rejecting excessive input, keeping internal information out of error responses,
and a security review report with actual evidence.
```

Use the installed entry name reported by the preview. Confirm Native requirements first, then follow the original Run through implementation, checks, and extension review. Inspect the candidate's report, preserve and repair code when issues are found, and still complete independent verification and user decisions after the extension passes.

Dashboard's **Comet Any** shows creation and application Runs. Linked Native records show requirements, candidates, and original acceptance progress. Observation does not approve or advance a Run.

## 6. Change guidance or resume a task

For interrupted creation, read the same record:

```bash theme={null}
comet creator status native-team-review --project . --json
comet creator next native-team-review --project . --json
```

Replace the name if your actual creation differs. `next` stops for host actions or user decisions; it does not perform security review or approve for you.

To change installed guidance or checks, provide the original package and new requirements to Any, then prepare and confirm a new version. Active business Runs retain their pinned version. Do not replace Skill content inside an existing version and expect an old Run to resume under new rules. See [installation and distribution](/en/skill-creator/publishing.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.