Agent skill

Write Product Spec

by bholmesdev in bholmesdev/hubble.md

Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior.

MITAuto-check passedProduct & Project Management

Install Write Product Spec

skills CLI
$ npx skills add bholmesdev/hubble.md --skill write-product-spec -a claude-code

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

GitHub CLI
$ gh skill install bholmesdev/hubble.md write-product-spec --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/bholmesdev/hubble.md.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/write-product-spec .claude/skills/write-product-spec && 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
write-product-spec
GitHub stars
1.5k
Token cost
~966 tokens
SKILL.md length
526 words
Files
1
Skills in repo
13
Repo updated
First seen
Licence
MIT

At a glance

Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior.

  • Works in 3 steps: Summary — 1-2 sentences: the feature and… → Flows — the core of the spec. For each… → Out of scope — bullets for what this…
  • The user asks for a product spec
  • SKILL.md covers Overview, Before Writing, Structure and Writing Guidance, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Write Product Spec is an agent skill from bholmesdev/hubble.md. Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. Use when the user asks for a product spec, UX spec, PRD, desired behavior doc, or wants feature behavior clarified before implementation.

Its SKILL.md is about 970 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, covering PRD writing and UX design. It works with GitHub. The repository describes itself as: The best notepad for you and your agents. The licence is MIT.

When your agent uses it

  • The user asks for a product spec
  • Desired behavior doc
  • Wants feature behavior clarified before implementation

Example prompts

  • “/write-product-spec”

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Summary — 1-2 sentences: the feature and the outcome.
  2. Flows — the core of the spec. For each user flow, spell it out step by step: where the user starts, what they do, what they see at each…
  3. Out of scope — bullets for what this slice deliberately does not do, including anything from the original issue that was dropped and why…

What it can do on your machine

Read from SKILL.md and the folder at commit 571a523. 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.

    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

Write Product Spec loads about 966 tokens when it runs. Until then it costs about 71 tokens; SKILL.md has 526 words of instructions outside code blocks.

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

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 bholmesdev/hubble.md at commit 571a523, republished under its MIT licence (© bholmesdev). 526 words, ~966 tokens.

