cc-dev-template 0.1.50 → 0.1.51

package/src/mcp-servers/qa-server/package.json

@@ -1,28 +0,0 @@
-{
-  "name": "qa-server",
-  "version": "1.0.0",
-  "description": "MCP server that spawns a QA sub-agent for frontend visual inspection",
-  "main": "dist/index.js",
-  "type": "module",
-  "bin": {
-    "qa-server": "./dist/index.js"
-  },
-  "scripts": {
-    "build": "tsc",
-    "start": "node dist/index.js",
-    "dev": "tsx src/index.ts"
-  },
-  "dependencies": {
-    "@anthropic-ai/claude-agent-sdk": "^0.1.30",
-    "@modelcontextprotocol/sdk": "^1.0.0",
-    "zod": "^3.24.1"
-  },
-  "devDependencies": {
-    "@types/node": "^20.0.0",
-    "tsx": "^4.7.0",
-    "typescript": "^5.3.0"
-  },
-  "engines": {
-    "node": ">=18.0.0"
-  }
-}

package/src/mcp-servers/qa-server/src/index.ts

@@ -1,220 +0,0 @@
-#!/usr/bin/env node
-/**
- * QA Server - MCP server that spawns a QA sub-agent for frontend visual inspection
- *
- * This server exposes a single `inspect_frontend` tool that:
- * 1. Takes a URL and task description
- * 2. Spawns a Claude sub-agent with Playwright MCP access
- * 3. The sub-agent navigates, screenshots, clicks, and inspects
- * 4. Returns a structured QA report
- *
- * Token savings: ~20k (26 browser tools) → ~500 (1 tool)
- */
-
-import { Server } from "@modelcontextprotocol/sdk/server/index.js";
-import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
-import {
-  CallToolRequestSchema,
-  ListToolsRequestSchema,
-} from "@modelcontextprotocol/sdk/types.js";
-import { query } from "@anthropic-ai/claude-agent-sdk";
-
-// QA Agent system prompt - follows ADR-002: explain WHY, positive framing, clear context
-const QA_SYSTEM_PROMPT = `You are a QA engineer helping developers verify their frontend works correctly.
-
-**Why this matters:** Catching visual bugs, console errors, and broken interactions early saves significant debugging time. Your detailed assessment helps developers ship with confidence.
-
-**Your capabilities:** You can navigate pages, take screenshots to see the visual state, click elements, fill forms, and read console messages. Screenshots show you exactly what users see.
-
-**What makes a great QA report:**
-- Visual Assessment: Describe the layout, colors, and overall appearance
-- Console Errors: List any errors found (or confirm none exist)
-- Task Result: What happened when you performed the requested task
-- Issues Found: Any problems discovered during inspection
-- Overall: PASS or FAIL with a clear reason
-
-Focus on what the developer needs to know: visual issues, broken functionality, and console errors. Be thorough in your inspection and clear in your reporting.`;
-
-// Create MCP server
-const server = new Server(
-  {
-    name: "qa-server",
-    version: "1.0.0",
-  },
-  {
-    capabilities: {
-      tools: {},
-    },
-  }
-);
-
-// List available tools
-server.setRequestHandler(ListToolsRequestSchema, async () => {
-  return {
-    tools: [
-      {
-        name: "inspect_frontend",
-        description:
-          "Spawn a QA sub-agent to visually inspect a frontend. The sub-agent can navigate, take screenshots, click elements, fill forms, and check console errors. Returns a structured QA report. Uses Opus for best visual understanding.",
-        inputSchema: {
-          type: "object",
-          properties: {
-            url: {
-              type: "string",
-              description: "URL to inspect (e.g., http://localhost:3000, https://example.com)",
-            },
-            task: {
-              type: "string",
-              description:
-                "What to inspect or test (e.g., 'Verify the login form works', 'Check for visual regressions on the homepage', 'Test the checkout flow')",
-            },
-          },
-          required: ["url", "task"],
-        },
-      },
-    ],
-  };
-});
-
-// Handle tool calls
-server.setRequestHandler(CallToolRequestSchema, async (request) => {
-  if (request.params.name !== "inspect_frontend") {
-    throw new Error(`Unknown tool: ${request.params.name}`);
-  }
-
-  const { url, task } = request.params.arguments as { url: string; task: string };
-
-  if (!url || !task) {
-    return {
-      content: [
-        {
-          type: "text",
-          text: "Error: Both 'url' and 'task' parameters are required",
-        },
-      ],
-      isError: true,
-    };
-  }
-
-  console.error(`[QA Server] Starting inspection of ${url}`);
-  console.error(`[QA Server] Task: ${task}`);
-
-  try {
-    // Build the task prompt - follows ADR-002: purpose-driven, positive framing
-    const taskPrompt = `
-**QA Inspection Request**
-
-URL: ${url}
-Task: ${task}
-
-**Context:** A developer needs verification that this frontend is working correctly. Your assessment helps them catch issues before users do.
-
-**Available tools:**
-- browser_navigate: Go to the URL
-- browser_take_screenshot: See the visual state (use this to understand what the page looks like)
-- browser_click: Click elements
-- browser_fill: Fill form fields
-- browser_get_text: Read page content
-- browser_wait_for: Wait for elements or conditions
-
-**Success criteria:** Provide a clear QA report covering visual state, console errors, task completion, and overall pass/fail assessment.
-`;
-
-    // Spawn sub-agent with Playwright MCP access
-    const result = query({
-      prompt: taskPrompt,
-      options: {
-        model: "claude-opus-4-5",
-        cwd: process.cwd(),
-        systemPrompt: QA_SYSTEM_PROMPT,
-        mcpServers: {
-          "playwright": {
-            command: "npx",
-            args: ["@playwright/mcp@latest", "--vision", "--headless"],
-          },
-        },
-        allowedTools: [
-          "mcp__playwright__browser_navigate",
-          "mcp__playwright__browser_click",
-          "mcp__playwright__browser_fill",
-          "mcp__playwright__browser_take_screenshot",
-          "mcp__playwright__browser_wait_for",
-          "mcp__playwright__browser_get_text",
-          "mcp__playwright__browser_hover",
-          "mcp__playwright__browser_press_key",
-          "mcp__playwright__browser_scroll",
-          "mcp__playwright__browser_get_url",
-        ],
-      },
-    });
-
-    // Collect the agent's final response
-    let report = "";
-    let totalCost = 0;
-
-    for await (const message of result) {
-      // Log progress to stderr (visible in server logs, not returned to client)
-      if (message.type === "system" && message.subtype === "init") {
-        console.error(`[QA Server] Agent initialized with tools: ${message.tools.length} tools`);
-      }
-
-      if (message.type === "assistant") {
-        // Extract text responses from assistant messages
-        const textBlocks = message.message.content.filter(
-          (c: any) => c.type === "text"
-        );
-        for (const block of textBlocks) {
-          report = block.text; // Keep latest text as the report
-        }
-
-        // Log tool calls
-        const toolCalls = message.message.content.filter(
-          (c: any) => c.type === "tool_use"
-        );
-        for (const tool of toolCalls) {
-          console.error(`[QA Server] Tool call: ${tool.name}`);
-        }
-      }
-
-      if (message.type === "result") {
-        totalCost = message.total_cost_usd;
-        console.error(`[QA Server] Completed. Cost: $${totalCost.toFixed(4)}`);
-      }
-    }
-
-    // Return the QA report
-    return {
-      content: [
-        {
-          type: "text",
-          text: report || "No report generated. The agent may have encountered an issue.",
-        },
-      ],
-    };
-  } catch (error) {
-    const errorMessage = error instanceof Error ? error.message : String(error);
-    console.error(`[QA Server] Error: ${errorMessage}`);
-
-    return {
-      content: [
-        {
-          type: "text",
-          text: `QA inspection failed: ${errorMessage}`,
-        },
-      ],
-      isError: true,
-    };
-  }
-});
-
-// Start the server
-async function main() {
-  const transport = new StdioServerTransport();
-  await server.connect(transport);
-  console.error("[QA Server] Started and ready for connections");
-}
-
-main().catch((error) => {
-  console.error("[QA Server] Fatal error:", error);
-  process.exit(1);
-});

