メニュー
Use when an architect in overview technical design must produce or review the 系统功能架构图 and needs the fully merged functional-architecture specialist method directly inside the new lifecycle family.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when architecture work hinges on DDD-style domain modeling: subdomains, bounded contexts, context relationships, aggregate boundaries, and how those decisions shape overview or detailed design artifacts.
Use when architecture or backend work needs pre-code structural guidance from design patterns, or post-code cleanup guidance from refactoring and code-smell-driven improvement.
Structured methodology for comparing technology options (frameworks, platforms, tools) and documenting adoption decisions with evidence-based reasoning.
Use when an architect in the deploy-and-ops stage must produce or review the 部署架构图 / 物理架构图 so that physical topology, deployment boundaries, and run-stage assumptions are visible during handoff.
Use when an architect in the solution-design stage must produce or review the 业务解决方案架构图 and needs the fully merged specialist method directly inside the new lifecycle family instead of via a legacy wrapper skill.
Use when an architect in the solution-design stage must produce or review a 业务流程图 that explains roles, steps, and handoff order without collapsing into system architecture, technical architecture, or detailed-design flow logic.
| name | arch-lifecycle-tech-overview-functional-arch-diagramming |
| description | Use when an architect in overview technical design must produce or review the 系统功能架构图 and needs the fully merged functional-architecture specialist method directly inside the new lifecycle family. |
| version | 1.1.0 |
| author | Architect Skill Pack |
| license | MIT |
| metadata | {"hermes":{"tags":["architect","lifecycle","technical-design","overview-design","functional-architecture"],"related_skills":["arch-lifecycle-tech-overview-methodology","arch-lifecycle-tech-overview-system-arch-diagramming"]}} |
This skill now directly contains the merged specialist doctrine that previously lived in the legacy system-functional-architecture skill.
This is the local architect-role skill for drawing and reviewing 系统功能架构图 in the 概要设计 stage.
It strengthens a generic diagramming meta-spec with the architecture-lifecycle requirement that a functional architecture diagram must answer, at minimum:
Core principle: 系统功能架构图 belongs to overview design, so it should explain capability structure and layering, not code structure, deployment topology, or runtime sequence detail.
This skill exists because many so-called “功能架构图” fail in one of two ways:
Use this skill to produce a diagram that is abstract enough for 概要设计, but concrete enough to guide later system architecture, technical architecture, and detailed design.
Canonical full-fidelity drawing spec:
references/universal-diagramming-spec-full.mdImportant preservation rule:
Use when:
Do not use when:
ddd-domain-modeling-for-architectureAt 概要设计 stage, the functional architecture diagram is the direct answer to two design questions from the lifecycle document:
Therefore, every qualified diagram must let a reviewer infer within ~30 seconds:
If the diagram cannot answer those five points quickly, it is not finished.
Keep the functional architecture diagram separate from nearby artifacts.
Important review rule: If the current “功能架构图” mainly shows time order, request sequence, or retry branches, it is actually a flow artifact, not a functional architecture artifact.
Before drawing, classify all candidate content into four buckets:
Core functional closed loop
Domain/feature capabilities
Support/governance capabilities
External or data-adjacent support
This classification prevents two failure modes:
Adopt the universal grammar, but interpret it specifically for overview-stage functional architecture.
Containers express functional layers or functional groups, not random visual grouping.
Allowed first-level container examples:
Allowed second-level container examples:
Do not exceed 2 container levels.
Nodes represent one of:
At this stage, nodes should usually be named as:
Good examples:
Bad examples:
module-aRuleEngineImpldoCheck()Edges show only relationships that matter to functional understanding:
Do not draw every conceivable relationship.
Default rule:
For overview-stage 系统功能架构图, the default layout is:
Because the dominant question is almost always:
A strong default stack is:
You do not always need all five. Collapse or rename layers to match the system, but preserve clear semantic separation.
Use a different layout only when the dominant question changes:
Review warning: If you chose non-layered layout for a normal overview functional diagram, be able to justify why layered view was insufficient.
Before drawing, write one sentence:
Then derive the diagram from that statement.
If no goal statement exists, the diagram will devolve into a feature list.
List the major functions the system must own.
Then classify each into:
Do not draw low-level technical pieces yet.
Choose one dominant layering logic and keep it pure.
Preferred axes:
Do not mix different abstraction axes in the same sibling layer.
Bad layering example:
That mixes interaction, function, data tech, governance, and deployment.
Place the central chain so the viewer can identify it immediately.
Typical methods:
A good functional architecture diagram should reveal:
At overview stage, the lifecycle document explicitly expects design principles, complexity awareness, and later risk/constraint thinking.
So if support/governance functions materially affect the system shape, include them as functional blocks such as:
But do not let them dominate the topology unless governance is itself the system’s primary mission.
Ask of each edge:
If no, omit it.
Recommended edge policy:
Final check:
If the picture contains too much of the following, it likely drifted:
Use this as a starting template, not a rigid doctrine.
Purpose:
Typical nodes:
Purpose:
Typical nodes:
Purpose:
Typical nodes:
This is usually the center of the diagram.
Purpose:
Typical nodes:
Purpose:
Typical nodes:
Important: At functional architecture stage, these nodes represent functional responsibilities, not specific storage engines or transport products.
Choose names that are:
Prefer:
Avoid:
Inside the same container, nodes must live at the same abstraction level.
Bad same-layer mix:
Good same-layer mix:
Container titles must be classification dimensions, not leftovers.
Good:
Bad:
Because the lifecycle document pushes architects to analyze complexity and risks early, a stronger functional architecture diagram should reveal where the main pressure points live.
Without turning the picture into a technical design, you may annotate or visually hint:
Use subtle cues:
Do not turn the functional diagram into a risk matrix. Just expose the places where later architecture decisions will concentrate.
When the system is a product built on top of an existing agent runtime, the 系统功能架构图 should show not only product-facing functions but also the inherited platform-capability groups that materially shape the product's real ceiling.
Preferred handling:
Reason:
Important boundary:
When the functional architecture diagram is part of a markdown/vault-based overview-design document set:
.html link only.svg and let the overview doc inline the .svg, with the .html kept as an optional richer artifactfill colors to visible <text> elements so dark-theme renderers do not degrade into unreadable black textWhen the user asks to continue/optimize the 概要设计方案 rather than just “draw one diagram”, the stronger default is:
A functional diagram delivered alone in that situation is usually incomplete, because overview design is being reviewed as a package rather than as an isolated figure.
At overview functional level, node names may still be product-facing, but they should remain capability-oriented rather than page-title-oriented. Prefer:
身份与空间入口员工定义与配置团队模板与行业方案多智能体协作编排审计与经营分析Prefer not to anchor the diagram in one UI surface name when the capability is broader than that UI.
When reviewing an existing 系统功能架构图, check these gates.
Can a reviewer infer the system construction goal from the title, layering, and core chain?
If no, the diagram is likely only enumerating functions.
Does each layer represent one abstraction axis?
If no, the diagram is mixing functional, technical, and deployment concerns.
Can a reviewer point to the system’s primary functional closed loop within 10 seconds?
If no, support functions are probably overpowering the core.
Are there concrete technologies, hosts, middleware brands, runtime carriers, code packages, or schema details in the main nodes?
If yes, the diagram has drifted downward into technical architecture.
Do arrows only show important collaboration/dependency?
If no, reduce edges until the main capability logic becomes legible.
If external systems materially shape the functional boundary, are they shown clearly as external/supporting rather than pretending to be internal core functions?
If audit, permissions, rules, monitoring, operations, or compliance materially affect the solution, are they visible enough to guide later design rather than being forgotten entirely?
When generating a diagram spec, use this compact scaffold before tool-specific syntax. Then apply the full visual/tooling rules from references/universal-diagramming-spec-full.md without compressing them:
Before producing a real diagram spec, review:
references/universal-diagramming-spec-full.mdreferences/layering-templates.mdUsage split:
universal-diagramming-spec-full.md = canonical full publication-grade drawing standard, preserved without compressionlayering-templates.md = reusable architect templates for common functional-layer shapesSKILL.md = overview-design positioning, artifact boundary control, and architect review methodDo not let the presence of templates or overview-design guidance silently erase the original visual grammar, spacing rules, naming rules, layout library, tool mapping, or checklist detail preserved in the full reference.
Tool-specific drawing details are governed by the canonical full reference:
references/universal-diagramming-spec-full.mdThis umbrella skill adds architect-usage routing on top of that reference: