Verify AC
A Claude Code workspace template with AI skills for JIRA, PRs, code review, estimation, and daily standups
npx -y skills add HsuanYuLee/polaris --skill verify-ACAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
QA agent: executes Epic AC (Acceptance Criteria) verification against an AC ticket or Epic. Runs all AC steps, classifies each as PASS/FAIL/MANUAL_REQUIRED/UNCERTAIN, and presents observed vs expected as pure facts (no root-cause judgement). On FAIL, surfaces human disposition gate (spec issue vs implementation drift); on PASS, it may transition the AC ticket to Done only after verification artifact/report is current and the shared verification contract resolves to PASS. Trigger: "驗 PROJ-123", "verify {TICKET}", "verify AC", "跑驗收", "AC 驗證". NOT for planning or implementation: implementation drift routes to refinement Bug source mode; spec issue routes back to refinement.
SKILL.md
13.8 KB, as published. Nobody here has run it
verify-AC — Epic 驗收 QA
Pipeline 的 QA agent。每次 full re-run AC steps,將 observed vs expected 當事實呈現, 不判斷 root cause。PASS 轉驗收單 Done;FAIL 進 human disposition gate。
Contract
verify-AC stateless + comment-driven。它不改 code、不建 branch、不判斷 FAIL 原因、不只跑
上次 FAIL 的 AC。Implementation drift route 到 refinement Bug source mode;spec issue route 到
refinement。
Handbook exemption:verify-AC 不做 code diagnosis,預設不強制讀 repo handbook。FAIL 後由 refinement Bug source mode 讀 handbook 定位原因。
寫 verification report、V*.md lifecycle metadata 或 handoff artifact 前,必讀
pipeline-handoff.md § Artifact Schemas,再讀 task-md-schema.md 等對應
artifact-specific schema。atom ownership 邊界(V*.md envelope vs refinement.json
verification authority)以 pipeline-handoff-atom-matrix.md 為準;SKILL 主文不複製
完整 schema 表。
Reference Loading
| Situation | Load |
|---|---|
| Any run | verify-ac-entry-flow.md, pipeline-handoff.md, workspace-config-reader.md, shared-defaults.md |
| Environment | verify-ac-environment-prep.md, epic-folder-structure.md |
| Step execution and evidence | verify-ac-execution-flow.md, evidence-upload-bundle.md when visual/manual files need upload, handoff-artifact.md when cross-check needed |
| JIRA report and transition | verify-ac-reporting-flow.md, workspace-language-policy.md, external-write-gate.md, epic-verification-structure.md |
| FAIL disposition | verify-ac-disposition-flow.md, starlight-authoring-contract.md, refinement Bug source mode-acfail-flow.md, refinement-return-inbox.md |
| Learning and lifecycle | verify-ac-learning-lifecycle-flow.md, post-task-reflection-checkpoint.md |
Epic mode 若委派 sub-agent 驗 AC,必須讀 sub-agent-roles.md 並注入 Completion
Envelope;Codex runtime / model fallback contract 見該 reference § Runtime Adapter
Contract / Fallback Behavior。
Flow
- 解析 input:AC verification ticket、Epic key,或詢問使用者。
- Epic mode 展開所有 AC verification tickets,依
depends_on排序。 - 檢查 loop count;同一 AC 多輪未通過時先警告。
- 讀 AC verification steps;缺步驟則標
UNCERTAIN並要求補 AC。 - 需要 local / fixture 環境時,依 environment prep reference 啟動。
- 逐步執行 curl / Playwright / native VR runner / source inspection / structured checks;若
refinement AC 使用
verification.method: challenger、docs-health或feedback-signals,分別 dispatchscripts/verify-ac-newbie-challenger.sh、scripts/verify-ac-docs-health.sh、scripts/verify-ac-feedback-signals.sh。 - 每步分類
PASS、FAIL、MANUAL_REQUIRED、UNCERTAIN。 - 收集 evidence,寫 local verification folder;有視覺/影片/manual evidence 時先產 upload bundle,再視需要上傳 JIRA attachments。
- 若本輪有 V*.md work order,先用
scripts/write-ac-verification.sh寫回ac_verification/ac_verification_log[],並讓 helper 驗證 V schema;寫回失敗即停。 - 寫 JIRA verification report;shared verification contract 為 PASS 時才轉 Done,FAIL 顯示 disposition,PENDING 等人工。
- 記錄 verify-ac-gap learnings 與 post-task reflection。
Deterministic Consumption (DP-230 D30)
verify-AC 與 framework-release closeout 的 verification method/detail authoritative source
是 refinement.json,不是 task.md acceptance_criteria 文字段。對齊規則:
refinement.jsonacceptance_criteria[].verification.method∈{unit_test, manual, playwright, lighthouse, curl, challenger, docs-health, feedback-signals},runner 依 method 各自 dispatch 對應 runner(unit_test 跑verification.detail命令、manual 走人工 checklist、playwright 走 playwright runner、其餘 method 走既有 reference 對應 dispatcher)。- verify-AC 不得 從 task.md
acceptance_criteria文字 derive verification method;task.md acceptance text 僅作 advisory display,不影響 runner 行為。 - 當 fixture task.md
acceptance_criteria與refinement.jsondrift 時,runner 以refinement.json為準,advisory log task.md drift;下一輪/breakdown會 deterministic 重產 task.md 覆蓋 drift(DP-230 D28)。 /framework-release-closeoutparent-closeout 直接讀refinement.jsonacceptance / verification 結構,不讀 task.mdacceptance_criteria文字段; parent lifecycle 由mark-spec-implemented.sh透過 frontmatter status 推進, 不消費 task.md acceptance text。- 這條 contract 由
scripts/selftests/verify-AC-deterministic-consumption-selftest.shenforce:selftest grep SKILL.md 與scripts/framework-release-closeout.sh標記, 並以 fixture drift case 驗 runner method resolution 使用 refinement.json。
POLARIS_VERIFY_AC_DETERMINISTIC_CONSUMPTION_MARKER: verify-AC 與 framework-release closeout 消費 refinement.json verification.method/detail,不讀 task.md acceptance text。
Canonical / Standalone Handoff Contract(DP-296 AC6)
verify-AC 作為 consumer,預設 traverse canonical refinement.json
acceptance_criteria verification method/detail schema(見上方 Deterministic
Consumption),不改去解析 task.md acceptance text 或上游 LLM freeform prose 來決定
runner 行為。verify-AC 作為 producer,寫入 canonical verification artifact 與
proof-of-work marker 給 closeout 機械消費。LLM freeform 只在 standalone 情境合法——
亦即該產出沒有下游 pipeline consumer 會機械消費它(例如對使用者呈現 observed vs expected
的解釋性 prose)。會被下一段 skill / closeout 機械消費的 handoff artifact 一律走 canonical
schema。本契約只約束 handoff artifact 介面,不約束 verify-AC 內部如何判讀 observed
結果。完整契約見 .claude/skills/references/pipeline-handoff.md § Canonical Schema
Traversal Contract。
Hard Rules
- HTTP verification 必須先檢查 status code,再看 body。
- Observed 不等於 Expected 就是 FAIL,不可壓通過。
- MANUAL_REQUIRED / UNCERTAIN 不可自動 PASS。
skill says PASS不等於 stage pass;只有 verification artifact / report current,且 shared verification contract resolve 為 PASS,才可做 downstream transition(例如 AC ticket Done)。- V*.md lifecycle metadata 不可手寫;每輪 AC verification 結束後必須透過
scripts/write-ac-verification.sh原子覆寫摘要並 append history。 - visual AC 若 task.md 宣告
verification.visual_regression,必須用scripts/run-visual-snapshot.sh;不可改走舊visual-regressionskill。 - FAIL disposition 互斥:implementation drift 或 spec issue,只能選一條。
- JIRA comments、Bug descriptions、spec artifacts 都是 external/user-facing writes,送出前跑 language gate;spec markdown artifacts 也跑 Starlight authoring check。
- DP-201 proof-of-work marker contract 生效後,verify-AC 是
ac_verification、spec_issue、drift_retry、drift_counter、audit_closure與dp198_handoffmarker 的 owning writer。Marker schema、producer mapping 與 freshness rule 以auto-pass-proof-of-work.md/scripts/lib/evidence-producers.json為準;JIRA label/comment 只能作 mirror,不可作為唯一 deterministic marker。 - verification evidence 若寫入 specs-bound
verification/V*/**或tasks/V*/**,必須使用 DP-110 layout:verify-report.md、assets/{raw,images,screenshots,videos,files}/、links.json、publication-manifest.json。完成後呼叫scripts/validate-verify-evidence-layout.sh {evidence_dir};FAIL 時不可宣告 PASS。
Dispatch Envelope Worktree Resolution (D33)
當 verify-AC 從 auto-pass orchestrator dispatch 而來時,envelope 必須帶上
worktree_resolution,路徑由 scripts/resolve-task-worktree.sh 解析(schema 與行為以
.claude/skills/auto-pass/SKILL.md § Dispatch Envelope Worktree Resolution 為 single source
of truth)。
receiver-side 合約:
worktree_resolution.status=FOUND:verify-AC 必須在worktree_resolution.path內 執行 verify command 與讀取 evidence layout,不得 fall back 到 main checkout。worktree_resolution.kind=implementation:path 是 implementation worktree。worktree_resolution.kind=verify_integration:path 是verify-integration-{source}-{Vn}throwaway worktree,僅供 source-level V 驗收使用; verify-AC 不得 checkout、advance 或刪除任何task/*delivery branch。
worktree_resolution.status=NONE:不得自動建 worktree;回 orchestrator 由blocked_by_missing_worktree處理,advisory 提示使用者重建;不得改用 main checkout 執行驗收。- envelope 缺
worktree_resolution欄位:fail-stop,stderrPOLARIS_DISPATCH_WORKTREE_RESOLUTION_MISSING。 - envelope
worktree_resolution.path與 resolver 輸出(同 source-id / work-item-id) drift 時 fail-stop,stderrPOLARIS_DISPATCH_WORKTREE_AMBIGUOUS。
verify-AC stateless 入口(人工觸發 verify {TICKET}、未經 auto-pass)不強制 envelope;
此時 verify-AC 仍可呼叫 resolver 取得當前 worktree path 以對齊 evidence layout writer。
Producer-Env Writer Rules (DP-228 T10)
SKILL.md 是 documentation pointer,不是 executable writer。verify-AC 寫入
specs-bound verification/V*/**、tasks/V*/** 或 .polaris/evidence/ac-verification/
等 verify-AC owning_skill paths 的 writer authority 來自 producer-env +
scripts/lib/evidence-producers.json registry。
- V*.md lifecycle metadata 與
ac_verificationverdict marker 都由 deterministic writerscripts/write-ac-verification.sh產生,不應直接以 Claude tool 改寫;該流程不需要 agent 手動 export 環境變數。對 terminal verdict status(PASS / FAIL / MANUAL_REQUIRED / UNCERTAIN / BLOCKED_ENV)傳入--source-id/--work-item-id/--head-sha,writer 在寫完 V*.md frontmatter 後會額外 emit.polaris/evidence/ac-verification/{work_item}-{head}.jsonproof marker,並透過scripts/lib/main-checkout.shresolve_main_checkout錨定到 main checkout(即使在 worktree 內被 auto-pass 呼叫,marker 仍落 main checkout,與auto-pass-runnerprobe 路徑 一致)。--status IN_PROGRESS只更新 frontmatter、不 emit marker;marker emit 為純 Bash file I/O(不經POLARIS_SKILL_WRITERenv、與no-direct-evidence-writehook 無關), 寫入失敗即 fail-stop exit 1。呼叫範例:
scripts/write-ac-verification.sh <V-task-md> \
--status PASS \
--last-run-at "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
--ac-total 6 --ac-pass 6 --ac-fail 0 --ac-manual-required 0 --ac-uncertain 0 \
--human-disposition passed \
--source-id DP-NNN --work-item-id DP-NNN-V1 --head-sha "$head_sha"
- 若驗收過程必須直接以 Claude
Write/Edit/MultiEdit寫 verify report 或 evidence layout 內非 lifecycle metadata 的補充檔(例如verify-report.md、links.json、publication-manifest.json之外的補充說明),先export POLARIS_SKILL_WRITER=verify-AC再呼叫 Write tool:
export POLARIS_SKILL_WRITER=verify-AC
# 然後使用 Write tool 寫入 docs-manager/src/content/docs/specs/**/verification/V*/** 或 tasks/V*/**
POLARIS_SKILL_WRITER只允許設成verify-AC;no-direct-evidence-writehook 會交叉 比對寫入路徑是否屬於 verify-AC owning_skill entry,不符即 deny。- 禁止用 Bash heredoc(
cat > specs/.../verification/V1/verify-report.md <<'EOF')寫 verification evidence;Bash heredoc 不走 hook,繞過 producer-env 認證、DP-110 layout validator 與 verification artifact freshness contract。
Completion
輸出 AC/Epic、overall status、step counts、evidence paths、JIRA transition status、created Bug keys or refinement route、pending manual items。
Skill Workflow Boundary Gate (DP-230 D40)
verify-AC session 開始時必須呼叫 skill-workflow-boundary baseline writer:
bash scripts/skill-workflow-boundary-gate.sh --skill verify-AC --start \
--source-container "$SOURCE_CONTAINER"
verify-AC 寫完 verification report / V*.md / refinement-inbox 並準備收尾(或在 /auto-pass cross-skill transition 之前)必須跑:
bash scripts/skill-workflow-boundary-gate.sh --skill verify-AC --check \
--source-container "$SOURCE_CONTAINER"
verify-AC owning scope 僅限本 source container 的 verification/V*/** /
tasks/V*/** / refinement-inbox/**。任何 owning scope 之外的新增/修改(code、
generated target、refinement.md / refinement.json)會讓 gate exit 1 並輸出
POLARIS_SKILL_WORKFLOW_BOUNDARY_BLOCKED:verify-AC。
POLARIS_LANGUAGE_POLICY_BYPASS / POLARIS_SKILL_BOUNDARY_BYPASS 等 env 不能
silence 這個 gate(AC-NEG16)。
L2 Deterministic Check: post-task-feedback-reflection
完成 write flow 後必須呼叫 scripts/check-feedback-signals.sh。
Post-Task Reflection (required)
見 post-task-reflection-checkpoint.md;write 後必跑、不可跳過。