SPEC-006: add new-project-reset skill for adopting this template

Adds .devfoundry/skills/new-project-reset.md: a one-time, explicitly-triggered
procedure for clearing DevFoundry's own internal process-development history
(specs/archive/, specs/active/, specs/.spec-counter, improvement-log.md
entries, and any residual project-specific facts in .devfoundry/references/)
when this template is copied to start a real project. It never runs
automatically or as part of the normal per-spec Archive step (AGENTS.md
Collaboration Rule 6 makes that explicit).

The skill was authored but deliberately not run against this repo - the
archive still holds SPEC-001 through SPEC-006 intact.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.devfoundry/improvement-log.md

@@ -53,3 +53,11 @@ Maintained by the Process Improver: on every new log entry below *whose Category
 - **Affected file:** `.devfoundry/skills/spec-interview.md`
 - **Proposed change:** Not yet escalated — first occurrence of this specific gap (below the 3-occurrence threshold). If a future spec repeats this same "which repo should this actually target" confusion, escalate by adding an explicit question to `spec-interview.md` step 2 (or a new step) asking whether the work belongs in this repo or in a separate project repo that adopts DevFoundry.
 - **Status:** LOGGED
+
+## 2026-08-19 — SPEC-006
+- **What worked:** Asking two direct clarifying questions before writing anything (one-time adoption reset vs. recurring per-spec action; delete vs. cold-storage disposition) avoided building a more destructive mechanism than intended — "clear the archive" had a plausible reading that would have silently wiped audit trail on every new spec.
+- **Friction:** none
+- **Category:** none
+- **Affected file:** none
+- **Proposed change:** none
+- **Status:** LOGGED

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

@@ -0,0 +1,20 @@
+# 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.

AGENTS.md

@@ -48,3 +48,4 @@
 3. **Context Passing:** When adopting a role, explicitly reference the persona markdown file in `.devfoundry/personas/` and apply the relevant procedures in `.devfoundry/skills/`.
 4. **Audit Gate:** Builder task checkboxes may be marked complete after their local verification passes, but a spec is only marked `COMPLETED` when the QA Verifier confirms all acceptance criteria pass without regression.
 5. **Continuous Improvement Loop:** Every spec passes through the Process Improver before archiving. Lessons are appended to `.devfoundry/improvement-log.md`; friction that recurs 3+ times must be escalated into a proposed amendment to the relevant rule, skill, persona, or reference file, subject to user approval. This is how the workflow itself improves rather than repeating the same manual corrections across specs.
+6. **Archive Reset Is Not Part of This Lifecycle:** Clearing `specs/archive/` (e.g. when this template is adopted to start a new project) uses `.devfoundry/skills/new-project-reset.md` and only ever runs on explicit request — never automatically, never as a substitute for the normal Archive step above.

README.md

