npm - @mthanh/vespercli - Versions diffs - 1.7.1 → 2.0.0 - Mend

@mthanh/vespercli 1.7.1 → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (1294) hide show

package/assets/core/skills/mcp-memory/references/memory-hygiene.md DELETED Viewed

@@ -1,166 +0,0 @@
-# Memory Hygiene
-Cleanup rules, deduplication strategies, lifecycle management, and maintenance triggers for the knowledge graph.
-## Observation Hygiene
-### Atomic Observations
-Each observation must contain exactly one fact. Split compound statements.
-**❌ Bad:**
-```
-"User prefers no auto-run tests and wants TypeScript strict mode enabled"
-```
-**✅ Good:**
-```
-"preference: Do not run tests automatically after generating them"
-"preference: TypeScript strict mode must be enabled in all projects"
-```
-### Observation Prefixes
-Always prefix observations with their field name for searchability:
-| Prefix | Used In | Purpose |
-| :----- | :------ | :------ |
-| `trigger:` | learning | What went wrong |
-| `correction:` | learning | The right approach |
-| `apply_when:` | learning | When to apply |
-| `category:` | learning | Classification |
-| `preference:` | preference | User preference |
-| `context:` | preference | When preference was expressed |
-| `pattern:` | workspace_pattern | Pattern description |
-| `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
-### Before Creating Any Entity
-1. `search_nodes("<key terms from the new learning>")` — check for existing matches
-2. If exact match → skip creation entirely
-3. If partial match (same topic, different insight) → `add_observations` to existing entity
-4. If contradiction → create new entity with `supersedes` relation to old one
-5. If genuinely new → create new entity
-### Search Strategy for Dedup
-Search with **multiple queries** to catch near-duplicates:
-```
-search_nodes("delegation researcher planner")
-search_nodes("task researcher before planning")
-```
-If either returns a relevant entity, update instead of creating.
-## Entity Lifecycle
-### Learning Entities
-| State | Trigger | Action |
-| :---- | :------ | :----- |
-| Active | Created after correction | Normal — agents consult during relevant tasks |
-| Superseded | New learning contradicts it | Create new + `supersedes` relation; keep old |
-| Obsolete | Root cause fixed permanently | `delete_entities` — the learning no longer applies |
-| Stale | 90+ days without relevance | Review during hygiene sweep; delete if no longer applicable |
-### Preference Entities
-| State | Trigger | Action |
-| :---- | :------ | :----- |
-| Active | User expressed preference | Normal — agents respect during all tasks |
-| Updated | User changed preference | `delete_observations` old + `add_observations` new |
-| Revoked | User explicitly reversed | `delete_entities` |
-### Workspace Pattern Entities
-| State | Trigger | Action |
-| :---- | :------ | :----- |
-| Active | Pattern discovered | Normal — agents follow pattern |
-| Changed | Codebase restructured | Update observations; add `updated:` observation |
-| Obsolete | Pattern no longer exists | `delete_entities` |
-### Task Context Entities
-| State | Trigger | Action |
-| :---- | :------ | :----- |
-| Active | Task in progress | Updated at each handoff |
-| Complete | Task finished | `delete_entities` — Feature Wrap cleans up |
-| Stale | 7+ days with no update | Delete — task likely abandoned or completed outside system |
-## Cleanup Triggers
-### Automatic (Agent-Initiated)
-Feature Wrap WILL perform these checks after every task:
-1. **Delete completed task context** — if task is done, remove `current_task`
-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, `delete_observations` the old one
-### Periodic (User-Prompted or Session Start)
-Vesper MAY trigger a hygiene sweep when:
-- User requests "clean up memory" or "review memory"
-- Session start reveals 50+ entities (graph getting large)
-- `read_graph` shows entities with no relations and old `discovered:` dates
-**Hygiene sweep process:**
-1. `read_graph` — get full graph
-2. Identify entities with `discovered:` date > 90 days
-3. For each old entity: check if still relevant to current workspace
-4. Delete obsolete entities and their orphaned relations
-5. Report cleanup summary to user
-## Relation Hygiene
-### Orphaned Relations
-When deleting an entity, `delete_entities` auto-cascades its relations. No manual cleanup needed.
-### Redundant Relations
-Avoid creating multiple relations between the same pair of entities. One relation per directional relationship.
-**❌ Bad:**
-```
-learning_a → relates_to → learning_b
-learning_a → informs → learning_b
-```
-**✅ Good:** Choose the most specific relation type:
-```
-learning_a → informs → learning_b
-```
-## Graph Size Guidelines
-| Metric | Healthy | Warning | Action Needed |
-| :----- | :------ | :------ | :------------ |
-| Total entities | < 30 | 30-50 | Review for stale entries |
-| Total entities | — | > 50 | Mandatory hygiene sweep |
-| Learning entities | < 20 | 20-30 | Check for superseded/obsolete |
-| Task context entities | 0-2 | 3-5 | Delete completed tasks |
-| Relations per entity | 1-3 | 4-6 | Check for redundancy |
-| Observations per entity | 3-7 | 8-12 | Split entity if observations cover different topics |
-## Anti-Patterns
-| Anti-Pattern | Problem | Fix |
-| :----------- | :------ | :-- |
-| Dumping all task details into memory | Bloats graph, buries real learnings | Only store corrections and insights |
-| Creating entities without searching first | Duplicates accumulate | Always `search_nodes` before `create_entities` |
-| Compound observations | Unsearchable, hard to update | One fact per observation |
-| Generic entity names | Collisions, ambiguity | Use type prefix + descriptive slug |
-| Never deleting anything | Graph noise grows | Apply lifecycle rules above |
-| Using memory instead of `.vesper/.tracking/` | Wrong system for task artifacts | Memory = knowledge; tracking = artifacts |

package/assets/core/skills/vesper-orchestration/SKILL.md DELETED Viewed

@@ -1,31 +0,0 @@
-# Vesper Orchestration Pipelines
-Orchestration workflows used exclusively by Vesper to delegate multi-step tasks to specialist agents.
-## Pipelines
-| Pipeline              | When to use                                                 | Reference                                                         |
-| --------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------- |
-| **Research & Plan**   | Steps 1-3: task fetch, research, architect validation       | [research-plan-pipeline.md](references/research-plan-pipeline.md) |
-| **Implementation**    | Steps 4-10: validation, coding, review, testing, docs, wrap | [implement-pipeline.md](references/implement-pipeline.md)         |
-| **QA / E2E Testing**  | Post-implementation or standalone test requests             | [qa-e2e-pipeline.md](references/qa-e2e-pipeline.md)               |
-| **Re-initialization** | "Re-vesperize", "refresh workspace setup"                   | [reinit-pipeline.md](references/reinit-pipeline.md)               |
-## Routing
-- **Implementation request** → read `research-plan-pipeline.md` first (Steps 1-3), then `implement-pipeline.md` (Steps 4-10)
-- **Bug fix** → same pipeline, research-plan and implement references include bug-fix overrides
-- **Skill creation** → same pipeline, references include skill-creation overrides
-- **Testing request** → read `qa-e2e-pipeline.md` (Mode B for standalone, Mode A for post-implementation)
-- **Re-initialization** → read `reinit-pipeline.md`
-## File Naming Convention
-All tracking output uses: `YYYYMMDD-[slug]-<type>.md` where `[slug]` is a short task identifier (3-5 words, kebab-case).
-## Shared Rules
-- All delegation prompts pass **file paths** — never embed file content
-- Subagents write outputs to `.vesper/.tracking/` — never to the npm package directory
-- Loop limits are defined in `vesper.agent.md` — pipelines reference them but don't override
-- Memory integration: subagents use `memory/*` MCP tools per `#skill:mcp-memory`

package/assets/core/skills/vesper-orchestration/references/implement-pipeline.md DELETED Viewed

@@ -1,244 +0,0 @@
-# Implementation Pipeline (Steps 4-10)
-Detailed orchestration for the Implementation purpose pipeline Steps 4-10.
-**Step mapping** (pipeline step → action):
-| Step | Action                  |
-| :--- | :---------------------- |
-| 4    | Validate Planning Files |
-| 5    | Execute Implementation  |
-| 6    | Code Review + Fix Loop  |
-| 7    | Unit Testing            |
-| 8    | Documentation Wrap-Up   |
-| 9    | Feature Wrap            |
-| 10   | Update Task Board       |
-Steps 1-3 (Research, Plan, Architect Validation) are covered by `research-plan-pipeline.md`.
-Step 11 (Log completion) is handled directly by Vesper.
-## Prerequisites
-- ✅ Research & Plan phase complete (plans, details, prompts exist)
-- Developer resolved from Team Roster
-## Orchestration Steps
-### STEP 4: Validate Planning Files (BLOCKING)
-Search for required files from the Plan phase:
-- [ ] `.vesper/.tracking/prompts/implement-*.prompt.md`
-- [ ] `.vesper/.tracking/plans/YYYYMMDD-*-plan.instructions.md`
-- [ ] `.vesper/.tracking/details/YYYYMMDD-*-details.md`
-- [ ] `.vesper/.tracking/research/YYYYMMDD-*-research.md`
-**Memory context**: `search_nodes("current_task")` — if a `task_context` entity exists from the planning phase, check its `status` and `key_decisions` observations for quick context.
-**IF ANY FILE MISSING:**
-- STOP and report: "Planning incomplete. Cannot proceed. Missing: [list]"
-- Suggest: "Run Research & Plan phase first"
-- DO NOT PROCEED
-### STEP 5: Execute Implementation (⚡ PARALLEL BY TRACK)
-The plan may contain multiple independent implementation tracks (e.g., backend API + frontend UI + database migration). Each track has its own prompt file.
-1. List all prompt files: `.vesper/.tracking/prompts/implement-*.prompt.md`
-2. For EACH prompt file, resolve the matching Developer from Team Roster (the prompt specifies the surface/stack — match to the best agent)
-3. Delegate ALL independent tracks in parallel — one subagent per track
-4. Each developer tracks changes in their own file: `.vesper/.tracking/changes/YYYYMMDD-[slug]-[track]-changes.md`
-Delegate to each Developer:
-```
-"Execute implementation using the prepared prompt.
-Implementation Prompt: .vesper/.tracking/prompts/implement-[slug]-[track].prompt.md
-The prompt contains:
-- References to plan, details, and research files
-- Step-by-step instructions for this track
-- Success criteria
-Memory: Check open_nodes(['current_task']) for task context and search_nodes('<task domain>') for relevant learnings before starting.
-Follow the implementation prompt exactly.
-Track changes in: .vesper/.tracking/changes/YYYYMMDD-[slug]-[track]-changes.md"
-```
-**Single track**: If only one prompt file exists, this is a standard single-developer delegation — no change from previous behavior.
-**WAIT** for ALL tracks to complete before proceeding to review.
-If any track returns `NEED_HELP` or `BLOCKED` → handle that track without blocking other running tracks.
-Note: Developer follows `#instruction:task-implementation`
-### STEP 6: Code Review — ⚡ PARALLEL
-After implementation, call BOTH reviewers in parallel:
-**Delegate to `@Code Reviewer Agent`:**
-```
-"Review changes for [task].
-Changes file: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-Plan: .vesper/.tracking/plans/YYYYMMDD-[slug]-plan.instructions.md
-Focus: Code quality, standards compliance, maintainability, test coverage.
-Approve or request specific changes."
-```
-**Delegate to `@Principal Software Engineer Agent`:**
-```
-"Review changes for [task].
-Changes file: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-Plan: .vesper/.tracking/plans/YYYYMMDD-[slug]-plan.instructions.md
-Focus: Architecture alignment, security, performance, scalability, design patterns.
-Approve or request specific changes."
-```
-Consolidate feedback from both reviewers.
-**IF any reviewer has feedback:**
-1. Delegate to Developer to fix all issues
-2. Re-review with BOTH reviewers (parallel)
-3. Repeat until both approve (subject to the global loop limit in `vesper.agent.md`)
-### STEP 7: Unit Testing
-Delegate to **Tester from roster** → fallback Developer:
-```
-"Write unit tests for implemented code.
-Scope: Unit tests ONLY (integration/E2E tests are handled in Testing purpose)
-Requirements:
-- Cover all acceptance criteria from the plan
-- Include edge cases identified in research
-- Test individual functions/components in isolation
-Track in: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md"
-```
-**WAIT** for unit tests to pass. If tests fail and require code changes, loop with Developer until green (subject to the global loop limit in `vesper.agent.md`).
-### STEP 8: Documentation Wrap-Up
-Delegate to `@SE: Tech Writer`:
-```
-"Update documentation for completed implementation.
-Review:
-- Changes: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-- Details: .vesper/.tracking/details/YYYYMMDD-[slug]-details.md
-Update: README, API docs, inline comments as needed.
-Capture learnings for future reference."
-```
-### STEP 9: Feature Wrap
-**Delegate to `@Feature Wrap and Retrospective Agent`:**
-```
-"Analyze completed implementation for knowledge capture.
-Changes file: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-Identify:
-- Patterns worth documenting
-- Instruction updates needed
-- Skill opportunities
-- Newly discovered best practices, pitfalls, or workspace-specific insights
-Memory: Use MCP Memory tools (memory/*) to create learning, workspace_pattern, and agent_insight entities.
-Follow #skill:mcp-memory for entity schema and hygiene rules.
-Clean up current_task entity if task is complete.
-Present numbered proposals. Vesper will approve."
-```
-**Vesper Approval:**
-- Review agent proposals
-- Approve ONLY what is truly reusable and necessary
-- Skip one-off solutions or obvious patterns
-- Criteria: "Would this help future tasks significantly?"
-### STEP 10: Update Task Board & Move Story
-**Always** (regardless of Task Management): Move story file from `inprogress/` to `inreview/`.
-**Additionally, if Task Management configured AND task reference exists**:
-Delegate to Task Agent (from Team Roster):
-```
-"Update task [task-id] status to IN REVIEW.
-Add comment: Implementation complete. Changes tracked in .vesper/.tracking/changes/"
-```
-**WAIT** for confirmation before proceeding to Step 11 (Log completion).
-## Output
-- Code changes implemented
-- `.vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md` (complete log)
-- Unit tests written and passing
-- Documentation updated
-- Story file moved to `inreview/`
-- Task status: IN REVIEW (if Task Management configured)
-## Next
-→ After Step 11 (Log completion, handled by Vesper), **E2E/integration testing** auto-triggers via Testing purpose (Mode A: Post-Implementation). See `qa-e2e-pipeline.md`.
-## Post-Flow: Memory Update
-After feature wrap complete, execute `#prompt:memory-update` to review if any learnings should be recorded.
----
-## Bug Fix Review Focus (when Purpose = bug fix)
-When delegating to reviewers in STEP 6 for a bug fix, add to the delegate prompt:
-```
-"Additional review focus for bug fix:
-- Fix addresses root cause (not just symptoms)
-- Regression test covers the exact scenario
-- No unintended side effects introduced
-- Is the fix minimal and scoped correctly?"
-```
-Bug fixes often reveal patterns worth documenting — ensure Feature Wrap in STEP 9 captures root cause categories, testing gaps, or common pitfalls.
----
-## Skills Implementation (when task = skill creation)
-When the task is creating a skill, STEP 5 delegates to `@Skill Creator Agent` instead of the Developer from roster:
-```
-"Create skill for [topic/technology].
-Research: .vesper/.tracking/research/YYYYMMDD-skill-research.md
-Plan: .vesper/.tracking/plans/YYYYMMDD-skill-plan.instructions.md
-Relevant Skills: skill-creator"
-```
-If Skill Creator's VESPER_RESPONSE is `NEED_HELP` asking about workspace patterns:
-1. Delegate to `@Workspace Learner` to answer the specific question (do NOT re-scan the codebase)
-2. Return answer to Skill Creator in a follow-up call

package/assets/core/skills/vesper-orchestration/references/qa-e2e-pipeline.md DELETED Viewed

@@ -1,151 +0,0 @@
-# QA / E2E Testing Pipeline
-Detailed orchestration steps for the Testing purpose.
-## Mode A: Post-Implementation (Auto-triggered after Implementation pipeline completes — Step 11)
-Uses existing materials from the completed Implementation pipeline — no research or planning needed.
-### Prerequisites
-- ✅ Implementation complete
-- ✅ Changes file exists: `.vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md`
-- ✅ Details file exists: `.vesper/.tracking/details/YYYYMMDD-[slug]-details.md`
-### STEP 1: Run E2E/Integration Tests
-Delegate to **Tester from roster**:
-```
-"Execute E2E and integration tests for [task/feature].
-Scope:
-- Integration tests for API changes
-- E2E tests for user flows
-- Cross-browser testing (if applicable)
-Reference:
-- Changes: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-- Details: .vesper/.tracking/details/YYYYMMDD-[slug]-details.md
-Report results and any failures."
-```
-### STEP 2: Log Issues (if tests fail)
-**IF tests fail:**
-Delegate to Tester:
-```
-"Log test failures to issues file.
-Create/update: .vesper/.tracking/issues/YYYYMMDD-[slug]-issues.md
-For each failure include:
-- Test name and file
-- Expected vs actual behavior
-- Steps to reproduce
-- Error logs/screenshots
-- Severity (critical/high/medium/low)
-Format as actionable bug reports."
-```
-### STEP 3: Fix Issues
-**IF issues logged:**
-Delegate to **Developer from roster**:
-```
-"Fix issues identified in QA testing.
-Issues: .vesper/.tracking/issues/YYYYMMDD-[slug]-issues.md
-For each issue:
-- Implement fix
-- Add/update unit test to cover the case
-- Update changes file
-Track in: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md"
-```
-### STEP 4: Re-run Tests
-After fixes applied:
-1. Return to STEP 1
-2. Repeat until all tests pass (subject to the global loop limit in `vesper.agent.md`)
-### STEP 5: Review Test Quality
-Delegate to `@Code Reviewer Agent`:
-```
-"Review test quality for [task].
-Test files: [paths from Tester output]
-Changes: .vesper/.tracking/changes/YYYYMMDD-[slug]-changes.md
-Check: coverage, edge cases, maintainability, no flaky tests."
-```
-### STEP 6: Update Status (when all tests pass)
-Delegate to **Task Agent** (from Team Roster, if Task Management configured):
-```
-"Update task [task-id] status to DONE.
-Add comment: QA complete. All E2E/integration tests passing."
-```
----
-## Mode B: Standalone (User explicitly requests tests)
-Full pipeline — same rigor as Implementation.
-### Steps
-| Step | Action                                                      | Agent                                                                          |
-| :--- | :---------------------------------------------------------- | :----------------------------------------------------------------------------- |
-| 1    | Research (understand system, existing tests, coverage gaps) | Researcher/Analyzer from roster → fallback `@Task Researcher Specialist Agent` |
-| 2    | Plan (test strategy, cases, scope)                          | Planner from roster → fallback `@Code Planner Agent`                           |
-| 3    | Write + run tests                                           | Tester from roster                                                             |
-| 4    | Fix failures (if any)                                       | Developer from roster                                                          |
-| 5    | Re-run tests                                                | Tester from roster                                                             |
-| 6    | Review test quality                                         | `@Code Reviewer Agent`                                                         |
-| 7    | Feature wrap                                                | `@Feature Wrap and Retrospective Agent`                                        |
-| 8    | Log completion                                              | `@History Logger`                                                              |
-**Loop**: Steps 3-5 repeat until tests pass (subject to the global loop limit in `vesper.agent.md`). Issues logged in `issues/`.
----
-## Output
-- E2E/Integration tests passing
-- `.vesper/.tracking/issues/YYYYMMDD-[slug]-issues.md` (resolved issues log)
-- Additional unit tests for edge cases found
-- Task status: DONE
-## Issue File Format
-```markdown
-# QA Issues: [Task Name]
-## Issue 1: [Test Name]
-- **Severity**: critical/high/medium/low
-- **Test File**: path/to/test.spec.ts
-- **Expected**: What should happen
-- **Actual**: What actually happened
-- **Steps to Reproduce**:
-  1. Step 1
-  2. Step 2
-- **Error Log**: [stack trace or error message]
-- **Status**: OPEN / FIXED / VERIFIED
-## Issue 2: ...
-```

package/assets/core/skills/vesper-orchestration/references/reinit-pipeline.md DELETED Viewed

@@ -1,87 +0,0 @@
-# Re-initialization Pipeline
-Triggered when user explicitly asks to re-initialize (e.g., "Re-vesperize", "re-initialize", "refresh workspace setup").
-## Prerequisites
-- ✅ `.github/instructions/orchestration.instructions.md` with a Team Roster already exists
-- This is NOT a first-time setup — this is a refresh of an existing workspace
-## Orchestration Steps
-| Step | Action                                                                                                                                                                                    | Agent                                   |
-| :--- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------- |
-| 1    | Force full re-scan of codebase. Do NOT skip with "already current" — treat as fresh analysis. Compare with existing `copilot-instructions.md` and produce a diff summary of what changed. | `@Workspace Learner`                    |
-| 2    | Review Team Roster changes: validate agent composition still fits the project's current needs. Approve or recommend additions/removals.                                                   | `@SE: Architect`                        |
-| 3    | Present Workspace Learner's diff summary + Architect's roster recommendations to user for confirmation.                                                                                   | Vesper (via `vscode/askQuestions`)      |
-| 4    | Apply confirmed changes to `copilot-instructions.md` and `orchestration.instructions.md`.                                                                                                 | `@Workspace Learner`                    |
-| 5    | Scoped memory update (see Memory Protocol below).                                                                                                                                         | `@Feature Wrap and Retrospective Agent` |
-| 6    | Log `"Workspace re-initialized"`                                                                                                                                                          | `@History Logger`                       |
-### Step 1 — Force Re-scan
-Delegate to `@Workspace Learner`:
-```
-"Force full workspace re-scan. This is a RE-INITIALIZATION — do NOT skip with 'already current'.
-Treat this as a fresh analysis. Compare results with the existing copilot-instructions.md.
-Produce a diff summary: what changed, what's new, what was removed.
-Save updated copilot-instructions.md and produce the diff summary in your response.
-If root CLAUDE.md exists during your conventions scan, skip its guarded <!-- vesper:start -->...<!-- vesper:end --> import block — it's machine-generated, not a project convention."
-```
-### Step 2 — Architect Roster Review
-Delegate to `@SE: Architect` with the current Team Roster included in the prompt:
-```
-"Review the current Team Roster against the updated copilot-instructions.md.
-Current Team Roster:
-[Vesper: paste the Team Roster table from orchestration.instructions.md here]
-Evaluate:
-- Are all current agents still needed?
-- Are there gaps — new capabilities needed that no current agent covers?
-- Should any agents be added or removed based on how the project has evolved?
-Provide specific recommendations: keep / add / remove for each agent role."
-```
-### Step 3 — User Confirmation
-Use `vscode/askQuestions` with options and allow free-form input:
-- **"Apply all changes"** — accept both workspace learning and roster updates
-- **"Apply workspace learning only"** — keep current Team Roster unchanged
-- **"Cancel"** — abort re-initialization, keep everything as-is
-### Step 4 — Apply Changes
-Based on user's choice:
-- **"Apply all changes"** → Delegate to `@Workspace Learner` to apply copilot-instructions + roster changes
-- **"Apply workspace learning only"** → Delegate to `@Workspace Learner` to apply copilot-instructions only, skip roster changes
-- **"Cancel"** → Stop. Log `"Re-initialization cancelled by user"` and return
-### Step 5 — Memory Update
-Delegate to `@Feature Wrap and Retrospective Agent` with `#skill:mcp-memory`.
-The skill defines entity schema, per-agent memory protocols, and hygiene rules for the MCP Memory knowledge graph.
-This applies to:
-- **Initial creation** (Auto-Setup Step 2 in `vesper.agent.md`)
-- **Re-initialization** (Step 5 above)
----
-## Memory File Rules
-Constraints for creating/updating `memory.instructions.md` (applies to both initial setup and re-initialization):
-- Memory files capture workspace-specific patterns and learnings
-- Do NOT duplicate information already in `copilot-instructions.md`
-- Focus on: discovered patterns, pitfalls, and workspace-specific conventions
-- Keep entries concise and actionable