New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Comet Open

by rpamis in rpamis/comet

Comet Phase 1: Open. An agent skill from rpamis/comet.

MITAuto-check passedProduct & Project Management

Install Comet Open

skills CLI
$ npx skills add rpamis/comet --skill comet-open -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rpamis/comet comet-open --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rpamis/comet.git skills-src && mkdir -p .claude/skills && cp -r skills-src/eval/local/skills/benchmarks/039-release/comet-classic-039-open .claude/skills/comet-open && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
comet-open
GitHub stars
3.2k
Token cost
~3.4k tokens
SKILL.md length
1,683 words
Files
1
Skills in repo
52
Repo updated
First seen
Licence
MIT

At a glance

Comet Phase 1: Open. An agent skill from rpamis/comet.

  • Works in 6 steps: Output Language Constraint → Explore Ideas and Clarify Requirements → Create Change Structure + Initialize State → …
  • Product & Project Management work in your project
  • SKILL.md covers Prerequisites, Steps, Exit Conditions and Automatic Handoff to Next Phase
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Comet Open is an agent skill from rpamis/comet. Comet Phase 1: Open. Invoke with /comet-open. Explore ideas through OpenSpec, confirm requirements clarification, then create change structure (proposal + design + tasks).

Its SKILL.md is about 3.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Product & Project Management. The repository describes itself as: Comet: agent skill harness for turning ideas into evaluated workflows. The licence is MIT.

When your agent uses it

  • Product & Project Management work in your project

Example prompts

  • “/comet-open”

Workflow steps

6 steps, taken from the step headings in SKILL.md.

  1. Output Language Constraint
  2. Explore Ideas and Clarify Requirements
  3. Create Change Structure + Initialize State
  4. Entry State Verification
  5. Content Completeness Check
  6. User Review and Confirmation (Blocking Point)

What it can do on your machine

Read from SKILL.md and the folder at commit c28e724. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are bash).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Comet Open loads about 3.4k tokens when it runs. Until then it costs about 46 tokens; SKILL.md has 1,683 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~46
When it runs · the whole SKILL.md, loaded when a task matches
~3.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rpamis/comet at commit c28e724, republished under its MIT licence (© rpamis). 1,683 words, ~3,354 tokens.

