SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsdwf-development

dwf-development

Coding & development

View repository

Updated 10-16 09:56

About this skill

dwf-development

This skill is used to execute the requirements analysis, technical solution, or implementation checklist stage of DWF, but each invocation handles only one stage. It does not start the full development workflow and does not generate multiple stage documents consecutively.

  1. Handle only the current stage each time. In workflow mode, use the active spec's current_step as the sole entry point:breakdown write only 03-需求分析/需求分析文档.md，plans write only 04-技术方案/技术方案.md，todos write only 05-实现清单/实现清单.md. In standalone mode, use the target stage confirmed by the user as the entry point. Do not generate multiple stage documents consecutively in a single invocation.

  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 is one of breakdown/plans/todos , and use .dwf/specs/{spec.name} as the target spec directory. If that spec's shared_ref is non-empty (sibling spec), preferentially read .dwf/specs/{shared_ref}/01-需求/、/02-设计稿/ as read-only reference context.
    • Standalone mode:.dwf/state.json does not exist or no active spec satisfying the conditions exists. First determine the target stage based on user input; if unclear, use question to ask for the target stage. Then use question to ask the user for the target directory, proposing by default .dwf/specs/{今日日期}-{seq}-feat-{描述}, where seq scans the maximum sequence number among existing spec directory names in .dwf/specs/ plus 1 (or 001 if none), to be confirmed or modified by the user.

  3. Do not create a full workflow directory. Create or update only the directory and documents corresponding to the current stage. Do not proactively create 01-需求/、02-设计稿/ or other non-current-stage directories. Do not modify existing requirements documents or design drafts. The project code directory is decided by dwf-coding/the user, and this skill does not create it.

  4. Do not overwrite existing documents before confirmation. If the target file already exists in the target spec directory, first read it and inform the user of the existing document, asking whether to keep, modify, or replace it. Do not overwrite before user confirmation.

  1. Use Chinese throughout. Unless the user explicitly requests another language, all interactions with the user, skill descriptions, generated documents, test records, audit conclusions, 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.

  2. In standalone mode, do not create or advance .dwf/state.json。 Standalone mode writes only the current stage document in the target spec directory and that spec's _meta.json(if this skill creates that spec). Do not advance the full workflow. Only in workflow mode, after user confirmation, update that spec's current_step。

Post-trigger flow

1. Explore context

  • Check whether .dwf/state.json exists, and determine the run mode (see step 2).
  • Read the requirements and design basis: in the target spec directory, 01-需求/需求文档.md、02-设计稿/设计稿.md; in workflow mode, if the spec's shared_ref is non-empty, read .dwf/specs/{shared_ref}/01-需求/、/02-设计稿/ first as read-only reference context.
  • Check whether the target file for the current phase already exists.

2. Determine the run mode and target spec directory

Read .dwf/state.json：

  • Standalone mode：.dwf/state.json does not exist or there is no active spec whose current_step is breakdown/plans/todos .

    • First determine the target phase from user input: requirements breakdown/requirements analysis corresponds to breakdown, technical solution corresponds to plans, implementation checklist corresponds to todos; if it cannot be determined, use question to let the user select a target phase.
    • Use question to ask the user for the target spec directory, by default proposing .dwf/specs/{今日日期}-{seq}-feat-{描述}（seq scan .dwf/specs/ the maximum number in existing spec directory names + 1, or 001 if none), for the user to confirm or modify.
    • If the target spec directory does not exist, create only it and the subdirectory corresponding to the target phase:breakdown create 03-需求分析/，plans create 04-技术方案/，todos create 05-实现清单/。
    • Under that spec directory, write an initial _meta.json（name as the directory name,status: "active"、current_step as the target phase,is_shared_context: false、shared_ref: null , etc.).
    • Do not create .dwf/state.json, and do not advance the full workflow.
    • After the current phase is completed, request user confirmation, and stop after confirmation.

  • Workflow mode: in the specs array, find status: "active" and current_step is one of breakdown/plans/todos spec. The target spec directory is .dwf/specs/{spec.name}/。

    • Execute only the phase corresponding to that spec's current current_step . After the phase is completed, update that spec's current_step、confirmed_stages、selected_plan(plans phase), synchronize _meta.json with the top-level updated_at, then stop.
    • Follow dwf-orchestrator's confirmation mechanism.

3. Generate the requirements analysis document

