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

dwf-coding

Coding & development

View repository

Updated 10-16 08:54

About this skill

dwf-coding

This skill is used to execute only the "coding execution" phase of the DWF workflow. It is only responsible for applying the confirmed solution and implementation checklist to the target code directory. It is not responsible for generating requirements documents, design drafts, requirements analysis, technical solutions, or implementation checklists.

  1. Handle only coding execution. By default, only read or update the target code directory, the target spec directory under 05-实现清单/实现清单.md, necessary project code files, and in workflow mode, .dwf/state.json. Do not proactively create or rewrite 01-需求/、02-设计稿/、03-需求分析/、04-技术方案/ or 05-实现清单/ unless the user explicitly requests returning to the corresponding phase first.

  2. The target code directory and target spec directory are determined by the run mode.

    • Workflow mode: read .dwf/state.json, in specs find in the array a spec with status: "active" and current_step as code . The target spec directory is .dwf/specs/{spec.name}/, and the target code directory isthe workspace root directory(the convention of dwf-orchestrator: code is not placed inside the spec directory, but uniformly placed in the root directory). If shared_ref is non-empty, you may read .dwf/specs/{shared_ref}/01-需求/、/02-设计稿/ as read-only context.
    • Standalone mode: use question to ask the user for the target spec directory (including the implementation checklist and technical solution) and the target code directory. For the spec directory, by default propose .dwf/specs/{今日日期}-{seq}-feat-{描述}, where seq scans .dwf/specs/ for the maximum number among existing spec directory names + 1 (or 001 if none). For the code directory, by default propose the current workspace directory, to be confirmed or modified by the user.

  3. Before coding, the basis must be read. Before executing any code modification, you must first read 05-实现清单/实现清单.md、04-技术方案/技术方案.mdunder the target spec directory (if it exists), references/coding_standards.mdunder this skill directory, and the confirmed programming standards under the project-level .dwf/coding-specs/ (if they exist), and inspect the existing structure of the target code directory. If the implementation checklist is missing or the technical solution is insufficient for execution, first explain the gap and request the user to supplement it or return to dwf-development。

  1. Detect the run mode. Each time it is triggered, check .dwf/state.jsonand find the spec with status: "active" and current_step as code .

    • If found, execute coding in workflow mode. After completion, remove that spec from the specs queue, append it to completed_specs, and increment iteration_count(finalization is handled by dwf-orchestrator; this skill may also update state.json and _meta.json）。
    • If no active spec meeting the conditions is found, execute in standalone mode, do not create .dwf/state.json, and do not advance the complete workflow state.

  2. The programming paradigm agreement must be completed before coding. Before entering "execute coding", you must first reach agreement with the user on the programming paradigm and apply the result to the project-level .dwf/coding-specs/(shared with all specs/iterations, not placed inside the spec directory):

    • Check whether there is already under .dwf/coding-specs/ a *.mdcovering the current tech stack (such as 前端编程规范.md、后端编程规范.md、移动端编程规范.md）。
    • already exists → use question Confirm with the user whether to reuse it; the user may want to modify it. When modifying, negotiate revisions according to the "does not exist" process and update the file. If reusing, skip generation.
    • Does not exist → from 04-技术方案/技术方案.md detect the ends involved this time (frontend/backend/mobile, etc.), use question to confirm with the user which specifications to generate; negotiate each one (third-party library selection, component/module splitting, whether to use TypeScript, state management, styling system, directory structure, naming conventions, API encapsulation, testing approach, etc.), write to .dwf/coding-specs/{端}编程规范.md, and use question to confirm each one.
    • .dwf/coding-specs/*.md Supplement the general baseline of references/coding_standards.md under this skill directory; in case of conflict, the project-level specification prevails; read both.
    • Before obtaining user confirmation, do not enter "execute coding" and do not modify any project code.

  3. Do not bypass confirmation boundaries. If the implementation checklist is still unconfirmed, the spec's current_step is not code, the programming paradigm agreement is not completed, or requirements/design/checklist are found to conflict with each other, you must pause and explain the reason; do not code without authorization.

  4. Execute item by item and mark item by item. Strictly execute tasks in the order of the implementation checklist. Each time one item is completed, verify the result against that task's "coding specification check" and "verification criteria", then mark the corresponding task from [ ] as [x](written to 05-实现清单/实现清单.mdunder the target spec directory). Do not mark all unverified tasks as completed at once.

  5. Change scope is controlled. Only modify files necessary to complete the current task. In workflow mode, only implement the affected scope confirmed this time; do not casually refactor unrelated modules, replace the architecture, or expand requirements.

  6. 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.

Process after triggering

1. Explore the context

  • Check whether .dwf/state.json exists, read the specs array and each item's current_step/selected_plan/shared_ref/updated_at。
  • After finding the spec with status: "active" and current_step: "code" , the target spec directory is .dwf/specs/{spec.name}/, and the target code directory defaults to the workspace root directory. If shared_ref is non-empty, you may read its 01-需求/、02-设计稿/ as read-only context.
  • Read 05-实现清单/实现清单.mdunder the target spec directory, and identify incomplete tasks, task order, verification criteria, and blockers.
  • Read 04-技术方案/技术方案.mdunder the target spec directory; if selected_plan has a value, prioritize the selected design.
  • Read references/coding_standards.mdunder this skill directory; if the file is missing, follow the existing project specifications and the coding constraints provided by the user.
  • Check whether there are already confirmed programming specifications under the project-level .dwf/coding-specs/ (such as 前端编程规范.md、后端编程规范.md、移动端编程规范.md); if so, use them as the project-level conventions for this coding session.
  • Check whether the target code directory already has project code, and analyze the framework, directory structure, naming, styling, testing, and build approach.

2. Determine the run mode

Standalone mode

If any condition is met, it is standalone mode:

  • .dwf/state.json does not exist.
  • .dwf/state.json exists, but specs does not contain status: "active" and current_step: "code" spec.
  • The user explicitly requested "execute coding only, do not advance workflow state".

In standalone mode:

  • Use question to ask the user for the target spec directory (containing the implementation checklist and technical plan) and the target code directory, and provide default proposals (the spec directory defaults to .dwf/specs/{今日日期}-{seq}-feat-{描述}，seq scanning .dwf/specs/ the maximum sequence number among existing spec directory names +1, or 001 if none; the code directory defaults to the workspace current directory), for the user to confirm or modify.
  • Only perform coding and task marking within the target code directory and the implementation checklist under the target spec directory.
  • Do not create .dwf/state.json。
  • After completion, summarize the changes, verification results, and remaining tasks.

Workflow mode

Enter workflow mode when the following conditions are met:

  • .dwf/state.json exists,specs contains status: "active" and current_step: "code" spec, and confirmed_stages contains all affected document phases.

In workflow mode:

  • Execute according to the code phase of dwf-orchestrator. The target code directory is the workspace root directory.
  • After completing each task, update 05-实现清单/实现清单.md under the target spec directory task checkboxes.
  • After all tasks are completed, update .dwf/state.json: remove this spec from specs , append it to completed_specs(including completed_at), increment iteration_count, update updated_at; synchronize this spec's _meta.json to status: "done"、completed_at. Then have dwf-orchestrator use question to ask whether to continue with the next spec.

3. Programming paradigm conventions

Before entering coding, first confirm this programming paradigm with the user, and persist the result to the project-level .dwf/coding-specs/. This directory is shared with all specs/iterations; programming conventions are not repeatedly negotiated per iteration.

  1. Check .dwf/coding-specs/ for existing *.md(e.g. 前端编程规范.md、后端编程规范.md、移动端编程规范.md）。
  2. Read 04-技术方案/技术方案.md, detect the ends involved this time (frontend/backend/mobile, etc.) and the tech stack.
  3. There are existing conventions covering the current tech stack:
    • Use question to confirm with the user whether to reuse the existing conventions (the user may want to modify them).
    • Reuse → skip generation and go directly to "Execute coding".
    • Need to modify → negotiate revisions according to the following "no conventions" process, and update the corresponding files.
  4. Does not exist or needs to be created:
    • Use question to confirm with the user which conventions to generate (according to the ends involved, typically 前端编程规范.md、后端编程规范.md , etc.).
    • Negotiate key paradigms one by one: third-party library selection, component/module splitting approach, whether to use TypeScript, state management approach, styling system, directory structure, naming conventions, interface encapsulation, testing approach, etc.
    • Write the negotiation results to .dwf/coding-specs/{端}编程规范.md, and use question to ask the user to confirm each one.
  5. .dwf/coding-specs/*.md supplement references/coding_standards.md general baseline; in case of conflict, the project-level conventions take precedence.
  6. Only after all conventions are confirmed, enter "Execute coding". Before the user confirms, do not modify any project code.

4. Execute coding

  1. Select the first incomplete and unblocked task from the implementation checklist.
  2. Read the files involved in the task (located in the target code directory); if a file does not exist, first confirm whether it should be created according to the technical plan.
  3. Implement the minimal necessary changes following the project's existing patterns.
  4. Self-check against the coding standards and verification criteria in the task.
  5. Run the relevant verification commands, such as lint, typecheck, test, build; if they cannot be run, explain why and record alternative checks.
  6. Mark the verified completed task as [x](written to the target spec directory under 05-实现清单/实现清单.md）。
  7. Continue to the next task until the checklist is complete or a blocker is encountered.

5. Handle templates and new projects

If the target code directory is empty and the technical plan explicitly chooses to base it on this skill's assets/ React template:

  • For PC, preferentially use this skill directory's assets/react-pc/。
  • For mobile, preferentially use this skill directory's assets/react-mobile/。
  • Common configuration, hooks, utils, request wrappers, etc. can reference or merge this skill directory's assets/shared/。
  • Only copy content that matches the target platform and the chosen plan; do not copy unrelated platform templates, and do not treat dist/ as source code to continue development.

If there is a conflict between the template, the technical plan, and the requirements, pause and explain the conflict to the user.

6. Blocker handling

You must pause when the following situations occur:

  • Missing in the target spec directory 05-实现清单/实现清单.md。
  • The implementation checklist has no clear tasks, verification criteria, or dependency order.
  • The technical plan is missing and the architecture or technology choices cannot be determined.
  • The spec's current_step shows it is still in requirements、design、breakdown、plans or todos。
  • The programming paradigm conventions are not complete (.dwf/coding-specs/ the standards covering the current tech stack are missing or have not been confirmed by the user).
  • During coding, it is discovered that the requirements, plan, or implementation checklist are no longer valid.

When pausing, explain: what is missing, why you cannot continue, and which skill or phase the user should enter to fill the gap.

Pre-completion check

Before finishing, confirm:

  • The implementation checklist, technical plan, coding standards (references/coding_standards.md and .dwf/coding-specs/*.md) and existing code structure have been read.
  • The programming paradigm conventions are complete:.dwf/coding-specs/ the standards covering the current tech stack already exist and have been confirmed by the user, or have been negotiated, generated, and confirmed in this session.
  • Tasks were executed in order, and only verified completed tasks were marked (checked off and written to the implementation checklist in the target spec directory).
  • The available verification commands have been run, or the reason they cannot be run has been explained.
  • In standalone mode, no .dwf/state.json。
  • In workflow mode, only after all tasks are complete, update state.json (move the spec into completed_specs, increment iteration_count) and that spec's _meta.json（status=done）。
  • The summary lists completed tasks, main modified files, verification results, unfinished items, or blockers.