Agent skill

Write Tech Spec

by bholmesdev in bholmesdev/hubble.md

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

MITAuto-check: notesDevelopment

Install Write Tech Spec

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

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

GitHub CLI
$ gh skill install bholmesdev/hubble.md write-tech-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-tech-spec .claude/skills/write-tech-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-tech-spec
GitHub stars
1.5k
Token cost
~1.1k tokens
SKILL.md length
559 words
Files
1
Skills in repo
13
Repo updated
First seen
Licence
MIT

At a glance

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

  • Works in 2 steps: Approach — the core of the spec. Bullets… → E2E test plan — required. Derive it from…
  • The user asks for a technical spec
  • SKILL.md covers Overview, When To Use, Research Before Writing and Structure, plus 3 more sections
  • Calls pnpm

What it does

Write Tech Spec is an agent skill from bholmesdev/hubble.md. Write a TECH.md spec for a significant Hubble feature after researching the monorepo architecture. Use when the user asks for a technical spec, implementation plan, architecture plan, or package/app/module breakdown tied to product behavior.

Its SKILL.md is about 1.1k 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 Development, covering Planning and Monorepo tooling. 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 technical spec
  • Implementation plan
  • Architecture plan
  • Package/app/module breakdown tied to product behavior

Example prompts

  • “/write-tech-spec”

Workflow steps

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

  1. Approach — the core of the spec. Bullets stating what changes where, each grounded in real code: New shared helper classifyHref(href) used…
  2. E2E test plan — required. Derive it from the PRODUCT.md flows

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

    Shell commands in SKILL.md call:

    • pnpm

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

  • Network

    No URLs in SKILL.md. Its commands use pnpm, which can reach the network depending on how they are called.

    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 Tech Spec loads about 1.1k tokens when it runs. Until then it costs about 64 tokens; SKILL.md has 559 words of instructions outside code blocks.

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

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: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:37
    nd `VITE_TEST_WORKSPACE_ID` in `apps/www/.env.local`).

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). 559 words, ~1,089 tokens.

