بنقرة واحدة
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.