Customize Classic with Any

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:

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

/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.

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.

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:

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. 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.

Start authoring

Practical tutorials

Authoring and validation

Installation and recovery

Related commands

Customize Classic with Any

1. Choose the base workflow

Which execution Skills can be customized

Where checks can be added

2. Prepare design and review Skills

3. Submit the customization goal

4. Read the before and after responsibilities

5. Test business conditions with negative samples

6. Try an interface task after installation

7. Resume and modify the application

​1. Choose the base workflow

​Which execution Skills can be customized

​Where checks can be added

​2. Prepare design and review Skills

​3. Submit the customization goal

​4. Read the before and after responsibilities

​5. Test business conditions with negative samples

​6. Try an interface task after installation

​7. Resume and modify the application

1. Choose the base workflow

Which execution Skills can be customized

Where checks can be added

2. Prepare design and review Skills

3. Submit the customization goal

4. Read the before and after responsibilities

5. Test business conditions with negative samples

6. Try an interface task after installation

7. Resume and modify the application