CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

write-tech-spec

Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints. Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec.

Quality

88%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-organized, highly actionable instruction-only skill: exact paths, commands, link formats, and checklists leave little ambiguity about what to produce. The main improvements are trimming duplicated commit-reference guidance between sections and either tightening the Parallelization detail or moving it to a reference file.

Suggestions

Deduplicate commit-pinned reference guidance: state it once (in 'Research before writing') and drop the overlapping 'Pin important code references to a commit SHA...' bullet from 'Writing guidance'.

Add an explicit validation checkpoint at the end of the workflow (e.g., re-verify every required section is present, links resolve to the pinned commit, and each PRODUCT.md invariant maps to a verification step) to lift workflow clarity from 4 to 5.

Move the detailed Parallelization per-agent bullet list (execution modes, worktrees, branch/PR strategy, coordination boundaries) into a reference file and keep a 2-3 line summary in SKILL.md, tightening both conciseness and progressive disclosure.

DimensionReasoningScore

Conciseness

The body is dense and assumes Claude's competence (no explanations of git, Mermaid, or spec-writing basics), but commit-pinned reference guidance is repeated in both 'Research before writing' and the 'Writing guidance' bullet, and the Parallelization section runs long. Anchor 4 (efficient, minor trimming possible) fits; not 3 because padding is minor, not 5 because of the duplication and length.

4 / 5

Actionability

Concrete, executable guidance throughout: exact paths ('specs/<id>/TECH.md') with three id examples, 'git rev-parse HEAD' for capturing SHAs, a copy-adaptable Markdown link syntax with worked examples, numeric length targets, and a per-agent parallelization checklist. Matches anchor 5's copy-paste-ready commands covering the common cases.

5 / 5

Workflow Clarity

The sequence is clear and well-ordered (When to use → Research before writing → Structure → Length heuristic → Keep the spec current) with explicit preconditions (prefer PRODUCT.md first, prototype when uncertain) and a required-sections checklist. Falls short of anchor 5 because there is no explicit validation step for the finished spec itself (e.g., verify all required sections or re-check references before delivering), but exceeds anchor 3 since checkpoints are mostly present.

4 / 5

Progressive Disclosure

A single ~95-line SKILL.md with no bundle files, cleanly sectioned, no nested references, and appropriately conditional optional sections ('Omit the heading entirely if empty'). The detailed Parallelization sub-bullets (per-agent mode, worktrees, branch/PR strategy, coordination boundaries) are reference-grade detail that could live in a separate file, matching anchor 4's minor organization gaps rather than anchor 5's tight overview.

4 / 5

Total

17

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: third-person voice, concrete artifact and prerequisites, and an explicit 'Use when' clause with natural trigger phrases that distinguish it from sibling spec skills. The only gap is modest synonym coverage ('tech spec', 'design doc') and not previewing the full scope of what the skill guides.

DimensionReasoningScore

Specificity

Names the concrete artifact ('Write a TECH.md spec'), the domain ('significant Warp feature'), and the prerequisite actions ('researching the current codebase and implementation constraints'). It falls just short of anchor 5 because it does not enumerate the fuller capability surface (structure guidance, testing/parallelization sections), but clearly exceeds anchor 3's 1-2 concrete actions.

4 / 5

Completeness

Explicitly answers both: what ('Write a TECH.md spec for a significant Warp feature after researching the current codebase and implementation constraints') and when ('Use when the user asks for a technical spec, implementation plan, or architecture doc tied to a product spec'). This is an exact match for anchor 5 with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural trigger phrases users would say: 'technical spec, implementation plan, or architecture doc tied to a product spec'. A few common synonyms are missing ('tech spec', 'design doc'), matching anchor 4 rather than anchor 5's comprehensive coverage.

4 / 5

Distinctiveness Conflict Risk

The 'TECH.md' artifact and the 'tied to a product spec' qualifier carve a clear niche distinct from sibling skills like write-product-spec. Triggers are specific enough that users asking for implementation or product specs would route to the correct skill, matching anchor 5's minimal conflict risk.

5 / 5

Total

18

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

warpdotdev/common-skills

Path

.agents/skills/write-tech-spec/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.