@dtt_siye/atool 1.2.1 → 1.3.0

package/skills/requirements-writer/examples/prd-outline-example.md

@@ -5,8 +5,8 @@ status: draft
 owner: PM
 last_updated: 2026-01-09
 related_docs:
-  - docs/100-standards/102-requirements-standards.md
-  - docs/200-product/201-project-brief.md
+  - docs/100-governance/102-requirements-standards.md
+  - docs/200-business/201-project-brief.md
 ---
 
 ## Purpose
@@ -206,9 +206,9 @@ Writing Order:
 
 ## References
 
-- Project Brief: `docs/200-product/201-project-brief.md`
-- Requirements Standards: `docs/100-standards/102-requirements-standards.md`
-- Documentation Standards: `docs/100-standards/101-documentation-standards.md`
+- Project Brief: `docs/200-business/201-project-brief.md`
+- Requirements Standards: `docs/100-governance/102-requirements-standards.md`
+- Documentation Standards: `docs/100-governance/101-documentation-standards.md`
 
 ## Version History
 

package/skills/requirements-writer/templates/module-prd-template.md

@@ -6,8 +6,8 @@ owner: PM
 last_updated: YYYY-MM-DD
 related_docs:
   - docs/300-requirements/30x-prd-outline.md
-  - docs/200-product/201-project-brief.md
-  - docs/100-standards/102-requirements-standards.md
+  - docs/200-business/201-project-brief.md
+  - docs/100-governance/102-requirements-standards.md
 ---
 
 ## Purpose
@@ -196,7 +196,7 @@ All NFRs must be **quantifiable and testable**.
 - **Condition**: <Under what conditions>
 - **Measurement**: <How to measure>
 - **Verification**: <Test method>
-- **Reference**: `docs/600-architecture/6xx-security-view.md`
+- **Reference**: `docs/400-architecture/4xx-security-view.md`
 
 ### NFR-<MODULE>-005: Audit
 
@@ -205,7 +205,7 @@ All NFRs must be **quantifiable and testable**.
 - **Condition**: <Under what conditions>
 - **Measurement**: <How to measure>
 - **Verification**: <Test method>
-- **Reference**: `docs/600-architecture/6xx-security-view.md`
+- **Reference**: `docs/400-architecture/4xx-security-view.md`
 
 ### NFR-<MODULE>-006: Data Quality
 
@@ -214,7 +214,7 @@ All NFRs must be **quantifiable and testable**.
 - **Condition**: <Under what conditions>
 - **Measurement**: <How to measure>
 - **Verification**: <Test method>
-- **Reference**: `docs/500-data/502-data-dictionary.md`
+- **Reference**: `docs/600-data/502-data-dictionary.md`
 
 ### NFR-<MODULE>-007: Compatibility
 
@@ -261,7 +261,7 @@ All NFRs must be **quantifiable and testable**.
 - **Color Contrast**: <Requirements>
 - **Font Sizing**: <Requirements>
 
-**Design Reference**: `docs/400-design/4xx-ux-design.md`
+**Design Reference**: `docs/500-design/4xx-ux-design.md`
 
 ## Data Requirements
 
@@ -270,11 +270,11 @@ All NFRs must be **quantifiable and testable**.
 <List key data entities this module uses/produces>
 
 - **<Entity 1>**: <Description>
-  - **Reference**: `docs/500-data/502-data-dictionary.md`
+  - **Reference**: `docs/600-data/502-data-dictionary.md`
   - **Operations**: <Read/Write/Update/Delete>
 
 - **<Entity 2>**: <Description>
-  - **Reference**: `docs/500-data/502-data-dictionary.md`
+  - **Reference**: `docs/600-data/502-data-dictionary.md`
   - **Operations**: <Read/Write/Update/Delete>
 
 ### Data Validations
@@ -340,20 +340,20 @@ Instead use:
 ## References
 
 ### Product Documents
-- Project Brief: `docs/200-product/201-project-brief.md`
+- Project Brief: `docs/200-business/201-project-brief.md`
 - Requirements Outline: `docs/300-requirements/30x-prd-outline.md`
 
 ### Design Documents
-- UX Design: `docs/400-design/4xx-ux-design.md`
-- Functional Spec: `docs/400-design/4xx-functional-spec.md`
+- UX Design: `docs/500-design/4xx-ux-design.md`
+- Functional Spec: `docs/500-design/4xx-functional-spec.md`
 
 ### Data Documents
