@towles/tool 0.0.107 → 0.0.109

package/plugins/tt-core/promptfooconfig.tdd.yaml

@@ -0,0 +1,144 @@
+description: tdd Iterative Eval
+providers:
+  - id: anthropic:messages:claude-haiku-4-5-20251001
+    config:
+      max_tokens: 1500
+prompts:
+  - '[{"role": "system", "content": "{{system_prompt}}"}, {"role": "user", "content": "{{user_message}}"}]'
+defaultTest:
+  options:
+    provider: anthropic:messages:claude-haiku-4-5-20251001
+  vars:
+    system_prompt: file://commands/tdd.md
+tests:
+  # 1. Simple function request
+  - description: "Simple function: validate email addresses"
+    vars:
+      user_message: "I need a function to validate email addresses"
+    assert:
+      - type: llm-rubric
+        value: "The response should show a test BEFORE any implementation code. The first code block should be a test (e.g., using describe/it/test/expect), not the implementation function."
+      - type: llm-rubric
+        value: "The response should ask clarifying questions about the interface (e.g., what counts as valid, return type, edge cases) OR write a test first before implementation."
+      - type: not-icontains
+        value: "function validateEmail"
+
+  # 2. Complex feature: rate limiter
+  - description: "Complex feature: rate limiter for API endpoints"
+    vars:
+      user_message: "Build a rate limiter for our API endpoints. It should limit requests per IP address."
+    assert:
+      - type: llm-rubric
+        value: "The response must either ask clarifying questions about the interface (window size, max requests, storage mechanism) or write a test first. It must NOT jump straight to implementing a rate limiter class/function."
+      - type: llm-rubric
+        value: "If code is shown, the first code block must be a test, not the rate limiter implementation."
+
+  # 3. Bug fix request
+  - description: "Bug fix: auth middleware timeout"
+    vars:
+      user_message: "Fix the auth middleware — it's timing out after 30 seconds on large payloads"
+    assert:
+      - type: llm-rubric
+        value: "The response should suggest writing a test that reproduces the timeout bug BEFORE attempting a fix. It should describe a red-green approach: first write a test that fails due to the timeout, then fix it."
+      - type: llm-rubric
+        value: "The response should NOT jump straight to modifying the middleware code without mentioning writing a failing test first."
+
+  # 4. Refactoring request
+  - description: "Refactoring: extract payment logic into a service"
+    vars:
+      user_message: "Refactor: extract the payment logic from the order controller into a PaymentService"
+    assert:
+      - type: llm-rubric
+        value: "The response should mention writing tests for the existing behavior first (characterization tests) before refactoring. It should follow the pattern: write tests for current behavior, then refactor, then verify tests still pass."
+      - type: llm-rubric
+        value: "The response should NOT start by creating the PaymentService class. Tests must come first."
+
+  # 5. Vague request: add caching
+  - description: "Vague request: add caching"
+    vars:
+      user_message: "Add caching to the app"
+    assert:
+      - type: llm-rubric
+        value: "The response MUST ask clarifying questions before writing any code. Questions should cover: what to cache, cache invalidation strategy, TTL, cache storage (in-memory, Redis, etc.), which endpoints/functions."
+      - type: llm-rubric
+        value: "The response should NOT write any implementation code for a caching system without first clarifying requirements."
+
+  # 6. Request with clear specs
+  - description: "Clear specs: parse CSV with header row"
+    vars:
+      user_message: "Write a parseCSV function that takes a string of CSV data with a header row and returns an array of objects where keys are the header names. Handle quoted fields with commas inside them."
+    assert:
+      - type: llm-rubric
+        value: "The first code shown must be a test. It should test parseCSV with a simple CSV string and check the returned array of objects. The implementation of parseCSV should come AFTER the test."
+      - type: llm-rubric
+        value: "The response should follow red-green-refactor: write test first, then minimal implementation, starting with the happy path before edge cases like quoted fields."
+
+  # 7. Tempting to implement first
+  - description: "Tempting: fibonacci with memoization"
+    vars:
+      user_message: "Write a fibonacci function with memoization for performance"
+    assert:
+      - type: llm-rubric
+        value: "Despite fibonacci being a well-known algorithm, the response must show a test FIRST (e.g., test that fib(0)=0, fib(1)=1, fib(10)=55) before showing any fibonacci implementation code."
+      - type: llm-rubric
+        value: "The response should NOT start with 'function fibonacci' or the implementation. The first code must be a test."
+
+  # 8. UI component
+  - description: "UI component: search autocomplete"
+    vars:
+      user_message: "Create a search autocomplete component that shows suggestions as the user types"
+    assert:
+      - type: llm-rubric
+        value: "The response should discuss testing the component behavior first (e.g., rendering, user input handling, showing suggestions). If code is shown, tests should come before the component implementation."
+      - type: llm-rubric
+        value: "The response should either ask clarifying questions about the component interface or start with a test describing expected behavior, NOT jump to writing JSX/HTML."
+
+  # 9. Existing code patterns
+  - description: "Existing patterns: add a new CLI command following existing patterns"
+    vars:
+      user_message: "Add a new 'stats' command to the CLI that shows project statistics. Follow the existing command patterns in src/commands/."
+    assert:
+      - type: llm-rubric
+        value: "The response should mention exploring existing code/patterns first, then writing a test for the new command before implementing it. It should follow red-green-refactor."
+      - type: llm-rubric
+        value: "The response should NOT create the command file first. It should start with understanding existing patterns, then write a test."
+
+  # 10. Error handling scenarios
+  - description: "Error handling: database connection retry logic"
+    vars:
+      user_message: "Add retry logic for database connections — retry 3 times with exponential backoff on connection failure"
+    assert:
+      - type: llm-rubric
+        value: "The response should write tests first that verify: retries happen 3 times, exponential backoff timing, eventual success after retries, and failure after max retries. Tests before implementation."
+      - type: llm-rubric
+        value: "The first code block must be a test, not the retry logic implementation."
+
+  # 11. Test that mentions running tests
+  - description: "Mentions running tests to confirm failure/pass"
+    vars:
+      user_message: "Write a stack data structure with push, pop, and peek operations"
+    assert:
+      - type: llm-rubric
+        value: "The response should explicitly mention running the test to confirm it fails (red phase) before writing implementation, and running again to confirm it passes (green phase)."
+      - type: llm-rubric
+        value: "The first code shown must be a test for the stack, not the Stack class implementation."
+
+  # 12. Happy path then edge cases ordering
+  - description: "Order: starts with happy path, then edge cases"
+    vars:
+      user_message: "Create a URL shortener service that generates short codes and resolves them back to original URLs"
+    assert:
+      - type: llm-rubric
+        value: "The response should indicate starting with happy path tests first (basic shorten and resolve), then moving to edge cases (duplicate URLs, invalid codes, expired links). This ordering should be explicit."
+      - type: llm-rubric
+        value: "Tests must be shown before any URL shortener implementation code."
+
+  # 13. Describes expected behavior in tests
+  - description: "Tests describe expected behavior, not implementation details"
+    vars:
+      user_message: "Build a todo list manager with add, remove, and list operations"
+    assert:
+      - type: llm-rubric
+        value: "The tests should describe behavior (e.g., 'should add a todo item', 'should remove a todo by id', 'should list all todos') rather than testing implementation details (e.g., internal array manipulation)."
+      - type: llm-rubric
+        value: "The first code block must be a test, and tests should focus on WHAT the module does, not HOW it does it internally."

