@elvis1513/auto-coding-skill 0.3.0 → 1.0.1

package/cli/assets/skill/SKILL.md

@@ -1,11 +1,15 @@
 ---
 name: auto-coding-skill
-description: Use for strict Go fullstack monorepo engineering workflow in Claude/Codex. Initialize docs, fill docs/ENGINEERING.md frontmatter once, then execute design->implement->local-docker-gates->jenkins-trigger->verify.
+description: Use for a lightweight Jenkins-first engineering workflow in Claude/Codex. Initialize docs, fill docs/ENGINEERING.md once, then execute task->minimal-design->light-gate->push->jenkins->target-env->closure.
 ---
 
 # Auto Coding Skill (Claude + Codex)
 
-This branch specializes the skill for Go backend + frontend monorepo projects that build Docker images locally and use Jenkins pipelines to auto-deploy after push. It supports both Claude and Codex. During design, research, implementation, verification, and delivery, prefer already available MCP servers, installed skills, plugins, and app connectors over ad-hoc manual work whenever they can complete the task reliably.
+This skill is for Go backend + frontend monorepo projects that rely on Jenkins to build and deploy after push. It supports both Claude and Codex. The default workflow is lightweight locally, then uses Jenkins and the real target environment as the authoritative verification path.
+
+`docs/ENGINEERING.md` is intentionally Git-tracked in this workflow. The remaining environment fields in that file are mandatory, must be filled with real values, and are committed as part of the project baseline. Unused environment keys should be removed from the template instead of being left as placeholders.
+
+Prefer already available MCP servers, installed skills, plugins, and app connectors over ad-hoc manual work whenever they can complete the task reliably.
 
 Default to multi-agent execution when the client supports it. Break work into independent design, research, implementation, validation, and documentation subtasks so Claude/Codex can run them in parallel whenever that reduces cycle time without weakening control of the main task.
 
@@ -23,21 +27,15 @@ Use available platform capabilities first:
 3) Prefer supported plugins/apps/connectors when they provide authoritative project context or can write back records.
 4) Fall back to manual shell/code workflows only when the above are unavailable, insufficient, or slower than direct execution.
 
-Typical examples:
-- Design/UI work: prefer Figma MCP and related design skills.
-- Documentation/library lookup: prefer official docs and MCP-backed doc tools.
-- Project management or knowledge base updates: prefer Linear/Notion connectors if available.
-- Browser/runtime verification: prefer Playwright/browser tools if available.
-- Pipeline and deployment verification: prefer Jenkins-capable connectors, browser automation, or project-integrated tools if available.
-
 ## Collaboration policy
 
 Prefer multi-agent mode across the workflow:
 
 1) Split independent subtasks early when they can run in parallel.
-2) Keep the main agent on the critical path: task framing, design decisions, integration, and final quality gates.
-3) Use side agents for bounded work such as research, code slices, documentation updates, regression checks, or review passes.
+2) Keep the main agent on the critical path: task framing, design decisions, integration, Jenkins / target-env verification, and final closure.
+3) Use side agents for bounded work such as research, code slices, documentation updates, targeted regression checks, or review passes.
 4) Do not delegate a blocking architectural decision without keeping one agent responsible for final integration and correctness.
+5) A practical default split for Go fullstack work is: design/research, backend implementation, frontend implementation, validation/documentation.
 
 ## Entry
 
@@ -69,72 +67,93 @@ Fill only:
 
 This contains all manual fields:
 - `commands.*`
-- `runtime.*`
+- `runtime.*` (only for optional local diagnostics)
+- `target_env.*`
 - `jenkins.*`
 - `docs.*`
 
 Do not duplicate config in other md/yaml files.
