# Skill: New Project Reset

Purpose: One-time reset of this DevFoundry template's own internal process-development history when it is adopted to start a brand-new real project, so the new project doesn't inherit DevFoundry's own meta-specs (e.g. SPEC-001–005, which document DevFoundry's own process hardening and a since-reverted framework-vendoring experiment — none of that is the new project's history).

**Trigger: only run this when explicitly asked to** ("reset this for a new project," "clear the archive, we're starting fresh," "adopt this template"). Never run it automatically, as part of the normal spec lifecycle in `AGENTS.md`, or without explicit confirmation — it permanently deletes DevFoundry's own spec archive. Archiving a single completed spec at the end of its normal lifecycle (AGENTS.md step 7) is a different, non-destructive action and does not use this skill.

## Steps
1. Confirm with the user this is genuinely a "start fresh, adopt the template" action, not a request to archive one specific spec. If ambiguous, ask before deleting anything.
2. If this repo is a git working tree, confirm `git status` is clean before deleting — deleted files stay recoverable from git history afterward, but only if nothing else was uncommitted at the time. If this is not a git repo, warn the user that deletion here is unrecoverable and get explicit confirmation before proceeding.
3. Delete every file in `specs/archive/` except `.gitkeep`.
4. Delete every file in `specs/active/` except `.gitkeep`. This should normally already be empty — a non-empty `specs/active/` means a spec is mid-flight; flag that to the user rather than silently discarding in-progress work, and stop until they confirm.
5. Reset `specs/.spec-counter` to `1`.
6. Reset `.devfoundry/improvement-log.md` to its empty template state: keep the header/instructions and the (empty) Friction Tally table, remove every dated entry below it.
7. Re-check `.devfoundry/references/*.md` (`environments.md`, `data-dictionary.md`, `sql-dialects.md`, and any stack-specific reference such as `asp-classic-framework.md`) for residual project-specific facts left over from DevFoundry's own development — a real connection string, a real schema, a real path — and blank anything found. Genuinely reusable framework/dialect knowledge (e.g. RouteKit's directory layout) is fine to keep; it's not project-specific history.
8. Do **not** touch `.devfoundry/rules/`, `.devfoundry/personas/`, `.devfoundry/skills/`, or `specs/templates/` — those are the process itself, not history, and are exactly what the new project is adopting.
9. If git-tracked, commit the reset with a message noting which DevFoundry template commit/version the new project started from, for traceability.

## What this does not do
- Does not change any standing process decision (e.g. "RouteKit is the sanctioned ASP Classic framework," recorded in `.devfoundry/rules/legacy-asp-vb6.md` and `.devfoundry/references/asp-classic-framework.md`) — those survive a reset by design; only the dated spec/log history is cleared.
- Does not run as part of the normal Requirements Analyst → ... → Archive lifecycle — it is a separate, manually-triggered adoption action, run at most once per new project.