Agent skill

Comet Design

by rpamis in rpamis/comet

Comet Phase 2: Deep Design. An agent skill from rpamis/comet.

MITAuto-check passedAgent Workflows

Install Comet Design

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

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

GitHub CLI
$ gh skill install rpamis/comet comet-design --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-design .claude/skills/comet-design && 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-design
GitHub stars
3.2k
Token cost
~3.2k tokens
SKILL.md length
1,181 words
Files
1
Skills in repo
52
Repo updated
First seen
Licence
MIT

At a glance

Comet Phase 2: Deep Design. An agent skill from rpamis/comet.

  • Works in 3 steps: Entry State Verification (Entry Check) → Create Design Doc → Update Comet State
  • Tasks that involve Brainstorming
  • SKILL.md covers Prerequisites, Steps, Exit Conditions and Context Compression Recovery, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Comet Design is an agent skill from rpamis/comet. Comet Phase 2: Deep Design. Invoke with /comet-design. Produce Design Doc and delta spec through brainstorming.

Its SKILL.md is about 3.2k 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 Agent Workflows, covering Brainstorming and Architecture decision records. The repository describes itself as: Comet: agent skill harness for turning ideas into evaluated workflows. The licence is MIT.

When your agent uses it

  • Tasks that involve Brainstorming
  • Tasks that involve Architecture decision records

Example prompts

  • “/comet-design”

Workflow steps

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

  1. Entry State Verification (Entry Check)
  2. Create Design Doc
  3. Update Comet State

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, yaml and markdown).

    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 Design loads about 3.2k tokens when it runs. Until then it costs about 31 tokens; SKILL.md has 1,181 words of instructions outside code blocks.

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

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,181 words, ~3,243 tokens.

