Nm Spec Kit Spec Writing

Create clear, testable specifications from feature descriptions with user stories, acceptance criteria, and success metrics

Security Scan

The skill's instructions, files, and requirements are coherent with a spec-writing assistant: it's instruction-only, requests no secrets or unusual binaries, and appears proportionate to its purpose.

Purpose & Capability

Name and description describe a specification-writing assistant and the included SKILL.md and module files contain templates, checklists, and patterns consistent with that purpose. The single declared config dependency (night-market.superpowers:brainstorming) plausibly maps to enabling platform features and is not inconsistent with the stated functionality.

Instruction Scope

Runtime instructions are purely about producing specification text, templates, and checklists. They do not instruct the agent to read arbitrary files, access environment variables, call external endpoints, or collect unrelated system data.

Install Mechanism

No install spec and no code files — this is instruction-only, so nothing is written to disk and no external packages are downloaded. This is the lowest-risk installation model.

Credentials

The skill requires no environment variables or credentials. It does declare a required config path (night-market.superpowers:brainstorming) which likely references a platform feature toggle or config namespace; this is reasonable but the exact scope of that config (what data it exposes) depends on platform implementation and should be understood before granting.

Persistence & Privilege

always:false and user-invocable:true (default). Autonomous model invocation is allowed (disable-model-invocation:false) which is normal for skills; the skill does not request permanent presence or system-wide configuration changes.

Assessment

This skill is instruction-only and appears coherent with its purpose. Before installing: (1) review what the platform config key night-market.superpowers:brainstorming controls (to ensure it doesn't grant broader access than you expect); (2) avoid feeding sensitive secrets or proprietary documents into the skill unless you trust the environment; (3) if you want stricter control, disable autonomous invocation for this skill or require explicit user approval before it runs; (4) verify the plugin homepage/owner if you want additional assurance about provenance and updates.

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.