savepoint 1.0.4 → 1.0.6

package/templates/project/.savepoint/router.md

@@ -1,153 +0,0 @@
-# Agent State Machine
-
-This file routes the agent based on the project's current state. Read this whenever you start a session.
-
-## Read order on every session
-
-1. This file (you are here)
-2. The current state below to know what to do next
-3. The active epic Design
-4. The active task file, when a task is selected
-
-Read `.savepoint/PRD.md` only for project vision changes. Read `.savepoint/Design.md` only for architecture changes or audit closeout. Read `.savepoint/releases/{release}/{release}-PRD.md` only for release planning or epic-order questions.
-
-**Conditional read (token discipline):** if your active task touches **Ink/TUI implementation**, also read `agent-skills/ink-tui-design/SKILL.md` after Design.md as the execution guide. If it touches **TUI rendering, theme, or visual design**, also read `.savepoint/visual-identity.md` as the visual guardrails. Otherwise skip the extra files — they are tokens you do not need.
-
-## Current state
-
-```yaml
-state: pre-implementation
-release: v{{RELEASE_NUMBER}}
-epic: none
-task: none
-next_action: "The project has its PRD and Design locked but no epics defined yet. Help the user define the epics list and confirm priority."
-```
-
-## Manual audit override
-
-If the user explicitly asks you to audit an epic, perform the audit for that epic even if the router has not reached `state: audit-pending` yet.
-
-Persist the audit artifact before replying:
-
-- Write exactly one `.savepoint/releases/{release}/epics/{E##-epic}/E##-Audit.md`.
-- Include `## Main Findings`, `## Code Style Review`, and `## Proposed Changes`.
-- Keep file-specific `### Target File` / `### Replace` / `### With` blocks under `## Proposed Changes`.
-- Do not apply proposals or mark the epic audited until the user says `apply audit`.
-
-## State → next action
-
-<!-- AGENT: Read the state above. Find the matching block below. Follow it. -->
-
-### `state: pre-implementation`
-
-The project has its PRD and Design locked but no epics defined yet.
-
-**Next action:**
-
-1. Read `.savepoint/releases/{release}/{release}-PRD.md` — the release scope (epic list lives there).
-2. Help the user define the epics list and confirm priority.
-3. For each epic in order, create the directory `.savepoint/releases/{release}/epics/E##-{epic-name}/` with a `Design.md` stub.
-4. When epic E01 (scaffolding) is created, transition to `state: epic-design` for that epic.
-
-**Do not** start writing code. We are still in planning.
-
-### `state: epic-design`
-
-An epic exists but its `Design.md` is empty or a stub.
-
-**Next action:** Walk the user through filling out the epic's `Design.md`:
-
-- What is this epic adding to the system?
-- What components / files does it touch?
-- What's the architectural delta vs the current state?
-
-When complete, transition to `state: epic-task-breakdown` for this epic.
-
-### `state: epic-task-breakdown`
-
-Epic Design exists but tasks are missing or not fully planned.
-
-**Next action:**
-
-1. Re-read the epic Design.
-2. Create or update the full epic task list — each task **independently buildable**, **objective-led**, with declared `depends_on`.
-3. Each task file lives at `.savepoint/releases/{release}/epics/{E##-epic}/tasks/TNNN-slug.md` with frontmatter:
-   ```yaml
-   ---
-   id: {E##-epic}/TNNN-slug
-   status: planned
-   objective: "<one sentence>"
-   depends_on: []
-   ---
-   ```
-4. In the same pass, write each task's `## Acceptance Criteria` (observable outcomes that define "done") and `## Implementation Plan` (the build checklist that satisfies them) as inline `- [ ]` checkboxes, plus a `## Context Log` section with `Files read`, `Estimated input tokens`, and `Notes` fields.
-5. When every task is planned, transition to `state: task-building` for the first unblocked task.
-
-### `state: task-planning`
-
-Reserved for repair or late-added tasks. Normal epic planning happens during `state: epic-task-breakdown`.
-
-**Next action:** Read the task's `objective`. Write `## Acceptance Criteria` (observable outcomes) before `## Implementation Plan` (build checklist). Use inline `- [ ]` checkboxes under the plan, add a `## Context Log` section, set `status: planned`, and stop.
-
-### `state: task-building`
-
-Task is `in_progress`. All `depends_on` are `done`.
-
-**Next action:** Execute the plan. Tick checkboxes as you complete them. The implementation checklist exists to satisfy the task's acceptance criteria; every checked box should map to an observable outcome in `## Acceptance Criteria`. Edit code per the **Code Style** rules in `AGENTS.md`. Before setting `status: done`, update the task's `## Context Log`. When all checkboxes tick, run the full quality-gate suite, set `status: done`, update the router, and **stop for user review**.
-
-**Do not start the next task without user acknowledgment.**
-
-### `state: audit-pending`
-
-The last task in an epic is `done`. Audit must run before the next epic starts.
-
-**Context gate:** If you just built this epic in the current session, you **must not** audit it. Close this session. The user should start a new session for the audit.
-
-**Next action (fresh session only):** Read the epic's `E##-Detail.md`, task files, drift notes, `.savepoint/Design.md`, `AGENTS.md`, and scoped changed files. Write one epic-local audit file to `.savepoint/releases/{release}/epics/{E##-epic}/E##-Audit.md`:
-
-- `## Main Findings` — user-facing AC verification, important drift, and notable risks.
-- `## Code Style Review` — checklist against the 10 AGENTS.md code style rules.
-- `## Proposed Changes` — admin/apply metadata using `### Target File`, `### Replace`, and `### With`.
-
-Prefer delta-only edits (`Insert After`, `Replace`, `Delete`) anchored to exact text. Do not quote and replace entire large sections unless the whole section genuinely changed.
-
-Proposal format:
-
-```md
-## Target File
-
-`path/to/file.md`
-
-## Replace
-
-<exact old heading, marker, or section>
-
-## With
-
-<new content>
-```
-
-Quality review section format:
-
-```md
-## Must Fix Before Close
-
-## Must Fix Before Next Epic
-
-## Carry Forward
-
-## Already Fixed
-```
-
-After proposals are approved, apply approved proposals to live files, mark the epic `E##-Detail.md` as `status: audited`, update project `Design.md` `last_audited`, refresh `AGENTS.md` Codebase Map if needed, and advance this router to the next epic state.
-
-Stop. The user reviews proposals in the TUI before commit actions.
-
-## Capability check
-
-If you are not Claude Opus / Gemini 2.5 Pro / GPT-5.5 / equivalent, surface a warning to the user:
-
-> _"Heads up — I'm running on a lighter model. Savepoint's planning steps work best with top-tier models because the embedded prompts are detailed. I'll do my best, but consider switching the model for PRD/Design/Task-breakdown steps."_
-
-Then proceed.
- proceed.

