specweave 1.0.261 → 1.0.262

package/plugins/specweave/skills/smart-reopen-detector/SKILL.md

@@ -1,245 +0,0 @@
----
-description: Detects issues with recently completed work and suggests reopening tasks/increments. Use for bugs, regressions, or problems with recently finished features.
-user-invocable: false
----
-
-# Smart Reopen Detector
-
-## Purpose
-
-When you report an issue with recently completed work, I'll automatically:
-1. 🔍 **Scan your recent work** (active + completed in last 7 days)
-2. 🎯 **Identify related items** using keyword matching
-3. 💡 **Suggest what to reopen** with relevance scoring
-4. ⚠️  **Check WIP limits** before suggesting reopen
-
-## When I Activate
-
-I automatically activate when you mention these keywords:
-- **Not working**: "not working", "broken", "failing", "error", "crash"
-- **Quality issues**: "bug", "issue", "problem", "wrong", "incorrect", "missing"
-- **Regressions**: "still broken", "regression", "broken again", "came back"
-
-## How I Help
-
-### Example 1: Issue Report
-```
-User: "The GitHub sync isn't working, it was just completed yesterday"
-```
-
-I'll respond with:
-```
-🔍 Scanning recent work...
-
-Found 2 related item(s) in recent work:
-
-📦 INCREMENT: 0031-external-tool-status-sync
-   Increment: 0031-external-tool-status-sync
-   Completed: 2 days ago
-   Relevance: 15 points
-   Matched: github, sync
-
-✓ TASK: T-003 GitHub Content Sync
-   Increment: 0031-external-tool-status-sync
-   Completed: 1 day ago
-   Relevance: 14 points
-   Matched: github, sync
-
-💡 Suggested action:
-   /sw:reopen 0031-external-tool-status-sync --reason "GitHub sync not working"
-
-Would you like me to:
-1. Reopen the entire increment (checks WIP limits)
-2. Reopen just task T-003 (targeted fix)
-3. Show me the WIP status first
-```
-
-### Example 2: Specific Feature Broken
-```
-User: "The authentication is broken after the recent deployment"
-```
-
-I'll respond with:
-```
-🔍 Scanning recent work...
-
-Found 3 related item(s) in recent work:
-
-✓ TASK: T-012 Authentication Service
-   Increment: 0025-user-auth
-   Completed: 3 days ago
-   Relevance: 10 points
-   Matched: authentication
-
-✓ TASK: T-014 JWT Token Validation
-   Increment: 0025-user-auth
-   Completed: 3 days ago
-   Relevance: 7 points
-   Matched: authentication
-
-💡 Suggested action:
-   /sw:reopen 0025-user-auth --task T-012 --reason "Authentication broken after deployment"
-
-⚠️  Note: Increment 0025 was completed 3 days ago. Consider checking deployment config first.
-```
-
-### Example 3: No Recent Work Found
-```
-User: "The payment flow is not working"
-```
-
-I'll respond with:
-```
-🔍 Scanning recent work...
-
-🔍 No related work found in recent activity (last 7 days)
-
-The payment functionality might be:
-1. From an older increment (>7 days ago)
-2. Not yet implemented
-3. Part of external dependencies
-
-Would you like me to:
-1. Search all increments (not just recent)
-2. Create a new bug increment for investigation
-3. Check the backlog for related work
-```
-
-## What I Do
-
-### Step 1: Extract Keywords
-From your message, I extract relevant keywords:
-- Feature names (authentication, github, payment)
-- Action words (sync, deploy, validate)
-- Component names (api, database, frontend)
-
-### Step 2: Scan Recent Work
-I scan:
-- ✅ **Active increments** (currently being worked on)
-- ✅ **Recently completed** (last 7 days)
-- ✅ **All tasks** from these increments
-
-### Step 3: Score Matches
-I assign relevance scores using:
-- **+10 points**: Exact match in title/ID
-- **+7 points**: Partial match in title
-- **+5 points**: Match in increment ID
-- **+3 points**: Match in description/AC
-
-### Step 4: Suggest Actions
-I provide:
-- Top matches (up to 5)
-- Relevance scores
-- Suggested `/sw:reopen` command
-- WIP limit warnings (if applicable)
-
-## Smart Suggestions
-
-### For Increments
-```bash
-# Reopen entire increment
-/sw:reopen 0031-external-tool-status-sync --reason "GitHub sync failing"
-
-# Check WIP limits first (recommended)
-/sw:status
-```
-
-### For Specific Tasks
-```bash
-# Reopen single task (surgical fix)
-/sw:reopen 0031 --task T-003 --reason "GitHub API 500 error"
-
-# Reopen multiple related tasks
-/sw:reopen 0031 --user-story US-001 --reason "All GitHub features broken"
-```
-
-### Force Reopen (Bypass WIP Limits)
-```bash
-# Use --force for critical production issues
-/sw:reopen 0031 --force --reason "Production down, critical fix needed"
-```
-
-## WIP Limit Awareness
-
-Before suggesting increment reopen, I check:
-- ✅ Current active increment count
-- ✅ Type-specific limits (feature: 2, refactor: 1, etc.)
-- ⚠️  Warn if reopening will exceed limits
-
-**Example Warning**:
-```
-⚠️  WIP LIMIT WARNING:
-   Current active: 2 features
-   Limit: 2 features
-   Reopening 0031-external-tool-status-sync will EXCEED the limit!
-
-   Options:
-   1. Pause another feature first: /sw:pause 0030
-   2. Complete another feature: /sw:done 0029
-   3. Force reopen (not recommended): --force
-```
-
-## Integration with Commands
-
-I work seamlessly with:
-- `/sw:reopen` - Execute reopen action
-- `/sw:status` - Check WIP limits
-- `/sw:progress` - See increment progress
-- `/sw:pause` - Pause another increment to make room
-
-## When NOT to Use
-
-I don't activate for:
-- ❌ General questions about code
-- ❌ Feature requests (use `/sw:increment`)
-- ❌ Documentation questions
-- ❌ Status inquiries (use `/sw:status`)
-
-I **only** activate when you explicitly report something is broken/not working.
-
-## Technical Implementation
-
-**Core Logic**:
-- Uses `RecentWorkScanner` to find matches
-- Keyword extraction from user message
-- Relevance scoring algorithm
-- WIP limit validation before suggestions
-
-**Smart Features**:
-- Deduplication (same increment from active + recent)
-- Recency bias (prefer more recent completions)
-- Contextual hints (deployment, config, dependencies)
-
-## Examples of Activation
-
-### ✅ Will Activate
-- "GitHub sync not working"
-- "Authentication is broken"
-- "Tests are failing after the last commit"
-- "Deployment crashed"
-- "API returns 500 error"
-- "Still broken after the fix"
-
-### ❌ Won't Activate
-- "How does GitHub sync work?"
-- "Can you add authentication?"
-- "What's the status of increment 0031?"
-- "Show me the progress"
-- "Create a new feature for payments"
-
-## Success Metrics
-
-I'm successful when:
-- ✅ You find the related work quickly (<30 seconds)
-- ✅ The suggested reopen command is correct
-- ✅ No false positives (only relevant matches)
-- ✅ WIP limits are respected
-- ✅ Clear next steps provided
-
----
-
-**Auto-loads when**: You report issues with recently completed work
-**Commands**: `/sw:reopen`, `/sw:status`
-**Related Skills**: `increment-planner`, `tdd-workflow`
-
-

package/plugins/specweave/skills/tdd-orchestrator/SKILL.md

@@ -1,228 +0,0 @@
----
-description: TDD orchestrator for red-green-refactor discipline and multi-agent test-driven workflows. Use for TDD enforcement, writing tests first, test isolation, quality gates.
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
-user-invocable: false
----
-
-# TDD Orchestrator Skill
-
-## Project Overrides
-
-!`s="tdd-orchestrator"; for d in .specweave/skill-memories .claude/skill-memories "$HOME/.claude/skill-memories"; do p="$d/$s.md"; [ -f "$p" ] && awk '/^## Learnings$/{ok=1;next}/^## /{ok=0}ok' "$p" && break; done 2>/dev/null; true`
-
-## Overview
-
-You are an expert TDD orchestrator specializing in comprehensive test-driven development coordination, modern TDD practices, and multi-agent workflow management. This skill also serves as the TDD discovery hub - detecting TDD intent and routing to appropriate commands.
-
-## When to Activate
-
-**Automatic activation when user mentions**:
-- "implement with TDD"
-- "use test-driven development"
-- "red-green-refactor"
-- "write tests first"
-- "test-first approach"
-- "Kent Beck style"
-- "TDD discipline"
-
-## Core Principles
-
-1. **ONE TDD phase per response** - Red, Green, OR Refactor
-2. **Test-first discipline** - Always write failing tests first
-3. **Minimal implementation** - Just enough to pass tests
-
-## Quick Reference
-
-### TDD Phases
-
-| Phase | What | Token Budget |
-|-------|------|--------------|
-| Red | Create failing tests | < 600 tokens |
-| Green | Minimal implementation | < 600 tokens |
-| Refactor | Clean up (tests green) | < 600 tokens |
-
-### TDD Styles
-
-- **Classic TDD (Chicago)**: State-based testing, real collaborators
-- **London School (Mockist)**: Interaction-based, test doubles
-
-### Red Phase Guidelines 🔴
-
-- Write test FIRST (should fail)
-- Ensure test fails for the right reason
-- Write the simplest test that fails
-- Test should compile but fail on assertion
-- Focus on WHAT, not HOW
-- One test at a time
-- Max 10-15 tests per response
-- Ask before moving to Green Phase
-
-### Green Phase Guidelines 🟢
-
-- Write MINIMAL code to pass tests
-- Embrace "fake it till you make it"
-- Hardcoded values acceptable initially
-- Get to green FAST
-- One implementation file per response
-- Verify tests pass before continuing
-- Ask before moving to Refactor Phase
-
-### Refactor Phase Guidelines 🔵
-
-- Refactor while keeping tests green
-- Improve code structure
-- Extract methods, remove duplication
-- One refactoring pass per response
-- Commit after each refactor
-- Ask before starting new cycle
-
-### TDD Anti-Patterns to Avoid
-
-- ❌ Writing implementation before test
-- ❌ Writing multiple tests before implementation
-- ❌ Over-engineering in GREEN phase
-- ❌ Refactoring without tests passing
-- ❌ Skipping refactor phase
-
-## Workflow
-
-1. **Analysis** (< 500 tokens): List TDD phases needed, ask which first
-2. **Execute ONE phase** (< 600 tokens): Red, Green, or Refactor
-3. **Report progress**: "Phase complete. Ready for next?"
-4. **Repeat**: One phase at a time
-
-## Token Budget
-
-- **Analysis**: 300-500 tokens
-- **Red Phase**: 400-600 tokens (2-3 test files max)
-- **Green Phase**: 400-600 tokens (1-2 impl files)
-- **Refactor Phase**: 400-600 tokens
-
-**NEVER exceed 2000 tokens per response!**
-
-## TDD Workflow Example
-
-```
-1. 📝 Red: Write failing tests
-2. ❌ Run tests: 0/N passing
-3. ✅ Green: Implement feature
-4. 🟢 Run tests: N/N passing
-5. ♻️ Refactor: Clean up
-6. 🟢 Run tests: Still passing
-```
-
-## Integration with SpecWeave
-
-**In Increment Workflow**:
-```
-/sw:inc "Authentication feature" → spec.md created
-↓
-User: "Implement with TDD"
-↓
-tdd-orchestrator skill activates
-↓
-/sw:tdd:cycle invoked
-  ↓
-  Phase 1: RED   - tests.md updated with failing tests
-  Phase 2: GREEN - tasks.md implementation
-  Phase 3: REFACTOR - code improvements
-↓
-Increment tasks completed with TDD discipline
-```
-
-## Commands Reference
-
-### Full Cycle
-- `/sw:tdd:cycle` - Complete red-green-refactor orchestration
-
-### Individual Phases
-- `/sw:tdd:red` - RED phase only (write failing test)
-- `/sw:tdd:green` - GREEN phase only (make test pass)
-- `/sw:tdd:refactor` - REFACTOR phase only (improve code)
-
-### When to Use Each
-
-**Use /sw:tdd:cycle when**:
-- ✅ Starting new feature from scratch
-- ✅ Learning TDD or teaching team
-- ✅ Want enforced discipline (gates)
-- ✅ Working in increment-based workflow
-
-**Use individual commands when**:
-- ✅ Already in middle of TDD cycle
-- ✅ Need to repeat a phase (e.g., multiple refactors)
-- ✅ Want finer control over cycle
-- ✅ Integrating with other workflows
-
-## CLI/Hook Integration Testing
-
-When TDD targets CLI commands, hooks, or terminal tools, apply these patterns:
-
-### Test Isolation Stack
-
-| Layer | Helper | Purpose |
-|-------|--------|---------|
-| Home dir | `withIsolatedHome()` | Override HOME to temp dir |
-| Working dir | `createIsolatedTestDir()` | Isolated .specweave/ structure |
-| Env vars | `getIsolatedEnv()` | Strip NODE_OPTIONS, set HOME |
-| Output | `normalizeOutput()` | Strip ANSI, normalize endings |
-| JSON parsing | `extractJson()` | Extract JSON from mixed stdout |
-
-### TDD for CLI: Red Phase
-```typescript
-// RED: Write test that spawns CLI process
-it('should init project in isolated dir', async () => {
-  const { homePath, restore } = await withIsolatedHome('init-test');
-  try {
-    const result = await execAsync('node bin/specweave.js init', {
-      cwd: workDir,
-      env: getIsolatedEnv(homePath, { CI: 'true' }),
-      timeout: 30000,
-    });
-    expect(normalizeOutput(result.stdout)).toContain('initialized');
-  } finally {
-    await restore();
-  }
-});
-```
-
-### TDD for Hooks: Red Phase
-```typescript
-// RED: Write test that executes real hook
-it('should approve when no increment active', async () => {
-  const harness = new HookTestHarness(testDir, hookPath);
-  const result = await harness.execute({ CI: 'true' });
-  const json = extractJson<{ decision: string }>(result.stdout);
-  expect(json?.decision).toBe('approve');
-});
-```
-
-### Key Rules for CLI TDD
-- Use 30s timeout for CLI tests (not default 5s)
-- Always use `getCleanEnv()` or `getIsolatedEnv()` for child processes
-- Never test hooks by string-matching file contents - EXECUTE them
-- Separate CLI tests into `vitest.e2e.config.ts` with fewer workers
-- Run `npm run test:e2e:cli` for CLI-specific tests
-
-## Configuration
-
-**Optional**: Customize TDD preferences in `.specweave/config.yaml`:
-
-```yaml
-tdd:
-  default_workflow: "cycle"  # Options: "cycle", "agent", "manual"
-  auto_activate: true         # Auto-offer TDD on new features
-  gates_enabled: true         # Enforce phase gates in cycle mode
-  mutation_testing: false     # Enable mutation testing (requires setup)
-```
-
-## Related Skills & Commands
-
-**Commands**:
-- `/sw:tdd:cycle` - Full red-green-refactor orchestration
-- `/sw:tdd:red`, `/sw:tdd:green`, `/sw:tdd:refactor` - Individual phases
-
-**Skills**:
-- `sw-testing:qa-engineer` - Test strategy overlaps with TDD principles
-
-