specweave 1.0.593 → 2.0.3

package/plugins/specweave/skills/pm/templates/spec-template.md

@@ -1,159 +0,0 @@
-# Spec Template
-
-Copy and customize this template for new increments.
-
-```markdown
----
-increment: ####-feature-name
-title: "Feature Title"
-status: active
-priority: P0
-type: feature
-created: YYYY-MM-DD
----
-
-# Feature Title
-
-## Problem Statement
-
-[Describe the problem this feature solves. Be specific about the pain point.]
-
-## Goals
-
-- [Primary goal]
-- [Secondary goal]
-- [Measurable outcome]
-
-## User Stories
-
-### US-001: [First User Story Title]
-**Project**: [project-name]
-**As a** [user role]
-**I want** [capability/action]
-**So that** [benefit/value]
-
-**Acceptance Criteria**:
-- [ ] **AC-US1-01**: Given [precondition], when [action], then [expected result]
-- [ ] **AC-US1-02**: [Another criterion]
-- [ ] **AC-US1-03**: [Edge case handling]
-
-### US-002: [Second User Story Title]
-**Project**: [project-name]
-**As a** [user role]
-**I want** [capability/action]
-**So that** [benefit/value]
-
-**Acceptance Criteria**:
-- [ ] **AC-US2-01**: [Criterion]
-- [ ] **AC-US2-02**: [Criterion]
-
-### US-003: [Third User Story Title]
-**Project**: [project-name]
-**As a** [user role]
-**I want** [capability/action]
-**So that** [benefit/value]
-
-**Acceptance Criteria**:
-- [ ] **AC-US3-01**: [Criterion]
-- [ ] **AC-US3-02**: [Criterion]
-
-## Out of Scope
-
-- [What this feature explicitly does NOT include]
-- [Features to be addressed in future increments]
-- [Technical limitations accepted for MVP]
-
-## Technical Notes
-
-### Dependencies
-- [External service/API]
-- [Internal module]
-
-### Constraints
-- [Performance requirement]
-- [Security consideration]
-
-### Architecture Decisions
-- [Key design choice and rationale]
-
-## Non-Functional Requirements
-
-- **Performance**: [Measurable target, e.g., "Scanner classifies 500 skills in < 100ms"]
-- **Accessibility**: [Requirements if UI-facing, e.g., "All interactive elements keyboard-navigable"]
-- **Security**: [Relevant security considerations, e.g., "No user input reaches path resolution unsanitized"]
-- **Compatibility**: [Platform/browser/OS constraints, e.g., "Works on Windows, macOS, Linux path formats"]
-
-## Edge Cases
-
-- [Edge case 1]: [Expected behavior, e.g., "Empty input returns empty result set"]
-- [Edge case 2]: [Expected behavior, e.g., "Symlinked directories resolve to their target path"]
-- [Edge case 3]: [Expected behavior, e.g., "Case-insensitive filesystem matching on macOS/Windows"]
-
-## Risks
-
-| Risk | Probability | Impact | Severity | Mitigation |
-|------|-------------|--------|----------|------------|
-| [Risk description] | [0.0-1.0] | [1-10] | [P×I score] | [Strategy] |
-| [Risk description] | [0.0-1.0] | [1-10] | [P×I score] | [Strategy] |
-
-## Success Metrics
-
-- [Metric 1]: [Target value]
-- [Metric 2]: [Target value]
-- [Qualitative success criteria]
-```
-
-## Guidelines
-
-### User Story Sizing
-- **Small**: 1-2 tasks, 1-2 days
-- **Medium**: 3-5 tasks, 3-5 days
-- **Large**: 6+ tasks - consider splitting
-
-### Acceptance Criteria Count
-- Minimum: 2 per user story
-- Maximum: 5 per user story
-- If more needed, split the user story
-
-### AC ID Format
-```
-AC-US{story_number}-{criterion_number}
-
-Examples:
-- AC-US1-01 (User Story 1, Criterion 1)
-- AC-US2-03 (User Story 2, Criterion 3)
-- AC-US10-01 (User Story 10, Criterion 1)
-```
-
-### Priority Levels
-- **P0**: Critical, blocks release
-- **P1**: Important, should be in release
-- **P2**: Nice to have, can defer
-
-### AC Quality Rules (MANDATORY)
-
-**Every AC must be unambiguous and single-outcome:**
-
-- **No "or" conditions**: "disabled or hidden" is ambiguous — pick ONE expected behavior
-  - Bad: `AC-US1-01: Button is disabled or hidden`
-  - Good: `AC-US1-01: Button has the disabled attribute and shows tooltip "Not available"`
-- **Measurable outcomes**: Use concrete values, not subjective descriptions
-  - Bad: `AC-US1-01: Card appears visually dimmed`
-  - Good: `AC-US1-01: Card text has opacity 0.7 and uses var(--text-tertiary) color`
-- **BDD format preferred**: `Given [precondition], when [action], then [single expected result]`
-- **One assertion per AC**: If you need to verify multiple things, split into separate ACs
-- **No subjective verbs**: Avoid "looks good", "is clear", "feels responsive" — use testable criteria
-
-### Mandatory Spec Sections
-
-Every spec.md MUST include these sections (QA scoring penalizes missing sections):
-
-1. **Problem Statement** — why this exists
-2. **Goals** — what success looks like
-3. **User Stories** — with ACs in BDD format
-4. **Out of Scope** — explicit boundaries
-5. **Non-Functional Requirements** — performance, security, accessibility, compatibility
-6. **Edge Cases** — boundary conditions, error states, unusual scenarios
-7. **Risks** — P×I scored risk table with mitigations
-8. **Technical Notes** — dependencies, constraints, architecture decisions
-9. **Success Metrics** — measurable outcomes

