@dtt_siye/atool 1.3.1 → 1.5.0

package/skills/software-architecture/SKILL.md

@@ -22,8 +22,6 @@ Use this skill when asked to design, evolve, review, or scaffold backend/system
 
 Do not trigger for isolated code formatting or minor bug fixes unless they affect architecture or non-functional requirements.
 
----
-
 ## Core Philosophy
 
 Three principles drive every architecture decision:
@@ -36,8 +34,6 @@ Three principles drive every architecture decision:
 
 Prefer: **suitable over trendy**, **simple over grand but fragile**, **evolvable over one-step finality**.
 
----
-
 ## Non-Negotiable Principles
 
 1. **Suitability first** — choose what the team can realistically build, operate, and debug.
@@ -47,381 +43,24 @@ Prefer: **suitable over trendy**, **simple over grand but fragile**, **evolvable
 5. **Clear boundaries** — every service/module/repo/DB boundary must correspond to a real business capability, not arbitrary technical slicing.
 6. **Operational reality** — architecture is incomplete without deployment, observability, rollback, security, and change management.
 
----
-
-## Architecture Decision Workflow
-
-### Step 1: Frame the Problem
-State: business goal, users/traffic/environments, latency/availability/scalability/security expectations, team capability, delivery timeline, major constraints (existing stack, compliance, integration dependencies).
-
-### Step 2: Identify the Dominant Technical Problem
-Classify the main driver: high concurrency / high availability / performance bottleneck / delivery speed / integration complexity / data consistency / cost or ops burden.
-
-### Step 3: Choose the Minimum Viable Architecture Style
-
-Use this progression — explain why simpler options are not enough before recommending a more complex one:
-
-| Style | Choose when |
-|-------|------------|
-| **Monolith** | Small scope, small team, fast delivery, domain still changing |
-| **Distributed modular** | Modules need independent scaling/deployment, multiple channels sharing backend |
-| **SOA** | Enterprise-level shared service layer, heterogeneous protocols already in use |
-| **Microservices** | Clear business capability splits, teams own services independently, full ops/tooling ready |
-| **Serverless** | Event-driven, bursty traffic, minimal infra management desired |
-
-### Step 4: Define Architecture Building Blocks
-Define only what is necessary: client/frontend, gateway/access layer, application/service layer, domain/business layer, persistence/data layer, cache, MQ, config center, service registry, auth/identity, observability, deployment/CI-CD, rollback/resilience.
-
-### Step 5: Map NFRs to Concrete Design
-| NFR | Concrete mechanisms |
-|-----|-------------------|
-| High concurrency | Statelessness, horizontal scaling, cache, queue, async, read-write split |
-| High availability | Degrade, rate limit, rollback, gray release, redundancy |
-| Performance | Static resources, request merge, caching, async IO |
-| Maintainability | Clear service boundaries, API contracts, documentation, automated tests |
-| Security | Authn/authz, validation, audit, masking, secure defaults |
-
-### Step 6: Produce Deliverables
-Architecture summary, component view, deployment view, service decomposition, data flow, interface contract outline, risk list with mitigations, phased evolution roadmap, implementation checklist.
-
----
-
-## Architecture Style Rules
-
-### Monolith
-- Keep clear layered/module boundaries inside — do not let it become "big ball of mud"
-- Isolate domain modules even within one repo
-- Prepare extraction seams around high-change or high-load modules
-- **Do not recommend microservices if the only reason is "future scalability" without present evidence**
-
-### Distributed Modular System
-- Define interface boundaries early
-- Keep shared business logic in versioned service layers or libraries
-- Make remote communication explicit and observable
-
-### Microservices
-Choose only when **all** are mostly true: clean business capability splits, teams own services independently, full tooling ready (CI/CD, tracing, monitoring, config, registry, gateway).
-
-Rules:
-- Each service = one clear business capability
-- Services must be independently deployable
-- Do not share databases across services unless transitional and justified
-- Document consistency strategy when data spans services
-- Ensure automated contract and integration testing
-
-**Warning signs:** too-tiny services without strong boundaries, no tracing/gateway/config center/rollback plan, distributed transactions added casually, services split by technical layer instead of business capability.
-
-### Serverless
-- Address function granularity — too fine creates orchestration overhead
-- Handle observability and integration testing explicitly
-
----
-
-## Clean Architecture & DDD Principles
-
-- Follow **Domain-Driven Design** and ubiquitous language
-- Separate domain entities from infrastructure concerns
-- Keep business logic independent of frameworks
-- Define use cases clearly and keep them isolated
-- Use **domain-specific names**: `OrderCalculator`, `UserAuthenticator` — avoid generic names like `utils`, `helpers`, `common`, `shared`
-- Separate concerns: no business logic in UI components, no DB queries in controllers
-
----
-
-## High-Concurrency Design
-
-When concurrency is a key requirement, apply these levers in order:
-
-1. **Statelessness** — prefer stateless services; use token-based context; avoid sticky sessions
-2. **Splitting** — by business domain, read/write characteristics, or function/sub-capability
-3. **Service governance** — discovery, routing, timeout, retry, rate limiting, fallback
-4. **Caching by layer** — client cache → CDN/edge → gateway/access → application → data layer. Define cacheable objects, TTL, invalidation strategy; call out consistency risks
-5. **Message queue and async** — use MQ only for: decoupling, async non-blocking work, traffic buffering/peak shaving, eventual consistency. Define retry/dead-letter/compensation
-6. **Reduce request count** — staticization, request merge/aggregation, rate limiting, load shaping
-7. **Speed up the path** — parallelize independent steps, async notifications, read replicas, delayed writes for non-real-time ops
-8. **Resource scaling** — horizontal scaling preferred; vertical scaling acceptable as fastest short-term fix
-
----
-
-## High-Availability Design
-
-### Degradation
-- Centralized degrade switches
-- Fallback to local cache / stale data / read-only mode where acceptable
-- Front-loaded degrade at gateway or Nginx
-- Business-priority downgrade: keep core flow, defer/disable non-core features
-
-### Rate Limiting and Protection
-- Controls for malicious traffic, abnormal IPs, gateway-level throttling
-
-### Rollback
-Every architecture proposal must include: rollback path, stable previous version reference, gray release strategy if relevant.
-
-### Monitoring and Alerts
-At minimum: metrics, logs, traces, alert thresholds, **business error monitoring** (not just system error monitoring).
-
----
-
-## Business Design Rules
-
-Always consider for order, payment, submission, workflow, approval, job triggering, messaging, and callback scenarios:
-
-- **Duplicate-prevention design**
-- **Idempotency** — explicit design for any operation that may be retried
-- **State machines** — for workflows with distinct states and transitions
-- **Operation feedback** in admin/backoffice systems
-- **Approval flow** for high-risk or business-controlled changes
-- **Backup / recovery** thinking
-
----
-
-## Cloud-Native Platform Baseline
-
-Only include components the scenario justifies — do not recommend the full stack for a small internal system:
-
-WAF / CDN / ingress / LB → API gateway → service registry/discovery → config center → auth / OAuth2 → service-to-service client or RPC → cache layer → relational DB (with replicas/shards if needed) → MQ → object storage → search engine (if needed) → metrics + tracing + logs → alerting → container registry → CI/CD → Kubernetes or equivalent.
-
----
-
-## Output Format
-
-### 概述
-
-架构设计产出 6 个交付物（A-F）+ ADR 模板。每个交付物有明确的模板结构和必填字段。
-
-如果文档写入 `docs/400-architecture/`，需遵循 `doc-standards-enforcer` 的 frontmatter 规范。
-
----
-
-### A. Architecture Summary（架构摘要）
-
-```markdown
-# {Project Name} Architecture Summary
-
-## 1. Business Context
-- 业务目标（1-2 句）
-- 目标用户和规模（用户数/并发量/数据量）
-- 核心业务流程（Mermaid flowchart）
-
-## 2. Dominant Technical Drivers
-| 驱动因素 | 优先级 | 当前状态 | 目标状态 |
-|---------|--------|---------|---------|
-| 高并发 | P0 | 100 QPS | 10K QPS |
-| 高可用 | P0 | 99% | 99.9% |
-| 安全 | P1 | 基础认证 | OAuth2 + RBAC |
-
-## 3. Architecture Style Decision
-- 推荐风格：{Monolith / Distributed / Microservices / Serverless}
-- 选择理由（为什么更简单的方案不够用）
-- 对比表：
-  | 方案 | 优势 | 劣势 | 适用条件 | 选择 |
-  |------|------|------|---------|------|
-
-## 4. Architecture Overview Diagram
-（Mermaid graph TB，展示所有核心组件和交互关系）
-```
-
-### B. Component Design（组件设计）
-
-```markdown
-# Component Design
-
-## 组件清单
-| 组件 | 职责 | 技术选型 | 部署方式 | 依赖组件 | SLA |
-|------|------|---------|---------|---------|-----|
-| API Gateway | 路由+限流+认证 | Kong/Nginx | K8s Pod | Auth Service | 99.9% |
-| User Service | 用户生命周期 | Spring Boot | K8s Pod | DB, Cache | 99.9% |
-
-## 分层架构
-| 层 | 职责 | 包含组件 | 通信协议 |
-|---|------|---------|---------|
-| 接入层 | 路由、认证、限流 | Gateway, LB | HTTPS |
-| 应用层 | 业务编排 | Services | gRPC/REST |
-| 领域层 | 核心业务逻辑 | Domain Models | In-process |
-| 数据层 | 持久化 | DB, Cache, MQ | TCP |
-
-## 每个核心组件详细设计
-对每个组件：
-- 职责边界（做什么 / 不做什么）
-- 接口定义（暴露的 API 摘要）
-- 数据归属（拥有哪些实体）
-- 扩展策略（水平/垂直，触发条件）
-- 容错机制（降级/熔断/重试策略）
-```
-
-### C. Data and Interaction Design（数据与交互设计）
-
-```markdown
-# Data and Interaction Design
-
-## 1. 数据归属矩阵
-| 数据实体 | 归属服务 | 读取方 | 写入方 | 一致性要求 |
-|---------|---------|--------|--------|-----------|
-| User | User Service | Order, Payment | User Service | 强一致 |
-| Order | Order Service | Payment, Report | Order Service | 最终一致 |
-
-## 2. 同步/异步通信边界
-| 源 | 目标 | 方式 | 协议 | 超时 | 重试 | 降级策略 |
-|---|------|------|------|------|------|---------|
-| Gateway → UserSvc | 同步 | REST | 3s | 2次 | 返回缓存 |
-| OrderSvc → PaymentSvc | 异步 | MQ(RabbitMQ) | - | 3次+DLQ | 人工补偿 |
-
-## 3. API 契约摘要
-| API | Method | Path | 请求方 | 提供方 | 关键参数 |
-|-----|--------|------|--------|--------|---------|
-
-## 4. 缓存策略
-| 缓存对象 | 缓存层 | TTL | 失效策略 | 一致性风险 |
-|---------|--------|-----|---------|-----------|
+## Quick Workflow
 
-## 5. 数据一致性方案
-对跨服务的数据操作：
-| 场景 | 涉及服务 | 一致性策略 | 补偿机制 |
-|------|---------|-----------|---------|
-| 下单支付 | Order+Payment | Saga | 退款补偿 |
-```
+1. **Frame the problem** — Identify business goals, constraints, and technical drivers
+2. **Choose architecture style** — Select between monolith, distributed, microservices, or serverless
+3. **Design core building blocks** — Define essential components and their interactions
+4. **Map NFRs to mechanisms** — Translate non-functional requirements into concrete design choices
+5. **Design for scale** — Apply concurrency, availability, and deployment patterns
+6. **Validate and document** — Review checklist and produce architecture deliverables
 
