pdlc-arch — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pdlc-arch (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
<!-- @include templates/prompts/iron-law-tool.md（已内联于下方，无需另读） --> ⛔ IRON LAW · 不可违反的硬门禁（工具型命令）
本命令不是主链路上的阶段：不追加 `history`，不改 `current_stage` / `next_step` / `last_phase_result`，也不为此分配功能ID。以下规则不可协商：
违反任一条 = 立即中止当前命令，输出违规详情，等待人工介入。 <!-- @include-end templates/prompts/iron-law-tool.md -->
对当前项目架构进行全面分析，输出架构评估报告。
<!-- @include templates/prompts/layout-detect.md（已内联于下方，无需另读） -->
下文出现的 backend/services/、frontend/web/ 等路径只是空项目时的默认布局。动手创建或扫描目录之前，先看项目实际长什么样：
pnpm-workspace.yaml、turbo.json、nx.json、lerna.json、package.json 的 workspaces、go.work、Cargo.toml 的 [workspace]、settings.gradle(.kts) 的 include → 按其中声明的目录（如 apps/、packages/、services/、crates/）理解布局
backend/services/、services/、apps/、packages/、cmd/、crates/ 下找已存在的服务 / 应用，新单元放在同级，命名与目录结构照着已有的来src/，或是框架默认结构（manage.py + 各 app、Rails 的 app/、Next.js 的 app/ / pages/、Spring Boot 单模块）→ 按框架约定放，不要新建 services/ 一类平行目录--autonomous 下记入 auto_decisions[]）把探测结论写进本次报告：布局类型 + 依据的文件 + 新内容的落点。判断错了的代价是在用户仓库里长出一套平行目录，比多问一句贵得多。 <!-- @include-end templates/prompts/layout-detect.md -->
架构总览是 surface 型产物：docs/ARCHITECTURE.md描述"系统当前长什么样"，就地覆盖更新，不按日期累积多份文件。演进历史靠git log docs/ARCHITECTURE.md追溯。这与 per-feature 的docs/02_design/architecture/F-xxx-arch.md（ledger 型，记录"为某个 feature 为什么改架构"）分工互补。
backend/ 和 frontend/ 下的所有服务和应用docs/02_design/architecture/ 下的 per-feature 架构 ledger（若有）*-arch-analysis.md（散落在 docs/02_design/architecture/ 或旧 review 目录，即 v1.0 的 v1..v5 累积模式），提示并移到 docs/.archive/architecture/，以最新一份作为 ARCHITECTURE.md 的起点docs/ARCHITECTURE.md（参考 本 skill 目录下的 assets/architecture-overview-template.md）⚠️ 必须写入磁盘，不可仅在对话中输出。
文件路径：docs/ARCHITECTURE.md（固定，就地覆盖）
文档顶部包含 PDLC 追溯头 + surface 标记：
<!-- artifact_type: surface -->
<!-- PDLC-TRACE -->
<!-- 功能名称: 架构总览 -->
<!-- 阶段: design -->
<!-- 创建时间: <执行时的实际 ISO 8601 时间戳> -->报告内容：
创建后验证：确认 docs/ARCHITECTURE.md 已存在且为本次内容
<!-- @include templates/prompts/output-language.md（已内联于下方，无需另读） --> 🌐 Output language for generated artifacts
All generated artifacts (PRDs, design docs, code comments, review reports, test plans, deployment manuals, changelog entries, etc.) follow this policy:
an artifact (e.g. "write the PRD in English", "用英文写 API 设计文档", "output the deploy doc in Japanese"), use that language for that artifact, regardless of conversation language.
language and others in a different language (common: Chinese PRD + English API docs for partners), honour each per-artifact instruction.
ask once before producing the first artifact.
This policy applies to content (prose, comments, headings). It does not override technical conventions like English variable names, English git commit subjects, or English error codes when the project's conventions require them. <!-- @include-end templates/prompts/output-language.md -->
ARCHITECTURE.md$ARGUMENTS
<!-- @include templates/prompts/handoff.md（已内联于下方，无需另读） -->
命令完成后必须输出以下格式的最终消息：
✅ <阶段名> 完成：<主要产出物路径>
📊 自检：<通过数>/<总数> 通过（若有未通过，附要点）
📦 状态快照：docs/.pdlc-state/<feature-id>.json
👉 下一步：/pdlc-<next_step>
（如果有分叉）或 /pdlc-<alt>（条件：<选择依据>）规则：
next_step，此时输出 👉 下一步：（本次流程结束，无后续）/pdlc-tdd；若测试已齐 → /pdlc-review"<!-- @include-end templates/prompts/handoff.md -->
本命令的 handoff 输出：
✅ 架构总览已更新：docs/ARCHITECTURE.md
📦 surface 型就地覆盖（历史见 git log docs/ARCHITECTURE.md）
👉 下一步：（本次流程结束，无后续）~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.