+Do not hide `docs/ENGINEERING.md` in `.gitignore`.
+
+Minimum required config for the default flow:
+- `project.name`
+- `commands.build`
+- `commands.quick_test` or `commands.test`
+- `commands.lint` or `commands.typecheck`
+- `target_env.name`
+- `target_env.frontend_base_url`
+- `target_env.frontend_username`
+- `target_env.frontend_password`
+- `target_env.backend_base_url`
+- `target_env.backend_username`
+- `target_env.backend_password`
+- `target_env.health_base_url`
+- `target_env.health_path`
+- `jenkins.base_url`
+- `jenkins.ui_username`
+- `jenkins.ui_password`
+- `jenkins.api_user`
+- `jenkins.api_password`
+- `jenkins.trigger_branch`
+- `jenkins.image_repository`
+- `jenkins.image_tag_strategy`
+- `jenkins.deploy_env`
+- `jenkins.job_url`
 
 ## Branch policy
 
-- `dev` remains the only long-lived integration branch.
-- Default behavior stays `dev`-first when there is no parallel work conflict.
-- If Claude or Codex is operating in a derived worktree, detached HEAD, or any parallel task context where another thread is already changing `dev`, prefer creating a temporary branch from the latest `dev` before editing.
-- Name temporary branches after the task, preferably `codex/<task-id>-<slug>` such as `codex/t0005-domestic-payment-site`.
-- Keep the temporary branch scoped to one task, complete design/implementation/verification there, then merge or rebase it back onto `dev` only after local gates pass.
-- Do not treat temporary branches as release branches; the final integration target is still `dev`.
-- In temporary-branch mode, work in small, closed-loop slices. Each slice should have a clear scope, synchronized docs, the relevant local validation, and a commit that can stand on its own.
-- Rebase temporary branches frequently against the latest `dev` to keep merge surfaces small.
-
-## CI trigger strategy
-
-- Prefer a split Jenkins model when parallel worktrees are active:
-- MR or branch validation job: build/test/lint/typecheck and optional non-deploy runtime checks on temporary branches or merge requests.
-- `dev` integration/deploy job: trigger only from pushes that land on `dev`.
-- Do not rely on merge-request acceptance events to drive production deployment when a `dev` push event already exists; that commonly creates duplicate builds around merge time.
+- `dev` is the long-lived integration branch.
+- Use a temporary task branch only when parallel work would otherwise collide on `dev`.
+- Keep temporary branches task-scoped and merge/rebase back into `dev` after closure.
 
 ## Execution order
 
-1) choose branch mode (`dev` directly, or temporary branch if parallel worktree rules apply)
-2) `docs/ENGINEERING.md`
-3) `docs/tasks/taskbook.md`
-4) `docs/design/**`
-5) implementation
-6) local build/test/lint gates
-7) start and validate local Docker Compose runtime
-8) update API docs + regression matrix + bug list + summary
-9) verify Jenkins config / Jenkinsfile readiness
-10) if temporary-branch mode is used, close one small slice at a time with reviewable commits and rebase regularly onto `dev`
-11) merge/rebase temporary branch back to latest `dev` when temporary-branch mode was used
-12) commit/push to trigger Jenkins
-13) verify Jenkins pipeline + target environment health, preferably with `verify-jenkins-build --git-ref HEAD` (strict deploy check by default; use `--allow-no-deploy` only for docs-only sync verification)
+1) read `docs/ENGINEERING.md`
+2) read / update `docs/tasks/taskbook.md`
+3) write minimal design notes; create a DD only when the change is cross-module, API, DB, deployment, Jenkins, or key-page-flow related
+4) implement only the necessary changes
+5) run the default local lightweight gate
+6) commit + push
+7) verify Jenkins build / deployment result
+8) verify the real target environment
+9) append `docs/tasks/closure-log.md`
+10) use summary / deployment record / regression matrix only when the task actually requires them
 
 ## Commands
 