-### D. Deployment and Operations（部署与运维）
+## File Reference Map
 
-```markdown
-# Deployment and Operations
-
-## 1. 部署拓扑
-（Mermaid graph，展示环境布局）
-
-## 2. 环境配置矩阵
-| 环境 | 用途 | 实例数 | 数据库 | 缓存 | 配置来源 |
-|------|------|--------|--------|------|---------|
-| dev | 开发 | 1 | SQLite/H2 | 本地 | .env |
-| staging | 预发布 | 2 | MySQL | Redis | ConfigCenter |
-| production | 生产 | 3+ | MySQL(主从) | Redis(集群) | ConfigCenter |
-
-## 3. CI/CD 流程
-（Mermaid flowchart：代码提交 → 构建 → 测试 → 镜像 → 部署 → 健康检查）
-
-## 4. 可观测性
-| 维度 | 工具 | 关键指标 | 告警阈值 |
-|------|------|---------|---------|
-| Metrics | Prometheus | API 延迟 P99 | > 500ms |
-| Logging | ELK/Loki | 错误率 | > 1% |
-| Tracing | Jaeger | 链路完整性 | 采样率 > 10% |
-
-## 5. 回滚策略
-| 场景 | 回滚方式 | RTO | 数据处理 |
-|------|---------|-----|---------|
-| 代码缺陷 | 回退到上一版本 | < 5min | 无需处理 |
-| 数据迁移失败 | 执行回滚脚本 | < 30min | 备份恢复 |
-
-## 6. 扩缩容规则
-| 服务 | 指标 | 扩容阈值 | 缩容阈值 | 最大/最小实例 |
-|------|------|---------|---------|-------------|
-```
-
-### E. Risk and Trade-offs（风险与权衡）
-
-```markdown
-# Risk and Trade-offs
-
-## 风险登记册
-| ID | 风险描述 | 概率 | 影响 | 缓解措施 | 负责人 | 状态 |
-|----|---------|------|------|---------|--------|------|
-| R001 | 第三方支付接口不稳定 | 高 | 高 | 多通道+降级 | Arch | Open |
-
-## 架构权衡
-| 决策 | 获得 | 付出 | 接受理由 |
-|------|------|------|---------|
-| 引入 MQ 异步 | 解耦+削峰 | 运维复杂度+最终一致 | 峰值流量 10x |
-```
-
-### F. Evolution Roadmap（演进路线图）
-
-```markdown
-# Evolution Roadmap
-
-| 阶段 | 时间范围 | 目标 | 关键动作 | 验证标准 |
-|------|---------|------|---------|---------|
-| Phase 1 | 1-2周 | 快速修复 | 解耦循环依赖、统一日志 | 循环依赖 = 0 |
-| Phase 2 | 2-4周 | 中期重构 | 抽取共享服务、引入缓存 | P99 < 200ms |
-| Phase 3 | 1-3月 | 架构升级 | 服务拆分、K8s 部署 | 可独立部署 |
-
-每个 Phase 包含：
-- 目标（解决什么问题）
-- 涉及模块/服务
-- 风险评估
-- 回退方案
-- 验证标准（可度量）
-```
-
----
-
-### G. ADR Template（架构决策记录 — 新增）
-
-每个重要架构决策生成一份 ADR：
-
-```markdown
-# ADR-{SEQ}: {Decision Title}
-
-## Status
-Proposed | Accepted | Deprecated | Superseded by ADR-{N}
-
-## Context
-- 背景：什么业务/技术问题触发了这个决策？
-- 约束：有什么限制（团队能力/时间/预算/合规）？
-- 当前状态：现在是怎么做的？为什么不够用？
-
-## Decision
-我们决定 {具体决策}。
-
-## Options Considered
-| 选项 | 优势 | 劣势 | 评估 |
-|------|------|------|------|
-| 选项 A（选中）| ... | ... | ✅ 最佳 |
-| 选项 B | ... | ... | ❌ 不满足 NFR |
-| 选项 C | ... | ... | ❌ 团队不熟悉 |
-
-## Consequences
-### 正面
-- ...
-
-### 负面
-- ...
-
-### 风险
-- ...
-
-## NFR Impact
-| NFR | 影响 | 缓解措施 |
-|-----|------|---------|
-| NFR-SYS-001 性能 | P99 可能增加 50ms | 引入缓存层 |
-
-## Related
-- 相关 ADR：ADR-{N}
-- 相关 PRD：PRD-{MOD}-{SEQ}（来自 requirements-writer）
-- 相关模块：{module list}
-```
-
----
-
-### NFR 统一编号体系
-
-与 requirements-writer 的 NFR 编号对齐：
-
-```
-NFR-{SCOPE}-{SEQ}
-
-SCOPE 可选值：
-  SYS   — 系统级（跨所有模块）
-  {MOD} — 模块级（如 USER, ORDER）
-
-示例：
-  NFR-SYS-001: 系统整体 API P99 延迟 < 500ms
-  NFR-SYS-002: 系统可用性 > 99.9%
-  NFR-USER-001: 用户注册 API 响应 < 200ms
-```
-
-architecture 中定义的系统级 NFR（NFR-SYS-*）是 requirements-writer 模块级 NFR（NFR-{MOD}-*）的上游约束。模块级 NFR 不得超过系统级 NFR 的范围。
-
----
+| File | When to Read | Content |
+|------|-------------|---------|
+| `rules/decision-workflow.md` | Starting architecture design | Six-step decision process, ADR template, deliverables checklist |
+| `rules/styles.md` | Choosing architecture style | Monolith vs microservices vs serverless selection criteria, evolution paths |
+| `rules/concurrency-ha.md` | Designing for performance | High concurrency patterns, high availability strategies, monitoring setup |
+| `rules/ddd.md` | Implementing clean architecture | DDD principles, clean architecture layers, domain modeling patterns |
+| `rules/deployment.md` | Planning deployment | CI/CD pipelines, container orchestration, monitoring, disaster recovery |
 
 ## Integration with Tech-Stack Skills
 