package/templates/project/.savepoint/visual-identity.md

@@ -1,122 +0,0 @@
----
-type: visual-identity
-status: active
-last_audited: never
----
-
-# Visual Identity — Atari-Noir
-
-> The brand identity and visual guardrails for {{PROJECT_NAME}}. **Loaded conditionally** — only when working on TUI rendering, theme, or design-system tasks. Non-visual tasks must skip this file to honor the token budget.
-
-## Vibe
-
-A serious digital system that loves old arcade hardware. Dark, cinematic, playful. Crisp, not noisy. Technical, not cold.
-
-**Avoid:** neon cyberpunk chaos, SaaS minimalism, fake terminal gimmicks.
-
-## Palette
-
-| Element       | Hex       | Role                          |
-| ------------- | --------- | ----------------------------- |
-| Background    | `#121212` | Main screen background        |
-| Surface       | `#0D0D0D` | Cards and panels              |
-| Surface 2     | `#0F0F0F` | Secondary panels / title bars |
-| Border        | `#1A1A1A` | Quiet structural edges        |
-| Border Subtle | `#222222` | Slightly stronger separators  |
-| Primary Text  | `#F0E6DA` | Warm off-white terminal text  |
-| Atari Orange  | `#FC6323` | Primary CTA, active highlight |
-| NPP Green     | `#A4C639` | Success, live systems         |
-| Vibe Purple   | `#B1A1DF` | AI, reflection                |
-
-**Color rules:**
-
-- **Intentional accents.** One accent color per major section/type. Use for labels, hover, glows, active text — never giant background fills.
-- **Dark backgrounds.** Keep them dark so accents pop.
-- **Visual encoding.** Color semantically encodes categories or states; reinforce with minimal text.
-
-## Typography
-
-- **System heading font:** `Chakra Petch` (web only — terminal cannot control fonts)
-- **System body/UI font:** `Space Mono` (web only — terminal cannot control fonts)
-- **Accent retro fonts:** `Silkscreen` or `Press Start 2P`, used rarely for score counters or deliberately extreme moments
-
-**Rules:**
-
-- Headings uppercase, with deliberate letter-spacing where the medium allows.
-- Body readable and restrained; abandon monospace for long text if readability suffers.
-- Render magnitude/comparison numbers as proportional visuals (bars, circles), not raw values.
-
-## Spacing rhythm
-
-- Sections breathe. Default spacing feels generous.
-- Cards have enough internal padding to feel like panels, not chips.
-- Whitespace creates hierarchy before borders or color do.
-
-## Signature UI patterns
-
-- **Scanlines** — low-opacity CRT atmosphere; never obscure readability.
-- **Glows** — radiate from perimeter ("lit from within"). Transparent section accent colors; no neon spam.
-- **Panels** — flat, dark, structured with quiet borders. Depth from contrast/glow, not heavy shadows.
-- **Search** — simple, single-line; integrated with section accent color.
-- **MDX prose** — integrated using standard typography, palette, border logic.
-
-## Interaction principles ("The Playable Dashboard")
-
-**Content is the interface.** Avoid traditional UI patterns (dropdowns, accordions) if content can express the information directly.
-
-- **Show, don't explain.** Visuals (scaled circles, markers) before text.
-- **Motion** — authored, not generic. Ease like a system booting up. No bouncy toy motion.
-- **Hover & focus** — internal light (underglow/surface tint), not thick outlines or loud transforms.
-- **Expansion** — breathe open, don't snap. Inline reveals, shared-element transitions.
-
-## Replication brief
-
-If recreating this look-and-feel, preserve:
-
-- dark charcoal background with warm off-white text
-- three-color accent system (one per major section)
-- `Chakra Petch` for headings, `Space Mono` for body/UI (where typography can be controlled)
-- uppercase, tracked headings
-- quiet borders, dark surfaces, selective glow
-- one strong interactive hero element
-- copy that sounds human, competent, intentionally non-corporate
-- **Young Explorer Baseline:** all content and visuals understandable by a 7-year-old. Intuitive visual metaphors, no unexplained jargon, discoverable through play.
-
-**Family resemblance, not exact duplication.** Preserve the underlying feel, hierarchy, restraint.
-
-## Flex & constraints
-
-- **Layout & components:** can adapt to content needs, provided palette discipline and tonal restraint remain.
-- **Fonts:** supporting fonts can vary if heading/body contrast remains.
-- **Hero:** interaction can vary, but requires one strong, ownable interactive element.
-- **Visual-first:** show relationships visually before explaining them in text (gradient bar > numbers). Text reinforces; visuals carry comprehension.
-- **Cognitive accessibility:** anchor complex concepts to physical/visual analogies a 7-year-old can grasp.
-
-## What survives in the terminal
-
-| Web rule                            | Terminal feasibility | Adaptation                                                       |
-| ----------------------------------- | -------------------- | ---------------------------------------------------------------- |
-| Dark bg + warm off-white text       | ✓                    | 24-bit color with 256/16-color fallbacks                         |
-| 3-color accent system               | ✓                    | per status, per epic, per section                                |
-| `Chakra Petch` / `Space Mono` fonts | ✗                    | terminal owns the font; README discloses                         |
-| Uppercase tracked headings          | ⚠                    | uppercase yes; letter-spacing no (fixed-width cells)             |
-| Scanlines                           | ✗                    | flicker/ugly in text — skip                                      |
-| Glows / underglow                   | ⚠                    | substitute with subtle bg tint on focused row + accent border    |
-| Quiet borders, dark surfaces        | ✓                    | box-drawing chars (`─ │ ┌ ┐`) in border-subtle gray              |
-| Inline reveal cards                 | ✓                    | Ink state-driven expand/collapse                                 |
-| Visual encoding before text         | ✓                    | colored glyphs (`▣ ◇ ◆ ✓`) with text reinforcement               |
-| "System booting up" motion          | ⚠                    | 200ms init sequence on launch acceptable; running animation skip |
-
-## Terminal UI guardrails
-
-- Keep UI state explicit and local to the smallest useful surface.
-- Use project data files as the source of truth; do not invent hidden UI state.
-- Keep layout compact and readable on narrow terminals first.
-- Treat accidental line wrapping as a bug.
-- Make selection, focus, and status changes obvious without relying on color alone.
-- Make every keyboard action predictable and idempotent.
-- Test branching input handling, navigation, state transitions, render output, and non-TTY fallbacks.
-
-## When `savepoint init` ships
-
-This file is the canonical default that `savepoint init` writes into a user's `.savepoint/visual-identity.md`. Users replace it with their own design system. The file's existence (not its contents) is what `savepoint` cares about.

