Current State Assessment
Systematically assess an existing system or codebase to produce a clear picture of the current architecture, capabilities, and technical debt. This assessment drives the gap analysis that informs the target architecture.
Overview
No target architecture is designed in a vacuum. This skill documents what exists today — its strengths, its limitations, and the debt that will impede change — so that the target architecture is grounded in reality.
Assessment Process
Step 1: System Inventory
Catalogue what exists:
- Services and components: name, purpose, technology, age
- Data stores: type (RDBMS, NoSQL, cache, file), technology, approximate size
- Integrations: upstream/downstream systems, protocol (REST, gRPC, queue, file)
- Infrastructure: hosting (cloud provider, region, on-prem), container/VM, IaC maturity
- CI/CD: pipeline tools, deployment frequency, automation level
Read the codebase (if available) using Glob and Read to supplement what the user provides.
Step 2: Architecture Pattern Identification
Identify the dominant architectural pattern:
- Monolith (single deployable unit)
- Modular monolith (logical separation, single deployment)
- SOA (service-oriented, shared database common)
- Microservices (independent deployable services, independent data stores)
- Serverless (function-based, managed infrastructure)
- Event-driven (async messaging, event sourcing)
- Hybrid (combination)
Note whether the pattern is intentional or has evolved organically.
Step 3: Capability Assessment
Rate current capabilities:
| Capability |
Current State |
Maturity |
Notes |
| Scalability |
[description] |
Low/Med/High |
|
| Observability |
[description] |
Low/Med/High |
|
| Security |
[description] |
Low/Med/High |
|
| Testability |
[description] |
Low/Med/High |
|
| Deployability |
[description] |
Low/Med/High |
|
| Developer Experience |
[description] |
Low/Med/High |
|
Step 4: Technical Debt Register
| Item |
Category |
Severity |
Impact on Change |
Remediation Approach |
Effort |
| [debt item] |
Architecture/Code/Data/Ops |
Critical/High/Med/Low |
[how it blocks progress] |
[recommendation] |
S/M/L |
Categories:
- Architecture debt: structural decisions that limit scalability or change
- Code debt: poor quality code that is hard to maintain or test
- Data debt: schema problems, lack of data quality, no data contracts
- Operational debt: missing observability, manual processes, no runbooks
Step 5: Gap Analysis
Compare current state to typical requirements for the target state:
| Capability |
Current |
Required for Target |
Gap |
Priority |
| [capability] |
[current level] |
[required level] |
[description of gap] |
High/Med/Low |
Output Format
Produce a Current State Assessment document with:
- System inventory table
- Architecture pattern description + diagram (Mermaid text)
- Capability maturity table
- Technical debt register
- Gap analysis table
- Executive summary (3-5 bullet points on the most important findings)
Additional Resources
references/technical-debt-patterns.md — Common technical debt patterns and remediation strategiesassets/current-state-template.md — Blank assessment template
1---2name: current-state-assessment3description: This skill should be used when the user asks to "assess the current architecture", "document the existing system", "analyse the codebase", "identify technical debt", "review the legacy system", "produce a current-state report", or needs to understand what exists before designing a target architecture.4---56# Current State Assessment78Systematically assess an existing system or codebase to produce a clear picture of the current architecture, capabilities, and technical debt. This assessment drives the gap analysis that informs the target architecture.910## Overview1112No target architecture is designed in a vacuum. This skill documents what exists today — its strengths, its limitations, and the debt that will impede change — so that the target architecture is grounded in reality.1314## Assessment Process1516### Step 1: System Inventory1718Catalogue what exists:19- **Services and components**: name, purpose, technology, age20- **Data stores**: type (RDBMS, NoSQL, cache, file), technology, approximate size21- **Integrations**: upstream/downstream systems, protocol (REST, gRPC, queue, file)22- **Infrastructure**: hosting (cloud provider, region, on-prem), container/VM, IaC maturity23- **CI/CD**: pipeline tools, deployment frequency, automation level2425Read the codebase (if available) using Glob and Read to supplement what the user provides.2627### Step 2: Architecture Pattern Identification2829Identify the dominant architectural pattern:30- Monolith (single deployable unit)31- Modular monolith (logical separation, single deployment)32- SOA (service-oriented, shared database common)33- Microservices (independent deployable services, independent data stores)34- Serverless (function-based, managed infrastructure)35- Event-driven (async messaging, event sourcing)36- Hybrid (combination)3738Note whether the pattern is intentional or has evolved organically.3940### Step 3: Capability Assessment4142Rate current capabilities:4344| Capability | Current State | Maturity | Notes |45|---|---|---|---|46| Scalability | [description] | Low/Med/High | |47| Observability | [description] | Low/Med/High | |48| Security | [description] | Low/Med/High | |49| Testability | [description] | Low/Med/High | |50| Deployability | [description] | Low/Med/High | |51| Developer Experience | [description] | Low/Med/High | |5253### Step 4: Technical Debt Register5455| Item | Category | Severity | Impact on Change | Remediation Approach | Effort |56|---|---|---|---|---|---|57| [debt item] | Architecture/Code/Data/Ops | Critical/High/Med/Low | [how it blocks progress] | [recommendation] | S/M/L |5859Categories:60- **Architecture debt**: structural decisions that limit scalability or change61- **Code debt**: poor quality code that is hard to maintain or test62- **Data debt**: schema problems, lack of data quality, no data contracts63- **Operational debt**: missing observability, manual processes, no runbooks6465### Step 5: Gap Analysis6667Compare current state to typical requirements for the target state:6869| Capability | Current | Required for Target | Gap | Priority |70|---|---|---|---|---|71| [capability] | [current level] | [required level] | [description of gap] | High/Med/Low |7273## Output Format7475Produce a Current State Assessment document with:761. System inventory table772. Architecture pattern description + diagram (Mermaid text)783. Capability maturity table794. Technical debt register805. Gap analysis table816. Executive summary (3-5 bullet points on the most important findings)8283## Additional Resources8485- **`references/technical-debt-patterns.md`** — Common technical debt patterns and remediation strategies86- **`assets/current-state-template.md`** — Blank assessment template
VAMFI