-- Data Dictionary: `docs/500-data/502-data-dictionary.md`
-- ERD: `docs/500-data/501-entity-relationship.md`
+- Data Dictionary: `docs/600-data/502-data-dictionary.md`
+- ERD: `docs/600-data/501-entity-relationship.md`
 
 ### Architecture Documents
-- Security View: `docs/600-architecture/6xx-security-view.md`
-- API Specification: `docs/700-engineering/701-api-reference.md`
+- Security View: `docs/400-architecture/4xx-security-view.md`
+- API Specification: `docs/800-engineering/701-api-reference.md`
 
 ## Version History
 

package/skills/requirements-writer/templates/prd-outline-template.md

@@ -174,9 +174,9 @@ For each module, create User Stories in: `docs/300-requirements/330-user-stories
 
 ## References
 
-- Project Brief: `docs/200-product/201-project-brief.md`
-- Requirements Standards: `docs/100-standards/102-requirements-standards.md`
-- Documentation Standards: `docs/100-standards/101-documentation-standards.md`
+- Project Brief: `docs/200-business/201-project-brief.md`
+- Requirements Standards: `docs/100-governance/102-requirements-standards.md`
+- Documentation Standards: `docs/100-governance/101-documentation-standards.md`
 
 ## Version History
 

package/skills/requirements-writer/templates/user-story-template.md

@@ -6,7 +6,7 @@ owner: PM
 last_updated: YYYY-MM-DD
 related_docs:
   - docs/300-requirements/31x-prd-<module>.md
-  - docs/400-design/4xx-functional-spec.md
+  - docs/500-design/4xx-functional-spec.md
 us_id: US-IA-XXXX
 module: <MODULE>
 priority: P0|P1|P2
@@ -241,8 +241,8 @@ so that **I can quickly identify what changed between versions and validate that
 - **Expected Result**: <What confirms it works>
 
 **Data References**:
-- **Entity**: `<docs/500-data/502-data-dictionary.md>` (<field descriptions>)
-- **API**: `<docs/700-engineering/701-api-reference.md>` (<endpoint details>)
+- **Entity**: `<docs/600-data/502-data-dictionary.md>` (<field descriptions>)
+- **API**: `<docs/800-engineering/701-api-reference.md>` (<endpoint details>)
 
 #### FR-<MODULE>-<SEQ>: <Additional Requirement>
 
@@ -417,7 +417,7 @@ so that **I can quickly identify what changed between versions and validate that
 
 ### Design Reference
 
-**Detailed UI/UX Specifications**: `docs/400-design/4xx-ux-design.md`
+**Detailed UI/UX Specifications**: `docs/500-design/4xx-ux-design.md`
 
 ---
 
@@ -438,7 +438,7 @@ so that **I can quickly identify what changed between versions and validate that
   - **Type**: <Data type>
   - **Required**: <Yes/No>
   - **Validation**: <Rules>
-  - **Reference**: `docs/500-data/502-data-dictionary.md` (<field definition>)
+  - **Reference**: `docs/600-data/502-data-dictionary.md` (<field definition>)
 
 - **Attribute 2**: <Name>
   - <Same structure>
@@ -480,7 +480,7 @@ so that **I can quickly identify what changed between versions and validate that
 
 ### Data Dictionary References
 
-**Primary Data Dictionary**: `docs/500-data/502-data-dictionary.md`
+**Primary Data Dictionary**: `docs/600-data/502-data-dictionary.md`
 
 **Relevant Sections**:
 - <Section 1>: <Description>
@@ -645,7 +645,7 @@ so that **I can quickly identify what changed between versions and validate that
 
 ### Security Reference
 
-**Security Architecture**: `docs/600-architecture/6xx-security-view.md`
+**Security Architecture**: `docs/400-architecture/4xx-security-view.md`
 
 ---
 
@@ -847,7 +847,7 @@ This user story is "done" when:
 - **Error Codes**: <What errors we handle>
 - **Retry Logic**: <How we retry failures>
 
-**Reference**: `docs/700-engineering/701-api-reference.md`
+**Reference**: `docs/800-engineering/701-api-reference.md`
 
 ### Data Migration
 
@@ -1042,28 +1042,28 @@ This user story is "done" when:
 - **Requirements Outline**: `docs/300-requirements/30x-prd-outline.md`
 
 ### Design Documents
-- **Functional Specification**: `docs/400-design/4xx-functional-spec.md`
-- **UX Design**: `docs/400-design/4xx-ux-design.md`
-- **User Flows**: `docs/400-design/4xx-user-flows.md`
+- **Functional Specification**: `docs/500-design/4xx-functional-spec.md`
+- **UX Design**: `docs/500-design/4xx-ux-design.md`
+- **User Flows**: `docs/500-design/4xx-user-flows.md`
 
 ### Data Documents
-- **Data Dictionary**: `docs/500-data/502-data-dictionary.md`
-- **Entity Relationship Diagram**: `docs/500-data/501-entity-relationship.md`
-- **Metrics Definition**: `docs/500-data/503-metrics-definition.md`
+- **Data Dictionary**: `docs/600-data/502-data-dictionary.md`
+- **Entity Relationship Diagram**: `docs/600-data/501-entity-relationship.md`
+- **Metrics Definition**: `docs/600-data/503-metrics-definition.md`
 
 ### Architecture Documents
-- **Security Architecture**: `docs/600-architecture/6xx-security-view.md`
-- **Integration Architecture**: `docs/600-architecture/6xx-integration.md`
-- **API Architecture**: `docs/600-architecture/6xx-api-design.md`
+- **Security Architecture**: `docs/400-architecture/4xx-security-view.md`
+- **Integration Architecture**: `docs/400-architecture/4xx-integration.md`
+- **API Architecture**: `docs/400-architecture/4xx-api-design.md`
 
 ### Engineering Documents
-- **API Reference**: `docs/700-engineering/701-api-reference.md`
-- **Data Models**: `docs/700-engineering/702-data-models.md`
+- **API Reference**: `docs/800-engineering/701-api-reference.md`
+- **Data Models**: `docs/800-engineering/702-data-models.md`
 
 ### Standards
-- **Requirements Standards**: `docs/100-standards/102-requirements-standards.md`
-- **Documentation Standards**: `docs/100-standards/101-documentation-standards.md`
-- **Engineering Standards**: `docs/100-standards/106-engineering-standards.md`
+- **Requirements Standards**: `docs/100-governance/102-requirements-standards.md`
+- **Documentation Standards**: `docs/100-governance/101-documentation-standards.md`
+- **Engineering Standards**: `docs/100-governance/106-engineering-standards.md`
 
 ---
 
@@ -1103,7 +1103,7 @@ Before considering this User Story complete, verify:
 - [ ] All 10 sections are complete
 - [ ] Each section meets minimum word count
 - [ ] All acceptance criteria are objectively verifiable
-- [ ] All data references link to `docs/500-data/`
+- [ ] All data references link to `docs/600-data/`
 - [ ] All security/audit requirements are specified
 - [ ] RBAC and data scope are defined
 - [ ] All edge cases are covered

package/skills/software-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: software-architecture
 description: Use when designing, reviewing, or scaffolding system architecture — covers architecture style selection, high-concurrency/HA design, DDD, clean architecture, microservice boundaries, and deployment strategy.
-version: 1.0.0
+version: 1.1.0
 category: architecture
 ---
 
@@ -185,25 +185,241 @@ WAF / CDN / ingress / LB → API gateway → service registry/discovery → conf
 
 ## Output Format
 
-### A. Architecture Summary
-- Business context and dominant technical drivers
-- Recommended architecture style
-- Why this complexity level is right for now
+### 概述
 
-### B. Component Design
-Key components and their responsibilities.
+架构设计产出 6 个交付物（A-F）+ ADR 模板。每个交付物有明确的模板结构和必填字段。
 
-### C. Data and Interaction Design
-Sync vs async boundaries, API boundaries, data ownership, consistency approach, cache strategy.
+如果文档写入 `docs/400-architecture/`，需遵循 `doc-standards-enforcer` 的 frontmatter 规范。
 
-### D. Deployment and Operations
-Environment layout, scaling model, CI/CD, observability, rollback.
+---
+
+### 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 | 失效策略 | 一致性风险 |
+|---------|--------|-----|---------|-----------|
+
+## 5. 数据一致性方案
+对跨服务的数据操作：
+| 场景 | 涉及服务 | 一致性策略 | 补偿机制 |
+|------|---------|-----------|---------|
+| 下单支付 | Order+Payment | Saga | 退款补偿 |
+```
+
+### D. Deployment and Operations（部署与运维）
+
+```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
+### 正面
+- ...
+
+### 负面
+- ...
+
+### 风险
+- ...
 
-### E. Risk and Trade-offs
-What this architecture solves and what complexity it introduces.
+## NFR Impact
+| NFR | 影响 | 缓解措施 |
+|-----|------|---------|
+| NFR-SYS-001 性能 | P99 可能增加 50ms | 引入缓存层 |
 
-### F. Evolution Roadmap
-Phased stages — e.g., Phase 1: modular monolith → Phase 2: extract hot/high-change services → Phase 3: platform governance and observability hardening.
+## 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 的范围。
 
 ---
 
@@ -230,7 +446,7 @@ 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.0 五维分析框架) first to generate knowledge graph and module inventory, then use that data to inform architecture review |
+| **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 |
@@ -240,7 +456,7 @@ This skill orchestrates architecture; stack-specific skills govern implementatio
 
 For existing projects requiring architecture assessment:
 
-1. Run `/project-analyze` (v5.0 五维分析框架) to generate knowledge graph
+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
@@ -276,3 +492,18 @@ Do **not**:
 **Safety and correctness:** Duplicate prevention and idempotency addressed? Rate limits, degradation, and fallback paths defined? Consistency trade-offs explained?
 
 **Evolution:** Design supports incremental evolution? Phased roadmap instead of "final architecture" thinking?
+
+---
+
+## Skill 协作
+
+| 协作 Skill | 触发条件 | 交互方式 |
+|-----------|---------|---------|
+| **project-analyze** | 需要分析现有项目架构 | 先运行 `/project-analyze` 生成知识图谱，再用数据驱动架构评审 |
+| **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** | Architecture NFR 需要传递到模块 PRD | 系统级 NFR（NFR-SYS-*）作为模块级 NFR 的上游约束 |
+| **java-conventions** | Java/Spring 项目架构设计 | 加载栈级分层/命名/并发规范 |
+| **web-conventions** | 前端项目架构设计 | 加载前端项目结构/组件规范 |

package/templates/CLAUDE.md.android

@@ -55,3 +55,20 @@ Android / Kotlin application
 # Check for dependency updates
 ./gradlew dependencyUpdates
 ```
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.