package/templates/project/AGENTS.md

@@ -1,88 +0,0 @@
-# Agents Guide
-
-## Workflow
-
-1. Read `.savepoint/router.md` — state + next action
-2. Activate skill per table below
-3. Read: router → epic → task → source files
-
-## Skill Activation
-
-| State | Skill |
-|-------|-------|
-| pre-implementation | savepoint-draft-prd |
-| epic-design | savepoint-system-design |
-| epic-task-breakdown | savepoint-create-task |
-| task-building | savepoint-build-task |
-| audit-pending | savepoint-audit |
-
-Use the `skill` tool when the listed skill is available. If the agent says the skill is not found, read `agent-skills/{skill}/SKILL.md` directly and follow it as the active skill.
-
-Read `.savepoint/PRD.md` only for vision changes, `.savepoint/Design.md` only for architecture/audit.
-
-## Task Status
-
-- `status`: only `planned`, `in_progress`, or `done`
-- `stage` (build/test/audit): **required** when `status: in_progress` — omitting it is a parse error
-- Never: todo, doing, blocked, review, audit
-- Agents may set a task to `status: in_progress` when starting implementation.
-- Only the user may set a task to `status: done` or retreat a task to an earlier status.
-
-## Implementation
-
-1. Read task's `## Context Files` using `Read` tool — one call per file, no explore, no glob
-2. Read task's `## Acceptance Criteria` + `## Implementation Plan`
-3. When starting implementation, set task frontmatter to `status: in_progress` + `stage: build` (both required together)
-4. After setting `in_progress`, press `p` in the TUI to mark the focused task as router priority
-5. Execute in order, tick checkboxes
-6. Verify every AC has passing test/outcome
-7. Run quality gates (build + test)
-8. Update router.md: next task or `audit-pending`
-9. **Stop. Prompt user before continuing.**
-
-## Drift Check
-
-- New files/modules not in Codebase Map?
-- Architecture changed from Design.md?
-
-If yes → append `## Drift Notes` to task file.
-
-## Audit Handoff
-
-The agent that builds an epic **must not audit it**. Start a fresh session.
-
-## Audit File Structure
-
-- Audit is agent-led via `savepoint-audit`, not a `savepoint audit` CLI pipeline.
-- Write exactly one `.savepoint/releases/{release}/epics/{E##-slug}/E##-Audit.md`.
-- The TUI Audit tab renders `## Main Findings` and `## Code Style Review` only.
-- Keep file-specific `### Target File` / `### Replace` / `### With` blocks under `## Proposed Changes` so admin apply details do not appear in the Epic Detail panel.
-- During audit apply/close, update the same `E##-Audit.md` visible sections so `## Main Findings` and `## Code Style Review` describe the applied outcome, not stale pre-apply blockers.
-
-## Code Style
-
-- **One job per file** — split files when responsibilities mix.
-- **One job per function** — small, named, testable units.
-- **Test branches** — cover meaningful conditionals and edge cases.
-- **Types document intent** — prefer explicit types over comments.
-- **Build only what is needed** — no speculative abstractions.
-- **Handle errors at boundaries** — validate inputs, APIs, IO, and external data.
-- **One source of truth** — no duplicated rules, constants, state, or config.
-- **Comments explain why** — not what the code already says.
-- **Content lives in data** — keep copy/config out of logic.
-- **Small diffs** — minimal, reviewable, behaviour-preserving changes.
-
-## Build
-
-```bash
-make build && make test
-```
-
-## Codebase Map
-
-| Module | Epic | Purpose |
-|--------|------|---------|
-
-## CLI Rules
-
-**Never run `savepoint` commands.** The CLI is for the human. Edit files directly.

