> ## 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 Classic with Any

> Choose full, hotfix, or tweak, replace phase execution Skills, and add checks with artifacts and recovery paths.

Your team uses Classic's Spec workflow and already has API design and compatibility review Skills. Use `/comet-any` to create a Classic composition that assigns them specific work while retaining phase documents, actual checks, user decisions, and archive requirements.

This tutorial creates a full application: a team Skill executes Design, then compatibility review follows successful Verify checks. Install it and try a small interface change.

## 1. Choose the base workflow

| Workflow | Suitable task | Confirm before customization |
| - | - | - |
| full | Complete requirements, design, implementation, verification, and archive. | Which phase execution Skill to replace, along with its original inputs and document requirements. |
| hotfix | A scoped defect. | Whether the work remains a quick repair and where added checks are permitted. |
| tweak | A lightweight change. | Whether new requirements exceed that scope and need the full workflow. |

Replacement applies to execution Skills. Domain machine checks, user decisions, and machine archive steps are outside that replacement scope. Added work uses allowed checkpoints; entry prose cannot relocate Verify or Archive.

This example chooses full. To keep the existing Design Skill and add review only, explicitly request an additional check rather than replacing design execution.

### Which execution Skills can be customized

Describe the phase and desired behavior; Any investigates actual steps, bindings, and input/output requirements. A phase may contain multiple execution steps. The plan should list them separately; replacing one does not replace the whole phase.

| Execution location | Applicable workflows | Supported customization | Retained requirements |
| - | - | - | - |
| Open requirement preparation | full, hotfix, tweak | Replace investigation, clarification, and document-authoring Skills. | Original scope, required documents, and applicable confirmation. |
| Design handoff and documents | full; lightweight workflows after upgrading to full | Use team architecture, interface, or data-design Skills. | Handoff input, design artifacts, checks, and approval. |
| Build configuration and planning | full; after upgrading to full | Customize implementation guidance and task planning. | Original plan requirements and evidence checks. |
| Build implementation | full, hotfix, tweak | Use team implementation or test-first Skills. | Actual code, allowed work scope, and machine checks. |
| Verify report execution | full, hotfix, tweak | Use domain verification Skills for testing and reports. | Required reports and real command results; machine acceptance remains. |
| Archive delivery proposals and execution guidance | full, hotfix, tweak | Customize delivery notes, commit summaries, and execution under the user's decision. | Current approval, archive preflight, machine archive, and actual delivery verification. |

### Where checks can be added

| Original workflow location | Supported added work | Scope and limits |
| - | - | - |
| After Open artifact checks pass | Requirements completeness, business constraints, or domain review. | Selected workflow; its original confirmation behavior remains. |
| After approved Open artifacts pass revalidation | Requirements review before Design. | full; does not replace confirmed-content revalidation. |
| After Design document checks pass | Architecture, interface, security, or maintainability review. | full or the upgraded full path. |
| After Build plan checks pass | Task coverage, dependencies, or implementation scope review. | full or the upgraded full path. |
| After real Build checks pass | Code quality, performance, or additional regression checks. | full, hotfix, tweak; extension success cannot bypass failed original checks. |
| After real Verify checks pass | Compatibility, compliance, or pre-delivery business review. | full, hotfix, tweak; retain original Archive conditions afterward. |
| Multiple extensions at the same checkpoint | Order added checks. | No cross-phase moves or reordering original domain checks. |

Added checks declare actual artifacts, acceptance, and failure recovery. Combine replacements and extensions for multiple phases. Any shows each placement and its relationship to the original flow for your confirmation.

## 2. Prepare design and review Skills

Install Comet and run `comet doctor`. Creator requires actual Skill loading and handoff through Codex or Claude Code.

The example uses:

```text theme={null}
team-skills/
  api-design/
    SKILL.md
    references/api-conventions.md
  api-compatibility-review/
    SKILL.md
```

