specrails-core 3.2.0 → 3.3.1

package/docs/installation.md

@@ -8,6 +8,7 @@ This guide covers the complete installation process in detail. For the quick ver
 
 | Tool | Why | Install |
 |------|-----|---------|
+| **Node.js 18+** | Required for the installer | [nodejs.org](https://nodejs.org/) or via [nvm](https://github.com/nvm-sh/nvm) |
 | **Git** | SpecRails operates on git repositories | [git-scm.com](https://git-scm.com/) |
 | **Claude Code** | The AI CLI that runs the agents | `npm install -g @anthropic-ai/claude-code` |
 
@@ -15,9 +16,7 @@ This guide covers the complete installation process in detail. For the quick ver
 
 | Tool | Why | Install |
 |------|-----|---------|
-| **npm** | Pipeline Monitor dashboard, OpenSpec CLI | Via [nvm](https://github.com/nvm-sh/nvm) |
 | **GitHub CLI** | Auto-create PRs, manage issues | `brew install gh` or [cli.github.com](https://cli.github.com/) |
-| **OpenSpec CLI** | Structured spec workflow | `npm install -g @openspec/cli` |
 
 ### Optional
 
@@ -42,8 +41,8 @@ No cloning required. Downloads the latest version and runs the installer automat
 If you prefer to clone the repo first:
 
 ```bash
-git clone https://github.com/fjpulidop/specrails.git
-./specrails/install.sh --root-dir <your-project>
+git clone https://github.com/fjpulidop/specrails-core.git
+./specrails-core/install.sh --root-dir <your-project>
 ```
 
 ### From curl
@@ -51,7 +50,7 @@ git clone https://github.com/fjpulidop/specrails.git
 Alternatively, pipe the installer directly:
 
 ```bash
-curl -sL https://raw.githubusercontent.com/fjpulidop/specrails/main/install.sh | bash
+curl -sL https://raw.githubusercontent.com/fjpulidop/specrails-core/main/install.sh | bash
 ```
 
 > **Important:** Always run the installer from the **target repository** — the project where you want SpecRails installed. If you run it from inside the SpecRails source repo, the installer will detect this and prompt you for the correct target path.
@@ -62,8 +61,7 @@ curl -sL https://raw.githubusercontent.com/fjpulidop/specrails/main/install.sh |
 2. **Detects existing setup** — warns if `.claude/agents/`, `.claude/commands/`, or `openspec/` already exist
 3. **Installs artifacts:**
    - `.claude/commands/setup.md` — the `/setup` wizard
-   - `.claude/setup-templates/` — all template files
-   - `.claude/web-manager/` — Pipeline Monitor dashboard
+   - `.claude/setup-templates/` — agent and command templates (temporary, removed after `/setup`)
    - `.claude/security-exemptions.yaml` — security scanner config
    - OpenSpec initialization (if CLI available)
 4. **Tracks version** — writes `.specrails-version` and `.specrails-manifest.json`
@@ -75,7 +73,6 @@ The installer only copies files. It does not:
 - Modify your existing code
 - Create commits
 - Push to any remote
-- Install npm dependencies (you do this manually for the web manager)
 
 ---
 
@@ -87,6 +84,19 @@ After installation, open Claude Code in your project and run:
 /setup
 ```
 
+There are two modes:
+
+| Mode | Command | When to use |
+|------|---------|-------------|
+| **Full wizard** (default) | `/setup` | Deep stack analysis, researched personas, fully adapted agents — takes 5–10 min |
+| **Lite** | `/setup --lite` | Fastest path — 3 questions, sensible defaults, done in under a minute |
+
+---
+
+### Full Wizard (default)
+
+The full 5-phase wizard — takes 5–10 minutes and produces deeply adapted agents.
+
 ### Phase 1: Codebase Analysis
 
 The wizard scans your project to detect:
@@ -116,10 +126,10 @@ Interactive prompts for:
 
 | Setting | Options |
 |---------|---------|
-| **Backlog provider** | GitHub Issues, JIRA, or none |
+| **Backlog provider** | Local tickets (default), GitHub Issues, JIRA, or none |
 | **Access mode** | Read-write or read-only |
 | **Git workflow** | Trunk-based, Git Flow, or custom |
-| **Agents** | Which agents to enable |
+| **Agents** | Which agents to enable (up to 14) |
 | **Commands** | Which commands to install |
 
 ### Phase 4: File Generation
@@ -132,7 +142,7 @@ The wizard fills all templates with your project-specific context:
 - `{{BACKEND_TECH_LIST}}` → your backend technologies
 - Every `{{PLACEHOLDER}}` resolved with real data
 
-**Generated files:**
+**Generated files (full set):**
 
 ```
 .claude/
@@ -145,13 +155,19 @@ The wizard fills all templates with your project-specific context:
 │   ├── sr-test-writer.md        # Uses your test framework
 │   ├── sr-security-reviewer.md  # Scans your patterns
 │   ├── sr-doc-sync.md           # Updates your doc format
+│   ├── sr-backend-developer.md  # Backend-specialized
+│   ├── sr-frontend-developer.md # Frontend-specialized
+│   ├── sr-backend-reviewer.md   # Backend quality audit
+│   ├── sr-frontend-reviewer.md  # Frontend quality audit
+│   ├── sr-merge-resolver.md     # AI-powered conflict resolution
+│   ├── sr-performance-reviewer.md # Performance regression detection
 │   └── [personas].md            # Your user personas
 ├── commands/
 │   └── sr/
 │       ├── implement.md
 │       ├── product-backlog.md
 │       ├── batch-implement.md
-│       └── ...
+│       └── ...                  # 17 commands total
 ├── rules/
 │   ├── backend.md
 │   ├── frontend.md
@@ -171,24 +187,24 @@ After this phase, `/setup` is no longer available — your workflow is ready.
 
 ---
 
-## Pipeline Monitor (optional)
+### Lite Mode (`/setup --lite`)
 
-SpecRails includes a web dashboard for visualizing pipeline execution.
+The quick path — three questions, sensible defaults, done in under a minute.
 
-### Install
+1. What is this project? (one sentence)
+2. Who are the target users?
+3. Git access for agents — read-only or read-write?
 
-```bash
-cd .claude/web-manager && npm install
-cd client && npm install
-```
-
-### Run
+**What gets installed:**
 
-```bash
-cd .claude/web-manager && npm run dev
-```
+| Item | Detail |
+|------|--------|
+| Core agents | sr-architect, sr-developer, sr-reviewer, sr-product-manager |
+| All workflow commands | `/sr:implement`, `/sr:product-backlog`, and 14 more |
+| Backlog storage | Local tickets (`.claude/local-tickets.json`) — no GitHub or JIRA required |
+| CLAUDE.md | Project-level context for agents |
 
-Opens at `http://localhost:4201` by default.
+You can run the full wizard later to deepen configuration: personas, stack analysis, layer-specific conventions.
 
 ---
 

package/docs/local-tickets.md

@@ -0,0 +1,192 @@
+# Local Ticket Management
+
+specrails-core ships with a built-in, file-based ticket management system. It is the **default backlog provider** — no GitHub account, CLI tool, or external service required.
+
+---
+
+## Overview
+
+Tickets live in `.claude/local-tickets.json` at your project root. Because it's a plain JSON file, tickets are:
+
+- **Version-controlled** — tracked by git, diffable in PRs
+- **Offline-first** — no network calls, no rate limits
+- **Tool-agnostic** — readable by any script or editor
+
+The file is read and written by specrails-core during command execution.
+
+---
+
+## Storage format
+
+`.claude/local-tickets.json`:
+
+```json
+{
+  "schema_version": "1.0",
+  "revision": 7,
+  "last_updated": "2026-03-23T10:00:00.000Z",
+  "next_id": 8,
+  "tickets": {
+    "1": {
+      "id": 1,
+      "title": "Add dark mode",
+      "description": "Support system-level dark mode preference via CSS variables.",
+      "status": "todo",
+      "priority": "medium",
+      "labels": ["area:frontend", "effort:medium"],
+      "assignee": null,
+      "prerequisites": [],
+      "metadata": {
+        "vpc_scores": { "persona-a": 4, "persona-b": 3 },
+        "effort_level": "Medium",
+        "user_story": "As a user working at night, I want dark mode...",
+        "area": "frontend"
+      },
+      "comments": [],
+      "created_at": "2026-03-20T09:00:00.000Z",
+      "updated_at": "2026-03-20T09:00:00.000Z",
+      "created_by": "sr-product-manager",
+      "source": "product-backlog"
+    }
+  }
+}
+```
+
+### Field reference
+
+**Root fields**
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `schema_version` | string | Always `"1.0"` for the current format |
+| `revision` | number | Incremented on every write — used for optimistic concurrency control |
+| `last_updated` | ISO-8601 | Timestamp of the most recent mutation |
+| `next_id` | number | Auto-increment counter for new ticket IDs |
+| `tickets` | object | Map of ticket ID (as string) → ticket object |
+
+**Ticket fields**
+
+| Field | Type | Values | Description |
+|-------|------|--------|-------------|
+| `id` | number | Auto-assigned | Numeric ID, referenced as `#<id>` |
+| `title` | string | — | Short title |
+| `description` | string | Markdown | Full description |
+| `status` | string | `todo`, `in_progress`, `done`, `cancelled` | Current state |
+| `priority` | string | `critical`, `high`, `medium`, `low` | Priority level |
+| `labels` | string[] | Freeform | Tag strings; convention: `area:*`, `effort:*` |
+| `assignee` | string\|null | — | Agent name or user, if assigned |
+| `prerequisites` | number[] | — | IDs of tickets that must be done first |
+| `metadata` | object | — | VPC scores, effort level, user story, area (set by agents) |
+| `comments` | array | — | Progress notes appended during implementation |
+| `created_at` | ISO-8601 | — | Creation timestamp |
+| `updated_at` | ISO-8601 | — | Last mutation timestamp |
+| `created_by` | string | — | Agent name or `"user"` |
+| `source` | string | `manual`, `product-backlog`, `propose-spec` | How the ticket was created |
+
+---
+
+## Setup
+
+Local tickets become the default during `/setup`. The wizard prompts:
+
+```
+## Backlog Provider
+
+Use local ticket management or connect an external provider?
+
+1. Local tickets (default, recommended) — lightweight JSON-based ticket management.
+   No external tools or accounts required.
+2. External provider — connect GitHub Issues, JIRA, or disable backlog commands
+```
+
+Pressing **Enter** or selecting **1** initializes `.claude/local-tickets.json` with an empty ticket store and writes `.claude/backlog-config.json`:
+
+```json
+{
+  "provider": "local",
+  "write_access": true,
+  "git_auto": true
+}
+```
+
+To switch providers later, re-run the setup wizard:
+
+```bash
+npx specrails-core@latest init --root-dir .
+> /setup
+```
+
+---
+
+## Concurrency model
+
+Multiple agents can modify `local-tickets.json` simultaneously. The system uses two complementary mechanisms:
+
+### Advisory file lock
+
+Before every write, the agent creates `.claude/local-tickets.json.lock`:
+
+```json
+{
+  "agent": "sr-product-manager",
+  "timestamp": "2026-03-23T10:00:00.000Z"
+}
+```
+
+If the lock file already exists:
+- **Fresh lock** (< 30 seconds old): wait 500 ms and retry, up to 5 attempts
+- **Stale lock** (≥ 30 seconds old): treat as orphaned, delete it, proceed
+
+The lock is deleted immediately after the write completes. The window is minimal: read → modify in memory → write → release.
+
+### Revision counter
+
+Every write increments `revision`. Readers that want to detect external changes compare the `revision` they last saw against the current value.
+
+---
+
+## Command integration
+
+### `/sr:implement`
+
+Pass local ticket IDs the same way you would GitHub issue numbers:
+
+```bash
+/sr:implement #1, #4, #7
+```
+
+The command reads each ticket from `local-tickets.json`, extracts metadata (area, effort, description), and tracks the ticket through the pipeline — updating status to `in_progress` on start and `done` on successful completion.
+
+### `/sr:product-backlog`
+
+```bash
+/sr:product-backlog              # all areas
+/sr:product-backlog UI, Backend  # filter by area
+```
+
+Reads all `todo` and `in_progress` tickets, scores them by VPC match, respects the `prerequisites` dependency graph, and recommends the top 3 for your next sprint.
+
+### `/sr:update-product-driven-backlog`
+
+```bash
+/sr:update-product-driven-backlog            # explore all areas
+/sr:update-product-driven-backlog Analytics  # focus on one area
+```
+
+Runs product discovery using your VPC personas. Creates new local tickets for discovered feature ideas, tagged with `source: "product-backlog"` and `labels: ["product-driven-backlog", "area:<area>"]`. Existing tickets are checked for duplicates before creating new ones.
+
+### `/sr:propose-spec`
+
+When a proposal is finalized, a local ticket is created automatically:
+
+```
+Created local ticket #12: Add analytics export
+```
+
+The ticket captures the full proposal as its description and is tagged `source: "propose-spec"` with the label `spec-proposal`.
+
+---
+
+## Migrating from GitHub Issues or JIRA
+
+See the [Migration Guide](./migration-guide.md).

package/docs/migration-guide.md

@@ -0,0 +1,140 @@
+# Migration Guide: Switching to Local Tickets
+
+This guide is for teams currently using GitHub Issues or JIRA as their specrails backlog provider who want to switch to the built-in local ticket system.
+
+Switching is optional. GitHub Issues and JIRA remain fully supported. Local tickets are the recommended default for new projects.
+
+---
+
+## Should you switch?
+
+**Switch to local tickets if:**
+- Your team prefers a simple, zero-dependency setup
+- You want tickets version-controlled alongside your code
+- You don't need GitHub/JIRA for other workflows (project boards, external stakeholders)
+
+**Stay on GitHub Issues / JIRA if:**
+- Other teams or stakeholders manage tickets in those tools
+- You rely on GitHub Projects, Milestones, or JIRA sprints
+- You want PR auto-close on issue merge (requires GitHub Issues)
+
+---
+
+## Step 1: Switch the provider
+
+Edit `.claude/backlog-config.json` in your project root:
+
+```json
+{
+  "provider": "local",
+  "write_access": true,
+  "git_auto": true
+}
+```
+
+Then initialize the ticket store if it doesn't exist yet:
+
+```bash
+# Inside Claude Code or Codex
+/sr:implement --setup-local-tickets
+```
+
+Or create the file manually:
+
+```bash
+cat > .claude/local-tickets.json << 'EOF'
+{
+  "schema_version": "1.0",
+  "revision": 0,
+  "last_updated": null,
+  "next_id": 1,
+  "tickets": {}
+}
+EOF
+```
+
+---
+
+## Step 2: Import existing issues (one-time migration)
+
+### From GitHub Issues
+
+Use the `sr:migrate-from-github` command (requires `gh` CLI):
+
+```bash
+# Inside Claude Code
+/sr:migrate-from-github
+```
+
+This command:
+1. Fetches all open issues labeled `product-driven-backlog` (the label specrails uses)
+2. Maps GitHub issue fields to local ticket schema:
+   - `number` → `id` (uses next available local ID)
+   - `title` → `title`
+   - `body` → `description`
+   - `labels` → `labels`
+   - `state: open` → `status: todo`
+3. Writes each ticket to `local-tickets.json`
+4. Prints a summary: `Imported 14 tickets from GitHub Issues`
+
+To import all open issues regardless of label:
+
+```bash
+/sr:migrate-from-github --all
+```
+
+To do a dry run (preview without writing):
+
+```bash
+/sr:migrate-from-github --dry-run
+```
+
+**After import:** Your GitHub Issues are unchanged. The migration is additive — it only creates local tickets. You can continue using GitHub Issues in parallel until you're ready to stop.
+
+### From JIRA
+
+Use the `sr:migrate-from-jira` command (requires `jira` CLI or REST API credentials in `.claude/backlog-config.json`):
+
+```bash
+# Inside Claude Code
+/sr:migrate-from-jira
+```
+
+This command:
+1. Fetches all open issues from the configured JIRA project
+2. Maps JIRA fields to local ticket schema:
+   - Issue key (`PROJECT-123`) → stored in `metadata.jira_key`
+   - `summary` → `title`
+   - `description` → `description`
+   - `priority` → `priority` (Critical/High/Medium/Low mapped directly)
+   - `status: To Do / Backlog` → `status: todo`
+   - `status: In Progress` → `status: in_progress`
+   - `labels` → `labels`
+3. Writes each ticket to `local-tickets.json`
+
+The original JIRA key is preserved in `metadata.jira_key` so you can cross-reference during the transition.
+
+---
+
+## Step 3: Regenerate commands (optional but recommended)
+
+Command templates are generated at `/setup` time with provider-specific instructions baked in. After switching providers, regenerate them so commands use the local file operations instead of GitHub/JIRA CLI calls:
+
+```bash
+npx specrails-core@latest init --root-dir .
+> /setup --update
+```
+
+The `--update` flag regenerates only the backlog commands (`product-backlog`, `update-product-driven-backlog`, `implement`) without re-running the full stack analysis.
+
+---
+
+## Rollback
+
+To revert to GitHub Issues:
+
+1. Edit `.claude/backlog-config.json` and set `"provider": "github"`
+2. Re-run `/setup --update` to regenerate commands
+3. Your `local-tickets.json` is preserved — switch back any time
+
+Local tickets and external provider data are independent. Switching providers does not delete tickets from either system.

package/docs/testing/test-matrix-codex.md

@@ -40,7 +40,6 @@ Epic: [SPEA-505](/SPEA/issues/SPEA-505) — Codex Compatibility Approach B
 | SKILL.md format `.claude/skills/sr-*/` | ✅ | ✅ |
 | `sr:implement` skill | ✅ | ✅ |
 | `sr:product-backlog` skill | ✅ | ✅ |
-| `sr:health-check` skill | ✅ | ✅ |
 | `sr:compat-check` skill | ✅ | ✅ |
 | `sr:why` skill | ✅ | ✅ |
 | `sr:refactor-recommender` skill | ✅ | ✅ |

package/docs/user-docs/cli-reference.md

@@ -174,18 +174,6 @@ The Product Manager researches your competitive landscape, generates 2–4 featu
 
 ## Analysis and inspection
 
-### `/sr:health-check` ✅ Both
-
-Run a comprehensive codebase quality analysis.
-
-```
-/sr:health-check
-```
-
-Analyzes code quality, test coverage, technical debt, complexity, and dependency health. Compares with previous runs to detect regressions.
-
----
-
 ### `/sr:refactor-recommender` ✅ Both
 
 Scan the codebase for refactoring opportunities, ranked by impact/effort ratio.

package/docs/user-docs/codex-vs-claude-code.md

@@ -31,7 +31,6 @@ SpecRails Skills use `SKILL.md` format, which is shared between Codex and Claude
 
 - `/sr:implement` — full pipeline (design → code → review → PR)
 - `/sr:product-backlog` — VPC-ranked backlog view
-- `/sr:health-check` — codebase quality analysis
 - `/opsx:ff` — OpenSpec fast-forward
 - All other workflow skills
 

package/docs/user-docs/faq.md

@@ -14,17 +14,20 @@ It creates a `.claude/` directory with agent templates, commands, and configurat
 
 Yes. Node 18+ is required to run `npx specrails-core@latest`. Once installed, SpecRails works with any language or framework — the agents adapt to whatever stack your project uses.
 
-**Can I run SpecRails on a project that doesn't have GitHub Issues?**
+**Do I need GitHub Issues?**
 
-Yes. During `/setup`, you can choose "none" as your backlog provider. Commands like `/sr:implement` will accept plain text descriptions instead of issue numbers:
+No. SpecRails ships with a built-in local ticket system — no GitHub account required. Local tickets are the default. Commands like `/sr:implement` accept ticket IDs or plain text:
 
 ```
+/sr:implement #1, #4
 /sr:implement "add rate limiting to the API"
 ```
 
+You can switch to GitHub Issues or JIRA during `/setup` (Phase 3) if you prefer.
+
 **How long does /setup take?**
 
-About 5 minutes. Most of the time is spent on Phase 2 (persona generation), which does web research on your domain.
+The full wizard takes about 5 minutes — most of the time is Phase 2 (persona research via web search). For a faster start, use `/setup --lite`: three questions, under a minute, no web research.
 
 ---
 

package/docs/user-docs/installation.md

@@ -4,6 +4,8 @@ Install SpecRails into any git repository in two steps: run the installer, then
 
 SpecRails supports both **Claude Code** and **OpenAI Codex**. The installer detects which CLI you have and configures accordingly. See [Codex vs Claude Code](codex-vs-claude-code.md) for a feature comparison.
 
+> **Looking for the comprehensive reference?** See [Installation & Setup](../installation.md) for full wizard phase details and advanced configuration.
+
 ## Requirements
 
 | Tool | Version | Notes |
@@ -63,7 +65,6 @@ your-project/
     ├── skills/                   # Workflow skills (/sr:*, /opsx:*)
     ├── agents/                   # Agent definitions
     ├── rules/                    # Per-layer coding conventions
-    ├── web-manager/              # Pipeline Monitor dashboard (optional)
     └── settings.json             # Permissions
 ```
 
@@ -95,7 +96,7 @@ codex     # Codex
 /setup
 ```
 
-The wizard runs 5 phases:
+By default, `/setup` runs the full 5-phase wizard:
 
 | Phase | What happens |
 |-------|-------------|
@@ -105,6 +106,8 @@ The wizard runs 5 phases:
 | **4. Generate** | Fills all templates with your project-specific context |
 | **5. Cleanup** | Removes setup files, leaving only your tailored workflow |
 
+**In a hurry?** Run `/setup --lite` instead — three questions, sensible defaults, done in under a minute.
+
 After setup, `.claude/` contains fully configured agents and commands ready to use. The `/setup` command removes itself — it only runs once.
 
 ## Verify
@@ -181,4 +184,4 @@ npx specrails-core@latest init --root-dir . --provider codex
 
 ---
 
-[Quick Start →](quick-start.md) · [Getting Started (Codex) →](getting-started-codex.md) · [CLI Reference →](cli-reference.md)
+[← Getting Started](../getting-started.md) · [Quick Start →](quick-start.md) · [Getting Started (Codex) →](getting-started-codex.md) · [CLI Reference →](cli-reference.md)

package/docs/user-docs/quick-start.md

@@ -46,7 +46,7 @@ Then run:
 /setup
 ```
 
-The wizard runs automatically and takes about 5 minutes. It analyzes your codebase and configures SpecRails for your specific project:
+The wizard runs the full 5-phase setup (about 5 minutes). It analyzes your codebase and configures SpecRails for your specific project:
 
 ```
 Phase 1/5  Analyzing codebase...
@@ -59,14 +59,14 @@ Phase 2/5  Generating user personas...
            → Created 3 VPC profiles
 
 Phase 3/5  Configuration...
-           → Backlog provider: GitHub Issues
+           → Backlog provider: local
            → Git workflow: trunk-based
 
 Phase 4/5  Generating files...
            → sr-architect.md (adapted to your stack)
            → sr-developer.md (knows your CI commands)
            → sr-reviewer.md (runs your specific checks)
-           → 9 more agents
+           → 11 more agents
 
 Phase 5/5  Cleanup complete. /setup removed.
 
@@ -75,6 +75,8 @@ Phase 5/5  Cleanup complete. /setup removed.
 
 After setup, the `/setup` command is gone — it's a one-time wizard.
 
+**In a hurry?** Use `/setup --lite` for a 3-question quick setup (under a minute). You can always run the full wizard later.
+
 ## Step 3: Implement your first feature
 
 Pick something small. Either reference a GitHub Issue or describe it in plain text:
@@ -129,7 +131,7 @@ One command. The PR is ready for human review.
 /sr:product-backlog
 ```
 
-See your GitHub Issues ranked by persona fit and effort. The top 3 are safe to implement next.
+See your tickets ranked by persona fit and effort. The top 3 are safe to implement next. Uses local tickets by default.
 
 **Generate new feature ideas:**
 
@@ -137,7 +139,7 @@ See your GitHub Issues ranked by persona fit and effort. The top 3 are safe to i
 /sr:update-product-driven-backlog
 ```
 
-The Product Manager researches your competitive landscape and creates well-formed GitHub Issues for new features.
+The Product Manager researches your competitive landscape and creates new tickets (local by default, or GitHub Issues if configured).
 
 **Run multiple features in parallel:**
 
@@ -157,4 +159,4 @@ Agents record their reasoning as they work. `/sr:why` searches those records in
 
 ---
 
-[← Installation](installation.md) · [CLI Reference →](cli-reference.md) · [FAQ →](faq.md)
+[← Getting Started](../getting-started.md) · [← Installation](installation.md) · [CLI Reference →](cli-reference.md) · [FAQ →](faq.md)

package/docs/workflows.md

@@ -126,7 +126,7 @@ View your prioritized product backlog, ranked by VPC fit and effort.
 
 ### What it shows
 
-The Product Analyst reads your GitHub Issues (labeled `product-driven-backlog`) and produces:
+The Product Analyst reads your backlog (local tickets in `.claude/local-tickets.json` by default, or GitHub Issues labeled `product-driven-backlog` if configured) and produces:
 
 - **Backlog table** per area — sorted by Total Persona Score
 - **Top 3 recommendations** — ranked by VPC score / effort ratio, filtered to Wave 1 of the safe implementation order
@@ -166,19 +166,7 @@ Generate new feature ideas through product discovery. The Product Manager (Opus)
 2. Researches competitors via web search
 3. Generates 2–4 feature ideas per area
 4. Scores each against every persona (0–5)
-5. Creates GitHub Issues (if write access) or displays for manual creation
-
----
-
-## `/sr:health-check`
-
-Run a comprehensive codebase quality analysis.
-
-```
-/sr:health-check
-```
-
-Analyzes code quality, test coverage, technical debt, and dependency health. Compares with previous runs to detect regressions.
+5. Creates tickets in your active backlog provider (local tickets by default; GitHub Issues or JIRA if configured) or displays for manual creation
 
 ---