package/templates/project/agent-skills/savepoint-audit/SKILL.md

@@ -1,87 +0,0 @@
----
-name: savepoint-audit
-description: Performs Savepoint audit-pending work for a completed epic, reviewing implementation against task acceptance criteria and writing the required E##-Audit.md handoff file.
----
-
-# Savepoint Skill: Audit (`audit`)
-
-## Objective
-At the end of an epic, review the implemented code against the Epic objectives and Task Acceptance Criteria, and reconcile any documentation "Drift".
-
-## Context
-The Audit Gate is Savepoint's wedge. It prevents projects from degrading into chaos. The `audit` agent acts as the Quality Assurance and Documentation Lead. It reviews the work of the `build-task` agent with "fresh eyes," ensuring that the `Design.md` and the `AGENTS.md` Codebase Map reflect the actual reality of the codebase before the next Epic begins.
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `audit-pending`.
-
-## Input
-- `.savepoint/releases/{release}/epics/{E##-slug}/E##-Detail.md` (the epic design).
-- `.savepoint/Design.md` (project architecture).
-- `AGENTS.md` (agent guide and codebase map).
-- The source and test files modified during the Epic.
-
-## Workflow
-
-1.  **Fresh Eyes Check:** If you are the exact same agent session that just built the `build-task` code for this Epic, you MUST STOP. Tell the user: "Epic complete. Start a new agent session for the audit."
-2.  **Verify ACs:** Review the completed tasks for the Epic. Ensure the Acceptance Criteria were actually met by the committed code. Also confirm each task file has a `## Context Files` section — flag any missing ones under `## Main Findings` as a process gap.
-3.  **Process Drift Notes (Reconciliation):** Read every task file in the Epic and look for `## Drift Notes`.
-4.  **Draft Audit File:** Based on the code changes and the Drift Notes, write exactly ONE file: `.savepoint/releases/{release}/epics/{E##-slug}/E##-Audit.md`. It must use this format:
-    ````md
-    ---
-    type: audit-findings
-    audited: YYYY-MM-DD
-    ---
-    # Audit Findings: E## {Epic Name}
-
-    ## Main Findings
-    [human-readable audit summary only: AC verification, important drift, and notable risks. Do not include per-file replacement blocks here.]
-
-    ## Code Style Review
-    - [ ] One job per file
-    - [ ] One-sentence functions
-    - [ ] Test branches
-    - [ ] Types are documentation
-    - [ ] Build, don't speculate
-    - [ ] Errors at boundaries
-    - [ ] One source of truth
-    - [ ] Comments explain WHY
-    - [ ] Content in data files
-    - [ ] Small diffs
-
-    ## Proposed Changes
-    ### Target File
-    path/to/file.md
-
-    ### Replace
-    ```
-    exact old text
-    ```
-
-    ### With
-    ```
-    replacement text
-    ```
-    ````
-    The TUI Audit tab renders only `## Main Findings` and `## Code Style Review`. Keep `## Proposed Changes` as admin/apply metadata so the Epic Detail panel does not show stale file-change blocks.
-5.  **Review Format:** Use `### Target File`, `### Replace`, and `### With` formatting only inside `## Proposed Changes`. Include proposals for:
-    *   **Design.md:** Merge the epic's architectural changes into the project-level `Design.md`.
-    *   **AGENTS.md:** Refresh the Codebase Map table with new or changed modules.
-    *   **Epic E##-Detail.md:** Add "Implemented as:" notes showing where reality deviated from the original plan.
-    *   **Implementation fixes:** Include any must-fix code or test changes found during audit.
-6.  **Handoff:** Do not apply the proposals yourself. Do not mark the epic audited. Stop and prompt the user to review `.savepoint/releases/{release}/epics/{E##-slug}/E##-Audit.md` (via the TUI Audit tab). Tell them: "Review the audit tab. When ready, say 'apply audit' to apply proposals and close the epic."
-7.  **Apply + Close** (only when the user approves by saying "apply audit" or equivalent):
-    1.  Read `E##-Audit.md` — extract every `### Target File` / `### Replace` / `### With` block from `## Proposed Changes`.
-    2.  For each pair, apply the replacement to the target file named in the preceding `### Target File` line.
-    3.  Update `E##-Audit.md` visible sections: rewrite `## Main Findings` and `## Code Style Review` so the TUI Audit tab reflects the applied outcome, resolved findings, remaining risks if any, and final code-style status. Keep `## Proposed Changes` intact as admin/apply trace unless the user asks to remove it.
-    4.  Update `E##-Detail.md` frontmatter: set `status: audited`.
-    5.  Update `.savepoint/Design.md` frontmatter: set `last_audited: {release}/{E##-slug}`.
-    6.  Read `.savepoint/router.md` current state. Advance:
-        - If more epics remain in the release: set `state: epic-design`, `epic: {next-epic-slug}`, `task: ""`, `next_action: "Draft epic design"`.
-        - If no more epics: set `state: epic-design`, `epic: ""`, `next_action: "Plan next epic"`.
-    7.  Print apply summary: "Applied X proposals. Updated audit findings. Epic {E##} closed as audited. Router → {new state}."
-
-## Constraints
-- **Do not write product code.** You are an auditor.
-- **Do not apply the changes immediately.** Write the proposals document first.
-- **One proposals file.** Do not create multiple proposal files.
-- **No CLI audit pipeline.** Savepoint audit is agent-led and skill-driven; do not invoke or design around a `savepoint audit` command.