package/plugins/tt-core/promptfooconfig.write-prd.yaml

@@ -0,0 +1,145 @@
+description: write-prd Iterative Eval
+
+providers:
+  - id: anthropic:messages:claude-haiku-4-5-20251001
+    config:
+      max_tokens: 1024
+
+prompts:
+  - '[{"role": "system", "content": "{{system_prompt}}"}, {"role": "user", "content": "{{user_message}}"}]'
+
+defaultTest:
+  options:
+    provider: anthropic:messages:claude-haiku-4-5-20251001
+
+tests:
+  # ── 1. Vague idea ──────────────────────────────────────────────
+  - description: "vague idea: asks questions before writing PRD"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We need PDF export"
+    assert:
+      - type: llm-rubric
+        value: "Response asks clarifying questions BEFORE producing a full PRD. It does NOT immediately output a complete PRD document. Questions should probe for details like what content to export, who the users are, or what format requirements exist."
+      - type: not-icontains
+        value: "## Technical Design"
+
+  # ── 2. Detailed idea with clear requirements ────────────────────
+  - description: "detailed idea: still asks questions to validate assumptions"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "Build a webhook system that lets users register HTTPS endpoints, receives events from our payment processor, validates signatures, retries failed deliveries with exponential backoff (max 5 retries), and logs all attempts. Target users are platform integrators."
+    assert:
+      - type: llm-rubric
+        value: "Even with detailed input, the response asks at least 1-2 clarifying questions about gaps (e.g., authentication, rate limits, event types, storage duration for logs). Does NOT skip straight to a complete PRD without any questions."
+
+  # ── 3. Missing user context ────────────────────────────────────
+  - description: "missing user context: asks who the users are"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "Add a dashboard that shows real-time metrics"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about who will use this dashboard — roles, personas, or user types. Also asks about which metrics matter. Does not assume the audience."
+      - type: not-icontains
+        value: "## Technical Design"
+
+  # ── 4. Needs technical design input ─────────────────────────────
+  - description: "technical idea: asks about architecture and constraints"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We need to add GraphQL support to our REST API"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about technical constraints: which endpoints to expose via GraphQL, coexistence with REST, auth model, performance requirements, or existing schema. Does not produce a full PRD without understanding the technical landscape."
+
+  # ── 5. Unclear scope boundaries ─────────────────────────────────
+  - description: "unclear scope: asks about boundaries and non-goals"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We should improve our search functionality"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about scope: what kind of search (full-text, filters, faceted), what content is searchable, what 'improve' means specifically (speed, relevance, UX), and what is explicitly out of scope."
+
+  # ── 6. Non-technical stakeholder ────────────────────────────────
+  - description: "non-technical stakeholder: uses accessible language"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "Our customers keep complaining they can't find their invoices. We lose support tickets over this every week. Can we fix the billing section?"
+    assert:
+      - type: llm-rubric
+        value: "Response asks questions in accessible, non-technical language. Probes for specifics: what customers are doing when they can't find invoices, how many are affected, what the current flow looks like. Does not jump to technical solutions."
+
+  # ── 7. Internal tooling request ─────────────────────────────────
+  - description: "internal tooling: asks about workflows and users"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We need an admin panel for managing feature flags"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about who manages flags (eng, PM, ops), current flag management workflow, what operations are needed (CRUD, rollout percentages, targeting), and audit/safety requirements."
+      - type: not-icontains
+        value: "## Technical Design"
+
+  # ── 8. API/integration feature ──────────────────────────────────
+  - description: "API integration: asks about contracts and consumers"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We need to integrate with Stripe for subscription billing"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about billing models (flat, usage-based, tiered), existing payment handling, which Stripe APIs to use, webhook handling, and how subscriptions map to the product's plans. Gathers context before writing."
+
+  # ── 9. Performance improvement request ──────────────────────────
+  - description: "performance: asks about current state and targets"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "The app is too slow, we need to speed it up"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about current performance metrics, which parts are slow, what the target is (specific latency, load time), and how performance is measured. Does not accept 'too slow' without quantification."
+
+  # ── 10. Migration/upgrade request ───────────────────────────────
+  - description: "migration: asks about current state and risk tolerance"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "We need to migrate from MongoDB to PostgreSQL"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about data volume, downtime tolerance, migration strategy (big bang vs incremental), which collections/schemas need migration, and current MongoDB usage patterns. Does not produce a PRD without understanding the scope of the migration."
+
+  # ── 11. Multi-turn: answers provided, expects PRD draft ─────────
+  - description: "multi-turn: produces structured PRD after context gathered"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: |
+        I want to add email notifications to our app.
+
+        You already asked questions and here are my answers:
+        - Users: both admins and regular users
+        - Triggers: account signup, password reset, weekly digest, payment receipt
+        - Preferences: users can opt out of digest but not transactional emails
+        - Technical: we use SendGrid, Node.js backend
+        - Scope: email only, no SMS or push for now
+        - Acceptance: emails delivered within 30 seconds, unsubscribe link in every email
+
+        Now write the PRD.
+    assert:
+      - type: llm-rubric
+        value: "Response produces a structured PRD with sections including Problem Statement, User Stories, Acceptance Criteria, and Non-Goals. User stories follow the 'As a [user], I want [action] so that [outcome]' format. Acceptance criteria are specific and testable (not vague like 'works well')."
+      - type: icontains
+        value: "User Stories"
+      - type: icontains
+        value: "Acceptance Criteria"
+
+  # ── 12. Feature with security implications ──────────────────────
+  - description: "security-sensitive: asks about auth and data protection"
+    vars:
+      system_prompt: file://commands/write-prd.md
+      user_message: "Add a file upload feature so users can attach documents to their profiles"
+    assert:
+      - type: llm-rubric
+        value: "Response asks about security considerations: file type restrictions, size limits, virus scanning, access control (who can see uploaded files), storage (local vs cloud), and data retention. Does not skip security concerns for a user-facing upload feature."
+      - type: not-icontains
+        value: "## Technical Design"

