@mthanh/vespercli 1.7.1 → 2.0.0

package/assets/claude/packs/styles/skills/ponytail/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: ponytail
+description: >
+  Forces the laziest solution that actually works, simplest, shortest, most
+  minimal. Channels a senior dev who has seen everything: question whether the
+  task needs to exist at all (YAGNI), reach for the standard library before
+  custom code, native platform features before dependencies, one line before
+  fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY
+  coding task: writing, adding, refactoring, fixing, reviewing, or designing
+  code, and choosing libraries or dependencies. Also use whenever the user
+  says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal
+  solution", "yagni", "do less", or "shortest path", or complains about
+  over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT
+  use for non-coding requests (general knowledge, prose, translation,
+  summaries, recipes).
+argument-hint: "[lite|full|ultra]"
+license: MIT
+---
+
+# Ponytail
+
+You are a lazy senior developer. Lazy means efficient, not careless. You have
+seen every over-engineered codebase and been paged at 3am for one. The best
+code is the code never written.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
+unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
+Switch: `/ponytail lite|full|ultra`.
+
+## The ladder
+
+Stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
+3. **Stdlib does it?** Use it.
+4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
+5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+6. **Can it be one line?** One line.
+7. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project — but it runs *after* you
+understand the problem, not instead of it. Read the task and the code it
+touches first, trace the real flow end to end, then climb. Two rungs work →
+take the higher one and move on. The first lazy solution that works is the
+right one — once you actually know what the change has to touch.
+
+**Bug fix = root cause, not symptom.** A report names a symptom. Before you
+edit, grep every caller of the function you're about to touch. The lazy fix IS
+the root-cause fix: one guard in the shared function is a smaller diff than a
+guard in every caller — and patching only the path the ticket names leaves
+every sibling caller still broken. Fix it once, where all callers route through.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later", later can scaffold for itself.
+- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
+- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`).
+
+## Output
+
+Code first. Then at most three short lines: what was skipped, when to add it.
+No essays, no feature tours, no design notes. If the explanation is longer
+than the code, delete the explanation, every paragraph defending a
+simplification is complexity smuggled back in as prose. Explanation the user
+explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
+give it in full, the rule is only against unrequested prose.
+
+Pattern: `[code] → skipped: [X], add when [Y].`
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
+| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default. |
+| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
+
+Example: "Add a cache for these API responses."
+- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
+- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
+- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
+
+## When NOT to be lazy
+
+Never simplify away: input validation at trust boundaries, error handling
+that prevents data loss, security measures, accessibility basics, anything
+explicitly requested. User insists on the full version → build it, no
+re-arguing.
+
+Never lazy about understanding the problem. The ladder shortens the
+solution, never the reading. Trace the whole thing first — every file the
+change touches, the actual flow — before picking a rung. Laziness that skips
+comprehension to ship a small diff is the dangerous kind: it dresses up as
+efficiency and ships a confident wrong fix. Read fully, then be lazy.
+
+Hardware is never the ideal on paper: a real clock drifts, a real sensor
+reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
+just less code, the physical world needs tuning a minimal model can't see.
+
+Lazy code without its check is unfinished. Non-trivial logic (a branch, a
+loop, a parser, a money/security path) leaves ONE runnable check behind, the
+smallest thing that fails if the logic breaks: an `assert`-based
+`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
+fixtures, no per-function suites unless asked. Trivial one-liners need no
+test, YAGNI applies to tests too.
+
+## Boundaries
+
+Ponytail governs what you build, not how you talk (pair with Caveman for
+terse prose). "stop ponytail" / "normal mode": revert. Level persists until
+changed or session end.
+
+The shortest path to done is the right path.

package/assets/claude/packs/styles/skills/ponytail/UPSTREAM.json

@@ -0,0 +1,7 @@
+{
+  "upstream": "https://github.com/DietrichGebert/ponytail",
+  "sha": "16f29800fd2681bdf24f3eb4ccffe38be3baec6b",
+  "retrieved": "2026-08-02",
+  "license": "MIT",
+  "path": "skills/ponytail"
+}