package/src/mcp-servers/qa-server/tsconfig.json

@@ -1,17 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "outDir": "./dist",
-    "rootDir": "./src",
-    "strict": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "forceConsistentCasingInFileNames": true,
-    "declaration": true,
-    "resolveJsonModule": true
-  },
-  "include": ["src/**/*"],
-  "exclude": ["node_modules", "dist"]
-}

package/src/skills/spec-interview/references/interview-guide.md

@@ -1,123 +0,0 @@
-# Interview Guide
-
-## The Interview Flow
-
-This is a conversation, not a checklist march. But ensure all areas get covered naturally.
-
-### Opening
-
-Start with open-ended understanding:
-- "Tell me about this feature. What problem does it solve?"
-- "Who will use this? What's their goal?"
-- "Walk me through what success looks like."
-
-Let the user talk. Ask follow-ups on anything unclear.
-
-### Areas to Cover
-
-Cover these naturally through conversation. Don't force the order.
-
-**Intent & Goals**
-- What is the user trying to accomplish?
-- Why does this matter? What's the business/user value?
-- What does success look like? How will we know it's working?
-
-**Integration Points**
-- What existing parts of the system does this touch?
-- Are there external services, APIs, or libraries involved?
-- What data flows in and out?
-
-→ *Use subagents to investigate the current codebase when integration questions arise.*
-
-**Data Model**
-- What entities/objects are involved?
-- What are the relationships between them?
-- What constraints exist (required fields, validations, limits)?
-- Are we extending existing models or creating new ones?
-
-**Behavior & Flows**
-- What are the main user flows?
-- What triggers this feature? What happens step by step?
-- Are there different modes or variations?
-
-**Edge Cases & Error Handling**
-- What can go wrong?
-- What happens with invalid input?
-- What are the boundary conditions?
-- How do we handle partial failures?
-
-**Acceptance Criteria**
-- How do we verify this works?
-- What are the specific, testable requirements?
-- What would make this "done"?
-
-**Blockers & Dependencies**
-- What external dependencies exist? (APIs, services, libraries)
-- Are there credentials, API keys, or access needed?
-- Are there decisions that need to be made before implementation?
-- Is anything waiting on external input?
-
-### Research During Interview
-
-When you need to understand something about the current system, external libraries, or technical feasibility:
-
-- Use **Explore agents** to investigate the codebase or research external APIs/libraries
-- Use **Plan agents** to evaluate technical approaches or architectural decisions
-
-Keep the main interview context clean. Agents return only the relevant findings you need to continue the conversation.
-
-### Writing the Spec
-
-As you gather information, write to `docs/specs/<name>/spec.md`. Update it incrementally during the conversation.
-
-**Spec structure:**
-
-```markdown
-# [Feature Name]
-
-## Overview
-[2-3 sentences: what this is and why it matters]
-
-## Goals
-- [Primary goal]
-- [Secondary goals if any]
-
-## Integration Points
-[How this connects to existing system]
-- Touches: [existing components]
-- External: [APIs, services, libraries]
-- Data flows: [in/out]
-
-## Data Model
-[Entities, relationships, constraints]
-
-## Behavior
-### [Flow 1]
-[Step by step]
-
-### [Flow 2]
-[Step by step]
-
-## Edge Cases
-- [Edge case]: [how handled]
-
-## Acceptance Criteria
-- [ ] [Testable requirement]
-- [ ] [Testable requirement]
-
-## Blockers
-- [ ] [Blocker]: [what's needed]
-- [ ] [Decision needed]: [options]
-```
-
-### Completion Check
-
-When the spec seems complete, invoke the `spec-review` skill and specify which spec to review in the prompt. It analyzes the spec and returns feedback. If gaps are found, ask follow-up questions. Repeat until review passes.
-
-### Finalizing
-
-Once review passes:
-1. Confirm with user and show the final spec
-2. Ask if they want to proceed to task breakdown
-
-If yes, invoke the `spec-to-tasks` skill and specify which spec to break down.