+Default commands:
+
+```bash
+python3 docs/tools/autopipeline/ap.py doctor
+python3 docs/tools/autopipeline/ap.py light-gate
+python3 docs/tools/autopipeline/ap.py commit-push <TASK_ID> --msg "<TASK_ID>: <summary>" --require-light-gate --require-jenkins
+python3 docs/tools/autopipeline/ap.py verify-jenkins-build --git-ref HEAD
+python3 docs/tools/autopipeline/ap.py wait-health --scope target
+python3 docs/tools/autopipeline/ap.py verify-target --backend-path /health --frontend-path /
+python3 docs/tools/autopipeline/ap.py record-closure <TASK_ID> --commit HEAD --jenkins <build-url> --result PASS --verification "health check" --verification "key api"
+```
+
+On-demand commands:
+
 ```bash
-python3 docs/tools/autopipeline/ap.py run build
-python3 docs/tools/autopipeline/ap.py run test
-python3 docs/tools/autopipeline/ap.py run lint
-python3 docs/tools/autopipeline/ap.py run typecheck
-python3 docs/tools/autopipeline/ap.py run docker_build
 python3 docs/tools/autopipeline/ap.py runtime-up
-python3 docs/tools/autopipeline/ap.py wait-health
+python3 docs/tools/autopipeline/ap.py wait-health --scope runtime
 python3 docs/tools/autopipeline/ap.py run smoke
 python3 docs/tools/autopipeline/ap.py run regression
 python3 docs/tools/autopipeline/ap.py runtime-down
-python3 docs/tools/autopipeline/ap.py verify-jenkins
-python3 docs/tools/autopipeline/ap.py verify-jenkins-build --git-ref HEAD
-python3 docs/tools/autopipeline/ap.py wait-health --scope prod
-python3 docs/tools/autopipeline/ap.py verify-api-docs
 python3 docs/tools/autopipeline/ap.py check-matrix
-python3 docs/tools/autopipeline/ap.py gen-summary T0001-1
-python3 docs/tools/autopipeline/ap.py commit-push T0001-1 --msg "T0001-1: <summary>" --require-runtime-health --require-jenkins --require-matrix
+python3 docs/tools/autopipeline/ap.py gen-summary <TASK_ID>
 ```
 
-## Quality gate expectations
-
-- Gate-4: backend must pass `commands.test`; frontend must at least pass `commands.build`, `commands.lint`, and `commands.typecheck`. Frontend automated tests are added incrementally when the repo gains them.
-- Gate-9: `docs/testing/regression-matrix.md` rows must start as `TODO` until they are actually executed.
-- A matrix row can be marked `PASS` only after real execution, and `Evidence` must contain non-placeholder logs, screenshots, or report paths.
-- `python3 docs/tools/autopipeline/ap.py check-matrix` should be treated as a hard gate; placeholder evidence is equivalent to incomplete regression.
-- Before the final commit/push, clean temporary files, logs, screenshots, generated verification artifacts, cache directories, and similar by-products created during the task. The only persistent local runtime data that may remain is `.local/`.
+## Quality policy
+
+- Default local gate is lightweight only: build, unit/quick test, lint, typecheck, API docs, Jenkinsfile / script syntax, `git diff --check`.
+- `doctor` should be used early to catch missing or invalid config before the first implementation loop.
+- `light-gate` now fails if the required default commands are not configured.
+- `doctor`, `light-gate`, and `commit-push` all fail when required environment fields are missing, placeholder-like, or syntactically invalid.
+- Do not require local Docker Compose or full local regression for every small change.
+- Jenkins and target environment verification are more valuable than repeated local simulation of deploy-only problems.
+- `verify-target` should be used for real target-environment API/page checks when the task touches user-visible or deploy-sensitive behavior.
+- `commit-push --record-closure` can close the loop in one command when Jenkins build URL and verification results are already known.
+- `regression-matrix.md` can mark `PASS` only after real execution with evidence.
+- High-risk changes must include target environment verification and usually a DD.

package/cli/assets/skill/data/templates/ENGINEERING.md

@@ -12,9 +12,12 @@ project:
 commands:
   build: ""
   test: ""
+  quick_test: ""
   lint: ""
   typecheck: ""
   format: ""
+  script_syntax: ""
+  diff_check: ""
   docker_build: ""
   compose_up: ""
   compose_down: ""
@@ -32,23 +35,33 @@ runtime:
   env_file: ""
   startup_timeout_sec: 120
 
+target_env:
+  name: ""
+  frontend_base_url: ""
+  frontend_username: ""
+  frontend_password: ""
+  backend_base_url: ""
+  backend_username: ""
+  backend_password: ""
+  health_base_url: ""
+  health_path: ""
+
 jenkins:
