@jigyasudham/veto 0.8.0

package/dist/skills/intelligence/skill-learning-loop.js

@@ -0,0 +1,66 @@
+// Skill: learning-loop — how to feed outcome data back into the router and agents
+export function run(input) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-learning-loop.js.map

package/dist/skills/intelligence/skill-pattern-detect.js

@@ -0,0 +1,35 @@
+// Skill: pattern-detect — find repeated patterns and anti-patterns in a codebase
+export function run(input) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-pattern-detect.js.map

package/dist/skills/intelligence/skill-rate-watch.js

@@ -0,0 +1,58 @@
+// Skill: rate-watch — monitor AI rate limits and trigger platform switches proactively
+export function run(input) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-rate-watch.js.map

package/dist/skills/memory/skill-context-compress.js

@@ -0,0 +1,82 @@
+// Skill: context-compress — when and how to compress context before model calls
+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) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-context-compress.js.map

package/dist/skills/memory/skill-cross-sync.js

@@ -0,0 +1,88 @@
+// Skill: cross-sync — how to move veto memory between machines using file export/import
+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) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-cross-sync.js.map

package/dist/skills/memory/skill-decision-log.js

@@ -0,0 +1,103 @@
+// Skill: decision-log — guide to logging architectural and design decisions
+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) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-decision-log.js.map

package/dist/skills/memory/skill-session-restore.js

@@ -0,0 +1,44 @@
+// Skill: session-restore — guide to restoring context from a saved session
+export function run(input) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-session-restore.js.map

package/dist/skills/memory/skill-session-save.js

@@ -0,0 +1,78 @@
+// Skill: session-save — when and how to save MCP sessions
+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) {
+    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',
+        ],
+    };
+}
+//# sourceMappingURL=skill-session-save.js.map

package/dist/skills/quality/skill-accessibility.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=skill-accessibility.js.map

package/dist/skills/quality/skill-code-review.js

@@ -0,0 +1,60 @@
+// Skill: code-review — 20-point code review checklist
+export function run(input) {
+    return {
+        skill: 'code-review',
+        template: undefined,
+        checklist: [
+            // Correctness (1-4)
+            '1. CORRECTNESS — Does the code do what the PR description says? Walk through the logic manually with a concrete example.',
+            '2. EDGE CASES — Does it handle null/undefined, empty collections, zero, negative numbers, very large inputs, and concurrent calls correctly?',
+            '3. ERROR HANDLING — Are all errors caught, typed, and handled? No silent swallowed errors, no bare catch blocks that discard the error.',
+            '4. CONCURRENCY — Does shared mutable state have proper synchronisation? Are async operations correctly awaited? No floating promises.',
+            // Security (5-7)
+            '5. INPUT VALIDATION — Is all user-supplied input validated with a schema library (zod/joi) before use? No raw string concatenation into queries.',
+            '6. AUTHENTICATION & AUTHORISATION — Does every data-access path check that the requesting user owns the resource? Is auth middleware applied?',
+            '7. SECRETS — No hardcoded credentials, API keys, or tokens in the diff. No sensitive values logged or included in error responses.',
+            // Performance (8-9)
+            '8. N+1 QUERIES — Are list endpoints fetching related records in a loop? Use batch/include/join instead.',
+            '9. COMPLEXITY — Are there any O(n²) or worse algorithms on large datasets? Is database access inside a loop?',
+            // Types and naming (10-12)
+            '10. TYPES — Is TypeScript used strictly (no `any`, no type assertions without comment)? Are interfaces and return types explicit on public functions?',
+            '11. NAMING — Are variables, functions, and classes named clearly and consistently? Do boolean variables use is/has/should prefixes?',
+            '12. MAGIC VALUES — Are all magic numbers and magic strings replaced with named constants or enums?',
+            // Style and complexity (13-14)
+            '13. COMPLEXITY — Are functions short (< 30 lines) and single-purpose? If a function requires a long comment to explain it, refactor instead.',
+            '14. DUPLICATION — Is the same logic copy-pasted from elsewhere? Extract a shared utility or extend an existing one.',
+            // Tests (15-16)
+            '15. TEST COVERAGE — Are there tests for the new code? Do they cover the happy path, error paths, and at least one edge case?',
+            '16. TEST QUALITY — Do the tests assert on the right things? Are mocks minimal and purposeful? Tests should not duplicate implementation logic.',
+            // Documentation (17)
+            '17. DOCUMENTATION — Do complex functions have a JSDoc comment explaining the why (not just the what)? Are public API changes reflected in the OpenAPI spec?',
+            // Dependencies and build (18)
+            '18. DEPENDENCIES — Are new npm packages justified? Check for license compatibility, maintenance status, and security advisories (npm audit).',
+            // Observability (19)
+            '19. OBSERVABILITY — Are significant operations logged at the appropriate level? Are errors logged with enough context to diagnose? No passwords in logs.',
+            // Review hygiene (20)
+            '20. BREAKING CHANGES — Does the change break any existing API contracts, DB schemas, or public interfaces? If so, is it properly versioned or migrated?',
+        ],
+        patterns: [
+            'Review the diff, not the file — focus on what changed and why',
+            'Ask questions instead of issuing commands: "Could this be null here?" vs "Fix this"',
+            'Distinguish blocking issues (must fix) from suggestions (nice to have) in comments',
+            'Approve with comments for minor non-blocking issues rather than blocking for style',
+            'Check the tests before the implementation — tests reveal the intended behaviour',
+        ],
+        gotchas: [
+            'Approving without running or reading the tests — tests are part of the code',
+            'Nitpicking style when an auto-formatter (Prettier/ESLint) should enforce it',
+            'Missing the forest for the trees: reviewing individual lines but missing a design flaw',
+            'Not reviewing DB migrations for data safety (missing IF NOT EXISTS, backfill plan)',
+            'Forgetting to check error message text — "null pointer exception" leaking to the user',
+        ],
+        resources: [
+            'https://google.github.io/eng-practices/review/reviewer/',
+            'https://mtlynch.io/code-review-love/',
+            'https://www.conventionalcommits.org/ (PR title / commit message style)',
+            'https://cheatsheetseries.owasp.org/cheatsheets/Code_Review_Guide_Introduction_Cheat_Sheet.html',
+        ],
+    };
+}
+//# sourceMappingURL=skill-code-review.js.map

package/dist/skills/quality/skill-docs-gen.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=skill-docs-gen.js.map

package/dist/skills/quality/skill-perf-audit.js

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=skill-perf-audit.js.map