package/templates/project/agent-skills/savepoint-build-task/SKILL.md

@@ -1,44 +0,0 @@
----
-name: savepoint-build-task
-description: Executes Savepoint task-building work when .savepoint/router.md state is task-building, including implementing one active task, checking acceptance criteria, running quality gates, and stopping for user review.
----
-
-# Savepoint Skill: Build Task (`build-task`)
-
-## Objective
-Act as a disciplined coding agent that strictly follows Savepoint's implementation loop.
-
-## Context
-The `build-task` skill is the execution engine. It reads the detailed task plan, writes the code, and proves that the Acceptance Criteria (ACs) have been met. It is strictly constrained to the scope of the single active task. It does not rewrite architecture, and it does not fix unrelated bugs.
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `task-building` and points to a specific task file.
-
-## Input
-- `.savepoint/router.md` (Current state).
-- The active epic E##-Detail.md: `.savepoint/releases/v1/epics/{E##-epic}/E##-Detail.md`.
-- The active task file: `.savepoint/releases/v1/epics/{E##-epic}/tasks/{T###}-*.md`.
-- Directly touched source/test files.
-
-## Workflow
-
-1.  **Read the Task Plan:** Review the `## Acceptance Criteria` and the `## Implementation Plan`.
-2.  **Test-First Implementation:** If testing is part of the project constraints, write the focused tests for the required behavior first.
-3.  **Execute:** Write the code to check off every item in the `## Implementation Plan`.
-4.  **Validate ACs:** You must verify that every single item in the `## Acceptance Criteria` has been met. A task is not done just because the code is written; it is done when the ACs are demonstrably true.
-5.  **Run Quality Gates:** Run the project's build, lint, and test commands (e.g., `npm run build && npm test` or `go test ./...`).
-6.  **Log Context:** Fill out the `## Context Log` at the bottom of the task file:
-    *   List files read/edited.
-    *   Estimate tokens used.
-    *   Record the result of the quality gates.
-7.  **Log Drift Notes:** **CRITICAL STEP.** Ask yourself:
-    *   Did I add new source files, modules, or exports not listed in the `AGENTS.md` Codebase Map?
-    *   Did I change the architecture from what `.savepoint/Design.md` describes?
-    *   If YES to either, append a `## Drift Notes` section to the bottom of the task file explaining what changed. DO NOT edit `Design.md` or `AGENTS.md` yourself. The `audit` agent will handle that later.
-8.  **Status Update:** Change the task frontmatter to `status: done`.
-9.  **Handoff:** Update `router.md` to point to the next unblocked task. If all tasks in the Epic are done, update it to `state: audit-pending`.
-10. **Stop:** Prompt the user: "Task {id} is done. Quality gates passed. Review the changes, then tell me to continue." Do not start the next task automatically.
-
-## Constraints
-- **Stay in scope:** Do not touch files outside of what is required for the Acceptance Criteria.
-- **Do not edit architecture documents.** If you must deviate from the plan, write the code and log a "Drift Note" in the task file.

