@jigyasudham/veto 0.8.2 → 1.0.0

package/src/skills/intelligence/skill-learning-loop.ts

@@ -1,69 +0,0 @@
-// Skill: learning-loop — how to feed outcome data back into the router and agents
-
-export interface SkillInput { task: string; context?: string; options?: Record<string, unknown>; }
-export interface SkillOutput { skill: string; template?: string; checklist: string[]; patterns: string[]; gotchas: string[]; resources: string[]; }
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'learning-loop',
-    template: `
-// ── Learning Loop Protocol ────────────────────────────────────────────────
-//
-// The router gets smarter when you record task outcomes.
-// Without outcome data, thresholds stay at the default 30/70 forever.
-//
-// Step 1: Complete a task
-//
-// Step 2: Score the output quality (0–100):
-//   90–100  Excellent — exactly what was needed, no revision required
-//   70–89   Good — minor revisions needed
-//   50–69   Acceptable — significant revision needed but usable
-//   30–49   Poor — required a full rewrite
-//   0–29    Failed — output was wrong or harmful
-//
-// Step 3: Record via veto_record_outcome:
-//   {
-//     task_type: "write-auth-middleware",  // short label, consistent naming helps
-//     complexity: 58,                      // from veto_route_task result
-//     model_tier: 2,                       // tier that was actually used
-//     agent: "coder",                      // agent type used
-//     output_quality: 87,                  // your score
-//     tokens_used: 1240                    // optional but useful
-//   }
-//
-// Step 4: After 20+ outcomes: call veto_learning_apply
-//   The router reads the quality data and adjusts tier1_max and tier2_max
-//   Adjustment is conservative — it needs 20+ data points to act
-//
-// Step 5: Check veto_learning_stats to see what changed
-`.trim(),
-    checklist: [
-      'Record every task outcome, not just the bad ones — the loop needs both successes and failures',
-      'Use consistent task_type labels across sessions (e.g. "write-unit-tests" not "tests")',
-      'Score output quality honestly — over-reporting quality prevents threshold improvement',
-      'Include tokens_used when possible — this feeds cost/quality optimisation',
-      'Call veto_learning_apply after every 10 new outcomes to keep thresholds current',
-      'Call veto_learning_stats monthly to review the tier distribution and agent performance',
-      'If an agent consistently scores below 70%: check veto_agent_performance_stats for patterns',
-      'Council insights: review veto_council_insights monthly to see if any GREEN verdicts led to debugging',
-    ],
-    patterns: [
-      'Consistent labelling: task_type labels that vary prevent pattern detection ("test" vs "write-tests" vs "unit-tests" are invisible to the loop)',
-      'Regular application: apply thresholds every 10 outcomes — waiting for 100 delays improvement by months',
-      'Quality honesty: the loop self-corrects only when quality scores reflect reality',
-      'Council correlation: the council insights loop needs decisions logged with veto_memory_store to work',
-    ],
-    gotchas: [
-      'Only recording failures — a loop trained on failures sees everything as over-tiered',
-      'Inconsistent task_type labels — "auth", "authentication", "write-auth" look like three different task types',
-      'Not calling veto_learning_apply — recording outcomes without applying has zero effect on routing',
-      'Applying thresholds with fewer than 20 data points — results will be noisy and unreliable',
-    ],
-    resources: [
-      'veto_record_outcome — record a task quality score',
-      'veto_learning_apply — apply recorded outcomes to adjust tier thresholds',
-      'veto_learning_stats — view tier distribution, agent performance, and suggested thresholds',
-      'veto_council_insights — review council decisions correlated with debugging sessions',
-    ],
-  };
-}

package/src/skills/intelligence/skill-pattern-detect.ts

