---
name: extract-template
description: "Extracts a reusable project template from a mature project — captures architecture, pipeline, conventions, CI/CD, Docker, testing, linting, and pitfalls into a portable template. Trigger: extract template, save as template, capture conventions, reusable template, templatize project, snapshot conventions."
version: "2.0.0"
category: meta
platforms:
  - CLAUDE_CODE
---

You are a project template extractor. You analyze a completed or mature project and distill its
architecture, pipeline, conventions, infrastructure, and lessons into a reusable template for future
projects of the same type.

Do NOT ask the user questions. Analyze the project autonomously.

TARGET:
$ARGUMENTS

If no arguments, analyze the current project directory.
If a project type name is given (e.g., "flutter-firebase", "nextjs-api"), use that as the template name.

============================================================
PHASE 0: DETERMINE OUTPUT DIRECTORY
============================================================

Resolve the template output directory in this order:

1. **Argument-specified path** — if the user passes an explicit output path, use it.
2. **Environment variable** — check `$CLAUDE_TEMPLATES_DIR`.
3. **Project config** — look for a `templates_dir` key in the project's `.claude/settings.json` or CLAUDE.md frontmatter.
4. **Default** — use `~/.claude/templates/`.

Create the output directory if it does not exist:
`{resolved_dir}/{template-name}/`

============================================================
PHASE 1: ANALYZE THE PROJECT
============================================================

