@mthanh/vespercli 1.7.1 → 2.0.0

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

@@ -0,0 +1,186 @@
+# Agent Memory Protocol
+
+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. `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
+
+Before delegating any task:
+
+1. `mcp__memory__search_nodes("<task domain keywords>")` — find relevant learnings
+2. If learnings exist → include entity names in delegation prompt: *"Check memory entities: `learning_x`, `learning_y` before proceeding"*
+3. If agent_insight exists for this task type → use it to inform agent selection
+
+### Memory Writes
+
+The orchestrator does NOT write to memory directly. After task completion:
+- Delegate to `feature-wrap-document` for learning capture
+- Feature Wrap handles all entity creation
+
+### What the Orchestrator Reads
+
+| When | Tool | Query |
+| :---- | :---- | :---- |
+| 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 |
+
+---
+
+## feature-wrap-document
+
+**Role**: Primary memory writer. Creates and maintains learning entities after implementation.
+
+### Post-Implementation Protocol
+
+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
+   - Unexpected behavior required different approach
+   - Workspace-specific pattern discovered
+   - Agent selection was wrong
+   - File path or naming convention was incorrect
+
+2. **Check for duplicates**:
+   - `mcp__memory__search_nodes("<learning description keywords>")` before creating
+   - If similar entity exists → `mcp__memory__add_observations` to existing entity instead
+   - If entity is outdated → create new entity with `supersedes` relation
+
+3. **Create entities**:
+   - One `learning` entity per distinct correction/insight
+   - One `workspace_pattern` entity per discovered workspace convention
+   - One `agent_insight` entity per agent selection lesson
+   - Follow naming and observation rules from [entity-schema](entity-schema.md)
+
+4. **Create relations**:
+   - `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. **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_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` |
+
+---
+
+## task-researcher
+
+**Role**: Reader before research; occasional writer for research-related learnings.
+
+### Pre-Research Protocol
+
+Before starting any research task:
+
+1. `mcp__memory__search_nodes("<research topic keywords>")` — find prior research insights
+2. If relevant `learning` entities exist → factor them into research approach
+3. If `workspace_pattern` entities exist for the domain → respect workspace conventions
+
+### Post-Research Protocol
+
+After completing research:
+
+1. If research contradicts a prior `learning` → create new learning with `supersedes` relation
+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 | Prior learning outdated | `mcp__memory__create_entities` + `mcp__memory__create_relations` (supersedes) |
+
+---
+
+## code-planner
+
+**Role**: Reader before planning.
+
+### Pre-Planning Protocol
+
+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. 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
+
+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` |
+
+---
+
+## The run ledger (`vespercli log`)
+
+**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).
+The ledger is for **chronological timeline** (what happened when).
+
+These are complementary systems — do not merge them.
+
+---
+
+## code-reviewer / principal-software-engineer
+
+**Role**: Reader only. May reference learnings when reviewing code.
+
+### During Review
+
+1. `mcp__memory__search_nodes("<review domain>")` — check if prior learnings affect review criteria
+2. If learnings exist about common mistakes in this domain → flag them proactively
+3. Do NOT write to memory — feed review findings back to the orchestrator for Feature Wrap to capture
+
+---
+
+## Cross-Agent Handoff Sequence
+
+Standard handoff flow — files carry state, the ledger carries chronology, memory carries knowledge:
+
+```
+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 (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 (prompt names the prompt file)
+  → Agent: search_nodes → implement → writes changes/<slug>-changes.md
+  → 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 tracking files it names; the ledger makes the sequence resumable after an interruption, and memory makes the next task smarter.

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

@@ -0,0 +1,141 @@
+# Entity Schema
+
+Entity types, naming conventions, observation patterns, and relation rules for the Vesper memory knowledge graph.
+
+## Entity Types
+
+### `learning`
+
+Corrections, mistakes, and better approaches discovered during work.
+
+**Naming**: `learning_<category>_<brief_slug>` — e.g., `learning_delegation_always_use_researcher_first`
+
+**Required observations** (one per observation, atomic):
+- `trigger: <what happened or went wrong>`
+- `correction: <the correct approach>`
+- `apply_when: <conditions for applying this learning>`
+- `category: <Flow|Delegation|Agent Selection|File Paths|Prompts|User Preference>`
+- `discovered: <YYYY-MM-DD>`
+
+**Example:**
+```
+Entity: learning_delegation_researcher_before_planner
+Type: learning
+Observations:
+  - "trigger: Code Planner started planning without research, produced plan with wrong assumptions"
+  - "correction: Always delegate to Task Researcher before Code Planner"
+  - "apply_when: Any new feature task that requires codebase analysis"
+  - "category: Delegation"
+  - "discovered: 2026-02-24"
+```
+
+### `preference`
+
+User preferences discovered during work sessions.
+
+**Naming**: `preference_<domain>_<brief_slug>` — e.g., `preference_testing_no_auto_run`
+
+**Required observations:**
+- `preference: <what the user prefers>`
+- `context: <when/why this preference was expressed>`
+- `discovered: <YYYY-MM-DD>`
+
+**Example:**
+```
+Entity: preference_testing_no_auto_run
+Type: preference
+Observations:
+  - "preference: Do not run tests automatically after generating them"
+  - "context: User explicitly corrected agent behavior during test generation task"
+  - "discovered: 2026-02-15"
+```
+
+### `workspace_pattern`
+
+Workspace-specific patterns that affect how subagents should operate in this project.
+
+**Naming**: `workspace_pattern_<brief_slug>` — e.g., `workspace_pattern_server_actions_in_lib`
+
+**Required observations:**
+- `pattern: <description of the pattern>`
+- `location: <where in the codebase this applies>`
+- `impact: <how this affects agent behavior>`
+- `discovered: <YYYY-MM-DD>`
+
+**Example:**
+```
+Entity: workspace_pattern_server_actions_in_lib
+Type: workspace_pattern
+Observations:
+  - "pattern: Server actions live in lib/actions/ not app/actions/"
+  - "location: lib/actions/*.ts"
+  - "impact: File creation and imports must target lib/actions/"
+  - "discovered: 2026-02-20"
+```
+
+### `agent_insight`
+
+Learnings about which subagents perform best for specific task types.
+
+**Naming**: `agent_insight_<brief_slug>` — e.g., `agent_insight_researcher_for_migration`
+
+**Required observations:**
+- `insight: <what was learned about agent selection>`
+- `wrong_choice: <which agent was tried and failed or suboptimal>`
+- `right_choice: <which agent should be used instead>`
+- `task_type: <what kind of task this applies to>`
+- `discovered: <YYYY-MM-DD>`
+
+**Example:**
+```
+Entity: agent_insight_researcher_for_migration
+Type: agent_insight
+Observations:
+  - "insight: Migration tasks need research phase before planning"
+  - "wrong_choice: Delegated directly to Code Planner"
+  - "right_choice: Task Researcher first, then Code Planner"
+  - "task_type: Database or library migration"
+  - "discovered: 2026-02-18"
+```
+
+> **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
+
+| Rule | Convention | Example |
+| :--- | :--------- | :------ |
+| Case | `snake_case` | `learning_flow_check_history_first` |
+| Prefix | Entity type as prefix | `preference_`, `learning_`, etc. |
+| Length | Descriptive but under 80 characters | Keep slugs to 3-6 words |
+| Uniqueness | Names must be globally unique | Check with `mcp__memory__search_nodes` before creating |
+
+## Relation Rules
+
+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 | `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 → `learning_y` |
+
+**Rules:**
+- From/to must reference existing entity names
+- Use active voice: `blocks`, not `is_blocked_by`
+- One relation per fact — don't overload a single relation
+- `supersedes` is the preferred way to handle updated learnings (keep old for audit trail)
+
+## Observation Rules
+
+- **One fact per observation** — atomic, not compound sentences
+- **Prefix with field name** — `trigger:`, `correction:`, `pattern:`, etc.
+- **No markdown formatting** — plain text only inside observations
+- **Timestamps use ISO format** — `YYYY-MM-DD` or `YYYY-MM-DD HH:MM`
+- **Max ~200 characters per observation** — split long facts into multiple observations

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

