SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsdwf-requirement

dwf-requirement

Writing & research

View repository

Updated 10-16 08:54

About this skill

dwf-requirement

This skill is used to organize scattered requirements into a requirements document for the DWF workflow. It is only responsible for requirements capture and requirements document generation; when run independently it does not start the full development workflow, and in workflow mode it follows .dwf/state.json to continue the current stage.

  1. Only generate the requirements document. By default, this skill only creates or updates the target spec directory's 01-需求/需求文档.md. It does not create other stage documents or code.

  2. The target spec directory is determined by the run mode and is not invented by this skill.

    • Workflow mode: read .dwf/state.json, in the specs array find the spec where status: "active" and current_step: "requirements" , and use .dwf/specs/{spec.name} as the target spec directory.
    • Standalone mode:.dwf/state.json does not exist or there is no active spec satisfying the conditions. Use question to ask the user for the target directory, and by default propose .dwf/specs/{今日日期}-{seq}-feat-{从用户输入提取的描述}, where seq scans .dwf/specs/ for the maximum sequence number among existing spec directory names + 1 (or 001 if none), to be confirmed or modified by the user.

  3. In standalone mode, do not create or advance .dwf/state.json。 Standalone mode only writes the requirements document in the target spec directory and that spec's _meta.json(if that spec directory was created by this skill). Do not advance the project to design, breakdown, plans, todos, or code. Only in workflow mode, after user confirmation, update that spec's current_step。

  4. Do not create a complete workflow directory. Except for the target spec directory's 01-需求/ , do not proactively create 02-设计稿/、03-需求分析/、04-技术方案/、05-实现清单/. The project code directory is decided by the user/dwf-coding, and this skill does not create it.

  1. Do not overwrite existing documents before confirmation. If the target spec directory's 01-需求/需求文档.md already exists, first read it and inform the user of the existing document, then ask whether to keep, modify, or replace it. Do not overwrite before the user confirms.

  2. Use Chinese throughout. Unless the user explicitly requests another language, all interactions with the user, requirements clarification questions, generated documents, titles, tags, table contents, explanatory text, test records, and artifact descriptions must be in Chinese. Code, file paths, commands, API names, technical terms, third-party library names, and original content provided by the user may remain in English.

Process after triggering

1. Explore the context

  • Check whether .dwf/state.json exists, and determine the run mode (see step 2).
  • Determine the source of user input: long text, local file path, external link, brief idea, or verbal description.
  • If the user provides a local file path, read the file contents and organize them as the basis for requirements.
  • If the user provides an external document link, use the corresponding skill to read it according to the link type. For example, use lark-docfor Feishu documents and web-access。
  • If the user only gives a brief idea, first clarify the minimum information that affects the requirements structure and acceptance criteria.

2. Determine the run mode and target spec directory

Read .dwf/state.json：

  • Workflow mode: in specs Find in the array status: "active" and current_step: "requirements" spec. The target spec directory is .dwf/specs/{spec.name}/。

    • If under that directory 01-需求/需求文档.md already exists, read it first and execute according to "handling existing documents".
    • After the requirements document is completed and confirmed by the user, update that spec's current_step to "design", append requirements to confirmed_stages, and synchronize its _meta.json with the top-level updated_at。
    • Follow dwf-orchestrator's confirmation mechanism; do not skip user confirmation.

  • Standalone mode：.dwf/state.json does not exist, or there is no active spec that meets the conditions.

    • Use question to ask the user for the target spec directory, proposing by default .dwf/specs/{今日日期}-{seq}-feat-{描述}(the description is extracted from user input,seq scans .dwf/specs/ the maximum sequence number among existing spec directory names +1, or 001 if none), for the user to confirm or modify. If the user chooses another directory, the user's input takes precedence.
    • If the target spec directory does not exist, create it and the 01-需求/。
    • under it. Write an initial _meta.json（name in that spec directory with the directory name asstatus: "active"、current_step: "requirements"、is_shared_context: false、shared_ref: null , etc.).
    • Do not create .dwf/state.json, and do not advance the full workflow.
    • After the requirements document is completed, request user confirmation, and stop after confirmation.