Download SKILL.mdSave it as .claude/skills/write-tech-spec/SKILL.md (or your agent's skills folder).
name
write-tech-spec
description
Write a TECH.md spec for a significant Hubble feature after researching the monorepo architecture. Use when the user asks for a technical spec, implementation plan, architecture plan, or package/app/module breakdown tied to product behavior.

write-tech-spec

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

Overview

The tech spec is the implementation approach as scannable bullets grounded in real code, plus the test plan. A reviewer should be able to scan it in under a minute and spot the risky decision. It is not a build log or a tutorial: every bullet either names a change to make or a decision a reviewer might push back on.

Prefer a sibling PRODUCT.md first (write-product-spec). Reference its flows instead of restating user-facing behavior.

Write specs to specs/<id>/TECH.md, matching the sibling product spec id. specs/ should contain only id-named directories as direct children.

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.

When To Use

Use for changes that span multiple modules, affect shared packages, change sync/workspace behavior, or introduce new data flow. Skip for single-file UI fixes.

Research Before Writing

Read the product spec, then inspect the actual code. Do not guess about architecture when the code can be read:

  • CONTEXT.md for domain terms and relevant docs/adr/* for constraints.
  • The affected source under apps/desktop, apps/www, packages/editor, packages/ui, packages/sync, packages/sync-backend, packages/convex-client, packages/cli.
  • Existing helpers and primitives that already do part of the job. Naming an existing unused helper beats proposing a new one.

Structure

  1. Approach — the core of the spec. Bullets stating what changes where, each grounded in real code: New shared helper classifyHref(href) used in three places: ..., No parser/serializer changes; links round-trip as-is, Reuse normalizePath from apps/desktop/src/lib/filePath.ts (exists but unused here). Group by concern (renderer, main process, shared package) when the change spans layers. Explicitly call out what does NOT change when a reviewer would expect it to. State a tradeoff in one line only where more than one approach is plausible.
  2. E2E test plan — required. Derive it from the PRODUCT.md flows:
    • Desktop: exact flows to drive in the running app per .agents/skills/test-desktop-app/SKILL.md — the Workspace state to open, the actions to perform, and the visible result to confirm. Name screens and controls, not "manually test the UI".
    • Web: the same flows via the dev server with ?test=1 when the behavior is cross-surface (requires VITE_TEST_CONVEX_URL and VITE_TEST_WORKSPACE_ID in apps/www/.env.local).
    • Unit/integration tests worth writing, named by module.
    • Commands: pnpm check for iteration, pnpm build:desktop for final confidence.
Show full SKILL.md (177 more words)Show less

Optional, only when they earn their lines:

  • Risks — real regressions, data loss, or sync hazards, one bullet each with the mitigation.
  • Diagram — Mermaid only when it explains data flow faster than prose.
  • Follow-ups — deferred slices.

Do not include boilerplate sections: no affected-package inventories, module-architecture essays, step-by-step build ordering, or parallelization plans. If a package matters, it shows up naturally in the Approach bullets' file paths.

Writing Guidance

  • Ground every bullet in code you read: name files, functions, and existing patterns. Prefer local paths with line numbers; use commit-pinned GitHub links only when the spec will be read outside a checkout.
  • Use project vocabulary from CONTEXT.md.
  • Reuse existing design-system primitives and nearby patterns before proposing new ones.
  • Use logical CSS spacing props in frontend plans: margin/padding inline/block/start/end, not physical left/right/top/bottom.
  • Target 30-80 lines total. If a bullet doesn't change what the implementer types or what the reviewer checks, cut it.

Keep Current

Update TECH.md in the same PR when the approach, risks, or test plan changes. The checked-in spec should describe what ships.

  • write-product-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-tech-spec of bholmesdev/hubble.md.

Open the folder on GitHubat commit 571a523

Compare with similar skills

Write Tech 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 Tech Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Write Tech Spec this skillbholmesdev/hubble.md1.5k—~1.1kAutomated safety check: NotesMIT
Breakdown Feature Implementationgithub/awesome-copilot40k2 repos~1.2kAutomated safety check: PassMIT
SPARC Development Methodologyruvnet/ruflo74k2 repos~829Automated safety check: PassMIT
Ckeditor5 Plugin DevelopmentTriliumNext/Trilium38k—~4.8kAutomated safety check: PassAGPL-3.0
Codebase Contexthomarr-labs/homarr5k—~679Automated safety check: PassApache-2.0
Tutti Agent Workspace Apptutti-os/tutti3.8k—~1.9kAutomated safety check: PassApache-2.0

Similar skills

  • Breakdown Feature Implementation

    github/awesome-copilot

    Official

    Prompt for creating detailed feature implementation plans, following Epoch monorepo structure.

    40k GitHub starsUsed in 2 repos~1.2k tokens
    Agent WorkflowsAuto-check passed
  • Applies the SPARC method (specification, pseudocode, architecture, refinement, completion) with 17 specialized modes and multi-agent orchestration, from research to deployment.

    74k GitHub starsUsed in 2 repos~829 tokens
    DevelopmentAuto-check passed
  • Ckeditor5 Plugin Development

    TriliumNext/Trilium

    Write, extend, and review CKEditor 5 plugins in the Trilium (TriliumNext Notes) monorepo — the rich-text-note editor under packages/ckeditor5, whose plugins live in src/plugins/.

    38k GitHub stars~4.8k tokensUpdated today
    DevelopmentAuto-check passed
  • Codebase Context

    homarr-labs/homarr

    Navigate Homarr's monorepo architecture and reuse shared packages.

    5k GitHub stars~679 tokensUpdated today
    DevelopmentAuto-check passed
  • Build or evolve a complex agent-enabled Tutti workspace app repository.

    3.8k GitHub stars~1.9k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Bulletproof Workflow

    artemiimillier/bulletproof

    Applies a 12-stage verified workflow, from research to deploy, to non-trivial coding tasks, scaled to lightweight, standard or full mode by task size.

    153 GitHub stars~3.5k tokensUpdated 6 mo ago
    DevelopmentAuto-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 Product Spec

    bholmesdev/hubble.md

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

    1.5k GitHub stars~966 tokensUpdated 6 days ago
    Auto-check passed
  • 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 starsUsed in 1 repo~306 tokens
    Auto-check passed

Questions about Write Tech Spec

What does Write Tech Spec do?

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

When should I use Write Tech Spec?

Write Tech Spec fits situations like: the user asks for a technical spec; implementation plan; architecture plan; package/app/module breakdown tied to product behavior.

How do I install Write Tech Spec in Claude Code?

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

How do I install Write Tech Spec in Codex?

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

Can I use Write Tech 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-tech-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-tech-spec, .gemini/skills/write-tech-spec, .github/skills/write-tech-spec and .opencode/skills/write-tech-spec in your project.

What does Write Tech Spec need to run?

Going by SKILL.md and its folder, Write Tech Spec needs the command-line tools its instructions call (pnpm).

Does Write Tech 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 Tech Spec safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Write Tech Spec use?

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

About 1.1k tokens (SKILL.md is roughly 4.4k 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 Tech Spec?

Skills that share tags, products or a category with Write Tech Spec: Breakdown Feature Implementation (github/awesome-copilot, 40k stars), SPARC Development Methodology (ruvnet/ruflo, 74k stars), Ckeditor5 Plugin Development (TriliumNext/Trilium, 38k stars) and Codebase Context (homarr-labs/homarr, 5k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Write Tech 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.