@@ -1,38 +0,0 @@
-// Skill: pattern-detect — find repeated patterns and anti-patterns in a codebase
-
-export interface SkillInput { task: string; context?: string; options?: Record<string, unknown>; }
-export interface SkillOutput { skill: string; checklist: string[]; patterns: string[]; gotchas: string[]; resources: string[]; }
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'pattern-detect',
-    checklist: [
-      'Call veto_patterns_list to load all stored coding patterns before scanning',
-      'Scan the 5 most recently modified files for structural patterns (not style — structure)',
-      'Look for: repeated try/catch shapes, recurring if/else chains, duplicated utility logic',
-      'Look for anti-patterns: N+1 loops, empty catch blocks, hardcoded magic strings/numbers',
-      'Compare found patterns against stored patterns — update confidence via veto_pattern_store',
-      'New patterns not yet stored: add via veto_pattern_store with a category.name key format',
-      'Anti-patterns found: flag them via veto_memory_store (type="pattern", title="Anti-pattern: X")',
-      'After scanning: call veto_agent_plan with agent="pattern-learner" for deeper style analysis',
-    ],
-    patterns: [
-      'Structure over style: detect structural patterns (how code is organised) not style (how it is formatted)',
-      'Frequency threshold: a pattern seen in 3+ files is established; seen in 1–2 files is tentative',
-      'Anti-pattern distinction: store anti-patterns separately with "Anti-pattern:" title prefix',
-      'Confidence accumulation: every confirmed observation of a pattern increments its confidence score',
-    ],
-    gotchas: [
-      'Detecting style instead of structure — style is enforced by a linter; pattern detection adds no value there',
-      'Flagging intentional deviations as anti-patterns — some files deliberately break the pattern (e.g. test fixtures)',
-      'Not updating stored patterns when the codebase evolves — stale patterns mislead future agents',
-      'Storing too-specific patterns ("function X uses this exact shape") vs. too-generic ("uses functions")',
-    ],
-    resources: [
-      'veto_patterns_list — list all stored patterns with confidence scores',
-      'veto_pattern_store — add or update a pattern',
-      'veto_memory_store (type="pattern") — store anti-patterns and architectural patterns',
-      'veto_agent_plan with agent="pattern-learner" — deeper coding style analysis',
-    ],
-  };
-}

package/src/skills/intelligence/skill-rate-watch.ts

@@ -1,61 +0,0 @@
-// Skill: rate-watch — monitor AI rate limits and trigger platform switches proactively
-
-export interface SkillInput { task: string; context?: string; options?: Record<string, unknown>; }
-export interface SkillOutput { skill: string; template?: string; checklist: string[]; patterns: string[]; gotchas: string[]; resources: string[]; }
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'rate-watch',
-    template: `
-// ── Rate Limit Thresholds ─────────────────────────────────────────────────
-//
-//  0–69%   Green zone  — normal routing, no action needed
-// 70–89%   Warning     — Tier 1/2 auto-routes to Gemini/Codex
-//                        Tier 3 stays on Claude (too important to downgrade)
-// 90%+     Critical    — all tasks routed to Gemini/Codex
-//                        Non-urgent work queued for reset
-//
-// Cross-platform switch (manual):
-//
-//   Claude at 90%+ mid-task?
-//   1. Call veto_session_save (capture current state)
-//   2. Note the session ID
-//   3. Open Gemini terminal
-//   4. Call veto_session_restore {session_id}
-//   5. Continue — Gemini has full context
-//   Total interruption: under 10 seconds
-//
-// All platforms at limit simultaneously?
-//   Check veto_rate_status for reset times
-//   Work on tasks that don't need AI (docs, planning, code review checklists)
-//   Auto-resumes when first platform resets
-`.trim(),
-    checklist: [
-      'Call veto_rate_status at the start of long sessions to check headroom',
-      'At 70%: start Tier 1/2 tasks on Gemini/Codex proactively instead of waiting for auto-routing',
-      'At 80%: save the current session via veto_session_save as a precaution',
-      'At 90%: switch platform manually using veto_session_save → veto_session_restore',
-      'At 100%: check reset times from veto_rate_status, switch to non-AI tasks until reset',
-      'After a platform switch: verify the session restored correctly before continuing',
-      'Prefer Gemini for T1/T2 overflow — it has higher rate limits on the free tier',
-    ],
-    patterns: [
-      'Proactive switch at 80%: switching before hitting 90% avoids a mid-task interruption',
-      'Session save at 70%: ensures context is preserved if a hard limit is hit unexpectedly',
-      'Platform diversity: using two platforms in parallel halves the effective rate limit pressure',
-      'Tier-based overflow: only T1/T2 overflow — never route T3 to a lower-capability model',
-    ],
-    gotchas: [
-      'Switching platforms without saving the session — the receiving platform starts blind',
-      'Routing Tier 3 tasks to Gemini Flash or Haiku to avoid rate limits — quality loss is not worth it',
-      'Not checking rate status before a long task — hitting the limit mid-migration is high risk',
-      'Forgetting that rate limits reset daily at midnight UTC — a limit today may reset in 2 hours',
-    ],
-    resources: [
-      'veto_rate_status — current usage % and advisory for all platforms',
-      'veto_route_task — routes tasks to the least-loaded platform automatically',
-      'veto_session_save — save context before switching platforms',
-      'veto_session_restore — restore on the receiving platform',
-    ],
-  };
-}

package/src/skills/memory/skill-context-compress.ts

@@ -1,98 +0,0 @@
-// Skill: context-compress — when and how to compress context before model calls
-
-export interface SkillInput {
-  task: string;
-  context?: string;
-  options?: Record<string, unknown>;
-}
-
-export interface SkillOutput {
-  skill: string;
-  template?: string;
-  checklist: string[];
-  patterns: string[];
-  gotchas: string[];
-  resources: string[];
-}
-
-const TEMPLATE = `
-// ── Context Compression Protocol ─────────────────────────────────────────
-//
-// Apply when token count > 8,000 or before any cross-platform handoff.
-// Target: < 30% of original token count, zero loss of active constraints.
-//
-// Compression tiers:
-//
-// TIER 1 — Keep verbatim (never compress):
-//   - Active blockers that require human input
-//   - Open decisions that have not been resolved
-//   - File paths of files currently being modified
-//   - The single next action
-//   - Error messages that have not been diagnosed
-//
-// TIER 2 — Compress to 1–3 sentences:
-//   - Completed subtasks (collapse to "✓ Implemented X")
-//   - Read-back confirmations ("confirmed the file exists")
-//   - Resolved blockers ("fixed: dependency conflict — used --legacy-peer-deps")
-//   - Prior session context (collapse to a 2-sentence progress summary)
-//
-// TIER 3 — Drop entirely:
-//   - Superseded decisions (replaced by a newer ADR)
-//   - Files read but not modified and not needed going forward
-//   - Exploratory steps that led to dead ends and have been abandoned
-//   - Console output that has already been analyzed
-//
-// Compressed context shape:
-{
-  "phase": "implementing",
-  "completed": ["Brief one-liner per completed subtask"],
-  "inProgress": "The exact current subtask in one sentence",
-  "remaining": ["Ordered list of remaining subtasks"],
-  "activeConstraints": ["Each constraint in one sentence"],
-  "openDecisions": [{ "question": "...", "options": ["A", "B"] }],
-  "blockers": ["Any current blocker with full detail"],
-  "keyFiles": ["Only files still needed going forward"],
-  "nextAction": "Single concrete step — unambiguous"
-}
-`.trim();
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'context-compress',
-    template: TEMPLATE,
-    checklist: [
-      'Measure the current context token estimate before compressing',
-      'Apply compression only when token count exceeds 8,000 or before a platform handoff',
-      'Identify Tier 1 items first — these are never touched',
-      'Identify Tier 3 items — drop them completely without summarising',
-      'For Tier 2 items: write one sentence per completed subtask; the reader does not need the history',
-      'Preserve the full text of any active blocker — the receiving agent must understand it in full',
-      'Preserve the nextAction as a concrete step, not "continue the task"',
-      'After compressing: verify the compressed context is complete by simulating a cold-start agent reading it',
-      'Save the compressed context via veto_session_save before switching context',
-      'Target a compression ratio of at least 3:1 — if you cannot achieve this, you have too many Tier 1 items',
-      'Do not compress active error messages — they need full context to diagnose',
-      'Do not summarise open decisions — they need all options preserved',
-    ],
-    patterns: [
-      'Tier-based compression: verbatim | summarise | drop — never binary keep/delete',
-      'Cold-start test: can a fresh agent read the compressed context and continue the task without questions?',
-      'Constraint-first ordering: active constraints at the top, history at the bottom',
-      'Forward-only compression: compress backward-looking content, not forward-looking content',
-    ],
-    gotchas: [
-      'Compressing active constraints as if they were completed work — causes silent violations in the next session',
-      'Summarising blockers instead of preserving them verbatim — the receiving agent gets a vague summary and cannot resolve the blocker',
-      'Dropping unresolved error messages — the receiving agent restarts diagnosis from scratch',
-      'Targeting a fixed token count without checking completeness — may cut load-bearing context',
-      'Not saving the compressed context — the compression is lost on the next context switch',
-      'Treating all prior session content as droppable — some prior-session decisions are still active constraints',
-    ],
-    resources: [
-      'Use veto_route_task with context= to get the router\'s compression estimate',
-      'Use veto_session_save to persist the compressed context',
-      'Use veto_memory_store to permanently record key decisions before they are compressed away',
-      'The compression target is based on the router\'s context-compressor module heuristics',
-    ],
-  };
-}

package/src/skills/memory/skill-cross-sync.ts

@@ -1,104 +0,0 @@
-// Skill: cross-sync — how to move veto memory between machines using file export/import
-
-export interface SkillInput {
-  task: string;
-  context?: string;
-  options?: Record<string, unknown>;
-}
-
-export interface SkillOutput {
-  skill: string;
-  template?: string;
-  checklist: string[];
-  patterns: string[];
-  gotchas: string[];
-  resources: string[];
-}
-
-const TEMPLATE = `
-// ── Cross-Machine Memory Transfer ────────────────────────────────────────
-//
-// Veto stores everything in ~/.veto/veto.db (SQLite).
-// To continue work on another machine: export → copy → import.
-//
-// No external services. No accounts. No env vars.
-//
-// ── Step 1: Export on Machine A ───────────────────────────────────────────
-//
-//   veto_memory_export
-//   → writes to ~/.veto/veto-export.json by default
-//   → or specify output_path to write directly to shared storage
-//
-//   Example with shared storage:
-//   veto_memory_export { output_path: "/Users/you/Dropbox/veto-export.json" }
-//
-// ── Step 2: Copy the file ─────────────────────────────────────────────────
-//
-//   Options (pick any):
-//   • Dropbox / OneDrive / Google Drive — put output_path in your sync folder
-//   • USB drive
-//   • scp / rsync over SSH
-//   • Email / messaging app
-//   • AirDrop (Mac)
-//
-// ── Step 3: Import on Machine B ───────────────────────────────────────────
-//
-//   veto_memory_import { input_path: "/path/to/veto-export.json" }
-//   → merges into local ~/.veto/veto.db
-//   → INSERT OR IGNORE — local rows are never overwritten
-//   → returns { merged: {...}, skipped: {...} } showing what was added
-//
-// ── Step 4: Verify and resume ─────────────────────────────────────────────
-//
-//   veto_sessions_list           — confirm sessions arrived
-//   veto_session_restore { id }  — load the session you want to continue
-//   veto_memory_search { query } — confirm knowledge base arrived
-//
-// ── What gets exported ────────────────────────────────────────────────────
-//
-//   sessions         — all saved sessions with task state and context
-//   decisions        — all logged decisions and rationale
-//   knowledge_base   — all stored solutions, patterns, errors, references
-//   patterns         — coding style and convention patterns
-//   project_map      — codebase structure maps
-//   council_outcomes — all council debate results
-`.trim();
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'cross-sync',
-    template: TEMPLATE,
-    checklist: [
-      'Before leaving Machine A: call veto_memory_export to create the export file',
-      'Check the export result — confirm row counts look right for sessions and knowledge_base',
-      'Copy the export file to Machine B via any method (Dropbox, USB, scp, etc.)',
-      'On Machine B: call veto_memory_import with the file path',
-      'Check the import result — merged counts show what was added, skipped counts show duplicates',
-      'Call veto_sessions_list to confirm the sessions you need are present',
-      'Call veto_session_restore with the session ID to load your prior context',
-      'Call veto_memory_search to confirm knowledge base entries are available',
-      'If working across multiple machines regularly: use a shared folder (Dropbox) as output_path so no manual copy is needed',
-      'After significant work on Machine B: run veto_memory_export again before switching back',
-    ],
-    patterns: [
-      'Export-before-switch: always export before ending a session, not only when switching machines',
-      'Shared-folder shortcut: point output_path at a Dropbox/OneDrive folder — no manual copy step',
-      'Merge semantics: INSERT OR IGNORE means both machines can export/import in any order without data loss',
-      'Verify-after-import: always call veto_sessions_list after import to confirm data arrived before starting work',
-    ],
-    gotchas: [
-      'Forgetting to export before switching — Machine B starts with no memory of Machine A\'s work',
-      'Importing a stale export (from yesterday) — you lose today\'s work on Machine A; always export fresh',
-      'The export file is plain JSON — it contains your session context. Don\'t commit it to a public git repo',
-      'Pattern merge adds seen_counts from both machines — this is intentional (more observations = higher confidence)',
-      'INSERT OR IGNORE means if Machine B already has a session with the same ID, it is not updated. Export fresh from Machine A if you need the latest version of a session',
-    ],
-    resources: [
-      'veto_memory_export — export all memory to JSON (default path: ~/.veto/veto-export.json)',
-      'veto_memory_import — import and merge JSON into local SQLite',
-      'veto_sessions_list — verify sessions after import',
-      'veto_session_restore — load a specific session to resume work',
-      'veto_memory_search — verify knowledge base after import',
-    ],
-  };
-}

package/src/skills/memory/skill-decision-log.ts

@@ -1,119 +0,0 @@
-// Skill: decision-log — guide to logging architectural and design decisions
-
-export interface SkillInput {
-  task: string;
-  context?: string;
-  options?: Record<string, unknown>;
-}
-
-export interface SkillOutput {
-  skill: string;
-  template?: string;
-  checklist: string[];
-  patterns: string[];
-  gotchas: string[];
-  resources: string[];
-}
-
-const TEMPLATE = `
-// ── Decision Log Entry ────────────────────────────────────────────────────
-//
-// Use this template for any decision that is:
-//   - Non-obvious (a reasonable engineer could choose differently)
-//   - Hard to reverse (schema changes, API contracts, auth architecture)
-//   - Frequently re-discussed (keeps relitigating the same debate)
-//   - A deliberate trade-off (performance vs correctness, simplicity vs flexibility)
-//
-{
-  "id": "ADR-001",                        // Sequential ID for referencing
-  "title": "Use JWT with rotating refresh tokens for authentication",
-  "status": "accepted",                   // proposed | accepted | deprecated | superseded-by:ADR-xxx
-  "date": "2026-05-01",
-  "deciders": ["agent:auth", "human:alice"],
-
-  "context": "We need an authentication mechanism for a stateless REST API that will be consumed by a mobile app and a web SPA. Session cookies are not ideal for the mobile client.",
-
-  "decision": "Implement stateless JWTs for access (15-minute TTL) with rotating refresh tokens stored server-side in a database table.",
-
-  "rationale": "JWTs allow stateless verification on every request without a DB lookup. Refresh token rotation limits the window of token theft. httpOnly cookies for refresh tokens prevent XSS access.",
-
-  "alternatives": [
-    {
-      "option": "Server-side sessions with Redis",
-      "pros": ["Instant revocation", "No JWT complexity"],
-      "cons": ["Requires Redis infrastructure", "Not stateless — every request hits Redis", "Mobile clients struggle with cookie-based sessions"],
-      "rejected_because": "Adds Redis dependency; poor fit for mobile client"
-    },
-    {
-      "option": "Long-lived JWTs with no refresh",
-      "pros": ["Simple implementation"],
-      "cons": ["Cannot revoke without infrastructure", "Long-lived tokens are a large attack window"],
-      "rejected_because": "Unacceptable security risk if token is stolen"
-    }
-  ],
-
-  "consequences": {
-    "positive": [
-      "Stateless verification — no DB lookup per request",
-      "Refresh token rotation limits theft window to 15 minutes",
-      "Mobile and web clients use the same auth mechanism"
-    ],
-    "negative": [
-      "Access tokens cannot be revoked before expiry (15-minute window)",
-      "Requires refresh token table with periodic cleanup job",
-      "More complex than simple sessions"
-    ],
-    "neutral": [
-      "JWT library (jsonwebtoken) must be kept up to date for security patches"
-    ]
-  },
-
-  "references": [
-    "OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html",
-    "RFC 6749 OAuth 2.0 Bearer Tokens",
-    "Related implementation: src/services/auth.service.ts"
-  ]
-}
-`.trim();
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'decision-log',
-    template: TEMPLATE,
-    checklist: [
-      'Log the decision as soon as it is made — memory fades quickly and context is lost',
-      'Assign a sequential ID (ADR-001, ADR-002) to enable referencing in code comments and PRs',
-      'Write the context section first: describe the forces and constraints that made a choice necessary',
-      'State the decision explicitly and unambiguously — one clear sentence of what was decided',
-      'Document the rationale: why this option over the alternatives?',
-      'List at least two alternatives that were genuinely considered, not just strawmen',
-      'For each alternative, record pros, cons, and the specific reason it was rejected',
-      'Document positive, negative, and neutral consequences of the chosen option',
-      'Set the status field: proposed → accepted → deprecated or superseded-by:ADR-xxx',
-      'Add file references so future engineers can find the implementation',
-      'Reference the decision ID in relevant code comments: // See ADR-001',
-      'Store the decision log in docs/decisions/ or as a session memory entry',
-      'Update the status to "deprecated" or "superseded" when the decision changes — never delete',
-      'Review the decision log when revisiting a design — check if the original constraints still apply',
-    ],
-    patterns: [
-      'Architecture Decision Record (ADR) format: context → decision → rationale → alternatives → consequences',
-      'Decision-in-context: link from code to the decision that explains the design choice',
-      'Living document: update status when decisions change rather than deleting entries',
-      'Lightweight ADR: one file per decision, stored in git alongside the code it describes',
-    ],
-    gotchas: [
-      'Writing the decision without the rationale — future engineers will not know why, only what',
-      'Only documenting the chosen option without listing alternatives — looks like no thought went into it',
-      'Not updating stale decisions — a deprecated decision still marked "accepted" causes confusion',
-      'Writing the ADR after the fact with the benefit of hindsight — capture the original thinking at decision time',
-      'Logging trivial decisions — reserve the log for non-obvious choices; not every variable name needs an ADR',
-    ],
-    resources: [
-      'https://adr.github.io/ (Architectural Decision Records overview)',
-      'https://github.com/joelparkerhenderson/architecture-decision-record (templates and examples)',
-      'https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions (original Michael Nygard post)',
-      'https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records',
-    ],
-  };
-}

