Write Workflow

Write Workflow

Eight-stage document-writing host. Writer skills own methodology; this host owns routing, source analysis, mode lifecycle, path depth, and verify/retrospect.

Writers: tech-review-doc (in-repo, design → review). humanizer / humanizer-zh are external strong dependencies (not shipped in this repo) for EN/ZH de-slop.

Not solve-workflow / analysis-core. Stage 2 is writing-oriented source analysis only.

Output templates: reference.md.

Prerequisite skill check

At startup, verify every frontmatter dependencies entry. If any is missing, abort with an install hint — no silent degradation.

Or for all in-repo open-skills: npx skills add FuDesign2008/open-skills -g --skill '*' --yes (does not install external humanizers).

Must not depend on: analysis-core, runtime-evidence-debug, hybrid-debug, browser-debug-toolkit. Must not vendor: do not add skills/humanizer/ or skills/humanizer-zh/ to this repository.

Triggers and modes

Mode detection: 「自动」 → auto; else manual. Mid-run: 「切换自动模式」/「切换手动模式」.

Core lifecycle → workflow-mode-lifecycle. Differences:

• Completion = stage 8 done → revert to manual.
• Hard pauses (even in auto):
  • tech-review-doc: §1 user approval; missing design path
  • humanizer / humanizer-zh: confirmed input text or file path (no tech-review §1 gate)
• After hard pause clears in auto: continue writer + stages 7–8 without extra host stops.
• Interruption → revert to manual.

Path selection

⚡ Quick Reference

Stage 1: Clarify intent

1. Document type / writer route (table below).
2. Path (Full/Incremental/Lean) and mode.
3. clarifying-question-discipline when unclear (one question per turn).
4. Language for humanize: primarily Chinese → humanizer-zh; primarily English → humanizer; ambiguous → ask once.

[👤] Confirm. [🤖] Skip confirm when route + inputs already clear.

Output: reference.md § Stage 1.

Stage 2: Analyze sources

1. Existence: required input readable (design path or text/file to humanize).
2. Inventory: for tech-review — title/modules/Mermaid/multi-option; for humanize — language, length, tone target.
3. Gaps: list blockers for later stages.
4. Do not write the final output file yet (except analysis notes in chat).

[👤] Stop after report. [🤖] Continue unless blocking gap.

Stages 3–5 by writer profile

Profile: tech-review-doc

• 3 Diagrams / §3 / §6 / §4 depth
• 4 Audience checklist (no code in §§1–3)
• 5 Outline → hand off writer Step 1 (§1 draft)

Profile: humanizer / humanizer-zh

• 3 Scope: whole doc vs selection; tone (formal/casual/technical)
• 4 Checklist: preserve facts; no invented claims; match tone
• 5 Short plan: input → rewrite → optional change summary

[👤]/[🤖] pauses per Quick Reference.

Stage 6: Execute via writer

Load the routed writer and follow it exactly.

• tech-review-doc: HARD-GATE on §1; auto may continuous-run after approval.
• humanizer / humanizer-zh: require confirmed input; then rewrite per that skill; do not apply tech-review §1.

Stage 7: Verify

• tech-review-doc: path/naming, §1 approved, diagrams, §3/§6 rules, §§1–3 language rules.
• humanizer:* facts preserved, AI patterns reduced, tone matched; optional quality score if the writer defines one.

Output: reference.md § Stage 7.

Stage 8: Retrospect

Brief improvements. Do not edit skill files unless asked. Revert auto → manual.

Extension slot (future writers)

1. Add skills/<name>/ and publish.
2. Prefer optional route unless product requires strong dep (external humanizers are strong by deliberate choice; still not vendored here).
3. Add route row + description triggers (≤1024).
4. Stage 6 stays “load writer and follow exactly.”

Relationship to other skills

Red flags

• Skipping tech-review-doc §1 in auto mode
• Applying §1 gate to humanizer routes
• Silent degrade when humanizer skills missing
• Declaring analysis-core on this host
• Inlining full writer bodies into this file