package/src/skills/youtube-to-notes/SKILL.md

@@ -1,11 +0,0 @@
----
-name: youtube-to-notes
-description: This skill should be used when the user asks to "transcribe this YouTube video", "turn this video into notes", "get me notes from this YouTube talk", "summarize this YouTube video", "convert this video to markdown", or says "youtube to notes". Activate when the user wants to download, transcribe, and summarize a YouTube video into structured Markdown documents.
-argument-hint: "[url or search query]"
----
-
-# YouTube to Notes
-
-## What To Do Now
-
-Read `references/step-1-setup.md`.

package/src/skills/youtube-to-notes/references/step-1-setup.md

@@ -1,15 +0,0 @@
-# Setup
-
-Verify `yt-dlp` and `whisper` are installed.
-
-If either is missing, tell the user the exact install command (`brew install yt-dlp` or `brew install openai-whisper`) and stop.
-
-## Resolve the Video
-
-The user provides either a YouTube URL or a search query via `$ARGUMENTS`.
-
-**If it's a URL:** Store it and move on.
-
-**If it's a search query:** Use yt-dlp to search YouTube for the top 5 results. Display each result's title, channel, duration, and URL. Ask the user to pick one.
-
-Read `references/step-2-download-transcribe.md` when a video URL is confirmed.

