Skill: floracat526/floracat-architecture-diagram (version 1.0.0)

--- name: floracat-architecture-diagram description: Create or revise standalone HTML/SVG architecture diagrams, runtime flow diagrams, sequence diagrams, and PPT-like technical visuals. Use when a user wants human-readable publication-ready diagrams instead of Mermaid, or wants help improving node layout, arrow accuracy, spacing, overlap handling, Chinese labels, or overall visual style for architecture and flow charts. --- # Architecture Diagram HTML/SVG Use this skill to produce standalone HTML files with embedded SVG diagrams that feel like clean presentation slides rather than code-first diagrams. ## Output Form - Default to a standalone HTML file with embedded SVG. - Prefer sectioned “deck” structure when there are multiple diagrams on one page. - Use SVG, not Mermaid, for final publication-quality layout control. - Make the result readable without zooming and understandable by non-engineers. ## Visual Style - Use a PPT-like information design style: warm background, panel cards, soft shadows, rounded nodes, restrained colors. - Prefer clear Chinese labels when the audience is Chinese-speaking; keep only essential English technical terms. - Use a small set of semantic colors and keep them consistent across sections. - Keep arrowheads understated; do not make lines or markers visually aggressive. - Favor balanced spacing over dense packing. The page should feel edited, not auto-generated. ## Diagram Building Workflow 1. Identify the user-facing purpose of each diagram. 2. Reduce the system into a few layers or stages before drawing. 3. Choose the simplest SVG structure that fits: - layered architecture - runtime flow - sequence/timing flow - subsystem drill-down 4. Place groups first, then nodes, then arrows, then notes. 5. After layout is stable, localize labels and tighten wording. 6. Do a dedicated arrow and overlap review before finishing. ## Node Rules - Give every node one clear responsibility. - Keep titles short; if a title is long, widen the node before shrinking text. - Use subtitle lines for detail; keep them short and scannable. - Avoid mixing multiple abstraction levels inside one node. - Align sibling nodes rigorously. ## Arrow Rules - Every arrow must start and end on a node edge, not inside a node. - Prefer straight lines first. Add bends only to avoid collisions or ambiguity. - When two arrows connect the same pair of areas, offset them vertically or horizontally. - Use solid lines for primary runtime/data flow. - Use dashed lines only for support, configuration, feedback, optional linkage, or on-demand reads. - If arrows are long, shorten or reroute them so the direction remains obvious. - Do not let text sit on top of an arrow. ## Editing Rules - When refining an existing SVG, inspect coordinates instead of making semantic guesses. - If a user reports overlap, fix geometry directly: move nodes, widen boxes, reroute paths, or adjust text anchors. - If a user questions arrow meaning, verify the actual system relationship in code/docs first, then correct the line. - Prefer explicit labels over decorative complexity. ## Diagram-Specific Guidance ### Overall Architecture - Separate access surfaces, control plane/runtime, capability subsystems, and state/config areas. - Use enclosing groups to show ownership or subsystem boundaries. - Keep cross-group arrows sparse and precise. ### Runtime Flow - Emphasize the main path first. - Put configuration, session state, and plugin/runtime support below the main path as supporting layers. - Use wording that reads like product behavior, not source code names, unless the source name is important. ### Sequence Diagram - Reduce participants to the minimum needed to explain the flow. - Name participants by role, not by file/module, unless implementation detail is the point. - Use loops only where a real repeated interaction exists. - Move loop labels close to the loop arrow. ## Final Review Checklist Before finishing, read [references/review-checklist.md](references/review-checklist.md) and verify every item.

path: agents/openai.yaml
content: interface:
  display_name: "Architecture Diagram HTML/SVG"
  short_description: "Create PPT-like architecture diagrams in standalone HTML/SVG."
  default_prompt: "Use $floracat-architecture-diagram to produce or refine a standalone HTML/SVG architecture diagram with PPT-like styling, precise arrows, and publication-ready readability."


path: references/review-checklist.md
content: # Diagram Review Checklist

Run this review after every substantial diagram edit.

## Semantics

