DevFoundry/.devfoundry/skills/new-project-reset.md

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.