Comment dev
Comment.io engineering-workflow skills for any AI coding agent (Claude Code, Codex, Cursor) — plan, prototype, build, review, ship. npx skills add comment-hq/skills
npx -y skills add comment-hq/skills --skill comment-devAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
The front door for pragmatic engineering delivery through Comment.io. Talk to it about dev work in plain language and it picks the right path: shape a rough idea (`comment-spec`), build a defined feature (`comment-feature`), fix a defect (`comment-bug`), or try a fast change you'll validate later (`comment-prototype`). Invoke as `$comment-dev` / `/comment-dev`, or when someone describes coding work — "build / add / implement", "fix / it's broken", "let me try / quick tweak / show me", "should we / scope this" — without naming a specific path. When the user already named a specific skill, let that one fire directly. Works identically under Codex and Claude Code.
SKILL.md
4.6 KB, as published. Nobody here has run it
comment-dev — the engineering front door
One thing to talk to. Describe the work; comment-dev classifies the intent and
routes to the path that fits, so you don't have to remember which comment-*
skill to call. It is a thin dispatcher — it does no delivery itself; it picks
a path and hands off.
Every route follows the same startup bias: get the simplest useful change in front of real users, learn whether they love it, and add complexity only when evidence or a hard invariant requires it.
Not a Comment.io document skill. "Make me a comm / read this doc / edit this comm" is the
commentskill.comment-devis for building, fixing, and shaping software.
Routing
Classify the request, state which path you're taking and why (one line), then run
that skill (read its full SKILL.md first — naming it here does not load it):
| The request looks like… | Route to | Why |
|---|---|---|
| A rough/unshaped idea; goal, scope, or product fit unsettled; "should we…", "what if…", "scope this", "is this worth doing" | comment-spec | Shape it into a crisp spec first; it then invokes comment-feature. |
| A defined feature; "build / add / implement / wire up X", clear what success is | comment-feature | Choose direct/lift topology → build bounded deltas → ship. |
| A defect/regression; "X is broken", "this throws", "stopped working", "wrong output" | comment-bug | Reproduce → failing test → fix → verify. |
| A fast, small, or exploratory change to look at first; "let me try", "quick tweak", "just show me", "spike / prototype this", UI nudges before committing to the gate | comment-prototype | Implement fast, show it, skip the heavy gate; promote later. |
| Make / read / edit a Comment.io doc itself (not code) | comment | That's a document operation, not a delivery flow. |
Picking between adjacent paths
- prototype vs feature/bug: if the user wants to see it before investing,
or it's a handful of UI/copy tweaks, start with
comment-prototype— it promotes intocomment-feature/comment-bugwhen they like it. If they want it real and merge-ready from the start, go straight to feature/bug. - spec vs feature: if you can't yet state the goal and what "done" means in one sentence, it's a spec. If you can, it's a feature.
- feature vs bug: new capability → feature; restoring intended behavior → bug.
When it's genuinely ambiguous, ask one crisp question with your recommended route — don't guess on a high-cost path. When it's clear, just route and say so.
What carries across the handoff
- Identity / worklog. The chosen skill reuses the working Comment.io route
and identity already available for the task. It invokes
comment-identityonly immediately before an uncredentialed direct-REST write. If the user already has a worklog / Project Root URL for this task, pass it through so the routed skill reuses it instead of opening a second root. - Repo config. The routed skills read this repo's setup themselves (see
Repo config below);
comment-devdoesn't need to. - Delivery topology. The routed delivery skill reads
delivery-methodologyand records direct versus controlled-lift choice before implementation. Do not default foundational work to feature flags when that would preserve two systems.
Repo config
comment-dev only routes, so it needs no repo specifics. The skills it routes to
read AGENTS.md (else CLAUDE.md) and linked delivery/testing docs, plus
delivery-methodology. If those are missing, the routed skill infers them or
offers comment-init to scaffold the repo config.
Out of scope
comment-dev never implements, tests, or ships directly — it delegates. If a
request spans paths (e.g. "spec then build"), route to the first one and let
the chain continue (comment-spec → comment-feature).