@@ -446,134 +85,33 @@ This skill orchestrates architecture; stack-specific skills govern implementatio
 
 | Workflow | When to Use | How |
 |----------|-------------|-----|
-| **project-analyze** | Analyzing an existing project's architecture | Run `/project-analyze` (v5.1 五维分析框架) first to generate knowledge graph and module inventory, then use that data to inform architecture review |
-| **code-review** | Architecture compliance validation | code-review Dimension 5 validates architecture compliance; for major violations, follow up with this skill for deeper review |
-| **doc-standards-enforcer** | Producing architecture documentation (ADRs, HLD/LLD) | After producing architecture deliverables, validate documentation format with `doc-standards-enforcer` |
-| **doc-coauthoring** | Co-authoring technical specs or design documents | Use `doc-coauthoring` workflow for collaborative document creation; this skill provides technical content accuracy |
-| **project-query** | 需要查询架构分析详细数据（层违反、耦合度等） | 建议运行 |
-
-### Architecture Review Workflow
-
-For existing projects requiring architecture assessment:
-
-1. Run `/project-analyze` (v5.1 五维分析框架) to generate knowledge graph
-2. Review the generated architecture diagrams and module dependency graph
-3. Use this skill's Review Checklist against the analysis results
-4. Produce ADR or architecture improvement plan
-5. Validate output with `doc-standards-enforcer`
-
-### project-analyze 数据契约（Refine Mode 输入）
-
-以下文件是 Refine Mode 的输入数据源，project-analyze 必须确保这些文件在 Phase 2.5 调用前存在：
-
-| 文件 | 内容 | 生成阶段 |
-|------|------|---------|
-| `.atool-docs/knowledge-graph.json` | 耦合度量、依赖图 | Phase 3 |
-| `.atool-docs/multi-dimensional-analysis.json` | 五维分析数据 | Phase 3 |
-| `.atool-docs/modules/*/data.json` | 模块级结构化数据 | Phase 2 |
-| `atool-analysis/modules/*/prd.md` | 精炼后的模块 PRD（含 NFR-{MOD}-NNN） | Phase 2.5 |
-| `atool-analysis/modules/*/dev-guide.md` | 精炼后的架构文档（含 ADR） | Phase 2.5 |
-
----
-
-## Refine Mode（精炼模式 — 由 project-analyze Phase 2.5 调用）
-
-### 触发条件
-
-Phase 2.5 通过 sub-agent prompt 内联激活，不由用户手动触发。在 requirements-writer Refine Mode 完成后自动进入。
-
-### 输入
-
-| 文件 | 用途 |
-|------|------|
-| `atool-analysis/modules/{name}/README.md` | 模块业务概述 |
-| `atool-analysis/modules/{name}/prd.md` | 精炼后的标准 PRD（8 节，含 NFR-{MOD}-NNN） |
-| `atool-analysis/modules/{name}/api.md` | 接口定义 → API 契约设计 |
-| `atool-analysis/modules/{name}/data-model.md` | 数据模型 → 数据所有权 |
-| `atool-analysis/modules/{name}/dev-guide.md` | Phase 2 初稿 → 追加架构章节 |
-| `.atool-docs/modules/{name}/data.json` | 结构化数据（含 refine_hints） |
-| `{stack}-conventions` Architecture + API Design 节 | 栈级架构规范约束 |
-
-### 精炼逻辑
-
-在 `dev-guide.md` 基础上**追加**架构章节（不删除原有内容）：
-
-1. **B-subset. 组件设计**（从 Output Format B 裁剪到模块级）：
-   - 模块内部分层表（层名 / 职责 / 关键类）
-   - 边界定义（公开接口 vs 内部实现）
-   - 依赖方向约束
-
-2. **C-subset. 数据与交互设计**（从 Output Format C 裁剪到模块级）：
-   - 数据所有权声明（本模块拥有哪些实体）
-   - 同步/异步通信边界表
-   - API 契约摘要（引用 api.md）
-
-3. **ADR（架构决策记录）**：
-   - 使用 G. ADR Template 的 7 节结构
-   - 至少 1 个 ADR（该模块最关键的架构决策）
-   - Status / Context / Decision / Options / Consequences / NFR Impact / Related
+| **project-analyze** | Analyzing existing architecture | Run `/project-analyze` to generate knowledge graph and dependency analysis |
+| **code-review** | Architecture compliance validation | code-review Dimension 5 validates architectural principles |
+| **doc-standards-enforcer** | Validating architecture documentation | Validate ADR and HLD/LLD format compliance |
+| **doc-coauthoring** | Collaborative architecture design | Use for co-authoring technical specifications |
+| **requirements-writer** | Aligning NFRs with architecture | System-level NFRs constrain module-level requirements |
 