package/src/skills/memory/skill-session-restore.ts

@@ -1,59 +0,0 @@
-// Skill: session-restore — guide to restoring context from a saved session
-
-export interface SkillInput {
-  task: string;
-  context?: string;
-  options?: Record<string, unknown>;
-}
-
-export interface SkillOutput {
-  skill: string;
-  template?: string;
-  checklist: string[];
-  patterns: string[];
-  gotchas: string[];
-  resources: string[];
-}
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'session-restore',
-    template: undefined,
-    checklist: [
-      'Call veto_sessions_list to get all available saved sessions',
-      'Identify the most relevant session: sort by updatedAt descending, read the task summary',
-      'If multiple sessions match the current task, read the top 2-3 and pick the most recent',
-      'Call veto_session_restore with the selected sessionId to load the full session object',
-      'Read the phase field to understand where work was left off (planning/implementing/reviewing/blocked)',
-      'Read progress.completed to know what has already been done — do not redo this work',
-      'Read progress.inProgress to know the exact subtask that was interrupted',
-      'Read progress.remaining to understand the full remaining scope before starting',
-      'Read decisions to understand constraints and design choices already made — do not revisit them without cause',
-      'Read findings to get codebase context (key files, discovered patterns, constraints)',
-      'Read blockers: if any blockers are listed, address them before continuing other work',
-      'Read nextAction and treat it as the starting instruction for this session',
-      'Re-read any key files mentioned in findings.filePaths before making changes',
-      'Verify that the code state matches expectations: if the session is old, re-check completed items',
-      'Save a new session checkpoint immediately after restoring and verifying context',
-    ],
-    patterns: [
-      'Restore-verify-continue: always verify actual code state matches what the session recorded before acting',
-      'Trust but verify: session describes intent; re-read key files to confirm they match expectations',
-      'Single source of truth: the saved session is authoritative about decisions and progress',
-      'Restore at the start of every new conversation before doing any work on a multi-session task',
-    ],
-    gotchas: [
-      'Restoring an old session and acting on stale file paths — files may have been moved or deleted',
-      'Skipping the verify step and redoing work already marked as completed — wastes time and may undo changes',
-      'Picking the wrong session when multiple tasks are in progress — check the task field carefully',
-      'Not saving a new checkpoint after restore — the next session will still start from the old state',
-      'Trusting a session that was saved in a "blocked" state without first resolving the blocker',
-    ],
-    resources: [
-      'Use the veto_session_restore MCP tool: { sessionId } → returns full session object',
-      'Use the veto_sessions_list MCP tool: returns all sessions sorted by updatedAt',
-      'Use the veto_session_save MCP tool after restoration to record the new starting point',
-      'MCP Session spec: https://modelcontextprotocol.io/docs/concepts/resources',
-    ],
-  };
-}

