Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计提醒

requirement-workflow需求工作流程

Agent Skill

requirement-workflow 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

1,371

周安装

56

GitHub Stars

1

下载量

444
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:requirement-workflow(需求工作流程)
来源仓库:https://github.com/learnwy/skills
仓库路径:skills/requirement-workflow
安装命令:
npx skills add https://github.com/learnwy/skills --skill requirement-workflow
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/learnwy/skills --skill requirement-workflow

简介

requirement-workflow 用于查找、检索和筛选相关信息。

  • 它适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果。
  • 可结合来源仓库、安装命令和原始 README 继续核验具体用法。
  • 安装命令为 npx skills add https://github.com/learnwy/skills --skill requirement-workflow。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Requirement Workflow (SDD)

Structured development orchestrator based on Spec-Driven Development: define specs first, decompose into tasks, execute with quality gates, verify against acceptance criteria.

Core principle: Spec is the single source of truth. Code follows spec, not the other way around.

Prerequisites

  • Node.js >= 18
  • Writable project directory for workflow state files (.trae/workflow/)

Quick Start

User says anything about building/implementing/fixing →
  1. AI classifies the request (type + size + risk)
  2. AI runs: node init.cjs -r <root> -n <name> -t <type> -s <size> -k <risk>
  3. AI fills spec.md with structured requirements (EARS format)
  4. AI decomposes spec.md into tasks.md
  5. AI implements task by task, advancing stages
  6. AI verifies against checklist.md

Working Modes

This skill supports two modes, selected based on classification:

Agent Mode (Default)

For small/tiny scope or bugfix type: skip spec phase, go straight to implementation.

INIT → IMPLEMENTING → TESTING → DONE

Spec Mode (SDD)

For medium/large scope or elevated/critical risk: full SDD lifecycle.

INIT → DEFINING → PLANNING → DESIGNING → IMPLEMENTING → TESTING → DELIVERING → DONE

Classification Matrix

SignalTypeSizeRisk
"fix bug", "broken", "crash"bugfixtiny-smallnormal
"add feature", "implement", "build"featuresmall-largenormal
"refactor", "clean up", "reorganize"refactorsmall-mediumnormal
"tech debt", "upgrade", "migrate"tech-debtmedium-largeelevated
auth, payments, data, securityanyanyelevated-critical
>15 files estimatedanylargeelevated

Size Heuristics

SizeFilesDurationStages
tiny≤2<30minINIT → IMPLEMENTING → DONE
small3-530min-2hINIT → IMPLEMENTING → TESTING → DONE
medium6-152h-1dFull SDD
large>15>1dFull SDD + all checkpoints

SDD Lifecycle

Stage 1: INIT

Classify request, initialize workflow, create artifact directory.

node init.cjs -r <project_root> -n "<name>" -t <type> -s <size> -k <risk>

Output: workflow.yaml, empty spec.md, tasks.md, checklist.md

Stage 2: DEFINING (Spec Mode only)

Fill spec.md with structured requirements using EARS format:

# Feature Name

## Background
{Why this is needed — problem statement}

## Scope
- In: {what IS included}
- Out: {what is NOT included}

## Acceptance Criteria (EARS format)
- [ ] When <condition>, the system shall <response>
- [ ] While <state>, the system shall <behavior>
- [ ] Where <constraint>, the system shall <limit>

## Constraints
- {Performance, security, compatibility requirements}

## Out of Scope
- {Explicitly deferred items}

Checkpoint: If risk is elevated/critical, pause for user review of spec.md.

Hooks: pre_stage_DEFINING → iron-audit-pm, problem-definer, risk-auditor

Stage 3: PLANNING (Spec Mode only)

Decompose spec.md into tasks.md — every acceptance criterion maps to ≥1 task:

# Tasks

## Phase 1: Foundation
- [ ] Task 1.1: {description} [files: x, y]
- [ ] Task 1.2: {description} [files: z]

## Phase 2: Core Logic
- [ ] Task 2.1: {description} [files: a, b]

## Phase 3: Integration & Polish
- [ ] Task 3.1: {description} [files: c]

## Verification
- [ ] All acceptance criteria pass
- [ ] Lint clean
- [ ] Type check pass

Rule: Each task must be atomic (completable independently) and traceable to a spec item.

Hooks: pre_stage_PLANNING → story-mapper, mvp-freeze-architect

Stage 4: DESIGNING (Spec Mode only)

Create design.md (only for medium+ size) with architecture decisions:

  • Component structure
  • Data flow
  • API contracts
  • Key trade-offs

Checkpoint: If risk is elevated/critical, pause for user review.

Hooks: pre_stage_DESIGNING → domain-modeler, architecture-advisor, responsibility-modeler

