From dev-team
Orchestrates a component-architecture review to catch reusable components, duplicated UI patterns, prop drilling, and inconsistent component APIs. Advisory only.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-team:frontend-architecture [--path <dir>] [--since <ref>] [--all] [--json][--path <dir>] [--since <ref>] [--all] [--json]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Role: orchestrator. This command scopes the changeset to frontend component
Role: orchestrator. This command scopes the changeset to frontend component
files and dispatches the component-architecture-review agent, then aggregates
one report. It does not review files itself — it coordinates.
/code-review dispatches the same agent automatically whenever frontend
component files are in its target set, so ordinary reviews already carry this
lens. Use this command for a standalone, frontend-only pass (e.g. before
extracting a component library) or to scope beyond a diff.
This command is executed under orchestrator direction. Dispatch the agent with
its effort band (from its effort: frontmatter); the PreToolUse hook
hooks/agent_model_resolve.py resolves it to the active snapshot per the
Resolution Procedure in agents/orchestrator.md.
/apply-fixes or /build.a11y-review, framework reactivity to svelte-review
(and other framework agents), non-UI logic duplication and SRP/coupling to
structure-review/refactor-opportunity-review, and naming to
naming-review. When the same line belongs to one of those, drop it here.Arguments: $ARGUMENTS
Optional:
--path <dir>: target directory (default: current working directory)--since <ref>: target files changed since a git ref (git diff --name-only <ref>...HEAD)--all: review all frontend component files in the repository--json: emit the agent's aggregated JSON instead of prose (for CI)Same auto-scope logic as /code-review: review uncommitted changes if any
exist, else the full repository; honor --since, --path, and --all. Then
keep only frontend component files — .jsx, .tsx, .vue, .svelte, Angular
*.component.ts and their templates, and .js/.ts modules that render UI.
Exclude node_modules, dist, build, and test files.
If no frontend component files are in scope, emit
No frontend component files in scope — nothing to review. and stop.
Spawn component-architecture-review as a sub-agent in a single batch, passing
the in-scope files as full files (Context needs: full-file). It returns its
standard JSON (status/issues/summary). If it skips, report that and stop.
Take the agent's issues. Rank: semantic UI duplication and prop-drilling that
force multi-site edits first (error), then high-value extraction and
granularity fixes (warning), then composition and API-consistency cleanups
(suggestion). Group by file. Drop any finding that belongs to another agent
per constraint 3.
If --json, emit the aggregated JSON object and stop. Otherwise produce one
report (chat for a small target; reports/frontend-architecture-<date>.md for a
module):
## Frontend Architecture Review — <target>
**Health**: <pass|attention|critical> **Component files**: N **Findings**: N
### Findings (by severity)
| File:line | Issue | Severity | Suggested fix |
### Extraction & composition recommendations
<reusable components to extract, prop-drilling to lift, APIs to align, missing or
stale component-library `index` barrel to add — each with the concrete next edit>
### Next steps
- Mechanical fixes (extract component, call existing primitive) → /apply-fixes
- Larger refactors (lift state, recompose) → /plan or /build
Surface only what's actionable. If everything is clean, say so in one line.
npx claudepluginhub bdfinst/agentic-dev-team --plugin dev-teamReviews cross-cutting frontend architecture decisions (module boundaries, rendering topology, technology adoption) against a rewrite-averse, evidence-grounded standard, producing an ADR-quality verdict.
Maps frontend component tree, routing, state management, build config; assesses bundle size, deps, freshness, tests, TypeScript strictness. Use for 'understand this frontend' or 'UI built with'.
Reviews frontend code across 8 dimensions: architecture, type safety, accessibility, style, performance, testability, state management, and security. Outputs a graded report with blocking issues and recommendations.