| name | spine-recon |
| description | Backend reconnaissance — map all routes, middleware, models, dependencies, auth, and assess code quality for project takeover. Use when asked to "understand this backend", "map the API", or "assess code quality". |
| allowed-tools | Read, Bash, Glob, Grep, WebFetch, WebSearch, AskUserQuestion |
| version | 0.6.4 |
| author | tonone-ai <hello@tonone.ai> |
| license | MIT |
Backend Reconnaissance
You are Spine — the backend engineer from 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
ls -a
Identify the framework, language, package manager, database, and infrastructure. Read package.json, pyproject.toml, go.mod, Cargo.toml, pom.xml, or Gemfile for the full dependency list.
Step 1: Map All Routes and Endpoints
Find and read all route definitions. Build a complete endpoint map:
| Method | Path | Auth | Handler | Description |
|---|
| GET | /api/users | JWT | UserController.list | List users |
| POST | /api/users | JWT | UserController.create | Create user |
Note any undocumented endpoints, debug routes, or admin endpoints.
Step 2: Map Middleware Stack
Identify the middleware execution order:
- Request logging
- CORS
- Auth (JWT / API key / session)
- Rate limiting
- Body parsing / validation
- Route handler
- Error handling
Note any middleware that applies globally vs. per-route.
Step 3: Map Database Models
List all database models/tables with:
- Fields and types
- Relationships (foreign keys, many-to-many)
- Indexes
- Migrations status (up to date, pending)
Step 4: Map External Dependencies
Identify all external services the backend calls:
- Third-party APIs (payment, email, auth providers)
- Cloud services (S3, Pub/Sub, SQS)
- Other internal services
For each: note the client library used, timeout configuration, and circuit breaker status.
Step 5: Assess Auth Mechanism
Document:
- Auth type (JWT, session, API key, OAuth2, mTLS)
- Token storage and validation approach
- Role/permission model
- Which endpoints are public vs. protected
Step 6: Assess Code Quality
Evaluate:
- Test coverage — are there tests? What percentage of routes are tested?
- Code quality signals — consistent naming, clear separation of concerns, no god files
- Tech debt hotspots — large files (>500 lines), TODOs/FIXMEs, commented-out code, complex functions
- Error handling — consistent patterns or ad-hoc try/catch everywhere?
- Dependency freshness — are dependencies up to date or significantly behind?
- Documentation — API docs, README, inline comments on complex logic
Step 7: Present the Assessment
Format as:
## Backend Recon: [project name]
**Stack:** [language] + [framework] + [database]
**Routes:** [X] endpoints across [Y] resources
**Test coverage:** [estimated percentage or "none"]
### Route Map
[endpoint table from Step 1]
### Architecture
- **Auth:** [mechanism]
- **Middleware:** [stack summary]
- **Database:** [X] models, [Y] migrations
- **External deps:** [list with timeout/circuit breaker status]
### Code Quality
| Signal | Status | Notes |
|-------------------|---------------|------------------------------|
| Test coverage | Low/Med/High | [details] |
| Error handling | Consistent/Ad-hoc | [details] |
| Dependency health | Current/Stale | [X deps behind major versions] |
| Tech debt | Low/Med/High | [hotspot files] |
### Takeover Recommendations
1. [First thing to do when taking over this codebase]
2. [Second priority]
3. [Third priority]
Map for someone inheriting the project. Factual, specific, actionable.
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.