package/templates/project/agent-skills/savepoint-create-plan/SKILL.md

@@ -1,33 +0,0 @@
----
-name: savepoint-create-plan
-description: Creates Savepoint release epics from the PRD and Design documents when the router is in pre-implementation planning.
----
-
-# Savepoint Skill: Create Plan (`create-plan`)
-
-## Objective
-Turn the Product Requirements Document (PRD) and the architectural `Design.md` into Epics (logical slices of work) and high-level tasks that can be implemented independently.
-
-## Context
-Savepoint enforces small scopes to prevent AI agents from "wandering." The `create-plan` skill acts as the Technical Project Manager. It takes the grand vision and the architectural blueprint and slices it into a sequence of achievable, testable milestones (Epics).
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `pre-implementation`.
-
-## Input
-- `.savepoint/PRD.md` (Vision and constraints)
-- `.savepoint/Design.md` (Architecture and layout)
-- `.savepoint/releases/v1/v1-PRD.md` (Optional: Release-scoped PRD)
-
-## Workflow
-
-1.  **Read the Context:** Consume the PRD and Design documents to understand the scope and technical constraints.
-2.  **Define Epics:** Group the work into high-level features or milestones. Name them clearly (e.g., `E01-scaffolding`, `E02-database`, `E03-auth`). Each Epic must represent a deliverable slice of value.
-3.  **Draft Epic Designs:** For each Epic, create a shell `E##-Detail.md` inside `.savepoint/releases/v1/epics/{E##-epic-name}/E##-Detail.md`. This file should describe the *delta* (what this specific epic adds to the overall architecture).
-4.  **Breakdown Tasks (High Level):** Inside each Epic folder, list out the high-level tasks required to complete it. Do not write full implementation plans yet—just identify the discrete chunks of work (e.g., `T001-setup-repo.md`, `T002-init-db.md`).
-5.  **Order and Dependency:** Ensure the Epics and tasks are ordered logically. You cannot build the frontend auth UI (E03) before the database models (E02) exist.
-6.  **Handoff:** Update `.savepoint/router.md` to `state: task-breakdown` and point it at the first Epic. Prompt the user to review the Epic list.
-
-## Constraints
-- **Do not write code.**
-- **Do not write detailed implementation steps.** That is the job of the `create-task` skill. Keep the task outlines high-level at this stage.