package/plugins/tt-core/skills/towles-tool/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: towles-tool
+description: Use towles-tool (`tt`) CLI for git helpers, journaling, and developer utilities. Use when asked about "tt commands", "create branch from issue", "daily notes", "meeting notes", or "check dependencies".
+---
+
+# towles-tool CLI
+
+Personal CLI toolkit. Alias: `tt`
+
+Config: `~/.config/towles-tool/towles-tool.settings.json`
+
+## Git
+
+```bash
+tt gh branch        # Create branch from GitHub issue
+tt gh pr            # Create pull request
+tt gh branch-clean  # Delete merged branches
+```
+
+## Journaling
+
+```bash
+tt journal daily-notes  # Weekly file, daily sections (alias: tt today)
+tt journal meeting      # Meeting notes (alias: tt m)
+tt journal note         # General notes (alias: tt n)
+```
+
+## Utilities
+
+```bash
+tt config   # Show config (alias: cfg)
+tt doctor   # Check dependencies
+tt graph    # Visualize dependency graph
+tt install  # Configure Claude Code settings
+```

package/src/cli.ts

@@ -1,7 +1,8 @@
 import { defineCommand } from "citty";
+import { version } from "../package.json";
 
 export const main = defineCommand({
-  meta: { name: "tt", description: "towles-tool — personal CLI utilities" },
+  meta: { name: "tt", version, description: "towles-tool — personal CLI utilities" },
   subCommands: {
     config: () => import("./commands/config.js").then((m) => m.default),
     doctor: () => import("./commands/doctor.js").then((m) => m.default),

package/src/commands/agentboard.ts

@@ -38,6 +38,14 @@ function ensureDeps(): void {
     process.exit(1);
   }
 
+  if (!existsSync(PLUGIN_DIR)) {
+    consola.error(`Agentboard plugin directory not found: ${PLUGIN_DIR}`);
+    consola.error(
+      "If installed globally, ensure the 'plugins' directory is included in the package.",
+    );
+    process.exit(1);
+  }
+
   const runtimeNodeModules = resolve(PLUGIN_DIR, "packages/runtime/node_modules");
   if (!existsSync(runtimeNodeModules)) {
     consola.info("Installing agentboard dependencies...");
@@ -308,7 +316,7 @@ function init(): void {
     );
   }
 
-  // Hooks (fallback for when server isn't running yet)
+  // Hooks — must match server's setupHooks() in provider.ts
   const hookPost = (path: string, body?: string) => {
     const bodyArg = body ? ` -d \\"${body}\\"` : "";
     return `run-shell -b "curl -s -X POST http://${host}:${port}${path}${bodyArg} >/dev/null 2>&1 || true"`;
@@ -317,8 +325,17 @@ function init(): void {
   const resizeBody =
     "#{q:pane_id}|#{q:session_name}|#{q:window_id}|#{q:pane_width}|#{q:window_width}";
 
-  tmux("set-hook", "-g", "client-session-changed", hookPost("/focus", focusBody));
+  tmux(
+    "set-hook",
+    "-g",
+    "client-session-changed",
+    `${hookPost("/focus", focusBody)} ; ${hookPost("/ensure-sidebar", focusBody)}`,
+  );
+  tmux("set-hook", "-g", "session-created", hookPost("/refresh"));
+  tmux("set-hook", "-g", "session-closed", hookPost("/refresh"));
+  tmux("set-hook", "-g", "client-resized", hookPost("/resize-sidebars"));
   tmux("set-hook", "-g", "after-select-window", hookPost("/ensure-sidebar", focusBody));
+  tmux("set-hook", "-g", "after-new-window", hookPost("/ensure-sidebar", focusBody));
   tmux("set-hook", "-g", "after-resize-pane", hookPost("/resize-sidebars", resizeBody));
 }