@mthanh/vespercli 1.8.0 → 2.0.1

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

package/assets/claude/skills/repo-story-time/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: repo-story-time
+description: Generate a comprehensive repository summary and a narrative story from commit history. Use when asked to summarize a repository, analyze its architecture and evolution, or produce a "story of this repo" from its git history. Produces two files at the repository root — `REPOSITORY_SUMMARY.md` (technical architecture and purpose) and `THE_STORY_OF_THIS_REPO.md` (narrative from commit-history analysis) — writing complete Markdown to the files rather than printing it in chat.
+---
+
+# Repo Story Time
+
+You are a senior technical analyst and storyteller with expertise in repository archaeology, code pattern analysis, and narrative synthesis. Transform raw repository data into a compelling technical narrative that reveals the human stories behind the code.
+
+## Deliverables
+
+Transform the repository into two files, written to the repository root with complete Markdown content (create the actual files — do not print the Markdown in chat):
+
+1. **REPOSITORY_SUMMARY.md** — technical architecture and purpose overview.
+2. **THE_STORY_OF_THIS_REPO.md** — narrative story from commit-history analysis.
+
+## Methodology
+
+### Phase 1: Repository Exploration
+
+Understand the repository structure and purpose. List key documentation and configuration files and map the top-level directory structure (excluding `node_modules`, `.git`, build output). Then use the codebase index (`vesper-indexing`) and reads to understand key concepts and technologies. Look for:
+
+- Configuration files (`package.json`, `pom.xml`, `requirements.txt`, etc.)
+- README files and documentation
+- Main source directories
+- Test directories
+- Build/deployment configurations
+
+### Phase 2: Technical Deep Dive
+
+Create a comprehensive technical inventory:
+
+- **Purpose**: What problem does this repository solve?
+- **Architecture**: How is the code organized?
+- **Technologies**: What languages, frameworks, and tools are used?
+- **Key Components**: What are the main modules/services/features?
+- **Data Flow**: How does information move through the system?
+
+### Phase 3: Commit History Analysis
+
+Run git commands systematically to understand the repository's evolution. Execute each and analyze the output before proceeding:
+
+- **Basic statistics**: `git rev-list --all --count` (total commits); `git log --oneline --since="1 year ago" | wc -l` (commits in the last year).
+- **Contributor analysis**: `git shortlog -sn --since="1 year ago" | head -20`.
+- **Activity patterns (by month)**: `git log --since="1 year ago" --format="%ad" --date=format:"%Y-%m" | sort | uniq -c | sort -rn | head -12`.
+- **Change themes**: `git log --since="1 year ago" --oneline --grep="feat\|fix\|update\|add\|remove" | head -50`.
+- **Most-changed files**: `git log --since="1 year ago" --name-only --pretty=format: | grep -v '^$' | sort | uniq -c | sort -rn | head -20`.
+- **Collaboration (merges)**: `git log --since="1 year ago" --merges --oneline | head -20`.
+- **Seasonal (by calendar month)**: `git log --since="1 year ago" --format="%ad" --date=format:"%m" | sort | uniq -c | sort`.
+
+Use your judgment to run additional commands based on prior output and the repository's specific content.
+
+### Phase 4: Pattern Recognition
+
+Look for these narrative elements:
+
+- **Characters**: Who are the main contributors? What are their specialties?
+- **Seasons**: Are there patterns by month/quarter? Holiday effects?
+- **Themes**: What types of changes dominate (features, fixes, refactoring)?
+- **Conflicts**: Are there areas of frequent change or contention?
+- **Evolution**: How has the repository grown and changed over time?
+
+## Output Format
+
+### REPOSITORY_SUMMARY.md Structure
+
+```markdown
+# Repository Analysis: [Repo Name]
+
+## Overview
+Brief description of what this repository does and why it exists.
+
+## Architecture
+High-level technical architecture and organization.
+
+## Key Components
+- **Component 1**: Description and purpose
+- **Component 2**: Description and purpose
+[Continue for all major components]
+
+## Technologies Used
+List of programming languages, frameworks, tools, and platforms.
+
+## Data Flow
+How information moves through the system.
+
+## Team and Ownership
+Who maintains different parts of the codebase.
+```
+
+### THE_STORY_OF_THIS_REPO.md Structure
+
+```markdown
+# The Story of [Repo Name]
+
+## The Chronicles: A Year in Numbers
+Statistical overview of the past year's activity.
+
+## Cast of Characters
+Profiles of main contributors with their specialties and impact.
+
+## Seasonal Patterns
+Monthly/quarterly analysis of development activity.
+
+## The Great Themes
+Major categories of work and their significance.
+
+## Plot Twists and Turning Points
+Notable events, major changes, or interesting patterns.
+
+## The Current Chapter
+Where the repository stands today and future implications.
+```
+
+## Key Instructions
+
+1. **Be Specific**: Use actual file names, commit messages, and contributor names.
+2. **Find Stories**: Look for interesting patterns, not just statistics.
+3. **Context Matters**: Explain why patterns exist (holidays, releases, incidents).
+4. **Human Element**: Focus on the people and teams behind the code.
+5. **Technical Depth**: Balance narrative with technical accuracy.
+6. **Evidence-Based**: Support observations with actual git data.
+
+## Success Criteria
+
+- Both Markdown files are **actually created** with complete, comprehensive content.
+- **No Markdown content is output to chat** — all content is written directly to the files.
+- The technical summary accurately represents the repository architecture.
+- The narrative story reveals human patterns and interesting insights.
+- Git commands provide concrete evidence for all claims.
+- The analysis reveals both technical and cultural aspects of development.
+- Files are ready to use immediately without any copy/paste from chat.
+
+Remember: every repository tells a story. Your job is to uncover it through systematic analysis and present it so that both technical and non-technical audiences can appreciate it.

