I have two related suggestions for /code-review.

1. Add architecture/design as a third review axis

The current skill reviews changes along two independent axes:

• Spec: Did we implement the right thing?
• Standards: Did we implement it according to the repository's coding standards?

I think there is a third question worth reviewing independently:

• Design: Does the change improve or preserve the quality of the codebase's interfaces, modules, seams, locality, and testability?

A change can satisfy both the spec and the repository's coding standards while still making the codebase harder to maintain.

For example, it might:

• introduce a shallow pass-through module
• expose implementation complexity through a large interface
• create an abstraction or seam before anything actually varies
• spread related behavior across multiple callers and reduce locality
• make behavior difficult to verify through the module's public interface

These are not necessarily spec violations or coding-standard violations. They are design concerns.

Since the existing codebase-design skill already defines principles and shared vocabulary for evaluating these decisions, could /code-review use it as the basis for a separate Design or Architecture axis?

Keeping it separate would also preserve the reasoning behind the current two-axis structure: a design concern should not be presented as a coding-standard violation, and strong design should not hide a spec failure.

The result would be three independently reported perspectives:

## Spec

Did the implementation satisfy the requested behavior?

## Standards

Does the implementation follow documented repository conventions and the code-smell baseline?

## Design

Does the change preserve or improve module depth, interface simplicity, seam placement, locality, and testability?

2. Extract Spec and Standards verification into independently invocable skills

I also think the existing Spec and Standards axes would be useful as standalone skills rather than only as internal parts of /code-review.

I often want to invoke them independently.

For example, when reviewing legacy code that has already been merged, verified, and running in production, there may be no useful originating spec to validate. I still want to review the code against the repository's coding standards and smell baseline without running the full /code-review workflow.

The reverse can also be useful. Sometimes I only want to verify an implementation against a spec without requesting a broader code-quality review.

Could the individual review axes become independently invocable skills, with /code-review acting as the orchestrator?

Conceptually:

/code-review
├── /review-spec
├── /review-code-standards
└── /review-codebase-design

Each skill could accept the same diff or fixed-point scope and produce its own report. /code-review would invoke all applicable reviews in parallel and aggregate their results, preserving its current behavior while making each capability reusable on its own.

This would make the review model more composable:

• Use /code-review for a complete review of new work.
• Use /review-spec when correctness against requirements is the only concern.
• Use /review-code-standards for legacy code, existing production code, or focused maintainability reviews.
• Use the design review independently when evaluating module structure or refactoring opportunities.