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

Tech Spec

by sd0xdev in sd0xdev/sd0x-harness

Tech spec generation and review. An agent skill from sd0xdev/sd0x-harness.

MITAuto-check passedDevelopment

Install Tech Spec

skills CLI
$ npx skills add sd0xdev/sd0x-harness --skill tech-spec -a claude-code

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

GitHub CLI
$ gh skill install sd0xdev/sd0x-harness 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/sd0xdev/sd0x-harness.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/tech-spec .claude/skills/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
tech-spec
GitHub stars
192
Token cost
~2k tokens
SKILL.md length
941 words
Files
3 (incl. references)
Skills in repo
89
Repo updated
First seen
Licence
MIT

At a glance

Tech spec generation and review. An agent skill from sd0xdev/sd0x-harness.

  • Works in 7 steps: Requirement summary (problem + goals +… → Existing code analysis → Technical solution (architecture + data… → …
  • : designing features
  • SKILL.md covers Trigger, When NOT to Use, Commands and Context-Aware Mode (Upsert), plus 8 more sections
  • Calls git

What it does

Tech Spec is an agent skill from sd0xdev/sd0x-harness. Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.

Its SKILL.md is about 2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files, including reference files (for example `references/native-feature-resolution.md` and `references/template.md`).

It sits in Development. It works with Bash. The repository describes itself as: The harness layer for Claude Code — a reference implementation of harness engineering with hook-enforced dual review, state-machine gates that survive context compaction, and… The licence is MIT.

When your agent uses it

  • : designing features

Example prompts

  • “/tech-spec”

Requirements

  • Pre-approved tools (allowed-tools): Read, Grep, Glob, Bash(git:*), Write

Workflow steps

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

  1. Requirement summary (problem + goals + scope)
  2. Existing code analysis
  3. Technical solution (architecture + data model + API + core logic)
  4. Risks and dependencies
  5. Work breakdown
  6. Testing strategy
  7. Open questions

What it can do on your machine

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

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Grep
    • Glob
    • Bash(git:*)
    • Write

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

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

  • Network

    No URLs in SKILL.md. Its commands use git, 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

Tech Spec loads about 2k tokens when it runs, and up to ~3.9k if it reads all its reference files. Until then it costs about 66 tokens; SKILL.md has 941 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~66
When it runs · the whole SKILL.md, loaded when a task matches
~2k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.9k

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 sd0xdev/sd0x-harness at commit a4d4bc1, republished under its MIT licence (© sd0xdev). 941 words, ~2,041 tokens.

Download SKILL.mdSave it as .claude/skills/tech-spec/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
tech-spec
description
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
allowed-tools
Read, Grep, Glob, Bash(git:*), Write

Tech Spec Skill

Trigger

  • Keywords: tech spec, technical specification, spec review, review spec, feature design

When NOT to Use

  • Creating request documents (use /create-request)
  • Code implementation (use feature-dev)
  • Architecture consulting (use /codex-architect)

Commands

CommandPurposeWhen
/tech-specCreate or update tech specAuto-detects create/update from filesystem state
/deep-analyzeDeepen spec + roadmapAfter initial concept
/review-specReview tech specSpec confirmation

Context-Aware Mode (Upsert)

When invoked without a full requirement description, the skill auto-detects the target feature using the cascade in references/native-feature-resolution.md — this skill's own reference, and deliberately command-free.

This skill grants Bash(git:*) and not Bash(node:*), so the resolver script is not a command it may run — and it does not link the shared reference that teaches it, because a file of unrunnable commands inside this skill's reachable graph is the defect, not the annotation on it. The cascade needs nothing beyond $ARGUMENTS, git branch --show-current, git diff --name-only HEAD and a Glob over docs/features/*. What that does not produce is the four document source sets or scan_error — this skill consumes neither. A skill that needs the sets (/architecture, /tech-brief, /runbook, /ask) grants Bash(node:*) and reads the shared reference itself.

Canonical discovery is still owed, and testing one literal path does not deliver it. The spec may have been split into a folder or may carry a variant name, and docs/features/auto-loop-evolution/2-tech-spec/2-tech-spec.md in this repo is the live proof. Resolve it with a Glob over docs/features/<key>/, in this order — the first hit wins:

#GlobMeaning
1docs/features/<key>/2-tech-spec.mdUnsplit canonical spec
2docs/features/<key>/2-tech-spec/2-tech-spec.mdSplit spec — the folder keeps the lifecycle prefix, the main file keeps the canonical filename (@rules/docs-numbering.md § Size Limit)
3docs/features/<key>/2-tech-spec*.md, minus any hit matching -fp-brief.md or -tech-brief.mdA variant (2-tech-spec-v2.md). The two suffixes are excluded because they are not specs: scripts/config/doc-taxonomy.json carries the same exclude_pattern for the same reason, and docs/features/seek-verdict/ holds a live 2-tech-spec-fp-brief.md that this glob would otherwise return as the canonical spec. Two or more remaining hits is ambiguity, not a match — report and take the Need Human exit rather than picking one

Requirements docs (1-requirements.md) resolve the same three ways, without the suffix exclusion — doc-taxonomy.json carries exclude_pattern on the tech-spec type only, and copying it to requirements here would put this skill out of step with the classifier rather than in step. A Glob that errors, or a <key> that resolved with low confidence and matches nothing, is not the same as "no spec exists" — say which of the two it was; do not silently drop into create mode.

A fourth lookup resolves the intent artifact: exactly intent-<key>.md in the feature directory — the exact name, never a wildcard pick. A separate Glob intent-*.md only surfaces strays or wrong-key files (report them; never adopt one as the intent).

Filesystem StateAction
Canonical discovery finds exactly one specUpdate mode: read that file — at the path discovery returned, not at the literal 2-tech-spec.md — research code changes since last update, incrementally update changed sections
All three globs emptyCreate mode: generate new spec from template at docs/features/<key>/2-tech-spec.md
Glob 3 returns two or moreGate: Need Human — ambiguous canonical spec, name the candidates
Feature not resolvedGate: Need Human

In create mode, if intent-<key>.md is absent, write it first from the intent template bundled with /req-analyze — distilled from the requirement clarification step (constraints only, ≤60 lines) — then write the spec. If present, read it before designing.

In update mode, focus on sections affected by recent code changes (use git diff to identify). Preserve unchanged sections. If intent-<key>.md is absent, create it exactly as in create mode (projecting from 1-requirements.md §§ 1–2 when present, else from the spec's requirement summary) — this is what lets the next-step advisory converge on features whose spec predates the intent mechanism. When it exists, read it: every spec section that contradicts an INV-* or Non-goal is a conflict to surface to the user, not to paper over — and never rewrite intent to match a spec; amending intent is a human re-decision.

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

Workflow

mermaid
sequenceDiagram
    participant A as Analyst
    participant C as Codebase
    participant D as Document

    A->>A: 1. Requirement clarification
    A->>C: 2. Code research
    C-->>A: Related modules
    A->>A: 3. Solution design
    A->>A: 4. Risk assessment
    A->>A: 5. Work breakdown
    A->>D: 6. Output document

Spec Structure

  1. Requirement summary (problem + goals + scope)
  2. Existing code analysis
  3. Technical solution (architecture + data model + API + core logic)
  4. Risks and dependencies
  5. Work breakdown
  6. Testing strategy
  7. Open questions

Write-Time Budget

A spec is cheapest to keep short while it is being written. Enforcing length afterwards means either a split or a prune, and both cost a review round that writing to budget would have avoided.

Lines (wc -l)At write time
≤ 300The target. Aim here
301–400Acceptable — trim before adding more
> 400State the cohesion exception in the document itself, or prune / split before it is written. "I ran out of room" is not the exception

The exception is a sentence in the spec naming why these sections are one argument that does not read better apart. Unstated, a spec over 400 lines is over budget, and @rules/docs-numbering.md § Size Limit takes it from there — prune first, then merge, then split.

What to leave out: alternatives considered and rejected (one line each, not a section), history of how the design changed (that belongs in a record), and anything the code will state more precisely than prose can.

In update mode, a section the code made obsolete is pruned, not annotated. Rewriting it in place keeps the spec current-authority; layering "previously..." notes turns it into a record it is not.

Output

Numbered tech spec document with sections: Overview, Requirements, Architecture, Implementation plan, Work breakdown, Testing strategy, Open questions.

Verification

  • Solution covers all requirement points
  • Architecture diagrams use Mermaid
  • Risks have mitigation strategies
  • Work can be broken into trackable items
  • Within the write-time budget, or the cohesion exception is stated in the document

References

  • references/template.md - Spec template + review dimensions

File Location

docs/features/{feature}/
├── 2-tech-spec.md    # Technical spec (numbered per docs-numbering rule)
├── requests/         # Request documents
└── README.md         # Feature description

Examples

Input: /tech-spec "Implement user asset snapshot feature"
Action: Requirement clarification -> Code research -> Solution design -> Output document
Input: /review-spec docs/features/xxx/2-tech-spec.md
Action: Read -> Research -> Review -> Output report + Gate

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

Files

SKILL.md and 2 other files (references) in skills/tech-spec of sd0xdev/sd0x-harness.

  • SKILL.md
  • references/native-feature-resolution.md
  • references/template.md

Open the folder on GitHubat commit a4d4bc1

Compare with similar skills

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.

Tech Spec compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Tech Spec this skillsd0xdev/sd0x-harness192—~2kAutomated safety check: PassMIT
Mole Bug Patternstw93/Mole70k—~2kAutomated safety check: PassGPL-3.0
CLI DeveloperJeffallan/claude-skills12k2 repos~1.2kAutomated safety check: PassMIT
JSON Processing with jqcharmbracelet/crush29k—~746Automated safety check: PassCustom licence
Segment CreateJanDeDobbeleer/oh-my-posh24k—~1.2kAutomated safety check: PassMIT
Coding AgentTermiX-official/cryptoclaw1008 repos~2.7kAutomated safety check: PassMIT

Similar skills

  • Mole Bug Patterns

    tw93/Mole

    A catalog of recurring bug shapes in the Mole Mac cleaner, used to review safety-sensitive diffs for deletion safety, unbounded commands, shell traps and weak tests.

    70k GitHub stars~2k tokensUpdated today
    DevelopmentAuto-check passed

  • CLI Developer

    Jeffallan/claude-skills

    Walks through designing, building and polishing a command-line tool: user workflow and command hierarchy, implementation in commander, click, typer or cobra, completions and cross-platform testing.

    12k GitHub starsUsed in 2 repos~1.2k tokens
    DevelopmentAuto-check passed

  • JSON Processing with jq

    charmbracelet/crush

    Explains the jq command built into Crush for querying, filtering and reshaping JSON, including its supported flags and where it differs from standard jq.

    29k GitHub stars~746 tokensUpdated today
    DevelopmentAuto-check passed

  • Segment Create

    JanDeDobbeleer/oh-my-posh

    Full scaffolding workflow for creating a new Oh My Posh segment.

    24k GitHub stars~1.2k tokensUpdated today
    DevelopmentAuto-check passed

  • Coding Agent

    TermiX-official/cryptoclaw

    Delegate coding tasks to Codex, Claude Code, or Pi agents via background process.

    100 GitHub starsUsed in 8 repos~2.7k tokens
    DevelopmentAuto-check passed

  • Omm Push

    oh-my-mermaid/oh-my-mermaid

    Push architecture docs to oh-my-mermaid cloud. An agent skill from oh-my-mermaid/oh-my-mermaid.

    2.3k GitHub stars~441 tokensUpdated 6 mo ago
    DevelopmentAuto-check passed

More from sd0xdev/sd0x-harness

All 89 skills in this repo

  • Adr

    sd0xdev/sd0x-harness

    Write an Architecture Decision Record (ADR) for a feature — Context / Decision / Status / Consequences / Alternatives, filed as docs/features/<feature/adr-<NNN-<title.md with a 3-digit zero-padded…

    192 GitHub stars~4.8k tokensUpdated today
    Auto-check passed

  • Load PR Review

    sd0xdev/sd0x-harness

    Load GitHub PR review comments into AI session — analyze, triage, plan.

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

  • Next Step

    sd0xdev/sd0x-harness

    Change-aware next step advisor. An agent skill from sd0xdev/sd0x-harness.

    192 GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • Obsidian CLI

    sd0xdev/sd0x-harness

    Obsidian vault integration via official CLI. An agent skill from sd0xdev/sd0x-harness.

    192 GitHub stars~1.1k tokensUpdated today
    Auto-check passed

  • Orchestrate

    sd0xdev/sd0x-harness

    Agent-driven workflow orchestration (v1 report-only). An agent skill from sd0xdev/sd0x-harness.

    192 GitHub stars~2.5k tokensUpdated today
    Auto-check passed

  • PR Comment

    sd0xdev/sd0x-harness

    Post friendly review comments to a GitHub PR — prepare locally, preview, then submit as atomic review.

    192 GitHub stars~1.5k tokensUpdated today
    Auto-check passed

Works with

Categories

Questions about Tech Spec

What does Tech Spec do?

Tech spec generation and review. An agent skill from sd0xdev/sd0x-harness. Tech Spec is an agent skill from sd0xdev/sd0x-harness. Tech spec generation and review.

When should I use Tech Spec?

Tech Spec fits situations like: : designing features.

How do I install Tech Spec in Claude Code?

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

How do I install Tech Spec in Codex?

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

Can I use 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 sd0xdev/sd0x-harness --skill 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/tech-spec, .gemini/skills/tech-spec, .github/skills/tech-spec and .opencode/skills/tech-spec in your project.

What does Tech Spec need to run?

Going by SKILL.md and its folder, Tech Spec needs the command-line tools its instructions call (git). Its frontmatter pre-approves these tools: Read, Grep, Glob, Bash(git:*), Write.

Does Tech Spec access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

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

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

About 2k tokens (SKILL.md is roughly 8.2k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.9k tokens, read only when the agent opens those files.

What are the alternatives to Tech Spec?

Skills that share tags, products or a category with Tech Spec: Mole Bug Patterns (tw93/Mole, 70k stars), CLI Developer (Jeffallan/claude-skills, 12k stars), JSON Processing with jq (charmbracelet/crush, 29k stars) and Segment Create (JanDeDobbeleer/oh-my-posh, 24k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Tech Spec?

sd0xdev (a GitHub user) maintains it in sd0xdev/sd0x-harness, which has 192 GitHub stars. The repository holds 89 skills in this directory. The repository was last updated on October 8, 2026.

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