workflow-kit-specify

Convert AI change requests into atomic spec.md files with scope and verification.

Updated May 27, 2026
One-click install
npx skills add https://github.com/Kat4X/spec-kit --skill workflow-kit-specify
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workflow-kit-specify
Source: https://github.com/Kat4X/spec-kit/tree/main/skill-drafts/workflow-kit-specify
Command: npx skills add https://github.com/Kat4X/spec-kit --skill workflow-kit-specify

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It helps you turn an AI change request into a self-contained, checkable specification so the next agent step can proceed without guessing what was intended, allowed, or out of scope.

Core Features & Use Cases

  • Atomic change spec creation: Produce a spec.md that captures a single desired result (WHAT/WHY) and the boundaries of editing.
  • Managed clarity via requirements and questions: Force unknowns into explicit “ТРЕБУЕТ УТОЧНЕНИЯ” questions or safe assumptions so planning doesn’t stall later.
  • Quality and workflow readiness: Ensure the spec matches the required template structure and is prepared for workflow-kit-plan.

Quick Start

Create a workflow-kit-specify workspace and generate spec.md for the atomic change “add support for exporting reports as CSV” before running workflow-kit-plan.

Frequently Asked Questions about workflow-kit-specify

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a specification for an AI change request without including implementation details?

To write a specification without implementation details, you create a self-contained atomic spec.md that captures WHAT/WHY, scope boundaries, and verification. This enforces no-HOW writing, ensuring requirements stay separate from implementation decisions for the next agent step.

What is an atomic workflow specification and when do I need one for agent handoff?

An atomic workflow specification is a single self-contained spec.md defining one verifiable desired result for agent handoff. You need it when preparing the next workflow step, preventing implementation guessing by explicitly capturing requirements, scope boundaries, and open questions.

How do I manage scope boundaries and open questions when converting a change request into a markdown specification?

To manage scope boundaries and open questions in a markdown specification, you force unknowns into explicit clarification requests or safe assumptions. This ensures planning doesn't stall later by requiring a single verifiable desired result before proceeding.

What happens if my change request lacks a single verifiable desired result for the workflow specification?

If your change request lacks a single verifiable desired result, the workflow specification process stops and requests clarification. This prevents ambiguous requirements from leaking into the spec.md, ensuring the next agent step receives a checkable atomic specification.

Can I use a custom template for atomic specification creation and scope control?

You must use the required SPEC-TEMPLATE.md for atomic specification creation and scope control, with an optional SCOPE-TEMPLATE.md. These templates enforce the no-HOW writing structure and ensure the spec.md is prepared for the downstream workflow-kit-plan step.