package/templates/project/agent-skills/savepoint-create-task/SKILL.md

@@ -1,44 +0,0 @@
----
-name: savepoint-create-task
-description: Plans Savepoint task files during epic-task-breakdown by writing acceptance criteria, implementation checklists, dependencies, and context-log shells.
----
-
-# Savepoint Skill: Create Task (`create-task`)
-
-## Objective
-Take high-level tasks identified during the planning phase and build detailed, actionable task plans with strict Acceptance Criteria.
-
-## Context
-A task plan is a contract between the planner and the builder. If the task plan is vague, the resulting code will be buggy. The `create-task` skill acts as a Senior Engineer writing tickets for a Junior Developer (the `build-task` agent). It must define exactly *what* constitutes success and *how* to achieve it, without actually writing the code.
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `epic-task-breakdown` and the router points to a specific epic.
-
-## Input
-- `.savepoint/releases/v1/epics/{E##-epic}/E##-Detail.md` (The active Epic's design).
-- The high-level task markdown file (e.g., `.savepoint/releases/v1/epics/{E##-epic}/tasks/T001-slug.md`).
-
-## Workflow
-
-1.  **Read Context:** Understand the goal of the specific task within the context of its parent Epic.
-2.  **Define Acceptance Criteria (ACs):** This is the most critical step. Write explicit, observable outcomes. (e.g., "Running `npm test` passes 5 tests for the auth module" or "The `/login` route returns a 200 OK with a valid JWT"). Do not use subjective language like "looks good."
-3.  **Draft Implementation Plan:** Create a step-by-step checklist for the `build-task` agent to follow.
-    *   List which files need to be created or modified.
-    *   Specify which functions or components need to be written.
-    *   Include instructions to write tests *first* if applicable.
-4.  **Populate Context Files:** Add a `## Context Files` section listing the exact file paths the build agent must read before coding. Pull these from the epic's Components table — only the files this task actually touches or depends on. Example:
-    ```markdown
-    ## Context Files
-    - `internal/board/board.go`
-    - `internal/board/model.go`
-    - `internal/data/config.go`
-    ```
-    No globs. No directories. Exact paths only.
-5.  **Add Context Log Shell:** Ensure the bottom of the task file includes a `## Context Log` section with placeholders for `Files read:`, `Estimated input tokens:`, and `Notes:`.
-5.  **Define Dependencies:** If this task relies on another task being completed first, explicitly declare it in the YAML frontmatter (e.g., `depends_on: [T001-setup]`).
-6.  **Status Update:** Change the task frontmatter to `status: planned`.
-7.  **Handoff:** Update `.savepoint/router.md` to `state: in-progress` and ensure it points to the newly planned task. Prompt the user to approve the task plan before building begins.
-
-## Constraints
-- **Do not write code.** Your job is to plan the work, not execute it.
-- **Keep it isolated:** The task plan should touch as few files as possible. If a task plan requires modifying 15 files, it is too large and should be broken down further.

package/templates/project/agent-skills/savepoint-draft-prd/SKILL.md

@@ -1,37 +0,0 @@
----
-name: savepoint-draft-prd
-description: Guides Savepoint PRD drafting and refinement before implementation, interviewing the user until the product scope is clear enough for design.
----
-
-# Savepoint Skill: Draft PRD (`draft-prd`)
-
-## Objective
-Help the user write a structured, sufficiently detailed Product Requirements Document (PRD) before any design or planning occurs.
-
-## Context
-In the Savepoint workflow, the PRD is the absolute source of truth. If the PRD is a vague brain-dump, the resulting architecture and code will be a mess. Your job as the `draft-prd` agent is to act as a strict Product Manager. You do not write code. You interrogate the user's idea until it is crisp enough to build a V1.
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `pre-implementation` or when the user explicitly asks you to help them write or refine their PRD.
-
-## Input
-- The user's initial idea, brain-dump, or `.txt` file outline.
-- The template located at `.savepoint/PRD.md`.
-
-## Workflow
-
-1.  **Read the Template:** Review the current state of `.savepoint/PRD.md`. If it is the default template (mostly comments), prepare to interview the user.
-2.  **Interrogation (The Grill):** Do not immediately overwrite the file with guesses. If the user's input lacks:
-    *   A specific core mechanic.
-    *   A defined target user.
-    *   Clear V1 constraints (e.g., tech stack).
-    *   Explicit "Out of scope" items.
-    ...you MUST ask them questions. Force them to define boundaries.
-3.  **Synthesis:** Once you have sufficient detail, synthesize the conversation into the `.savepoint/PRD.md` file, strictly adhering to its markdown structure. Remove the instructional HTML comments as you fill in each section.
-4.  **The V1 Gate:** Review the final document. If the scope still feels too large for a rapid MVP (e.g., "Build a full clone of Jira with AI"), warn the user. Suggest moving features to the "Out of Scope" section for V1.
-5.  **Handoff:** Once the PRD is solid and approved by the user, update `.savepoint/router.md` to `state: design`. Instruct the user to review the PRD and then prompt the agent to continue to the design phase.
-
-## Constraints
-- **Do not write code.**
-- **Do not plan Epics.** That is the job of the `create-plan` skill.
-- **Do not make technical architectural decisions.** That is the job of the `system-design` skill. Your focus is strictly on *what* and *why*, not *how*.

package/templates/project/agent-skills/savepoint-system-design/SKILL.md

@@ -1,38 +0,0 @@
----
-name: savepoint-system-design
-description: Produces Savepoint system or epic design documents from the PRD when the router is in epic-design or the user asks for architectural design.
----
-
-# Savepoint Skill: System Design (`system-design`)
-
-## Objective
-Translate the Product Requirements Document (PRD) into the initial architectural blueprint (`Design.md`) before the planning phase breaks the work down into Epics.
-
-## Context
-Before any tasks can be planned, the project needs a high-level technical direction. The `system-design` skill acts as the Staff Engineer. It reads the vision and constraints from the PRD and makes authoritative technical decisions regarding architecture, directory layout, dependency strategies, and workflow rules.
-
-## Trigger
-This skill is activated when the `.savepoint/router.md` state is `epic-design` or when the user explicitly asks to design the system based on the PRD.
-
-## Input
-- `.savepoint/PRD.md` (The source of truth for "what" and "why").
-- Any existing template or shell in `.savepoint/Design.md`.
-
-## Workflow
-
-1.  **Read the PRD:** Analyze `.savepoint/PRD.md` to understand the goal, constraints (e.g., tech stack, budget), and what is out of scope.
-2.  **Architectural Mapping:** Make firm, opinionated technical decisions that solve the PRD's goals. Do not offer options unless absolutely necessary; pick a path and justify it briefly.
-3.  **Draft `.savepoint/Design.md`:** Write or update the architectural design document. It must include:
-    *   **Architecture Model:** The core pattern (e.g., "File-only state machine," "Client-side React with Firebase," "CLI Tool").
-    *   **Directory Layout:** A clear, visual tree mapping out the structure of the project (`src/`, `test/`, etc.).
-    *   **Hierarchy Semantics:** Definitions of what constitutes an Epic vs. a Task.
-    *   **Status Model & Gates:** How work moves from `planned` to `done`.
-    *   **Dependencies:** How modules or tasks rely on each other.
-    *   **CLI Surface/API Contract:** If applicable, define the boundary interactions.
-4.  **Review Against Constraints:** Ensure your design strictly adheres to the constraints and out-of-scope items listed in the PRD. If the PRD says "no database," do not add a database to the architecture.
-5.  **Handoff:** Update `.savepoint/router.md` to `state: planning`. Instruct the user to review the `Design.md` and then prompt the agent to start the epic breakdown.
-
-## Constraints
-- **Do not write code.**
-- **Do not break down tasks.** That is the job of the `create-plan` skill.
-- **Maintain Token Discipline:** Keep the `Design.md` concise. It is meant to be read by AI agents on every turn. Rambling design docs destroy context windows.