analyze

Files (1)

• SKILL.md

SKILL.md (first lines)

# System Analysis

Shared files: a path written `@rules/…`, `@skills/…`, `@templates/…` or `@docs/…` is relative to the
plugin root, `${CLAUDE_PLUGIN_ROOT}` — not to the project being worked on. Read it from there.

**Usage:** `/architect:analyze [target_path]`

## Desired Outcome

Structure the domain knowledge of the target system and generate the following four analysis documents:
1. **System Overview** — Business context, key features, system boundaries
2. **Ubiquitous Language** — Domain term dictionary (term, definition, code correspondence, usage context)
3. **Actors, Roles, and Permissions** — User types, role definitions, permission matrix
4. **Domain-Code Mapping** — Correspondence between domain concepts and code implementations

## Decision Criteria

- Cross-reference ubiquitous language with actual naming in the code
- Detect cases where the same concept uses different names
- Identify gaps in domain-code mapping (domain concepts not reflected in code)
- Track where business rules are implemented in the code

## Prerequisites

| File | Required/Recommended | Source |
|------|---------------------|--------|
| reports/before/{project}/ | Required | /architect:investigate |
| reports/before/{project}/ui-inventory.json | Optional | /architect:analyze-ui (when the system has a UI) |

### Using the UI inventory (when present)

The existing UI is evidence the backend alone does not give (@rules/ui-analysis.md §9):

- **Actors, roles, permissions** — every screen's `access` (authentication, roles, guards) is a
  row of evidence for the permission matrix. A role enforced only by a `view` guard is recorded
  as such — as UI-hidden, not as access-controlled.
- **Ubiquitous language** — screen names, labels and messages are the users' vocabulary. A label
  that differs from the code name for the same concept is a synonym to resolve, not a new term.
- **Domain-code mapping** — add a screen column: concept → screens (`UIS-`) → handlers → code.
- **Business rules in the code** — the inventory's `embedded_logic` items are business rules the
  view layer implements; map them like any other rule location.

## Available Resources

- **Serena MCP** — Symbol relationship analysis via `find_symbol`, `find_referencing_symbols` (preferred)
- **Glob/Grep** — Search for domain terms within code
- **Read** — Extract domain knowledge from documentation, comments, and test cases
- **Agent(Explore)** — Parallel entity extraction across large codebases

## Output

| File | Content |
|------|---------|
| `reports/01_analysis/system-overview.md` | Business context, feature list |
| `reports/01_analysis/ubiquitous-language.md` | Domain term dictionary |
| `reports/01_analysis/actors-roles-permissions.md` | Actor, role, and permission matrix |
| `reports/01_analysis/domain-code-mapping.md` | Domain-code correspondence table |

Write all reports in the language configured in `work/pipeline-progress.json` (`options.output_language`).

## Completion

1. All four output files have been written
2. Ubiquitous language contains at least 20 domain terms
3. Update pipeline-progress.json

## Related Skills

| Skill | Relationship |
|-------|-------------|
| /architect:investigate | Upstream (input source) |
| /architect:analyze-ui | Upstream (optional — the UI inventory) |
| /architect:evaluate-mmi | Downstream |
| /architect:evaluate-ddd | Downstream |
| /architect:analyze-data-model | Downstream |

From wfukatsu/nexus-architect, MIT.

More from wfukatsu/nexus-architect