specweave 1.0.443 → 1.0.445

package/src/templates/AGENTS.md.template

@@ -126,7 +126,7 @@ Good: npm run build → node script.js → Success
 
 ### Test Before Ship
 - Tests pass at every step — unit after each task, E2E before close, no exceptions
-- `/sw:test-aware-planner` generates BDD test plans during design — verify they exist before `/sw:do`
+- `/sw:increment` generates BDD test plans during design via the sw-planner agent — verify they exist before `/sw:do`
 - TDD cycle: `/sw:tdd-red` → `/sw:tdd-green` → `/sw:tdd-refactor`
 - E2E with Playwright CLI (`npx playwright test`) is a blocking closure gate
 <!-- /SECTION -->
@@ -378,7 +378,7 @@ specweave context projects
 5. Create `tasks.md` (task checklist with BDD tests)
 6. Optional: `plan.md` for complex features
 7. **Verify** tasks.md has `**Test Plan**:` for every task with testable ACs
-8. **Verify** E2E scenarios exist for user-facing user stories — re-run `/sw:test-aware-planner` if missing
+8. **Verify** E2E scenarios exist for user-facing user stories — re-run `/sw:plan --force` if missing
 
 ### Completing Tasks
 1. Implement the task

package/src/templates/CLAUDE.md.template

@@ -221,7 +221,7 @@ Primary: `/sw:progress-sync`. Individual: `/sw-github:push`, `/sw-github:close`.
 **Testing is a pipeline step, not an afterthought.**
 
 ### During Design (`/sw:increment`)
-- `/sw:test-aware-planner` generates tasks.md with BDD test plans (Given/When/Then) for every AC
+- `/sw:increment` generates tasks.md with BDD test plans (Given/When/Then) for every AC via the sw-planner agent
 - Every task MUST have a `**Test Plan**:` block before implementation begins
 - E2E test scenarios MUST be specified for user-facing features
 

package/plugins/specweave/commands/docs-updater.md

@@ -1,66 +0,0 @@
----
-description: "DEPRECATED: Use /sw:docs-updater skill instead. Living documentation updater that syncs implementation progress to product docs."
-user-invocable: false
----
-
-# Documentation Updater
-
-## Project Overrides
-
-!`s="docs-updater"; 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`
-
-Updates product documentation (.specweave/docs/) based on implementation progress.
-
-## When to Use
-
-- Task specifies documentation updates in tasks.md
-- Feature implementation is complete
-- User says "update documentation" or "sync docs"
-- After closing increment to ensure docs reflect reality
-
-## What It Does
-
-1. **Reads task requirements** - Understands what was implemented from tasks.md
-2. **Updates living docs** - Modifies `.specweave/docs/` files with actual implementation
-3. **Status tracking** - Changes `[DRAFT]` → `[COMPLETE]` on doc sections
-4. **Bidirectional links** - Maintains links between docs and increments
-5. **Format adaptation** - Matches existing doc structure (features/ or modules/)
-
-## Workflow
-
-```
-1. Read tasks.md → Find documentation tasks
-2. Read implementation → Understand what changed
-3. Update docs → Add real code examples, endpoints, configs
-4. Mark complete → Change [DRAFT] to [COMPLETE]
-5. Verify links → Ensure increment → doc references work
-```
-
-## Example
-
-**tasks.md says:**
-```markdown
-**Documentation Updates**:
-- [ ] .specweave/docs/features/payment.md [DRAFT]
-- [ ] .specweave/docs/api/payments.md [DRAFT]
-```
-
-**docs-updater does:**
-1. Reads payment implementation code
-2. Updates `payment.md` with actual code examples
-3. Updates API docs with real endpoints discovered in code
-4. Changes status to `[COMPLETE]`
-
-## Integration Points
-
-- **Called by**: spec-generator, task completion hooks
-- **Updates**: `.specweave/docs/**/*.md`
-- **Reads**: `tasks.md`, implementation code
-
-## Best Practices
-
-- Run after completing feature tasks, not during
-- Verify doc links are valid (use relative paths)
-- Keep examples in sync with actual code
-- Don't over-document - focus on what users need
-

package/plugins/specweave/skills/docs-updater/SKILL.md

