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

# Compose Skills into an independent workflow

> Build a weekly report application with real inputs, branches, artifacts, approval, and recovery.

You have independent Skills and want them to collaborate under consistent rules instead of explaining the sequence every time. Use `/comet-any` to create a standalone SDK application that records input, steps, files, acceptance, and user decisions together.

This tutorial combines task research, report writing, and source review. The application accepts weekly task records and writes a local publication only after source review and approval of the actual draft. It does not use Native or Classic development phases.

## 1. Describe your goal in natural language

Tell Any what material to work with, what result you want, and which decisions require your approval. Describe it directly or provide existing documents and paths. You do not need to write JSON, a Schema, or an execution request.

For example:

```text theme={null}
I want to generate a project report every week.
Read the task records and acceptance documents I provide to identify completed work.
Do not report ongoing tasks as delivered.
Include Completed this week and Risks and next steps, with readable sources for every completion claim.
Show the draft and source review first. Save the final report in reports/weekly only after my approval.
```

If a detail is unclear, say so. Any investigates the materials and actual Skills, asks for missing information, and proposes inputs, outputs, steps, and acceptance conditions for you to confirm.

| What you provide or confirm | What Any generates or checks |
| - | - |
| The goal, such as a weekly project report. | Application plan, workflow, and entry Skill. |
| Available materials, such as tasks, acceptance documents, or an existing system. | Reading methods, required fields, input structures, and validation. |
| Desired results, such as sections and a save location. | Step outputs, actual paths, file checks, and business acceptance. |
| Decisions, such as approval before publication. | Current-proposal approval, revision, rejection, and recovery paths. |

Review these designs against business requirements; you do not need to name protocol fields or copy SDK requests. Any checks allowed project output paths. For email, website, or other external publication, it explains permissions and reconciliation requirements and waits for your decision.

## 2. Prepare cooperating Skills

This example assumes:

```text theme={null}
team-skills/
  task-research/SKILL.md
  report-writing/SKILL.md
  source-review/SKILL.md
```

| Skill | Input | Result |
| - | - | - |
| Task research | Task records and readable sources. | Accepted tasks, unresolved items, and a source index. |
| Report writing | Organized tasks and the week. | Markdown draft with required sections. |
| Source review | Draft, task list, and actual sources. | Conclusion-to-source mapping and an acceptance result. |

Paths are illustrative. Have the Agent inspect actual content, scripts, and resources for compatible inputs and outputs. Chat-only and file-writing Skills have different responsibilities that must be declared.

## 3. Describe the workflow and approval scope

Enter this in an Agent session supporting Creator:

```text theme={null}
/comet-any
Name this creation weekly-report and compose an independent SDK weekly report application.
Use ./team-skills/task-research, ./team-skills/report-writing, and ./team-skills/source-review.
Read actual Skills. Organize tasks and sources, write a draft, then check sources for every completed-work conclusion.
For each execution I will specify the week and supply task records or existing documents. Design the input and reading method.
Sources must be readable; output stays inside project reports/weekly.
The draft needs Completed this week and Risks and next steps sections. Review maps conclusions to acceptance evidence.
Give every Run separate draft and review files so weeks and Runs do not overwrite one another.
On review failure retain and revise the draft, then review again. Unchecked requirements cannot pass.
Show the actual draft and review before the user chooses local publication, revision, or rejection.
Revised drafts need fresh review and approval; rejection finishes without publication.
Do not send email or deploy a website. Write only the local final report and verify it matches the approved draft.
Show the complete entry, business rules, steps, positive and negative artifact samples, and main workflow acceptance.
Wait for separate plan and installation confirmation.
```

Actual graph dependencies enforce ordering. This example needs research before writing, so it does not require parallel work. For independent sources in parallel, specify join conditions and separate outputs.

## 4. Check the three result paths

The plan should include:

```mermaid theme={null}
flowchart LR
  A[Organize tasks and sources] --> B[Write draft]
  B --> C[Review sources]
  C -->|Fail| D[Revise draft]
  D --> C
  C -->|Pass| E[Show draft and review]
  E -->|Approve| F[Publish local file]
  E -->|Revise| D
  E -->|Reject| G[Finish without publication]
```

| Condition | Purpose |
| - | - |
| Completed tasks have acceptance evidence. | Do not report ongoing work as delivered. |
| Review reads actual sources. | A plausible citation list does not prove support. |
| Draft and review have clear paths and hashes. | Downstream work checks existence and unchanged content. |
| Approval shows the actual draft and review. | The user knows which content is being approved. |
| Publication verifies approved content. | Do not publish a different report afterward. |
| Revision limits and stopping conditions are explicit. | Avoid unbounded failure loops. |

File-producing steps declare actual artifacts. Explain file-free interaction or computation and how results are saved. Inspect negative samples and business validators; see [artifact acceptance](/en/sdk/artifact-validation.md).

## 5. Exercise the workflow, not just files

Standalone applications exercise the actual main workflow in an isolated project. Require these scenarios:

| Scenario | Expected result |
| - | - |
| Complete sources and user approval. | Real draft and review, with publication only after approval. |
| Valid draft sections, but one conclusion lacks acceptance evidence. | Reject and revise; no publication. |
| Review passes and the user rejects publication. | Finish normally without a final published file. |
| User requests changes. | Revised content receives fresh review and approval. |
| Process exits before approval. | Retain the draft and original pending Wait for recovery. |

Also check missing files, empty content, and hash drift. Conversation-only steps still participate in main workflow acceptance; no file is not an exemption.

Isolated checks do not establish actual model-call quality. Model Eval checks real Skill coordination, anomaly detection, approval branches, and recovery. Uncovered paths remain unverified.

## 6. Install and generate the first report

Confirm installation to export the complete package and install platform entries and dependencies. Inspect entry names, output scope, host tools, and Hook activation; see [installation and distribution](/en/skill-creator/publishing.md).

Load the entry reported by installation and describe the task and available materials in natural language:

```text theme={null}
Use the installed weekly-report application for week 2026-W42.
Tasks come from the existing records/week-42.md and acceptance documents are in records/.
Write inside reports/weekly. Show the reviewed draft and wait for my decision on local publication.
```

The first execution should pause to show the draft. Revise, reject, or approve; after approval, check the actual final file against that draft.

On rejection, `completed` means the declared path finished, not that the report was published. Dashboard records creation separately from each application Run: building the application and using it are different processes.

## 7. Resume and add capabilities

For interrupted creation:

```bash theme={null}
comet creator status weekly-report --project . --json
comet creator next weekly-report --project . --json
```

For interrupted report execution, continue the original application Run and Wait rather than running publication again. Query an unknown external operation first. This example publishes locally; external services need additional recovery contracts.

To add translation, publication channels, or child review workflows, provide the original package and new input, output, approval, and failure requirements. Prepare and confirm a new version. Declare effects and reconciliation per channel; one draft approval does not authorize arbitrary sending destinations.


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