@valentia-ai-skills/framework 2.0.1 → 2.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +315 -39
- package/bin/cli.js +244 -1
- package/package.json +1 -1
- package/skills/global/aisupportapp-project-architecture/SKILL.md +1 -1
- package/skills/global/aisupportapp-project-conventions/SKILL.md +1 -1
- package/skills/global/aisupportapp-project-workflows/SKILL.md +1 -1
- package/skills/global/aisupportapp-test-installation/SKILL.md +1 -1
- package/skills/global/api-design/SKILL.md +1 -1
- package/skills/global/appointment-oas-app/SKILL.md +1 -1
- package/skills/global/code-standards/SKILL.md +1 -1
- package/skills/global/codebase-legacy-intelligence/SKILL.md +627 -0
- package/skills/global/project-scanner/SKILL.md +1 -1
- package/skills/global/viteapp-core-workflows/SKILL.md +1 -1
|
@@ -0,0 +1,627 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: codebase-legacy-intelligence
|
|
3
|
+
description: A complete project Ecosystem Builder
|
|
4
|
+
version: 1.0.0
|
|
5
|
+
scope: global
|
|
6
|
+
last_reviewed: 2026-03-28
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
name: codebase-legacy-intelligence
|
|
11
|
+
description: >
|
|
12
|
+
Deep reverse-engineering skill that scans any legacy codebase (.NET, MVC, React, Node, TypeScript, Python, or any project) and generates a complete intelligence package — structured SKILL.md files, API registries, business logic extraction, data models, Mermaid diagrams, and a full reproduction guide. The generated skills are so thorough that a developer or AI agent could rebuild the entire application from scratch using only the output. Use this skill whenever someone asks to: scan a legacy codebase, reverse-engineer a project, understand an unfamiliar codebase, generate documentation from code, extract business logic from source files, create a project knowledge base, audit a codebase's architecture, produce onboarding materials from existing code, map out APIs in a project, or generate Mermaid diagrams of application flow. Also trigger when someone says things like "I inherited this codebase", "help me understand this project", "document this application", "what does this code do", "extract the logic from this app", "scan this repo", or "I need to hand off this project". Works on any language or framework — the scanner adapts its parsing strategy per tech stack.
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
# Codebase Legacy Intelligence
|
|
16
|
+
|
|
17
|
+
You are a deep codebase reverse-engineering agent. Your job is to scan a legacy codebase and produce a **complete application blueprint** — structured knowledge so thorough that a developer or AI agent could rebuild the entire application from scratch using only your output.
|
|
18
|
+
|
|
19
|
+
This is not documentation. This is **reproduction-grade intelligence**.
|
|
20
|
+
|
|
21
|
+
## Philosophy
|
|
22
|
+
|
|
23
|
+
Legacy codebases contain years of implicit decisions, undocumented business rules, tribal knowledge, and architectural evolution that nobody wrote down. Your job is to make all of it explicit, structured, and actionable. Every output you produce must pass the **Rebuild Test**: could someone who has never seen this codebase recreate its exact behavior using only your generated skills?
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Step 0: User Interview
|
|
28
|
+
|
|
29
|
+
Before scanning anything, ask the user these questions to calibrate your approach:
|
|
30
|
+
|
|
31
|
+
1. **Scan scope**: Full project scan or targeted module scan?
|
|
32
|
+
2. **Project location**: Where is the codebase? (path on disk, or will they share files?)
|
|
33
|
+
3. **Tech stack confirmation**: Auto-detect the stack, then confirm with the user. Ask if there are multiple stacks (e.g., .NET backend + React frontend).
|
|
34
|
+
4. **Priority modules**: Are there specific areas they care most about? (e.g., "the billing module is the one that breaks")
|
|
35
|
+
5. **Output depth**: Quick overview (architecture + API map) or deep intelligence (full business logic extraction + reproduction skills)?
|
|
36
|
+
6. **Known pain points**: What's confusing or undocumented? Where do new developers get stuck?
|
|
37
|
+
|
|
38
|
+
Once you have answers, announce your scan plan and proceed.
|
|
39
|
+
|
|
40
|
+
---
|
|
41
|
+
|
|
42
|
+
## Step 1: Structural Reconnaissance
|
|
43
|
+
|
|
44
|
+
Start broad. Map the entire project before going deep.
|
|
45
|
+
|
|
46
|
+
### Actions:
|
|
47
|
+
1. List the full directory tree (2-3 levels deep)
|
|
48
|
+
2. Identify the tech stack by examining signature files — read `references/stack-parsers.md` for the detected stack's parsing strategy
|
|
49
|
+
3. Identify entry points (main files, startup configs, route registrations)
|
|
50
|
+
4. Map the build system (webpack, vite, dotnet build, docker, CI/CD configs)
|
|
51
|
+
5. Catalog environment configurations (`.env`, `appsettings.json`, `config/`)
|
|
52
|
+
6. Count modules/directories and estimate project size
|
|
53
|
+
|
|
54
|
+
### Output: `OVERVIEW.md`
|
|
55
|
+
|
|
56
|
+
```markdown
|
|
57
|
+
# {Project Name} — Codebase Intelligence Report
|
|
58
|
+
|
|
59
|
+
## Tech Stack
|
|
60
|
+
- **Language**: {language + version if detectable}
|
|
61
|
+
- **Framework**: {framework + version}
|
|
62
|
+
- **Build System**: {build tool}
|
|
63
|
+
- **Package Manager**: {npm/nuget/pip/etc}
|
|
64
|
+
- **Database**: {if detectable from ORM configs or connection strings}
|
|
65
|
+
- **Infrastructure**: {Docker, CI/CD, cloud configs if present}
|
|
66
|
+
|
|
67
|
+
## Architecture Pattern
|
|
68
|
+
{Monolith / Microservices / MVC / Clean Architecture / etc — explain the pattern}
|
|
69
|
+
|
|
70
|
+
## Entry Points
|
|
71
|
+
{List main entry files and what they bootstrap}
|
|
72
|
+
|
|
73
|
+
## Module Map
|
|
74
|
+
{List each top-level module/directory with a one-line description of its purpose}
|
|
75
|
+
|
|
76
|
+
## Project Scale
|
|
77
|
+
- Files: {count}
|
|
78
|
+
- Estimated Lines of Code: {rough count}
|
|
79
|
+
- External Dependencies: {count}
|
|
80
|
+
- Environment Variables: {count}
|
|
81
|
+
|
|
82
|
+
## Build & Run
|
|
83
|
+
{How to build and run this project — extracted from scripts, Dockerfiles, READMEs}
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
### Output: `diagrams/system-architecture.mermaid`
|
|
87
|
+
|
|
88
|
+
Generate a Mermaid diagram showing the high-level architecture — major modules, their relationships, external services, databases, and entry points.
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## Step 2: Dependency & Data Layer
|
|
93
|
+
|
|
94
|
+
### Actions:
|
|
95
|
+
1. **External dependencies**: Parse package manifests and list every dependency with its purpose (group into: framework, UI, state management, HTTP/API, database/ORM, auth, testing, utilities, dev tools)
|
|
96
|
+
2. **Internal dependency graph**: Trace imports between modules — which modules depend on which
|
|
97
|
+
3. **Database schema**: Extract from ORM models (Entity Framework, Sequelize, Prisma, TypeORM, Django models), migration files, or raw SQL. Document every table, column, type, constraint, relationship, and index.
|
|
98
|
+
4. **External service integrations**: Find all outbound HTTP calls, SDK usages, message queue connections, email services, payment gateways, etc.
|
|
99
|
+
|
|
100
|
+
### Output: `DEPENDENCIES.md`
|
|
101
|
+
|
|
102
|
+
```markdown
|
|
103
|
+
# Dependencies
|
|
104
|
+
|
|
105
|
+
## External Packages
|
|
106
|
+
### Framework & Core
|
|
107
|
+
| Package | Version | Purpose |
|
|
108
|
+
|---------|---------|---------|
|
|
109
|
+
| ... | ... | ... |
|
|
110
|
+
|
|
111
|
+
### Database & ORM
|
|
112
|
+
| Package | Version | Purpose |
|
|
113
|
+
|---------|---------|---------|
|
|
114
|
+
|
|
115
|
+
{Continue for each category}
|
|
116
|
+
|
|
117
|
+
## Internal Module Dependencies
|
|
118
|
+
{Which modules import from which — directional}
|
|
119
|
+
|
|
120
|
+
## External Service Integrations
|
|
121
|
+
| Service | Purpose | Where Used | Auth Method |
|
|
122
|
+
|---------|---------|------------|-------------|
|
|
123
|
+
| ... | ... | ... | ... |
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
### Output: `DATA_MODELS.md`
|
|
127
|
+
|
|
128
|
+
```markdown
|
|
129
|
+
# Data Models
|
|
130
|
+
|
|
131
|
+
## Entity: {EntityName}
|
|
132
|
+
- **Table**: {table_name}
|
|
133
|
+
- **Purpose**: {what this entity represents in the business domain}
|
|
134
|
+
|
|
135
|
+
| Field | Type | Nullable | Default | Constraints | Notes |
|
|
136
|
+
|-------|------|----------|---------|-------------|-------|
|
|
137
|
+
| id | int/uuid | No | auto | PK | ... |
|
|
138
|
+
|
|
139
|
+
### Relationships
|
|
140
|
+
- Has many: {related entities}
|
|
141
|
+
- Belongs to: {parent entities}
|
|
142
|
+
- Many-to-many: {junction tables}
|
|
143
|
+
|
|
144
|
+
### Indexes
|
|
145
|
+
- {index name}: {columns} ({unique/non-unique})
|
|
146
|
+
|
|
147
|
+
{Repeat for every entity}
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
### Output: `diagrams/data-model-er.mermaid` and `diagrams/module-dependencies.mermaid`
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Step 3: API Surface Mapping
|
|
155
|
+
|
|
156
|
+
Catalog every API endpoint the application exposes AND every external API it consumes. Use the stack-specific parsing strategy from `references/stack-parsers.md`.
|
|
157
|
+
|
|
158
|
+
### Output: `API_REGISTRY.md`
|
|
159
|
+
|
|
160
|
+
```markdown
|
|
161
|
+
# API Registry
|
|
162
|
+
|
|
163
|
+
## Exposed Endpoints
|
|
164
|
+
|
|
165
|
+
### {Module/Controller Name}
|
|
166
|
+
|
|
167
|
+
#### `{METHOD} {route}`
|
|
168
|
+
- **Purpose**: {what this endpoint does}
|
|
169
|
+
- **Authentication**: {required/optional/none — specify scheme}
|
|
170
|
+
- **Authorization**: {roles/permissions required}
|
|
171
|
+
- **Request**:
|
|
172
|
+
- Headers: {required headers}
|
|
173
|
+
- Query params: {param: type — description}
|
|
174
|
+
- Body:
|
|
175
|
+
```json
|
|
176
|
+
{
|
|
177
|
+
"field": "type — description (required/optional)"
|
|
178
|
+
}
|
|
179
|
+
```
|
|
180
|
+
- **Response** (200):
|
|
181
|
+
```json
|
|
182
|
+
{
|
|
183
|
+
"field": "type — description"
|
|
184
|
+
}
|
|
185
|
+
```
|
|
186
|
+
- **Error Responses**:
|
|
187
|
+
- 400: {when/why}
|
|
188
|
+
- 401: {when/why}
|
|
189
|
+
- 404: {when/why}
|
|
190
|
+
- **Business Rules Applied**: {reference to rules in BUSINESS_RULES.md}
|
|
191
|
+
- **Side Effects**: {emails sent, events published, logs written}
|
|
192
|
+
|
|
193
|
+
{Repeat for every endpoint}
|
|
194
|
+
|
|
195
|
+
## Consumed External APIs
|
|
196
|
+
|
|
197
|
+
### {Service Name}
|
|
198
|
+
- **Base URL**: {from config}
|
|
199
|
+
- **Authentication**: {API key / OAuth / etc}
|
|
200
|
+
- **Endpoints Called**:
|
|
201
|
+
| Method | Path | Called From | Purpose |
|
|
202
|
+
|--------|------|-------------|---------|
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
### Output: Per-feature Mermaid sequence diagrams in `diagrams/`
|
|
206
|
+
|
|
207
|
+
---
|
|
208
|
+
|
|
209
|
+
## Step 4: Business Logic Extraction — THE CRITICAL PASS
|
|
210
|
+
|
|
211
|
+
This is the most important pass. This is what makes the generated skills reproduction-grade. Go function by function through service layers, handlers, and business logic files.
|
|
212
|
+
|
|
213
|
+
### What to Extract:
|
|
214
|
+
|
|
215
|
+
**1. Business Rules** — Convert imperative code into explicit declarative rules:
|
|
216
|
+
|
|
217
|
+
```
|
|
218
|
+
RULE {module}.{number}: {short name}
|
|
219
|
+
WHEN: {condition in plain English}
|
|
220
|
+
THEN: {action taken}
|
|
221
|
+
ELSE: {alternative action, if any}
|
|
222
|
+
RELATED: {other rules that interact with this one}
|
|
223
|
+
SOURCE: {file:line reference}
|
|
224
|
+
```
|
|
225
|
+
|
|
226
|
+
**2. Validation Rules** — Every field validation, input sanitization, format check, range constraint.
|
|
227
|
+
|
|
228
|
+
**3. Calculation Logic** — Any formulas, aggregations, score computations, pricing calculations — the exact formula step by step.
|
|
229
|
+
|
|
230
|
+
**4. State Machines** — Any entity that transitions between states. Document every valid transition, trigger, and side effects.
|
|
231
|
+
|
|
232
|
+
**5. Authorization Logic** — Who can do what, under which conditions. Role-based rules, ownership checks, time-based restrictions.
|
|
233
|
+
|
|
234
|
+
**6. Workflow / Process Steps** — Multi-step business processes — each step, progression triggers, and per-step behavior.
|
|
235
|
+
|
|
236
|
+
**7. Error Handling Patterns** — How the app handles failures: retry logic, fallback behavior, error transformation, user-facing messages.
|
|
237
|
+
|
|
238
|
+
**8. Scheduled Jobs / Background Tasks** — What they do, when they run, what they process.
|
|
239
|
+
|
|
240
|
+
### Output: `BUSINESS_RULES.md`
|
|
241
|
+
|
|
242
|
+
```markdown
|
|
243
|
+
# Business Rules
|
|
244
|
+
|
|
245
|
+
## Module: {module name}
|
|
246
|
+
|
|
247
|
+
### Rule {module}.001: {descriptive name}
|
|
248
|
+
- **When**: {condition}
|
|
249
|
+
- **Then**: {action}
|
|
250
|
+
- **Else**: {alternative}
|
|
251
|
+
- **Validation**: {field constraints that apply}
|
|
252
|
+
- **Source**: `{file}:{line_range}`
|
|
253
|
+
|
|
254
|
+
## Cross-Module Rules
|
|
255
|
+
{Rules that span multiple modules}
|
|
256
|
+
|
|
257
|
+
## State Transitions
|
|
258
|
+
### Entity: {entity name}
|
|
259
|
+
| From State | To State | Trigger | Side Effects | Permissions |
|
|
260
|
+
|------------|----------|---------|--------------|-------------|
|
|
261
|
+
|
|
262
|
+
## Calculations & Formulas
|
|
263
|
+
### {Calculation Name}
|
|
264
|
+
- **Purpose**: {what it computes}
|
|
265
|
+
- **Formula**: {exact formula}
|
|
266
|
+
- **Inputs**: {list each input and where it comes from}
|
|
267
|
+
- **Output**: {what is produced}
|
|
268
|
+
- **Edge Cases**: {division by zero, null handling, rounding rules}
|
|
269
|
+
```
|
|
270
|
+
|
|
271
|
+
### Output: Mermaid flowcharts for complex workflows in `diagrams/`
|
|
272
|
+
|
|
273
|
+
---
|
|
274
|
+
|
|
275
|
+
## Step 5: Pattern & Risk Analysis
|
|
276
|
+
|
|
277
|
+
### Actions:
|
|
278
|
+
1. **Design patterns detected**: Repository, Unit of Work, Mediator, Observer, Factory, etc.
|
|
279
|
+
2. **Anti-patterns flagged**: God classes, circular dependencies, magic strings/numbers, deep nesting
|
|
280
|
+
3. **Dead code identification**: Unused functions, unreachable branches, commented-out blocks
|
|
281
|
+
4. **Test coverage assessment**: Which modules have tests, which don't
|
|
282
|
+
5. **Security surface**: Auth bypass risks, input validation gaps, hardcoded secrets, unprotected endpoints
|
|
283
|
+
6. **Tech debt hotspots**: Highest complexity files, most TODO/FIXME/HACK comments
|
|
284
|
+
|
|
285
|
+
### Output: `RISK_REPORT.md`
|
|
286
|
+
|
|
287
|
+
```markdown
|
|
288
|
+
# Risk & Tech Debt Report
|
|
289
|
+
|
|
290
|
+
## Architecture Health
|
|
291
|
+
- **Coupling Score**: {low/medium/high — explain}
|
|
292
|
+
- **Cohesion Score**: {low/medium/high — explain}
|
|
293
|
+
- **Test Coverage**: {estimated percentage, by module}
|
|
294
|
+
|
|
295
|
+
## Design Patterns in Use
|
|
296
|
+
| Pattern | Where | Assessment |
|
|
297
|
+
|---------|-------|------------|
|
|
298
|
+
|
|
299
|
+
## Anti-Patterns & Code Smells
|
|
300
|
+
| Issue | Location | Severity | Recommendation |
|
|
301
|
+
|-------|----------|----------|----------------|
|
|
302
|
+
|
|
303
|
+
## Dead Code
|
|
304
|
+
{List of unused functions, unreachable paths, deprecated endpoints}
|
|
305
|
+
|
|
306
|
+
## Security Concerns
|
|
307
|
+
| Concern | Location | Severity | Details |
|
|
308
|
+
|---------|----------|----------|---------|
|
|
309
|
+
|
|
310
|
+
## Tech Debt Hotspots
|
|
311
|
+
{Ranked list by debt severity}
|
|
312
|
+
|
|
313
|
+
## Untested Business Logic
|
|
314
|
+
{Critical business rules from BUSINESS_RULES.md that have no test coverage}
|
|
315
|
+
```
|
|
316
|
+
|
|
317
|
+
---
|
|
318
|
+
|
|
319
|
+
## Step 6: Environment & Configuration Audit
|
|
320
|
+
|
|
321
|
+
### Output: `ENV_CONFIG.md`
|
|
322
|
+
|
|
323
|
+
```markdown
|
|
324
|
+
# Environment & Configuration
|
|
325
|
+
|
|
326
|
+
## Environment Variables
|
|
327
|
+
| Variable | Purpose | Required | Default | Used In |
|
|
328
|
+
|----------|---------|----------|---------|---------|
|
|
329
|
+
|
|
330
|
+
## Configuration Files
|
|
331
|
+
{Each config file, what it controls, which environments}
|
|
332
|
+
|
|
333
|
+
## Feature Flags
|
|
334
|
+
| Flag | Purpose | Default | Affects |
|
|
335
|
+
|------|---------|---------|---------|
|
|
336
|
+
|
|
337
|
+
## Secrets & Credentials
|
|
338
|
+
{What secrets are needed — NOT the values — and where they're expected}
|
|
339
|
+
```
|
|
340
|
+
|
|
341
|
+
---
|
|
342
|
+
|
|
343
|
+
## Step 7: Diagram Synthesis
|
|
344
|
+
|
|
345
|
+
Review all information gathered and generate comprehensive Mermaid diagrams in `diagrams/`.
|
|
346
|
+
|
|
347
|
+
### Required Diagrams:
|
|
348
|
+
1. `system-architecture.mermaid` — High-level system overview
|
|
349
|
+
2. `module-dependencies.mermaid` — Internal module dependency graph
|
|
350
|
+
3. `data-model-er.mermaid` — Entity-relationship diagram
|
|
351
|
+
4. `auth-flow.mermaid` — Authentication and authorization flow
|
|
352
|
+
5. `request-lifecycle.mermaid` — How a typical request flows through the system
|
|
353
|
+
|
|
354
|
+
### Per-Feature Diagrams (for each major feature):
|
|
355
|
+
6. `{feature}-sequence.mermaid` — Sequence diagram for main flow
|
|
356
|
+
7. `{feature}-state.mermaid` — State machine diagram (if state transitions exist)
|
|
357
|
+
8. `{feature}-flowchart.mermaid` — Business logic decision tree
|
|
358
|
+
|
|
359
|
+
### Mermaid Formatting Rules:
|
|
360
|
+
- `graph TD` for architecture and dependency diagrams
|
|
361
|
+
- `sequenceDiagram` for API and request flow diagrams
|
|
362
|
+
- `erDiagram` for data models
|
|
363
|
+
- `stateDiagram-v2` for state machines
|
|
364
|
+
- `flowchart TD` for business logic decision trees
|
|
365
|
+
- Always include a title comment: `%% {Diagram Title}`
|
|
366
|
+
- Use clear, descriptive node labels
|
|
367
|
+
- Color-code by concern using `classDef`
|
|
368
|
+
|
|
369
|
+
---
|
|
370
|
+
|
|
371
|
+
## Step 8: Skill Synthesis — THE OUTPUT THAT MATTERS
|
|
372
|
+
|
|
373
|
+
Generate SKILL.md files that are **reproduction-grade** — comprehensive enough that a developer or AI agent could rebuild the entire module from the skill alone.
|
|
374
|
+
|
|
375
|
+
### Per-Module Skill: `modules/{module-name}/SKILL.md`
|
|
376
|
+
|
|
377
|
+
```markdown
|
|
378
|
+
---
|
|
379
|
+
name: {project}-{module}
|
|
380
|
+
description: >
|
|
381
|
+
Complete reproduction skill for the {module} module of {project}.
|
|
382
|
+
Contains all business rules, API contracts, data models, and implementation
|
|
383
|
+
patterns needed to rebuild this module from scratch.
|
|
384
|
+
---
|
|
385
|
+
|
|
386
|
+
# {Module Name} — Reproduction Skill
|
|
387
|
+
|
|
388
|
+
## Purpose
|
|
389
|
+
{One paragraph: what this module does and why it exists}
|
|
390
|
+
|
|
391
|
+
## Tech Stack for This Module
|
|
392
|
+
{Language, framework, key libraries specific to this module}
|
|
393
|
+
|
|
394
|
+
## Data Models Owned
|
|
395
|
+
|
|
396
|
+
### {EntityName}
|
|
397
|
+
| Field | Type | Nullable | Default | Constraints |
|
|
398
|
+
|-------|------|----------|---------|-------------|
|
|
399
|
+
|
|
400
|
+
{Include relationships, indexes}
|
|
401
|
+
|
|
402
|
+
## API Endpoints
|
|
403
|
+
|
|
404
|
+
### `{METHOD} {route}`
|
|
405
|
+
- **Purpose**: {description}
|
|
406
|
+
- **Auth**: {requirements}
|
|
407
|
+
- **Request**: {full schema}
|
|
408
|
+
- **Response**: {full schema with all fields}
|
|
409
|
+
- **Errors**: {all error cases}
|
|
410
|
+
- **Business Rules**: {list rule IDs that apply}
|
|
411
|
+
|
|
412
|
+
{Repeat for every endpoint}
|
|
413
|
+
|
|
414
|
+
## Business Rules
|
|
415
|
+
|
|
416
|
+
### Rule {number}: {name}
|
|
417
|
+
- **When**: {exact condition}
|
|
418
|
+
- **Then**: {exact action}
|
|
419
|
+
- **Else**: {exact alternative}
|
|
420
|
+
- **Implementation Notes**: {non-obvious implementation details}
|
|
421
|
+
|
|
422
|
+
{Every rule — be exhaustive}
|
|
423
|
+
|
|
424
|
+
## Validation Rules
|
|
425
|
+
| Field | Rule | Error Message |
|
|
426
|
+
|-------|------|---------------|
|
|
427
|
+
|
|
428
|
+
## State Transitions (if applicable)
|
|
429
|
+
| From | To | Trigger | Side Effects |
|
|
430
|
+
|------|-----|---------|--------------|
|
|
431
|
+
|
|
432
|
+
## Integration Points
|
|
433
|
+
- **Depends on**: {other modules this one calls}
|
|
434
|
+
- **Depended on by**: {modules that call this one}
|
|
435
|
+
- **External services**: {APIs this module calls}
|
|
436
|
+
|
|
437
|
+
## Error Handling
|
|
438
|
+
{Retry logic, fallbacks, error response format}
|
|
439
|
+
|
|
440
|
+
## Key Implementation Patterns
|
|
441
|
+
{Design patterns, architectural decisions, non-obvious approaches}
|
|
442
|
+
|
|
443
|
+
## Reproduction Checklist
|
|
444
|
+
- [ ] All data models created with correct constraints
|
|
445
|
+
- [ ] All endpoints respond with correct schemas
|
|
446
|
+
- [ ] All business rules implemented and tested
|
|
447
|
+
- [ ] All validation rules enforced
|
|
448
|
+
- [ ] All state transitions working correctly
|
|
449
|
+
- [ ] All integrations with other modules connected
|
|
450
|
+
- [ ] All error cases handled
|
|
451
|
+
- [ ] All side effects triggered correctly
|
|
452
|
+
```
|
|
453
|
+
|
|
454
|
+
### Master Skill: `MASTER_SKILL.md`
|
|
455
|
+
|
|
456
|
+
```markdown
|
|
457
|
+
---
|
|
458
|
+
name: {project}-master
|
|
459
|
+
description: >
|
|
460
|
+
Complete application blueprint for {project}. Contains the full architecture,
|
|
461
|
+
module map, cross-cutting concerns, and reproduction guide.
|
|
462
|
+
---
|
|
463
|
+
|
|
464
|
+
# {Project Name} — Master Reproduction Skill
|
|
465
|
+
|
|
466
|
+
## Architecture
|
|
467
|
+
{High-level architecture description}
|
|
468
|
+
|
|
469
|
+
## Module Map
|
|
470
|
+
| Module | Purpose | Dependencies | Skill File |
|
|
471
|
+
|--------|---------|--------------|------------|
|
|
472
|
+
|
|
473
|
+
## Cross-Cutting Concerns
|
|
474
|
+
|
|
475
|
+
### Authentication & Authorization
|
|
476
|
+
{How auth works across the entire app}
|
|
477
|
+
|
|
478
|
+
### Error Handling Strategy
|
|
479
|
+
{Global error handling approach}
|
|
480
|
+
|
|
481
|
+
### Logging & Monitoring
|
|
482
|
+
{What gets logged, where, in what format}
|
|
483
|
+
|
|
484
|
+
### Shared Utilities
|
|
485
|
+
{Common functions/services used across modules}
|
|
486
|
+
|
|
487
|
+
## Build & Deployment
|
|
488
|
+
{How to build, test, and deploy}
|
|
489
|
+
|
|
490
|
+
## Reproduction Guide — Step by Step
|
|
491
|
+
1. {Set up the project scaffold}
|
|
492
|
+
2. {Configure the database}
|
|
493
|
+
3. {Build module X first because others depend on it}
|
|
494
|
+
4. {Wire up authentication}
|
|
495
|
+
5. {Build module Y}
|
|
496
|
+
...
|
|
497
|
+
|
|
498
|
+
## Environment Setup
|
|
499
|
+
{All env vars, configs, and infrastructure needed}
|
|
500
|
+
```
|
|
501
|
+
|
|
502
|
+
---
|
|
503
|
+
|
|
504
|
+
## Step 9: Domain Glossary
|
|
505
|
+
|
|
506
|
+
### Output: `GLOSSARY.md`
|
|
507
|
+
|
|
508
|
+
Extract domain-specific terms from variable names, function names, comments, string literals, database names, API endpoints, and error messages.
|
|
509
|
+
|
|
510
|
+
```markdown
|
|
511
|
+
# Domain Glossary
|
|
512
|
+
|
|
513
|
+
| Term | Meaning | Used In |
|
|
514
|
+
|------|---------|---------|
|
|
515
|
+
```
|
|
516
|
+
|
|
517
|
+
---
|
|
518
|
+
|
|
519
|
+
## Step 10: Reproduction Guide
|
|
520
|
+
|
|
521
|
+
### Output: `REPRODUCTION_GUIDE.md`
|
|
522
|
+
|
|
523
|
+
The master "how to rebuild this app from zero" document. References all other files.
|
|
524
|
+
|
|
525
|
+
```markdown
|
|
526
|
+
# Reproduction Guide for {Project Name}
|
|
527
|
+
|
|
528
|
+
## Prerequisites
|
|
529
|
+
{What you need installed and running}
|
|
530
|
+
|
|
531
|
+
## Step-by-Step Rebuild Order
|
|
532
|
+
|
|
533
|
+
### Phase 1: Project Setup
|
|
534
|
+
1. Initialize {framework} project
|
|
535
|
+
2. Install dependencies (see DEPENDENCIES.md)
|
|
536
|
+
3. Configure environment (see ENV_CONFIG.md)
|
|
537
|
+
4. Set up database schema (see DATA_MODELS.md)
|
|
538
|
+
|
|
539
|
+
### Phase 2: Core Infrastructure
|
|
540
|
+
5. Implement authentication
|
|
541
|
+
6. Set up error handling middleware
|
|
542
|
+
7. Configure logging
|
|
543
|
+
|
|
544
|
+
### Phase 3: Module Implementation
|
|
545
|
+
{For each module, in dependency order:}
|
|
546
|
+
8. Build {module A} (see modules/{module-a}/SKILL.md)
|
|
547
|
+
- Create data models
|
|
548
|
+
- Implement endpoints
|
|
549
|
+
- Apply business rules
|
|
550
|
+
- Wire up integrations
|
|
551
|
+
|
|
552
|
+
### Phase 4: Integration & Testing
|
|
553
|
+
|
|
554
|
+
### Phase 5: Deployment
|
|
555
|
+
|
|
556
|
+
## Verification Checklist
|
|
557
|
+
{Comprehensive checklist to verify the rebuild matches the original}
|
|
558
|
+
```
|
|
559
|
+
|
|
560
|
+
---
|
|
561
|
+
|
|
562
|
+
## Final Output Folder Structure
|
|
563
|
+
|
|
564
|
+
```
|
|
565
|
+
{project-name}-intelligence/
|
|
566
|
+
├── MASTER_SKILL.md
|
|
567
|
+
├── OVERVIEW.md
|
|
568
|
+
├── API_REGISTRY.md
|
|
569
|
+
├── DATA_MODELS.md
|
|
570
|
+
├── BUSINESS_RULES.md
|
|
571
|
+
├── DEPENDENCIES.md
|
|
572
|
+
├── ENV_CONFIG.md
|
|
573
|
+
├── RISK_REPORT.md
|
|
574
|
+
├── GLOSSARY.md
|
|
575
|
+
├── REPRODUCTION_GUIDE.md
|
|
576
|
+
├── diagrams/
|
|
577
|
+
│ ├── system-architecture.mermaid
|
|
578
|
+
│ ├── module-dependencies.mermaid
|
|
579
|
+
│ ├── data-model-er.mermaid
|
|
580
|
+
│ ├── auth-flow.mermaid
|
|
581
|
+
│ ├── request-lifecycle.mermaid
|
|
582
|
+
│ └── {feature}-*.mermaid
|
|
583
|
+
└── modules/
|
|
584
|
+
├── {module-name}/
|
|
585
|
+
│ ├── SKILL.md
|
|
586
|
+
│ └── diagrams/
|
|
587
|
+
│ └── *.mermaid
|
|
588
|
+
└── ...
|
|
589
|
+
```
|
|
590
|
+
|
|
591
|
+
---
|
|
592
|
+
|
|
593
|
+
## Targeted Module Scan Mode
|
|
594
|
+
|
|
595
|
+
If the user selected targeted scan:
|
|
596
|
+
1. Ask which module(s) to scan
|
|
597
|
+
2. Run Steps 2-4 only on those modules
|
|
598
|
+
3. Generate module-level SKILL.md and diagrams
|
|
599
|
+
4. Still produce a lightweight OVERVIEW.md for project context
|
|
600
|
+
|
|
601
|
+
---
|
|
602
|
+
|
|
603
|
+
## Quality Gate: The Rebuild Test
|
|
604
|
+
|
|
605
|
+
After generating all output, self-evaluate each module skill:
|
|
606
|
+
|
|
607
|
+
- [ ] **Data completeness**: Every entity field, type, and constraint documented
|
|
608
|
+
- [ ] **API completeness**: Every endpoint has full request/response schemas and error cases
|
|
609
|
+
- [ ] **Logic completeness**: Every business rule extracted with explicit conditions
|
|
610
|
+
- [ ] **Validation completeness**: Every validation rule listed with error message
|
|
611
|
+
- [ ] **State completeness**: Every state transition documented with triggers and side effects
|
|
612
|
+
- [ ] **Integration completeness**: All inter-module and external dependencies mapped
|
|
613
|
+
- [ ] **Reproduction clarity**: Rebuild steps in correct order with no circular dependencies
|
|
614
|
+
|
|
615
|
+
If any item fails, go back and enrich before delivering.
|
|
616
|
+
|
|
617
|
+
---
|
|
618
|
+
|
|
619
|
+
## Handling Very Large Codebases
|
|
620
|
+
|
|
621
|
+
If the project has more than ~50 files or ~10,000 lines:
|
|
622
|
+
1. Complete Step 1 (structural) for the entire project
|
|
623
|
+
2. Present the module map to the user
|
|
624
|
+
3. Ask them to prioritize which modules to deep-scan first
|
|
625
|
+
4. Process priority modules through Steps 2-8
|
|
626
|
+
5. Generate lightweight stubs for remaining modules
|
|
627
|
+
6. Offer to deep-scan additional modules on demand
|