-  job_name: ""
+  base_url: ""
+  ui_username: ""
+  ui_password: ""
   job_url: ""
   trigger_branch: ""
   image_repository: ""
   image_tag_strategy: ""
   deploy_env: ""
   deploy_timeout_sec: 1800
-  prod_health_base_url: ""
-  prod_health_path: ""
   api_user: ""
-  api_token: ""
-  api_user_env: "JENKINS_USER"
-  api_token_env: "JENKINS_TOKEN"
+  api_password: ""
 
 docs:
   taskbook: "docs/tasks/taskbook.md"
+  closure_log: "docs/tasks/closure-log.md"
   design_dir: "docs/design"
   review_dir: "docs/reviews"
   api_doc: "docs/interfaces/api.md"
@@ -58,40 +71,90 @@ docs:
   summary_dir: "docs/tasks/summaries"
 ---
 
-# docs/ENGINEERING.md — AutoPipeline Gates (Source of Truth)
+# docs/ENGINEERING.md — Lightweight Default Workflow (Source of Truth)
 
-目标：把一次任务固化为不可跳过的流水线：  
-读任务 → 写DD → 实现 → 本地构建/测试通过 → 静态分析+Review落盘 → 更新 API Markdown+接口变更清单 →  
-本地 Docker Compose 启动验证 → 本地健康检查 → 对本地环境全量回归 + 回归矩阵 0 fail →  
-记录 Bug 并新增自动化回归 → 任务总结落盘 → commit → push 触发 Jenkins → Jenkins 构建镜像并更新目标环境 →  
-生产健康检查通过
+目标：默认采用高效率开发闭环：  
+需求/任务记录 → 最小设计 → 开发实现 → 本地轻量校验 → commit/push → Jenkins 构建部署 → 目标环境验证 → 闭环记录
 
-规则：任一步骤失败或缺产物，禁止进入下一步；本地 compose 验证未通过禁止 commit；Jenkins 未成功或生产健康检查未通过，任务不视为完成。
+默认原则：
+- 默认不要求本地 Docker Compose 启动。
+- 默认不要求本地 Docker build。
+- 默认不要求本地完整 smoke / regression。
+- 默认不要求每个小改动生成长 summary。
+- 默认不要求 regression matrix 全 PASS。
+- 默认不要求 deployment record。
+- Jenkins 构建结果和目标环境真实验证，比本地模拟更重要。
 
 补充规则：
-- 每次任务闭环后，必须清理临时文件、临时目录、日志、截图、回归中间产物、构建缓存等非必要产物；仅 `.local/` 下的本地运行数据允许保留。
+- 每次任务闭环后，必须清理临时文件、临时目录、日志、截图、构建缓存等非必要产物；仅明确需要保留的本地诊断目录允许保留。
+- 所有手工填写信息，只维护在本文件 frontmatter 中，其他文档不得重复配置。
+- `docs/ENGINEERING.md` 必须提交到 Git 管理，不允许写入 `.gitignore`。
+- 本 workflow 明确允许在 `docs/ENGINEERING.md` 中明文维护平台账号、密码，并随 Git 一起版本化。
+- 未参与默认流程的环境项不要保留占位；模板中未保留的字段视为已清理，不再额外配置。
 
 ---
 
 ## 0. 配置填写（必须）
 