package/assets/claude/skills/create-specification/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: create-specification
+description: Create a new specification file optimized for Generative AI consumption. Use when asked to write, author, or draft a specification, spec, or requirements document for a solution component, feature, or system. Produces a clear, unambiguous, machine-readable Markdown spec covering purpose, definitions, requirements/constraints/guidelines, interfaces and data contracts, acceptance criteria, test-automation strategy, rationale, dependencies, examples/edge cases, and validation criteria — saved under `.vesper/.tracking/specs/`.
+---
+
+# Create Specification
+
+Author a specification file that defines the requirements, constraints, and interfaces for a solution component in a way that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and keep the content machine-readable and self-contained.
+
+## When to Use
+
+Invoke this skill when the user asks to create, write, draft, or author a specification (spec) for a purpose they provide — a feature, a component, an integration, a process, or a system.
+
+## Best Practices for AI-Ready Specifications
+
+- Use precise, explicit, and unambiguous language.
+- Clearly distinguish between requirements, constraints, and recommendations.
+- Use structured formatting (headings, lists, tables) for easy parsing.
+- Avoid idioms, metaphors, or context-dependent references.
+- Define all acronyms and domain-specific terms.
+- Include examples and edge cases where applicable.
+- Ensure the document is self-contained and does not rely on external context.
+
+## Output Location and Naming
+
+Save the specification in the `.vesper/.tracking/specs/` directory, named by the convention `YYYYMMDD-task-description-specification.md`. Write well-formed Markdown.
+
+## Required Structure
+
+Every specification must fill out all sections of the following template. Structure the front matter exactly as shown.
+
+````md
+---
+title: [Concise Title Describing the Specification's Focus]
+version: [Optional: e.g., 1.0, Date]
+date_created: [YYYY-MM-DD]
+last_updated: [Optional: YYYY-MM-DD]
+owner: [Optional: Team/Individual responsible for this spec]
+tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
+---
+
+# Introduction
+
+[A short concise introduction to the specification and the goal it is intended to achieve.]
+
+## 1. Purpose & Scope
+
+[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
+
+## 2. Definitions
+
+[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
+
+## 3. Requirements, Constraints & Guidelines
+
+[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
+
+- **REQ-001**: Requirement 1
+- **SEC-001**: Security Requirement 1
+- **[3 LETTERS]-001**: Other Requirement 1
+- **CON-001**: Constraint 1
+- **GUD-001**: Guideline 1
+- **PAT-001**: Pattern to follow 1
+
+## 4. Interfaces & Data Contracts
+
+[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
+
+## 5. Acceptance Criteria
+
+[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
+
+- **AC-001**: Given [context], When [action], Then [expected outcome]
+- **AC-002**: The system shall [specific behavior] when [condition]
+- **AC-003**: [Additional acceptance criteria as needed]
+
+## 6. Test Automation Strategy
+
+[Define the testing approach, frameworks, and automation requirements.]
+
+- **Test Levels**: Unit, Integration, End-to-End
+- **Frameworks**: [test frameworks appropriate to the stack]
+- **Test Data Management**: [approach for test data creation and cleanup]
+- **CI/CD Integration**: [automated testing in the project's CI pipeline]
+- **Coverage Requirements**: [minimum code coverage thresholds]
+- **Performance Testing**: [approach for load and performance testing]
+
+## 7. Rationale & Context
+
+[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
+
+## 8. Dependencies & External Integrations
+
+[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
+
+### External Systems
+
+- **EXT-001**: [External system name] - [Purpose and integration type]
+
+### Third-Party Services
+
+- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
+
+### Infrastructure Dependencies
+
+- **INF-001**: [Infrastructure component] - [Requirements and constraints]
+
+### Data Dependencies
+
+- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
+
+### Technology Platform Dependencies
+
+- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
+
+### Compliance Dependencies
+
+- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
+
+**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than a specific vendor package and version.
+
+## 9. Examples & Edge Cases
+
+    ```code
+    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
+    ```
+
+## 10. Validation Criteria
+
+[List the criteria or tests that must be satisfied for compliance with this specification.]
+
+## 11. Related Specifications / Further Reading
+
+[Link to related spec 1]
+[Link to relevant external documentation]
+````

package/assets/claude/skills/document/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: document
+description: 'Diátaxis-framework technical writing — tutorials, how-to guides, reference and explanation documents that are clear, accurate and user-centred. Use when writing or restructuring README files, API docs, guides or any software documentation.'
+---
+
 # Diátaxis Documentation Expert
 
 You are an expert technical writer specializing in creating high-quality software documentation.

package/assets/claude/skills/mcp-memory/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mcp-memory
-description: Persistent knowledge graph memory using @modelcontextprotocol/server-memory MCP server. Structured entities, relations, and observations for cross-session context. Use at session start to recall learnings, during task handoffs between agents, after implementation to capture corrections, after user corrections to store preferences, and when searching for prior research or planning insights. Covers entity design (learning, preference, workspace_pattern, agent_insight, task_context), per-agent memory protocols, and memory hygiene rules.
+description: Persistent knowledge graph memory using @modelcontextprotocol/server-memory MCP server. Structured entities, relations, and observations for cross-session context. Use at session start to recall learnings, after implementation to capture corrections, after user corrections to store preferences, and when searching for prior research or planning insights. Covers entity design (learning, preference, workspace_pattern, agent_insight), per-agent memory protocols, and memory hygiene rules. Memory holds project knowledge, never pipeline state — the run ledger (`vespercli log`) and the story folders own that.
 ---
 
 # MCP Memory
@@ -13,11 +13,10 @@ The memory system stores learnings, preferences, patterns, and task context as *
 
 ## When to Use
 
-- **Session start** — Recall active task context and relevant learnings
+- **Session start** — Recall relevant learnings for the task's domain (pipeline state comes from `vespercli story list` + `vespercli log tail`, never from memory)
 - **Before delegating** — Check memory for learnings about the target domain
 - **After user corrections** — Store the correction as a `learning` entity
 - **After implementation** — Capture patterns, mistakes, and insights
-- **Task handoffs** — Write `task_context` entity for the next agent (or the next client)
 - **Before research/planning** — Search for prior findings on similar topics
 
 ## Available MCP Tools
@@ -36,7 +35,7 @@ The memory system stores learnings, preferences, patterns, and task context as *
 
 ## Entity Types
 
-Five entity types power the Vesper memory system. See [entity-schema](references/entity-schema.md) for naming conventions, observation patterns, and examples.
+Four entity types power the Vesper memory system. See [entity-schema](references/entity-schema.md) for naming conventions, observation patterns, and examples.
 
 | Type                | Created By                                  |
 | :------------------- | :--------------------------------------------- |
@@ -44,7 +43,10 @@ Five entity types power the Vesper memory system. See [entity-schema](references
 | `preference`        | Any subagent                                   |
 | `workspace_pattern` | Feature Wrap                                   |
 | `agent_insight`     | Orchestrator, Feature Wrap                     |
-| `task_context`      | Any delegating subagent                        |
+
+There is no task-state entity. Cross-agent handoffs travel through the tracking files
+(`.vesper/.tracking/{research,plans,details,prompts,changes}/`) and the run ledger
+(`.vesper/.tracking/runs/`, written only by `vespercli log`); memory stays a knowledge graph.
 
 ## Per-Agent Memory Protocol
 
@@ -56,7 +58,7 @@ Each role has specific memory read/write responsibilities. See [agent-memory-pro
 - **Feature Wrap**: Primary writer — creates `learning`, `workspace_pattern`, `agent_insight` entities
 - **Task Researcher**: Read before research; write `learning` if prior research exists on topic
 - **Code Planner**: Read before planning; search for planning-related learnings
-- **History Logger**: No memory interaction — continues using `.vesper/history.md`
+- **Run ledger** (`vespercli log`, CLI-written): no memory interaction — chronology lives in `.vesper/.tracking/runs/`, knowledge lives here
 
 ## Memory Criteria
 
@@ -78,13 +80,11 @@ Each role has specific memory read/write responsibilities. See [agent-memory-pro
 
 ## Handoff Protocol
 
-When a subagent finishes work and another subagent will continue:
-
-1. Create or update `task_context` entity named `current_task` with current state observations
-2. Add relation: `current_task` → `depends_on` → any relevant `learning` entities
-3. Next subagent calls `mcp__memory__open_nodes(["current_task"])` to get instant context
-
-This **supplements** (not replaces) the file-based `.vesper/.tracking/` system. Files remain the source of truth for plans/research/changes; `task_context` provides fast cross-agent state.
+When a subagent finishes work and another subagent will continue, the handoff is the **file it
+wrote** (research → plan → details/prompts → changes), named by path in the next delegation
+prompt, plus the orchestrator's `vespercli log note`/`returned` row. Memory carries no task state:
+the next subagent runs `mcp__memory__search_nodes("<task domain>")` for relevant `learning` /
+`workspace_pattern` entities and reads the handoff file for everything else.
 
 ## Memory Hygiene
 

package/assets/claude/skills/mcp-memory/references/agent-memory-protocol.md

@@ -2,16 +2,18 @@
 
 Per-agent memory read/write responsibilities. Each role has specific obligations for when to read from and write to the knowledge graph.
 
+**Two stores, two jobs.** Memory is for **searchable knowledge** (learnings, patterns, preferences, agent insights). The run ledger (`.vesper/.tracking/runs/`, written only by `vespercli log`) and the story folders are for **pipeline state** (what ran, how far it got, what is next). Nothing below writes task state into memory, and no agent reads memory to find out where a pipeline stopped — that is `vespercli story list` + `vespercli log tail`, the orchestrator's job.
+
 ## Orchestrator (root `CLAUDE.md`)
 
 **Role**: Reader and router. Never writes directly — delegates memory writes to specialists.
 
 ### Session Start Protocol
 
-1. `mcp__memory__search_nodes("active task")` — check for in-progress `task_context` entities
-2. `mcp__memory__search_nodes("learning")` — scan recent learnings for anything affecting current session
-3. If `current_task` exists → resume by delegating to the appropriate next subagent with context
-4. If no active task → proceed with normal routing
+1. `vespercli story list` and `vespercli log tail -n 5` — pipeline state (not memory)
+2. `mcp__memory__search_nodes("learning")` — scan recent learnings for anything affecting the current session
+3. If a run is in flight (a `started` row with no later `completed`) → resume by delegating to the appropriate next subagent, naming the handoff files
+4. Otherwise → proceed with normal routing
 
 ### Pre-Delegation Check
 
@@ -31,7 +33,7 @@ The orchestrator does NOT write to memory directly. After task completion:
 
 | When | Tool | Query |
 | :---- | :---- | :---- |
-| Session start | `mcp__memory__search_nodes` | `"active task"`, `"current_task"` |
+| Session start | `mcp__memory__search_nodes` | `"learning"` (state itself comes from the ledger) |
 | Before delegation | `mcp__memory__search_nodes` | Task domain keywords |
 | Agent selection | `mcp__memory__search_nodes` | `"agent_insight"` + task type |
 | User asks "what do you remember" | `mcp__memory__read_graph` | Full graph for summary |
@@ -44,7 +46,7 @@ The orchestrator does NOT write to memory directly. After task completion:
 
 ### Post-Implementation Protocol
 
-After analyzing completed work (changes files, git diffs, conversation history):
+After analyzing completed work (changes files, git diffs, the run ledger's rows for the slug, conversation history):
 
 1. **Identify learnings** using standard criteria:
    - User corrected a decision
@@ -65,19 +67,17 @@ After analyzing completed work (changes files, git diffs, conversation history):
    - Follow naming and observation rules from [entity-schema](entity-schema.md)
 
 4. **Create relations**:
-   - `discovered_by` → link learning to task context if exists
    - `relates_to` → link related learnings together
    - `supersedes` → link updated learning to the one it replaces
+   - `informs` → link a workspace pattern to the learning it explains
 
-5. **Clean up task context**:
-   - If task is fully complete → `mcp__memory__delete_entities(["current_task"])` (or the specific task entity)
-   - If task continues → update `current_task` observations with latest state
+5. **Record the decision** (Implementation completions): the one-line summary of what shipped goes into the `recent-decisions.md` ring buffer (N=10) AND, when it is a durable choice, into a `learning`/`workspace_pattern` entity — the file is the convenience view, memory is the record.
 
 ### What Feature Wrap Writes
 
 | Entity Type | When | Example |
 | :----------- | :---- | :------- |
-| `learning` | User correction, unexpected behavior | `learning_flow_check_history_first` |
+| `learning` | User correction, unexpected behavior | `learning_flow_check_ledger_first` |
 | `workspace_pattern` | Convention discovered | `workspace_pattern_server_actions_in_lib` |
 | `agent_insight` | Wrong agent was used | `agent_insight_researcher_for_migration` |
 | `preference` | User stated preference | `preference_testing_no_auto_run` |
@@ -101,24 +101,20 @@ Before starting any research task:
 After completing research:
 
 1. If research contradicts a prior `learning` → create new learning with `supersedes` relation
-2. Update `current_task` entity with research completion status:
-   ```
-   mcp__memory__add_observations("current_task", ["status: Research complete, findings in .vesper/.tracking/research/YYYYMMDD-topic-research.md"])
-   ```
+2. The research file (`.vesper/.tracking/research/YYYYMMDD-<slug>-research.md`) is the handoff; the orchestrator records the milestone with `vespercli log note`. Do not write task state into memory.
 
 ### What Task Researcher Reads/Writes
 
 | Action | When | Tool |
 | :------ | :---- | :---- |
 | Read | Before research | `mcp__memory__search_nodes` with topic keywords |
-| Write | Research complete | `mcp__memory__add_observations` on `current_task` |
 | Write | Prior learning outdated | `mcp__memory__create_entities` + `mcp__memory__create_relations` (supersedes) |
 
 ---
 
 ## code-planner
 
-**Role**: Reader before planning; updates task context after planning.
+**Role**: Reader before planning.
 
 ### Pre-Planning Protocol
 
@@ -126,33 +122,27 @@ Before creating any implementation plan:
 
 1. `mcp__memory__search_nodes("planning")` — find planning-related learnings (wrong estimates, missed deps)
 2. `mcp__memory__search_nodes("<task domain>")` — find domain-specific learnings
-3. `mcp__memory__open_nodes(["current_task"])` — get current task state from researcher handoff
+3. Read the research file named in the delegation prompt — that is the researcher's handoff
 4. Factor all findings into plan estimates and dependency analysis
 
 ### Post-Planning Protocol
 
-After plan creation:
-
-1. Update `current_task` observations:
-   ```
-   mcp__memory__add_observations("current_task", ["status: Planning complete, plan in .vesper/.tracking/plans/YYYYMMDD-task-plan.md", "next_action: Implementation agent should follow plan phases in order"])
-   ```
+The plan/details/prompt files are the handoff to the implementation agents; the orchestrator records the milestone with `vespercli log note`. Nothing is written to memory.
 
 ### What Code Planner Reads/Writes
 
 | Action | When | Tool |
 | :------ | :---- | :---- |
-| Read | Before planning | `mcp__memory__search_nodes`, `mcp__memory__open_nodes` |
-| Write | Planning complete | `mcp__memory__add_observations` on `current_task` |
+| Read | Before planning | `mcp__memory__search_nodes` |
 
 ---
 
-## history-logger
+## The run ledger (`vespercli log`)
 
-**No memory interaction.** Continues using `.vesper/history.md` for chronological event logging.
+**No memory interaction.** The CLI appends chronological rows (`started`, `completed`, `note`, `delegated`, `returned`) to `.vesper/.tracking/runs/YYYYMMDD-<slug>.jsonl`; the orchestrator reads them with `vespercli log tail`.
 
 Memory is for **searchable knowledge** (learnings, patterns, preferences).
-History is for **chronological timeline** (what happened when).
+The ledger is for **chronological timeline** (what happened when).
 
 These are complementary systems — do not merge them.
 
@@ -172,24 +162,25 @@ These are complementary systems — do not merge them.
 
 ## Cross-Agent Handoff Sequence
 
-Standard handoff flow using `task_context`:
+Standard handoff flow — files carry state, the ledger carries chronology, memory carries knowledge:
 
 ```
-Orchestrator delegates to Task Researcher
-  → Researcher: search_nodes → do research → add_observations("current_task", ...)
-  → Returns to orchestrator
+Orchestrator: vespercli log started --pipeline implementation --slug <slug> …
+Orchestrator delegates to Task Researcher (prompt names the output path)
+  → Researcher: search_nodes → do research → writes research/<slug>-research.md
+  → Returns to orchestrator (Status: DONE) → orchestrator: vespercli log note --step 1
 
-Orchestrator delegates to Code Planner
-  → Planner: open_nodes(["current_task"]) → plan → add_observations("current_task", ...)
-  → Returns to orchestrator
+Orchestrator delegates to Code Planner (prompt names the research path)
+  → Planner: search_nodes → reads research → writes plans/, details/, prompts/
+  → Returns to orchestrator → orchestrator: vespercli log note --step 2
 
-Orchestrator delegates to implementation agent
-  → Agent: open_nodes(["current_task"]) → implement → add_observations("current_task", ...)
+Orchestrator delegates to implementation agent (prompt names the prompt file)
+  → Agent: search_nodes → implement → writes changes/<slug>-changes.md
   → Returns to orchestrator
 
-Orchestrator delegates to Feature Wrap
-  → Feature Wrap: analyze → create learning entities → delete_entities(["current_task"])
-  → Returns to orchestrator
+Orchestrator delegates to Feature Wrap (prompt names changes/plans/research paths)
+  → Feature Wrap: analyze → create learning entities → append recent-decisions.md
+  → Returns to orchestrator → orchestrator: vespercli log completed --status DONE
 ```
 
-Each handoff preserves context through the `current_task` entity, supplementing the file-based `.vesper/.tracking/` system with instant queryable state.
+Each handoff preserves context through the tracking files it names; the ledger makes the sequence resumable after an interruption, and memory makes the next task smarter.

package/assets/claude/skills/mcp-memory/references/entity-schema.md

@@ -98,30 +98,11 @@ Observations:
   - "discovered: 2026-02-18"
 ```
 
-### `task_context`
-
-Active task state for cross-agent handoffs. Short-lived — deleted when task completes.
-
-**Naming**: `current_task` (singleton for active task) or `task_<brief_slug>` for parallel tasks
-
-**Required observations:**
-- `status: <current phase and progress>`
-- `next_action: <what the next agent should do>`
-- `key_decisions: <important decisions made so far>`
-- `blockers: <any known blockers or risks>`
-- `updated: <YYYY-MM-DD HH:MM>`
-
-**Example:**
-```
-Entity: current_task
-Type: task_context
-Observations:
-  - "status: Research complete, planning in progress, phase 2 of 4"
-  - "next_action: Code Planner should create implementation plan from research in .vesper/.tracking/research/20260224-auth-migration-research.md"
-  - "key_decisions: Chose Better Auth over NextAuth due to framework-agnostic requirement"
-  - "blockers: None"
-  - "updated: 2026-02-24 14:30"
-```
+> **No task-state type.** Vesper 2.0 removed the `task_context` entity (and its `current_task`
+> singleton). Pipeline state — which run is in flight, which step it reached, what the next agent
+> should do — lives in the run ledger (`.vesper/.tracking/runs/`, written by `vespercli log`) and
+> the story folders, and the handoff itself is the tracking file the previous agent wrote. Memory
+> holds durable knowledge only. Do not create task-state entities under any name.
 
 ## Naming Rules
 
@@ -139,11 +120,11 @@ Relations are **directed** and use **active voice** verbs.
 | Relation Type | Meaning | Example |
 | :------------- | :------ | :------ |
 | `blocks` | Source blocks target | `task_auth` → blocks → `task_dashboard` |
-| `depends_on` | Source depends on target | `current_task` → depends_on → `learning_auth_pattern` |
+| `depends_on` | Source depends on target | `workspace_pattern_auth_flow` → depends_on → `learning_auth_pattern` |
 | `discovered_by` | Learning discovered during task | `learning_x` → discovered_by → `task_y` |
 | `supersedes` | Source replaces target | `learning_new` → supersedes → `learning_old` |
 | `relates_to` | Loose association | `preference_x` → relates_to → `workspace_pattern_y` |
-| `informs` | Source provides context for target | `workspace_pattern_x` → informs → `current_task` |
+| `informs` | Source provides context for target | `workspace_pattern_x` → informs → `learning_y` |
 
 **Rules:**
 - From/to must reference existing entity names

package/assets/claude/skills/mcp-memory/references/memory-hygiene.md

@@ -35,10 +35,7 @@ Always prefix observations with their field name for searchability:
 | `location:` | workspace_pattern | Codebase location |
 | `impact:` | workspace_pattern | How it affects agents |
 | `insight:` | agent_insight | Agent selection learning |
-| `status:` | task_context | Current progress |
-| `next_action:` | task_context | What to do next |
 | `discovered:` | all types | ISO date of discovery |
-| `updated:` | task_context | ISO datetime of last update |
 
 ## Deduplication
 
@@ -102,7 +99,7 @@ If either returns a relevant entity, update instead of creating.
 
 Feature Wrap WILL perform these checks after every task:
 
-1. **Delete completed task context** — if task is done, remove `current_task`
+1. **No task-state cleanup is needed** — pipeline state never enters memory (the run ledger and story folders hold it); if a stray task-state entity is found, delete it
 2. **Check superseded learnings** — if a new learning supersedes an old one and the old one has no other relations, consider deletion
 3. **Remove contradicted observations** — if a new observation directly contradicts an existing one on the same entity, `mcp__memory__delete_observations` the old one
 

package/assets/claude/skills/project-management/SKILL.md

@@ -1,3 +1,8 @@
+---
+name: project-management
+description: 'Project-management conventions for agents — which task system is the source of truth, story lifecycle, status mapping and tracking rules. Use when creating, refining, moving or reporting on tasks and stories (e.g. as the Technical Product Manager).'
+---
+
 # Project Management Instructions (MANDATORY)
 
 Last updated: 2026-01-30