-4. **NFR 对齐**：
-   - 确保 prd.md 中的 NFR-{MOD}-NNN 与架构选择一致
-   - 首轮标注 `[待系统级确认]`（Phase 4 生成 NFR-SYS-NNN 后回扫替换）
-
-### 不做的事（硬性）
-
-- ❌ 不生成 A（Architecture Summary）— 项目级，Phase 4 负责
-- ❌ 不生成 D（Deployment）— 项目级，Phase 4 负责
-- ❌ 不生成 E（Risk）/ F（Roadmap）— 项目级，Phase 4 负责
-- ❌ 不做交互式 6 步决策工作流 — 信息从 Phase 2 产物中提取
-- ❌ 不修改 prd.md / api.md / data-model.md — 只精炼 dev-guide.md
-
-### 输出质量门禁
-
-精炼后的 dev-guide.md 必须通过以下检查（由 Phase 2.5 Gate 3 执行）：
-- 包含"组件设计"或"Component Design"章节
-- 包含至少 1 个 ADR 条目
-- ADR 包含 Status + Decision + Consequences（7 节中最关键的 3 节）
-
----
-
-## Guardrails
-
-Do **not**:
-- Recommend microservices by default
-- Add Redis, MQ, ES, Kubernetes, or gateway without tying them to a requirement
-- Create service splits that mirror technical layers instead of business capabilities
-- Ignore rollback, observability, or release strategy
-- Propose strong consistency across distributed services without calling out complexity and cost
-- Treat architecture diagrams as sufficient without delivery and ops explanation
-- Overfit for hypothetical future scale while hurting current delivery
-
----
-
-## Review Checklist
-
-**Problem-fit:** Business problem clearly stated? Main technical driver identified? Design solves real problem rather than showcases technology?
-
-**Simplicity:** Is there a simpler design that would work now? Unnecessary distributed complexity avoided?
-
-**Boundaries:** Service/module boundaries aligned to business capability? Data ownership clear? Sync and async boundaries clear?
-
-**NFR mapping:** Each key NFR mapped to concrete architecture measures? Concurrency, availability, security, and performance handled explicitly?
-
-**Operability:** Monitoring, logs, traces, alerts, and rollback covered? Deployment topology described?
+## Output Format
 
