Stats
Actions
Tags
From tsdd
Use when a new feature, system, or product idea appears in conversation — before any implementation discussion begins
How this skill is triggered — by the user, by Claude, or both
Slash command
/tsdd:spec-createThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a new HTML specification document through collaborative dialogue.
Create a new HTML specification document through collaborative dialogue.
Precondition: spec/index.html must not exist. If it already exists, use tsdd:spec-update instead, or ask the user whether they want to extend the current spec or document a separate feature.
Auto-trigger when:
spec/index.html does not yet existDO NOT write any files until the user has reviewed and approved the full draft in the conversation. Violations of this gate produce specs the user did not agree to.
Ask the user to describe the idea in one sentence if they haven't already. Then ask questions one at a time in this order:
Rules:
After gathering answers, show the full spec draft as text in your message. Do not write files yet.
Formatting note: Use 2-space indentation throughout. One attribute per tag on long lines. This keeps git diffs human-readable.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>[Feature Name] Spec</title>
</head>
<body>
<h1>[Feature Name]</h1>
<section id="why">
<h2>Why</h2>
<p>[Background and motivation.]</p>
</section>
<section id="what">
<h2>What</h2>
<p>[What the system does. User stories and behaviors.]</p>
<p>
When a <a href="glossary.html#term-user" class="term">user</a> does X,
the system does Y.
</p>
</section>
<section id="out-of-scope">
<h2>Out of Scope</h2>
<ul>
<li>[Thing we explicitly will not do.]</li>
</ul>
</section>
<section id="success-criteria">
<h2>Success Criteria</h2>
<ul>
<li>[Measurable condition that means "done".]</li>
</ul>
</section>
</body>
</html>
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Glossary</title>
</head>
<body>
<h1>Glossary</h1>
<dl>
<dt id="term-user">User</dt>
<dd>
A person with an account in this system.
<footer>See: <a href="index.html#what">What</a></footer>
</dd>
</dl>
</body>
</html>
<a href="glossary.html#term-NAME" class="term">TERM</a><dd> ends with <footer>See: <a href="SPEC_FILE.html#SECTION_ID">Section Title</a>(, additional refs as needed)</footer>Include glossary entries only for domain-specific terms; exclude common English words. If a term is something a general audience would understand without specialized context, it does not need a glossary entry.
Before moving to Phase 3, review the draft for domain-specific terms. Ask the user:
"These terms appear in the spec—want definitions for any of them: [term1], [term2], [term3]?"
Allow the user to suggest additional terms or decline glossary entries. Update the draft as needed.
After showing the draft, ask:
"Does this look right? Any changes before I write the files?"
Revise and re-show as needed. Do not write files until the user explicitly approves.
Recovery path: If the user's changes contradict answers from Phase 1 (fundamental revision), return to Phase 1 and re-ask affected questions. Otherwise, revise the draft locally and re-show.
Once the user approves:
spec/ if it does not existspec/index.htmlspec/glossary.htmlgit add spec/
git commit -m "feat(spec): initial spec for [feature-name]"
If any section in a spec file exceeds ~150 lines, suggest splitting:
"The [Section] section is getting large. Want me to move it to
spec/[section-name].htmland link from index.html?"
Do not split without user approval.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub iwtn/tsdd --plugin tsdd