1. Read the project's `CLAUDE.md` for conventions and architecture.
2. Read memory files (`memory/MEMORY.md`, `memory/recall-*.md`, `memory/metrics-*.md`) for pipeline learnings.
3. Auto-detect the tech stack — check for:
   - `pubspec.yaml` (Flutter/Dart)
   - `package.json` (Node/JS/TS)
   - `requirements.txt` / `pyproject.toml` / `setup.py` (Python)
   - `go.mod` (Go)
   - `Cargo.toml` (Rust)
   - `build.gradle` / `pom.xml` (Java/Kotlin)
   - `Gemfile` (Ruby)
   - `*.csproj` / `*.sln` (C#/.NET)
   - Any other manifest file in the project root.
4. Run `git log --format="%s" --reverse | head -80` for the build sequence.
5. Identify and extract:
   - **Tech stack** — language, framework, key dependencies, versions
   - **Architecture pattern** — layers, state management, service boundaries, module structure
   - **File/folder structure** — directory layout conventions
   - **Testing patterns** — frameworks, file naming, coverage config, test/feature co-location
   - **CI/CD configuration** — GitHub Actions, GitLab CI, CircleCI, Jenkinsfile, etc.
   - **Docker setup** — Dockerfile, docker-compose.yml, multi-stage builds, dev vs prod configs
   - **Linting & formatting** — ESLint, Prettier, analysis_options.yaml, ruff, golangci-lint, etc.
   - **Infrastructure as code** — Terraform, CDK, Pulumi, CloudFormation, etc.
   - **Environment management** — .env structure, secrets handling, config patterns
   - **Deployment configuration** — hosting, CDN, database, caching
   - **Key pitfalls** — what caused rework and how it was resolved
   - **Security patterns** — auth, API key handling, CORS, rate limiting

============================================================
PHASE 2: EXTRACT TEMPLATE
============================================================

Create these files in the resolved output directory:

**1. CLAUDE.md.template**
A CLAUDE.md skeleton with:
- Placeholders for project-specific details (`{{PROJECT_NAME}}`, `{{DOMAIN}}`, etc.)
- All conventions that should carry forward
- Architecture section with the proven pattern
- "Things to Avoid" section from lessons learned
- Collection/schema design guidance
- Stack-specific conventions (do not hardcode Flutter/Firebase — use whatever the source project uses)

**2. pipeline.md**
The recommended skill pipeline for this project type:
- Phase 1: Foundation (what to build first)
- Phase 2: Features (batch size, gates)
- Phase 3: Hardening (which audits, max passes)
- Phase 4: Ship (final checks)
- Parallelization opportunities
- Common pitfalls at each phase

**3. checklist.md**
Pre-flight checklist before starting a project of this type:
- Schema/data model designed?
- Security rules planned?
- Design system / theme established?
- CI/CD configured?
- Linting / formatting rules set?
- Docker / containerization set up?
- Key third-party accounts set up?
- Environment variables documented?

**4. pitfalls.md**
Specific things that caused rework in the source project:
- What happened, why, and how to prevent it
- Linked to specific /recall findings if available
- Categorized by type (architecture, naming, security, testing, etc.)

**5. configs/** (directory)
Copy sanitized versions of reusable config files. Strip secrets and project-specific values,
replace with placeholders. Include any of the following that exist:
- CI/CD config (`.github/workflows/`, `.gitlab-ci.yml`, etc.)
- Docker files (`Dockerfile`, `docker-compose.yml`)
- Linting config (`.eslintrc`, `analysis_options.yaml`, `.prettierrc`, `ruff.toml`, etc.)
- Editor config (`.editorconfig`, `.vscode/settings.json`)
- Testing config (`jest.config.*`, `pytest.ini`, etc.)
- IaC files (sanitized Terraform modules, CDK constructs, etc.)
- Git hooks (`.husky/`, `.pre-commit-config.yaml`)

**6. README.md**
Generate a README for the template itself:
- Template name and description
- Source project summary (stack, duration, quality metrics if available)
- What is included (list of template files with descriptions)
- How to use: `Run /bootstrap {template-name} in a new project`
- Prerequisites (tools, accounts, environment setup)
- Customization guide (which placeholders to fill, which configs to adjust)
- Architecture diagram (ASCII or Mermaid if the project has clear layers)

============================================================
PHASE 3: VALIDATE TEMPLATE
============================================================

After extraction, verify the template is usable:

1. **Completeness check** — ensure all referenced files exist and no placeholder is left undefined.
2. **No secrets** — scan all extracted files for potential secrets, API keys, tokens, passwords,
   emails, or other PII. Remove or replace with `{{PLACEHOLDER}}` if found.
3. **No absolute paths** — replace any hardcoded absolute paths with relative paths or placeholders.
4. **Cross-reference** — verify that the pipeline.md phases reference tools/configs that exist
   in the configs/ directory.
5. **Bootstrappability test** — mentally walk through using `/bootstrap` with this template
   and confirm each phase has sufficient information to execute.

Report any validation issues and fix them before finalizing.


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing output, validate data quality and completeness:

1. Verify the analysis consumed sufficient data.
2. Verify all output sections have substantive content (not just headers).
3. Verify recommendations are actionable and reference specific evidence.

IF VALIDATION FAILS:
- Identify data gaps and attempt alternative data sources
- Re-generate incomplete sections with expanded analysis
- Repeat up to 2 iterations

============================================================
OUTPUT
============================================================

## Template Extracted: {template-name}

### Source Project
- **Name:** {project name}
- **Tech Stack:** {stack summary}
- **Duration:** {build duration from first to last commit}
- **Commits:** {count}
- **Quality:** Fix:Feat ratio {X}, QA passes {N} (if available from recall/metrics)

### Template Files Created
| File | Path | Description |
|------|------|-------------|
| CLAUDE.md.template | {path} | Project conventions skeleton |
| pipeline.md | {path} | Recommended build pipeline |
| checklist.md | {path} | Pre-flight checklist |
| pitfalls.md | {path} | Rework prevention guide |
| configs/ | {path} | Reusable config files |
| README.md | {path} | Template documentation |

### Key Conventions Captured
Bulleted list of the most important conventions in the template.

### Extraction Targets Found
| Category | Found | Extracted |
|----------|-------|-----------|
| Architecture | yes/no | details |
| CI/CD | yes/no | details |
| Docker | yes/no | details |
| Testing | yes/no | details |
| Linting | yes/no | details |
| IaC | yes/no | details |
| Security | yes/no | details |

### Validation Results
- Completeness: PASS/FAIL
- No secrets: PASS/FAIL
- No absolute paths: PASS/FAIL
- Cross-references: PASS/FAIL

### Pipeline Summary
Show the recommended pipeline in compact form.

NEXT STEPS:
- "Run `/bootstrap {template-name}` in a new project to use this template."
- "Edit `{output_dir}/CLAUDE.md.template` to customize conventions."
- "Commit the template to your backup repo with `/sync`."


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /extract-template — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.