Download SKILL.mdSave it as .claude/skills/comet-design/SKILL.md (or your agent's skills folder).
name
comet-design
description
Comet Phase 2: Deep Design. Invoke with /comet-design. Produce Design Doc and delta spec through brainstorming.

Comet Phase 2: Deep Design (Design)

Prerequisites

  • Active change exists (proposal.md, design.md, tasks.md)
  • No Design Doc (no corresponding file under docs/superpowers/specs/)

Steps

0. Entry State Verification (Entry Check)

Execute entry verification:

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"
"$COMET_BASH" "$COMET_STATE" check <name> design

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

Idempotency: All design phase operations can be safely re-executed. If handoff_context and handoff_hash already exist, confirm they match current artifacts before deciding whether to regenerate.

1a. Generate OpenSpec → Superpowers Handoff Package

Must be generated by script. Agent writing summaries on the fly is not allowed.

bash
"$COMET_BASH" "$COMET_HANDOFF" <change-name> design --write

The script reads the change .comet.yaml context_compression snapshot, then generates and records the matching handoff package.

Default context_compression: off generates:

openspec/changes/<name>/.comet/handoff/design-context.json
openspec/changes/<name>/.comet/handoff/design-context.md

Beta mode (context_compression: beta in project .comet/config.yaml, snapshotted into .comet.yaml when the change is created) generates:

openspec/changes/<name>/.comet/handoff/spec-context.json
openspec/changes/<name>/.comet/handoff/spec-context.md

And writes to .comet.yaml:

yaml
handoff_context: openspec/changes/<name>/.comet/handoff/design-context.json
handoff_hash: <sha256>

The default handoff package is a compact traceable excerpt, not an agent summary:

  • design-context.json: machine index containing change, phase, canonical spec, source paths, hash
  • design-context.md: context for Superpowers to read, containing script markers, source path, line range, sha256, deterministic excerpts
  • When exceeding excerpt budget, marks [TRUNCATED] and retains Full source path

The beta handoff package is a structured spec projection that reduces OpenSpec token load without replacing the canonical spec:

  • spec-context.json: machine index containing change, phase, canonical spec, source paths, hash, and file roles
  • spec-context.md: context for Superpowers to read, verbatim-projecting delta spec files and referencing supporting artifacts by hash
  • OpenSpec delta specs remain canonical; if the projection is missing, stale, or unclear, regenerate the handoff or read the source spec directly instead of writing an agent summary

If full context is genuinely needed, explicitly run:

bash
"$COMET_BASH" "$COMET_HANDOFF" <change-name> design --write --full

Handoff package sources come from OpenSpec open phase artifacts:

  • proposal.md: goals, motivation, scope, non-goals
  • design.md: high-level architecture decisions, approach constraints
  • tasks.md: initial task boundaries
  • specs/*/spec.md: delta capability specs
1b. Execute Brainstorming (with Context)

Immediately execute: Use the Skill tool to load the Superpowers brainstorming skill. Skipping this step is prohibited.

When loading the skill, ARGUMENTS must include:

text
Language: Use the language of the user request that triggered this workflow

After the skill loads, follow its guidance and use the following context:

Change: <change-name>
OpenSpec Context Pack: openspec/changes/<name>/.comet/handoff/design-context.md
Machine handoff: openspec/changes/<name>/.comet/handoff/design-context.json

If context_compression is beta, use:
OpenSpec Context Pack: openspec/changes/<name>/.comet/handoff/spec-context.md
Machine handoff: openspec/changes/<name>/.comet/handoff/spec-context.json

OpenSpec artifacts are the upstream source of truth, but you must not weaken the Superpowers `brainstorming` clarification flow by "skipping redundant context exploration".
Your task is to perform deep technical design based on the handoff package: implementation approach, technical risks, testing strategy, boundary conditions.
If goals, scope, non-goals, acceptance scenarios, or key constraints remain unclear, you must continue asking questions and form the design proposal first; must not create the Design Doc after only one Q&A turn.
Do not rewrite proposal/spec; if you find OpenSpec delta spec missing acceptance scenarios, you may only propose Spec Patches and write them back to OpenSpec delta spec; do not create a second requirements spec in the Design Doc. Spec Patches are limited to supplementing acceptance scenarios, correcting ambiguous descriptions, or adding boundary conditions — they must not substantially rewrite the delta spec's structure or scope. If major changes are needed, flag them as design findings and return to brainstorming for confirmation.

Design Doc frontmatter must be minimal, containing only:
---
comet_change: <change-name>
role: technical-design
canonical_spec: openspec
---

Proceed through the original `brainstorming` skill flow: clarifying questions, 2-3 approaches, and step-by-step design confirmation. Do not write the Design Doc early.

Proceeding without loading this skill is prohibited.

If the Superpowers brainstorming skill is unavailable, stop the process and prompt to install or enable Superpowers skills. Do not substitute this step with normal conversation.

After the skill loads, follow its guidance to produce design proposals (presented as conversation):

  • Technical approach: architecture, data flow, key technology choices and risks
  • Testing strategy
  • Requirement/scope gaps and Spec Patches to be written back
  • If acceptance scenarios need supplementing, indicate delta spec changes to be written back

The brainstorming phase does not write to the Design Doc file; it only produces design proposals for Step 1c user confirmation. Only after confirmation should docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md be created and delta spec written back.

For context compaction recovery, the agent must incrementally update brainstorm-summary.md during brainstorming. After each clarification round or proposal iteration, update the file whenever new confirmed facts, key constraints, candidate approaches, trade-offs/risks, testing strategy, or Spec Patch candidates emerge; mark unconfirmed items as "pending" or "candidate". This file is a recovery checkpoint, not the Design Doc, and must not replace the Step 1c user confirmation.

1c. User Confirms Design Proposal (Blocking Point)

After brainstorming produces a design proposal, must follow the comet/reference/decision-point.md protocol to pause and wait for the user to explicitly confirm the design proposal. Must not create the final Design Doc, write design_doc, run design guard, or enter /comet-build before user confirmation.

When pausing, only present essential summary:

  • Technical approach adopted
  • Key trade-offs and risks
  • Testing strategy
  • If there are Spec Patches, list the delta spec changes to be written back

Only after the user explicitly confirms, proceed to Step 2. If the user requests adjustments, continue brainstorming iteration until the user confirms.

1d. Brainstorming Checkpoint Finalization

After the user confirms the design proposal, before creating the Design Doc, create or update the incrementally maintained checkpoint file and finalize it as the confirmed design summary:

bash
mkdir -p openspec/changes/<name>/.comet/handoff

openspec/changes/<name>/.comet/handoff/brainstorm-summary.md structure:

markdown
# Brainstorm Summary

- Change: <change-name>
- Date: <YYYY-MM-DD>

## Confirmed Technical Approach

<summary of the user-confirmed approach>

## Key Trade-offs and Risks

<major trade-offs and risks>

## Testing Strategy

<testing method overview>

## Spec Patches

<delta spec changes to write back, or "None" if none>

Context compaction note: Each incremental update to brainstorm-summary.md is a relatively safe recovery point. After brainstorming completes, if the context window is tight, prefer compacting here. After compaction, reload the following files to continue Step 2:

  • openspec/changes/<name>/.comet/handoff/brainstorm-summary.md
  • openspec/changes/<name>/.comet/handoff/design-context.md (or spec-context.md in beta mode)
  • openspec/changes/<name>/.comet/handoff/design-context.json (or spec-context.json in beta mode)
Show full SKILL.md (483 more words)Show less
1e. Active Context Compaction Gate

After Step 1d completes and brainstorm-summary.md is written, enter the active compaction gate before creating the Design Doc. At this point the OpenSpec handoff, brainstorming decisions, and pending items are durable, so the agent should proactively release the earlier Spec and brainstorming context to preserve window space for Step 2 and the later Build phase.

Rules:

  • If the current platform provides a native context compaction/cleanup mechanism (for example, the host agent's compact/compaction command, tool, or UI action), trigger active compaction here once; do not try to fake compaction through a shell script.
  • The compaction resume prompt must include the change name, current step (Design Step 2), and the three handoff file categories listed above.
  • If the current platform cannot be compacted programmatically by the agent, pause and tell the user to run the host platform's manual compaction action; continue to Step 2 only after the user confirms compaction is unavailable or asks to continue.
2. Create Design Doc

Create the Design Doc based on the full brainstorming conversation context (still in the main session).

Design Doc frontmatter must be minimal:

yaml
---
comet_change: <change-name>
role: technical-design
canonical_spec: openspec
---

Write the Design Doc to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md. If Spec Patches need to be written back, also edit the corresponding specs/*/spec.md.

Context compaction recovery: If context has been compacted, resume from brainstorm-summary.md + handoff context. If the user has not confirmed the design proposal yet, return to Step 1b/1c and continue brainstorming; if the user has confirmed it, continue creating the Design Doc. brainstorm-summary.md is the compaction checkpoint, not the sole input for the Design Doc — when creating, leverage the full recovered context as much as possible.

3. Update Comet State

First record the design_doc path. If Spec Patches wrote back delta spec (added or modified specs/*/spec.md), must regenerate handoff to update hash:

bash
# Record design_doc path
"$COMET_BASH" "$COMET_STATE" set <name> design_doc docs/superpowers/specs/YYYY-MM-DD-topic-design.md

# If delta spec changes exist, regenerate handoff (update hash)
"$COMET_BASH" "$COMET_HANDOFF" <change-name> design --write

# Auto-transition to next phase
"$COMET_BASH" "$COMET_GUARD" <change-name> design --apply

If there are no delta spec changes, skip the handoff regeneration step. The state file updates automatically; no manual editing of other fields needed.

Exit Conditions

  • Design Doc created and saved
  • Design Doc frontmatter contains comet_change, role: technical-design, canonical_spec: openspec
  • handoff_context and handoff_hash written to .comet.yaml (enforced by guard)
  • handoff_hash matches current OpenSpec open phase artifacts (enforced by guard)
  • design-context.md or beta spec-context.md must be script-generated and contain source path, mode, sha256 traceability markers (enforced by guard)
  • In beta mode, spec-context.json must be structurally valid and reference the current source files (enforced by guard)
  • If new capabilities or supplementary acceptance scenarios exist, OpenSpec delta spec has been created/updated
  • design_doc written to .comet.yaml
  • Phase guard: Run "$COMET_BASH" "$COMET_GUARD" <change-name> design --apply; after all PASS, auto-transitions to phase: build

Must use --apply before exit:

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

Context Compression Recovery

Follow comet/reference/context-recovery.md with phase set to design.

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

© 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-design of rpamis/comet.

Open the folder on GitHubat commit c28e724

Compare with similar skills

Comet Design 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 Design compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Comet Design this skillrpamis/comet3.2k—~3.2kAutomated safety check: PassMIT
Octocode Rfc Generatorbgauryy/octocode949—~1.1kAutomated safety check: PassMIT
Dotfile Brainstormharperreed/dotfiles334—~2.3kAutomated safety check: PassNone
Brainstormingdavekilleen/Dex494—~1.5kAutomated safety check: PassMIT
Macro Idea Generationagentii-ai/agentii-investment-intelligence207—~2.1kAutomated safety check: PassApache-2.0
Grounding A Designandrew-blake/melcloudhome142—~1.1kAutomated safety check: PassMIT

Similar skills

  • Octocode Rfc Generator

    bgauryy/octocode

    A skill your agent uses when a consequential change needs a decision before coding: write or improve an RFC, design doc, architecture proposal, migration plan, option comparison, rollout plan, or…

    949 GitHub stars~1.1k tokensUpdated yesterday
    Agent WorkflowsAuto-check passed
  • Dotfile Brainstorm

    harperreed/dotfiles

    A skill your agent uses when you want to build a project but don't have a spec yet and need to brainstorm the idea into a design doc structured for pipeline DOT generation.

    334 GitHub stars~2.3k tokensUpdated 7 days ago
    Agent WorkflowsAuto-check passed
  • Brainstorming

    davekilleen/Dex

    This skill should be used before implementing features, building components, or making changes.

    494 GitHub stars~1.5k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Macro Idea Generation

    agentii-ai/agentii-investment-intelligence

    Macro-driven trade idea generation, translating macroeconomic views into concrete stock ideas, sector selection from macro regime, international trade ideas via ADRs, cross-border idea sourcing…

    207 GitHub stars~2.1k tokensUpdated 11 days ago
    Agent WorkflowsAuto-check passed
  • Grounding A Design

    andrew-blake/melcloudhome

    A skill your agent uses when about to propose, brainstorm, review or revise a design, fix approach or plan for a feature or behaviour change in this repo, including "brief" or "quick" design…

    142 GitHub stars~1.1k tokensUpdated today
    DevelopmentAuto-check passed
  • Brainstorming

    feiskyer/claude-code-settings

    Explore user intent, requirements, and design options through collaborative dialogue before implementation.

    1.7k GitHub stars~985 tokensUpdated 12 days ago
    DevelopmentAuto-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 Design

What does Comet Design do?

Comet Phase 2: Deep Design. An agent skill from rpamis/comet. Comet Design is an agent skill from rpamis/comet. Comet Phase 2: Deep Design.

When should I use Comet Design?

Comet Design fits situations like: tasks that involve Brainstorming; tasks that involve Architecture decision records.

How do I install Comet Design in Claude Code?

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

How do I install Comet Design in Codex?

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

Can I use Comet Design 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-design -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-design, .gemini/skills/comet-design, .github/skills/comet-design and .opencode/skills/comet-design in your project.

What does Comet Design need to run?

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

Does Comet Design 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 Design 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 Design use?

Comet Design 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 Design use?

About 3.2k 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 Design?

Skills that share tags, products or a category with Comet Design: Octocode Rfc Generator (bgauryy/octocode, 949 stars), Dotfile Brainstorm (harperreed/dotfiles, 334 stars), Brainstorming (davekilleen/Dex, 494 stars) and Macro Idea Generation (agentii-ai/agentii-investment-intelligence, 207 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Comet Design?

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.