nextura-reverse-engineering
Discover architecture from codebase and document in SSOT. Use when understanding how existing code works.
Packaged view
This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.
Install command
npx @skill-hub/cli install alicoding-nextura-nextura-reverse-engineering
Repository
Skill path: .claude/skills/nextura-reverse-engineering
Discover architecture from codebase and document in SSOT. Use when understanding how existing code works.
Open repositoryBest for
Primary workflow: Ship Full Stack.
Technical facets: Full Stack.
Target audience: everyone.
License: Unknown.
Original source
Catalog source: SkillHub Club.
Repository owner: alicoding.
This is still a mirrored public skill entry. Review the repository before installing into production workflows.
What it helps with
- Install nextura-reverse-engineering into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
- Review https://github.com/alicoding/nextura before adding nextura-reverse-engineering to shared team environments
- Use nextura-reverse-engineering for development workflows
Works across
Favorites: 0.
Sub-skills: 0.
Aggregator: No.
Original source / Raw SKILL.md
---
name: nextura-reverse-engineering
scope: nextura
description: >
Discover architecture from codebase and document in SSOT.
Use when understanding how existing code works.
version: 2.0.0
triggers:
- understand code
- how does work
- reverse engineer
- discover architecture
- document existing
gates:
post:
- "make validate"
---
# Reverse Engineering
Discover architecture from code. Output to SSOT.
---
## Quick Start
1. Identify scope (module, service, system)
2. Create session folder
3. Analyze code systematically
4. Document findings in SSOT
---
## Analysis Phases
### Phase 1: Entry Points
- Main functions, CLI commands
- API endpoints
- Event handlers
### Phase 2: Dependencies
- Import graph
- External services
- Data stores
### Phase 3: Data Flow
- Input -> processing -> output
- State management
- Persistence patterns
### Phase 4: Boundaries
- Public vs internal APIs
- Module boundaries
- Domain concepts
**For detailed analysis:** See [reference/analysis.md](reference/analysis.md)
---
## Output to SSOT
| Discovery | SSOT Entity |
|-----------|-------------|
| Module | C-XXX (component) |
| API | FLOW-XXX (sequence) |
| Data model | SCHEMA-XXX |
| Architecture decision | ADR-XXX |
---
## STOP GATES
### STOP GATE 1: Scope Defined
**Check:** Is analysis scope clear?
**Pass:** Specific module/service identified
**Fail:** STOP. Define scope first.
### STOP GATE 2: Entry Points Found
**Check:** Are entry points documented?
**Pass:** Main functions identified
**Fail:** STOP. Find entry points.
### STOP GATE 3: SSOT Updated
**Check:** Are discoveries in SSOT?
**Pass:** Components/flows created
**Fail:** STOP. Create SSOT entities.
---
## Quick Reference
```
DISCOVERY ORDER
1. Entry points (main, handlers)
2. Dependencies (imports, services)
3. Data flow (input -> output)
4. Boundaries (public vs internal)
OUTPUT
C-XXX.yaml # Components
FLOW-XXX.yaml # Sequences
ADR-XXX.yaml # Decisions
```
---
## Reference Files
- [reference/analysis.md](reference/analysis.md) - Analysis patterns
- [reference/tools.md](reference/tools.md) - Analysis tools