Download SKILL.mdSave it as .claude/skills/comet-open/SKILL.md (or your agent's skills folder).
name
comet-open
description
Comet Phase 1: Open. Invoke with /comet-open. Explore ideas through OpenSpec, confirm requirements clarification, then create change structure (proposal + design + tasks).

Comet Phase 1: Open

Prerequisites

  • No active change, or user wants to create a new change

Steps

0. Output Language Constraint

Every prompt and artifact request passed to OpenSpec must include the output-language constraint: use the language of the user request that triggered this workflow. When resuming an existing change with a clear dominant artifact language, preserve that language unless the user explicitly asks to switch.

1. Explore Ideas and Clarify Requirements

Immediately execute: Use the Skill tool to load the openspec-explore skill. Skipping this step is prohibited.

After the skill loads, explore the problem space following its guidance, but do not treat one Q&A turn as sufficient clarification. You must continue asking, align with the user, and form a clarification summary covering:

  • Goals: the problem the user truly wants to solve and the expected outcome
  • Non-goals: what is explicitly out of scope for this change
  • Scope boundaries: included/excluded modules, users, platforms, or data
  • Key unknowns: unresolved assumptions, risks, or dependencies
  • Draft acceptance scenarios: at least the core success scenario and important boundary scenarios

The clarification summary must include: goals, non-goals, scope boundaries, key unknowns, and draft acceptance scenarios.

1a. PRD Split Preflight (Blocking Point)

When the user input is a large PRD, roadmap, complete product plan, or the clarification summary shows multiple independent capabilities, modules, user journeys, or milestones, must evaluate whether it should be split into multiple changes before creating OpenSpec artifacts.

The split preflight must be based on clarified information and output a proposed split list. Each proposed split item must include:

  • Suggested change name
  • Goals and scope boundaries
  • Explicit non-goals
  • Dependencies or recommended execution order
  • Core acceptance scenarios

Recommend splitting when any condition applies:

  • The PRD contains multiple capabilities that can be independently designed, built, verified, and archived
  • Multiple modules or user journeys are involved, and part of them can be delivered independently
  • Clear phased milestones exist
  • The work is expected to produce multiple delta specs or more than 3 large tasks
  • Failure or delay in one part should not block other parts from entering later phases

When splitting is recommended, must follow the comet/reference/decision-point.md protocol to pause and wait for the user's choice.

The user choices must include:

  • "Create multiple OpenSpec changes" — create independent changes from the proposed split
  • "Keep everything as one change" — continue the single-change flow and record the reason for not splitting in proposal/design/tasks
  • "Adjust the split plan before continuing" — after the user describes the adjustment, output the revised proposed split list and ask for confirmation again

Every accepted split item must be created as an independent change through /comet-open, not by calling /opsx:new directly. /comet-open creates both OpenSpec artifacts and .comet.yaml, ensuring each change enters the Comet state machine.

Must not create proposal.md, design.md, or tasks.md before the user completes the PRD split choice. If the user chooses to create multiple changes, the current /comet-open invocation only completes split confirmation and coordination, then enters /comet-open for each split item in the user-confirmed order.

In batch split mode, entering /comet-open for each split item must explicitly mark it as a "confirmed split item" and carry that split item's goals, scope, non-goals, and acceptance scenarios. Confirmed split items skip the PRD split preflight by default, unless the split item itself still clearly contains multiple independent capabilities.

In batch split mode, a single split item must not auto-advance to /comet-design after completing the open phase. After splitting is complete, must pause and ask the user which change to start; after the user chooses, advance only that change into /comet-design, while other changes remain active and can be resumed later through /comet.

Minimal resume rule: do not add a dedicated batch state file. On resume, first check already-created active changes; split items that already exist and contain .comet.yaml must not be created again, while uncreated split items continue through /comet-open according to the user-confirmed split list. If the confirmed split list cannot be recovered from the conversation, must ask the user to confirm the split list again before continuing.

1b. Requirements Clarification Completion Confirmation (Blocking Point)

Before creating OpenSpec artifacts, must follow the comet/reference/decision-point.md protocol to pause and wait for the user to confirm requirements clarification is complete.

When pausing, present the clarification summary: goals, non-goals, scope boundaries, key unknowns, and draft acceptance scenarios.

Must not create proposal.md, design.md, or tasks.md before the user confirms requirements clarification is complete, and must not use the Skill tool to load the openspec-propose skill to generate all artifacts in one pass.

1c. Change Name Confirmation (Blocking Point)

Before creating the change directory (openspec new change), must follow the comet/reference/decision-point.md protocol to pause and let the user decide the change name. Must not auto-generate or silently infer the change name.

OpenSpec change names must be kebab-case English (lowercase letters, digits, hyphens; e.g. refine-requirements-doc). Chinese or other non-conforming names are invalid.

When pausing, present:

  • 2-3 recommended kebab-case English names derived from the confirmed clarification summary, each with a one-line description of the scope it implies
  • An explicit option for the user to enter their own name
  • A note that if the user enters Chinese (or any non-kebab-case text), it will be converted into a compliant kebab-case English name, and the converted result must be shown back to the user for confirmation before use

The decision options must include:

  • Pick one of the recommended names
  • "Enter a custom name" — accept the user's input; if it is already valid kebab-case English, use it directly; if it is Chinese or otherwise non-conforming, convert it to compliant kebab-case English and show the converted name for confirmation before continuing

Must not run openspec new change or create .comet.yaml before the user confirms the final change name. If the chosen/converted name collides with an existing change, report the collision and ask the user to choose another name.

Show full SKILL.md (741 more words)Show less
2. Create Change Structure + Initialize State

Immediately execute: Use the Skill tool to load the openspec-new-change skill. Skipping this step is prohibited.

Full /comet workflow must not use the Skill tool to load the openspec-propose skill by default; only load it when the user explicitly requests generating the proposal and artifacts in one pass.

After the skill loads, follow its guidance to create the change skeleton, but override its "STOP and wait for user direction" behavior when a confirmed clarification summary from Step 1b is already available in the conversation context.

If the user has already confirmed a clarification summary (Step 1b), use that summary directly to populate artifact content. If no clarification summary exists (edge case), fall back to the skill's default behavior of asking the user.

After the change skeleton is created, generate proposal, design, and tasks one by one using the standard artifact loop:

Standard Artifact Loop (for each artifact-id: proposal → design → tasks):

  1. Refresh status: openspec status --change "<name>" --json

  2. Fetch artifact instructions:

    bash
    openspec instructions proposal --change "<name>" --json
openspec instructions design --change "<name>" --json
openspec instructions tasks --change "<name>" --json

  3. For the returned JSON instruction payload, you must:

    • Read every completed dependency artifact listed in dependencies
    • Use template as the artifact structure
    • Follow instruction guidance
    • Apply context and rules as constraints — must not copy them into the artifact content
    • Write to resolvedOutputPath
    • Verify the output file exists and is non-empty

  4. After creating each artifact, re-run openspec status --change "<name>" --json to confirm status before continuing to the next artifact

Failure handling: If openspec instructions fails, returns invalid JSON, reports unmet dependencies, or does not provide a usable resolvedOutputPath, must immediately stop artifact creation and report the OpenSpec error. Must not fall back to hard-coded artifact prose because that would silently bypass project rules.

Naming and scope guard: Change name must be the kebab-case English name confirmed by the user in Step 1c — must not auto-generate, infer, or use a non-kebab-case (e.g. Chinese) name. Change scope must match the user's description — must not expand or narrow it independently.

Confirm the following artifacts have been created:

openspec/changes/<name>/
├── .openspec.yaml
├── .comet.yaml
├── proposal.md       # Why + What: problem, goals, scope
├── design.md         # How (high-level): architecture decisions, approach selection
└── tasks.md          # Task checklist (checkboxes)

Create .comet.yaml state file:

bash
COMET_ENV="${COMET_ENV:-$(find . "$HOME"/.*/skills "$HOME/.config" "$HOME/.gemini" -path '*/comet/scripts/comet-env.sh' -type f -print -quit 2>/dev/null)}"
if [ -z "$COMET_ENV" ]; then
  echo "ERROR: comet-env.sh not found. Ensure the comet skill is installed." >&2
  return 1
fi
. "$COMET_ENV"

if [ -z "$COMET_STATE" ] || [ -z "$COMET_GUARD" ]; then
  echo "ERROR: Comet scripts not found. Ensure the comet skill is installed." >&2
  return 1
fi

"$COMET_BASH" "$COMET_STATE" init <name> full
3. Entry State Verification

Verify state machine has been correctly initialized:

bash
"$COMET_BASH" "$COMET_STATE" check <name> open

Proceed to Step 4 after verification passes. The script outputs specific failure reasons when verification fails.

Idempotency: All open phase operations can be safely re-executed. If .comet.yaml is already at phase: open and all three artifact files exist, skip completed steps and continue from the first missing step.

4. Content Completeness Check

Confirm the three documents have complete content:

  • proposal.md: problem background, goals, scope, non-goals
  • design.md: high-level architecture decisions, approach selection, data flow
  • tasks.md: task list, each task has a clear description

File existence verification: Confirm all three file paths exist and are non-empty. If any file is missing or empty, must not enter Step 5 or execute phase guard — return to creation step to fill the gap.

5. User Review and Confirmation (Blocking Point)

After the three documents are created and content completeness check passes, must follow the comet/reference/decision-point.md protocol to pause and wait for user confirmation. Must not execute phase guard or auto-transition before user confirmation.

The user confirmation question must be presented as a single-select question with the following summary and options:

Summary content:

  • proposal.md: problem background, goals, scope
  • design.md: high-level architecture decisions, approach selection
  • tasks.md: task count and key task descriptions

Options:

  • "Confirm, proceed to next phase" — artifacts meet expectations, execute phase guard transition
  • "Needs adjustment" — include adjustment notes, modify and re-request confirmation

After user selects "Confirm", proceed to exit conditions. When user selects "Needs adjustment", modify the corresponding files per their notes, then request confirmation again.

Exit Conditions

  • proposal.md, design.md, tasks.md all created with complete content
  • User has confirmed proposal, design, tasks content meets expectations
  • Phase guard: Run "$COMET_BASH" "$COMET_GUARD" <change-name> open --apply; after all PASS, auto-transitions to next phase

Must use --apply before exit, otherwise .comet.yaml remains at phase: open and the next phase entry check will fail.

bash
"$COMET_BASH" "$COMET_GUARD" <change-name> open --apply

Full workflow auto-transitions to phase: design; hotfix/tweak presets auto-transition to phase: build.

Automatic Handoff to Next Phase

Follow comet/reference/auto-transition.md. Key command:

bash
"$COMET_BASH" "$COMET_STATE" next <change-name>
  • NEXT: auto → invoke the skill pointed to by SKILL to enter the next phase
  • NEXT: manual → do not invoke the next skill; prompt user to run /<SKILL> manually
  • NEXT: done → workflow is complete, no further action needed

hotfix/tweak presets are controlled by their corresponding preset skill (phase goes directly to build); their next returns the corresponding preset skill.

© rpamis, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in eval/local/skills/benchmarks/039-release/comet-classic-039-open of rpamis/comet.

Open the folder on GitHubat commit c28e724

Compare with similar skills

Comet Open next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Comet Open compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Comet Open this skillrpamis/comet3.2k—~3.4kAutomated safety check: PassMIT
User Story Writerdeanpeters/Product-Manager-Skills7.2k2 repos~2.9kAutomated safety check: PassCustom licence
Game Changing FeaturesopenstatusHQ/data-table-filters2.3k3 repos~2.1kAutomated safety check: PassMIT
CCPM Project Managementautomazeio/ccpm8.4k—~1.1kAutomated safety check: PassMIT
Convex Create Componentspokvulcan/poker-planning1148 repos~2.6kAutomated safety check: PassMIT
Self Improving Agentfarm-fe/farm5.6k2 repos~3.3kAutomated safety check: NotesMIT

Similar skills

  • User Story Writer

    deanpeters/Product-Manager-Skills

    Writes user stories in Mike Cohn's format with Gherkin acceptance criteria, turning user needs into development-ready work with testable conditions.

    7.2k GitHub starsUsed in 2 repos~2.9k tokens
    Product & Project ManagementAuto-check passed

  • Game Changing Features

    openstatusHQ/data-table-filters

    Find 10x product opportunities and high-leverage improvements.

    2.3k GitHub starsUsed in 3 repos~2.1k tokens
    Product & Project ManagementAuto-check passed

  • CCPM Project Management

    automazeio/ccpm

    Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.

    8.4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Product & Project ManagementAuto-check passed

  • Convex Create Component

    spokvulcan/poker-planning

    Builds reusable Convex components with isolated tables and app-facing APIs.

    114 GitHub starsUsed in 8 repos~2.6k tokens
    Product & Project ManagementAuto-check passed

  • Self Improving Agent

    farm-fe/farm

    A universal self-improving agent that learns from ALL skill experiences.

    5.6k GitHub starsUsed in 2 repos~3.3k tokens
    Product & Project ManagementAuto-check: notes

  • Weekly Engineering Retro

    garrytan/gstack

    Builds a weekly engineering retrospective from git history: commit counts, per-person contributions, work patterns and code quality numbers over a chosen window.

    136k GitHub stars~2.4k tokensUpdated today
    Product & Project ManagementAuto-check passed

More from rpamis/comet

All 52 skills in this repo

  • Comet

    rpamis/comet

    A skill your agent uses when 用户要启动或恢复 Comet 工作流，需要根据 active change、.comet.yaml、hotfix/tweak 意图路由到对应阶段 Skill。

    3.2k GitHub stars~2.7k tokensUpdated today
    Auto-check passed

  • Comet

    rpamis/comet

    Comet workflow entry. An agent skill from rpamis/comet.

    3.2k GitHub stars~686 tokensUpdated today
    Auto-check passed

  • Comet

    rpamis/comet

    Comet — OpenSpec + Superpowers dual-star development workflow.

    3.2k GitHub stars~4.4k tokensUpdated today
    Auto-check passed

  • Comet Archive

    rpamis/comet

    Archive and deliver a Classic change. An agent skill from rpamis/comet.

    3.2k GitHub stars~3.9k tokensUpdated today
    Auto-check passed

  • Comet Classic

    rpamis/comet

    Comet Classic workflow entry. An agent skill from rpamis/comet.

    3.2k GitHub stars~3k tokensUpdated today
    Auto-check passed

  • Comet Design

    rpamis/comet

    Complete the Classic technical design and obtain user confirmation.

    3.2k GitHub stars~4.3k tokensUpdated today
    Auto-check passed

Categories

Questions about Comet Open

What does Comet Open do?

Comet Phase 1: Open. An agent skill from rpamis/comet. Comet Open is an agent skill from rpamis/comet. Comet Phase 1: Open.

When should I use Comet Open?

Comet Open fits situations like: product & Project Management work in your project.

How do I install Comet Open in Claude Code?

Run `npx skills add rpamis/comet --skill comet-open -a claude-code`. Or copy the skill folder (eval/local/skills/benchmarks/039-release/comet-classic-039-open in rpamis/comet) into .claude/skills/comet-open in your project. Claude Code loads it when a task matches its description.

How do I install Comet Open in Codex?

Run `npx skills add rpamis/comet --skill comet-open -a codex`. Or copy the skill folder (eval/local/skills/benchmarks/039-release/comet-classic-039-open in rpamis/comet) into .agents/skills/comet-open in your project. Codex loads it when a task matches its description.

Can I use Comet Open in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rpamis/comet --skill comet-open -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/comet-open, .gemini/skills/comet-open, .github/skills/comet-open and .opencode/skills/comet-open in your project.

What does Comet Open need to run?

SKILL.md names no scripts, command-line tools or credentials: Comet Open is instructions for the agent only.

Does Comet Open access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Comet Open safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Comet Open use?

Comet Open is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Comet Open use?

About 3.4k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Comet Open?

Skills that share tags, products or a category with Comet Open: User Story Writer (deanpeters/Product-Manager-Skills, 7.2k stars), Game Changing Features (openstatusHQ/data-table-filters, 2.3k stars), CCPM Project Management (automazeio/ccpm, 8.4k stars) and Convex Create Component (spokvulcan/poker-planning, 114 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Comet Open?

rpamis (a GitHub organization) maintains it in rpamis/comet, which has 3,172 GitHub stars. The repository holds 52 skills in this directory. The repository was last updated on October 9, 2026.

Source: rpamis/comet on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.