package/assets/claude/skills/self-explanatory-code-commenting/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: self-explanatory-code-commenting
-description: Conventions for writing and reviewing code comments: prefer self-explanatory code, comment WHY not WHAT, and avoid obvious, redundant, outdated, dead-code, or decorative comments. Language-agnostic (examples in JavaScript). Use when working with Python, JavaScript, TypeScript, Java, C#, C++, Go, or Ruby files.
+description: 'Conventions for writing and reviewing code comments: prefer self-explanatory code, comment WHY not WHAT, and avoid obvious, redundant, outdated, dead-code, or decorative comments. Language-agnostic (examples in JavaScript). Use when working with Python, JavaScript, TypeScript, Java, C#, C++, Go, or Ruby files.'
+copilot-apply-to: '**/*.py, **/*.js, **/*.ts, **/*.java, **/*.cs, **/*.cpp, **/*.go, **/*.rb'
+copilot-instructions-tier: extended
 ---
 
 # Self-explanatory Code Commenting Instructions

package/assets/claude/skills/skill-creator/SKILL.md

@@ -232,6 +232,6 @@ After testing the skill, users may request improvements. Often this happens righ
 
 ## References
 - [Agent Skills](https://docs.claude.com/en/docs/claude-code/skills.md)
-- [Agent Skills Spec](.claude/skills/agent_skills_spec.md)
+- [Agent Skills Spec](./agent_skills_spec.md) — bundled with this skill
 - [Agent Skills Overview](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview.md)
 - [Best Practices](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices.md)

package/assets/claude/skills/task-implementation/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: task-implementation
 description: Instructions for implementing task plans with progressive tracking and change record - Brought to you by microsoft/edge-ai. Use when working with task change-record files under .vesper/.tracking/changes/.
+copilot-apply-to: '**/.vesper/.tracking/changes/*.md'
+copilot-instructions-tier: extended
 ---
 
 # Task Plan Implementation Instructions