@@ -1,84 +0,0 @@
----
-description: Living documentation updater that syncs implementation progress to product docs. Use when updating docs after task completion, changing DRAFT status to published, or ensuring documentation reflects current implementation state.
-argument-hint: "[increment-id]"
----
-
-# Documentation Updater
-
-## Project Overrides
-
-!`s="docs-updater"; 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`
-
-Updates living documentation (.specweave/docs/) based on implementation progress after task completion or increment closure.
-
-## When to Use
-
-- After closing an increment to ensure docs reflect reality (called by `/sw:done` Step 10b)
-- Task specifies documentation updates in tasks.md
-- Feature implementation is complete
-- User says "update documentation" or "update docs links"
-
-## Workflow
-
-### Step 1: Detect Context
-
-1. If increment ID is provided, load `spec.md`, `tasks.md`, and `metadata.json`
-2. Detect project ID from config: `.specweave/config.json` → `project.name`
-3. Locate living docs: `.specweave/docs/internal/`
-
-### Step 2: Verify Feature Specs Exist
-
-1. Check `.specweave/docs/internal/specs/{project}/` for FS-XXX folders
-2. For each folder, verify `FEATURE.md` and `us-*.md` files exist
-3. If NO feature specs found and increment exists:
-   - Run: `specweave sync-living-docs <increment-id>` to create them
-   - Verify again after sync
-4. Report: "Found N feature specs in {project}/"
-
-### Step 3: Update Cross-References in Existing Docs
-
-Scan `.specweave/docs/internal/` for docs that should reference the feature specs:
-
-1. **FEATURE-CATALOG.md** (in `enterprise/`): Add entries for spec-based features with links to `specs/{project}/FS-XXX/FEATURE.md`
-2. **FEATURE-TO-CODE.md** (in `relationships/`): Add mappings from spec features to code features
-3. **Module docs** (in `modules/`): Add "Related Specs" links where modules correspond to feature areas
-4. **Project specs README** (`specs/{project}/README.md`): Update feature listing with links to each FS-XXX
-
-For each doc update:
-- Read existing content
-- Add or update `## Related Specs` or `## Feature Specs` section
-- Use relative markdown links: `[FS-001](../specs/{project}/FS-001/FEATURE.md)`
-- Preserve existing content, only add/update the cross-reference sections
-
-### Step 4: Update Status Markers
-
-1. Scan docs for `[DRAFT]` markers on sections that correspond to completed ACs
-2. Change `[DRAFT]` → `[COMPLETE]` for sections matching completed acceptance criteria
-3. Report: "Updated N status markers from DRAFT to COMPLETE"
-
-### Step 5: Verify Bidirectional Links
-
-Validate that links work in both directions:
-
-1. **Increment → Feature Spec**: spec.md references should resolve to `specs/{project}/FS-XXX/`
-2. **Feature Spec → Living Docs**: FEATURE.md links to modules, architecture, etc.
-3. **Living Docs → Feature Spec**: Module docs, catalogs link back to specs
-4. Report broken links with suggested fixes
-
-### Step 6: Summary Report
-
-Display results:
-
-```
-Docs Update Summary:
-- Feature specs verified: N
-- Cross-references updated: M files
-- Status markers updated: K (DRAFT → COMPLETE)
-- Broken links found: L (see details above)
-```
-
-## Integration Points
-
-- **Called by**: `/sw:done` (Step 10b), task completion hooks, spec-generator
-- **Updates**: `.specweave/docs/**/*.md`
-- **Reads**: `tasks.md`, `spec.md`, implementation code, feature specs

package/plugins/specweave/skills/spec-generator/SKILL.md

@@ -1,92 +0,0 @@
----
-description: Generates comprehensive specifications (spec.md, plan.md, tasks.md with embedded tests) for SpecWeave increments. Use when creating new increments, planning features, or converting ideas into actionable specs. Produces structured documentation with proven templates and context-aware organization.
----
-
-# Spec Generator - Flexible Increment Documentation
-
-**Purpose**: Generate spec.md, plan.md, tasks.md with embedded tests for SpecWeave increments.
-
-**When to Use**: Creating increments (`/sw:inc`), planning features, converting ideas into specs.
-
----
-
-## MANDATORY STEP 0: Get Project Context FIRST
-
-**This step is BLOCKING — do not proceed until you have actual project/board IDs.**
-
-1. **Run**: `specweave context projects`
-2. **Parse** the JSON output for project IDs and (if 2-level) board IDs
-3. **Resolve** each user story to correct project using this priority:
-   - EXACT MATCH from config → use it
-   - LIVING DOCS folder match → use it
-   - RECENT PATTERNS in past increments → use same
-   - UNCERTAIN → ASK USER (never guess!)
-   - FALLBACK → use "default" (never "specweave")
-
-**VALIDATION**: Every US MUST have `**Project**:` field with resolved value. Never use placeholders.
-
----
-
-## 1. Spec Generation (spec.md)
-
-**Adapts to Context**: New Product (full PRD) | Feature Addition (focused stories) | Bug Fix (problem-solution) | Refactoring (current-proposed)
-
-**YAML Frontmatter**:
-```yaml
----
-increment: 0001-feature-name
-title: "Feature Title"
-type: feature
-priority: P1
-status: planned
-created: 2025-12-04
----
-```
-
-**Core Sections**: Executive Summary, Problem Statement, User Stories & Acceptance Criteria, Success Metrics, Non-Goals.
-
-**Per-US Format**:
-```markdown
-### US-001: [Title]
-**Project**: [MANDATORY - resolved from Step 0]
-**Board**: [MANDATORY for 2-level only]
-
-**As a** [user type]
-**I want** [goal]
-**So that** [benefit]
-
-**Acceptance Criteria**:
-- [ ] **AC-US1-01**: [Criterion]
-```
-
-**Flexible Sections** (auto-include by context): Competitive Analysis, Technical Requirements, API Design, UI/UX, Security, Migration Plan.
-
-## 2. Technical Plan (plan.md)
-
-Core sections: Architecture Overview, Component Architecture, Data Models, Implementation Strategy (phased), Testing Strategy, Deployment Plan, Risks & Mitigations.
-
-## 3. Task Breakdown (tasks.md)
-
-```markdown
-### T-001: [Task Title]
-**User Story**: US-001 | **Satisfies ACs**: AC-US1-01
-**Status**: [ ] Not Started
-**Test**: Given [X] → When [Y] → Then [Z]
-```
-
-## Multi-Project User Story Generation
-
-When multi-project mode detected (config `multiProject.enabled`, multiple `specs/` folders, or user mentions multiple repos):
-
-- Group user stories by project (FE/BE/SHARED/MOBILE/INFRA)
-- Use prefixed IDs: `US-FE-001`, `AC-FE-US1-01`
-- Each US specifies `**Project**:` inline
-- Tasks reference project-scoped story IDs
-
-| Keywords | Project |
-|----------|---------|
-| UI, component, page, form, view | Frontend |
-| API, endpoint, CRUD, webhook, service | Backend |
-| types, schemas, validators, utilities | Shared |
-| iOS, Android, mobile, push notification | Mobile |
-| Terraform, K8s, Docker, CI/CD | Infrastructure |

package/plugins/specweave/skills/test-aware-planner/SKILL.md

@@ -1,117 +0,0 @@
----
-description: Generate tasks.md with embedded test plans in BDD format, one user story at a time to prevent crashes. Use for test-first task planning where each task includes Given/When/Then scenarios. Produces implementation tasks with inline test specifications.
-context: fork
-model: sonnet
----
-
-# Test-Aware Planner Skill
-
-## STEP 0: Register Skill Chain Marker (MANDATORY - DO THIS FIRST)
-
-**Before any other work**, register your invocation so the skill-chain-enforcement-guard allows tasks.md writes.
-
-Extract the increment ID from your args (e.g., "Generate tasks for increment 0323-feature-name ...").
-Then write the marker file:
-
-```bash
-mkdir -p .specweave/state
-STATE_FILE=".specweave/state/skill-chain-XXXX-name.json"
-if [ -f "$STATE_FILE" ]; then
-  jq '.planner_invoked=true | .planner_invoked_at="'$(date -Iseconds)'"' "$STATE_FILE" > "${STATE_FILE}.tmp" && mv "${STATE_FILE}.tmp" "$STATE_FILE"
-else
-  echo '{"planner_invoked":true,"planner_invoked_at":"'$(date -Iseconds)'"}' > "$STATE_FILE"
-fi
-```
-
-Replace `XXXX-name` with the actual increment ID. **This unblocks the guard for tasks.md writes.**
-
-**If you skip this step, your Write to tasks.md will be BLOCKED by the PreToolUse guard.**
-
-## Overview
-
-You generate `tasks.md` with embedded test plans for each task. No separate tests.md - tests are inline with tasks.
-
-## Core Principles
-
-1. **ONE user story per response** - Never generate all tasks at once
-2. **Embedded tests** - Test plans inline with tasks
-3. **AC coverage** - Every AC-ID must be covered
-
-## Quick Reference
-
-### Task Format
-
-```markdown
-## User Story: US-001 - Title
-
-**Linked ACs**: AC-US1-01, AC-US1-02
-**Tasks**: X total, 0 completed
-
-### T-001: Task Title
-
-**User Story**: US-001
-**Satisfies ACs**: AC-US1-01
-**Status**: [ ] pending
-
-**Test Plan**:
-- **Given** precondition
-- **When** action
-- **Then** expected result
-
-**Test Cases**:
-1. **Unit**: `tests/unit/feature.test.ts`
-   - testFeatureSuccess(): Description
-   - **Coverage Target**: 90%
-
-2. **Integration**: `tests/integration/flow.test.ts`
-   - testFullFlow(): Description
-   - **Coverage Target**: 85%
-
-**Implementation**:
-1. Create file
-2. Implement function
-3. Run tests
-```
-
-### Coverage Targets
-
-| Code Type | Target |
-|-----------|--------|
-| Core logic | 90-95% |
-| API endpoints | 85-90% |
-| Utilities | 80-85% |
-| Overall | 80-90% |
-
-### Multi-Project Format
-
-If umbrella.enabled in config:
-```markdown
-## Phase 1: Shared (sw-app-shared)
-
-### User Story: US-SHARED-001 - Types
-**Linked ACs**: AC-SHARED-US1-01
-```
-
-## Workflow
-
-1. **Analysis** (< 500 tokens): List user stories, ask which first
-2. **Generate ONE US tasks** (< 800 tokens): Write to tasks.md
-3. **Report progress**: "US-001 complete. Ready for US-002?"
-4. **Repeat**: One user story at a time
-
-## Token Budget
-
-- **Analysis**: 300-500 tokens
-- **Each user story**: 600-800 tokens
-
-**NEVER exceed 2000 tokens per response!**
-
-## Validation Checklist
-
-- [ ] All AC-IDs from spec.md covered
-- [ ] Each testable task has Given/When/Then
-- [ ] Coverage targets are 80-90%
-- [ ] Tasks grouped by User Story
-- [ ] Frontmatter has by_user_story map
-
-