Entry condition: standalone mode with the target phase being breakdown, or workflow mode with the spec's current_step being breakdown。

  1. Read the requirements document (if it exists); if shared_ref is non-empty, read its 01-需求/、02-设计稿/ as read-only context.
  2. Generate the document according to the template in references/breakdown_template.md , covering:
    • Target platform: PC / mobile / both.
    • Page and feature breakdown: List each page's platform, dependencies, and feature modules separately by page; classify cross-page shared modules separately.
    • Assets/dependencies checklist: Which assets the user needs to provide (such as API keys, accounts, third-party service credentials, image assets, etc.).
    • Scope boundaries: Clearly specify what is not included in this implementation.
  3. Save to {目标 spec 目录}/03-需求分析/需求分析文档.md。
  4. Use question tool to show the document to the user and request confirmation.
  5. Wait for user confirmation.
    • If the user chooses "needs modification" or enters modification feedback: directly modify the document, then use question tool again to request confirmation.
    • Only after the user chooses "confirm":
      • Standalone mode: stop.
      • Workflow mode: update this spec's current_step to "plans", append breakdown to confirmed_stages, sync _meta.json and updated_at, then stop and return control to dwf-orchestrator.After completing the breakdown advancement, if this spec is an initialization spec (is_shared_context: true) and its requirements cover multiple pages/complex modules, remind dwf-orchestrator to proactively ask the user whether to split into iterations—this skill does not split directly; the orchestrator handles splitting.

4. Generate technical solution

Entry conditions: standalone mode with the target stage being plans, or workflow mode with the spec's current_step being plans。

  1. Read the requirements document and requirements analysis document; if shared_ref is non-empty, read it as read-only context.
  2. Analyze the codebase (if it exists) to understand the current architecture, conventions, and patterns.
  3. Generate a technical solution according to the template in references/plans_template.md ,must provide at least 2 parallel options. Each option includes:
    • Framework/tech stack selection and rationale
    • Required third-party libraries
    • Backend API requirements (which APIs the backend needs to provide, API field definitions)
    • Data model changes
    • Affected files and modules
    • Risk assessment and mitigation strategies
    • Pros and cons comparison
  4. In {目标 spec 目录}/04-技术方案/技术方案.md , include all options and the option comparison table.
  5. Use the question tool to present the options to the user and request a selection.
  6. Wait for the user's selection.
    • If the user selects "needs modification" or enters modification feedback: directly modify the document, then use the question tool again to request confirmation.
    • Only after the user selects an option:
      • Standalone mode: stop.
      • Workflow mode: set this spec's selected_plan record the selected option,current_step update to "todos", append plans to confirmed_stages, sync _meta.json and updated_at, then stop and return control to dwf-orchestrator.

5. Generate implementation checklist

Entry conditions: standalone mode with the target stage being todos, or workflow mode with the spec's current_step being todos。

  1. Read the requirements document, requirements analysis document, and technical solution (primarily the option specified by selected_plan ); if shared_ref is non-empty, read it as read-only context.
  2. Break the selected option down into specific, ordered tasks, following the template in references/todos_template.md . Task requirements:
    • Break down as much as possible; do not implement a feature or page all at once(for example, a page should be split into independent tasks such as skeleton, component A, component B, state integration, API integration, and styles).
    • Specific enough to be executed unambiguously.
    • Order by dependencies (earlier tasks unblock later tasks).
    • Assign priorities (must/should/could/won't, MoSCoW).
    • Every task must include "coding standard checks" and "verification criteria" to ensure the coding phase can verify them item by item.
  3. Save to {目标 spec 目录}/05-实现清单/实现清单.md。
  4. Use the question tool to show the implementation checklist to the user and request confirmation.
  5. Wait for user confirmation.
    • If the user selects "needs modification" or enters modification feedback: directly modify the document, then use the question tool again to request confirmation.
    • Only after the user selects "confirm":
      • Standalone mode: stop.
      • Workflow mode: update the spec's current_step to "code", append the todos to confirmed_stages, synchronize _meta.json and updated_at, then stop and return control to dwf-orchestrator.

Handling existing documents

If the target file already exists:

  1. Read the existing document.
  2. Summarize the main content of the current document.
  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 with a new document.
  4. Only write to the file after the user explicitly chooses to modify or replace.

When modifying an existing document, preserve the original structure unless the user requests a rewrite. Do not create 文档-v2.md or similar new version files unless the user explicitly requests it.

Pre-completion checks

Before finishing, confirm:

  • Only one document corresponding to the current phase under the target spec directory was created or updated.
  • In standalone mode, no .dwf/state.json。
  • In standalone mode, no subsequent phases were advanced.
  • In workflow mode, multiple phase documents were not generated consecutively in a single invocation.
  • The document content is in Chinese.
  • The document follows the corresponding template in references/ .
  • The save path and the matters requiring user confirmation for the next step have been stated.