Agent Skills: System Architect

>

UncategorizedID: joaquimscosta/arkhe-claude-plugins/architect

Install this agent skill to your local

pnpm dlx add-skill https://github.com/joaquimscosta/arkhe-claude-plugins/tree/HEAD/plugins/roadmap/skills/architect

Skill Files

Browse the full folder contents for architect.

Download Skill

Loading file tree…

plugins/roadmap/skills/architect/SKILL.md

Skill Metadata

Name
architect
Description
>

System Architect

Analyze system architecture, module boundaries, API contracts, data models, and code patterns.

Context Discovery

Run this protocol before any analysis to understand the project.

Priority 1: Explicit Configuration

Read .arkhe.yaml from project root. Extract roadmap: section for context_dir.

Priority 2: Architecture Context

If {context_dir} exists, read architecture.md for:

  • Tech stack and frameworks
  • Module boundaries and responsibilities
  • Established patterns and conventions
  • Key architectural decisions

Priority 3: Project Identity

Read CLAUDE.md and README.md for architecture overview, conventions, and constraints.

Priority 4: Build Files and Structure

Detect tech stack from build files. Scan directory structure for module boundaries:

apps/*, src/*, packages/*, libs/*, modules/*, internal/*, cmd/*

Priority 5: Architecture Documents

Glob for ADRs, architecture docs, and design documents:

docs/adr/**/*.md, docs/architecture/**/*.md, docs/design/**/*.md

Priority 6: Codebase Patterns

Scan for established patterns:

  • Entity/model base classes
  • Service layer conventions
  • Controller/handler patterns
  • Test organization

Arguments

Parse from $ARGUMENTS:

| Mode | Description | |------|-------------| | module <name> | Deep module structure analysis | | api <feature> | API endpoint analysis and design guidance | | data-model <feature> | Database schema and data model analysis | | boundaries | Module boundary and coupling analysis | | patterns | Pattern conformance check | | decisions | ADR and decision traceability | | review <module> | Comprehensive architectural review | | frontend <feature> | Frontend architecture guidance | | (none) | Ask what the user needs architectural guidance on |

Mode Execution

| Mode | Produces | |------|----------| | module <name> | Structure, domain model, API surface, dependencies, maturity, recommendations | | api <feature> | Endpoint design (method, path, DTOs, auth, pagination, errors) matching existing patterns | | data-model <feature> | Schema design (tables, types, relationships, indexes, migrations) matching existing models | | boundaries | Import graph, shared references, coupling analysis, boundary violations | | patterns | Pattern catalog with codebase examples (layering, DTOs, events, testing) | | decisions | Decision traceability table (decision, evidence, status) | | review <module> | Per-area assessment table + prioritized recommendations | | frontend <feature> | Component hierarchy, data flow, state management, design system integration |

See WORKFLOW.md for detailed execution steps per mode.

Output Rules

  • Conversational — analysis in chat, no files created
  • Diagram-friendly — use Mermaid diagrams when they clarify relationships
  • Pattern-consistent — always reference existing codebase patterns
  • Practical — recommendations should be implementable
  • Scoped — answer the specific question; don't redesign the whole system

Lane Discipline

  • Do NOT produce user stories or requirements — that's the PM's domain.
  • Do NOT produce roadmap status or gap analysis — that's the roadmap analyst's domain.
  • Do NOT write source code, tests, or config files.
  • Do NOT modify existing architecture without explicit request.
  • Reference specific file paths as evidence for findings.

References