Download SKILL.mdSave it as .claude/skills/write-product-spec/SKILL.md (or your agent's skills folder).
name
write-product-spec
description
Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. Use when the user asks for a product spec, UX spec, PRD, desired behavior doc, or wants feature behavior clarified before implementation.

write-product-spec

Write a PRODUCT.md spec for a significant Hubble feature.

Overview

The product spec settles the product decisions and spells out the user flow. A maintainer should be able to scan it in under a minute and either agree or point at the exact bullet they disagree with. It is a decision record, not documentation: write the choices, not the reasoning that led to them.

Stay out of implementation. No internal types, state layout, data flow, module architecture, or file paths. Those belong in the companion TECH.md from write-tech-spec.

"User" means the consumer of the surface: the person using Hubble desktop or web, or the developer invoking hubble for CLI surfaces.

Write specs to specs/<id>/PRODUCT.md, where <id> is a GitHub issue id prefixed with gh- (for example specs/gh-456/PRODUCT.md) or a short kebab-case feature name. specs/ should contain only id-named directories as direct children. Use the sibling TECH.md path for the same id.

Only create a GitHub issue when the user explicitly asks. This repo uses GitHub Issues on bholmesdev/hubble.md via gh; see docs/agents/issue-tracker.md.

Before Writing

Gather only enough context to write observable behavior:

  • The existing user journey and the desired one.
  • Nearby Hubble screens, flows, and design-system primitives the experience should reuse. Do not invent a new visual system.
  • Project vocabulary from CONTEXT.md: Workspace, Workspace Folder, Plain Folder, Loose File, Cloud Sync, Markdown File, Asset, Embed, Embed Bundle, Workspace Snapshot.

Structure

  1. Summary — 1-2 sentences: the feature and the outcome.
  2. Flows — the core of the spec. For each user flow, spell it out step by step: where the user starts, what they do, what they see at each step. Group the decisions that shape each flow as short bullets directly under it: inputs and their results, error and empty states, cross-surface (desktop vs web) differences, and what stays unchanged. One bullet per decision; state the choice, not the options considered.
  3. Out of scope — bullets for what this slice deliberately does not do, including anything from the original issue that was dropped and why in a few words.

Optional, only when they earn their lines:

  • Problem — one short paragraph, only when motivation is not obvious.
  • Open questions — prefer inline **Open question:** ... next to the affected bullet.

Do not include implementation, module breakdown, engineering validation, or success criteria. The E2E test plan lives in TECH.md and should derive directly from the Flows section here.

Show full SKILL.md (132 more words)Show less

Writing Guidance

  • Every bullet is a testable, observable behavior: what the user does and what they see.
  • Cover the happy path completely, then only the edge cases where the answer is not obvious: error, empty, offline, conflict, and cancellation states that a reviewer would otherwise have to guess.
  • Name existing primitives the user experiences (dialog, toast, popover, menu item) rather than describing new UI from scratch.
  • Note Workspace-state differences (Workspace Folder, Plain Folder, Loose File, synced) only when the behavior actually differs.
  • Target 20-60 lines total. If a section restates another, collapse it. Long numbered invariant lists are a smell: fold them into the flow they belong to.

Keep Current

Update PRODUCT.md in the same PR when shipped behavior changes. The checked-in spec should describe what ships.

  • write-tech-spec
  • to-issues
  • grill-with-docs

© bholmesdev, 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 .agents/skills/write-product-spec of bholmesdev/hubble.md.

Open the folder on GitHubat commit 571a523

Compare with similar skills

Write Product Spec 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.

Write Product Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Write Product Spec this skillbholmesdev/hubble.md1.5k—~966Automated safety check: PassMIT
CCPM Project Managementautomazeio/ccpm8.4k—~1.1kAutomated safety check: PassMIT
Ouroboros PM InterviewQ00/ouroboros6.2k—~5.7kAutomated safety check: PassMIT
To Issuessmallnest/pigo474—~1.9kAutomated safety check: PassMIT
Write A Prdbestofjs/bestofjs3.1k1 repos~722Automated safety check: PassMIT
Vscuse Scenario AuthoringOfficeDev/microsoft-365-agents-toolkit781—~4.3kAutomated safety check: PassCustom licence

Similar skills

  • 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
  • Runs a guided product-manager interview that classifies each question automatically and produces a Product Requirements Document.

    6.2k GitHub stars~5.7k tokensUpdated yesterday
    Product & Project ManagementAuto-check passed
  • To Issues

    smallnest/pigo

    Decompose a PRD and/or SPEC into implementable Issues and create them in your chosen platform (GitHub, Local, or Baidu iCafe).

    474 GitHub stars~1.9k tokensUpdated 25 days ago
    Product & Project ManagementAuto-check passed
  • Write A Prd

    bestofjs/bestofjs

    Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue.

    3.1k GitHub starsUsed in 1 repo~722 tokens
    Product & Project ManagementAuto-check passed
  • Vscuse Scenario Authoring

    OfficeDev/microsoft-365-agents-toolkit

    A skill your agent uses when: reading a docs scenario, PRD, mockup, or user flow and using vscuse-ui/noVNC as the primary authoring surface to record, generate, replace, or update vscuse test plans…

    781 GitHub stars~4.3k tokensUpdated yesterday
    Product & Project ManagementAuto-check passed
  • Write new TiDB documentation or update existing TiDB documentation from code changes, PRs, issues, design docs, product specs, rough drafts, existing docs, or short feature descriptions.

    616 GitHub stars~2.3k tokensUpdated today
    Product & Project ManagementAuto-check passed

More from bholmesdev/hubble.md

All 13 skills in this repo
  • Changelog

    bholmesdev/hubble.md

    Add a user-facing entry to CHANGELOG.md for work that just landed.

    1.5k GitHub stars~564 tokensUpdated 6 days ago
    Auto-check passed
  • Review PR

    bholmesdev/hubble.md

    Review a pull request or local branch diff for correctness, security, lifecycle, error handling, tests, and meaningful performance risks.

    1.5k GitHub stars~800 tokensUpdated 6 days ago
    Auto-check passed
  • Triage

    bholmesdev/hubble.md

    Triage an incoming GitHub, Jira, Linear, or other issue-tracker issue against the current codebase and related issues, then return a structured decision with exactly one triage state.

    1.5k GitHub stars~1.5k tokensUpdated 6 days ago
    Auto-check passed
  • Simplify

    bholmesdev/hubble.md

    Use this skill automatically when you feel your code is ready for human review, and whenever writing or reviewing code comments.

    1.5k GitHub stars~886 tokensUpdated 6 days ago
    Auto-check passed
  • Write Tech Spec

    bholmesdev/hubble.md

    Write a TECH.md spec for a significant Hubble feature after researching the monorepo architecture.

    1.5k GitHub stars~1.1k tokensUpdated 6 days ago
    Auto-check: notes
  • Taste Review

    bholmesdev/hubble.md

    Ask Claude Code to make a taste-driven call on something ambiguous — UI polish, prose phrasing, naming, formatting.

    1.5k GitHub stars~306 tokensUpdated 6 days ago
    Auto-check passed

Works with

Questions about Write Product Spec

What does Write Product Spec do?

Write a PRODUCT.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior. md.md spec for a significant Hubble user-facing feature, focused only on user experience and observable behavior.

When should I use Write Product Spec?

Write Product Spec fits situations like: the user asks for a product spec; desired behavior doc; wants feature behavior clarified before implementation.

How do I install Write Product Spec in Claude Code?

Run `npx skills add bholmesdev/hubble.md --skill write-product-spec -a claude-code`. Or copy the skill folder (.agents/skills/write-product-spec in bholmesdev/hubble.md) into .claude/skills/write-product-spec in your project. Claude Code loads it when a task matches its description.

How do I install Write Product Spec in Codex?

Run `npx skills add bholmesdev/hubble.md --skill write-product-spec -a codex`. Or copy the skill folder (.agents/skills/write-product-spec in bholmesdev/hubble.md) into .agents/skills/write-product-spec in your project. Codex loads it when a task matches its description.

Can I use Write Product Spec 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 bholmesdev/hubble.md --skill write-product-spec -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/write-product-spec, .gemini/skills/write-product-spec, .github/skills/write-product-spec and .opencode/skills/write-product-spec in your project.

What does Write Product Spec need to run?

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

Does Write Product Spec 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 Write Product Spec 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 Write Product Spec use?

Write Product Spec 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 Write Product Spec use?

About 966 tokens (SKILL.md is roughly 3.9k 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 Write Product Spec?

Skills that share tags, products or a category with Write Product Spec: CCPM Project Management (automazeio/ccpm, 8.4k stars), Ouroboros PM Interview (Q00/ouroboros, 6.2k stars), To Issues (smallnest/pigo, 474 stars) and Write A Prd (bestofjs/bestofjs, 3.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Write Product Spec?

bholmesdev (a GitHub user) maintains it in bholmesdev/hubble.md, which has 1,483 GitHub stars. The repository holds 13 skills in this directory. The repository was last updated on October 1, 2026.

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