
Spec Miner
Reverse-engineer an unfamiliar repo into a structured spec using glob/grep checklists for routes, models, auth, jobs, and tests before you commit scope.
Overview
spec-miner is an agent skill most often used in Validate (also Idea research, Build pm) that systematically discovers stack, APIs, data models, and business flows from an existing codebase using phased checklists.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill spec-minerWhat is this skill?
- 10-area comprehensive checklist (entry points, routes, models, auth, validation, errors, external calls, config, tests,
- 4 analysis phases: Structure Discovery, API Surface, Data Layer, Business Logic
- Maps @Controller, @Entity, DTO validators, ExceptionFilter, queues, and cron in one pass
- Test file globs (*.spec.ts, *.test.ts) to infer behaviors from existing coverage
Adoption & trust: 2.3k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You inherited a repo with no trustworthy spec and cannot confidently scope features, endpoints, or refactors.
Who is it for?
Solo builders validating whether to extend, replace, or wrap an unknown codebase before committing calendar time.
Skip if: Greenfield projects with no code yet, or when you only need a single-file bugfix without system context.
When should I use this skill?
You need to understand an existing codebase’s stack, routes, models, auth, and jobs before scoping or implementing changes.
What do I get? / Deliverables
After the skill runs, you have a phased inventory of stack, directory layout, endpoints, models, auth, validation, jobs, and main flows suitable for a scope doc or implementation plan.
- Structured discovery notes per checklist area
- API surface summary with methods and auth
- Data model and flow trace outline
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Spec mining tightens what you will build or refactor before heavy implementation—the skill shelves under Validate scope because it produces boundary and surface-area clarity. Scope subphase is where you define what the system actually does today; the four analysis phases turn discovery into an actionable inventory.
Where it fits
Mine an open-source competitor fork to list real API surface and auth before choosing build-vs-buy.
Run four analysis phases to produce endpoint and model inventory for a fixed-price MVP quote.
Hand the mined API and data-layer map to an agent as context before a multi-sprint refactor.
Re-run structure and job checklists after a production incident to see what changed in queues and cron.
How it compares
Use instead of ad-hoc ripgrep sessions that miss auth, queues, and config in one coherent spec pass.
Common Questions / FAQ
Who is spec-miner for?
Indie developers and small teams who need a structured reverse-spec from real files before pricing, prototyping, or agent-assisted refactors.
When should I use spec-miner?
Use it in Validate to bound scope on a legacy app, in Idea research when comparing a competitor’s OSS fork, or in Build pm when onboarding an agent to a monorepo you did not write.
Is spec-miner safe to install?
The skill instructs read-only discovery patterns; confirm Prism Security Audits on this page and avoid piping secrets from .env into logs when documenting config.
SKILL.md
READMESKILL.md - Spec Miner
# Analysis Checklist ## Comprehensive Checklist | Area | What to Find | Glob/Grep Patterns | |------|--------------|-------------------| | **Entry points** | main.ts, app.ts, index.ts | `**/main.{ts,js,py}` | | **Routes** | Controllers, route files | `**/routes/**/*`, `@Controller` | | **Models** | Entities, schemas | `**/models/**/*`, `@Entity` | | **Auth** | Guards, middleware, JWT | `**/auth/**/*`, `passport` | | **Validation** | DTOs, validators, pipes | `**/dto/**/*`, `@IsString` | | **Error handling** | Exception filters, try/catch | `ExceptionFilter`, `catch` | | **External calls** | HTTP clients, SDK usage | `fetch(`, `axios.` | | **Config** | Env files, config modules | `**/.env*`, `ConfigService` | | **Tests** | Test files reveal behaviors | `**/*.spec.ts`, `**/*.test.ts` | | **Background jobs** | Queues, cron, workers | `@Cron`, `Bull`, `Queue` | ## Analysis Phases ### Phase 1: Structure Discovery - [ ] Identify technology stack - [ ] Map directory structure - [ ] Find entry points - [ ] List all modules/packages ### Phase 2: API Surface - [ ] Document all endpoints - [ ] Note HTTP methods and paths - [ ] Identify request/response formats - [ ] Find authentication requirements ### Phase 3: Data Layer - [ ] Map all data models - [ ] Document relationships - [ ] Find migrations - [ ] Note validation rules ### Phase 4: Business Logic - [ ] Trace main flows - [ ] Identify business rules - [ ] Document state transitions - [ ] Find external integrations ### Phase 5: Security - [ ] Check authentication method - [ ] Review authorization patterns - [ ] Find input validation - [ ] Note security configurations ### Phase 6: Quality & Testing - [ ] Review existing tests - [ ] Note test coverage - [ ] Document error handling - [ ] Find logging patterns ## Verification Questions Before finalizing specification: - [ ] All endpoints documented? - [ ] All models mapped? - [ ] Authentication flow clear? - [ ] Error responses documented? - [ ] External dependencies listed? - [ ] Uncertainties flagged? # Analysis Process ## Step 1: Project Structure ```bash # Find entry points Glob: **/main.{ts,js,py,go} Glob: **/app.{ts,js,py} Glob: **/index.{ts,js} # Find routes/controllers Glob: **/routes/**/*.{ts,js} Glob: **/controllers/**/*.{ts,js} Grep: @Controller|@Get|@Post|router\.|app\.get ``` ## Step 2: Data Models ```bash # Database schemas Glob: **/models/**/*.{ts,js,py} Glob: **/schema*.{ts,js,py,sql} Glob: **/migrations/**/* Grep: @Entity|class.*Model|schema\s*= ``` ## Step 3: Business Logic ```bash # Services and logic Glob: **/services/**/*.{ts,js} Grep: async.*function|export.*class ``` ## Step 4: Authentication & Security ```bash # Auth patterns Glob: **/auth/**/* Glob: **/guards/**/* Grep: @Guard|middleware|passport|jwt ``` ## Step 5: External Integrations ```bash # External calls Grep: fetch\(|axios\.|HttpService|request\( Glob: **/integrations/**/* Glob: **/clients/**/* ``` ## Step 6: Configuration ```bash # Config files Glob: **/*.config.{ts,js} Glob: **/.env* Glob: **/config/**/* ``` ## Quick Reference | Pattern | Purpose | |---------|---------| | `**/main.{ts,js,py}` | Entry points | | `**/routes/**/*` | API routes | | `**/models/**/*` | Data models | | `@Controller\|@Get` | NestJS patterns | | `router.\|app.get` | Express patterns | # EARS Format ## EARS Syntax Easy Approach to Requirements Syntax for clear, unambiguous requirements. ### Basic Patterns **Ubiquitous (Always)** ``` The system shall [action]. ``` **Event-Driven** ``` When [trigger], the system shall [action]. ``` **State-Driven** ``` While [state], the system shall [action]. ``` **Conditional** ``` While [state], when [trigger], the system shall [action]. ``` **Optional** ``` Where [feature enabled], the system shall [action]. ``` ## Example Observations ### Authentication **OBS-AUTH-001: Login Flow** ``` While credentials are valid, when POST /auth/login is called, the system shall return JWT access token (15m) and refre