-**Safety and correctness:** Duplicate prevention and idempotency addressed? Rate limits, degradation, and fallback paths defined? Consistency trade-offs explained?
+Architecture deliverables include A-F:
+- A: Architecture Summary
+- B: Component View
+- C: Data & Interaction Design
+- D: Deployment Strategy
+- E: Risk Assessment
+- F: Evolution Roadmap
 
-**Evolution:** Design supports incremental evolution? Phased roadmap instead of "final architecture" thinking?
+For module-level architecture refinement (Refine Mode), integrate with project-analyze Phase 2.5 to enhance development guides with component design, ADRs, and NFR alignment.
 
----
+## Constraints
 
-## Skill 协作
+- Must follow six-step decision workflow
+- Architecture style must match actual needs, not trends
+- Every NFR must have concrete implementation mechanisms
+- Must include deployment, monitoring, and rollback strategies
+- Documentation must follow ADR template
+- Architecture must support evolution, not assume finality
 
-| 协作 Skill | 触发条件 | 交互方式 |
-|-----------|---------|---------|
-| **project-analyze** | Phase 2.5 Refine Mode 调用；Phase 4 聚合时引用 A/E/F 模板结构 | 读取模块文档 + 知识图谱 |
-| **code-review** | 架构合规性验证 | code-review Dimension 5 验证架构合规；重大违规时建议运行本 skill 深度评审 |
-| **doc-standards-enforcer** | 产出架构文档（ADR、HLD/LLD） | 架构交付物完成后，用 `doc-standards-enforcer` 验证文档格式 |
-| **doc-coauthoring** | 协作撰写技术规格或设计文档 | 本 skill 提供技术内容准确性，`doc-coauthoring` 管理协作流程 |
-| **project-query** | 需要查询架构分析详细数据（层违反、耦合度等） | 建议运行 |
-| **requirements-writer** | NFR-SYS-* 是 NFR-{MOD}-* 的上游约束 | 系统级 NFR 约束模块级 NFR 范围 |
-| **java-conventions** | Java/Spring 项目架构设计 | 加载栈级分层/命名/并发规范 |
-| **web-conventions** | 前端项目架构设计 | 加载前端项目结构/组件规范 |
+> IMPORTANT: When this skill is invoked, you MUST read the relevant
+> subdirectory files based on the current design phase. Do NOT execute using
+> only this SKILL.md content.