-先填写 `docs/ENGINEERING.md` frontmatter 中的所有空值（例如 Go/前端目录、Docker 文件、Compose 服务、Jenkins Job、健康检查地址、命令）。  
-禁止在其他 md/yaml 重复维护这些配置。
+先填写 `docs/ENGINEERING.md` frontmatter 中的所有空值。重点包括：
+- `commands.*`：本地轻量校验命令
+- `target_env.*`：目标环境前端 / 后端地址、用户名、密码，必须全部填写且真实可用
+- `jenkins.*`：Jenkins UI/API 用户名、密码、Job、分支、镜像、部署环境，必须全部填写且真实可用
+
+字段说明：
+- `target_env.backend_username` / `target_env.backend_password`：目标环境后台账号
+- `target_env.frontend_username` / `target_env.frontend_password`：目标环境前端登录账号
+- `jenkins.ui_username` / `jenkins.ui_password`：Jenkins 页面登录账号
+- `jenkins.api_user` / `jenkins.api_password`：Jenkins API 用户名 / 密码
+
+默认必填：
+- `project.name`
+- `commands.build`
+- `commands.quick_test` 或 `commands.test`
+- `commands.lint` 或 `commands.typecheck`
+- `target_env.name`
+- `target_env.frontend_base_url`
+- `target_env.frontend_username`
+- `target_env.frontend_password`
+- `target_env.backend_base_url`
+- `target_env.backend_username`
+- `target_env.backend_password`
+- `target_env.health_base_url`
+- `target_env.health_path`
+- `jenkins.ui_username`
+- `jenkins.ui_password`
+- `jenkins.api_user`
+- `jenkins.api_password`
+- `jenkins.trigger_branch`
+- `jenkins.image_repository`
+- `jenkins.image_tag_strategy`
+- `jenkins.deploy_env`
+- `jenkins.job_url`
+
+按需填写：
+- `runtime.*`：仅在本地运行诊断时使用
+- `commands.compose_up` / `commands.compose_down` / `commands.smoke` / `commands.regression`
 
 ---
 
 ## 1. 权威输入与冲突裁决（优先级）
 
