360 Secure SkillHub
360 安全技能中心

spec-writing

核心功能是将自然语言的功能描述转化为聚焦用户价值、无实现细节的可测试规格文档,包含概述、用户场景等标准结构。典型场景包括新功能规格创建、现有规格优化、撰写用户故事与验收准则。输入为自然语言需求,输出符合质量标准的结构化规格,确保需求可验证、范围清晰。

athola
athola
热度 62.58
最近更新 2026-08-26 21:24:22
分类:效率依赖:纯提示词应用场景:报告撰写 / 模板

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add nm-spec-kit-spec-writing
Metadata
name
spec-writing
description
Creates clear, testable specifications from feature descriptions with user stories
version
1.9.8
triggers
["speckit","specification","requirements","user-stories","acceptance-criteria","starting a new feature and needing a spec before planning"]
metadata
{"openclaw":{"homepage":"https://github.com/athola/claude-night-market/tree/master/plugins/spec-kit","emoji":"🦞","requires":{"config":["night-market.superpowers:brainstorming"]}}}
source
claude-night-market
source_plugin
spec-kit

Night Market Skill — ported from claude-night-market/spec-kit. For the full experience with agents, hooks, and commands, install the Claude Code plugin.

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.