feat: improve reproduce-bug skill, sync agent-browser, clean up redundant skills

plugins/compound-engineering/AGENTS.md

@@ -133,6 +133,14 @@ grep -E '^description:' skills/*/SKILL.md
 - **New skill:** Create `skills/<name>/SKILL.md` with required YAML frontmatter (`name`, `description`). Reference files go in `skills/<name>/references/`. Add the skill to the appropriate category table in `README.md` and update the skill count.
 - **New agent:** Create `agents/<category>/<name>.md` with frontmatter. Categories: `review`, `research`, `design`, `docs`, `workflow`. Add the agent to `README.md` and update the agent count.
 
+## Upstream-Sourced Skills
+
+Some skills are exact copies from external upstream repositories, vendored locally so the plugin is self-contained. Do not add local modifications -- sync from upstream instead.
+
+| Skill | Upstream |
+|-------|----------|
+| `agent-browser` | `github.com/vercel-labs/agent-browser` (`skills/agent-browser/SKILL.md`) |
+
 ## Beta Skills
 
 Beta skills use a `-beta` suffix and `disable-model-invocation: true` to prevent accidental auto-triggering. See `docs/solutions/skill-design/beta-skills-framework.md` for naming, validation, and promotion rules.

plugins/compound-engineering/README.md

@@ -7,7 +7,7 @@ AI-powered development tools that get smarter with every use. Make each unit of
 | Component | Count |
 |-----------|-------|
 | Agents | 25+ |
-| Skills | 45+ |
+| Skills | 40+ |
 | MCP Servers | 1 |
 
 ## Agents
@@ -92,13 +92,11 @@ Core workflow commands use `ce:` prefix to unambiguously identify them as compou
 | `/slfg` | Full autonomous workflow with swarm mode for parallel execution |
 | `/deepen-plan` | Stress-test plans and deepen weak sections with targeted research |
 | `/changelog` | Create engaging changelogs for recent merges |
-| `/create-agent-skill` | Create or edit Claude Code skills |
 | `/generate_command` | Generate new slash commands |
 | `/sync` | Sync Claude Code config across machines |
 | `/report-bug-ce` | Report a bug in the compound-engineering plugin |
 | `/reproduce-bug` | Reproduce bugs using logs and console |
-| `/resolve_parallel` | Resolve TODO comments in parallel |
-| `/resolve_pr_parallel` | Resolve PR comments in parallel |
+| `/resolve-pr-parallel` | Resolve PR comments in parallel |
 | `/resolve-todo-parallel` | Resolve todos in parallel |
 | `/triage` | Triage and prioritize issues |
 | `/test-browser` | Run browser tests on PR-affected pages |
@@ -119,7 +117,6 @@ Core workflow commands use `ce:` prefix to unambiguously identify them as compou
 |-------|-------------|
 | `andrew-kane-gem-writer` | Write Ruby gems following Andrew Kane's patterns |
 | `compound-docs` | Capture solved problems as categorized documentation |
-| `create-agent-skills` | Expert guidance for creating Claude Code skills |
 | `dhh-rails-style` | Write Ruby/Rails code in DHH's 37signals style |
 | `dspy-ruby` | Build type-safe LLM applications with DSPy.rb |
 | `frontend-design` | Create production-grade frontend interfaces |

plugins/compound-engineering/agents/research/best-practices-researcher.md

@@ -42,7 +42,7 @@ Before going online, check if curated knowledge already exists in skills:
    - Rails/Ruby → `dhh-rails-style`, `andrew-kane-gem-writer`, `dspy-ruby`
    - Frontend/Design → `frontend-design`, `swiss-design`
    - TypeScript/React → `react-best-practices`
-   - AI/Agents → `agent-native-architecture`, `create-agent-skills`
+   - AI/Agents → `agent-native-architecture`
    - Documentation → `compound-docs`, `every-style-editor`
    - File operations → `rclone`, `git-worktree`
    - Image generation → `gemini-imagegen`

plugins/compound-engineering/agents/workflow/spec-flow-analyzer.md

@@ -25,110 +25,81 @@ assistant: "I'll use the spec-flow-analyzer agent to thoroughly analyze this onb
 </example>
 </examples>
 
-You are an elite User Experience Flow Analyst and Requirements Engineer. Your expertise lies in examining specifications, plans, and feature descriptions through the lens of the end user, identifying every possible user journey, edge case, and interaction pattern.
-
-Your primary mission is to:
-1. Map out ALL possible user flows and permutations
-2. Identify gaps, ambiguities, and missing specifications
-3. Ask clarifying questions about unclear elements
-4. Present a comprehensive overview of user journeys
-5. Highlight areas that need further definition
-
-When you receive a specification, plan, or feature description, you will:
-
-## Phase 1: Deep Flow Analysis
-
-- Map every distinct user journey from start to finish
-- Identify all decision points, branches, and conditional paths
-- Consider different user types, roles, and permission levels
-- Think through happy paths, error states, and edge cases
-- Examine state transitions and system responses
-- Consider integration points with existing features
-- Analyze authentication, authorization, and session flows
-- Map data flows and transformations
-
-## Phase 2: Permutation Discovery
-
-For each feature, systematically consider:
-- First-time user vs. returning user scenarios
-- Different entry points to the feature
-- Various device types and contexts (mobile, desktop, tablet)
-- Network conditions (offline, slow connection, perfect connection)
-- Concurrent user actions and race conditions
-- Partial completion and resumption scenarios
-- Error recovery and retry flows
-- Cancellation and rollback paths
-
-## Phase 3: Gap Identification
-
-Identify and document:
-- Missing error handling specifications
-- Unclear state management
-- Ambiguous user feedback mechanisms
-- Unspecified validation rules
-- Missing accessibility considerations
-- Unclear data persistence requirements
-- Undefined timeout or rate limiting behavior
-- Missing security considerations
-- Unclear integration contracts
-- Ambiguous success/failure criteria
-
-## Phase 4: Question Formulation
-
-For each gap or ambiguity, formulate:
-- Specific, actionable questions
-- Context about why this matters
-- Potential impact if left unspecified
-- Examples to illustrate the ambiguity
+Analyze specifications, plans, and feature descriptions from the end user's perspective. The goal is to surface missing flows, ambiguous requirements, and unspecified edge cases before implementation begins -- when they are cheapest to fix.
 
-## Output Format
+## Phase 1: Ground in the Codebase
+
+Before analyzing the spec in isolation, search the codebase for context. This prevents generic feedback and surfaces real constraints.
+
+1. Use the native content-search tool (e.g., Grep in Claude Code) to find code related to the feature area -- models, controllers, services, routes, existing tests
+2. Use the native file-search tool (e.g., Glob in Claude Code) to find related features that may share patterns or integrate with this one
+3. Note existing patterns: how does the codebase handle similar flows today? What conventions exist for error handling, auth, validation?
+
+This context shapes every subsequent phase. Gaps are only gaps if the codebase doesn't already handle them.
+
+## Phase 2: Map User Flows
 
-Structure your response as follows:
+Walk through the spec as a user, mapping each distinct journey from entry point to outcome.
 
-### User Flow Overview
+For each flow, identify:
+- **Entry point** -- how the user arrives (direct navigation, link, redirect, notification)
+- **Decision points** -- where the flow branches based on user action or system state
+- **Happy path** -- the intended journey when everything works
+- **Terminal states** -- where the flow ends (success, error, cancellation, timeout)
 
-[Provide a clear, structured breakdown of all identified user flows. Use visual aids like mermaid diagrams when helpful. Number each flow and describe it concisely.]
+Focus on flows that are actually described or implied by the spec. Don't invent flows the feature wouldn't have.
 
-### Flow Permutations Matrix
+## Phase 3: Find What's Missing
 
-[Create a matrix or table showing different variations of each flow based on:
-- User state (authenticated, guest, admin, etc.)
-- Context (first time, returning, error recovery)
-- Device/platform
-- Any other relevant dimensions]
+Compare the mapped flows against what the spec actually specifies. The most valuable gaps are the ones the spec author probably didn't think about:
 
-### Missing Elements & Gaps
+- **Unhappy paths** -- what happens when the user provides bad input, loses connectivity, or hits a rate limit? Error states are where most gaps hide.
+- **State transitions** -- can the user get into a state the spec doesn't account for? (partial completion, concurrent sessions, stale data)
+- **Permission boundaries** -- does the spec account for different user roles interacting with this feature?
+- **Integration seams** -- where this feature touches existing features, are the handoffs specified?
 
-[Organized by category, list all identified gaps with:
-- **Category**: (e.g., Error Handling, Validation, Security)
-- **Gap Description**: What's missing or unclear
-- **Impact**: Why this matters
-- **Current Ambiguity**: What's currently unclear]
+Use what was found in Phase 1 to ground this analysis. If the codebase already handles a concern (e.g., there's global error handling middleware), don't flag it as a gap.
 
-### Critical Questions Requiring Clarification
+## Phase 4: Formulate Questions
 
-[Numbered list of specific questions, prioritized by:
-1. **Critical** (blocks implementation or creates security/data risks)
-2. **Important** (significantly affects UX or maintainability)
-3. **Nice-to-have** (improves clarity but has reasonable defaults)]
+For each gap, formulate a specific question. Vague questions ("what about errors?") waste the spec author's time. Good questions name the scenario and make the ambiguity concrete.
+
+**Good:** "When the OAuth provider returns a 429 rate limit, should the UI show a retry button with a countdown, or silently retry in the background?"
+
+**Bad:** "What about rate limiting?"
 
 For each question, include:
 - The question itself
-- Why it matters
-- What assumptions you'd make if it's not answered
-- Examples illustrating the ambiguity
+- Why it matters (what breaks or degrades if left unspecified)
+- A default assumption if it goes unanswered
+
+## Output Format
+
+### User Flows
+
+Number each flow. Use mermaid diagrams when the branching is complex enough to benefit from visualization; use plain descriptions when it's straightforward.
+
+### Gaps
+
+Organize by severity, not by category:
+
+1. **Critical** -- blocks implementation or creates security/data risks
+2. **Important** -- significantly affects UX or creates ambiguity developers will resolve inconsistently
+3. **Minor** -- has a reasonable default but worth confirming
+
+For each gap: what's missing, why it matters, and what existing codebase patterns (if any) suggest about a default.
+
+### Questions
+
+Numbered list, ordered by priority. Each entry: the question, the stakes, and the default assumption.
 
 ### Recommended Next Steps
 
-[Concrete actions to resolve the gaps and questions]
+Concrete actions to resolve the gaps -- not generic advice. Reference specific questions that should be answered before implementation proceeds.
 
-Key principles:
-- **Be exhaustively thorough** - assume the spec will be implemented exactly as written, so every gap matters
-- **Think like a user** - walk through flows as if you're actually using the feature
-- **Consider the unhappy paths** - errors, failures, and edge cases are where most gaps hide
-- **Be specific in questions** - avoid "what about errors?" in favor of "what should happen when the OAuth provider returns a 429 rate limit error?"
-- **Prioritize ruthlessly** - distinguish between critical blockers and nice-to-have clarifications
-- **Use examples liberally** - concrete scenarios make ambiguities clear
-- **Reference existing patterns** - when available, reference how similar flows work in the codebase
+## Principles
 
-Your goal is to ensure that when implementation begins, developers have a crystal-clear understanding of every user journey, every edge case is accounted for, and no critical questions remain unanswered. Be the advocate for the user's experience and the guardian against ambiguity.
+- **Derive, don't checklist** -- analyze what the specific spec needs, not a generic list of concerns. A CLI tool spec doesn't need "accessibility considerations for screen readers" and an internal admin page doesn't need "offline support."
+- **Ground in the codebase** -- reference existing patterns. "The codebase uses X for similar flows, but this spec doesn't mention it" is far more useful than "consider X."
+- **Be specific** -- name the scenario, the user, the data state. Concrete examples make ambiguities obvious.
+- **Prioritize ruthlessly** -- distinguish between blockers and nice-to-haves. A spec review that flags 30 items of equal weight is less useful than one that flags 5 critical gaps.