Skip to main content

architecture-diagram

Generate architecture diagram with component relationship details from project analysis

来源信息

仓库
microsoft/github-copilot-modernization
最近来源活动
2026年7月17日 03:11
检测到的 SKILL.md 语言
英语
星标
49
分支
14

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
architecture-diagram
description
Generate architecture diagram with component relationship details from project analysis
# Architecture Diagram This skill generates a two-layer architecture visualization: a high-level application architecture diagram and a detailed component relationship diagram. Produce both in a single pass and save to `.github/modernize/assessment/engines/facts/architecture-diagram.md`. ## Input Parameters - `workspace-path` (optional): Path to the project to analyze (defaults to current directory) ## ⚠ Mermaid Safety Constraints — read BEFORE you write any ```mermaid block Mermaid is unforgiving: one illegal character anywhere in a block crashes the **whole** diagram with `Syntax error in text`, not just the offending line. There is no partial rendering. Stay strictly inside this subset: 1. **Chart kind.** Only `flowchart TD` (Step 1) or `flowchart LR` (Step 2). Never `graph TD`, never mixed. 2. **Subgraph form.** Always `subgraph <AlphaNumId>["display label"]`. The id must match `[A-Za-z][A-Za-z0-9_]*` (no spaces, no punctuation). NEVER use the anonymous form `subgraph "label"` — it crashes whenever the label contains `(`, `)`, `:`, `/`, `-`, etc., and the parser error appears on an unrelated line. 3. **Node form.** Only one of: `Id["label"]` (rectangle), `Id(("label"))` (circle), `Id[("label")]` (cylinder for data stores). Pick one shape per node — do not stack brackets. 4. **Arrow form.** Solid `-->`, dotted `-.->`. If you put a label on an arrow it MUST be double-quoted: `-->|"label"|`. Never bare `-->|label|`. 5. **No line breaks in labels.** The escape `\n` was removed in modern Mermaid and is the #1 cause of failures. Use `<br/>` in flowcharts when you really must break a line. Strongly prefer single-line ≤ 60-char labels — put detail in the Inventory / Stack tables instead. 6. **Banned characters inside any label or subgraph title.** Use the ASCII replacement: | Banned | Why it breaks | Replacement | |---|---|---| | `\n` (literal two chars) | escape removed | `<br/>` or drop | | `—` (em-dash, U+2014) | parser treats as edge | `-` (ASCII hyphen) | | `–` (en-dash, U+2013) | parser treats as edge | `-` | | `{` `}` (e.g. `{id}`) | opens an entity block | drop braces — write `id` or `:id` | | `"` inside a label | closes the label early | `'` (single quote) | | `\|` inside a label | breaks edge-label parser | rephrase | | `@` `#` `$` `%` `&` | unsafe in many positions | rephrase or drop | | `(` `)` outside a `["..."]` quoted label | unbalanced parens crash | only inside the quoted label | | smart quotes `"` `"` `'` `'` | not ASCII | regular `"` and `'` | 7. **Unique node IDs across the whole file.** If Layer 1 has `DB`, Layer 2 cannot also have `DB`. Use `DB1` and `DB2` (or `AppDb`, `ComponentDb`). 8. **`subgraph` must be closed by a matching `end` on its own line.** No `end`, no diagram. ### Mandatory self-attestation Immediately before writing each ` ```mermaid ` opening fence, emit this exact one-line HTML comment in the markdown (the comment will not render — it is for your own visible attestation that you have re-checked the block): ``` <!-- mermaid-checked: no \n, no em-dash/en-dash, no {} in labels, subgraphs are id["label"], arrows are -->|"label"|, all subgraphs closed by end, ids unique --> ``` If you cannot truthfully emit that comment, fix the diagram first. --- ## Execution Steps ### Step 1: Generate Application Architecture Section Analyze the project and produce the complete `## Application Architecture` section in one pass. **Analysis:** - Examine build files (Java: pom.xml, build.gradle; .NET: *.csproj, *.sln; JS/TS: package.json, tsconfig.json) - Review configuration files (application.properties, appsettings.json, .env, database/API configs) - Scan key source files to extract: framework, major dependencies, data access patterns, external integrations, technology stack - Identify application layers (UI, Business Logic, Data Access), data storage technologies, and external service dependencies **Diagram — Mermaid `flowchart TD`** (re-read the Safety Constraints above before writing): - Application layers with technology info (use `subgraph` for grouping) - Data storage components (specific names like "PostgreSQL", "Redis") - External service integrations - Data flow with descriptive arrow labels **Do NOT include**: individual classes/methods or migration directions. Reference example (this block satisfies every Safety Constraint — match its shape): <!-- mermaid-checked: no \n, no em-dash/en-dash, no {} in labels, subgraphs are id["label"], arrows are -->|"label"|, all subgraphs closed by end, ids unique --> ~~~mermaid flowchart TD subgraph Client["Client Layer"] Browser["Web Browser"] end subgraph App["Application Layer - Spring Boot 2.7"] Web["Spring MVC + Thymeleaf"] Security["Spring Security"] Service["Business Services"] end subgraph Data["Data Layer"] JPA["Spring Data JPA"] DB[("PostgreSQL 14")] Cache[("Redis")] end subgraph External["External Services"] SMTP["SMTP Email Service"] S3["AWS S3 Storage"] end Browser -->|"HTTP requests"| Web Web --> Security -->|"authorized"| Service Service -->|"CRUD operations"| JPA JPA -->|"SQL queries"| DB Service -->|"session cache"| Cache Service -->|"send email"| SMTP Service -->|"file upload"| S3 ~~~ **Textual explanations (write immediately after the diagram):** - **Technology Stack Summary table**: Layer | Technology | Version | Purpose - **Data Storage & External Services**: A short paragraph describing what databases, caches, message brokers, or external APIs are used and how they fit into the architecture - **Key Architectural Decisions**: 1-3 bullet points on notable patterns (e.g., "Uses repository pattern with EF6", "Autofac DI with module-based registration") > ⚠ Move detail OUT of node labels and INTO this table. A diagram with short labels and a rich table renders; a diagram with long labels does not. ### Step 2: Generate Component Relationships Section Analyze component interactions and produce the complete `## Component Relationships` section in one pass. **Analysis:** - Identify key component types by framework conventions: - Java (Spring): Controllers, Services, Repositories, Configurations, Entities, DTOs, Listeners, Filters - Java (Jakarta EE): Servlets, EJBs, CDI Beans, JPA Entities, JAX-RS Resources - .NET (ASP.NET Core): Controllers, Services, Middleware, DbContext, Entities, Hubs, Filters - .NET (Blazor/MVC): Pages, Components, ViewModels - JavaScript/TypeScript (Node.js): Routes, Controllers, Services, Middleware, Models - JavaScript/TypeScript (React/Angular/Vue): Components, Hooks, Services, Stores, Pages - Trace dependency injection (constructor/field injection) - Map communication patterns (REST, gRPC, message queues, events) - Map data access patterns (service-to-repository, DbContext usage) - Detect cross-cutting concerns (middleware, interceptors, filters) **Diagram — Mermaid `flowchart LR`** (re-read the Safety Constraints above before writing): - Components grouped by architectural layer using `subgraph` (Presentation, Business Logic, Data Access, Infrastructure) - Interaction arrows with brief labels - Cross-cutting concerns - **Use IDs that do NOT collide with Step 1's diagram** (e.g., prefix with `c` for Component: `cWeb`, `cService`). **Do NOT include**: method signatures, private helpers, or external dependencies (covered by dependency-map skill). Reference example (satisfies every Safety Constraint): <!-- mermaid-checked: no \n, no em-dash/en-dash, no {} in labels, subgraphs are id["label"], arrows are -->|"label"|, all subgraphs closed by end, ids unique --> ~~~mermaid flowchart LR subgraph PresentationLayer["Presentation"] UserCtrl["UserController"] OrderCtrl["OrderController"] end subgraph BusinessLayer["Business Logic"] UserSvc["UserService"] OrderSvc["OrderService"] NotifSvc["NotificationService"] end subgraph DataAccessLayer["Data Access"] UserRepo["UserRepository"] OrderRepo["OrderRepository"] end subgraph InfraLayer["Infrastructure"] AuthFilter["AuthenticationFilter"] LogMiddleware["LoggingMiddleware"] end UserCtrl -->|"delegates"| UserSvc OrderCtrl -->|"delegates"| OrderSvc OrderSvc -->|"lookups"| UserSvc OrderSvc -->|"triggers"| NotifSvc UserSvc -->|"queries"| UserRepo OrderSvc -->|"queries"| OrderRepo AuthFilter -.->|"intercepts"| UserCtrl AuthFilter -.->|"intercepts"| OrderCtrl LogMiddleware -.->|"wraps"| PresentationLayer ~~~ **Textual explanation (write immediately after the diagram):** - **Component Inventory table**: Component | Layer | Type | Responsibility ### Step 3: Save Output Save the combined output to `.github/modernize/assessment/engines/facts/architecture-diagram.md` with this exact structure: ``` # Architecture Diagram A brief introduction (1-2 sentences). ## Application Architecture < Layer 1 Mermaid flowchart TD here > ### Technology Stack Summary [Table: Layer | Technology | Version | Purpose] ### Data Storage & External Services [Short paragraph on databases, caches, external APIs] ### Key Architectural Decisions [1-3 bullet points on notable patterns] ## Component Relationships < Layer 2 Mermaid flowchart LR here > ### Component Inventory [Table: Component | Layer | Type | Responsibility] ``` ## Scaling Rules - If the project has **more than 30 components**, aggregate by package/namespace (e.g., show `com.example.orders` as one node instead of listing every class) — this also keeps labels short and safe. - Keep each diagram under **40 nodes** to ensure readability and GitHub rendering compatibility. - For multi-module projects, focus on inter-module boundaries in Layer 1 and key components within the most important modules in Layer 2. ## Common failure patterns observed in past runs Each row below is something the model actually produced and crashed the diagram. Use the ✅ form. | ❌ Past mistake | ✅ Safe form | Why the ❌ crashed | |---|---|---| | `subgraph "Spring Boot Application (port 8080)"` | `subgraph SpringApp["Spring Boot Application (port 8080)"]` | Anonymous subgraph + parentheses in title | | `HC["HomeController\n GET / — gallery page"]` | `HC["HomeController GET /"]` (move detail to table) | Literal `\n` + em-dash | | `PHOTOS_TABLE["PHOTOS table\n id (UUID PK)\n photo_data (BLOB)"]` | `PHOTOS_TABLE["PHOTOS"]` (columns belong in a table) | `\n` and overlong label | | `PFC["PhotoFileController\n GET /photo/{id}"]` | `PFC["PhotoFileController GET /photo/:id"]` | `\n` + `{id}` | | `Spring["Spring Boot\n2.7.18"]` | `Spring["Spring Boot 2.7.18"]` | `\n` | | `A -->|fetches users| B` | `A -->|"fetches users"| B` | Bare (unquoted) arrow label | ## Error Handling - **Unsupported project type**: Output a single line: `> ERROR: Unsupported project type. This skill supports Java, .NET, JavaScript, and TypeScript projects only.` - **No source code found**: Output: `> ERROR: No recognized source files found at workspace-path. Verify the path is correct.` - **Insufficient info**: Generate a best-effort diagram from available data. Add a note inside the diagram: `Note["Some components could not be identified"]` ## Success Criteria - Layer 1 Mermaid diagram renders correctly showing architecture with technology names, data storage, and external dependencies - Layer 1 is accompanied by Technology Stack Summary table, Data Storage & External Services paragraph, and Key Architectural Decisions - Layer 2 Mermaid diagram renders correctly showing component interactions grouped by architectural layer - Layer 2 is accompanied by Component Inventory table - Every ```mermaid block is preceded by the `<!-- mermaid-checked: ... -->` attestation comment - File saved to `.github/modernize/assessment/engines/facts/architecture-diagram.md`
在 GitHub 查看