AncientM00N/Skills_for_NLP_huliang6

Multi-Agent Web Workflow

Purpose

Use this skill to run a sequential multi-agent workflow for web generation tasks. Treat each stage as a distinct role with a narrow responsibility, a clear handoff artifact, and explicit acceptance criteria.

This skill is intentionally tool-light. It does not require special scripts; it provides an operating method for agent identity, stage contracts, review, and repair.

Workflow

Use this default sequence for substantial web tasks:

Planner -> Architect -> Developer -> Reviewer -> AutoFixer(optional) -> Reviewer(optional) -> Final

Skip stages only when the task is small enough that the user clearly wants a direct answer.

Planner

Classify the request before acting:

• chat: Explain, discuss, compare, or answer without editing.
• inspect: Read or analyze existing files, previews, or project state.
• code: Create, edit, fix, or build a web page or frontend project.

Prefer chat for ambiguous conversation. Enter code only when the user asks for implementation, visible UI changes, bug fixes, or generation.

Architect

Use the Architect stage before implementation when the task has more than one UI element, interaction, page section, or quality constraint.

Produce a compact plan:

{
  "type": "architect_plan",
  "goal": "What the page or change must achieve",
  "page_structure": ["Main visible sections or components"],
  "visual_direction": "Style direction tied to the domain",
  "interaction_notes": ["Expected user interactions"],
  "files": [
    {"path": "index.html", "purpose": "Entry page", "required": true}
  ],
  "acceptance_criteria": ["Observable checks for success"],
  "risks": ["Likely implementation or UX risks"]
}

Do not write files in this stage. Do not hide vague requirements; either define a conservative assumption or ask one focused question.

Developer

Implement the Architect plan. Keep changes scoped to the requested page or component.

Follow this order:

1. Read relevant existing files before editing.
2. Create or edit files using the smallest practical change.
3. Build or preview when the environment supports it.
4. Summarize what changed and what was verified.

End the stage with:

{
  "type": "implementation_summary",
  "changed_files": ["relative/path"],
  "created_files": [],
  "deleted_files": [],
  "checks": [
    {"name": "build_or_preview", "passed": true, "note": "Result"}
  ],
  "summary": "Concise implementation result"
}

Reviewer

Review as a separate role. Do not rewrite the implementation during review.

Check:

• User request coverage.
• Architect acceptance criteria.
• UI clarity, responsive layout, and interaction completeness.
• Obvious broken states, missing assets, runtime errors, or build failures.
• Whether the implementation overreaches or changes unrelated files.

Output one structured report:

{
  "type": "review_report",
  "passed": true,
  "severity": "pass",
  "summary": "Review result",
  "issues": [
    {
      "id": "R1",
      "severity": "minor|major|blocker",
      "area": "ux|functionality|build|scope|content",
      "file": "relative/path",
      "message": "Specific issue",
      "suggested_fix": "Actionable repair"
    }
  ],
  "acceptance_checklist": [
    {"item": "Criterion", "passed": true, "note": "Evidence"}
  ]
}

Use blocker for build failure, unusable core interaction, missing primary output, or unsafe behavior. Use major for missing required functionality. Use minor for polish issues.

AutoFixer

Use AutoFixer only when Reviewer reports issues.

Rules:

• Fix only listed review issues.
• Prefer local patches over broad rewrites.
• Preserve the original design unless the issue requires a design adjustment.
• Verify again after fixing when possible.
• Return to Reviewer after the fix.

End with:

{
  "type": "fix_summary",
  "fixed_issue_ids": ["R1"],
  "changed_files": ["relative/path"],
  "checks": [
    {"name": "build_or_preview", "passed": true, "note": "Result"}
  ],
  "summary": "What was fixed"
}

Final Response

Give the user only the high-signal outcome:

• What was built or changed.
• What passed review.
• Remaining risks or skipped checks.
• Where to view or inspect the result, if available.

Do not expose internal chain-of-thought. Do mention stage outputs or review findings when they materially help the user trust the result.