home / skills / ntcoding / claude-skillz / architect-refine-critique

architect-refine-critique skill

safe

This skill orchestrates a three-phase design review by chaining architect, refiner, and critique agents to formulate and validate architecture decisions.

npx playbooks add skill ntcoding/claude-skillz --skill architect-refine-critique

Review the files below or copy the command above to add this skill to your agents.

Files (7)

SKILL.md

840 B

---
name: architect-refine-critique
description: "Three-phase design review. Chain architect → refiner → critique subagents. Triggers on: 'design review', 'architecture review', '/arc', system design proposals, significant refactoring decisions, new service or module design."
version: 1.3.6
---

# Architect-Refine-Critique

Chain three subagents sequentially from the main conversation.

## Usage

`/arc [name] [target]`

## Execution

Use the architect subagent to create the initial design for [target] with name=[name],
then use the refiner subagent to improve the design with name=[name],
then use the critique subagent to challenge the design with name=[name].

After all three complete, tell the user: "Run `/arc-review [name]` to discuss findings."

Do not analyze. Do not summarize. Do not add value. Just chain and hand off.

Overview

This skill runs a three-phase design review pipeline by chaining an architect, a refiner, and a critique subagent. It orchestrates sequential handoffs so each subagent focuses on one stage: initial design, improvement, and critical challenge. The goal is a structured, repeatable review cycle for system and module designs.

How this skill works

When invoked, the architect subagent generates an initial design for the specified target and name. The refiner subagent receives that design and produces an improved, more detailed version. The critique subagent then challenges assumptions, finds risks, and surfaces gaps. After the chain completes, the skill prompts the user to run a follow-up review command to discuss findings.

When to use it

Preparing or documenting a new service, module, or API design
Before approving significant refactors or architecture changes
During design syncs to get a structured second opinion
When drafting system design proposals for stakeholders
To validate or stress-test an existing design before implementation

Best practices

Provide a clear name and concise target description when invoking the pipeline
Include context such as goals, constraints, and expected traffic or load
Run iterative cycles: refine inputs based on critique and re-run the pipeline
Keep each invocation focused on a single design boundary to avoid noisy outputs
Use the follow-up review command to discuss and prioritize critique findings

Example use cases

Designing a new microservice and validating data flow and scaling considerations
Refactoring an authentication module and checking for security regressions
Drafting an integration pattern between services and surfacing failure modes
Creating a proposal for a new feature and getting a structured improvement pass
Validating trade-offs and deployment strategies before sprint planning

FAQ

What inputs does the pipeline require?

A short name and a clear target description. Include goals, constraints, and any nonfunctional requirements for best results.

How do I act on the outputs?

Run the follow-up review command to discuss findings, then iterate: update the design, re-run the pipeline, and track changes until satisfied.

Can I skip stages or run them independently?

The skill is designed for the full three-stage flow. For focused work, run the corresponding subagent directly if available.