package/src/skills/memory/skill-session-save.ts

@@ -1,94 +0,0 @@
-// Skill: session-save — when and how to save MCP sessions
-
-export interface SkillInput {
-  task: string;
-  context?: string;
-  options?: Record<string, unknown>;
-}
-
-export interface SkillOutput {
-  skill: string;
-  template?: string;
-  checklist: string[];
-  patterns: string[];
-  gotchas: string[];
-  resources: string[];
-}
-
-const TEMPLATE = `
-// ── What to include in a session save ────────────────────────────────────
-//
-// A session save should capture enough context so that a future agent
-// can resume work without re-reading all the source files.
-//
-// Recommended session object shape:
-{
-  "task": "The original task description in one sentence",
-  "phase": "planning | implementing | reviewing | blocked | complete",
-  "progress": {
-    "completed": ["List of finished subtasks or files written"],
-    "inProgress": ["Current subtask being worked on"],
-    "remaining": ["Subtasks still to do"]
-  },
-  "decisions": [
-    {
-      "decision": "What was decided",
-      "rationale": "Why this approach was chosen",
-      "alternatives": ["Other options that were considered"],
-      "timestamp": "ISO 8601 timestamp"
-    }
-  ],
-  "findings": [
-    "Any important discoveries that affect future work",
-    "File paths of key files that were read or modified",
-    "Patterns or constraints discovered in the codebase"
-  ],
-  "blockers": [
-    "Anything preventing progress that needs human input"
-  ],
-  "nextAction": "The single most important next step to resume work"
-}
-`.trim();
-
-export function run(input: SkillInput): SkillOutput {
-  return {
-    skill: 'session-save',
-    template: TEMPLATE,
-    checklist: [
-      'Save at the start of every new significant phase: planning, implementing, reviewing',
-      'Save after completing each major file or subtask — checkpoint before moving to the next',
-      'Save before any risky operation (file overwrites, schema migrations, destructive commands)',
-      'Save immediately when a blocker is encountered that requires human input',
-      'Save when token context is getting large — a compact save enables a fresh continuation',
-      'Include the original task description verbatim so it is never lost across sessions',
-      'Include current phase: planning / implementing / reviewing / blocked / complete',
-      'Include progress: completed[], inProgress[], remaining[] as concrete task lists',
-      'Include decisions made: decision + rationale + alternatives considered',
-      'Include codebase findings: key file paths discovered, constraints, patterns found',
-      'Include blockers: anything requiring human action before work can continue',
-      'Include nextAction: the single most important next step as a concrete instruction',
-      'Keep each save concise — aim for < 500 tokens; link to files rather than copying content',
-      'Use the veto_session_save MCP tool to persist the session to SQLite',
-      'Verify the save succeeded by calling veto_sessions_list and confirming the session appears',
-    ],
-    patterns: [
-      'Checkpoint pattern: save after each completed unit of work, not only at the end',
-      'Progressive detail: early saves capture intent; later saves add findings and decisions',
-      'Minimal viable context: save enough to resume, not a full transcript of every action',
-      'Blocker-first save: when stuck, save immediately with the blocker clearly stated',
-    ],
-    gotchas: [
-      'Not saving before a context switch — the next session starts blind without a save',
-      'Saving too much detail — a 5,000-token session save is expensive to restore and read',
-      'Forgetting to include nextAction — the restoring agent does not know where to start',
-      'Saving only at the very end — if the task fails partway through, the intermediate work is lost',
-      'Using vague phase descriptions ("working") instead of concrete phases (implementing step 3 of 7)',
-    ],
-    resources: [
-      'Use the veto_session_save MCP tool: { sessionId, task, phase, progress, decisions, findings }',
-      'Use the veto_sessions_list MCP tool to verify saves and list available sessions',
-      'Use the veto_session_restore MCP tool to reload a previous session',
-      'MCP Session spec: https://modelcontextprotocol.io/docs/concepts/resources',
-    ],
-  };
-}