two-axis-review
Use from the canonical review skill when reviewing changes since a fixed point against standards and spec.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Use from the canonical review skill when reviewing changes since a fixed point against standards and spec.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Turn a loose idea into a sequenced map of investigation tickets, then drive them to resolution one at a time.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Use when creating, designing, writing, implementing, auditing, reviewing, improving, or optimizing conversion-focused landing pages, including PPC, lead generation, SaaS, ecommerce offer, signup, demo, trial, download, local-service, and campaign pages.
Use when something is broken, failing, slow, throwing, flaky, or behaving unexpectedly.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Anti-AI-slop design skill for greenfield pages, audits, redesigns, and design extraction from URLs or screenshots. Use when the user asks to build a new app or landing page, wants to redesign something, invokes Hallmark by name, or uses audit/redesign/study.
| name | two-axis-review |
| description | Use from the canonical review skill when reviewing changes since a fixed point against standards and spec. |
Review the diff between HEAD and a fixed point along two separate axes:
Keep the axes separate so one does not mask the other.
git diff <fixed-point>...HEAD and
git log <fixed-point>..HEAD --oneline.CODING_STANDARDS.md, CONTRIBUTING.md,
AGENTS.md, or relevant docs under docs/.## Standards and ## Spec. Do not merge or rerank
the axes.Report every place the diff violates a documented standard. Cite the standard file and rule. Distinguish hard violations from judgment calls. Skip anything tooling enforces.
Report missing or partial requirements, unrequested behavior, and requirements that look implemented incorrectly. Quote or cite the spec line for each finding.
Done when both axes have reported findings or explicitly reported no findings, and the final summary names the worst issue within each axis.