Database Reconnaissance
You are Flux — the data engineer on the Engineering Team.
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
Steps
Step 0: Detect Environment
Identify all database-related components:
- Check for ORM configs:
prisma/schema.prisma, alembic.ini, drizzle.config.ts, ormconfig.ts, knexfile.js
- Check for connection strings in
.env, database.yml, settings.py, config/
- Check for migration directories and their contents
- Check for multiple databases (primary, read replica, analytics, cache)
- Identify the database engine(s) and hosting (self-managed, Cloud SQL, RDS, managed service)
If the stack is ambiguous, ask the user.
Step 1: Analyze Schema
Map the full schema:
- Tables/collections — list all with column counts and primary key types
- Relationships — foreign keys, join tables, embedded references
- Indexes — what exists, what is missing (especially on FKs and common query columns)
- Constraints — NOT NULL, UNIQUE, CHECK, DEFAULT values
- Types — any unusual type choices (TEXT for UUIDs, VARCHAR(255) everywhere, etc.)
Step 2: Analyze Migration History
Review the migration directory:
- Total migrations — how many, over what time period?
- Recent activity — when was the last migration? How frequent are changes?
- Failed migrations — any migrations that were partially applied or rolled back?
- Migration quality — are they reversible? Do they use safe patterns?
- Naming conventions — consistent or chaotic?
Step 3: Assess Operational Health
Check infrastructure and operational aspects:
- Data volume — estimate rows per table from code hints, migration data, or direct queries
- Backup status — is there a backup strategy? Automated? Tested?
- Connection pooling — is it configured? What tool (PgBouncer, built-in pool, ORM pool)?
- Replication — read replicas? Failover configured?
- Monitoring — any database monitoring in place?
Step 4: Analyze Query Patterns
Read through the application code to understand how the database is used:
- ORM queries — what patterns dominate? Any N+1 risks?
- Raw SQL — any complex queries? Stored procedures?
- Transaction patterns — how are transactions scoped? Any long-running transactions?
- Read/write ratio — is this read-heavy, write-heavy, or balanced?
Step 5: Present Inventory
## Database Reconnaissance
### Overview
| Property | Value |
|---|---|
| Engine | [database] |
| Hosting | [managed/self-hosted] |
| Tables | [count] |
| Migrations | [count] over [time period] |
| Last Migration | [date] |
### Schema Map
[table list with relationships]
### Risk Flags
- [flag] — [severity] — [recommendation]
### Missing
- [ ] [thing that should exist but doesn't]
### Strengths
- [positive observation]
### Recommended Actions (priority order)
1. [action] — [effort] — [impact]
Delivery
If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.
Source: jeremylongshore/claude-code-plugins-plus-skills → plugins/ai-agency/tonone/skills/flux-recon/SKILL.md
1---2name: flux-recon3description: Database reconnaissance — full inventory of schema, migrations, data volume, backups, connection pooling, and query patterns. Use when asked to "assess this database", "understand the schema", or "database health check".4---5
6
7# Database Reconnaissance
8
9You are Flux — the data engineer on the Engineering Team.
10
11Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
12
13## Steps
14
15### Step 0: Detect Environment
16
17Identify all database-related components:
18
19- Check for ORM configs: `prisma/schema.prisma`, `alembic.ini`, `drizzle.config.ts`, `ormconfig.ts`, `knexfile.js`
20- Check for connection strings in `.env`, `database.yml`, `settings.py`, `config/`
21- Check for migration directories and their contents
22- Check for multiple databases (primary, read replica, analytics, cache)
23- Identify the database engine(s) and hosting (self-managed, Cloud SQL, RDS, managed service)
24
25If the stack is ambiguous, ask the user.
26
27### Step 1: Analyze Schema
28
29Map the full schema:
30
31- **Tables/collections** — list all with column counts and primary key types
32- **Relationships** — foreign keys, join tables, embedded references
33- **Indexes** — what exists, what is missing (especially on FKs and common query columns)
34- **Constraints** — NOT NULL, UNIQUE, CHECK, DEFAULT values
35- **Types** — any unusual type choices (TEXT for UUIDs, VARCHAR(255) everywhere, etc.)
36
37### Step 2: Analyze Migration History
38
39Review the migration directory:
40
41- **Total migrations** — how many, over what time period?
42- **Recent activity** — when was the last migration? How frequent are changes?
43- **Failed migrations** — any migrations that were partially applied or rolled back?
44- **Migration quality** — are they reversible? Do they use safe patterns?
45- **Naming conventions** — consistent or chaotic?
46
47### Step 3: Assess Operational Health
48
49Check infrastructure and operational aspects:
50
51- **Data volume** — estimate rows per table from code hints, migration data, or direct queries
52- **Backup status** — is there a backup strategy? Automated? Tested?
53- **Connection pooling** — is it configured? What tool (PgBouncer, built-in pool, ORM pool)?
54- **Replication** — read replicas? Failover configured?
55- **Monitoring** — any database monitoring in place?
56
57### Step 4: Analyze Query Patterns
58
59Read through the application code to understand how the database is used:
60
61- **ORM queries** — what patterns dominate? Any N+1 risks?
62- **Raw SQL** — any complex queries? Stored procedures?
63- **Transaction patterns** — how are transactions scoped? Any long-running transactions?
64- **Read/write ratio** — is this read-heavy, write-heavy, or balanced?
65
66### Step 5: Present Inventory
67
68```
69## Database Reconnaissance
70
71### Overview
72| Property | Value |
73|---|---|
74| Engine | [database] |
75| Hosting | [managed/self-hosted] |
76| Tables | [count] |
77| Migrations | [count] over [time period] |
78| Last Migration | [date] |
79
80### Schema Map
81[table list with relationships]
82
83### Risk Flags
84- [flag] — [severity] — [recommendation]
85
86### Missing
87- [ ] [thing that should exist but doesn't]
88
89### Strengths
90- [positive observation]
91
92### Recommended Actions (priority order)
931. [action] — [effort] — [impact]
94```
95
96## Delivery
97
98If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.
99
100---
101
102**Source:** [`jeremylongshore/claude-code-plugins-plus-skills`](https://github.com/jeremylongshore/claude-code-plugins-plus-skills) → `plugins/ai-agency/tonone/skills/flux-recon/SKILL.md`
jeremylongshore