package/src/skills/youtube-to-notes/references/step-2-download-transcribe.md

@@ -1,13 +0,0 @@
-# Download and Transcribe
-
-## Download Audio
-
-Use yt-dlp to extract audio as high-quality MP3 from the selected URL. Use the video title as the output filename.
-
-## Transcribe
-
-Run Whisper on the MP3 file using the `base` model. Output format: plain text, current directory.
-
-If the user requested higher accuracy, use `small` or `medium` instead — warn that these are significantly slower.
-
-Read `references/step-3-create-documents.md` when the `.txt` transcript file exists.

package/src/skills/youtube-to-notes/references/step-3-create-documents.md

@@ -1,31 +0,0 @@
-# Create Documents
-
-Read the raw `.txt` transcript from Whisper. Create two Markdown files in the current directory.
-
-## Transcript: `<video-title>-transcript.md`
-
-| Element | Instructions |
-|---------|-------------|
-| **YAML frontmatter** | `title`, `channel`, `url`, `date` (today), `duration` |
-| **Section headers** (`##`) | Insert where the topic shifts |
-| **Paragraphs** | Break at natural pause points into short, readable paragraphs |
-| **Speaker labels** | Label speakers in conversations when confident from context. Omit when unsure. |
-| **Code blocks** | Wrap any code mentioned in the video |
-| **Blockquotes** | Use for notable quotes |
-
-## Summary: `<video-title>-summary.md`
-
-| Section | Content |
-|---------|---------|
-| **YAML frontmatter** | Same fields as transcript, plus `type: summary` |
-| **Overview** | 2-3 sentence summary |
-| **Key Points** | 5-10 bullets of the most important ideas |
-| **Notable Quotes** | 3-5 direct quotes (include approximate timestamps if available from Whisper output) |
-| **Action Items / Takeaways** | Concrete recommendations or next steps from the video |
-| **Related Topics** | Keywords or topics for further research |
-
-## Cleanup
-
-Delete the intermediate `.mp3` and `.txt` files unless the user asked to keep them.
-
-Tell the user what files were created and their full paths.