Stage 5: IMPLEMENTING

Execute tasks from tasks.md sequentially. For each task:

  1. Read the task description
  2. Implement the change
  3. Mark task as [x] in tasks.md
  4. Run relevant tests if available

Hooks: pre_stage_IMPLEMENTING → tdd-coach

Stage 6: TESTING

Run full test suite. Update checklist.md:

# Checklist

## Code Quality
- [ ] Implementation complete
- [ ] Lint clean (run lint command)
- [ ] Type check pass (run typecheck command)

## Tests
- [ ] Unit tests pass
- [ ] Integration tests pass (if applicable)

## Acceptance Criteria
- [ ] AC 1: {criterion from spec} — verified
- [ ] AC 2: {criterion from spec} — verified

## Review
- [ ] Self-review complete
- [ ] No TODO/FIXME left unresolved

Hooks: pre_stage_TESTING → test-strategy-advisor, test-strategist, code-reviewer

Stage 7: DELIVERING (Spec Mode only)

Final verification against spec.md. Ensure every acceptance criterion has been met.

Hooks: post_stage_DELIVERING → code-reviewer, tech-design-reviewer

Stage 8: DONE

Workflow complete. Summary output:

  • What was delivered
  • Files changed
  • Tests passed
  • Time elapsed

Stage Advancement

# Check current status
node status.cjs -r <project_root>

# Advance to next stage
node advance.cjs -r <project_root>

# Force advance (skip checkpoint)
node advance.cjs -r <project_root> --force

Hooks System

Hooks are agents/skills that run at stage transitions. Three scopes:

ScopeFilePriority
Globalhooks.yaml (skill dir)Lowest
Project.trae/workflow/hooks.yamlMedium
Workflowworkflow.yaml (in workflow dir)Highest

Hook Points

HookWhenDefault Agents
pre_stage_DEFININGBefore filling speciron-audit-pm, risk-auditor
pre_stage_PLANNINGBefore task decompositionstory-mapper, mvp-freeze-architect
pre_stage_DESIGNINGBefore architecturedomain-modeler, architecture-advisor
pre_stage_IMPLEMENTINGBefore codingtdd-coach
pre_stage_TESTINGBefore test phasetest-strategy-advisor, code-reviewer
post_stage_DELIVERINGAfter final checktech-design-reviewer
# List hooks
node hooks.cjs -r <project_root> list

# Add a hook
node hooks.cjs -r <project_root> add pre_stage_TESTING -n my-validator --type skill

Quality Gates

Checkpoint Rules

StageCheckpoint When
DEFININGrisk = elevated or critical
PLANNINGsize = large or risk ≥ elevated
DESIGNINGsize ≥ medium or risk ≥ elevated
TESTINGalways (all risk levels)

At checkpoints, AI pauses and asks user for confirmation before advancing.

SDD Traceability Rule

Every line of code must trace back to:

  1. A task in tasks.md
  2. Which traces to an acceptance criterion in spec.md

If you find yourself writing code not covered by any task — stop and update tasks.md first.

Error Handling

IssueSolution
User gives vague requestClassify as feature/small, use Agent Mode, refine during implementation
Spec is incompleteAdd missing acceptance criteria before advancing to PLANNING
Task is too largeBreak into sub-tasks, each ≤1 file change
Tests fail during TESTINGStay in TESTING, fix issues, re-run
Checkpoint rejected by userStay in current stage, revise artifacts per feedback
Workflow abandonedNo cleanup needed, state persists in .trae/workflow/

Scripts

ScriptPurpose
init.cjsInitialize workflow with classification
advance.cjsAdvance to next stage
status.cjsShow current workflow status
hooks.cjsManage hook registrations
lib/common.cjsShared YAML utilities

Agents

See AGENTS.md for the full registry. Key agents by phase:

PhaseAgentMethodology
DEFININGiron-audit-pmPRD audit, DNA extraction
DEFININGrisk-auditorRisk scanning
DEFININGproblem-definerWeinberg problem analysis
PLANNINGstory-mapperPatton story mapping
PLANNINGmvp-freeze-architectScope freezing
DESIGNINGdomain-modelerDDD/Evans modeling
DESIGNINGarchitecture-advisorQuality attributes
IMPLEMENTINGtdd-coachBeck TDD cycle
TESTINGtest-strategistCrispin test strategy
TESTINGcode-reviewerCode review
DELIVERINGtech-design-reviewerArchitecture review

References

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.6%
按下载量换算154

Claude

29.37%
按下载量换算130

Cursor

19.28%
按下载量换算86

Gemini CLI

9.69%
按下载量换算43

安全审计

Gen Agent Trust Hub

通过

Socket

可疑

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills