cc-dev-template 0.1.49 → 0.1.51

package/bin/install.js

@@ -255,6 +255,32 @@ if (fs.existsSync(mergeSettingsPath)) {
 console.log('\nCleanup:');
 let cleanupPerformed = false;
 
+// Remove deprecated skills
+const deprecatedSkills = ['youtube-to-notes'];
+deprecatedSkills.forEach(skill => {
+  const skillPath = path.join(CLAUDE_DIR, 'skills', skill);
+  if (fs.existsSync(skillPath)) {
+    fs.rmSync(skillPath, { recursive: true });
+    console.log(`✓ Removed deprecated skill: ${skill}`);
+    cleanupPerformed = true;
+  }
+});
+
+// Remove deprecated MCP servers
+const deprecatedMcpServers = ['qa-server'];
+deprecatedMcpServers.forEach(server => {
+  const serverPath = path.join(CLAUDE_DIR, 'mcp-servers', server);
+  if (fs.existsSync(serverPath)) {
+    fs.rmSync(serverPath, { recursive: true });
+    // Unregister from Claude Code
+    try {
+      execSync(`claude mcp remove ${server} 2>/dev/null || true`, { stdio: 'pipe' });
+    } catch (e) {}
+    console.log(`✓ Removed deprecated MCP server: ${server}`);
+    cleanupPerformed = true;
+  }
+});
+
 // Remove deprecated bash wrapper files
 const deprecatedFiles = [
   path.join(CLAUDE_DIR, 'hooks', 'bash-precheck.sh'),
@@ -341,13 +367,11 @@ These settings are available globally across all your projects.
 Commands:
   /prime - Start a session (orientation, scaffolding for new projects)
   /done  - End a session (sync docs, commit work)
-
-MCP Server Notes:
-  - qa-server: Spawns a sub-agent for frontend visual inspection
-    Saves ~20k tokens by offloading browser tools to sub-agent
-    If you have chrome-devtools MCP installed, consider removing it:
-    claude mcp remove chrome-devtools
 `);
 }
 
+console.log(`Note: This installer contains no API keys, credentials, or private data.
+It's safe to share and anyone can run it.
+`);
+
 console.log('Restart Claude Code to pick up changes.');

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-dev-template",
-  "version": "0.1.49",
+  "version": "0.1.51",
   "description": "Structured AI-assisted development framework for Claude Code",
   "bin": {
     "cc-dev-template": "./bin/install.js"

package/src/skills/claude-md/SKILL.md

@@ -1,19 +1,12 @@
 ---
 name: claude-md
-description: This skill should be used when working with CLAUDE.md files. Activate when the user asks to "audit CLAUDE.md", "create a CLAUDE.md", "update the CLAUDE.md", "clean up CLAUDE.md files", or "check CLAUDE.md best practices". Also activate proactively whenever about to create or modify any CLAUDE.md file - the skill contains required principles for how these files should be written.
+description: Manages CLAUDE.md files - the orientation prompts that help Claude understand codebases. Activates for auditing, creating, updating, or cleaning up CLAUDE.md files. Also activates before modifying any CLAUDE.md file to ensure best practices are followed.
 ---
 
 # CLAUDE.md Management
 
 Base directory for this skill: ~/.claude/skills/claude-md
 
-## When This Activates
-
-- User asks to audit, create, update, or clean up CLAUDE.md files
-- You are about to create or modify any CLAUDE.md file
-
-**If you're about to touch a CLAUDE.md file, read this skill first.**
-
 ## What To Do
 
 Determine the task:

package/src/skills/claude-md/references/audit.md

@@ -9,16 +9,7 @@
 
 ## Step 1: Discover
 
-Find all CLAUDE.md files:
-
-```bash
-find . -name "CLAUDE.md" -type f | head -20
-```
-
-Or use Glob:
-```
-**/CLAUDE.md
-```
+Find all CLAUDE.md files using Glob pattern `**/CLAUDE.md`.
 
 ## Step 2: Map Hierarchy
 

package/src/skills/claude-md/references/create.md

@@ -6,11 +6,11 @@
 2. **Read them** - Understand what's already covered
 3. **Identify the gap** - What does this folder need that parents don't provide?
 
-If the parent files already cover everything, you probably don't need a new CLAUDE.md.
+Skip creating a new CLAUDE.md if parent files already cover everything needed.
 
 ## Structure Template
 
-Use this as a starting point, not a rigid template. Include only sections that add value.
+Starting template. Include only sections that add value.
 
 ```markdown
 # [Folder/Project Name]

package/src/skills/initialize-project/SKILL.md

@@ -1,84 +1,33 @@
 ---
 name: initialize-project
-description: Scaffold docs structure for Claude Code sessions. Use when starting a new project or when docs/CURRENT_WORK.md is missing.
+description: Scaffold docs structure for Claude Code sessions. Use when starting a new project, when "docs/CURRENT_WORK.md is missing", or when user says "initialize this project" or "set up session tracking".
 ---
 
 # Initialize Project
 
-Set up the documentation structure for Claude Code session tracking.
+Ask the user:
+- "What is this project? (1-2 sentences)"
+- "Primary language/framework?" (optional)
 
-## Purpose
+## Create the Docs Structure
 
-Create the minimal scaffolding that enables the `/prime` and `/done` workflow. This gives Claude context about project status across sessions without heavy tooling.
+Create `docs/INDEX.md` using `templates/INDEX.md.template`. Replace `{{PROJECT_NAME}}` with the project name.
 
-## What To Do
+Create `docs/CURRENT_WORK.md` using `templates/CURRENT_WORK.md.template`.
 
-1. **Announce:** "Setting up project for Claude Code session tracking..."
+## Handle CLAUDE.md
 
-2. **Gather context** - ask the user:
-   - "What is this project? (1-2 sentences)"
-   - "Primary language/framework?" (optional, for CLAUDE.md context)
+Check if CLAUDE.md exists and has content.
 
-3. **Create the docs structure:**
+**If missing or empty:** Create using `templates/CLAUDE.md.template`. Replace placeholders with user's answers.
 
-   Create `docs/INDEX.md`:
-   ```markdown
-   # [Project Name] Documentation
+**If exists with content:** Leave unchanged.
 
-   ## Quick Links
-   - [Current Work](CURRENT_WORK.md) - Active tasks and project status
+## Confirm Completion
 
-   ## Documentation
-   Add links to documentation as the project grows.
-   ```
+Report what was created:
+- `docs/INDEX.md` - documentation hub
+- `docs/CURRENT_WORK.md` - status tracking
+- `CLAUDE.md` - created or unchanged
 
-   Create `docs/CURRENT_WORK.md`:
-   ```markdown
-   # Current Work
-
-   ## In Progress
-   - (none)
-
-   ## Up Next
-   - (add your first task)
-
-   ## Blocked / Waiting
-   - (none)
-
-   ## Open Questions
-   - (none)
-   ```
-
-4. **Handle CLAUDE.md:**
-
-   Check if CLAUDE.md exists and has content.
-
-   **If missing or empty**, create a minimal starter:
-   ```markdown
-   # [Project Name]
-
-   [User's project description from step 2]
-
-   ## Tech Stack
-   [Language/framework from step 2, if provided]
-
-   ## Structure
-   - `docs/` - Documentation and status tracking
-   - `docs/CURRENT_WORK.md` - What's in progress and up next
-   ```
-
-   **If CLAUDE.md exists with content**, leave it alone - the user has already configured it.
-
-5. **Confirm completion:**
-   "Project initialized with:
-   - `docs/INDEX.md` - documentation hub
-   - `docs/CURRENT_WORK.md` - status tracking
-   - `CLAUDE.md` - [created/unchanged]
-
-   Run `/prime` to start your session."
-
-## Success Criteria
-
-- `docs/` directory exists with INDEX.md and CURRENT_WORK.md
-- CLAUDE.md exists (created if missing, preserved if present)
-- User understands the `/prime` → work → `/done` workflow
+End with: "Run `/prime` to start a session."

package/src/skills/initialize-project/templates/CLAUDE.md.template

@@ -0,0 +1,10 @@
+# {{PROJECT_NAME}}
+
+{{PROJECT_DESCRIPTION}}
+
+## Tech Stack
+{{TECH_STACK}}
+
+## Structure
+- `docs/` - Documentation and status tracking
+- `docs/CURRENT_WORK.md` - What's in progress and up next

package/src/skills/initialize-project/templates/CURRENT_WORK.md.template

@@ -0,0 +1,13 @@
+# Current Work
+
+## In Progress
+- (none)
+
+## Up Next
+- (add your first task)
+
+## Blocked / Waiting
+- (none)
+
+## Open Questions
+- (none)

package/src/skills/initialize-project/templates/INDEX.md.template

@@ -0,0 +1,7 @@
+# {{PROJECT_NAME}} Documentation
+
+## Quick Links
+- [Current Work](CURRENT_WORK.md) - Active tasks and project status
+
+## Documentation
+Add links to documentation as the project grows.

package/src/skills/prompting/SKILL.md

@@ -1,123 +1,16 @@
 ---
 name: prompting
-description: Best practices for creating effective Claude prompts. Use when creating, reviewing, or modifying prompts for agents or commands.
+description: Invoked when user says "review my prompt", "help me write a prompt", "improve this prompt", or "create a prompt for...". Guides prompt creation and improvement using Claude 4.x best practices.
 ---
 
-# Prompting Skill
+# Prompting
 
-Actionable guidance for crafting effective prompts for Claude 4.x models. Apply these principles when creating or reviewing agent prompts, command specifications, or any structured Claude interactions.
+## Determine Intent
 
-## Core Principles
+| User Intent | Action |
+|-------------|--------|
+| Has an existing prompt to review or improve | Read `references/review.md` |
+| Needs to create a new prompt from scratch | Read `references/create.md` |
+| Unclear | Ask: "Do you have an existing prompt to improve, or are you creating one from scratch?" |
 
-Apply in order of importance:
-
-### 1. Explain WHY, Not Just WHAT (Most Important)
-
-Provide purpose and context rather than exhaustive implementation details. Trust Claude's intelligence.
-
-**Mental Model**: Treat Claude like a brilliant senior colleague, not a junior who needs hand-holding.
-
-**Provide**:
-- The goal or purpose of the task
-- Why this matters (business context, use case)
-- Constraints that exist (technical, business, regulatory)
-- What success looks like
-
-**Avoid providing**:
-- Every possible edge case
-- Step-by-step implementation unless genuinely needed
-- Obvious best practices for the domain
-
-### 2. Use Positive Framing
-
-Tell Claude what TO do, not what NOT to do. Negatives require extra processing and can prime unwanted behavior.
-
-| Negative Framing | Positive Framing |
-|------------------|------------------|
-| "Don't hallucinate facts" | "Only use information from the provided documents" |
-| "Don't be too formal" | "Write in a conversational, friendly tone" |
-| "Avoid long paragraphs" | "Keep paragraphs to 3-4 sentences" |
-| "Don't skip error handling" | "Include comprehensive error handling" |
-| "Don't make it complicated" | "Keep the solution simple and maintainable" |
-| "Avoid making assumptions" | "Base responses on the provided data" |
-
-### 3. Be Clear and Direct
-
-Claude 4.x models are more literal than previous versions. State exactly what you want without hedging.
-
-| Vague | Clear |
-|-------|-------|
-| "Can you maybe help me think about..." | "Redesign the authentication flow to support SSO" |
-| "It might be nice to have..." | "Add rate limiting to the login endpoint" |
-| "Create a dashboard" | "Create a fully-featured dashboard with charts, filters, export, and user preferences" |
-
-### 4. Provide Context
-
-Answer these questions:
-1. **Why does this matter?** (Purpose, goal, business context)
-2. **Who is this for?** (Audience, user type, skill level)
-3. **What does success look like?** (Outcomes, metrics, acceptance criteria)
-4. **What constraints exist?** (Technical limits, requirements, policies)
-
-## The Complete Framework Checklist
-
-Every good prompt should answer:
-
-- [ ] **WHAT** are you asking Claude to do?
-- [ ] **WHY** does this matter? (Purpose, goal)
-- [ ] **WHO** is this for? (Audience, user type)
-- [ ] **SUCCESS** looks like what?
-- [ ] Frame everything **POSITIVELY** (what TO do, not what NOT to do)
-
-Then trust Claude to:
-- Handle edge cases intelligently
-- Apply best practices for the domain
-- Make reasonable implementation choices
-- Ask clarifying questions if truly ambiguous
-
-## Quick Diagnostics
-
-When Claude's response is problematic:
-
-| Problem | Likely Cause | Fix |
-|---------|--------------|-----|
-| Too minimal/basic | Not explicit about expectations | Add "Create a fully-featured..." or "Go beyond basics..." |
-| Off-topic | Missing context about purpose | Explain WHY you need this and what it's for |
-| Inconsistent | Vague or ambiguous instructions | Be more direct and specific about requirements |
-| Overly cautious | Negative framing ("don't do X") | Reframe positively ("do Y instead") |
-| Missing key details | Didn't explain what success looks like | Define concrete success criteria |
-
-## Common Antipatterns
-
-### The Micromanager
-Providing step-by-step implementation instead of goals.
-
-**Fix**: Explain the goal, let Claude handle implementation.
-
-### The Negative Nancy
-String of "don't do X" instructions.
-
-**Fix**: Reframe every negative as a positive instruction.
-
-### The Context-Free Zone
-Bare instruction with no purpose or audience.
-
-**Fix**: Explain who will use it, why it exists, what success looks like.
-
-### The Vague Suggestion
-Hedged language like "maybe we could possibly..."
-
-**Fix**: Be direct and explicit about what you want.
-
-## Structural Elements
-
-For multi-step tasks where order matters, use numbered lists.
-
-For complex prompts with distinct sections, consider XML-style tags:
-- `<instructions>`, `<context>`, `<data>`
-- `<examples>`, `<input>`, `<output>`
-- `<requirements>`, `<constraints>`
-
-## ADR Compliance
-
-This skill implements the practices mandated by ADR-002 (Structured Prompting Practices for Agents and Commands). All agents and commands in this framework must follow these principles.
+Route to the appropriate path before proceeding.

package/src/skills/prompting/references/create.md

@@ -0,0 +1,59 @@
+# Create a New Prompt
+
+## Step 1: Gather Requirements
+
+Ask the user these questions (skip any already answered):
+
+1. **What should Claude do?** (The core task)
+2. **Why does this matter?** (Purpose, business context)
+3. **Who will use the output?** (Audience)
+4. **What does success look like?** (Concrete outcomes)
+5. **What constraints exist?** (Technical limits, policies, format requirements)
+
+## Step 2: Draft the Prompt
+
+Structure the prompt with these elements:
+
+### Opening: Task and Purpose
+State the task directly in imperative form. Include why it matters.
+
+```
+[Task in imperative form]. This [purpose/context].
+```
+
+### Context Section (if needed)
+For complex tasks, add structured context:
+
+```
+<context>
+- Audience: [who]
+- Constraints: [limits]
+- Success criteria: [outcomes]
+</context>
+```
+
+### Requirements (if specific)
+List concrete requirements as bullet points. Keep to essentials only.
+
+### Output Format (if specific)
+Specify format only when it genuinely matters. Otherwise trust Claude's judgment.
+
+## Step 3: Self-Review
+
+Before presenting, verify:
+
+- [ ] All instructions use positive framing (what TO do)
+- [ ] Language is direct, no hedging
+- [ ] Purpose and context are clear
+- [ ] No over-specification of obvious practices
+- [ ] Success criteria are concrete
+
+Read `references/principles.md` if any check fails and apply the relevant fix.
+
+## Step 4: Present and Iterate
+
+Present the draft prompt to the user.
+
+Ask: "Does this capture what you need? Any adjustments?"
+
+Incorporate feedback until the user is satisfied.

package/src/skills/prompting/references/principles.md

@@ -0,0 +1,60 @@
+# Prompting Principles Reference
+
+Load this file when diagnosing issues or applying fixes during review/creation.
+
+## Principle 1: Positive Framing
+
+State what TO do, not what NOT to do.
+
+| Negative | Positive |
+|----------|----------|
+| "Don't hallucinate facts" | "Only use information from provided documents" |
+| "Don't be too formal" | "Write in a conversational tone" |
+| "Avoid long paragraphs" | "Keep paragraphs to 3-4 sentences" |
+| "Don't skip error handling" | "Include comprehensive error handling" |
+| "Avoid assumptions" | "Base responses on provided data" |
+
+## Principle 2: Direct Language
+
+State exactly what is needed. Remove hedging.
+
+| Vague | Direct |
+|-------|--------|
+| "Can you maybe help me think about..." | "Redesign the authentication flow to support SSO" |
+| "It might be nice to have..." | "Add rate limiting to the login endpoint" |
+| "Consider adding..." | "Add..." |
+| "Try to keep it simple" | "Keep the solution simple" |
+
+## Principle 3: Context Over Micromanagement
+
+Provide goals and constraints. Trust Claude to handle implementation.
+
+**Include:**
+- Purpose and business context
+- Who will use the output
+- What success looks like
+- Constraints that apply
+
+**Omit:**
+- Step-by-step implementation for common tasks
+- Edge cases Claude would handle naturally
+- Domain best practices Claude already knows
+
+## Principle 4: Structural Elements
+
+For multi-step tasks: use numbered lists.
+
+For complex prompts with distinct sections: use XML-style tags.
+- `<instructions>`, `<context>`, `<data>`
+- `<examples>`, `<input>`, `<output>`
+- `<requirements>`, `<constraints>`
+
+## Quick Diagnostics
+
+| Problem in Output | Likely Cause | Fix |
+|-------------------|--------------|-----|
+| Too minimal | Expectations unclear | Add "Create a fully-featured..." or specify scope |
+| Off-topic | Missing purpose | Explain WHY and what it's for |
+| Inconsistent | Vague instructions | Be more specific about requirements |
+| Overly cautious | Negative framing | Reframe positively |
+| Missing details | No success criteria | Define concrete outcomes |

package/src/skills/prompting/references/review.md

@@ -0,0 +1,78 @@
+# Review an Existing Prompt
+
+## Step 1: Get the Prompt
+
+Request the prompt from the user if not already provided.
+
+## Step 2: Analyze Against Principles
+
+Evaluate the prompt against each criterion. For each issue found, note the specific text and the fix.
+
+### Positive Framing Check
+
+Find any negative instructions:
+- "Don't...", "Never...", "Avoid..."
+- "Do not...", "Should not..."
+
+For each, draft a positive reframe.
+
+| Negative | Positive Reframe |
+|----------|------------------|
+| "Don't hallucinate" | "Only use information from provided documents" |
+| "Don't be verbose" | "Keep responses concise" |
+| "Avoid jargon" | "Use plain language" |
+
+### Clarity Check
+
+Find vague or hedging language:
+- "Maybe...", "Perhaps...", "Consider..."
+- "It would be nice if...", "Try to..."
+- "Can you help me think about..."
+
+For each, draft a direct replacement.
+
+### Context Check
+
+Identify what's missing:
+- **Purpose**: Why does this task matter?
+- **Audience**: Who will use the output?
+- **Success criteria**: What does a good result look like?
+- **Constraints**: What limits apply?
+
+### Over-specification Check
+
+Find unnecessary details:
+- Step-by-step instructions for common tasks
+- Obvious best practices spelled out
+- Edge cases that Claude would handle naturally
+
+These can be removed or condensed to goals.
+
+## Step 3: Present Findings
+
+Format the review as:
+
+```
+## Prompt Review
+
+### Issues Found
+
+1. **[Issue type]** at "[quoted text]"
+   - Problem: [why this is problematic]
+   - Fix: [specific replacement text]
+
+2. ...
+
+### Improved Version
+
+[Full rewritten prompt with all fixes applied]
+
+### Summary of Changes
+- [Bullet list of what changed and why]
+```
+
+## Step 4: Offer Iteration
+
+Ask: "Would you like me to adjust anything in the improved version?"
+
+Incorporate feedback and present updated version until the user is satisfied.

package/src/skills/spec-interview/SKILL.md

@@ -1,37 +1,15 @@
 ---
 name: spec-interview
-description: This skill helps create thorough feature specifications through conversation. Use when the user says "spec out a feature", "create a specification", "design a feature", "I need to plan a feature", or wants to document requirements before building.
+description: Conducts a conversational interview to produce implementation-ready feature specifications. Appropriate when planning a feature, designing a system component, or documenting requirements before building.
 argument-hint: <spec-name>
 ---
 
 # Spec Interview
 
-Guide the user through creating a complete feature specification via structured conversation.
-
 ## What To Do Now
 
-1. **Ask what feature they want to spec out** using AskUserQuestion
-2. **Create the spec directory** at `docs/specs/<feature-name>/`
-3. **Begin the interview** - read `references/interview-guide.md`
-
-## Key Principles
-
-**Interviewer, not form.** Have a natural conversation. Ask follow-up questions. Dig into details that seem unclear.
-
-**Subagents for research.** Offload exploration and research to subagents to keep the main interview context clean. They return only relevant findings.
-
-**One or two questions at a time.** Use AskUserQuestion liberally. This is a conversation, not an interrogation.
-
-**Implementation-ready output.** The finished spec should enable hands-off implementation with zero clarification needed.
-
-## Spec Location
-
-Specs live at: `docs/specs/<feature-name>/spec.md`
-
-The feature name is derived from the user's description (kebab-case, concise).
-
-## When You Think the Spec is Complete
+If an argument was provided, use it as the feature name. Otherwise, ask what feature to spec out.
 
-Before finalizing, invoke the `spec-review` skill to check for gaps. It will return specific feedback. If gaps exist, ask follow-up questions to address them.
+Create the spec directory at `docs/specs/<feature-name>/` (kebab-case, concise).
 
-Only finalize when review passes.
+Read `references/step-1-opening.md` to begin the interview.

package/src/skills/spec-interview/references/step-1-opening.md

@@ -0,0 +1,21 @@
+# Step 1: Opening
+
+Establish understanding of the feature before diving into details.
+
+## Opening Questions
+
+Ask one or two questions at a time. Follow up on anything unclear.
+
+Start with:
+- What problem does this feature solve?
+- Who uses it and what is their goal?
+
+Then explore:
+- What does success look like?
+- Are there existing solutions or workarounds?
+
+## When to Move On
+
+Move to `references/step-2-deep-dive.md` when:
+- The core problem and user goal are clear
+- Success criteria are understood at a high level