package/plugins/specweave/skills/pr/SKILL.md

@@ -1,257 +0,0 @@
----
-description: Create pull request from increment feature branch. Use when increment is complete and push strategy is pr-based, or when explicitly saying "create PR", "open pull request", "make a PR".
-version: 1.0.0
-argument-hint: "<increment-id>"
-user-invokable: true
----
-
-# Create Pull Request
-
-Creates a pull request for a completed increment. Automatically invoked by `sw:done` when `cicd.pushStrategy` is `"pr-based"`. Can also be invoked manually.
-
-## When to Activate
-
-**Do activate:**
-- `sw:done` invokes this after quality gates pass (when `pushStrategy: "pr-based"`)
-- User says "create PR", "open pull request", "make a PR for this increment"
-- User says "push this as a PR"
-
-**Do NOT activate:**
-- `pushStrategy` is `"direct"` and user didn't explicitly ask for a PR
-- Increment is not active or completed
-- No changes exist to push
-
-## Step 1: Read Configuration
-
-```bash
-# Read push strategy and git config
-PUSH_STRATEGY=$(jq -r '.cicd.pushStrategy // "direct"' .specweave/config.json 2>/dev/null)
-BRANCH_PREFIX=$(jq -r '.cicd.git.branchPrefix // "sw/"' .specweave/config.json 2>/dev/null)
-TARGET_BRANCH=$(jq -r '.cicd.git.targetBranch // "main"' .specweave/config.json 2>/dev/null)
-DELETE_ON_MERGE=$(jq -r '.cicd.git.deleteOnMerge // true' .specweave/config.json 2>/dev/null)
-```
-
-Read increment metadata to check if PR already exists:
-```bash
-jq -r '.prRefs // empty' .specweave/increments/{increment-id}/metadata.json
-```
-
-If `prRefs` already has an entry with `state: "open"`, skip PR creation and report existing PR URL.
-
-## Step 2: Determine Branch Name
-
-**External ticket key prefix** — If the increment was imported from JIRA/ADO, prefix the branch with the external ticket key for native integration linking:
-
-```bash
-# Check metadata for external ticket key (JIRA or ADO)
-JIRA_KEY=$(jq -r '.jira.issue // .jira.issueKey // .externalLinks.jira.epicKey // .externalLinks.jira.issueKey // empty' \
-  .specweave/increments/${INCREMENT_ID}/metadata.json 2>/dev/null)
-ADO_ID=$(jq -r '.externalLinks.ado.featureId // .externalLinks.ado.workItemId // empty' \
-  .specweave/increments/${INCREMENT_ID}/metadata.json 2>/dev/null)
-EXTERNAL_KEY_BRANCHING=$(jq -r '.cicd.git.externalKeyBranching // true' .specweave/config.json 2>/dev/null)
-
-if [ "$EXTERNAL_KEY_BRANCHING" = "true" ] && [ -n "$JIRA_KEY" ]; then
-  BRANCH_NAME="${JIRA_KEY}/${INCREMENT_ID}"
-  # e.g., ID-300/0520-auth-gateway-otel
-elif [ "$EXTERNAL_KEY_BRANCHING" = "true" ] && [ -n "$ADO_ID" ]; then
-  BRANCH_NAME="AB#${ADO_ID}/${INCREMENT_ID}"
-  # e.g., AB#4567/0520-auth-gateway-otel
-else
-  BRANCH_NAME="${BRANCH_PREFIX}${INCREMENT_ID}"
-  # e.g., sw/0520-pr-based-increment-closure
-fi
-```
-
-Check current branch:
-```bash
-CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
-```
-
-## Step 3: Ensure on Feature Branch
-
-**If already on the feature branch** (`CURRENT_BRANCH === BRANCH_NAME`):
-- Skip branch creation, proceed to push.
-
-**If on target branch** (main/develop):
-- Check if feature branch exists locally: `git branch --list ${BRANCH_NAME}`
-- If exists: `git checkout ${BRANCH_NAME}`
-- If not: `git checkout -b ${BRANCH_NAME}`
-
-**If on a different branch** (user created manually):
-- Use the existing branch as-is. Set `BRANCH_NAME = CURRENT_BRANCH`.
-- Do NOT force rename to match naming convention.
-
-## Step 4: Push Branch
-
-```bash
-git push -u origin ${BRANCH_NAME}
-```
-
-If push fails (e.g., no remote, auth issues), warn and exit gracefully. Do NOT block increment closure.
-
-## Step 5: Build PR Description
-
-Read spec.md to build the PR body. Use `--body-file` to avoid shell quoting issues:
-
-```bash
-# Create temp file for PR body
-cat > /tmpsw-pr-body-${INCREMENT_ID}.md << 'PREOF'
-## Summary
-
-<!-- Auto-generated from SpecWeave increment {INCREMENT_ID} -->
-
-{spec.md overview section — first paragraph}
-
-## User Stories
-
-{For each US in spec.md:}
-- **US-001**: {title} ({AC count} acceptance criteria)
-- **US-002**: {title} ({AC count} acceptance criteria)
-
-## Acceptance Criteria
-
-{Checklist of all ACs from spec.md:}
-- [ ] AC-US1-01: {criterion}
-- [ ] AC-US1-02: {criterion}
-
-## Test Summary
-
-{Summary of test plan from tasks.md — what was tested, coverage}
-
----
-
-*Created by [SpecWeave](https://verified-skill.com) increment `{INCREMENT_ID}`*
-PREOF
-```
-
-## Step 6: Create Pull Request
-
-```bash
-gh pr create \
-  --title "[${INCREMENT_ID}] {spec title}" \
-  --body-file /tmpsw-pr-body-${INCREMENT_ID}.md \
-  --base ${TARGET_BRANCH} \
-  --head ${BRANCH_NAME}
-```
-
-Capture the PR URL and number:
-```bash
-PR_URL=$(gh pr create ... 2>&1)
-PR_NUMBER=$(echo "$PR_URL" | grep -oE '[0-9]+$')
-```
-
-Clean up temp file:
-```bash
-rm -f /tmpsw-pr-body-${INCREMENT_ID}.md
-```
-
-If `deleteOnMerge` is true, add auto-delete label or note in PR description.
-
-## Step 7: Update Metadata
-
-Update increment metadata with PR reference. Edit `metadata.json` to add/update `prRefs`:
-
-```json
-{
-  "prRefs": [{
-    "branch": "sw/0520-pr-based-increment-closure",
-    "prNumber": 42,
-    "prUrl": "https://github.com/org/repo/pull/42",
-    "state": "open",
-    "createdAt": "2026-03-12T10:00:00Z"
-  }]
-}
-```
-
-Use `jq` or direct JSON edit to update metadata.json.
-
-## Step 7b: Link PR to External Tickets
-
-After PR creation, link the PR to any associated JIRA/ADO tickets. This creates remote links (JIRA) or hyperlinks (ADO) so the PR appears in the external tool's UI.
-
-```bash
-specweave link-pr \
-  --increment "${INCREMENT_ID}" \
-  --pr-url "${PR_URL}" \
-  --pr-number "${PR_NUMBER}" \
-  --branch "${BRANCH_NAME}"
-```
-
-This is **non-blocking** — if linking fails, the PR is still created successfully. Errors are logged as warnings.
-
-The link-pr command:
-- Reads metadata.json for JIRA issue keys and ADO work item IDs
-- Creates JIRA remote links via `/rest/api/3/issue/{key}/remotelink` (idempotent via `globalId`)
-- Creates ADO work item hyperlinks via JSON Patch on work item relations
-- Reports linked tickets and any errors
-
-## Step 8: Multi-Repo / Umbrella Mode
-
-Check if umbrella mode is enabled:
-```bash
-UMBRELLA=$(jq -r '.umbrella.enabled // false' .specweave/config.json 2>/dev/null)
-```
-
-If umbrella mode:
-
-1. **Scan for modified repos**: Check each `repositories/{org}/{repo}/` for changes relative to target branch:
-   ```bash
-   for repo_dir in repositories/*/*; do
-     if [ -d "$repo_dir/.git" ]; then
-       cd "$repo_dir"
-       CHANGES=$(git log ${TARGET_BRANCH}..HEAD --oneline 2>/dev/null | wc -l)
-       if [ "$CHANGES" -gt 0 ]; then
-         # This repo has changes — create branch + PR
-       fi
-       cd -
-     fi
-   done
-   ```
-
-2. **Create branch + PR in each repo** with changes (Steps 3-6 per repo).
-
-3. **Collect all PR refs** and store in metadata as array:
-   ```json
-   {
-     "prRefs": [
-       { "branch": "sw/0520-...", "prUrl": "...repo1/pull/42", "repoSlug": "org/repo1" },
-       { "branch": "sw/0520-...", "prUrl": "...repo2/pull/15", "repoSlug": "org/repo2" }
-     ]
-   }
-   ```
-
-4. **Continue on failure**: If one repo's PR fails, log the error and continue with others. Report all results at the end.
-
-## Step 9: Output Summary
-
-Display a summary table:
-
-```
-PR CREATION SUMMARY
-═══════════════════════════════════════════════
-Increment: 0520-pr-based-increment-closure
-Strategy:  pr-based
-Target:    main
-
-  Repo            Branch                          PR
-  ─────────────   ─────────────────────────────   ────────────────────────────
-  org/repo1       sw/0520-pr-based-closure        https://github.com/.../42
-  org/repo2       sw/0520-pr-based-closure        https://github.com/.../15
-
-Status: 2/2 PRs created successfully
-```
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| `gh` not installed | Warn: "Install GitHub CLI: brew install gh" |
-| `gh auth` not configured | Warn: "Run: gh auth login" |
-| Push rejected | Warn but don't block. Show error message. |
-| PR already exists for branch | Skip creation, report existing PR URL |
-| No changes to push | Skip PR creation, inform user |
-| Merge conflicts with target | Create PR anyway (conflicts visible in PR UI) |
-
-## Resources
-
-- [Official Documentation](https://verified-skill.com/docs/reference/skills#pr)

package/plugins/specweave/skills/pr-review/SKILL.md

@@ -1,167 +0,0 @@
----
-description: AI-powered pull request review against spec acceptance criteria. Use for "review PR", "check PR against spec", "review pull request". Enterprise feature.
-version: 1.0.0
-argument-hint: "<increment-id|pr-url>"
-user-invokable: true
----
-
-# AI Pull Request Review
-
-Reviews a pull request against the increment's spec.md acceptance criteria. Posts structured review comments on the PR via `gh pr review`.
-
-This is an **enterprise feature** — optional, not part of the default flow. Invoke explicitly or configure for automatic invocation.
-
-## When to Activate
-
-**Do activate:**
-- User says "review PR", "check PR against spec", "review pull request"
-- User says "AI review for PR #42"
-- Configured for automatic review after `sw:pr` creates a PR
-
-**Do NOT activate:**
-- User is doing manual code review (don't interfere)
-- No increment context available
-- PR is already merged
-
-## Step 1: Resolve PR and Increment
-
-**If given an increment ID:**
-```bash
-# Read PR refs from metadata
-PR_URL=$(jq -r '.prRefs[0].prUrl // empty' .specweave/increments/{id}/metadata.json)
-PR_NUMBER=$(jq -r '.prRefs[0].prNumber // empty' .specweave/increments/{id}/metadata.json)
-```
-
-**If given a PR URL or number:**
-```bash
-# Extract PR number from URL
-PR_NUMBER=$(echo "$PR_URL" | grep -oE '[0-9]+$')
-# Find increment by searching metadata for matching prRefs
-```
-
-**If neither:** Check current branch for an associated PR:
-```bash
-CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
-PR_NUMBER=$(gh pr list --head "$CURRENT_BRANCH" --json number -q '.[0].number')
-```
-
-## Step 2: Load Spec Context
-
-Read the increment spec.md to extract:
-1. All acceptance criteria (AC-USXX-YY)
-2. User stories overview
-3. Non-functional requirements
-4. Edge cases documented in the spec
-
-Build a review checklist from ACs.
-
-## Step 3: Get PR Diff
-
-```bash
-gh pr diff ${PR_NUMBER} > /tmpsw-pr-diff-${PR_NUMBER}.diff
-```
-
-Also get the list of changed files:
-```bash
-gh pr view ${PR_NUMBER} --json files -q '.files[].path'
-```
-
-## Step 4: Review Against Acceptance Criteria
-
-For each AC in spec.md, analyze the diff to determine:
-
-- **SATISFIED**: The diff clearly implements this criterion
-- **PARTIALLY SATISFIED**: Some aspects are covered, others are missing
-- **NOT SATISFIED**: No evidence of implementation in the diff
-- **NOT APPLICABLE**: This AC is not relevant to the changed files
-
-Build a structured review:
-
-```markdown
-## SpecWeave AC Review — Increment {INCREMENT_ID}
-
-### Acceptance Criteria Coverage
-
-| AC | Status | Evidence |
-|----|--------|----------|
-| AC-US1-01: User can log in | SATISFIED | `src/auth/login.ts` implements full flow |
-| AC-US1-02: Invalid creds show error | PARTIALLY | Error handling exists but no user-facing message |
-| AC-US2-01: Session persists | NOT SATISFIED | No session storage implementation found |
-
-### Code Quality Observations
-
-{List any code quality issues found in the diff — not bugs, but patterns that deviate from the spec or best practices}
-
-### Summary
-
-{Overall assessment: ready to merge / needs changes / needs discussion}
-- {X}/{Y} ACs satisfied
-- {Z} observations
-```
-
-## Step 5: Post Review
-
-Determine review action based on AC coverage:
-
-- **All ACs satisfied**: `--approve`
-- **Any AC not satisfied**: `--request-changes`
-- **Only observations, no blockers**: `--comment`
-
-```bash
-gh pr review ${PR_NUMBER} \
-  --body-file /tmpsw-pr-review-${PR_NUMBER}.md \
-  --{approve|request-changes|comment}
-```
-
-Clean up:
-```bash
-rm -f /tmpsw-pr-diff-${PR_NUMBER}.diff /tmpsw-pr-review-${PR_NUMBER}.md
-```
-
-## Step 6: Post Inline Comments (Optional)
-
-For specific issues found in the diff, post inline comments on the relevant lines:
-
-```bash
-# For each finding with a specific file + line:
-gh api repos/{owner}/{repo}/pulls/${PR_NUMBER}/comments \
-  -f body="**AC-US1-02**: Error message is logged but not displayed to the user. The spec requires a user-facing error toast." \
-  -f commit_id="{latest_commit_sha}" \
-  -f path="src/auth/login.ts" \
-  -F line=42 \
-  -f side="RIGHT"
-```
-
-## Scheduled Review Mode
-
-For teams that want automated PR reviews, this skill can be triggered via Claude Code scheduled tasks:
-
-```json
-// .claude/scheduled-tasks.json
-{
-  "tasks": [{
-    "schedule": "*/30 * * * *",
-    "command": "sw:pr-review --all-open",
-    "description": "Review all open PRs every 30 minutes"
-  }]
-}
-```
-
-When invoked with `--all-open`:
-1. List all open PRs: `gh pr list --state open --json number,headRefName`
-2. For each PR, check if it has an associated increment (via branch naming convention or metadata scan)
-3. Skip PRs already reviewed by this tool (check for existing SpecWeave review comments)
-4. Review each PR against its increment spec
-
-## Multi-Agent Review (Complex PRs)
-
-For PRs spanning multiple domains (frontend + backend + infrastructure), consider using `sw:team-build` with the `review` preset to spawn domain-specialized review agents in parallel.
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| No spec.md found | Warn: "No increment spec found for this PR. Cannot perform AC review." |
-| PR already merged | Skip: "PR #{N} is already merged." |
-| `gh` auth issues | Warn: "Run: gh auth login" |
-| Large diff (>5000 lines) | Summarize by file instead of line-by-line review |