package/templates/CLAUDE.md.devops

@@ -48,3 +48,20 @@ DevOps / Infrastructure (Docker / Kubernetes / Terraform / CI-CD)
 - Use secrets management (Vault, AWS Secrets Manager)
 - Least privilege principle
 - Rotate secrets regularly
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.

package/templates/CLAUDE.md.generic

@@ -32,3 +32,20 @@ Generic project (no specific technology stack detected)
 - Run `./install.sh --project .` again after setting up your project
 - aTool can auto-detect your stack once you add config files (package.json, Cargo.toml, etc.)
 - Use `/atool-init` to re-run initialization after project setup
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.

package/templates/CLAUDE.md.go

@@ -65,3 +65,20 @@ gofmt -w .
 # Tidy dependencies
 go mod tidy
 ```
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.

package/templates/CLAUDE.md.harmony

@@ -52,3 +52,20 @@ hvigorw clean
 # Run tests
 hvigorw test
 ```
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.

package/templates/CLAUDE.md.java

@@ -54,3 +54,20 @@ Java / Spring Boot project
 # Check for dependency updates
 ./mvnw versions:display-dependency-updates
 ```
+
+
+## aTool Hard Rules (Non-bypassable)
+
+These rules apply regardless of which skills are invoked or which mode the IDE is in (Plan Mode, normal mode, etc.).
+
+### 1. Documentation Sync Gate
+After modifying any source file, update affected documentation (README.md, COMPONENT.md, UI_STYLE.md, docs/) BEFORE claiming the task done.
+Gate: if docs are stale, the task is NOT done. Invoke /verification-before-completion before completion.
+
+### 2. Verification Gate
+Before claiming any work complete: (a) run tests and verify they pass, (b) check doc freshness, (c) confirm no critical code quality issues.
+If any check fails, the task is NOT done. No exceptions.
+
+### 3. Root Cause Before Fix
+When fixing bugs: investigate and identify root cause BEFORE writing any fix code. Never guess-fix or try multiple changes simultaneously.
+See /systematic-debugging for full methodology.