Replace these paths. The design Skill must read current requirements, existing interfaces, and conventions, then generate actual documents required by Classic. Compatibility review compares old and new behavior, explains caller impact, and produces a verifiable report.

For a Skill that produces only chat summaries, request an adaptation to phase files. Renaming it “Classic Design” does not establish output compatibility.

## 3. Submit the customization goal

```text theme={null}
/comet-any
Name this creation classic-api-review and create a Classic full composition.
Read ./team-skills/api-design and ./team-skills/api-compatibility-review.
Replace the full workflow's Design execution Skill with the team API design Skill.
It must read current requirements and interfaces and produce all required Design documents.
Add compatibility review after actual Verify checks pass, before the original Archive path.
Write reports/api-compatibility.md with Interface changes, Caller impact, Validation evidence, and Conclusion sections.
Explain compatibility for every behavior change. Unresolved breaking changes or missing evidence must fail.
Preserve code and reports on failure; repair, rerun affected checks, and repeat compatibility review.
Retain phase user decisions, real checks, and archive requirements. Do not commit or push Git for me.
Show the complete plan and valid and invalid acceptance samples. Confirm project installation in Codex separately.
```

The Agent selects execution bindings and permitted checkpoints from the actual full definition. You need not write step IDs, but confirm that replacing Design and adding compatibility review are separate operations.

## 4. Read the before and after responsibilities

| Original work | Custom execution | Retained requirements |
| - | - | - |
| Design authoring | Team API design Skill. | Current requirements, required documents, and user confirmation. |
| Build implementation and checks | Original Classic entries. | Actual code, check plan, commands, and current evidence. |
| Verify | Original verification followed by compatibility Skill. | Original report and checks, plus actual review artifacts. |
| Archive and delivery | Original Classic flow and host. | Current approval, archive evidence, and actual Git delivery permission. |

Inspect the design inputs, generated files, and accepted verification result consumed by the new check. Use actual planned artifact paths without targeting Runtime control directories or core state files.

For further changes, add interface version policy or error-code conventions to the design Skill. New responsibilities, artifacts, or failure conditions belong in a freshly confirmed plan, not just edited entry prose.

## 5. Test business conditions with negative samples

| Scenario | Expected behavior |
| - | - |
| New optional parameter, old callers still pass, report has evidence. | Accept compatibility review. |
| All report sections exist, but an old field was removed without migration or evidence. | Reject business conditions despite valid format. |
| Required design or review file is missing. | Reject phase artifacts. |
| Interface or check input changes after review. | Revalidate affected work; old evidence does not cover current output. |

Added reports do not replace original checks. A successful Skill result cannot turn a failed test command into a pass.

After local acceptance, optional model Eval can check document generation, breaking-change detection, and repair continuation. Skipping retains explicit status; see [creation, acceptance, and installation](/en/skill-creator/workflow.md).

## 6. Try an interface task after installation

Review the complete export, entries, pinned dependencies, and Rules/Hooks, then confirm the current installation preview. Use the application separately from default Classic, with the actual installed entry name.

```text theme={null}
Use the installed classic-api-review application to add an optional pagination parameter to a list endpoint.
Existing callers that omit it must retain the original behavior.
Design documents must explain defaults. Verification and compatibility reports must provide actual checks for old and new callers.
```

Inspect the team's actual Design document before deciding. Build and Verify run real commands. Repair and revalidate a failed compatibility report; do not claim completion merely to reach Archive.

Confirm the final delivery scope. Local archive, commit, push, and PR are different decisions; application creation or installation approval does not grant business-task delivery permission.

## 7. Resume and modify the application

For interrupted creation:

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

For an interrupted installed business task, continue its original application Run instead of creating a same-named workflow through Creator. Reconcile unknown executions; see [recovery](/en/sdk/recovery.md).

To replace a design Skill or change review conditions, provide the original package and new requirements, then prepare and confirm a version. Upgrades retain versions required by active Runs. Changing hotfix or tweak to full uses the domain's permitted upgrade path, not direct profile edits in state files.


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