technical-spec-document

technical-spec-document is a skill for Claude Code from lenar-amirov/product-pipeline-public. It costs 82 tokens per session (552 once invoked), scanned A, original, MIT.

An implementation blueprint that translates product requirements into a shared plan for the development team. It describes what changes, how parts should behave, and how each requirement will be checked.

In plain words
What is it for?
Use it to scope component changes, describe inputs, outputs, and errors, connect user stories to implementation work, define tracking needs, and structure estimates.
Why use it?
It prevents requirements from being lost or expanded during estimation and gives developers clear behavior and verification points.

Skill for Claude Code

Written for Claude Code: installed under .claude/.

Good fit Use it to scope component changes, describe inputs, outputs, and errors, connect user stories to implementation work, define tracking needs, and structure estimates.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/lenar-amirov/product-pipeline-public/technical-spec-document
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add lenar-amirov/product-pipeline-public --skill technical-spec-document
Clone the repo
git clone --depth 1 https://github.com/lenar-amirov/product-pipeline-public

Made for: Claude Code.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for technical-spec-document

README.md
[![agentmods](https://agentmods.dev/badge/skills/lenar-amirov/product-pipeline-public/technical-spec-document/github.svg)](https://agentmods.dev/skills/lenar-amirov/product-pipeline-public/technical-spec-document)
Your own site
<a href="https://agentmods.dev/skills/lenar-amirov/product-pipeline-public/technical-spec-document"><img src="https://agentmods.dev/badge/skills/lenar-amirov/product-pipeline-public/technical-spec-document/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

agentmods 80×15 button for technical-spec-document

Your own site · 80×15
<a href="https://agentmods.dev/skills/lenar-amirov/product-pipeline-public/technical-spec-document"><img src="https://agentmods.dev/badge/skills/lenar-amirov/product-pipeline-public/technical-spec-document.svg" alt="Reviewed on agentmods" width="80" height="20"></a>
Per session 82 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 552 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00082 $0.00552
Opus 5 $0.00041 $0.00276
Sonnet 5 $0.00016 $0.00110
Haiku 4.5 $0.00008 $0.00055

Measured 11d ago against content hash 3f43615877ac, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-10, from the pricing page.

Security

Grade A, and why

technical-spec-document scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/technical-spec-document/SKILL.md · 49 lines

How it starts

The opening of the file, as written. The whole thing — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Technical Spec (implementation blueprint)

Boundary: this skill = what will be built for THIS initiative, agreed with the dev team. What the system already looks like and what constrains us is system-design-doc.

The spec's customer is the dev team; its source of truth is PRD §6–8 (which traces to confirmed hypotheses in the registry). Nothing enters the spec without tracing back to a requirement — and no requirement leaves without acceptance criteria.

Structure

  1. Scope by component — for each affected component (from system-design-doc): what changes, and what explicitly does NOT change (the out-of-scope list prevents estimate creep).
  2. Contracts at behavior level — new/changed interfaces described as inputs → outputs → errors. Enough for the dev team to design against; not pretending to be their design. Example: submit_order(cart, payment_method) → order_id + confirmation event; errors: payment_declined (retryable), out_of_stock (per item, cart preserved) — behavior, not schemas.
  3. Acceptance mapping — every user story from PRD §8 → which component(s) deliver it → how we verify (feeds /tickets Given/When/Then directly).
  4. Tracking requirements — events the solution must emit so the AB test (step 14) and post-launch review can measure it. A solution that ships unmeasurable is a spec bug.
  5. Estimate structure — S/M/L per component with the dev lead's confidence; unknowns from system-design-doc widen ranges explicitly.

Output

output/dev-estimate.md (spec section) + PRD §9–10 updates. Feeds /tickets — Epics/Stories are generated from the acceptance mapping, so sloppy mapping here becomes sloppy tickets there.

Anti-patterns

  • Duplicating system-design-doc content — link to it instead.
  • Code-level detail (schemas, class names) — that's the dev team's design.
  • Specs for features whose hypotheses are not confirmed in the registry — check hypotheses.py show <dir> before writing a line.

Read the full file on GitHub · 49 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 11d ago First seen · 49 lines · 82 tokens per session scan A 3f43615877ac

Subscribe to this mod's changes

technical-spec-document is a skill published in the GitHub repository lenar-amirov/product-pipeline-public (12 stars, last pushed 21d ago), licensed MIT. It adds 82 tokens to every session and 552 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

seo-strategy

Audits and improves organic search performance — technical health, site architecture, internal linking, structured data, and the content decisions that determine what can rank. Use this to run an SEO audit, diagnose why pages are not ranking or were deindexed, plan a site's URL and navigation structure, add structured…

cbrock84/headcount · 74 tokens

youtube-producer

Plans, packages, and scripts long-form video for retention and channel growth — idea selection, titles and thumbnails, script structure, and diagnosing why a video or channel underperforms. Use this for video ideas, packaging, scripting, a retention teardown, or channel strategy — including when someone describes a…

cbrock84/headcount · 86 tokens

support-operations

Designs and runs the support function — channels, queues, routing, staffing, service levels, quality, and the metrics that show whether it is working. Use this to set up or fix support operations, choose channels, size a team, set or renegotiate service levels, reduce cost per contact, diagnose long queues or poor…

cbrock84/headcount · 77 tokens

ai-ml-governance

Governs models and AI systems in production — intended use, evaluation, monitoring, human oversight, documentation, and the decision to deploy or retire. Use this before deploying a model or AI feature, when defining evaluation criteria, when a model's behavior has drifted, when assessing AI risk or regulatory…

cbrock84/headcount · 83 tokens

paid-advertising

Plans, runs, and optimizes paid acquisition across search, social, and display — account structure, targeting, creative, bidding, budget, and the analysis that says whether to scale or stop. Use this to set up or restructure campaigns, write and iterate ad creative, diagnose rising costs or falling performance, decide…

cbrock84/headcount · 78 tokens

customer-onboarding-and-implementation

Takes a new customer from signature to working — setting a definition of live that both sides agreed before the contract was signed, planning and staffing the implementation, running data migration and integration realistically, training the people who will actually use it, and handing over to the ongoing…

cbrock84/headcount · 94 tokens