- Confirm each node represents the correct system concept.
- Confirm each arrow direction matches the real relationship.
- Remove arrows that do not express a meaningful dependency or flow.
- Separate primary flow from support/config links.

## Layout

- Check that no text extends beyond node borders.
- Check that sibling nodes align cleanly.
- Check that groups fully contain their child nodes.
- Check that headings and body content have comfortable margins.

## Arrows

- Check that all arrows terminate on node edges.
- Check that no arrow starts inside a node body.
- Check that parallel arrows are offset rather than overlapping.
- Check that long arrows do not create misleading visual ownership.
- Check that dashed arrows are visually lighter than primary solid arrows.

## Readability

- Check that labels are short and human-readable.
- Check that important concepts are in Chinese if the target audience is Chinese-speaking.
- Check that text does not sit on top of lines.
- Check that loops and return paths are still easy to follow.

## Publication Fit

- Check that the diagram looks intentional at page scale, not only when zoomed in.
- Check that the visual style is consistent across sections.
- Check that the result feels like a presentation slide, not a raw engineering sketch.


path: evals/evals.json
content: {
  "skill_name": "floracat-architecture-diagram",
  "evals": [
    {
      "id": 1,
      "slug": "platform-overview",
      "prompt": "为一个内容运营 AI 平台生成一张适合公众号展示的总体架构图，要求输出 standalone HTML + inline SVG，中文标签，人类可读，PPT 风格。",
      "expected_output": "输出一份可直接打开的 HTML 架构图，结构分层清晰，中文可读，适合公众号截图展示。",
      "files": [],
      "output_files": [
        "platform-overview.html"
      ],
      "expectations": [
        "输出目录中生成 platform-overview.html",
        "HTML 中包含 SVG 架构图",
        "图中存在中文标签"
      ]
    },
    {
      "id": 2,
      "slug": "runtime-sequence",
      "prompt": "为一个内容运营 AI 助手生成一张中文时序图，说明需求输入、Prompt 装配、Agent 执行、工具调用、结果回传的完整链路，要求适合公众号展示。",
      "expected_output": "输出一份中文时序图 HTML，主链路完整，环路与回传关系清晰，整体适合公众号展示。",
      "files": [],
      "output_files": [
        "runtime-sequence.html"
      ],
      "expectations": [
        "输出目录中生成 runtime-sequence.html",
        "HTML 中包含 SVG 时序图",
        "图中体现需求输入、Agent 执行、工具调用、结果回传"
      ]
    },
    {
      "id": 3,
      "slug": "agent-patterns-overview",
      "prompt": "为公众号文章生成一张“常见 Agent 设计模式”总览架构图，要求对比 ReAct、Planner-Executor、Router、Multi-Agent 四种模式。输出 standalone HTML + inline SVG，中文标签，PPT 风格，人类一眼能看懂。",
      "expected_output": "输出一份适合公众号展示的 Agent 设计模式总览图，四种模式结构分区明确，对比关系清楚，中文可读。",
      "files": [],
      "output_files": [
        "agent-patterns-overview.html"
      ],
      "expectations": [
        "输出目录中生成 agent-patterns-overview.html",
        "HTML 中包含 SVG 总览图",
        "图中体现 ReAct、Planner-Executor、Router、Multi-Agent 四种模式"
      ]
    },
    {
      "id": 4,
      "slug": "multi-agent-collaboration",
      "prompt": "生成一张多 Agent 协作架构图，描述用户请求如何经过 Router、Planner、多个 Specialist Agent、共享工具层和记忆层，最后回到结果汇总器并输出给用户。要求中文标签，standalone HTML + inline SVG，适合公众号展示。",
      "expected_output": "输出一份多 Agent 协作架构图 HTML，体现路由、规划、专业 Agent 分工、共享工具和记忆、结果汇总的完整关系。",
      "files": [],
      "output_files": [
        "multi-agent-collaboration.html"
      ],
      "expectations": [
        "输出目录中生成 multi-agent-collaboration.html",
        "HTML 中包含 SVG 架构图",
        "图中体现 Router、Planner、Specialist Agent、工具层、记忆层、结果汇总器"
      ]
    }
  ]
}


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)