-1) docs/ENGINEERING.md（本文件）  
-2) docs/tasks/taskbook.md  
-3) docs/design/**  
-4) docs/interfaces/api.md  
-5) docs/interfaces/api-change-log.md  
-6) docs/testing/regression-matrix.md（必须 0 FAIL）  
-7) docs/bugs/bug-list.md（长期积累，回归必测）  
-8) docs/tasks/summaries/**（每任务一份，强制产物）  
-9) docs/deployment/**  
-10) 代码实现（不得反向覆盖 1~9）
+1) `docs/ENGINEERING.md`
+2) `docs/tasks/taskbook.md`
+3) `docs/design/**`
+4) `docs/interfaces/api.md`
+5) `docs/interfaces/api-change-log.md`
+6) `docs/testing/regression-matrix.md`
+7) `docs/bugs/bug-list.md`
+8) `docs/tasks/closure-log.md`
+9) `docs/tasks/summaries/**`
+10) `docs/deployment/**`
+11) 代码实现
+
+说明：
+- `closure-log.md` 是每个任务默认必须留下的轻量闭环记录。
+- `summaries/**` 只用于跨模块、高风险、阶段性里程碑、需要完整复盘的任务。
+- `deployment/**` 只用于真实部署记录、手工发布或高风险发布场景。
 
 ---
 
@@ -99,56 +162,116 @@ docs:
 
 优先使用当前环境已安装、已授权、已可访问的工具能力：
 
-1) MCP servers  
-2) 已安装 skills  
-3) plugins / apps / connectors  
+1) MCP servers
+2) 已安装 skills
+3) plugins / apps / connectors
 4) shell / 手工实现
 
 规则：
-- 做设计、查资料、看文档、看页面、查知识库、写回外部系统时，优先调用现有 MCP / skills / plugins / apps。
-- 能用权威工具直接完成时，不重复手写中间数据。
-- 工具不可用、无权限、结果不可靠时，才回退到本地命令或手工处理。
-- 选择工具时优先“已安装且当前项目可直接使用”的能力，而不是重新造流程。
-- 查看 Jenkins、知识库、设计稿、页面、缺陷系统时，优先使用现成的连接器或 MCP，而不是手工拼接上下文。
+- 做设计、查资料、查文档、查 Jenkins、查页面、写回外部系统时，优先调用现成能力。
+- 工具不可用、权限不足、结果不可靠时，才回退到 shell 或手工流程。
+- 不重复手写工具已经能直接读取或写回的权威数据。
 
 ---
 
 ## 1.6 多 Agent 协作策略（Claude / Codex 专属）
 
-整个流程尽可能使用多 agent 模式并行推进。
+整个流程尽可能使用多 agent 并行推进。
 
 规则：
-- 任务开始后，优先拆分为可并行的子任务：设计补充、资料检索、实现分块、测试验证、文档回写、review。
-- 主 agent 负责关键路径：任务定义、方案裁决、代码集成、质量门禁、最终交付。
-- 子 agent 负责边界清晰、可独立推进的工作，完成后回收结果给主 agent 集成。
-- 如果某项工作会直接阻塞主路径且难以独立定义，不要机械拆分；由主 agent 保持控制。
-- 能并行就不要串行；能拆独立 write scope 就不要让多个 agent 写同一块内容。
+- 主 agent 负责任务定义、方案裁决、代码集成、轻量门禁、Jenkins/目标环境闭环、最终交付。
+- 子 agent 优先拆为：设计/调研、后端实现、前端实现、验证/文档。
+- 任务边界不清或需要强一致裁决时，由主 agent 保持控制，不机械拆分。
+
+---
+
+## 2. 标准流程（默认）
+
+1. 需求确认  
+   明确任务范围、影响服务、是否涉及 API/数据库/部署/Jenkins/前端页面。
+
+2. 最小设计记录  
+   普通小改动只更新 `taskbook` 或设计文档中的最小必要段落；跨模块、接口、数据库、部署、Jenkins、关键页面流程变更才补 DD。
+
+3. 开发实现  
+   只修改本次任务必要文件，不做无关重构。
+
+4. 本地轻量校验  
+   默认只跑：
+   - 编译 / build
+   - 单元测试或关键快速测试
+   - lint / typecheck
+   - API 文档检查
+   - Jenkinsfile / 脚本语法检查
+   - `git diff --check`
+
+5. 立即提交推送  
+   轻量校验通过后，commit + push，触发 Jenkins。
+
+6. Jenkins 验证  
+   查看 Jenkins 构建、镜像、部署结果；失败则根据 Jenkins 日志修复，再次提交推送。
+
+7. 目标环境验证  
+   在真实目标环境做健康检查、关键接口、关键页面或业务路径验证。
+
+8. 回归与证据记录  
+   只有真实执行过 Jenkins / 目标环境验证，或显式要求本地运行验证时，才允许把 `regression-matrix.md` 标为 `PASS`。
+
+9. 闭环记录  
+   每个任务必须留下轻量闭环记录：任务 ID、提交号、Jenkins Build URL、目标环境验证结果、是否通过、遗留问题。
+
+10. 配置入库  
+   `docs/ENGINEERING.md` 中保留下来的环境信息、前端/后端账号、Jenkins 账号与密码必须 100% 填写、正确填写，并提交 Git 作为项目权威配置持续维护。
 
 ---
 
-## 2. Gate 流水线（强制、不可跳过）
-
-Gate-1 读任务：只从 taskbook 取范围与验收；缺信息先补 taskbook  
-Gate-2 写DD：无DD禁止写代码；DD必须含 时序图/ER图/接口时序（Mermaid）  
-Gate-3 实现：严格按DD；接口变更必须同步 API Markdown  
-Gate-4 本地CI：后端必须通过 `commands.test`；前端至少通过 `commands.build`、`commands.lint`、`commands.typecheck`；前端自动化测试能力逐步补齐  
-Gate-5 静态分析+Review：静态分析通过；docs/reviews/ 生成记录  
-Gate-6 文档：更新 api.md + 追加 api-change-log.md  
-Gate-7 本地运行：必须用项目 Compose 启动本地 Docker 环境；失败先修复再继续  
-Gate-8 健康检查：本地容器启动后必须健康检查通过  
-Gate-9 全量回归：按 API Markdown 对本地 Compose 环境全量回归；回归矩阵仅可在真实执行后标记 PASS，且必须附证据；发现问题必须写 bug-list 并新增自动化回归用例  
-Gate-10 Jenkins 准备：Jenkinsfile、Job 配置、镜像仓库策略必须可用  
-Gate-11 任务总结：必须生成 docs/tasks/summaries/<TASK_ID>.md  
-Gate-12 提交触发：本地门禁全过且临时产物已清理后，才允许 commit+push  
-Gate-13 流水线验证：push 后必须确认 Jenkins 自动构建、镜像发布、目标环境更新成功  
-Gate-14 完成：生产健康检查通过并补齐部署记录后，任务才完成
+## 3. 高风险变更（必须补强验证）
+
+以下类型默认视为高风险变更：
+- 数据库迁移
+- 鉴权 / 权限
+- 支付 / 订单
+- 部署 / Jenkins
+- Nginx / 网关
+- 文件上传 / 下载
+- 生产配置
+
+高风险变更至少额外要求：
+- 明确 DD
+- 目标环境真实验证
+- 闭环记录写清楚验证路径和结果
+- 必要时补 summary / deployment record / regression matrix
+
+---
+
+## 4. 本地 Docker 与完整回归（按需，不默认）
+
+以下能力保留，但仅用于显式要求、问题复现、Jenkins/目标环境问题前置诊断：
+- `runtime-up`
+- `runtime-down`
+- 本地 health check
+- 本地 `smoke`
+- 本地 `regression`
+- `check-matrix`
+- `gen-summary`
+
+默认情况下，不把它们作为每个小改动的固定门禁。
 
 ---
 
-## 3. Repo 工具入口
+## 5. Repo 工具入口
 
-统一用 `python3 docs/tools/autopipeline/ap.py <command>` 执行。
+统一使用：
+- `python3 docs/tools/autopipeline/ap.py doctor`
+- `python3 docs/tools/autopipeline/ap.py light-gate`
+- `python3 docs/tools/autopipeline/ap.py verify-jenkins-build ...`
+- `python3 docs/tools/autopipeline/ap.py wait-health --scope target`
+- `python3 docs/tools/autopipeline/ap.py verify-target ...`
+- `python3 docs/tools/autopipeline/ap.py record-closure <TASK_ID> ...`
 
-补充：
-- `commands.smoke` / `commands.regression` 可以封装 repo 脚本，但必须真正在本地运行目标系统。
-- `docs/testing/regression-matrix.md` 中的 `PASS` 只在真实执行并填入证据后允许保留；占位符证据会被视为未完成。
+说明：
+- `doctor`：检查默认流程必填项和常见配置错误。
+- `light-gate`：默认轻量门禁。
+- `verify-target`：目标环境健康检查 + 按需关键 API / 页面验证。
+- `record-closure`：默认轻量闭环记录。
+- `check-matrix`、`gen-summary`、`runtime-up/down`：保留为按需工具。

package/cli/assets/skill/data/templates/bridges/CLAUDE.md

@@ -1,4 +1,5 @@
-Follow docs/ENGINEERING.md strictly. Source of truth: docs/ENGINEERING.md.
+Follow `docs/ENGINEERING.md` strictly. Source of truth: `docs/ENGINEERING.md`.
 Prefer already available MCP servers, installed skills, plugins, and app connectors during design, research, verification, and documentation workflows.
 Prefer multi-agent mode whenever the task can be split into independent parallel subtasks without weakening integration control.
-For Go monorepo + Jenkins projects, local Docker Compose validation must pass before commit, and push is expected to trigger Jenkins pipeline verification.
+Default to the lightweight local gate first, then use Jenkins build verification and real target-environment verification as the primary completion gate.
+Local Docker Compose and full local regression are on-demand diagnostic tools, not the default gate for every small change.

package/cli/assets/skill/data/templates/bridges/CODEX.md

@@ -1,4 +1,5 @@
-Follow docs/ENGINEERING.md strictly. Source of truth: docs/ENGINEERING.md.
+Follow `docs/ENGINEERING.md` strictly. Source of truth: `docs/ENGINEERING.md`.
 Prefer already available MCP servers, installed skills, plugins, and app connectors during design, research, verification, and documentation workflows.
 Prefer multi-agent mode whenever the task can be split into independent parallel subtasks without weakening integration control.
-For Go monorepo + Jenkins projects, local Docker Compose validation must pass before commit, and push is expected to trigger Jenkins pipeline verification.
+Default to the lightweight local gate first, then use Jenkins build verification and real target-environment verification as the primary completion gate.
+Local Docker Compose and full local regression are on-demand diagnostic tools, not the default gate for every small change.

package/cli/assets/skill/data/templates/docs/deployment/deploy-records/_TEMPLATE-DEPLOY-RECORD.md

@@ -1,28 +1,19 @@
 # Deploy Record — <Task ID> — YYYY-MM-DD
 
-## 1. Local Compose Validation
-- Docker compose file:
-- Docker service:
-- Container name:
-- Image/tag:
-- Exposed port:
-- Env file:
-- Local health URL:
+> 仅在真实需要独立部署审计记录时使用。
 
-## 2. Jenkins Pipeline
-- Jenkins job name:
-- Jenkins build number:
-- Jenkins build URL:
-- Trigger branch:
-- Trigger commit:
-- Image repository:
-- Published image tag:
-- Deploy environment:
+## 1. Deployment Context
+- Task ID:
+- Commit:
+- Jenkins Build:
+- Target Env:
 
-## 3. Evidence
-- docker ps / compose ps:
-- local_health_check:
-- smoke_test:
-- api_regression:
-- jenkins_result:
-- production_health_check:
+## 2. Verification
+- Health check:
+- Key API:
+- Key page / business path:
+
+## 3. Notes
+- Risk:
+- Rollback:
+- Follow-up:

package/cli/assets/skill/data/templates/docs/deployment/deploy-runbook.md

@@ -1,19 +1,11 @@
-# Deployment Runbook（本地 Compose 验证 + Jenkins 自动部署）
+# Deployment Runbook（按需使用，不是默认小改动产物）
 
-统一读取：`docs/ENGINEERING.md` frontmatter
-- `runtime.*`：本地 Compose 启动与健康检查
-- `jenkins.*`：Jenkins Job、镜像仓库、目标环境、生产健康检查
+用途：
+- 手工部署
+- 高风险发布
+- 需要额外审计证据的发布
 
-执行顺序：
-1. 本地构建、测试、lint、typecheck 通过
-2. 本地 `docker compose` 启动目标服务
-3. 本地 health / smoke / regression 全部通过
-4. `commit + push`
-5. Jenkins 自动触发，完成镜像构建、镜像推送、目标环境更新
-6. 检查 Jenkins 结果与目标环境健康状态
-
-完成条件：
-- 本地 Compose 验证通过
-- Jenkins Pipeline 成功
-- 目标环境健康检查通过
-- `docs/deployment/deploy-records/<TASK_ID>-YYYYMMDD.md` 证据补齐
+默认情况下：
+- 小改动直接走 Jenkins 自动构建与自动部署
+- 主要闭环证据写入 `docs/tasks/closure-log.md`
+- 只有需要更重的发布审计时，才补本目录文档

package/cli/assets/skill/data/templates/docs/reviews/_TEMPLATE-REVIEW.md

@@ -1,16 +1,25 @@
 # Review — <Task ID> — YYYY-MM-DD HH:MM
 
-## 1. 静态分析结果（必须）
-- Command：lint + typecheck（来自 docs/ENGINEERING.md frontmatter）
+> 仅在任务需要独立 review 记录时使用；不是每个小改动的默认强制文档。
+
+## 1. 静态分析结果
+- Command：lint / typecheck / script_syntax / diff_check
 - Summary：
 - Issues：
-- Resolved/Deferred（deferred 必须给出后续任务）：
 
-## 2. 代码质量
-## 3. 本地构建与测试质量（后端 test + 前端 build/lint/typecheck）
-## 4. 本地 Compose 验证（health / smoke / regression）
-## 5. 接口契约（API Markdown + change-log）
-## 6. Jenkins 准备度（Jenkinsfile / job config / image strategy）
-## 7. 安全与性能
-## 8. 风险与回滚
-## 9. 结论（Pass / Blocked）
+## 2. 本地轻量校验
+- build：
+- test or quick_test：
+- api docs：
+- jenkinsfile / scripts：
+
+## 3. 按需本地运行验证（如果有）
+- runtime-up / health / smoke / regression：
+
+## 4. Jenkins 与目标环境
+- Jenkins readiness：
+- Target env verification：
+
+## 5. 风险与结论
+- Risk：
+- Conclusion：Pass / Blocked