@@ -0,0 +1,163 @@
+# 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 |
+| `discovered:` | all types | ISO date of discovery |
+
+## Deduplication
+
+### Before Creating Any Entity
+
+1. `mcp__memory__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) → `mcp__memory__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:
+
+```
+mcp__memory__search_nodes("delegation researcher planner")
+mcp__memory__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 | `mcp__memory__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 | `mcp__memory__delete_observations` old + `mcp__memory__add_observations` new |
+| Revoked | User explicitly reversed | `mcp__memory__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 | `mcp__memory__delete_entities` |
+
+### Task Context Entities
+
+| State | Trigger | Action |
+| :----- | :------- | :------ |
+| Active | Task in progress | Updated at each handoff |
+| Complete | Task finished | `mcp__memory__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. **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
+
+### Periodic (User-Prompted or Session Start)
+
+The orchestrator MAY trigger a hygiene sweep when:
+
+- User requests "clean up memory" or "review memory"
+- Session start reveals 50+ entities (graph getting large)
+- `mcp__memory__read_graph` shows entities with no relations and old `discovered:` dates
+
+**Hygiene sweep process:**
+
+1. `mcp__memory__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, `mcp__memory__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 `mcp__memory__search_nodes` before `mcp__memory__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/copilot/skills/nodejs-javascript-vitest/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: nodejs-javascript-vitest
+description: Guidelines for writing Node.js and JavaScript code with Vitest testing
+---
+
+# Code Generation Guidelines
+
+## Coding standards
+
+- Use JavaScript with ES2022 features and Node.js (20+) ESM modules
+- Use Node.js built-in modules and avoid external dependencies where possible
+- Ask the user if you require any additional dependencies before adding them
+- Always use async/await for asynchronous code, and use 'node:util' promisify function to avoid callbacks
+- Keep the code simple and maintainable
+- Use descriptive variable and function names
+- Do not add comments unless absolutely necessary, the code should be self-explanatory
+- Never use `null`, always use `undefined` for optional values
+- Prefer functions over classes
+
+## Testing
+
+- Use Vitest for testing
+- Write tests for all new features and bug fixes
+- Ensure tests cover edge cases and error handling
+- NEVER change the original code to make it easier to test, instead, write tests that cover the original code as it is
+
+## Documentation
+
+- When adding new features or making significant changes, update the README.md file where necessary
+
+## User interactions
+
+- Ask questions if you are unsure about the implementation details, design choices, or need clarification on the requirements
+- Always answer in the same language as the question, but use english for the generated content like code, comments or docs

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

@@ -0,0 +1,129 @@
+---
+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
+Owner: <fill>
+
+This file is the single source of truth for **project management conventions** used by agents (e.g., the Technical Product Manager agent).
+
+## 1) Task Management System
+
+Which task management system is the source of truth?
+
+- System: <ClickUp | Jira | Local | Other>
+- Workspace/Org (if applicable): <fill>
+
+Purpose: This determines which MCP tools/agents must be used for reads/writes.
+
+## Agent Tracking (Always `.vesper/.tracking/`)
+
+Regardless of whether the task system is ClickUp, Jira, or Local, agent tracking files (refinement progress, batch logs, implementation progress) MUST live under:
+
+- `.vesper/.tracking/`
+
+## 2) Task System Configuration
+
+### ClickUp (fill only if System = ClickUp)
+
+- Space name: <fill>
+- Space ID (optional): <fill>
+- Default List/Folder (optional): <fill>
+- URL (optional): <fill>
+
+- Username/handle (ClickUp only; used ONLY if your branch naming pattern includes `{username}`):
+  - Examples: `thanh_tran`, `ttran`, `thanh`
+  - Username/handle: <fill>
+
+### Jira (fill only if System = Jira)
+
+- Project key: <fill>
+- Board name (optional): <fill>
+- URL (optional): <fill>
+
+### Local (fill only if System = Local)
+
+- Stories root folder: `docs/stories`
+- Backlog file: `docs/stories/backlog.md`
+- Tasks folder (optional): `docs/stories/tasks/`
+
+Note: `docs/stories` is for the local story/task _source of truth_ only. Agent tracking remains under `.vesper/.tracking/`.
+
+## 3) Status Model + Labels
+
+### Status Flow
+
+Define the canonical statuses and expected flow for THIS project.
+
+You MUST define these groups (names can differ per system):
+
+- Backlog statuses: <comma-separated>
+- In progress statuses: <comma-separated>
+- Review statuses: <comma-separated>
+- Done statuses: <comma-separated>
+
+Also define the two agent-relevant refinement states:
+
+- Needs-clarification status: <single status>
+- Ready/refined status: <single status>
+
+Write the actual flow used in this project:
+
+- Flow: <e.g., Backlog → Needs-clarification → In progress → Review → Done>
+
+### Labels/Tags
+
+Define required labels/tags used by agents:
+
+- Questions label/tag: <fill>
+- Refined/ready label/tag: <fill>
+- Bug label/tag (optional): <e.g., `bug`>
+
+Rules:
+
+- "Needs clarification" MUST be represented by: Needs-clarification status + Questions label/tag.
+- "Ready queue" MUST be represented by: Ready/refined status + Refined/ready label/tag and NOT Questions label/tag.
+
+## 4) Version Control + Branching
+
+- VCS: <Git | Other>
+- Hosting: <GitHub | GitLab | Bitbucket | Other>
+
+### Branch Naming
+
+- Pattern: <fill>
+- Example: <fill>
+
+(If you use ClickUp/Jira IDs in branches, specify the exact prefix and formatting.)
+
+## 5) Commit Message Pattern
+
+Choose the commit message pattern used by the repo:
+
+- Pattern: <Conventional Commits | Custom>
+
+If Conventional Commits:
+
+- Examples: `feat: ...`, `fix: ...`, `chore: ...`, `refactor: ...`
+- Optional scope usage: <yes/no>
+
+If Custom:
+
+- Provide the exact template and examples.
+
+## 6) Confirmation Checklist (Required)
+
+Before continuing any TPM workflow, confirm:
+
+- [ ] Task system is correct (ClickUp/Jira/Local/Other)
+- [ ] If ClickUp: correct Space name is set
+- [ ] If Jira: correct Project key is set
+- [ ] If Local: `docs/stories` workflow is agreed
+- [ ] Status flow matches the workspace
+- [ ] Questions label/tag and Refined/ready label/tag are correct
+- [ ] Branch naming pattern is correct
+- [ ] If System=ClickUp and pattern includes `{username}`: ClickUp username/handle is set
+- [ ] Commit message pattern is correct