3. Determine the input source

Choose the handling method based on the information provided by the user:

  • Complete requirements document or long text: Directly extract the project name, background, goals, user roles, scope, functional requirements, non-functional requirements, constraints, dependencies, risks, and acceptance criteria.
  • Local file path: After reading the file contents, organize them into a requirements document.
  • External document link: Use the corresponding skill to read it according to the link type. For example, use lark-docfor Feishu documents and web-access。
  • Brief idea or verbal description: Clarify the requirements first; do not rush to generate a document.

4. Clarify missing information

If the information is insufficient, ask follow-up questions one at a time. Prioritize clarifying content that affects the document structure and acceptance criteria:

  1. Project name or one-sentence overview.
  2. Background and business value.
  3. Target users and roles.
  4. Target platform: PC, mobile, or both.
  5. In-scope and out-of-scope content.
  6. Core use cases and main flow.
  7. Functional requirements and priorities.
  8. Non-functional requirements.
  9. Constraints, assumptions, dependencies, and risks.
  10. Overall acceptance criteria.

Do not throw out a large number of questions at once. If reasonable assumptions can be made based on context, first write them explicitly into "Assumptions", and put uncertain items into "Items to be confirmed".

5. Generate the requirements document

Read references/requirements_template.md, and generate a Chinese requirements document according to the template. Save it to the target spec directory:

{目标 spec 目录}/01-需求/需求文档.md

Generation rules:

  • Keep the YAML frontmatter, including project、version、author、date、status and revision。
  • The new document's status defaults to draft。
  • date Use the current date.
  • version Initially 1.0.0。
  • revision Record "initial version".
  • The document must include a business process diagram, using Mermaid to express the main flow; if information is insufficient, generate a reasonable high-level flow and mark the branches that need confirmation in "Items to Be Confirmed".
  • Functional requirements use FR-1、FR-2 numbering.
  • Non-functional requirements use NFR-1、NFR-2 numbering.
  • Priorities use MoSCoW: Must, Should, Could, Won't.
  • Acceptance criteria must be observable or testable.

6. Request user confirmation

After generating the document, show the user the save location and a brief summary, and request confirmation:

  • If the user confirms, state that the requirements document is complete.
  • If the user provides modification suggestions, directly update 01-需求/需求文档.mdunder the target spec directory, keep status: draft, and request confirmation again.
  • If the user explicitly requests that it be marked as confirmed, change status in the frontmatter to confirmed, and append a confirmation record in revision .

After confirmation is complete:

  • Standalone mode: stop, and do not automatically proceed to the design draft, requirements analysis, technical proposal, implementation checklist, or coding.
  • Workflow mode: update the spec's current_step to "design", append requirements to confirmed_stages, synchronize _meta.json and updated_at, and let dwf-orchestrator advance.

Handling existing documents

If the target file already exists:

  1. Read {目标 spec 目录}/01-需求/需求文档.md。
  2. Summarize the current document's project name, version, status, and main content.
  3. Ask the user how to handle it:
    • Keep the existing document, and only view or summarize it.
    • Modify based on the existing document.
    • Replace it with a new requirements document.
  4. Only after the user explicitly chooses to modify or replace may the file be written.

When modifying an existing document:

  • Preserve the original structure unless the user requests a rewrite.
  • Update date。
  • If the user confirms that this is a new version, increment version and append a revision entry.
  • Do not create 需求文档-v2.md or similar new version files unless the user explicitly requests it.

Pre-completion check

Before finishing, confirm:

  • Only 01-需求/需求文档.md。
  • under the target spec directory was created or updated; in standalone mode, .dwf/state.json。
  • In standalone mode, no phase directories other than the target spec directory 01-需求/ were created.
  • In standalone mode, no subsequent phases were advanced.
  • In workflow mode, the spec's current_step was updated to design。
  • The document content is in Chinese.
  • The document includes frontmatter.
  • The document includes background, goals, user roles, scope, use cases, functional requirements, non-functional requirements, constraints, dependencies, risks, acceptance criteria, and items to be confirmed.
  • The save path and the matters requiring user confirmation for the next step have been explained.