@@ -142,3 +142,8 @@ See [.devfoundry/rules/dotnet-csharp.md](.devfoundry/rules/dotnet-csharp.md), [.
 | `ABANDONED` | User cancellation, recorded by the agent | Draft work was cancelled before approval; the spec is archived and its ID is never reused. |
 
 A spec can also move `APPROVED`/`IN PROGRESS` → `REVISED` if the user requests a genuine scope change after freeze — see "Amending an APPROVED or IN PROGRESS Spec" in [.devfoundry/skills/technical-spec.md](.devfoundry/skills/technical-spec.md). Once the revision is approved, it returns to `APPROVED` or `IN PROGRESS` and continues toward `COMPLETED`.
+
+## Adopting This Template for a New Project
+This repo's own `specs/archive/` currently holds DevFoundry's *own* process-development history (spec IDs documenting how this template itself was hardened) — not any real project's history. When this template is copied to start an actual new project, that history should be cleared out first, so the new project's spec archive starts empty and its IDs start at `SPEC-001`.
+
+This is a one-time, explicitly-requested action — see [.devfoundry/skills/new-project-reset.md](.devfoundry/skills/new-project-reset.md) for the exact steps (clear `specs/archive/` and `specs/active/`, reset `specs/.spec-counter` to `1`, clear `.devfoundry/improvement-log.md`'s entries, and re-check `.devfoundry/references/` for any leftover project-specific facts). It never runs automatically — ask for it by name ("reset this for a new project") when you're ready to start using the adopted copy for real work. The process itself — `.devfoundry/rules/`, `.devfoundry/personas/`, `.devfoundry/skills/`, `specs/templates/` — is what's being adopted, and is left untouched by the reset.

specs/.spec-counter

@@ -1 +1 @@
-6
+7

specs/archive/SPEC-006-new-project-reset-skill.md

@@ -0,0 +1,50 @@
+# SPEC-006: New Project Reset Skill
+
+- **Status:** COMPLETED
+- **Stack:** DevFoundry process documentation (template adoption tooling)
+- **Target Files:** `.devfoundry/skills/new-project-reset.md` (new), `README.md`, `AGENTS.md`
+
+---
+
+### 0. Spec Creation Checklist
+- [x] Status is `DRAFT` before user approval.
+- [x] Target Files are listed and checked for overlap with other active specs — `specs/active/` was empty; no conflict.
+- [x] Build/test/lint commands documented — N/A, documentation-only spec.
+- [x] Database changes — none; not applicable.
+- [x] Every implementation task has a preceding test/manual-verification task and `completed:` timestamp space.
+
+### 1. Business Context & Goal
+`specs/archive/` currently holds DevFoundry's own process-development history (SPEC-001–005), not any real project's history — this template has no built-in way to clear that out when it's copied to start an actual new project. The user asked for "a way to clear out the spec archive when we start a new spec." Clarified via two direct questions: (1) this means a one-time reset run when adopting the template for a brand-new project, not a per-spec recurring action, and (2) old specs should be deleted outright, not moved to cold storage — they're DevFoundry's own internal history, not the new project's.
+
+No other active specs existed, so there were no target-file conflicts.
+
+### 2. Acceptance Criteria (Given / When / Then)
+- **AC-1:** Given a user wants to adopt DevFoundry for a new project, when they ask for the reset, then `.devfoundry/skills/new-project-reset.md` gives an explicit, ordered procedure covering `specs/archive/`, `specs/active/`, `specs/.spec-counter`, `.devfoundry/improvement-log.md`, and residual project-specific facts in `.devfoundry/references/`. — **PASS**
+- **AC-2:** Given the skill exists, when an agent might otherwise run it opportunistically, then the skill and `AGENTS.md` both state it only runs on explicit request, never automatically and never as part of the normal spec lifecycle. — **PASS**
+- **AC-3:** Given a user is reading top-level docs, when they open `README.md`, then they find a pointer to this skill explaining why and when to use it. — **PASS**
+- **AC-4:** Given the reset procedure risks discarding in-progress work, when `specs/active/` is non-empty at reset time, then the skill instructs stopping and confirming with the user rather than silently deleting it. — **PASS**
+
+### 3. Technical Design & Contracts
+- **Data Model / Schema Changes:** None. Rollback is a git revert of documentation changes.
+- **Functions / APIs / Interfaces:** None — this is a documented manual/agent-followed procedure, not executable code.
+- **Architecture:** N/A — process documentation only.
+- **Error Handling Strategy:** N/A. The skill's own step 2 covers the "unrecoverable if not git-tracked" risk by requiring explicit confirmation before deleting anything.
+
+### 4. Implementation Plan (Atomic Steps, TDD-ordered)
+- [x] **Step 1 (verification authoring):** Wrote this spec's acceptance criteria, informed by the user's answers to the two clarifying questions, before drafting the skill — files: `specs/active/SPEC-006-new-project-reset-skill.md` — completed: 2026-08-19 23:20
+- [x] **Step 2 (implementation):** Added `.devfoundry/skills/new-project-reset.md` with the ordered reset procedure and explicit-trigger-only guardrail — files: `.devfoundry/skills/new-project-reset.md` — completed: 2026-08-19 23:21
+- [x] **Step 3 (implementation):** Added an "Adopting This Template for a New Project" section to `README.md`, and Collaboration Rule 6 to `AGENTS.md` stating the reset is separate from and never a substitute for the normal Archive step — files: `README.md`, `AGENTS.md` — completed: 2026-08-19 23:22
+- [x] **Step 4 (verification):** Re-read the new skill and both edited docs end-to-end to confirm every acceptance criterion is met and the skill was *not* itself invoked against this repo's real archive — files: listed target files — completed: 2026-08-19 23:23
+
+### 5. Verification & Regression Plan
+- [x] Verify AC-1 by confirming `new-project-reset.md` covers all five listed items (archive, active, counter, improvement-log, references) in an explicit numbered order.
+- [x] Verify AC-2 by confirming both the skill's own header and `AGENTS.md` Collaboration Rule 6 state "only on explicit request."
+- [x] Verify AC-3 by confirming `README.md` contains a section linking to the skill.
+- [x] Verify AC-4 by confirming skill step 4 instructs stopping and confirming rather than silently deleting a non-empty `specs/active/`.
+- [x] Regression check: confirmed `specs/archive/SPEC-001` through `SPEC-005` were **not** deleted by this spec — the skill was authored but deliberately not executed, since the user asked for the capability, not for it to be run yet.
+
+### 6. Retrospective
+*Filled by the Process Improver per `.devfoundry/skills/process-retrospective.md`, after QA approval and before archiving.*
+- **What worked:** Asking two direct clarifying questions before writing anything (scope: one-time adoption reset vs. per-spec; disposition: delete vs. cold-storage) avoided building the wrong, more destructive mechanism — "clear the archive" had at least one plausible reading (recurring, per-spec) that would have silently destroyed audit trail on every cycle.
+- **Friction (rule/reference/interview gap, or none):** none — the existing spec machinery handled this cleanly once scope was confirmed.
+- **Logged in `.devfoundry/improvement-log.md`:** [x] yes