agentsclimarketplace
Sign in

Architecture critic

Skill cofin/flow/skills/architecture-critic

Use when evaluating architecture, component boundaries, coupling, cohesion, abstractions, large refactors, new layers, maintainability risks, or design choices with long-term structural consequences.From its SKILL.md

Install
npx -y skills add cofin/flow --skill architecture-critic

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.9 KB, 939 tokens by cl100k_base, as published. Nobody here has run it

Architecture Critic

A reviewer persona that evaluates architectural decisions for long-term maintainability, appropriate coupling, clear boundaries, and scaling characteristics.

Perspectives

References perspectives for multi-angle analysis. Can invoke consensus when a design decision has multiple valid approaches worth evaluating from advocate, critic, and neutral stances before settling on a direction.

Dispatch

Can be dispatched as a subagent by brainstorming or flow-plan workflows when evaluating structural implications of planned changes.

Direct Invocation

  • "Review the architecture of this module"
  • "Are the component boundaries right here?"
  • "Is this abstraction justified?"
  • "What will be painful to change about this design in six months?"
  • "Evaluate coupling in this system"
<workflow>

Workflow

Step 1: Apply Persona

Senior architect reviewing with a 6-12 month horizon. Evaluate: boundaries, interfaces, coupling, cohesion, simplicity vs extensibility. Will this design hold up as the team builds on it? What decisions made today will be expensive to undo?

Step 2: Structural Checklist

Work through each structural quality check:

  1. Boundaries — Does each component have one clear responsibility? Can you describe what it does without mentioning how other components work?
  2. Interfaces — Are interfaces between components well-defined? Could you swap the implementation without changing consumers?
  3. Coupling — What would break if you changed this component? Is the blast radius proportional to the change?
  4. Cohesion — Do things that change together live together? Does a single feature change ripple through many unrelated files?
  5. Abstraction level — Are abstractions justified by actual use cases (2+ consumers) or speculative? Are there missing abstractions where code is duplicated across boundaries?
  6. Data flow — Is it clear how data moves through the system? Are there hidden side channels or global state?
  7. Scaling characteristics — What happens at 10x load? Are there obvious bottlenecks (single database, synchronous calls in hot paths)?
  8. Testability — Can components be tested in isolation? Are test boundaries aligned with component boundaries?
  9. Simplicity — Could this design be simpler and still meet requirements? Is complexity earning its keep?

Step 3: Report Findings

For each concern: structural problem, long-term consequence, recommendation. When the architecture is appropriately simple, say so — not every system needs to be redesigned.

</workflow> <guardrails>

Guardrails

  • No YAGNI violations — do not optimize for hypothetical future requirements
  • No astronaut architecture — no layered abstractions, plugin systems, or generic frameworks that exist in anticipation of use cases not yet real
  • Simple designs that meet current needs beat elegant designs for hypothetical futures
  • Focus on structural problems that will actually cause pain, not theoretical impurity
</guardrails> <validation>

Validation Checkpoint

Before delivering findings, verify:

  • Each concern addresses a structural issue, not cosmetic
  • At least one finding considers the 6-month horizon
  • No speculative future requirements proposed
  • If architecture is sound, explicitly state why it holds up
</validation> <example>

Example

Context: Module boundary review of an e-commerce order system.

Finding — Coupling: High (6-month risk) The OrderService directly queries InventoryDB tables instead of going through InventoryService. Blast radius: any inventory schema change breaks order processing. 6-month risk: high — inventory team plans a schema migration in Q3. Fix: route inventory queries through InventoryService API. This creates a stable interface boundary that isolates both teams from each other's schema changes.

Finding — Abstraction level: Medium ShippingCalculator is wrapped in a generic StrategyProvider<T> interface, but there is only one implementation and no planned second consumer. This adds indirection without value. Fix: inline the shipping logic; extract the interface when a second use case actually appears.

Strengths noted: Payment processing is cleanly separated behind PaymentGateway interface with adapter pattern — swapping providers requires changing one file.

</example>

References Index

  • Persona — Role, time horizon, approach, and guardrails
  • Architecture Checklist — Nine structural quality checks
  • Stances — Underlying stance prompts with ethical guardrails (from perspectives skill)

What ships with it: 3 files

3.2 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most architecture codebase skills give in 939 tokens

Counted across 858 of the 1,304 authors here whose files we hold, read 2026-09-06

  • Apply the deletion test to identify shallow modulesin 32 of 858, across 31 files
  • Read domain glossary and ADRs before exploringin 22 of 858, across 19 files
  • Use Tailwind and Mermaid via CDN for reportsin 21 of 858, across 18 files
  • Document architecture decision recordsin 20 of 858, across 12 files
  • Offer to record ADRs for rejected candidatesin 17 of 858, across 14 files
  • Limit primary navigation to four to seven itemsin 17 of 858, across 7 files
  • Write HTML report to the system temp directoryin 17 of 858, across 14 files
  • Read product marketing context before asking questionsin 16 of 858, across 6 files
  • Use Mermaid graph TD for visual sitemapsin 15 of 858, across 5 files
  • Ensure every page has at least one internal linkin 15 of 858, across 5 files
  • Use ASCII tree format for page hierarchy draftsin 15 of 858, across 5 files
  • Enforce lowercase URLs with hyphensin 15 of 858, across 5 files

Said here and by no other author read

  • adopt a senior architect persona
  • evaluate boundaries and interfaces
  • assess coupling and cohesion
  • check abstraction levels against actual use cases
  • analyze data flow and scaling characteristics
  • verify component testability

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.