agentsclimarketplace

Spec writing

Skill athola/claude-night-market/plugins/spec-kit/skills/spec-writing

23 Claude Code plugins: TDD enforcement hooks, git/PR workflows, spec-driven development, code review, project lifecycle, fix-from-error, maintenance automation, context optimization, research, and multi-LLM delegation. 186 skills, 128 commands, 54 agents.

Install
npx -y skills add athola/claude-night-market --skill spec-writing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Creates clear, testable specifications from feature descriptions with user stories. Use when starting a new feature and needing a spec before planning.

SKILL.md

4.0 KB, 689 tokens by cl100k_base, as published. Nobody here has run it

Spec Writing

Overview

Create clear, complete, and testable specifications from natural language feature descriptions. Specifications focus on user value and business needs, avoiding implementation details.

When To Use

  • Creating new feature specifications
  • Refining existing specifications
  • Writing user stories and acceptance criteria
  • Defining success criteria

When NOT To Use

  • Generating implementation tasks - use task-planning

Core Principles

Focus on user value and business needs rather than implementation details. Avoid specifying technology choices in requirement definitions unless strictly necessary. Ensure every requirement is testable and verifiable with measurable criteria. Limit clarification markers; make informed assumptions based on industry standards and document them explicitly.

Specification Structure

Mandatory Sections

  1. Overview/Context: What problem does this solve?
  2. User Scenarios: Who uses it and how?
  3. Functional Requirements: What must it do?
  4. Success Criteria: How do we know it works?

Optional Sections

  • Success Criteria (when performance/security critical)
  • Edge Cases (when special handling needed)
  • Dependencies (when external systems involved)
  • Assumptions (when decisions made with incomplete info)

See: modules/specification-structure.md for detailed templates and guidelines

Quality Checklist

  • No implementation details present
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • User scenarios cover primary flows
  • Edge cases identified
  • Scope clearly bounded

Success Criteria Quick Reference

Good (User-focused, Measurable, Technology-agnostic)

  • "Users complete checkout in under 3 minutes"
  • "System supports 10,000 concurrent users"
  • "95% of searches return results in under 1 second"

Bad (Implementation-focused, Internal metrics)

  • "API response time under 200ms" -> Use: "Pages load in under 2 seconds"
  • "Redis cache hit rate above 80%" -> Use: "Frequently accessed data loads with no noticeable delay"
  • "React components render efficiently" -> Use: "UI updates appear with no visible frame drops"

See: modules/success-criteria-patterns.md for detailed examples and conversion process

Related Skills

  • speckit-orchestrator: Workflow coordination
  • task-planning: Converting specs to tasks

Troubleshooting

Common Issues

If specifications are too vague, use the success-criteria-patterns module to enforce measurable outcomes. If implementation details leak into specs, review against the "Core Principles" and refactor to focus on user behavior.

Exit Criteria

  • Spec document contains all 4 mandatory sections: Overview/Context, User Scenarios, Functional Requirements, and Success Criteria
  • All success criteria are user-focused and measurable (e.g. "Users complete checkout in under 3 minutes") not implementation metrics (e.g. "API response under 200ms")
  • Quality checklist passes: no implementation details present, requirements unambiguous, edge cases identified, scope bounded
  • No technology choices appear in requirements unless the spec explicitly marks them as strictly necessary constraints
  • Each functional requirement has at least one testable acceptance criterion that can be verified from outside the system

Gives 0 of the 12 instructions most docs writing skills give in 689 tokens

Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-06

  • announce the skill at startin 54 of 1637, across 21 files
  • convert legacy doc files before editingin 45 of 1637, across 7 files
  • predict questions readers might askin 42 of 1637, across 3 files
  • Generate clarifying questions for initial contextin 42 of 1637, across 3 files
  • Create document scaffold with placeholder textin 42 of 1637, across 3 files
  • Brainstorm content options for each sectionin 42 of 1637, across 3 files
  • Test document with fresh context-less instancein 42 of 1637, across 3 files
  • ask interview questions one at a timein 42 of 1637, across 26 files
  • include exact file paths in every taskin 42 of 1637, across 15 files
  • Apply surgical edits during refinementin 41 of 1637, across 2 files
  • Offer structured workflow or freeformin 40 of 1637, across 1 file
  • Ask for document meta-contextin 40 of 1637, across 1 file

Said here and by no other author read

  • focus on user value and business needs
  • make success criteria user-focused
  • ensure each requirement has a testable acceptance criterion

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.