Your first repeatable task

Your first repeatable task in CMDOP should begin as an ordinary conversation, not as automation. Ask a joined machine to do one small, checkable thing, read the result, and only then decide whether it stays a conversation, becomes a version-controlled script, or is packaged as a Skill. Automating a process you have not yet reviewed is the mistake this order prevents.

Start with a small, useful task in a browser conversation. Review the result, then decide whether the work should remain a conversation, become a script, or be packaged as a Skill. This order keeps the first experience simple and avoids automating an unreviewed process.

Pick something small

Good first tasks are bounded and easy to check:

• “Summarize the recent errors in this machine’s logs.”
• “Review the status of this repository and suggest the next small change.”
• “Find large files in this project and explain what can be cleaned up.”

Use a machine you can inspect and a Project Root when the task concerns a repository.

1. Start a conversation

1. Open the joined machine’s web console.
2. Start or resume a conversation.
3. Select a Project Root if the task needs repository context.
4. State the outcome and any constraints in plain language.
5. Review the result before asking for a follow-up.

The conversation is durable, so you can return to the same work later instead of rebuilding its context from a new prompt.

2. Make the task repeatable only when it is understood

For deterministic work, a version-controlled script or configuration-management tool may be the best long-term home. For a reusable instruction capability, use the supported Skill authoring boundary.

cmdop skill create, cmdop skill check, and cmdop skill pack create, validate, and package a local Skill project. They do not execute the Skill. Check the help for the installed Cmdop version before changing a machine:

cmdop skill --help
cmdop skill create --help
cmdop skill check --help
cmdop skill pack --help

Runtime availability, installation, and publication are separate from local authoring. Do not assume a packaged Skill is automatically available to a conversation or another machine.

3. Keep the review loop

Before making work unattended or widely reusable:

• keep the input and expected result explicit;
• review changes and outputs with the responsible person;
• choose a deterministic tool when repeatability matters;
• check current product and CLI documentation for the supported lifecycle.

What to do next

Related

• First connection
• Quickstart
• Skills overview

Common questions

What should my first Cmdop automation be?

Start with a small reviewed conversation on a joined machine. Ask for one bounded, checkable result, review it, then decide whether the task should remain a conversation, become a script, or become a Skill.

When should I turn a task into a Skill?

Use a Skill when the task is a reusable instruction capability that should be available by name on machines where it is installed. Do not package work you have not first reviewed in a normal session.

Does packing a Skill make it available everywhere?

No. Authoring, packing, publishing, installation, and runtime availability are separate. A packaged Skill is not automatically installed on a machine or available to another conversation.