<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

dual-axis-review

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Catch both craft defects and product drift by keeping standards findings separate from missing, creeping, or wrong behavior relative to the agreed spec.

Required inputs

• Diff fixed point (three-dot range or stated base), the governing spec or acceptance criteria, and repository standards docs.
• Subagent support for parallel readonly review lanes.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Freeze the diff range; do not review uncommitted noise unless the user asks.
2. Run two parallel readonly lanes: Standards (AGENTS.md, architecture rules, obvious maintainability risks) and Spec (missing behavior, scope creep, incorrect behavior).
3. Aggregate findings side by side; never merge or rerank across axes into a single score.
4. Lead judgment: Act on / Consider / Noted / Dismissed per finding with a one-line reason.
5. Return blockers separately from nits; do not auto-apply fixes unless the user requests a follow-up pass.

Output contract

• Two-column or two-section findings: Standards versus Spec.
• Judgment buckets and explicit merge/block recommendation.
• Pointers to spec sections and files; no rewritten history of the review brief.

Guardrails

• Do not collapse the axes into one ranked list.
• Do not treat style nits as spec failures or vice versa.
• Do not approve when acceptance criteria remain unmet.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.