一键导入
spec-compliance
Phase 1 of code review: verify the implementation matches the architect's design document exactly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Phase 1 of code review: verify the implementation matches the architect's design document exactly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this skill after problem framing to produce a locked architecture document. Creates data flow diagrams, state machines, error paths, test matrices, and bite-sized task breakdowns.
Design + accessibility skill for ASU UI work (WCAG 2.1 AA). Use when designing, building, or reviewing any ASU component or page in Unity or Webspark. Covers semantics/landmarks, keyboard + focus, contrast, reflow at 320px, forced-colors mode, labels/forms, and a pre-delivery checklist. Prefer Unity/Bootstrap components over hand-rolled div+ARIA.
Evaluate code structure, maintainability, and engineering standards alongside adversarial review.
Phase 3 of code review: run tests, verify behavior, check edge cases, confirm no regressions.
Use during REVIEW to compare a rendered UI component against its design references (screenshots in .intake/ and/or the Figma frame). Drives a running Storybook (Unity) or local Webspark page with agent-browser to screenshot the build at multiple viewports, then reports P1/P2/P3 visual-fidelity findings to .pipeline/visual-report.md. Used by the acp-visual agent.
Use at the END of the Unity stage to enforce the PR-ready gate and write the cross-stage handoff. Defines the gate (build+lint, Storybook story + interaction/a11y tests, HTML-parity) and writes handoff.json (+ markup.html) to the shared peer handoff/ directory, keyed by Jira key or component slug, for the Webspark stage to consume. Validate with .kiro/scripts/validate-handoff.sh.
| name | spec-compliance |
| description | Phase 1 of code review: verify the implementation matches the architect's design document exactly. |
Compare the implementation against the design document line by line.
PASS or SPEC_GAPS with file:line references for each gap.
If SPEC_GAPS found → report immediately. Do not proceed to Phase 2 until Phase 1 passes. You cannot review the quality of code that solves the wrong problem.
For each test matrix row, verify:
If the implementation uses mocks where the design specified real/fake/stub, report SPEC_GAP. If the implementation adds interfaces not in the design, report SPEC_GAP unless justified by a design amendment.