@bugzy-ai/bugzy 1.5.0 → 1.7.0

package/dist/tasks/index.cjs

@@ -22,800 +22,36 @@ var tasks_exports = {};
 __export(tasks_exports, {
   TASK_SLUGS: () => TASK_SLUGS,
   TASK_TEMPLATES: () => TASK_TEMPLATES,
-  buildSlashCommandsConfig: () => buildSlashCommandsConfig,
   getAllTaskSlugs: () => getAllTaskSlugs,
-  getRequiredMCPsFromTasks: () => getRequiredMCPsFromTasks,
   getTaskTemplate: () => getTaskTemplate,
+  isInlineStep: () => isInlineStep,
+  isStepReferenceObject: () => isStepReferenceObject,
   isTaskRegistered: () => isTaskRegistered
 });
 module.exports = __toCommonJS(tasks_exports);
 
+// src/tasks/steps/types.ts
+function isInlineStep(ref) {
+  return typeof ref === "object" && "inline" in ref && ref.inline === true;
+}
+function isStepReferenceObject(ref) {
+  return typeof ref === "object" && "stepId" in ref;
+}
+
 // src/tasks/constants.ts
 var TASK_SLUGS = {
   EXPLORE_APPLICATION: "explore-application",
+  ONBOARD_TESTING: "onboard-testing",
   GENERATE_TEST_CASES: "generate-test-cases",
   GENERATE_TEST_PLAN: "generate-test-plan",
   HANDLE_MESSAGE: "handle-message",
   PROCESS_EVENT: "process-event",
   RUN_TESTS: "run-tests",
-  VERIFY_CHANGES: "verify-changes"
+  VERIFY_CHANGES: "verify-changes",
+  /** @deprecated Use ONBOARD_TESTING instead */
+  FULL_TEST_COVERAGE: "onboard-testing"
 };
 
-// src/tasks/templates/exploration-instructions.ts
-var EXPLORATION_INSTRUCTIONS = `
-## Exploratory Testing Protocol
-
-Before creating or running formal tests, perform exploratory testing to validate requirements and understand actual system behavior. The depth of exploration should adapt to the clarity of requirements.
-
-### Step {{STEP_NUMBER}}.1: Assess Requirement Clarity
-
-Determine exploration depth based on requirement quality:
-
-| Clarity | Indicators | Exploration Depth | Goal |
-|---------|-----------|-------------------|------|
-| **Clear** | Detailed acceptance criteria, screenshots/mockups, specific field names/URLs/roles, unambiguous behavior, consistent patterns | Quick (1-2 min) | Confirm feature exists, capture evidence |
-| **Vague** | General direction clear but specifics missing, incomplete examples, assumed details, relative terms ("fix", "better") | Moderate (3-5 min) | Document current behavior, identify ambiguities, generate clarification questions |
-| **Unclear** | Contradictory info, multiple interpretations, no examples/criteria, ambiguous scope ("the page"), critical details missing | Deep (5-10 min) | Systematically test scenarios, document patterns, identify all ambiguities, formulate comprehensive questions |
-
-**Examples:**
-- **Clear:** "Change 'Submit' button from blue (#007BFF) to green (#28A745) on /auth/login. Verify hover effect."
-- **Vague:** "Fix the sorting in todo list page. The items are mixed up for premium users."
-- **Unclear:** "Improve the dashboard performance. Users say it's slow."
-
-### Step {{STEP_NUMBER}}.2: Quick Exploration (1-2 min)
-
-**When:** Requirements CLEAR
-
-**Steps:**
-1. Navigate to feature (use provided URL), verify loads without errors
-2. Verify key elements exist (buttons, fields, sections mentioned)
-3. Capture screenshot of initial state
-4. Document:
-   \`\`\`markdown
-   **Quick Exploration (1 min)**
-   Feature: [Name] | URL: [Path]
-   Status: \u2705 Accessible / \u274C Not found / \u26A0\uFE0F Different
-   Screenshot: [filename]
-   Notes: [Immediate observations]
-   \`\`\`
-5. **Decision:** \u2705 Matches \u2192 Test creation | \u274C/\u26A0\uFE0F Doesn't match \u2192 Moderate Exploration
-
-**Time Limit:** 1-2 minutes
-
-### Step {{STEP_NUMBER}}.3: Moderate Exploration (3-5 min)
-
-**When:** Requirements VAGUE or Quick Exploration revealed discrepancies
-
-**Steps:**
-1. Navigate using appropriate role(s), set up preconditions, ensure clean state
-2. Test primary user flow, document steps and behavior, note unexpected behavior
-3. Capture before/after screenshots, document field values/ordering/visibility
-4. Compare to requirement: What matches? What differs? What's absent?
-5. Identify specific ambiguities:
-   \`\`\`markdown
-   **Moderate Exploration (4 min)**
-
-   **Explored:** Role: [Admin], Path: [Steps], Behavior: [What happened]
-
-   **Current State:** [Specific observations with examples]
-   - Example: "Admin view shows 8 sort options: By Title, By Due Date, By Priority..."
-
-   **Requirement Says:** [What requirement expected]
-
-   **Discrepancies:** [Specific differences]
-   - Example: "Premium users see 5 fewer sorting options than admins"
-
-   **Ambiguities:**
-   1. [First ambiguity with concrete example]
-   2. [Second if applicable]
-
-   **Clarification Needed:** [Specific questions]
-   \`\`\`
-6. Assess severity using Clarification Protocol
-7. **Decision:** \u{1F7E2} Minor \u2192 Proceed with assumptions | \u{1F7E1} Medium \u2192 Async clarification, proceed | \u{1F534} Critical \u2192 Stop, escalate
-
-**Time Limit:** 3-5 minutes
-
-### Step {{STEP_NUMBER}}.4: Deep Exploration (5-10 min)
-
-**When:** Requirements UNCLEAR or critical ambiguities found
-
-**Steps:**
-1. **Define Exploration Matrix:** Identify dimensions (user roles, feature states, input variations, browsers)
-
-2. **Systematic Testing:** Test each matrix cell methodically
-   \`\`\`
-   Example for "Todo List Sorting":
-   Matrix: User Roles \xD7 Feature Observations
-
-   Test 1: Admin Role \u2192 Navigate, document sort options (count, names, order), screenshot
-   Test 2: Basic User Role \u2192 Same todo list, document options, screenshot
-   Test 3: Compare \u2192 Side-by-side table, identify missing/reordered options
-   \`\`\`
-
-3. **Document Patterns:** Consistent behavior? Role-based differences? What varies vs constant?
-
-4. **Comprehensive Report:**
-   \`\`\`markdown
-   **Deep Exploration (8 min)**
-
-   **Matrix:** [Dimensions] | **Tests:** [X combinations]
-
-   **Findings:**
-
-   ### Test 1: Admin
-   - Setup: [Preconditions] | Steps: [Actions]
-   - Observations: Sort options=8, Options=[list], Ordering=[sequence]
-   - Screenshot: [filename-admin.png]
-
-   ### Test 2: Basic User
-   - Setup: [Preconditions] | Steps: [Actions]
-   - Observations: Sort options=3, Missing vs Admin=[5 options], Ordering=[sequence]
-   - Screenshot: [filename-user.png]
-
-   **Comparison Table:**
-   | Sort Option | Admin Pos | User Pos | Notes |
-   |-------------|-----------|----------|-------|
-   | By Title | 1 | 1 | Match |
-   | By Priority | 3 | Not visible | Missing |
-
-   **Patterns:**
-   - Role-based feature visibility
-   - Consistent relative ordering for visible fields
-
-   **Critical Ambiguities:**
-   1. Option Visibility: Intentional basic users see 5 fewer sort options?
-   2. Sort Definition: (A) All roles see all options in same order, OR (B) Roles see permitted options in same relative order?
-
-   **Clarification Questions:** [Specific, concrete based on findings]
-   \`\`\`
-
-5. **Next Action:** Critical ambiguities \u2192 STOP, clarify | Patterns suggest answer \u2192 Validate assumption | Behavior clear \u2192 Test creation
-
-**Time Limit:** 5-10 minutes
-
-### Step {{STEP_NUMBER}}.5: Link Exploration to Clarification
-
-**Flow:** Requirement Analysis \u2192 Exploration \u2192 Clarification
-
-1. Requirement analysis detects vague language \u2192 Triggers exploration
-2. Exploration documents current behavior \u2192 Identifies discrepancies
-3. Clarification uses findings \u2192 Asks specific questions referencing observations
-
-**Example:**
-\`\`\`
-"Fix the sorting in todo list"
-  \u2193 Ambiguity: "sorting" = by date, priority, or completion status?
-  \u2193 Moderate Exploration: Admin=8 sort options, User=3 sort options
-  \u2193 Question: "Should basic users see all 8 sort options (bug) or only 3 with consistent sequence (correct)?"
-\`\`\`
-
-### Step {{STEP_NUMBER}}.6: Document Exploration Results
-
-**Template:**
-\`\`\`markdown
-## Exploration Summary
-
-**Date:** [YYYY-MM-DD] | **Explorer:** [Agent/User] | **Depth:** [Quick/Moderate/Deep] | **Duration:** [X min]
-
-### Feature: [Name and description]
-
-### Observations: [Key findings]
-
-### Current Behavior: [What feature does today]
-
-### Discrepancies: [Requirement vs observation differences]
-
-### Assumptions Made: [If proceeding with assumptions]
-
-### Artifacts: Screenshots: [list], Video: [if captured], Notes: [detailed]
-\`\`\`
-
-**Memory Storage:** Feature behavior patterns, common ambiguity types, resolution approaches
-
-### Step {{STEP_NUMBER}}.7: Integration with Test Creation
-
-**Quick Exploration \u2192 Direct Test:**
-- Feature verified \u2192 Create test matching requirement \u2192 Reference screenshot
-
-**Moderate Exploration \u2192 Assumption-Based Test:**
-- Document behavior \u2192 Create test on best interpretation \u2192 Mark assumptions \u2192 Plan updates after clarification
-
-**Deep Exploration \u2192 Clarification-First:**
-- Block test creation until clarification \u2192 Use exploration as basis for questions \u2192 Create test after answer \u2192 Reference both exploration and clarification
-
----
-
-## Adaptive Exploration Decision Tree
-
-\`\`\`
-Start: Requirement Received
-    \u2193
-Are requirements clear with specifics?
-    \u251C\u2500 YES \u2192 Quick Exploration (1-2 min)
-    \u2502         \u2193
-    \u2502      Does feature match description?
-    \u2502         \u251C\u2500 YES \u2192 Proceed to Test Creation
-    \u2502         \u2514\u2500 NO \u2192 Escalate to Moderate Exploration
-    \u2502
-    \u2514\u2500 NO \u2192 Is general direction clear but details missing?
-          \u251C\u2500 YES \u2192 Moderate Exploration (3-5 min)
-          \u2502         \u2193
-          \u2502      Are ambiguities MEDIUM severity or lower?
-          \u2502         \u251C\u2500 YES \u2192 Document assumptions, proceed with test creation
-          \u2502         \u2514\u2500 NO \u2192 Escalate to Deep Exploration or Clarification
-          \u2502
-          \u2514\u2500 NO \u2192 Deep Exploration (5-10 min)
-                    \u2193
-                 Document comprehensive findings
-                    \u2193
-                 Assess ambiguity severity
-                    \u2193
-                 Seek clarification for CRITICAL/HIGH
-\`\`\`
-
----
-
-## Remember:
-
-\u{1F50D} **Explore before assuming** | \u{1F4CA} **Concrete observations > abstract interpretation** | \u23F1\uFE0F **Adaptive depth: time \u221D uncertainty** | \u{1F3AF} **Exploration findings \u2192 specific clarifications** | \u{1F4DD} **Always document** | \u{1F517} **Link exploration \u2192 ambiguity \u2192 clarification**
-`;
-
-// src/tasks/templates/knowledge-base.ts
-var KNOWLEDGE_BASE_READ_INSTRUCTIONS = `
-## Knowledge Base Context
-
-Before proceeding, read the curated knowledge base to inform your work:
-
-**Location:** \`.bugzy/runtime/knowledge-base.md\`
-
-**Purpose:** The knowledge base is a living collection of factual knowledge - what we currently know and believe to be true about this project, its patterns, and its context. This is NOT a historical log, but a curated snapshot that evolves as understanding improves.
-
-**How to Use:**
-1. Read the knowledge base to understand:
-   - Project-specific patterns and conventions
-   - Known behaviors and system characteristics
-   - Relevant context from past work
-   - Documented decisions and approaches
-
-2. Apply this knowledge to:
-   - Make informed decisions aligned with project patterns
-   - Avoid repeating past mistakes
-   - Build on existing understanding
-   - Maintain consistency with established practices
-
-**Note:** The knowledge base may not exist yet or may be empty. If it doesn't exist or is empty, proceed without this context and help build it as you work.
-`;
-var KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS = `
-## Knowledge Base Maintenance
-
-After completing your work, update the knowledge base with new insights.
-
-**Location:** \`.bugzy/runtime/knowledge-base.md\`
-
-**Process:**
-
-1. **Read the maintenance guide** at \`.bugzy/runtime/knowledge-maintenance-guide.md\` to understand when to ADD, UPDATE, or REMOVE entries and how to maintain a curated knowledge base (not an append-only log)
-
-2. **Review the current knowledge base** to check for overlaps, contradictions, or opportunities to consolidate existing knowledge
-
-3. **Update the knowledge base** following the maintenance guide principles: favor consolidation over addition, update rather than append, resolve contradictions immediately, and focus on quality over completeness
-
-**Remember:** Every entry should answer "Will this help someone working on this project in 6 months?"
-`;
-
-// src/tasks/library/explore-application.ts
-var exploreApplicationTask = {
-  slug: TASK_SLUGS.EXPLORE_APPLICATION,
-  name: "Explore Application",
-  description: "Systematically explore application to discover UI elements, workflows, and behaviors",
-  frontmatter: {
-    description: "Systematically explore application to discover UI elements, workflows, and behaviors",
-    "argument-hint": "--focus [area] --depth [shallow|deep] --system [system-name]"
-  },
-  baseContent: `# Explore Application Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Systematically explore the application using the test-runner agent to discover actual UI elements, workflows, and behaviors. Updates test plan and project documentation with findings.
-
-## Arguments
-Arguments: $ARGUMENTS
-
-## Parse Arguments
-Extract the following from arguments:
-- **focus**: Specific area to explore (authentication, navigation, search, content, admin)
-- **depth**: Exploration depth - shallow (quick discovery) or deep (comprehensive) - defaults to deep
-- **system**: Which system to explore (optional for multi-system setups)
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Process
-
-### Step 0: Understand Exploration Protocol
-
-This task implements the exploration protocol defined in the exploration-instructions template.
-
-**Purpose**: This task provides the infrastructure for systematic application exploration that is referenced by other tasks (generate-test-plan, generate-test-cases, verify-changes) when they need to explore features before proceeding.
-
-**Depth Alignment**: The depth levels in this task align with the exploration template:
-- **Shallow exploration (15-20 min)** implements the quick/moderate exploration from the template
-- **Deep exploration (45-60 min)** implements comprehensive deep exploration from the template
-
-The depth levels are extended for full application exploration compared to the focused feature exploration used in other tasks.
-
-**Full Exploration Protocol Reference**:
-
-${EXPLORATION_INSTRUCTIONS}
-
-**Note**: This task extends the protocol for comprehensive application-wide exploration, while other tasks use abbreviated versions for targeted feature exploration.
-
-### Step 1: Load Environment and Context
-
-#### 1.1 Check Environment Variables
-Read \`.env.testdata\` file to understand what variables are required:
-- TEST_BASE_URL or TEST_MOBILE_BASE_URL (base URL variable names)
-- [SYSTEM_NAME]_URL (if multi-system setup)
-- Authentication credential variable names for the selected system
-- Any test data variable names
-
-Note: The actual values will be read from the user's \`.env\` file at test execution time.
-Verify \`.env.testdata\` exists to understand variable structure. If it doesn't exist, notify user to create it based on test plan.
-
-#### 1.2 Read Current Test Plan
-Read \`test-plan.md\` to:
-- Identify sections marked with [TO BE EXPLORED]
-- Find features requiring discovery
-- Understand testing scope and priorities
-
-#### 1.3 Read Project Context
-Read \`.bugzy/runtime/project-context.md\` for:
-- System architecture understanding
-- Testing environment details
-- QA workflow requirements
-
-### Step 2: Prepare Exploration Strategy
-
-Based on the arguments and context, prepare exploration instructions.
-
-#### 2.1 Focus Area Strategies
-
-**If focus is "authentication":**
-\`\`\`
-1. Navigate to the application homepage
-2. Locate and document all authentication entry points:
-   - Login button/link location and selector
-   - Registration option and flow
-   - Social login options (Facebook, Google, etc.)
-3. Test login flow:
-   - Document form fields and validation
-   - Test error states with invalid credentials
-   - Verify successful login indicators
-4. Test logout functionality:
-   - Find logout option
-   - Verify session termination
-   - Check redirect behavior
-5. Explore password recovery:
-   - Locate forgot password link
-   - Document recovery flow
-   - Note email/SMS options
-6. Check role-based access:
-   - Identify user role indicators
-   - Document permission differences
-   - Test admin/moderator access if available
-7. Test session persistence:
-   - Check remember me functionality
-   - Test timeout behavior
-   - Verify multi-tab session handling
-\`\`\`
-
-**If focus is "navigation":**
-\`\`\`
-1. Document main navigation structure:
-   - Primary menu items and hierarchy
-   - Mobile menu behavior
-   - Footer navigation links
-2. Map URL patterns:
-   - Category URL structure
-   - Parameter patterns
-   - Deep linking support
-3. Test breadcrumb navigation:
-   - Availability on different pages
-   - Clickability and accuracy
-   - Mobile display
-4. Explore category system:
-   - Main categories and subcategories
-   - Navigation between levels
-   - Content organization
-5. Document special sections:
-   - User profiles
-   - Admin areas
-   - Help/Support sections
-6. Test browser navigation:
-   - Back/forward button behavior
-   - History management
-   - State preservation
-\`\`\`
-
-**If focus is "search":**
-\`\`\`
-1. Locate search interfaces:
-   - Main search bar
-   - Advanced search options
-   - Category-specific search
-2. Document search features:
-   - Autocomplete/suggestions
-   - Search filters
-   - Sort options
-3. Test search functionality:
-   - Special character handling
-   - Empty/invalid queries
-4. Analyze search results:
-   - Result format and layout
-   - Pagination
-   - No results handling
-5. Check search performance:
-   - Response times
-   - Result relevance
-   - Load more/infinite scroll
-\`\`\`
-
-**If no focus specified:**
-Use comprehensive exploration covering all major areas.
-
-#### 2.2 Depth Configuration
-
-**Implementation Note**: These depths implement the exploration protocol defined in exploration-instructions.ts, extended for full application exploration.
-
-**Shallow exploration (--depth shallow):**
-- Quick discovery pass (15-20 minutes)
-- Focus on main features only
-- Basic screenshot capture
-- High-level findings
-- *Aligns with Quick/Moderate exploration from template*
-
-**Deep exploration (--depth deep or default):**
-- Comprehensive exploration (45-60 minutes)
-- Test edge cases and variations
-- Extensive screenshot documentation
-- Detailed technical findings
-- Performance observations
-- Accessibility notes
-- *Aligns with Deep exploration from template*
-
-### Step 3: Execute Exploration
-
-#### 3.1 Create Exploration Test Case
-Generate a temporary exploration test case file at \`./test-cases/EXPLORATION-TEMP.md\`:
-
-\`\`\`markdown
----
-id: EXPLORATION-TEMP
-title: Application Exploration - [Focus Area or Comprehensive]
-type: exploratory
-priority: high
----
-
-## Preconditions
-- Browser with cleared cookies and cache
-- Access to [system] environment
-- Credentials configured per .env.testdata template
-
-## Test Steps
-[Generated exploration steps based on strategy]
-
-## Expected Results
-Document all findings including:
-- UI element locations and selectors
-- Navigation patterns and URLs
-- Feature behaviors and workflows
-- Performance observations
-- Error states and edge cases
-- Screenshots of all key areas
-\`\`\`
-
-#### 3.2 Launch Test Runner Agent
-{{INVOKE_TEST_RUNNER}}
-
-Execute the exploration test case with special exploration instructions:
-
-\`\`\`
-Execute the exploration test case at ./test-cases/EXPLORATION-TEMP.md with focus on discovery and documentation.
-
-Special instructions for exploration mode:
-1. Take screenshots of EVERY significant UI element and page
-2. Document all clickable elements with their selectors
-3. Note all URL patterns and parameters
-4. Test variations and edge cases where possible
-5. Document load times and performance observations
-6. Create detailed findings report with structured data
-7. Organize screenshots by functional area
-8. Note any console errors or warnings
-9. Document which features are accessible vs restricted
-
-Generate a comprehensive exploration report that can be used to update project documentation.
-\`\`\`
-
-### Step 4: Process Exploration Results
-
-#### 4.1 Read Test Runner Output
-Read the generated test run files from \`./test-runs/[timestamp]/EXPLORATION-TEMP/\`:
-- \`findings.md\` - Main findings document
-- \`test-log.md\` - Detailed step execution
-- \`screenshots/\` - Visual documentation
-- \`summary.json\` - Execution summary
-
-#### 4.2 Parse and Structure Findings
-Extract and organize:
-- Discovered features and capabilities
-- UI element selectors and patterns
-- Navigation structure and URLs
-- Authentication flow details
-- Performance metrics
-- Technical observations
-- Areas requiring further investigation
-
-### Step 5: Update Project Artifacts
-
-#### 5.1 Update Test Plan
-Read and update \`test-plan.md\`:
-- Replace [TO BE EXPLORED] markers with concrete findings
-- Add newly discovered features to test items
-- Update navigation patterns and URL structures
-- Document actual authentication methods
-- Update environment variables if new ones discovered
-- Refine pass/fail criteria based on actual behavior
-
-#### 5.2 Create Exploration Report
-Create \`./exploration-reports/[timestamp]-[focus]-exploration.md\`
-
-### Step 6: Cleanup
-
-#### 6.1 Remove Temporary Files
-Delete the temporary exploration test case:
-\`\`\`bash
-rm ./test-cases/EXPLORATION-TEMP.md
-\`\`\`
-
-### Step 7: Generate Summary Report
-Create a concise summary for the user
-
-## Error Handling
-
-### Environment Issues
-- If \`.env.testdata\` missing: Warn user and suggest creating it from test plan
-- If credentials invalid (at runtime): Document in report and continue with public areas
-- If system unreachable: Retry with exponential backoff, report if persistent
-
-### Exploration Failures
-- If test-runner fails: Capture partial results and report
-- If specific area inaccessible: Note in findings and continue
-- If browser crashes: Attempt recovery and resume
-- If test-runner stops, but does not create files, inspect what it did and if it was not enough remove the test-run and start the test-runner agent again. If it has enough info, continue with what you have.
-
-### Data Issues
-- If dynamic content prevents exploration: Note and try alternative approaches
-- If rate limited: Implement delays and retry
-
-## Integration with Other Commands
-
-### Feeds into /generate-test-cases
-- Provides actual UI elements for test steps
-- Documents real workflows for test scenarios
-- Identifies edge cases to test
-
-### Updates from /process-event
-- New exploration findings can be processed as events
-- Discovered bugs trigger issue creation
-- Feature discoveries update test coverage
-
-### Enhances /run-tests
-- Tests use discovered selectors
-- Validation based on actual behavior
-- More reliable test execution
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}`,
-  optionalSubagents: [],
-  requiredSubagents: ["test-runner"]
-};
-
-// src/tasks/templates/clarification-instructions.ts
-var CLARIFICATION_INSTRUCTIONS = `
-## Clarification Protocol
-
-Before proceeding with test creation or execution, ensure requirements are clear and testable. Use this protocol to detect ambiguity, assess its severity, and determine the appropriate action.
-
-### Step {{STEP_NUMBER}}.0: Check for Pending Clarification
-
-Before starting, check if this task is resuming from a blocked clarification:
-
-1. **Check $ARGUMENTS for clarification data:**
-   - If \`$ARGUMENTS.clarification\` exists, this task is resuming with a clarification response
-   - Extract: \`clarification\` (the user's answer), \`originalArgs\` (original task parameters)
-
-2. **If clarification is present:**
-   - Read \`.bugzy/runtime/blocked-task-queue.md\`
-   - Find and remove your task's entry from the queue (update the file)
-   - Proceed using the clarification as if user just provided the answer
-   - Skip ambiguity detection for the clarified aspect
-
-3. **If no clarification in $ARGUMENTS:** Proceed normally with ambiguity detection below.
-
-### Step {{STEP_NUMBER}}.1: Detect Ambiguity
-
-Scan for ambiguity signals:
-
-**Language:** Vague terms ("fix", "improve", "better", "like", "mixed up"), relative terms without reference ("faster", "more"), undefined scope ("the ordering", "the fields", "the page"), modal ambiguity ("should", "could" vs "must", "will")
-
-**Details:** Missing acceptance criteria (no clear PASS/FAIL), no examples/mockups, incomplete field/element lists, unclear role behavior differences, unspecified error scenarios
-
-**Interpretation:** Multiple valid interpretations, contradictory information (description vs comments), implied vs explicit requirements
-
-**Context:** No reference documentation, "RELEASE APPROVED" without criteria, quick ticket creation, assumes knowledge ("as you know...", "obviously...")
-
-**Quick Check:**
-- [ ] Success criteria explicitly defined? (PASS if X, FAIL if Y)
-- [ ] All affected elements specifically listed? (field names, URLs, roles)
-- [ ] Only ONE reasonable interpretation?
-- [ ] Examples, screenshots, or mockups provided?
-- [ ] Consistent with existing system patterns?
-- [ ] Can write test assertions without assumptions?
-
-### Step {{STEP_NUMBER}}.2: Assess Severity
-
-If ambiguity is detected, assess its severity:
-
-| Severity | Characteristics | Examples | Action |
-|----------|----------------|----------|--------|
-| \u{1F534} **CRITICAL** | Expected behavior undefined/contradictory; test outcome unpredictable; core functionality unclear; success criteria missing; multiple interpretations = different strategies | "Fix the issue" (what issue?), "Improve performance" (which metrics?), "Fix sorting in todo list" (by date? priority? completion status?) | **STOP** - Seek clarification before proceeding |
-| \u{1F7E0} **HIGH** | Core underspecified but direction clear; affects majority of scenarios; vague success criteria; assumptions risky | "Fix ordering" (sequence OR visibility?), "Add validation" (what? messages?), "Update dashboard" (which widgets?) | **STOP** - Seek clarification before proceeding |
-| \u{1F7E1} **MEDIUM** | Specific details missing; general requirements clear; affects subset of cases; reasonable low-risk assumptions possible; wrong assumption = test updates not strategy overhaul | Missing field labels, unclear error message text, undefined timeouts, button placement not specified, date formats unclear | **PROCEED** - (1) Moderate exploration, (2) Document assumptions: "Assuming X because Y", (3) Proceed with creation/execution, (4) Async clarification (team-communicator), (5) Mark [ASSUMED: description] |
-| \u{1F7E2} **LOW** | Minor edge cases; documentation gaps don't affect execution; optional/cosmetic elements; minimal impact | Tooltip text, optional field validation, icon choice, placeholder text, tab order | **PROCEED** - (1) Mark [TO BE CLARIFIED: description], (2) Proceed, (3) Mention in report "Minor Details", (4) No blocking/async clarification |
-
-### Step {{STEP_NUMBER}}.3: Check Memory for Similar Clarifications
-
-Before asking, check if similar question was answered:
-
-**Process:**
-1. **Query team-communicator memory** - Search by feature name, ambiguity pattern, ticket keywords
-2. **Review past Q&A** - Similar question asked? What was answer? Applicable now?
-3. **Assess reusability:**
-   - Directly applicable \u2192 Use answer, no re-ask
-   - Partially applicable \u2192 Adapt and reference ("Previously for X, clarified Y. Same here?")
-   - Not applicable \u2192 Ask as new
-4. **Update memory** - Store Q&A with task type, feature, pattern tags
-
-**Example:** Query "todo sorting priority" \u2192 Found 2025-01-15: "Should completed todos appear in main list?" \u2192 Answer: "No, move to separate archive view" \u2192 Directly applicable \u2192 Use, no re-ask needed
-
-### Step {{STEP_NUMBER}}.4: Formulate Clarification Questions
-
-If clarification needed (CRITICAL/HIGH severity), formulate specific, concrete questions:
-
-**Good Questions:** Specific and concrete, provide context, offer options, reference examples, tie to test strategy
-
-**Bad Questions:** Too vague/broad, assumptive, multiple questions in one, no context
-
-**Template:**
-\`\`\`
-**Context:** [Current understanding]
-**Ambiguity:** [Specific unclear aspect]
-**Question:** [Specific question with options]
-**Why Important:** [Testing strategy impact]
-
-Example:
-Context: TODO-456 "Fix the sorting in the todo list so items appear in the right order"
-Ambiguity: "sorting" = (A) by creation date, (B) by due date, (C) by priority level, or (D) custom user-defined order
-Question: Should todos be sorted by due date (soonest first) or priority (high to low)? Should completed items appear in the list or move to archive?
-Why Important: Different sort criteria require different test assertions. Current app shows 15 active todos + 8 completed in mixed order.
-\`\`\`
-
-### Step {{STEP_NUMBER}}.5: Communicate Clarification Request
-
-**For Slack-Triggered Tasks:** Use team-communicator subagent:
-\`\`\`
-Ask clarification in Slack thread:
-Context: [From ticket/description]
-Ambiguity: [Describe ambiguity]
-Severity: [CRITICAL/HIGH]
-Questions:
-1. [First specific question]
-2. [Second if needed]
-
-Clarification needed to proceed. I'll wait for response before testing.
-\`\`\`
-
-**For Manual/API Triggers:** Include in task output:
-\`\`\`markdown
-## \u26A0\uFE0F Clarification Required Before Testing
-
-**Ambiguity:** [Description]
-**Severity:** [CRITICAL/HIGH]
-
-### Questions:
-1. **Question:** [First question]
-   - Context: [Provide context]
-   - Options: [If applicable]
-   - Impact: [Testing impact]
-
-**Action Required:** Provide clarification. Testing cannot proceed.
-**Current Observation:** [What exploration revealed - concrete examples]
-\`\`\`
-
-### Step {{STEP_NUMBER}}.5.1: Register Blocked Task (CRITICAL/HIGH only)
-
-When asking a CRITICAL or HIGH severity question that blocks progress, register the task in the blocked queue so it can be automatically re-triggered when clarification arrives.
-
-**Update \`.bugzy/runtime/blocked-task-queue.md\`:**
-
-1. Read the current file (create if doesn't exist)
-2. Add a new row to the Queue table
-
-\`\`\`markdown
-# Blocked Task Queue
-
-Tasks waiting for clarification responses.
-
-| Task Slug | Question | Original Args |
-|-----------|----------|---------------|
-| generate-test-plan | Should todos be sorted by date or priority? | \`{"ticketId": "TODO-456"}\` |
-\`\`\`
-
-**Entry Fields:**
-- **Task Slug**: The task slug (e.g., \`generate-test-plan\`) - used for re-triggering
-- **Question**: The clarification question asked (so LLM can match responses)
-- **Original Args**: JSON-serialized \`$ARGUMENTS\` wrapped in backticks
-
-**Purpose**: The LLM processor reads this file and matches user responses to pending questions. When a match is found, it re-queues the task with the clarification.
-
-### Step {{STEP_NUMBER}}.6: Wait or Proceed Based on Severity
-
-**CRITICAL/HIGH \u2192 STOP and Wait:**
-- Do NOT create tests, run tests, or make assumptions
-- Wait for clarification, resume after answer
-- *Rationale: Wrong assumptions = incorrect tests, false results, wasted time*
-
-**MEDIUM \u2192 Proceed with Documented Assumptions:**
-- Perform moderate exploration, document assumptions, proceed with creation/execution
-- Ask clarification async (team-communicator), mark results "based on assumptions"
-- Update tests after clarification received
-- *Rationale: Waiting blocks progress; documented assumptions allow forward movement with later corrections*
-
-**LOW \u2192 Proceed and Mark:**
-- Proceed with creation/execution, mark gaps [TO BE CLARIFIED] or [ASSUMED]
-- Mention in report but don't prioritize, no blocking
-- *Rationale: Details don't affect strategy/results significantly*
-
-### Step {{STEP_NUMBER}}.7: Document Clarification in Results
-
-When reporting test results, always include an "Ambiguities" section if clarification occurred:
-
-\`\`\`markdown
-## Ambiguities Encountered
-
-### Clarification: [Topic]
-- **Severity:** [CRITICAL/HIGH/MEDIUM/LOW]
-- **Question Asked:** [What was asked]
-- **Response:** [Answer received, or "Awaiting response"]
-- **Impact:** [How this affected testing]
-- **Assumption Made:** [If proceeded with assumption]
-- **Risk:** [What could be wrong if assumption is incorrect]
-
-### Resolution:
-[How the clarification was resolved and incorporated into testing]
-\`\`\`
-
----
-
-## Remember:
-
-\u{1F6D1} **Block for CRITICAL/HIGH** | \u2705 **Ask correctly > guess poorly** | \u{1F4DD} **Document MEDIUM assumptions** | \u{1F50D} **Check memory first** | \u{1F3AF} **Specific questions \u2192 specific answers**
-`;
-
 // src/tasks/library/generate-test-cases.ts
 var generateTestCasesTask = {
   slug: TASK_SLUGS.GENERATE_TEST_CASES,
@@ -825,40 +61,39 @@ var generateTestCasesTask = {
     description: "Generate manual test case documentation AND automated Playwright test scripts from test plan",
     "argument-hint": "--type [exploratory|functional|regression|smoke] --focus [optional-feature]"
   },
-  baseContent: `# Generate Test Cases Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret test data (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Generate comprehensive test artifacts including BOTH manual test case documentation AND automated Playwright test scripts.
-
-## Overview
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Generate Test Cases Overview",
+      content: `Generate comprehensive test artifacts including BOTH manual test case documentation AND automated Playwright test scripts.
 
 This command generates:
 1. **Manual Test Case Documentation** (in \`./test-cases/\`) - Human-readable test cases in markdown format
 2. **Automated Playwright Tests** (in \`./tests/specs/\`) - Executable TypeScript test scripts
 3. **Page Object Models** (in \`./tests/pages/\`) - Reusable page classes for automated tests
-4. **Supporting Files** (fixtures, helpers, components) - As needed for test automation
-
-## Arguments
-Arguments: $ARGUMENTS
+4. **Supporting Files** (fixtures, helpers, components) - As needed for test automation`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `Arguments: $ARGUMENTS
 
-## Parse Arguments
+**Parse Arguments:**
 Extract the following from arguments:
 - **type**: Test type (exploratory, functional, regression, smoke) - defaults to functional
-- **focus**: Optional specific feature or section to focus on
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Process
-
-### Step 1: Gather Context
-
-#### 1.1 Read Test Plan
+- **focus**: Optional specific feature or section to focus on`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Gather Context (inline)
+    {
+      inline: true,
+      title: "Gather Context",
+      content: `**1.1 Read Test Plan**
 Read the test plan from \`test-plan.md\` to understand:
 - Test items and features
 - Testing approach and automation strategy
@@ -867,35 +102,40 @@ Read the test plan from \`test-plan.md\` to understand:
 - Test environment and data requirements
 - Automation decision criteria
 
-#### 1.2 Check Existing Test Cases and Tests
+**1.2 Check Existing Test Cases and Tests**
 - List all files in \`./test-cases/\` to understand existing manual test coverage
 - List all files in \`./tests/specs/\` to understand existing automated tests
 - Determine next test case ID (TC-XXX format)
 - Identify existing Page Objects in \`./tests/pages/\`
-- Avoid creating overlapping test cases or duplicate automation
-
-{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
-
-### Step 1.4: Explore Features (If Needed)
-
-If documentation is insufficient or ambiguous, perform adaptive exploration to understand actual feature behavior before creating test cases.
-
-${EXPLORATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.4")}
-
-### Step 1.5: Clarify Ambiguities
-
-If exploration or documentation review reveals ambiguous requirements, use the clarification protocol to resolve them before generating test cases.
-
-${CLARIFICATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.5")}
-
-**Important Notes:**
-- **CRITICAL/HIGH ambiguities:** STOP test case generation and seek clarification
-- **MEDIUM ambiguities:** Document assumptions explicitly in test case with [ASSUMED: reason]
-- **LOW ambiguities:** Mark with [TO BE CLARIFIED: detail] in test case notes section
-
-### Step 1.6: Organize Test Scenarios by Area
+- Avoid creating overlapping test cases or duplicate automation`
+    },
+    // Step 6: Documentation Researcher (conditional inline)
+    {
+      inline: true,
+      title: "Gather Product Documentation",
+      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive product documentation:
 
-Based on exploration and documentation, organize test scenarios by feature area/component:
+\`\`\`
+Explore all available product documentation, specifically focusing on:
+- UI elements and workflows
+- User interactions and navigation paths
+- Form fields and validation rules
+- Error messages and edge cases
+- Authentication and authorization flows
+- Business rules and constraints
+- API endpoints for test data setup
+\`\`\``,
+      conditionalOnSubagent: "documentation-researcher"
+    },
+    // Step 7: Exploration Protocol (from library)
+    "exploration-protocol",
+    // Step 8: Clarification Protocol (from library)
+    "clarification-protocol",
+    // Step 9: Organize Test Scenarios (inline - task-specific)
+    {
+      inline: true,
+      title: "Organize Test Scenarios by Area",
+      content: `Based on exploration and documentation, organize test scenarios by feature area/component:
 
 **Group scenarios into areas** (e.g., Authentication, Dashboard, Checkout, Profile Management):
 - Each area should be a logical feature grouping
@@ -930,19 +170,21 @@ Based on exploration and documentation, organize test scenarios by feature area/
 
 Example structure:
 - **Authentication**: TC-001 Valid login (smoke, automate), TC-002 Invalid password (automate), TC-003 Password reset (automate)
-- **Dashboard**: TC-004 View dashboard widgets (smoke, automate), TC-005 Filter data by date (automate), TC-006 Export data (manual - rare use)
-
-### Step 1.7: Generate All Manual Test Case Files
-
-Generate ALL manual test case markdown files in the \`./test-cases/\` directory BEFORE invoking the test-code-generator agent.
+- **Dashboard**: TC-004 View dashboard widgets (smoke, automate), TC-005 Filter data by date (automate), TC-006 Export data (manual - rare use)`
+    },
+    // Step 10: Generate Manual Test Cases (inline)
+    {
+      inline: true,
+      title: "Generate All Manual Test Case Files",
+      content: `Generate ALL manual test case markdown files in the \`./test-cases/\` directory BEFORE invoking the test-code-generator agent.
 
-**For each test scenario from Step 1.6:**
+**For each test scenario from the previous step:**
 
 1. **Create test case file** in \`./test-cases/\` with format \`TC-XXX-feature-description.md\`
 2. **Include frontmatter** with:
    - \`id:\` TC-XXX (sequential ID)
    - \`title:\` Clear, descriptive title
-   - \`automated:\` true/false (based on automation decision from Step 1.6)
+   - \`automated:\` true/false (based on automation decision)
    - \`automated_test:\` (leave empty - will be filled by subagent when automated)
    - \`type:\` exploratory/functional/regression/smoke
    - \`area:\` Feature area/component
@@ -954,30 +196,30 @@ Generate ALL manual test case markdown files in the \`./test-cases/\` directory
    - **Test Data**: Environment variables to use (e.g., \${TEST_BASE_URL}, \${TEST_OWNER_EMAIL})
    - **Notes**: Any assumptions, clarifications needed, or special considerations
 
-**Output**: All manual test case markdown files created in \`./test-cases/\` with automation flags set
-
-### Step 2: Automate Test Cases Area by Area
-
-**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.
-
-**For each area from Step 1.6**, invoke the test-code-generator agent:
+**Output**: All manual test case markdown files created in \`./test-cases/\` with automation flags set`
+    },
+    // Step 11: Automate Test Cases (inline - detailed instructions for test-code-generator)
+    {
+      inline: true,
+      title: "Automate Test Cases Area by Area",
+      content: `**IMPORTANT**: Process each feature area separately to enable incremental, focused test creation.
 
-#### Step 2.1: Prepare Area Context
+**For each area**, invoke the test-code-generator agent:
 
+**Prepare Area Context:**
 Before invoking the agent, identify the test cases for the current area:
 - Current area name
 - Test case files for this area (e.g., TC-001-valid-login.md, TC-002-invalid-password.md)
 - Which test cases are marked for automation (automated: true)
-- Test type: {type}
+- Test type from arguments
 - Test plan reference: test-plan.md
 - Existing automated tests in ./tests/specs/
 - Existing Page Objects in ./tests/pages/
 
-#### Step 2.2: Invoke test-code-generator Agent
+**Invoke test-code-generator Agent:**
 
 {{INVOKE_TEST_CODE_GENERATOR}} for the current area with the following context:
 
-**Agent Invocation:**
 "Automate test cases for the [AREA_NAME] area.
 
 **Context:**
@@ -998,63 +240,34 @@ Before invoking the agent, identify the test cases for the current area:
    - Create automated Playwright test in ./tests/specs/
    - Update the manual test case file to reference the automated test path
 6. Run and iterate on each test until it passes or fails with a product bug
-8. Update .env.testdata with any new variables
+7. Update .env.testdata with any new variables
 
 **Focus only on the [AREA_NAME] area** - do not automate tests for other areas yet."
 
-#### Step 2.3: Verify Area Completion
-
+**Verify Area Completion:**
 After the agent completes the area, verify:
 - Manual test case files updated with automated_test references
 - Automated tests created for all test cases marked automated: true
 - Tests are passing (or failing with documented product bugs)
 - Page Objects created/updated for the area
 
-#### Step 2.4: Repeat for Next Area
-
-Move to the next area and repeat Steps 2.1-2.3 until all areas are complete.
+**Repeat for Next Area:**
+Move to the next area and repeat until all areas are complete.
 
 **Benefits of area-by-area approach**:
 - Agent focuses on one feature at a time
 - POMs built incrementally as needed
 - Tests verified before moving to next area
 - Easier to manage and track progress
-- Can pause/resume between areas if needed
-
-### Step 2.5: Validate Generated Artifacts
-
-After the test-code-generator completes, verify:
-
-1. **Manual Test Cases (in \`./test-cases/\`)**:
-   - Each has unique TC-XXX ID
-   - Frontmatter includes \`automated: true/false\` flag
-   - If automated, includes \`automated_test\` path reference
-   - Contains human-readable steps and expected results
-   - References environment variables for test data
-
-2. **Automated Tests (in \`./tests/specs/\`)**:
-   - Organized by feature in subdirectories
-   - Each test file references manual test case ID in comments
-   - Uses Page Object Model pattern
-   - Follows role-based selector priority
-   - Uses environment variables for test data
-   - Includes proper TypeScript typing
-
-3. **Page Objects (in \`./tests/pages/\`)**:
-   - Extend BasePage class
-   - Use semantic selectors (getByRole, getByLabel, getByText)
-   - Contain only actions, no assertions
-   - Properly typed with TypeScript
-
-4. **Supporting Files**:
-   - Fixtures created for common setup (in \`./tests/fixtures/\`)
-   - Helper functions for data generation (in \`./tests/helpers/\`)
-   - Component objects for reusable UI elements (in \`./tests/components/\`)
-   - Types defined as needed (in \`./tests/types/\`)
-
-### Step 3: Create Directories if Needed
-
-Ensure required directories exist:
+- Can pause/resume between areas if needed`
+    },
+    // Step 12: Validate Artifacts (library)
+    "validate-test-artifacts",
+    // Step 13: Create Directories (inline)
+    {
+      inline: true,
+      title: "Create Directories if Needed",
+      content: `Ensure required directories exist:
 \`\`\`bash
 mkdir -p ./test-cases
 mkdir -p ./tests/specs
@@ -1062,23 +275,53 @@ mkdir -p ./tests/pages
 mkdir -p ./tests/components
 mkdir -p ./tests/fixtures
 mkdir -p ./tests/helpers
-\`\`\`
-
-### Step 4: Update .env.testdata (if needed)
-
-If new environment variables were introduced:
-- Read current \`.env.testdata\`
-- Add new TEST_* variables with empty values
-- Group variables logically with comments
-- Document what each variable is for
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
+\`\`\``
+    },
+    // Step 14: Extract Env Variables (library)
+    "extract-env-variables",
+    // Step 15: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 16: Team Communication (conditional inline)
+    {
+      inline: true,
+      title: "Team Communication",
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:
 
-{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
+\`\`\`
+1. Post an update about test case and automation creation
+2. Provide summary of coverage:
+   - Number of manual test cases created
+   - Number of automated tests created
+   - Features covered by automation
+   - Areas kept manual-only (and why)
+3. Highlight key automated test scenarios
+4. Share command to run automated tests: npx playwright test
+5. Ask for team review and validation
+6. Mention any areas needing exploration or clarification
+7. Use appropriate channel and threading for the update
+\`\`\`
 
-### Step 5: Final Summary
+The team communication should include:
+- **Test artifacts created**: Manual test cases + automated tests count
+- **Automation coverage**: Which features are now automated
+- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)
+- **Key automated scenarios**: Critical paths now covered by automation
+- **Running tests**: Command to execute automated tests
+- **Review request**: Ask team to validate scenarios and review test code
+- **Next steps**: Plans for CI/CD integration or additional test coverage
 
-Provide a comprehensive summary showing:
+**Update team communicator memory:**
+- Record this communication
+- Note test case and automation creation
+- Track team feedback on automation approach
+- Document any clarifications requested`,
+      conditionalOnSubagent: "team-communicator"
+    },
+    // Step 17: Final Summary (inline)
+    {
+      inline: true,
+      title: "Final Summary",
+      content: `Provide a comprehensive summary showing:
 
 **Manual Test Cases:**
 - Number of manual test cases created
@@ -1102,245 +345,162 @@ Provide a comprehensive summary showing:
 - Note about copying .env.testdata to .env
 - Mention any exploration needed for edge cases
 
-### Important Notes
-
+**Important Notes:**
 - **Both Manual AND Automated**: Generate both artifacts - they serve different purposes
 - **Manual Test Cases**: Documentation, reference, can be executed manually when needed
 - **Automated Tests**: Fast, repeatable, for CI/CD and regression testing
 - **Automation Decision**: Not all test cases need automation - rare edge cases can stay manual
 - **Linking**: Manual test cases reference automated tests; automated tests reference manual test case IDs
-- **Two-Phase Workflow**: First generate all manual test cases (Step 1.7), then automate area-by-area (Step 2)
-- **Ambiguity Handling**: Use exploration (Step 1.4) and clarification (Step 1.5) protocols before generating
+- **Two-Phase Workflow**: First generate all manual test cases, then automate area-by-area
+- **Ambiguity Handling**: Use exploration and clarification protocols before generating
 - **Environment Variables**: Use \`process.env.VAR_NAME\` in tests, update .env.testdata as needed
-- **Test Independence**: Each test must be runnable in isolation and in parallel`,
-  optionalSubagents: [
-    {
-      role: "documentation-researcher",
-      contentBlock: `#### 1.4 Gather Product Documentation
-
-{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive product documentation:
-
-\`\`\`
-Explore all available product documentation, specifically focusing on:
-- UI elements and workflows
-- User interactions and navigation paths
-- Form fields and validation rules
-- Error messages and edge cases
-- Authentication and authorization flows
-- Business rules and constraints
-- API endpoints for test data setup
-\`\`\``
-    },
-    {
-      role: "team-communicator",
-      contentBlock: `### Step 4.5: Team Communication
-
-{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test cases and automated tests:
-
-\`\`\`
-1. Post an update about test case and automation creation
-2. Provide summary of coverage:
-   - Number of manual test cases created
-   - Number of automated tests created
-   - Features covered by automation
-   - Areas kept manual-only (and why)
-3. Highlight key automated test scenarios
-4. Share command to run automated tests: npx playwright test
-5. Ask for team review and validation
-6. Mention any areas needing exploration or clarification
-7. Use appropriate channel and threading for the update
-\`\`\`
-
-The team communication should include:
-- **Test artifacts created**: Manual test cases + automated tests count
-- **Automation coverage**: Which features are now automated
-- **Manual-only areas**: Why some tests are kept manual (rare scenarios, exploratory)
-- **Key automated scenarios**: Critical paths now covered by automation
-- **Running tests**: Command to execute automated tests
-- **Review request**: Ask team to validate scenarios and review test code
-- **Next steps**: Plans for CI/CD integration or additional test coverage
-
-**Update team communicator memory:**
-- Record this communication
-- Note test case and automation creation
-- Track team feedback on automation approach
-- Document any clarifications requested`
+- **Test Independence**: Each test must be runnable in isolation and in parallel`
     }
   ],
-  requiredSubagents: ["test-runner", "test-code-generator"]
+  requiredSubagents: ["test-runner", "test-code-generator"],
+  optionalSubagents: ["documentation-researcher", "team-communicator"],
+  dependentTasks: []
 };
 
 // src/tasks/library/generate-test-plan.ts
 var generateTestPlanTask = {
   slug: TASK_SLUGS.GENERATE_TEST_PLAN,
   name: "Generate Test Plan",
-  description: "Generate a comprehensive test plan from product description",
+  description: "Generate a concise feature checklist test plan from product description",
   frontmatter: {
-    description: "Generate a comprehensive test plan from product description",
+    description: "Generate a concise feature checklist test plan (~50-100 lines)",
     "argument-hint": "<product-description>"
   },
-  baseContent: `# Generate Test Plan Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret test data (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Generate a comprehensive test plan from product description following the Brain Module specifications.
-
-## Arguments
-Product description: $ARGUMENTS
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Process
-
-### Step 1: Load project context
-Read \`.bugzy/runtime/project-context.md\` to understand:
-- Project overview and key platform features
-- SDLC methodology and sprint duration
-- Testing environment and goals
-- Technical stack and constraints
-- QA workflow and processes
-
-### Step 1.5: Process the product description
-Use the product description provided directly in the arguments, enriched with project context understanding.
-
-### Step 1.6: Initialize environment variables tracking
-Create a list to track all TEST_ prefixed environment variables discovered throughout the process.
-
-{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
-
-### Step 1.7: Explore Product (If Needed)
-
-If product description is vague or incomplete, perform adaptive exploration to understand actual product features and behavior.
-
-${EXPLORATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.7")}
-
-### Step 1.8: Clarify Ambiguities
-
-If exploration or product description reveals ambiguous requirements, use the clarification protocol before generating the test plan.
-
-${CLARIFICATION_INSTRUCTIONS.replace(/{{STEP_NUMBER}}/g, "1.8")}
-
-**Important Notes:**
-- **CRITICAL/HIGH ambiguities:** STOP test plan generation and seek clarification
-  - Examples: Undefined core features, unclear product scope, contradictory requirements
-- **MEDIUM ambiguities:** Document assumptions in test plan with [ASSUMED: reason] and seek async clarification
-  - Examples: Missing field lists, unclear validation rules, vague user roles
-- **LOW ambiguities:** Mark with [TO BE EXPLORED: detail] in test plan for future investigation
-  - Examples: Optional features, cosmetic details, non-critical edge cases
-
-### Step 3: Prepare the test plan generation context
-
-**After ensuring requirements are clear through exploration and clarification:**
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Generate Test Plan Overview",
+      content: `Generate a comprehensive test plan from product description following the Brain Module specifications.`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `Product description: $ARGUMENTS`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Load Project Context (library)
+    "load-project-context",
+    // Step 6: Process Description (inline)
+    {
+      inline: true,
+      title: "Process the Product Description",
+      content: `Use the product description provided directly in the arguments, enriched with project context understanding.`
+    },
+    // Step 7: Initialize Env Tracking (inline)
+    {
+      inline: true,
+      title: "Initialize Environment Variables Tracking",
+      content: `Create a list to track all TEST_ prefixed environment variables discovered throughout the process.`
+    },
+    // Step 8: Documentation Researcher (conditional inline)
+    {
+      inline: true,
+      title: "Gather Comprehensive Project Documentation",
+      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to explore and gather all available project information and other documentation sources. This ensures the test plan is based on complete and current information.
 
-Based on the gathered information:
-- **goal**: Extract the main purpose and objectives from all available documentation
-- **knowledge**: Combine product description with discovered documentation insights
-- **testPlan**: Use the standard test plan template structure, enriched with documentation findings
-- **gaps**: Identify areas lacking documentation that will need exploration
-
-### Step 4: Generate the test plan using the prompt template
-
-You are an expert QA Test Plan Writer with expertise in both manual and automated testing strategies. Using the gathered information and context from the product description provided, you will now produce a comprehensive test plan in Markdown format that includes an automation strategy.
-
-Writing Instructions:
-- **Use Product Terminology:** Incorporate exact terms and labels from the product description for features and UI elements (to ensure the test plan uses official naming).
-- **Testing Scope:** The plan covers both automated E2E testing via Playwright and exploratory manual testing. Focus on what a user can do and see in a browser.
-- **Test Data - IMPORTANT:**
-  - DO NOT include test data values in the test plan body
-  - Test data goes ONLY to the \`.env.testdata\` file
-  - In the test plan, reference \`.env.testdata\` for test data requirements
-  - Define test data as environment variables prefixed with TEST_ (e.g., TEST_BASE_URL, TEST_USER_EMAIL, TEST_USER_PASSWORD)
-  - DO NOT GENERATE VALUES FOR THE ENV VARS, ONLY THE KEYS
-  - Track all TEST_ variables for extraction to .env.testdata in Step 7
-- **DO NOT INCLUDE TEST SCENARIOS**
-- **Incorporate All Relevant Info:** If the product description mentions specific requirements, constraints, or acceptance criteria (such as field validations, role-based access rules, important parameters), make sure these are reflected in the test plan. Do not add anything not supported by the given information.
-- **Test Automation Strategy Section - REQUIRED:** Include a comprehensive "Test Automation Strategy" section with the following subsections:
-
-  **## Test Automation Strategy**
-
-  ### Automated Test Coverage
-  - Identify critical user paths to automate (login, checkout, core features)
-  - Define regression test scenarios for automation
-  - Specify API endpoints that need automated testing
-  - List smoke test scenarios for CI/CD pipeline
-
-  ### Exploratory Testing Areas
-  - New features not yet automated
-  - Complex edge cases requiring human judgment
-  - Visual/UX validation requiring subjective assessment
-  - Scenarios that are not cost-effective to automate
-
-  ### Test Data Management
-  - Environment variables strategy (which vars go in .env.example vs .env)
-  - Dynamic test data generation approach (use data generators)
-  - API-based test data setup (10-20x faster than UI)
-  - Test data isolation and cleanup strategy
-
-  ### Automation Approach
-  - **Framework:** Playwright + TypeScript (already scaffolded)
-  - **Pattern:** Page Object Model for all pages
-  - **Selectors:** Prioritize role-based selectors (getByRole, getByLabel, getByText)
-  - **Components:** Reusable component objects for common UI elements
-  - **Fixtures:** Custom fixtures for authenticated sessions and common setup
-  - **API for Speed:** Use Playwright's request context to create test data via API
-  - **Best Practices:** Reference \`.bugzy/runtime/testing-best-practices.md\` for patterns
-
-  ### Test Organization
-  - Automated tests location: \`./tests/specs/[feature]/\`
-  - Page Objects location: \`./tests/pages/\`
-  - Manual test cases location: \`./test-cases/\` (human-readable documentation)
-  - Test case naming: TC-XXX-feature-description.md
-  - Automated test naming: feature.spec.ts
-
-  ### Automation Decision Criteria
-  Define which scenarios warrant automation:
-  - \u2705 Automate: Frequent execution, critical paths, regression tests, CI/CD integration
-  - \u274C Keep Manual: Rare edge cases, exploratory tests, visual validation, one-time checks
-
-### Step 5: Create the test plan file
-
-Read the test plan template from \`.bugzy/runtime/templates/test-plan-template.md\` and use it as the base structure. Fill in the placeholders with information extracted from BOTH the product description AND documentation research:
-
-1. Read the template file from \`.bugzy/runtime/templates/test-plan-template.md\`
-2. Replace placeholders like:
-   - \`[ProjectName]\` with the actual project name from the product description
-   - \`[Date]\` with the current date
-   - Feature sections with actual features identified from all documentation sources
-   - Test data requirements based on the product's needs and API documentation
-   - Risks based on the complexity, known issues, and technical constraints
-3. Add any product-specific sections that may be needed based on discovered documentation
-4. **Mark ambiguities based on severity:**
-   - CRITICAL/HIGH: Should be clarified before plan creation (see Step 1.8)
-   - MEDIUM: Mark with [ASSUMED: reason] and note assumption
-   - LOW: Mark with [TO BE EXPLORED: detail] for future investigation
-5. Include references to source documentation for traceability
-
-### Step 6: Save the test plan
-
-Save the generated test plan to a file named \`test-plan.md\` in the project root with appropriate frontmatter:
+\`\`\`
+Explore all available project documentation related to: $ARGUMENTS
 
-\`\`\`yaml
----
-version: 1.0.0
-lifecycle_phase: initial
-created_at: [current date]
-updated_at: [current date]
-last_exploration: null
-total_discoveries: 0
-status: draft
-author: claude
-tags: [functional, security, performance]
----
+Specifically gather:
+- Product specifications and requirements
+- User stories and acceptance criteria
+- Technical architecture documentation
+- API documentation and endpoints
+- User roles and permissions
+- Business rules and validations
+- UI/UX specifications
+- Known limitations or constraints
+- Existing test documentation
+- Bug reports or known issues
 \`\`\`
 
-### Step 7: Extract and save environment variables
+The agent will:
+1. Check its memory for previously discovered documentation
+2. Explore workspace for relevant pages and databases
+3. Build a comprehensive understanding of the product
+4. Return synthesized information about all discovered documentation`,
+      conditionalOnSubagent: "documentation-researcher"
+    },
+    // Step 9: Exploration Protocol (from library)
+    "exploration-protocol",
+    // Step 10: Clarification Protocol (from library)
+    "clarification-protocol",
+    // Step 11: Prepare Context (inline)
+    {
+      inline: true,
+      title: "Prepare Test Plan Generation Context",
+      content: `**After ensuring requirements are clear through exploration and clarification:**
 
-**CRITICAL**: Test data values must ONLY go to .env.testdata, NOT in the test plan document.
+Based on the gathered information:
+- **goal**: Extract the main purpose and objectives from all available documentation
+- **knowledge**: Combine product description with discovered documentation insights
+- **testPlan**: Use the standard test plan template structure, enriched with documentation findings
+- **gaps**: Identify areas lacking documentation that will need exploration`
+    },
+    // Step 12: Generate Test Plan (inline - more detailed than library step)
+    {
+      inline: true,
+      title: "Generate Test Plan Using Simplified Format",
+      content: `You are an expert QA Test Plan Writer. Generate a **concise** test plan (~50-100 lines) that serves as a feature checklist for test case generation.
+
+**CRITICAL - Keep it Simple:**
+- The test plan is a **feature checklist**, NOT a comprehensive document
+- Detailed UI elements and exploration findings go to \`./exploration-reports/\`
+- Technical patterns and architecture go to \`.bugzy/runtime/knowledge-base.md\`
+- Process documentation stays in \`.bugzy/runtime/project-context.md\`
+
+**Writing Instructions:**
+- **Use Product Terminology:** Use exact feature names from the product description
+- **Feature Checklist Format:** Each feature is a checkbox item with brief description
+- **Group by Feature Area:** Organize features into logical sections
+- **NO detailed UI elements** - those belong in exploration reports
+- **NO test scenarios** - those are generated in test cases
+- **NO process documentation** - keep only what's needed for test generation
+
+**Test Data Handling:**
+- Test data goes ONLY to \`.env.testdata\` file
+- In test plan, reference environment variable NAMES only (e.g., TEST_BASE_URL)
+- DO NOT generate values for env vars, only keys
+- Track all TEST_ variables for extraction to .env.testdata in the next step`
+    },
+    // Step 13: Create Test Plan File (inline)
+    {
+      inline: true,
+      title: "Create Test Plan File",
+      content: `Read the simplified template from \`.bugzy/runtime/templates/test-plan-template.md\` and fill it in:
+
+1. Read the template file
+2. Replace placeholders:
+   - \`[PROJECT_NAME]\` with the actual project name
+   - \`[DATE]\` with the current date
+   - Feature sections with actual features grouped by area
+3. Each feature is a **checkbox item** with brief description
+4. **Mark ambiguities:**
+   - MEDIUM: Mark with [ASSUMED: reason]
+   - LOW: Mark with [TO BE EXPLORED: detail]
+5. Keep total document under 100 lines`
+    },
+    // Step 14: Save Test Plan (inline)
+    {
+      inline: true,
+      title: "Save Test Plan",
+      content: `Save to \`test-plan.md\` in project root. The template already includes frontmatter - just fill in the dates.`
+    },
+    // Step 15: Extract Env Variables (inline - more detailed than library step)
+    {
+      inline: true,
+      title: "Extract and Save Environment Variables",
+      content: `**CRITICAL**: Test data values must ONLY go to .env.testdata, NOT in the test plan document.
 
 After saving the test plan:
 
@@ -1377,53 +537,15 @@ After saving the test plan:
 5. **Verify test plan references .env.testdata**:
    - Ensure test plan DOES NOT contain test data values
    - Ensure test plan references \`.env.testdata\` for test data requirements
-   - Add instruction: "Fill in actual values in .env.testdata before running tests"
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
-
-{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
-
-### Step 8: Final summary
-
-Provide a summary of:
-- Test plan created successfully at \`test-plan.md\`
-- Environment variables extracted to \`.env.testdata\`
-- Number of TEST_ variables discovered
-- Instructions for the user to fill in actual values in .env.testdata before running tests`,
-  optionalSubagents: [
-    {
-      role: "documentation-researcher",
-      contentBlock: `### Step 2: Gather comprehensive project documentation
-
-{{INVOKE_DOCUMENTATION_RESEARCHER}} to explore and gather all available project information and other documentation sources. This ensures the test plan is based on complete and current information.
-
-\`\`\`
-Explore all available project documentation related to: $ARGUMENTS
-
-Specifically gather:
-- Product specifications and requirements
-- User stories and acceptance criteria
-- Technical architecture documentation
-- API documentation and endpoints
-- User roles and permissions
-- Business rules and validations
-- UI/UX specifications
-- Known limitations or constraints
-- Existing test documentation
-- Bug reports or known issues
-\`\`\`
-
-The agent will:
-1. Check its memory for previously discovered documentation
-2. Explore workspace for relevant pages and databases
-3. Build a comprehensive understanding of the product
-4. Return synthesized information about all discovered documentation`
+   - Add instruction: "Fill in actual values in .env.testdata before running tests"`
     },
+    // Step 16: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 17: Team Communication (conditional inline)
     {
-      role: "team-communicator",
-      contentBlock: `### Step 7.5: Team Communication
-
-{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:
+      inline: true,
+      title: "Team Communication",
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about the new test plan:
 
 \`\`\`
 1. Post an update about the test plan creation
@@ -1444,10 +566,23 @@ The team communication should include:
 **Update team communicator memory:**
 - Record this communication in the team-communicator memory
 - Note this as a test plan creation communication
-- Track team response to this type of update`
+- Track team response to this type of update`,
+      conditionalOnSubagent: "team-communicator"
+    },
+    // Step 18: Final Summary (inline)
+    {
+      inline: true,
+      title: "Final Summary",
+      content: `Provide a summary of:
+- Test plan created successfully at \`test-plan.md\`
+- Environment variables extracted to \`.env.testdata\`
+- Number of TEST_ variables discovered
+- Instructions for the user to fill in actual values in .env.testdata before running tests`
     }
   ],
-  requiredSubagents: ["test-runner"]
+  requiredSubagents: ["test-runner"],
+  optionalSubagents: ["documentation-researcher", "team-communicator"],
+  dependentTasks: []
 };
 
 // src/tasks/library/handle-message.ts
@@ -1459,27 +594,30 @@ var handleMessageTask = {
     description: "Handle team responses and Slack communications, maintaining context for ongoing conversations",
     "argument-hint": "[slack thread context or team message]"
   },
-  baseContent: `# Handle Message Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Process team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.
-
-## Arguments
-Team message/thread context: $ARGUMENTS
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Process
-
-### Step 0: Detect Message Intent and Load Handler
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Handle Message Overview",
+      content: `# Handle Message Command
 
-Before processing the message, identify the intent type to load the appropriate handler.
+Process team responses from Slack threads and handle multi-turn conversations with the product team about testing clarifications, ambiguities, and questions.`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `Team message/thread context: $ARGUMENTS`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Detect Intent (inline - task-specific)
+    {
+      inline: true,
+      title: "Detect Message Intent and Load Handler",
+      content: `Before processing the message, identify the intent type to load the appropriate handler.
 
 #### 0.1 Extract Intent from Event Payload
 
@@ -1522,11 +660,17 @@ The handler file contains all necessary processing logic for the detected intent
 - Specific processing steps for that intent
 - Context loading requirements
 - Response guidelines
-- Memory update instructions
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
-
-## Key Principles
+- Memory update instructions`
+    },
+    // Step 6: Clarification Protocol (for ambiguous intents)
+    "clarification-protocol",
+    // Step 8: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 9: Key Principles (inline)
+    {
+      inline: true,
+      title: "Key Principles",
+      content: `## Key Principles
 
 ### Context Preservation
 - Always maintain full conversation context
@@ -1546,9 +690,13 @@ ${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
 ### Quality Communication
 - Acknowledge team input appropriately
 - Provide updates on actions taken
-- Ask good follow-up questions when needed
-
-## Important Considerations
+- Ask good follow-up questions when needed`
+    },
+    // Step 10: Important Considerations (inline)
+    {
+      inline: true,
+      title: "Important Considerations",
+      content: `## Important Considerations
 
 ### Thread Organization
 - Keep related discussions in same thread
@@ -1568,9 +716,12 @@ ${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
 ### Memory Maintenance
 - Keep active conversations visible and current
 - Archive resolved discussions appropriately
-- Maintain searchable history of resolutions`,
+- Maintain searchable history of resolutions`
+    }
+  ],
+  requiredSubagents: ["team-communicator"],
   optionalSubagents: [],
-  requiredSubagents: ["team-communicator"]
+  dependentTasks: []
 };
 
 // src/tasks/library/process-event.ts
@@ -1582,42 +733,47 @@ var processEventTask = {
     description: "Process external system events (Jira, GitHub, Linear) using handler-defined rules to extract insights and track issues",
     "argument-hint": "[event payload or description]"
   },
-  baseContent: `# Process Event Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Process various types of events using intelligent pattern matching and historical context to maintain and evolve the testing system.
-
-## Arguments
-Arguments: $ARGUMENTS
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Process
-
-### Step 1: Understand Event Context
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Process Event Overview",
+      content: `# Process Event Command
 
-Events come from integrated external systems via webhooks or manual input. Common sources include:
+Process various types of events using intelligent pattern matching and historical context to maintain and evolve the testing system.`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `Arguments: $ARGUMENTS`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Understand Event Context (inline)
+    {
+      inline: true,
+      title: "Understand Event Context",
+      content: `Events come from integrated external systems via webhooks or manual input. Common sources include:
 - **Issue Trackers**: Jira, Linear, GitHub Issues
 - **Source Control**: GitHub, GitLab
 - **Communication Tools**: Slack
 
-**Event structure and semantics vary by source.** Do not interpret events based on generic assumptions. Instead, load the appropriate handler file (Step 2.4) for system-specific processing rules.
+**Event structure and semantics vary by source.** Do not interpret events based on generic assumptions. Instead, load the appropriate handler file for system-specific processing rules.
 
 #### Event Context to Extract:
 - **What happened**: The core event (test failed, PR merged, etc.)
 - **Where**: Component, service, or area affected
 - **Impact**: How this affects testing strategy
-- **Action Required**: What needs to be done in response
-
-### Step 1.5: Clarify Unclear Events
-
-If the event information is incomplete or ambiguous, seek clarification before processing:
+- **Action Required**: What needs to be done in response`
+    },
+    // Step 6: Clarify Unclear Events (inline - task-specific)
+    {
+      inline: true,
+      title: "Clarify Unclear Events",
+      content: `If the event information is incomplete or ambiguous, seek clarification before processing:
 
 #### Detect Unclear Events
 
@@ -1700,9 +856,13 @@ In event history, record:
 - **Assumption made**: If proceeded with assumption
 - **Resolution**: How ambiguity was resolved
 
-This ensures future similar events can reference past clarifications and avoid redundant questions.
-
-### Step 2: Load Context and Memory
+This ensures future similar events can reference past clarifications and avoid redundant questions.`
+    },
+    // Step 7: Load Context and Memory (inline)
+    {
+      inline: true,
+      title: "Load Context and Memory",
+      content: `### Step 2: Load Context and Memory
 
 #### 2.1 Check Event Processor Memory
 Read \`.bugzy/runtime/memory/event-processor.md\` to:
@@ -1727,10 +887,10 @@ Read \`.bugzy/runtime/memory/event-history.md\` to:
 Based on the event source, load the handler from \`.bugzy/runtime/handlers/\`:
 
 **Step 1: Detect Event Source from Payload:**
-- \`com.jira-server.*\` event type prefix \u2192 \`.bugzy/runtime/handlers/jira.md\`
-- \`github.*\` or GitHub webhook structure \u2192 \`.bugzy/runtime/handlers/github.md\`
-- \`linear.*\` or Linear webhook \u2192 \`.bugzy/runtime/handlers/linear.md\`
-- Other sources \u2192 Check for matching handler file by source name
+- \`com.jira-server.*\` event type prefix -> \`.bugzy/runtime/handlers/jira.md\`
+- \`github.*\` or GitHub webhook structure -> \`.bugzy/runtime/handlers/github.md\`
+- \`linear.*\` or Linear webhook -> \`.bugzy/runtime/handlers/linear.md\`
+- Other sources -> Check for matching handler file by source name
 
 **Step 2: Load and Read the Handler File:**
 The handler file contains system-specific instructions for:
@@ -1756,9 +916,13 @@ Do NOT guess or apply generic logic. Instead:
 Handlers reference \`.bugzy/runtime/project-context.md\` for project-specific rules like:
 - Which status transitions trigger verify-changes
 - Which resolutions should update the knowledge base
-- Which transitions to ignore
-
-### Step 3: Intelligent Event Analysis
+- Which transitions to ignore`
+    },
+    // Step 8: Intelligent Event Analysis (inline)
+    {
+      inline: true,
+      title: "Intelligent Event Analysis",
+      content: `### Step 3: Intelligent Event Analysis
 
 #### 3.1 Contextual Pattern Analysis
 Don't just match patterns - analyze the event within the full context:
@@ -1789,11 +953,28 @@ Based on event type and content, generate 3-5 specific search queries:
 - Search for similar past events
 - Look for related test cases
 - Find relevant documentation
-- Check for known issues
-
-{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
-
-### Step 4: Task Planning with Reasoning
+- Check for known issues`
+    },
+    // Step 9: Documentation Research (conditional inline)
+    {
+      inline: true,
+      title: "Use Documentation Researcher",
+      content: `#### 3.3 Use Documentation Researcher if Needed
+
+{{INVOKE_DOCUMENTATION_RESEARCHER}} to find information about unknown features or components:
+
+For events mentioning unknown features or components, ask the agent to explore project documentation and return:
+- Feature specifications
+- Related test cases
+- Known issues or limitations
+- Component dependencies`,
+      conditionalOnSubagent: "documentation-researcher"
+    },
+    // Step 10: Task Planning (inline)
+    {
+      inline: true,
+      title: "Task Planning with Reasoning",
+      content: `### Step 4: Task Planning with Reasoning
 
 Generate tasks based on event analysis, using examples from memory as reference.
 
@@ -1809,11 +990,11 @@ Analyze the event in context of ALL available information to decide what actions
 
 **Contextual Decision Making**:
 The same event type can require different actions based on context:
-- If handler says this status triggers verification \u2192 Invoke /verify-changes
-- If this issue was already processed (check event history) \u2192 Skip to avoid duplicates
-- If related PR exists in knowledge base \u2192 Include PR context in actions
-- If this is a recurring pattern from the same source \u2192 Consider flagging for review
-- If handler has no rule for this event type \u2192 Ask user for guidance
+- If handler says this status triggers verification -> Invoke /verify-changes
+- If this issue was already processed (check event history) -> Skip to avoid duplicates
+- If related PR exists in knowledge base -> Include PR context in actions
+- If this is a recurring pattern from the same source -> Consider flagging for review
+- If handler has no rule for this event type -> Ask user for guidance
 
 **Dynamic Task Selection**:
 Based on the contextual analysis, decide which tasks make sense:
@@ -1831,15 +1012,40 @@ For each task, document WHY it's being executed:
 Task: extract_learning
 Reasoning: This event reveals a pattern of login failures on Chrome that wasn't previously documented
 Data: "Chrome-specific timeout issues with login button"
-\`\`\`
+\`\`\``
+    },
+    // Step 11: Issue Tracking (conditional inline)
+    {
+      inline: true,
+      title: "Issue Tracking",
+      content: `##### For Issue Tracking:
 
-### Step 5: Execute Tasks with Memory Updates
+When an issue needs to be tracked (task type: report_bug or update_story):
 
-#### 5.1 Execute Each Task
+{{INVOKE_ISSUE_TRACKER}}
+
+1. Check for duplicate issues in the tracking system
+2. For bugs: Create detailed bug report with:
+   - Clear, descriptive title
+   - Detailed description with context
+   - Step-by-step reproduction instructions
+   - Expected vs actual behavior
+   - Environment and configuration details
+   - Test case reference (if applicable)
+   - Screenshots or error logs
+3. For stories: Update status and add QA comments
+4. Track issue lifecycle and maintain categorization
 
-{{ISSUE_TRACKER_INSTRUCTIONS}}
+The issue-tracker agent will handle all aspects of issue tracking including duplicate detection, story management, QA workflow transitions, and integration with your project management system (Jira, Linear, Notion, etc.).`,
+      conditionalOnSubagent: "issue-tracker"
+    },
+    // Step 12: Execute Tasks (inline)
+    {
+      inline: true,
+      title: "Execute Tasks with Memory Updates",
+      content: `### Step 5: Execute Tasks with Memory Updates
 
-##### For Other Tasks:
+#### 5.1 Execute Each Task
 Follow the standard execution logic with added context from memory.
 
 #### 5.2 Update Event Processor Memory
@@ -1876,9 +1082,13 @@ source: [source]
 **Outcome**: [Success/Partial/Failed]
 **Notes**: [Any additional context]
 ---
-\`\`\`
-
-### Step 6: Learning from Events
+\`\`\``
+    },
+    // Step 13: Learning and Maintenance (inline)
+    {
+      inline: true,
+      title: "Learning from Events",
+      content: `### Step 6: Learning from Events
 
 After processing, check if this event teaches us something new:
 1. Is this a new type of event we haven't seen?
@@ -1898,9 +1108,15 @@ mkdir -p ./test-cases .claude/memory
 Create files if they don't exist:
 - \`.bugzy/runtime/knowledge-base.md\`
 - \`.bugzy/runtime/memory/event-processor.md\`
-- \`.bugzy/runtime/memory/event-history.md\`
-
-## Important Considerations
+- \`.bugzy/runtime/memory/event-history.md\``
+    },
+    // Step 14: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 15: Important Considerations (inline)
+    {
+      inline: true,
+      title: "Important Considerations",
+      content: `## Important Considerations
 
 ### Contextual Intelligence
 - Never process events in isolation - always consider full context
@@ -1924,42 +1140,11 @@ Create files if they don't exist:
 - Each event adds to our understanding of the system
 - Update patterns when new correlations are discovered
 - Refine decision rules based on outcomes
-- Build institutional memory through event history
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}`,
-  optionalSubagents: [
-    {
-      role: "documentation-researcher",
-      contentBlock: `#### 3.3 Use Documentation Researcher if Needed
-For events mentioning unknown features or components:
-\`\`\`
-{{INVOKE_DOCUMENTATION_RESEARCHER}} to find information about: [component/feature]
-\`\`\``
-    },
-    {
-      role: "issue-tracker",
-      contentBlock: `##### For Issue Tracking:
-
-When an issue needs to be tracked (task type: report_bug or update_story):
-\`\`\`
-{{INVOKE_ISSUE_TRACKER}}
-1. Check for duplicate issues in the tracking system
-2. For bugs: Create detailed bug report with:
-   - Clear, descriptive title
-   - Detailed description with context
-   - Step-by-step reproduction instructions
-   - Expected vs actual behavior
-   - Environment and configuration details
-   - Test case reference (if applicable)
-   - Screenshots or error logs
-3. For stories: Update status and add QA comments
-4. Track issue lifecycle and maintain categorization
-\`\`\`
-
-The issue-tracker agent will handle all aspects of issue tracking including duplicate detection, story management, QA workflow transitions, and integration with your project management system (Jira, Linear, Notion, etc.).`
+- Build institutional memory through event history`
     }
   ],
-  requiredSubagents: [],
+  requiredSubagents: ["team-communicator"],
+  optionalSubagents: ["documentation-researcher", "issue-tracker"],
   dependentTasks: ["verify-changes"]
 };
 
@@ -1972,49 +1157,40 @@ var runTestsTask = {
     description: "Execute automated Playwright tests, analyze failures, and fix test issues automatically",
     "argument-hint": '[file-pattern|tag|all] (e.g., "auth", "@smoke", "tests/specs/login.spec.ts")'
   },
-  baseContent: `# Run Tests Command
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
-
-Execute automated Playwright tests, analyze failures using JSON reports, automatically fix test issues, and log product bugs.
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Run Tests Overview",
+      content: `# Run Tests Command
 
-## Arguments
-Arguments: $ARGUMENTS
+Execute automated Playwright tests, analyze failures using JSON reports, automatically fix test issues, and log product bugs.`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `Arguments: $ARGUMENTS
 
-## Parse Arguments
+**Parse Arguments:**
 Extract the following from arguments:
 - **selector**: Test selection criteria
   - File pattern: "auth" \u2192 finds tests/specs/**/*auth*.spec.ts
   - Tag: "@smoke" \u2192 runs tests with @smoke annotation
   - Specific file: "tests/specs/login.spec.ts"
-  - All tests: "all" or "" \u2192 runs entire test suite
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Test Execution Strategy
-
-**IMPORTANT**: Before selecting tests, read \`.bugzy/runtime/test-execution-strategy.md\` to understand:
-- Available test tiers (Smoke, Component, Full Regression)
-- When to use each tier (commit, PR, release, debug)
-- Default behavior (default to @smoke unless user specifies otherwise)
-- How to interpret user intent from context keywords
-- Time/coverage trade-offs
-- Tag taxonomy
-
-Apply the strategy guidance when determining which tests to run.
-
-## Process
-
-**First**, consult \`.bugzy/runtime/test-execution-strategy.md\` decision tree to determine appropriate test tier based on user's selector and context.
-
-### Step 1: Identify Automated Tests to Run
-
-#### 1.1 Understand Test Selection
+  - All tests: "all" or "" \u2192 runs entire test suite`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Test Execution Strategy (library)
+    "read-test-strategy",
+    // Step 6: Identify Tests (inline - task-specific)
+    {
+      inline: true,
+      title: "Identify Automated Tests to Run",
+      content: `#### Understand Test Selection
 Parse the selector argument to determine which tests to run:
 
 **File Pattern** (e.g., "auth", "login"):
@@ -2031,7 +1207,7 @@ Parse the selector argument to determine which tests to run:
 **All Tests** ("all" or no selector):
 - Run entire test suite: \`tests/specs/**/*.spec.ts\`
 
-#### 1.2 Find Matching Test Files
+#### Find Matching Test Files
 Use glob patterns to find test files:
 \`\`\`bash
 # For file pattern
@@ -2044,211 +1220,39 @@ ls tests/specs/auth/login.spec.ts
 ls tests/specs/**/*.spec.ts
 \`\`\`
 
-#### 1.3 Validate Test Files Exist
+#### Validate Test Files Exist
 Check that at least one test file was found:
 - If no tests found, inform user and suggest available tests
 - List available test files if selection was unclear
 
-### Step 2: Execute Automated Playwright Tests
-
-#### 2.1 Build Playwright Command
-Construct the Playwright test command based on the selector:
-
-**For file pattern or specific file**:
-\`\`\`bash
-npx playwright test [selector]
-\`\`\`
-
-**For tag**:
-\`\`\`bash
-npx playwright test --grep "[tag]"
-\`\`\`
-
-**For all tests**:
-\`\`\`bash
-npx playwright test
-\`\`\`
-
-**Output**: Custom Bugzy reporter will create hierarchical test-runs/YYYYMMDD-HHMMSS/ structure with manifest.json
-
-#### 2.2 Execute Tests via Bash
-Run the Playwright command:
-\`\`\`bash
-npx playwright test [selector]
-\`\`\`
-
-Wait for execution to complete. This may take several minutes depending on test count.
-
-**Note**: The custom Bugzy reporter will automatically:
-- Generate timestamp in YYYYMMDD-HHMMSS format
-- Create test-runs/{timestamp}/ directory structure
-- Record execution-id.txt with BUGZY_EXECUTION_ID
-- Save results per test case in TC-{id}/exec-1/ folders
-- Generate manifest.json with complete execution summary
-
-#### 2.3 Locate and Read Test Results
-After execution completes, find and read the manifest:
-
-1. Find the test run directory (most recent):
-   \`\`\`bash
-   ls -t test-runs/ | head -1
-   \`\`\`
-
-2. Read the manifest.json file:
-   \`\`\`bash
-   cat test-runs/[timestamp]/manifest.json
-   \`\`\`
-
-3. Store the timestamp for use in test-debugger-fixer if needed
-
-### Step 3: Analyze Test Results from Manifest
-
-#### 3.1 Parse Manifest
-The Bugzy custom reporter produces structured output in manifest.json:
-\`\`\`json
-{
-  "bugzyExecutionId": "70a59676-cfd0-4ffd-b8ad-69ceff25c31d",
-  "timestamp": "20251115-123456",
-  "startTime": "2025-11-15T12:34:56.789Z",
-  "endTime": "2025-11-15T12:45:23.456Z",
-  "status": "completed",
-  "stats": {
-    "totalTests": 10,
-    "passed": 8,
-    "failed": 2,
-    "totalExecutions": 10
-  },
-  "testCases": [
+#### Confirm Selection Before Execution
+Before running tests, confirm the selection with the user if ambiguous:
+- **Clear selection** (specific file or tag): Proceed immediately
+- **Pattern match** (multiple files): List matching files and ask for confirmation if count > 5
+- **No selector** (all tests): Confirm running full suite before executing`
+    },
+    // Step 7-10: Test Execution (library steps)
+    "run-playwright-tests",
+    "parse-test-results",
+    "triage-failures",
+    "fix-test-issues",
+    // Step 11: Log Product Bugs (conditional - library step)
     {
-      "id": "TC-001-login",
-      "name": "Login functionality",
-      "totalExecutions": 1,
-      "finalStatus": "passed",
-      "executions": [
-        {
-          "number": 1,
-          "status": "passed",
-          "duration": 1234,
-          "videoFile": "video.webm",
-          "hasTrace": false,
-          "hasScreenshots": false,
-          "error": null
-        }
-      ]
+      stepId: "log-product-bugs",
+      conditionalOnSubagent: "issue-tracker"
     },
+    // Step 12: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 13: Team Communication (conditional - library step)
     {
-      "id": "TC-002-invalid-credentials",
-      "name": "Invalid credentials error",
-      "totalExecutions": 1,
-      "finalStatus": "failed",
-      "executions": [
-        {
-          "number": 1,
-          "status": "failed",
-          "duration": 2345,
-          "videoFile": "video.webm",
-          "hasTrace": true,
-          "hasScreenshots": true,
-          "error": "expect(locator).toBeVisible()..."
-        }
-      ]
-    }
-  ]
-}
-\`\`\`
-
-#### 3.2 Extract Test Results
-From the manifest, extract:
-- **Total tests**: stats.totalTests
-- **Passed tests**: stats.passed
-- **Failed tests**: stats.failed
-- **Total executions**: stats.totalExecutions (includes re-runs)
-- **Duration**: Calculate from startTime and endTime
-
-For each failed test, collect from testCases array:
-- Test ID (id field)
-- Test name (name field)
-- Final status (finalStatus field)
-- Latest execution details:
-  - Error message (executions[last].error)
-  - Duration (executions[last].duration)
-  - Video file location (test-runs/{timestamp}/{id}/exec-{num}/{videoFile})
-  - Trace availability (executions[last].hasTrace)
-  - Screenshots availability (executions[last].hasScreenshots)
-
-#### 3.3 Generate Summary Statistics
-\`\`\`markdown
-## Test Execution Summary
-- Total Tests: [count]
-- Passed: [count] ([percentage]%)
-- Failed: [count] ([percentage]%)
-- Skipped: [count] ([percentage]%)
-- Total Duration: [time]
-\`\`\`
-
-### Step 5: Triage Failed Tests
-
-After analyzing test results, triage each failure to determine if it's a product bug or test issue:
-
-#### 5.1 Triage Failed Tests FIRST
-
-**\u26A0\uFE0F IMPORTANT: Do NOT report bugs without triaging first.**
-
-For each failed test:
-
-1. **Read failure details** from JSON report (error message, stack trace)
-2. **Classify the failure:**
-   - **Product bug**: Application behaves incorrectly
-   - **Test issue**: Test code needs fixing (selector, timing, assertion)
-3. **Document classification** for next steps
-
-**Classification Guidelines:**
-- **Product Bug**: Correct test code, unexpected application behavior
-- **Test Issue**: Selector not found, timeout, race condition, wrong assertion
-
-#### 5.2 Fix Test Issues Automatically
-
-For each test classified as **[TEST ISSUE]**, use the test-debugger-fixer agent to automatically fix the test:
-
-\`\`\`
-{{INVOKE_TEST_DEBUGGER_FIXER}}
-
-For each failed test classified as a test issue (not a product bug), provide:
-- Test run timestamp: [from manifest.timestamp]
-- Test case ID: [from testCases[].id in manifest]
-- Test name/title: [from testCases[].name in manifest]
-- Error message: [from testCases[].executions[last].error]
-- Execution details path: test-runs/{timestamp}/{testCaseId}/exec-1/
-
-The agent will:
-1. Read the execution details from result.json
-2. Analyze the failure (error message, trace if available)
-3. Identify the root cause (brittle selector, missing wait, race condition, etc.)
-4. Apply appropriate fix to the test code
-5. Rerun the test
-6. The custom reporter will automatically create the next exec-N/ folder
-7. Repeat up to 3 times if needed (exec-1, exec-2, exec-3)
-8. Report success or escalate as likely product bug
-
-After test-debugger-fixer completes:
-- If fix succeeded: Mark test as fixed, add to "Tests Fixed" list
-- If still failing after 3 attempts: Reclassify as potential product bug for Step 5.3
-\`\`\`
-
-**Track Fixed Tests:**
-- Maintain list of tests fixed automatically
-- Include fix description (e.g., "Updated selector from CSS to role-based")
-- Note verification status (test now passes)
-
-{{ISSUE_TRACKER_INSTRUCTIONS}}
-
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
-
-{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
-
-### Step 6: Handle Special Cases
-
-#### If No Test Cases Found
+      stepId: "notify-team",
+      conditionalOnSubagent: "team-communicator"
+    },
+    // Step 14: Handle Special Cases (inline - task-specific)
+    {
+      inline: true,
+      title: "Handle Special Cases",
+      content: `#### If No Test Cases Found
 If no test cases match the selection criteria:
 1. Inform user that no matching test cases were found
 2. List available test cases or suggest running \`/generate-test-cases\` first
@@ -2291,128 +1295,12 @@ If selected test cases have formatting issues:
 
 **Related Documentation**:
 - \`.bugzy/runtime/test-execution-strategy.md\` - When and why to run specific tests
-- \`.bugzy/runtime/testing-best-practices.md\` - How to write tests (patterns and anti-patterns)
-
-`,
-  optionalSubagents: [
-    {
-      role: "issue-tracker",
-      contentBlock: `
-
-#### 5.3 Log Product Bugs via Issue Tracker
-
-After triage in Step 5.1, for tests classified as **[PRODUCT BUG]**, use the issue-tracker agent to log bugs:
-
-For each bug to report, use the issue-tracker agent:
-
-\`\`\`
-{{INVOKE_ISSUE_TRACKER}}
-1. Check for duplicate bugs in the tracking system
-   - The agent will automatically search for similar existing issues
-   - It maintains memory of recently reported issues
-   - Duplicate detection happens automatically - don't create manual checks
-
-2. For each new bug (non-duplicate):
-   Create detailed bug report with:
-   - **Title**: Clear, descriptive summary (e.g., "Login button fails with timeout on checkout page")
-   - **Description**:
-     - What happened vs. what was expected
-     - Impact on users
-     - Test reference: [file path] \u203A [test title]
-   - **Reproduction Steps**:
-     - List steps from the failing test
-     - Include specific test data used
-     - Note any setup requirements from test file
-   - **Test Execution Details**:
-     - Test file: [file path from JSON report]
-     - Test name: [test title from JSON report]
-     - Error message: [from JSON report]
-     - Stack trace: [from JSON report]
-     - Trace file: [path if available]
-     - Screenshots: [paths if available]
-   - **Environment Details**:
-     - Browser and version (from Playwright config)
-     - Test environment URL (from .env.testdata BASE_URL)
-     - Timestamp of failure
-   - **Severity/Priority**: Based on:
-     - Test type (smoke tests = high priority)
-     - User impact
-     - Frequency (always fails vs flaky)
-   - **Additional Context**:
-     - Error messages or stack traces from JSON report
-     - Related test files (if part of test suite)
-     - Relevant knowledge from knowledge-base.md
-
-3. Track created issues:
-   - Note the issue ID/number returned
-   - Update issue tracker memory with new bugs
-   - Prepare issue references for team communication
-\`\`\`
-
-#### 6.3 Summary of Bug Reporting
-
-After issue tracker agent completes, create a summary:
-\`\`\`markdown
-### Bug Reporting Summary
-- Total bugs found: [count of FAIL tests]
-- New bugs reported: [count of newly created issues]
-- Duplicate bugs found: [count of duplicates detected]
-- Issues not reported: [count of skipped/known issues]
-
-**New Bug Reports**:
-- [Issue ID]: [Bug title] (Test: TC-XXX, Priority: [priority])
-- [Issue ID]: [Bug title] (Test: TC-YYY, Priority: [priority])
-
-**Duplicate Bugs** (already tracked):
-- [Existing Issue ID]: [Bug title] (Matches test: TC-XXX)
-
-**Not Reported** (skipped or known):
-- TC-XXX: Skipped due to blocker failure
-- TC-YYY: Known issue documented in knowledge base
-\`\`\`
-
-**Note**: The issue tracker agent handles all duplicate detection and system integration automatically. Simply provide the bug details and let it manage the rest.`
-    },
-    {
-      role: "team-communicator",
-      contentBlock: `### Step 6: Team Communication
-
-{{INVOKE_TEAM_COMMUNICATOR}}
-
-Notify the product team about test execution:
-
-\`\`\`
-1. Post test execution summary with key statistics
-2. Highlight critical failures that need immediate attention
-3. Share important learnings about product behavior
-4. Report any potential bugs discovered during testing
-5. Ask for clarification on unexpected behaviors
-6. Provide recommendations for areas needing investigation
-7. Use appropriate urgency level based on failure severity
-\`\`\`
-
-The team communication should include:
-- **Execution summary**: Overall pass/fail statistics and timing
-- **Critical issues**: High-priority failures that need immediate attention
-- **Key learnings**: Important discoveries about product behavior
-- **Potential bugs**: Issues that may require bug reports
-- **Clarifications needed**: Unexpected behaviors requiring team input
-- **Recommendations**: Suggested follow-up actions
-
-**Communication strategy based on results**:
-- **All tests passed**: Brief positive update, highlight learnings
-- **Minor failures**: Standard update with failure details and plans
-- **Critical failures**: Urgent notification with detailed analysis
-- **New discoveries**: Separate message highlighting interesting findings
-
-**Update team communicator memory**:
-- Record test execution communication
-- Track team response patterns to test results
-- Document any clarifications provided by the team
-- Note team priorities based on their responses`
+- \`.bugzy/runtime/testing-best-practices.md\` - How to write tests (patterns and anti-patterns)`
     }
   ],
-  requiredSubagents: ["test-runner", "test-debugger-fixer"]
+  requiredSubagents: ["test-runner", "test-debugger-fixer"],
+  optionalSubagents: ["issue-tracker", "team-communicator"],
+  dependentTasks: []
 };
 
 // src/tasks/library/verify-changes.ts
@@ -2424,14 +1312,12 @@ var verifyChangesTask = {
     description: "Verify code changes with automated tests and manual verification checklists",
     "argument-hint": "[trigger-auto-detected]"
   },
-  baseContent: `# Verify Changes - Unified Multi-Trigger Workflow
-
-## SECURITY NOTICE
-**CRITICAL**: Never read the \`.env\` file. It contains ONLY secrets (passwords, API keys).
-- **Read \`.env.testdata\`** for non-secret environment variables (TEST_BASE_URL, TEST_OWNER_EMAIL, etc.)
-- \`.env.testdata\` contains actual values for test data, URLs, and non-sensitive configuration
-- For secrets: Reference variable names only (TEST_OWNER_PASSWORD) - values are injected at runtime
-- The \`.env\` file access is blocked by settings.json
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Verify Changes Overview",
+      content: `# Verify Changes - Unified Multi-Trigger Workflow
 
 ## Overview
 
@@ -2439,21 +1325,27 @@ This task performs comprehensive change verification with:
 - **Automated testing**: Execute Playwright tests with automatic triage and fixing
 - **Manual verification checklists**: Generate role-specific checklists for non-automatable scenarios
 - **Multi-trigger support**: Works from manual CLI, Slack messages, GitHub PRs, and CI/CD
-- **Smart output routing**: Results formatted and delivered to the appropriate channel
-
-## Arguments
-
-**Input**: $ARGUMENTS
-
-The input format determines the trigger source and context extraction strategy.
-
-${KNOWLEDGE_BASE_READ_INSTRUCTIONS}
-
-## Step 1: Detect Trigger Source
+- **Smart output routing**: Results formatted and delivered to the appropriate channel`
+    },
+    // Step 2: Security Notice (library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `**Input**: $ARGUMENTS
 
-Analyze the input format to determine how this task was invoked:
+The input format determines the trigger source and context extraction strategy.`
+    },
+    // Step 4: Knowledge Base Read (library)
+    "read-knowledge-base",
+    // Step 5: Detect Trigger Source (inline)
+    {
+      inline: true,
+      title: "Detect Trigger Source",
+      content: `Analyze the input format to determine how this task was invoked:
 
-### 1.1 Identify Trigger Type
+### Identify Trigger Type
 
 **GitHub PR Webhook:**
 - Input contains \`pull_request\` object with structure:
@@ -2470,7 +1362,7 @@ Analyze the input format to determine how this task was invoked:
     }
   }
   \`\`\`
-\u2192 **Trigger detected: GITHUB_PR**
+-> **Trigger detected: GITHUB_PR**
 
 **Slack Event:**
 - Input contains \`event\` object with structure:
@@ -2487,7 +1379,7 @@ Analyze the input format to determine how this task was invoked:
     }
   }
   \`\`\`
-\u2192 **Trigger detected: SLACK_MESSAGE**
+-> **Trigger detected: SLACK_MESSAGE**
 
 **CI/CD Environment:**
 - Environment variables present:
@@ -2497,24 +1389,26 @@ Analyze the input format to determine how this task was invoked:
   - \`GITHUB_BASE_REF\` (base branch)
   - \`GITHUB_HEAD_REF\` (head branch)
 - Git context available via bash commands
-\u2192 **Trigger detected: CI_CD**
+-> **Trigger detected: CI_CD**
 
 **Manual Invocation:**
 - Input is natural language, URL, or issue identifier
 - Patterns: "PR #123", GitHub URL, "PROJ-456", feature description
-\u2192 **Trigger detected: MANUAL**
-
-### 1.2 Store Trigger Context
-
-Store the detected trigger for use in Step 6 (output routing):
-- Set variable: \`TRIGGER_SOURCE\` = [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL]
-- This determines output formatting and delivery channel
+-> **Trigger detected: MANUAL**
 
-## Step 2: Extract Context Based on Trigger
+### Store Trigger Context
 
-Based on the detected trigger source, extract relevant context:
+Store the detected trigger for use in output routing:
+- Set variable: \`TRIGGER_SOURCE\` = [GITHUB_PR | SLACK_MESSAGE | CI_CD | MANUAL]
+- This determines output formatting and delivery channel`
+    },
+    // Step 6: Extract Context (inline)
+    {
+      inline: true,
+      title: "Extract Context Based on Trigger",
+      content: `Based on the detected trigger source, extract relevant context:
 
-### 2.1 GitHub PR Trigger - Extract PR Details
+### GitHub PR Trigger - Extract PR Details
 
 If trigger is GITHUB_PR:
 - **PR number**: \`pull_request.number\`
@@ -2525,9 +1419,7 @@ If trigger is GITHUB_PR:
 - **Base branch**: \`pull_request.base.ref\`
 - **Head branch**: \`pull_request.head.ref\`
 
-Optional: Fetch additional details via GitHub API if needed (PR comments, reviews)
-
-### 2.2 Slack Message Trigger - Parse Natural Language
+### Slack Message Trigger - Parse Natural Language
 
 If trigger is SLACK_MESSAGE:
 - **Message text**: \`event.text\`
@@ -2542,30 +1434,24 @@ If trigger is SLACK_MESSAGE:
 - Feature names: Quoted terms, capitalized phrases
 - Environments: "staging", "production", "preview"
 
-### 2.3 CI/CD Trigger - Read CI Environment
+### CI/CD Trigger - Read CI Environment
 
 If trigger is CI_CD:
 - **CI platform**: Read \`CI\` env var
-- **Branch**: \`GITHUB_REF\` \u2192 extract branch name
+- **Branch**: \`GITHUB_REF\` -> extract branch name
 - **Commit**: \`GITHUB_SHA\`
 - **Base branch**: \`GITHUB_BASE_REF\` (for PRs)
 - **Changed files**: Run \`git diff --name-only $BASE_SHA...$HEAD_SHA\`
 
-If in PR context, can also fetch PR number from CI env vars (e.g., \`GITHUB_EVENT_PATH\`)
-
-### 2.4 Manual Trigger - Parse User Input
+### Manual Trigger - Parse User Input
 
 If trigger is MANUAL:
 - **GitHub PR URL**: Parse to extract PR number, then fetch details via API
-  - Pattern: \`https://github.com/owner/repo/pull/123\`
-  - Extract: owner, repo, PR number
-  - Fetch: PR details, diff, comments
-- **Issue identifier**: Extract issue ID
-  - Patterns: "PROJ-123", "#456", "BUG-789"
+- **Issue identifier**: Extract issue ID (patterns: "PROJ-123", "#456", "BUG-789")
 - **Feature description**: Use text as-is for verification context
 - **Deployment URL**: Extract for testing environment
 
-### 2.5 Unified Context Structure
+### Unified Context Structure
 
 After extraction, create unified context structure:
 \`\`\`
@@ -2578,21 +1464,21 @@ CHANGE_CONTEXT = {
   environment: "staging" | "production" | URL,
   prNumber: 123 (if available),
   issueId: "PROJ-456" (if available),
-
-  // For output routing:
   slackChannel: "C123456" (if Slack trigger),
   slackThread: "1234567890.123456" (if Slack trigger),
   githubRepo: "owner/repo" (if GitHub trigger)
 }
-\`\`\`
-
-## Step 3: Determine Test Scope (Smart Selection)
-
-**IMPORTANT**: You do NOT have access to code files. Infer test scope from change **descriptions** only.
+\`\`\``
+    },
+    // Step 7: Determine Test Scope (inline)
+    {
+      inline: true,
+      title: "Determine Test Scope (Smart Selection)",
+      content: `**IMPORTANT**: You do NOT have access to code files. Infer test scope from change **descriptions** only.
 
 Based on PR title, description, and commit messages, intelligently select which tests to run:
 
-### 3.1 Infer Test Scope from Change Descriptions
+### Infer Test Scope from Change Descriptions
 
 Analyze the change description to identify affected feature areas:
 
@@ -2600,32 +1486,19 @@ Analyze the change description to identify affected feature areas:
 
 | Description Keywords | Inferred Test Scope | Example |
 |---------------------|-------------------|---------|
-| "login", "authentication", "sign in/up" | \`tests/specs/auth/\` | "Fix login page validation" \u2192 Auth tests |
-| "checkout", "payment", "purchase" | \`tests/specs/checkout/\` | "Optimize checkout flow" \u2192 Checkout tests |
-| "cart", "shopping cart", "add to cart" | \`tests/specs/cart/\` | "Update cart calculations" \u2192 Cart tests |
-| "API", "endpoint", "backend" | API test suites | "Add new user API endpoint" \u2192 User API tests |
-| "profile", "account", "settings" | \`tests/specs/profile/\` or \`tests/specs/settings/\` | "Profile page redesign" \u2192 Profile tests |
+| "login", "authentication", "sign in/up" | \`tests/specs/auth/\` | "Fix login page validation" -> Auth tests |
+| "checkout", "payment", "purchase" | \`tests/specs/checkout/\` | "Optimize checkout flow" -> Checkout tests |
+| "cart", "shopping cart", "add to cart" | \`tests/specs/cart/\` | "Update cart calculations" -> Cart tests |
+| "API", "endpoint", "backend" | API test suites | "Add new user API endpoint" -> User API tests |
+| "profile", "account", "settings" | \`tests/specs/profile/\` or \`tests/specs/settings/\` | "Profile page redesign" -> Profile tests |
 
 **Inference strategy:**
 1. **Extract feature keywords** from PR title and description
-   - PR title: "feat(checkout): Add PayPal payment option"
-   - Keywords: ["checkout", "payment"]
-   - Inferred scope: Checkout tests
-
 2. **Analyze commit messages** for conventional commit scopes
-   - \`feat(auth): Add password reset flow\` \u2192 Auth tests
-   - \`fix(cart): Resolve quantity update bug\` \u2192 Cart tests
-
 3. **Map keywords to test organization**
-   - Reference: Tests are organized by feature under \`tests/specs/\` (see \`.bugzy/runtime/testing-best-practices.md\`)
-   - Feature areas typically include: auth/, checkout/, cart/, profile/, api/, etc.
-
 4. **Identify test scope breadth from description tone**
-   - "Fix typo in button label" \u2192 Narrow scope (smoke tests)
-   - "Refactor shared utility functions" \u2192 Wide scope (full suite)
-   - "Update single component styling" \u2192 Narrow scope (component tests)
 
-### 3.2 Fallback Strategies Based on Description Analysis
+### Fallback Strategies Based on Description Analysis
 
 **Description patterns that indicate full suite:**
 - "Refactor shared/common utilities" (wide impact)
@@ -2640,30 +1513,13 @@ Analyze the change description to identify affected feature areas:
 - "Fix formatting" or "Linting fixes" (no logic change)
 
 **When description is vague or ambiguous:**
-- Examples: "Updated several components", "Various bug fixes", "Improvements"
 - **ACTION REQUIRED**: Use AskUserQuestion tool to clarify test scope
-- Provide options based on available test suites:
-  \`\`\`typescript
-  AskUserQuestion({
-    questions: [{
-      question: "The change description is broad. Which test suites should run?",
-      header: "Test Scope",
-      multiSelect: true,
-      options: [
-        { label: "Auth tests", description: "Login, signup, password reset" },
-        { label: "Checkout tests", description: "Purchase flow, payment processing" },
-        { label: "Full test suite", description: "Run all tests for comprehensive validation" },
-        { label: "Smoke tests only", description: "Quick validation of critical paths" }
-      ]
-    }]
-  })
-  \`\`\`
 
 **If specific test scope requested:**
 - User can override with: "only smoke tests", "full suite", specific test suite names
 - Honor user's explicit scope over smart selection
 
-### 3.3 Test Selection Summary
+### Test Selection Summary
 
 Generate summary of test selection based on description analysis:
 \`\`\`markdown
@@ -2673,180 +1529,51 @@ Generate summary of test selection based on description analysis:
 - **Affected test suites**: [list inferred test suite paths or names]
 - **Scope reasoning**: [explain why this scope was selected]
 - **Execution strategy**: [smart selection | full suite | smoke tests | user-specified]
-\`\`\`
-
-**Example summary:**
-\`\`\`markdown
-### Test Scope Determined
-- **Change description**: "feat(checkout): Add PayPal payment option"
-- **Identified keywords**: checkout, payment, PayPal
-- **Affected test suites**: tests/specs/checkout/payment.spec.ts, tests/specs/checkout/purchase-flow.spec.ts
-- **Scope reasoning**: Change affects checkout payment processing; running all checkout tests to validate payment integration
-- **Execution strategy**: Smart selection (checkout suite)
-\`\`\`
-
-## Step 4: Run Verification Workflow
-
-Execute comprehensive verification combining automated tests and manual checklists:
-
-### 4A: Automated Testing (Integrated from /run-tests)
-
-Execute automated Playwright tests with full triage and fixing:
-
-#### 4A.1 Execute Tests
-
-Run the selected tests via Playwright:
-\`\`\`bash
-npx playwright test [scope] --reporter=json --output=test-results/
-\`\`\`
-
-Wait for execution to complete. Capture JSON report from \`test-results/.last-run.json\`.
-
-#### 4A.2 Parse Test Results
-
-Read and analyze the JSON report:
-- Extract: Total, passed, failed, skipped counts
-- For each failed test: file path, test name, error message, stack trace, trace file
-- Calculate: Pass rate, total duration
-
-#### 4A.3 Triage Failures (Classification)
-
-#### Automatic Test Issue Fixing
-
-For each test classified as **[TEST ISSUE]**, use the test-debugger-fixer agent to automatically fix the test:
-
-\`\`\`
-{{INVOKE_TEST_DEBUGGER_FIXER}}
-
-For each failed test classified as a test issue (not a product bug), provide:
-- Test file path: [from JSON report]
-- Test name/title: [from JSON report]
-- Error message: [from JSON report]
-- Stack trace: [from JSON report]
-- Trace file path: [if available]
-
-The agent will:
-1. Read the failing test file
-2. Analyze the failure details
-3. Open browser via Playwright MCP to debug if needed
-4. Identify the root cause (brittle selector, missing wait, race condition, etc.)
-5. Apply appropriate fix to the test code
-6. Rerun the test to verify the fix
-7. Repeat up to 3 times if needed
-8. Report success or escalate as likely product bug
-
-After test-debugger-fixer completes:
-- If fix succeeded: Mark test as fixed, add to "Tests Fixed" list
-- If still failing after 3 attempts: Reclassify as potential product bug
-\`\`\`
-
-**Track Fixed Tests:**
-- Maintain list of tests fixed automatically
-- Include fix description (e.g., "Updated selector from CSS to role-based")
-- Note verification status (test now passes)
-- Reference .bugzy/runtime/testing-best-practices.md for best practices
-
-For each failed test, classify as:
-- **[PRODUCT BUG]**: Correct test code, but application behaves incorrectly
-- **[TEST ISSUE]**: Test code needs fixing (selector, timing, assertion)
-
-Classification guidelines:
-- Product Bug: Expected behavior not met, functional issue
-- Test Issue: Selector not found, timeout, race condition, brittle locator
-
-#### 4A.4 Fix Test Issues Automatically
-
-For tests classified as [TEST ISSUE]:
-- {{INVOKE_TEST_DEBUGGER_FIXER}} to analyze and fix
-- Agent debugs with browser if needed
-- Applies fix (selector update, wait condition, assertion correction)
-- Reruns test to verify fix (10x for flaky tests)
-- Max 3 fix attempts, then reclassify as product bug
-
-Track fixed tests with:
-- Test file path
-- Fix description
-- Verification status (now passes)
-
-#### 4A.5 Log Product Bugs
-
-{{ISSUE_TRACKER_INSTRUCTIONS}}
-
-For tests classified as [PRODUCT BUG]:
-- {{INVOKE_ISSUE_TRACKER}} to create bug reports
-- Agent checks for duplicates automatically
-- Creates detailed report with:
-  - Title, description, reproduction steps
-  - Test reference, error details, stack trace
-  - Screenshots, traces, environment details
-  - Severity based on test type and impact
-- Returns issue ID for tracking
-
-### 4B: Manual Verification Checklist (NEW)
-
-Generate human-readable checklist for non-automatable scenarios:
-
-#### Generate Manual Verification Checklist
-
-Analyze the code changes and generate a manual verification checklist for scenarios that cannot be automated.
+\`\`\``
+    },
+    // Step 8-11: Test Execution (library steps)
+    "run-playwright-tests",
+    "parse-test-results",
+    "triage-failures",
+    "fix-test-issues",
+    // Step 12: Log Product Bugs (conditional library step)
+    {
+      stepId: "log-product-bugs",
+      conditionalOnSubagent: "issue-tracker"
+    },
+    // Step 13: Generate Manual Verification Checklist (inline)
+    {
+      inline: true,
+      title: "Generate Manual Verification Checklist",
+      content: `Generate human-readable checklist for non-automatable scenarios:
 
-#### Analyze Change Context
+### Analyze Change Context
 
 Review the provided context to understand what changed:
 - Read PR title, description, and commit messages
 - Identify change types from descriptions: visual, UX, forms, mobile, accessibility, edge cases
 - Understand the scope and impact of changes from the change descriptions
 
-#### Identify Non-Automatable Scenarios
+### Identify Non-Automatable Scenarios
 
 Based on the change analysis, identify scenarios that require human verification:
 
 **1. Visual Design Changes** (CSS, styling, design files, graphics)
-- Color schemes, gradients, shadows
-- Typography, font sizes, line heights
-- Spacing, margins, padding, alignment
-- Visual consistency across components
-- Brand guideline compliance
-\u2192 Add **Design Validation** checklist items
+-> Add **Design Validation** checklist items
 
 **2. UX Interaction Changes** (animations, transitions, gestures, micro-interactions)
-- Animation smoothness (60fps expectation)
-- Transition timing and easing
-- Interaction responsiveness and feel
-- Loading states and skeleton screens
-- Hover effects, focus states
-\u2192 Add **UX Feel** checklist items
+-> Add **UX Feel** checklist items
 
 **3. Form and Input Changes** (new form fields, input validation, user input)
-- Screen reader compatibility
-- Keyboard navigation (Tab order, Enter to submit)
-- Error message clarity and placement
-- Color contrast (WCAG 2.1 AA: 4.5:1 ratio for text)
-- Focus indicators visibility
-\u2192 Add **Accessibility** checklist items
+-> Add **Accessibility** checklist items
 
 **4. Mobile and Responsive Changes** (media queries, touch interactions, viewport)
-- Touch target sizes (\u226544px iOS, \u226548dp Android)
-- Responsive layout breakpoints
-- Mobile keyboard behavior (doesn't obscure inputs)
-- Swipe gestures and touch interactions
-- Pinch-to-zoom functionality
-\u2192 Add **Mobile Experience** checklist items
+-> Add **Mobile Experience** checklist items
 
 **5. Low ROI or Rare Scenarios** (edge cases, one-time migrations, rare user paths)
-- Scenarios used by < 1% of users
-- Complex multi-system integrations
-- One-time data migrations
-- Leap year, DST, timezone edge cases
-\u2192 Add **Exploratory Testing** notes
-
-**6. Cross-Browser Visual Consistency** (layout rendering differences)
-- Layout consistency across Chrome, Firefox, Safari
-- CSS feature support differences
-- Font rendering variations
-\u2192 Add **Cross-Browser** checklist items (if significant visual changes)
+-> Add **Exploratory Testing** notes
 
-#### Generate Role-Specific Checklist Items
+### Generate Role-Specific Checklist Items
 
 For each identified scenario, create clear, actionable checklist items:
 
@@ -2855,113 +1582,24 @@ For each identified scenario, create clear, actionable checklist items:
 - Assigned role (@design-team, @qa-team, @a11y-team, @mobile-team)
 - Acceptance criteria (what constitutes pass/fail)
 - Reference to standards when applicable (WCAG, iOS HIG, Material Design)
-- Priority indicator (\u{1F534} critical, \u{1F7E1} important, \u{1F7E2} nice-to-have)
+- Priority indicator (red circle critical, yellow circle important, green circle nice-to-have)
 
 **Example checklist items:**
 
 **Design Validation (@design-team)**
-- [ ] \u{1F534} Login button color matches brand guidelines (#FF6B35)
-- [ ] \u{1F7E1} Loading spinner animation smooth (60fps, no jank)
-- [ ] \u{1F7E1} Card shadows match design system (elevation-2: 0 2px 4px rgba(0,0,0,0.1))
-- [ ] \u{1F7E2} Hover states provide appropriate visual feedback
+- [ ] Login button color matches brand guidelines (#FF6B35)
+- [ ] Loading spinner animation smooth (60fps, no jank)
 
 **Accessibility (@a11y-team)**
-- [ ] \u{1F534} Screen reader announces form errors clearly (tested with VoiceOver/NVDA)
-- [ ] \u{1F534} Keyboard navigation: Tab through all interactive elements in logical order
-- [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)
-- [ ] \u{1F7E1} Focus indicators visible on all interactive elements
+- [ ] Screen reader announces form errors clearly (tested with VoiceOver/NVDA)
+- [ ] Keyboard navigation: Tab through all interactive elements in logical order
+- [ ] Color contrast meets WCAG 2.1 AA (4.5:1 for body text, 3:1 for large text)
 
 **Mobile Experience (@qa-team, @mobile-team)**
-- [ ] \u{1F534} Touch targets \u226544px (iOS Human Interface Guidelines)
-- [ ] \u{1F534} Mobile keyboard doesn't obscure input fields on iOS/Android
-- [ ] \u{1F7E1} Swipe gestures work naturally without conflicts
-- [ ] \u{1F7E1} Responsive layout adapts properly on iPhone SE (smallest screen)
-
-**UX Feel (@design-team, @qa-team)**
-- [ ] \u{1F7E1} Page transitions smooth and not jarring
-- [ ] \u{1F7E1} Button click feedback immediate (< 100ms perceived response)
-- [ ] \u{1F7E2} Loading states prevent confusion during data fetch
-
-**Exploratory Testing (@qa-team)**
-- [ ] \u{1F7E2} Test edge case: User submits form during network timeout
-- [ ] \u{1F7E2} Test edge case: User navigates back during submission
-
-#### Format for Output Channel
-
-Adapt the checklist format based on the output channel (determined by trigger source):
+- [ ] Touch targets greater than or equal to 44px (iOS Human Interface Guidelines)
+- [ ] Mobile keyboard doesn't obscure input fields on iOS/Android
 
-**Terminal (Manual Trigger):**
-\`\`\`markdown
-MANUAL VERIFICATION CHECKLIST:
-Please verify the following before merging:
-
-Design Validation (@design-team):
-  [ ] \u{1F534} Checkout button colors match brand guidelines (#FF6B35)
-  [ ] \u{1F7E1} Loading spinner animation smooth (60fps)
-
-Accessibility (@a11y-team):
-  [ ] \u{1F534} Screen reader announces error messages
-  [ ] \u{1F534} Keyboard navigation works (Tab order logical)
-  [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 ratio)
-
-Mobile Experience (@qa-team):
-  [ ] \u{1F534} Touch targets \u226544px (iOS HIG)
-  [ ] \u{1F7E1} Responsive layout works on iPhone SE
-\`\`\`
-
-**Slack (Slack Trigger):**
-\`\`\`markdown
-*Manual Verification Needed:*
-\u25A1 Visual: Button colors, animations (60fps)
-\u25A1 Mobile: Touch targets \u226544px
-\u25A1 A11y: Screen reader, keyboard nav, contrast
-
-cc @design-team @qa-team @a11y-team
-\`\`\`
-
-**GitHub PR Comment (GitHub Trigger):**
-\`\`\`markdown
-### Manual Verification Required
-
-The following scenarios require human verification before release:
-
-#### Design Validation (@design-team)
-- [ ] \u{1F534} Checkout button colors match brand guidelines (#FF6B35)
-- [ ] \u{1F7E1} Loading spinner animation smooth (60fps)
-- [ ] \u{1F7E1} Card shadows match design system
-
-#### Accessibility (@a11y-team)
-- [ ] \u{1F534} Screen reader announces error messages (VoiceOver/NVDA)
-- [ ] \u{1F534} Keyboard navigation through all form fields (Tab order)
-- [ ] \u{1F534} Color contrast meets WCAG 2.1 AA (4.5:1 for body text)
-
-#### Mobile Experience (@qa-team)
-- [ ] \u{1F534} Touch targets \u226544px (iOS Human Interface Guidelines)
-- [ ] \u{1F534} Mobile keyboard doesn't obscure input fields
-- [ ] \u{1F7E1} Responsive layout works on iPhone SE (375x667)
-
----
-*Legend: \u{1F534} Critical \u2022 \u{1F7E1} Important \u2022 \u{1F7E2} Nice-to-have*
-\`\`\`
-
-#### Guidelines for Quality Checklists
-
-**DO:**
-- Make each item verifiable (clear pass/fail criteria)
-- Include context (why this needs manual verification)
-- Reference standards (WCAG, iOS HIG, Material Design)
-- Assign to specific roles
-- Prioritize items (critical, important, nice-to-have)
-- Be specific (not "check colors" but "Login button color matches #FF6B35")
-
-**DON'T:**
-- Create vague items ("test thoroughly")
-- List items that can be automated
-- Skip role assignments
-- Forget acceptance criteria
-- Omit priority indicators
-
-#### When NO Manual Verification Needed
+### When NO Manual Verification Needed
 
 If the changes are purely:
 - Backend logic (no UI changes)
@@ -2973,18 +1611,13 @@ Output:
 \`\`\`markdown
 **Manual Verification:** Not required for this change.
 All user-facing changes are fully covered by automated tests.
-\`\`\`
-
-#### Summary
-
-After generating the checklist:
-- Count total items by priority (\u{1F534} critical, \u{1F7E1} important, \u{1F7E2} nice-to-have)
-- Estimate time needed (e.g., "~30 minutes for design QA, ~45 minutes for accessibility testing")
-- Suggest who should perform each category of checks
-
-### 4C: Aggregate Results
-
-Combine automated and manual verification results:
+\`\`\``
+    },
+    // Step 14: Aggregate Results (inline)
+    {
+      inline: true,
+      title: "Aggregate Verification Results",
+      content: `Combine automated and manual verification results:
 
 \`\`\`markdown
 ## Verification Results Summary
@@ -2998,231 +1631,99 @@ Combine automated and manual verification results:
 - Duration: [time]
 
 ### Manual Verification Required
-[Checklist generated in 4B, or "Not required"]
+[Checklist generated in previous step, or "Not required"]
 
 ### Overall Recommendation
-[\u2705 Safe to merge | \u26A0\uFE0F Review bugs before merging | \u274C Do not merge]
-\`\`\`
-
-## Step 5: Understanding the Change (Documentation Research)
-
-{{DOCUMENTATION_RESEARCHER_INSTRUCTIONS}}
-
-Before proceeding with test creation or execution, ensure requirements are clear through ambiguity detection and adaptive exploration.
-
-**Note**: For detailed exploration and clarification protocols, refer to the complete instructions below. Adapt the depth of exploration based on requirement clarity and use the clarification protocol to detect ambiguity, assess severity, and seek clarification when needed.
-
-After clarification and exploration, analyze the change to determine the verification approach:
-
-### 5.1 Identify Test Scope
-Based on the change description, exploration findings, and clarified requirements:
-- **Direct impact**: Which features/functionality are directly modified
-- **Indirect impact**: What else might be affected (dependencies, integrations)
-- **Regression risk**: Existing functionality that should be retested
-- **New functionality**: Features that need new test coverage
-
-### 5.2 Determine Verification Strategy
-Plan your testing approach based on validated requirements:
-- **Priority areas**: Critical paths that must work
-- **Test types needed**: Functional, regression, integration, UI/UX
-- **Test data requirements**: What test accounts, data, or scenarios needed
-- **Success criteria**: What determines the change is working correctly (now clearly defined)
-
-## Step 6: Report Results (Multi-Channel Output)
-
-Route output based on trigger source (from Step 1):
-
-### 6.1 MANUAL Trigger \u2192 Terminal Output
-
-Format as comprehensive markdown report for terminal display:
-
-\`\`\`markdown
-# Test Verification Report
-
-## Change Summary
-- **What Changed**: [Brief description]
-- **Scope**: [Affected features/areas]
-- **Changed Files**: [count] files
-
-## Automated Test Results
-### Statistics
-- Total Tests: [count]
-- Passed: [count] ([percentage]%)
-- Failed: [count]
-- Test Issues Fixed: [count]
-- Product Bugs Logged: [count]
-- Duration: [time]
-
-### Tests Fixed Automatically
-[For each fixed test:
-- **Test**: [file path] \u203A [test name]
-- **Issue**: [problem found]
-- **Fix**: [what was changed]
-- **Status**: \u2705 Now passing
-]
-
-### Product Bugs Logged
-[For each bug:
-- **Issue**: [ISSUE-123] [Bug title]
-- **Test**: [test file] \u203A [test name]
-- **Severity**: [priority]
-- **Link**: [issue tracker URL]
-]
-
-## Manual Verification Checklist
-
-[Insert checklist from Step 4B]
-
-## Recommendation
-[\u2705 Safe to merge - all automated tests pass, complete manual checks before release]
-[\u26A0\uFE0F Review bugs before merging - [X] bugs need attention]
-[\u274C Do not merge - critical failures]
-
-## Test Artifacts
-- JSON Report: test-results/.last-run.json
-- HTML Report: playwright-report/index.html
-- Traces: test-results/[test-id]/trace.zip
-- Screenshots: test-results/[test-id]/screenshots/
-\`\`\`
-
-### 6.2 SLACK_MESSAGE Trigger \u2192 Thread Reply
-
-{{TEAM_COMMUNICATOR_INSTRUCTIONS}}
-
-{{INVOKE_TEAM_COMMUNICATOR}} to post concise results to Slack thread:
-
-\`\`\`
-Post verification results.
-
-**Channel**: [from CHANGE_CONTEXT.slackChannel]
-**Thread**: [from CHANGE_CONTEXT.slackThread]
-
-**Message**:
-\u{1F9EA} *Verification Results for [change title]*
-
-*Automated:* \u2705 [passed]/[total] tests passed ([duration])
-[If test issues fixed:] \u{1F527} [count] test issues auto-fixed
-[If bugs logged:] \u{1F41B} [count] bugs logged ([list issue IDs])
-
-*Manual Verification Needed:*
-[Concise checklist summary - collapsed/expandable]
-\u25A1 Visual: [key items]
-\u25A1 Mobile: [key items]
-\u25A1 A11y: [key items]
-
-*Recommendation:* [\u2705 Safe to merge | \u26A0\uFE0F Review bugs | \u274C Blocked]
-
-[If bugs logged:] cc @[relevant-team-members]
-[Link to full test report if available]
-\`\`\`
-
-### 6.3 GITHUB_PR Trigger \u2192 PR Comment
-
-Use GitHub API to post comprehensive comment on PR:
-
-**Format as GitHub-flavored markdown:**
-\`\`\`markdown
-## \u{1F9EA} Test Verification Results
-
-**Status:** [\u2705 All tests passed | \u26A0\uFE0F Issues found | \u274C Critical failures]
-
-### Automated Tests
-| Metric | Value |
-|--------|-------|
-| Total Tests | [count] |
-| Passed | \u2705 [count] ([percentage]%) |
-| Failed | \u274C [count] |
-| Test Issues Fixed | \u{1F527} [count] |
-| Product Bugs Logged | \u{1F41B} [count] |
-| Duration | \u23F1\uFE0F [time] |
-
-### Failed Tests (Triaged)
-
-[For each failure:]
-
-#### \u274C **[Test Name]**
-- **File:** \`[test-file-path]\`
-- **Cause:** [Product bug | Test issue]
-- **Action:** [Bug logged: [ISSUE-123](url) | Fixed: [commit-hash](url)]
-- **Details:**
-  \`\`\`
-  [Error message]
-  \`\`\`
-
-### Tests Fixed Automatically
-
-[For each fixed test:]
-- \u2705 **[Test Name]** (\`[file-path]\`)
-  - **Issue:** [brittle selector | missing wait | race condition]
-  - **Fix:** [description of fix applied]
-  - **Verified:** Passes 10/10 runs
-
-### Product Bugs Logged
-
-[For each bug:]
-- \u{1F41B} **[[ISSUE-123](url)]** [Bug title]
-  - **Test:** \`[test-file]\` \u203A [test name]
-  - **Severity:** [\u{1F534} Critical | \u{1F7E1} Important | \u{1F7E2} Minor]
-  - **Assignee:** @[backend-team | frontend-team]
-
-### Manual Verification Required
-
-The following scenarios require human verification before release:
-
-#### Design Validation (@design-team)
-- [ ] \u{1F534} [Critical design check]
-- [ ] \u{1F7E1} [Important design check]
-
-#### Accessibility (@a11y-team)
-- [ ] \u{1F534} [Critical a11y check]
-- [ ] \u{1F7E1} [Important a11y check]
-
-#### Mobile Experience (@qa-team)
-- [ ] \u{1F534} [Critical mobile check]
-- [ ] \u{1F7E1} [Important mobile check]
-
----
-*Legend: \u{1F534} Critical \u2022 \u{1F7E1} Important \u2022 \u{1F7E2} Nice-to-have*
-
-### Test Artifacts
-- [Full HTML Report](playwright-report/index.html)
-- [Test Traces](test-results/)
-
-### Recommendation
-[\u2705 **Safe to merge** - All automated tests pass, complete manual checks before release]
-[\u26A0\uFE0F **Review required** - [X] bugs need attention, complete manual checks]
-[\u274C **Do not merge** - Critical failures must be resolved first]
-
----
-*\u{1F916} Automated by Bugzy \u2022 [View Test Code](tests/specs/) \u2022 [Manual Test Cases](test-cases/)*
-\`\`\`
+[Safe to merge | Review bugs before merging | Do not merge]
+\`\`\``
+    },
+    // Step 15: Documentation Research (conditional inline)
+    {
+      inline: true,
+      title: "Understanding the Change (Documentation Research)",
+      content: `{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive context about the changed features:
 
-**Post comment via GitHub API:**
-- Endpoint: \`POST /repos/{owner}/{repo}/issues/{pr_number}/comments\`
-- Use GitHub MCP or bash with \`gh\` CLI
-- Requires GITHUB_TOKEN from environment
+Explore project documentation related to the changes.
 
-### 6.4 CI_CD Trigger \u2192 Build Log + PR Comment
+Specifically gather:
+- Product specifications for affected features
+- User stories and acceptance criteria
+- Technical architecture documentation
+- API endpoints and contracts
+- User roles and permissions relevant to the change
+- Business rules and validations
+- UI/UX specifications
+- Known limitations or constraints
+- Related bug reports or known issues
+- Existing test documentation for this area
 
-**Output to CI build log:**
-- Print detailed results to stdout (captured by CI)
-- Use ANSI colors if supported by CI platform
-- Same format as MANUAL terminal output
+The agent will:
+1. Check its memory for previously discovered documentation
+2. Explore workspace for relevant pages and databases
+3. Build comprehensive understanding of the affected features
+4. Return synthesized information to inform testing strategy
 
-**Exit with appropriate code:**
+Use this information to:
+- Better understand the change context
+- Identify comprehensive test scenarios
+- Recognize integration points and dependencies
+- Spot potential edge cases or risk areas
+- Enhance manual verification checklist generation`,
+      conditionalOnSubagent: "documentation-researcher"
+    },
+    // Step 16: Report Results (inline)
+    {
+      inline: true,
+      title: "Report Results (Multi-Channel Output)",
+      content: `Route output based on trigger source:
+
+### MANUAL Trigger -> Terminal Output
+
+Format as comprehensive markdown report for terminal display with:
+- Change Summary (what changed, scope, affected files)
+- Automated Test Results (statistics, tests fixed, bugs logged)
+- Manual Verification Checklist
+- Recommendation (safe to merge / review / do not merge)
+- Test Artifacts (JSON report, HTML report, traces, screenshots)
+
+### SLACK_MESSAGE Trigger -> Thread Reply
+
+{{INVOKE_TEAM_COMMUNICATOR}} to post concise results to Slack thread with:
+- Verification results summary
+- Critical failures that need immediate attention
+- Bugs logged with issue tracker links
+- Manual verification checklist summary
+- Recommendation and next steps
+- Tag relevant team members for critical issues
+
+### GITHUB_PR Trigger -> PR Comment
+
+Use GitHub API to post comprehensive comment on PR with:
+- Status (All tests passed / Issues found / Critical failures)
+- Automated Tests table (Total, Passed, Failed, Fixed, Bugs, Duration)
+- Failed Tests (triaged and with actions taken)
+- Tests Fixed Automatically (issue, fix, verified)
+- Product Bugs Logged (issue ID, title, test, severity)
+- Manual Verification Required (checklist)
+- Test Artifacts links
+- Recommendation
+
+### CI_CD Trigger -> Build Log + PR Comment
+
+Output to CI build log (print detailed results to stdout) and exit with appropriate code:
 - Exit 0: All tests passed (safe to merge)
 - Exit 1: Tests failed or critical bugs found (block merge)
 
-**Post PR comment if GitHub context available:**
-- Check for PR number in CI environment
-- If available: Post comment using 6.3 format
-- Also notify team via Slack if critical failures
-
-## Additional Steps
-
-### Handle Special Cases
-
-**If no tests found for changed files:**
+Post PR comment if GitHub context available.`,
+      conditionalOnSubagent: "team-communicator"
+    },
+    // Step 17: Knowledge Base Update (library)
+    "update-knowledge-base",
+    // Step 18: Handle Special Cases (inline)
+    {
+      inline: true,
+      title: "Handle Special Cases",
+      content: `**If no tests found for changed files:**
 - Inform user: "No automated tests found for changed files"
 - Recommend: "Run smoke test suite for basic validation"
 - Still generate manual verification checklist
@@ -3236,8 +1737,6 @@ The following scenarios require human verification before release:
 - Suggest troubleshooting steps
 - Don't proceed with triage if tests didn't run
 
-${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
-
 ## Important Notes
 
 - This task handles **all trigger sources** with a single unified workflow
@@ -3248,162 +1747,172 @@ ${KNOWLEDGE_BASE_UPDATE_INSTRUCTIONS}
 - Product bugs are logged with **automatic duplicate detection**
 - Test issues are fixed automatically with **verification**
 - Results include both automated and manual verification items
-- For best results, ensure:
-  - Playwright is installed (\`npx playwright install\`)
-  - Environment variables configured (copy \`.env.testdata\` to \`.env\`)
-  - GitHub token available for PR comments (if GitHub trigger)
-  - Slack integration configured (if Slack trigger)
-  - Issue tracker configured (Linear, Jira, etc.)
 
 ## Success Criteria
 
 A successful verification includes:
-1. \u2705 Trigger source correctly detected
-2. \u2705 Context extracted completely
-3. \u2705 Tests executed (or skipped with explanation)
-4. \u2705 All failures triaged (product bug vs test issue)
-5. \u2705 Test issues fixed automatically (when possible)
-6. \u2705 Product bugs logged to issue tracker
-7. \u2705 Manual verification checklist generated
-8. \u2705 Results formatted for output channel
-9. \u2705 Results delivered to appropriate destination
-10. \u2705 Clear recommendation provided (merge / review / block)`,
-  optionalSubagents: [
-    {
-      role: "documentation-researcher",
-      contentBlock: `#### Research Project Documentation
-
-{{INVOKE_DOCUMENTATION_RESEARCHER}} to gather comprehensive context about the changed features:
-
-\`\`\`
-Explore project documentation related to the changes.
-
-Specifically gather:
-- Product specifications for affected features
-- User stories and acceptance criteria
-- Technical architecture documentation
-- API endpoints and contracts
-- User roles and permissions relevant to the change
-- Business rules and validations
-- UI/UX specifications
-- Known limitations or constraints
-- Related bug reports or known issues
-- Existing test documentation for this area
-\`\`\`
-
-The agent will:
-1. Check its memory for previously discovered documentation
-2. Explore workspace for relevant pages and databases
-3. Build comprehensive understanding of the affected features
-4. Return synthesized information to inform testing strategy
+1. Trigger source correctly detected
+2. Context extracted completely
+3. Tests executed (or skipped with explanation)
+4. All failures triaged (product bug vs test issue)
+5. Test issues fixed automatically (when possible)
+6. Product bugs logged to issue tracker
+7. Manual verification checklist generated
+8. Results formatted for output channel
+9. Results delivered to appropriate destination
+10. Clear recommendation provided (merge / review / block)`
+    }
+  ],
+  requiredSubagents: ["test-runner", "test-debugger-fixer"],
+  optionalSubagents: ["documentation-researcher", "issue-tracker", "team-communicator"],
+  dependentTasks: []
+};
 
-Use this information to:
-- Better understand the change context
-- Identify comprehensive test scenarios
-- Recognize integration points and dependencies
-- Spot potential edge cases or risk areas
-- Enhance manual verification checklist generation`
+// src/tasks/library/onboard-testing.ts
+var onboardTestingTask = {
+  slug: TASK_SLUGS.ONBOARD_TESTING,
+  name: "Onboard Testing",
+  description: "Complete workflow: explore application, generate test plan, create test cases, run tests, fix issues, and report results",
+  frontmatter: {
+    description: "Complete test coverage workflow - from exploration to passing tests",
+    "argument-hint": "<focus-area-or-feature-description>"
+  },
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Onboard Testing Overview",
+      content: `## Overview
+
+This command orchestrates the complete test coverage workflow in a single execution:
+1. **Phase 1**: Read project context and explore application
+2. **Phase 2**: Generate lightweight test plan
+3. **Phase 3**: Generate and verify test cases (create + fix until passing)
+4. **Phase 4**: Triage failures and fix test issues
+5. **Phase 5**: Log product bugs
+6. **Phase 6**: Final report`
     },
+    // Step 2: Security Notice (from library)
+    "security-notice",
+    // Step 3: Arguments (inline)
     {
-      role: "issue-tracker",
-      contentBlock: `#### Log Product Bugs
-
-For tests classified as **[PRODUCT BUG]**, {{INVOKE_ISSUE_TRACKER}} to log bugs:
-
-\`\`\`
-1. Check for duplicate bugs in the tracking system
-   - The agent will automatically search for similar existing issues
-   - It maintains memory of recently reported issues
-   - Duplicate detection happens automatically - don't create manual checks
-
-2. For each new bug (non-duplicate):
-   Create detailed bug report with:
-   - **Title**: Clear, descriptive summary (e.g., "Login button fails with timeout on checkout page")
-   - **Description**:
-     - What happened vs. what was expected
-     - Impact on users
-     - Test reference: [file path] \u203A [test title]
-   - **Reproduction Steps**:
-     - List steps from the failing test
-     - Include specific test data used
-     - Note any setup requirements from test file
-   - **Test Execution Details**:
-     - Test file: [file path from JSON report]
-     - Test name: [test title from JSON report]
-     - Error message: [from JSON report]
-     - Stack trace: [from JSON report]
-     - Trace file: [path if available]
-     - Screenshots: [paths if available]
-   - **Environment Details**:
-     - Browser and version (from Playwright config)
-     - Test environment URL (from .env.testdata BASE_URL)
-     - Timestamp of failure
-   - **Severity/Priority**: Based on:
-     - Test type (smoke tests = high priority)
-     - User impact
-     - Frequency (always fails vs flaky)
-   - **Additional Context**:
-     - Error messages or stack traces from JSON report
-     - Related test files (if part of test suite)
-     - Relevant knowledge from knowledge-base.md
-
-3. Track created issues:
-   - Note the issue ID/number returned
-   - Update issue tracker memory with new bugs
-   - Prepare issue references for team communication
-\`\`\`
-
-**Note**: The issue tracker agent handles all duplicate detection and system integration automatically. Simply provide the bug details and let it manage the rest.`
+      inline: true,
+      title: "Arguments",
+      content: `Focus area: $ARGUMENTS`
     },
+    // Phase 1: Setup
+    "read-knowledge-base",
+    // Phase 2: Exploration Protocol
+    "exploration-protocol",
+    // Execute exploration via test-runner
+    "create-exploration-test-case",
+    "run-exploration",
+    "process-exploration-results",
+    // Phase 3: Test Plan Generation
+    "generate-test-plan",
+    "extract-env-variables",
+    // Phase 4: Test Case Generation
+    "generate-test-cases",
+    "automate-test-cases",
+    // Phase 5: Test Execution
+    "run-playwright-tests",
+    "parse-test-results",
+    // Phase 6: Triage and Fix (NEW - was missing from full-test-coverage)
+    "triage-failures",
+    "fix-test-issues",
     {
-      role: "team-communicator",
-      contentBlock: `#### Team Communication
-
-{{INVOKE_TEAM_COMMUNICATOR}} to share verification results (primarily for Slack trigger, but can be used for other triggers):
-
-\`\`\`
-1. Post verification results summary
-2. Highlight critical failures that need immediate attention
-3. Share bugs logged with issue tracker links
-4. Provide manual verification checklist summary
-5. Recommend next steps based on results
-6. Tag relevant team members for critical issues
-7. Use appropriate urgency level based on failure severity
-\`\`\`
+      stepId: "log-product-bugs",
+      conditionalOnSubagent: "issue-tracker"
+    },
+    // Phase 7: Reporting and Communication
+    "update-knowledge-base",
+    {
+      stepId: "notify-team",
+      conditionalOnSubagent: "team-communicator"
+    },
+    "generate-final-report"
+  ],
+  requiredSubagents: ["test-runner", "test-code-generator", "test-debugger-fixer"],
+  optionalSubagents: ["documentation-researcher", "team-communicator", "issue-tracker"],
+  dependentTasks: ["run-tests", "generate-test-cases"]
+};
 
-The team communication should include:
-- **Execution summary**: Overall pass/fail statistics and timing
-- **Tests fixed**: Count of test issues fixed automatically
-- **Bugs logged**: Product bugs reported to issue tracker
-- **Manual checklist**: Summary of manual verification items
-- **Recommendation**: Safe to merge / Review required / Do not merge
-- **Test artifacts**: Links to reports, traces, screenshots
-
-**Communication strategy based on trigger**:
-- **Slack**: Post concise message with expandable details in thread
-- **Manual**: Full detailed report in terminal
-- **GitHub PR**: Comprehensive PR comment with tables and checklists
-- **CI/CD**: Build log output + optional Slack notification for critical failures
-
-**Update team communicator memory**:
-- Record verification communication
-- Track response patterns by trigger type
-- Document team preferences for detail level
-- Note which team members respond to which types of issues`
-    }
+// src/tasks/library/explore-application.ts
+var exploreApplicationTask = {
+  slug: TASK_SLUGS.EXPLORE_APPLICATION,
+  name: "Explore Application",
+  description: "Systematically explore application to discover UI elements, workflows, and behaviors",
+  frontmatter: {
+    description: "Explore application to discover UI, workflows, and behaviors",
+    "argument-hint": "--focus [area] --depth [shallow|deep] --system [name]"
+  },
+  steps: [
+    // Step 1: Overview (inline)
+    {
+      inline: true,
+      title: "Explore Application Overview",
+      content: `Discover actual UI elements, workflows, and behaviors using the test-runner agent. Updates test plan and project documentation with findings.`
+    },
+    // Step 2: Security Notice (from library)
+    "security-notice",
+    // Step 3: Arguments (inline)
+    {
+      inline: true,
+      title: "Arguments",
+      content: `**Arguments**: $ARGUMENTS
+
+**Parse:**
+- **focus**: auth, navigation, search, content, admin (default: comprehensive)
+- **depth**: shallow (15-20 min) or deep (45-60 min, default)
+- **system**: target system (optional for multi-system setups)`
+    },
+    // Setup
+    "read-knowledge-base",
+    "load-project-context",
+    // Exploration Protocol (adaptive depth)
+    "exploration-protocol",
+    // Execute
+    "create-exploration-test-case",
+    "run-exploration",
+    "process-exploration-results",
+    // Update
+    "update-exploration-artifacts",
+    // Team Communication (conditional inline)
+    {
+      inline: true,
+      title: "Team Communication",
+      content: `{{INVOKE_TEAM_COMMUNICATOR}} to notify the product team about exploration findings:
+
+\`\`\`
+1. Post an update about exploration completion
+2. Summarize key discoveries:
+   - UI elements and workflows identified
+   - Behaviors documented
+   - Areas needing further investigation
+3. Share exploration report location
+4. Ask for team feedback on findings
+5. Use appropriate channel and threading
+\`\`\``,
+      conditionalOnSubagent: "team-communicator"
+    },
+    "cleanup-temp-files",
+    "update-knowledge-base"
   ],
-  requiredSubagents: ["test-runner", "test-debugger-fixer"]
+  requiredSubagents: ["test-runner"],
+  optionalSubagents: ["team-communicator"],
+  dependentTasks: []
 };
 
 // src/tasks/index.ts
 var TASK_TEMPLATES = {
-  [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask,
   [TASK_SLUGS.GENERATE_TEST_CASES]: generateTestCasesTask,
   [TASK_SLUGS.GENERATE_TEST_PLAN]: generateTestPlanTask,
   [TASK_SLUGS.HANDLE_MESSAGE]: handleMessageTask,
   [TASK_SLUGS.PROCESS_EVENT]: processEventTask,
   [TASK_SLUGS.RUN_TESTS]: runTestsTask,
-  [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask
+  [TASK_SLUGS.VERIFY_CHANGES]: verifyChangesTask,
+  [TASK_SLUGS.ONBOARD_TESTING]: onboardTestingTask,
+  [TASK_SLUGS.EXPLORE_APPLICATION]: exploreApplicationTask
 };
 function getTaskTemplate(slug) {
   return TASK_TEMPLATES[slug];
@@ -3414,50 +1923,14 @@ function getAllTaskSlugs() {
 function isTaskRegistered(slug) {
   return TASK_TEMPLATES[slug] !== void 0;
 }
-function buildSlashCommandsConfig(slugs) {
-  const configs = {};
-  for (const slug of slugs) {
-    const task = TASK_TEMPLATES[slug];
-    if (!task) {
-      console.warn(`Unknown task slug: ${slug}, skipping`);
-      continue;
-    }
-    configs[slug] = {
-      frontmatter: task.frontmatter,
-      content: task.baseContent
-    };
-    console.log(`\u2713 Added slash command: /${slug}`);
-  }
-  return configs;
-}
-function getRequiredMCPsFromTasks(slugs) {
-  const mcps = /* @__PURE__ */ new Set();
-  for (const slug of slugs) {
-    const task = TASK_TEMPLATES[slug];
-    if (!task) continue;
-    for (const subagent of task.requiredSubagents) {
-      const mcpMap = {
-        "test-runner": "playwright",
-        "team-communicator": "slack",
-        "documentation-researcher": "notion",
-        "issue-tracker": "linear"
-      };
-      const mcp = mcpMap[subagent];
-      if (mcp) {
-        mcps.add(mcp);
-      }
-    }
-  }
-  return Array.from(mcps);
-}
 // Annotate the CommonJS export names for ESM import in node:
 0 && (module.exports = {
   TASK_SLUGS,
   TASK_TEMPLATES,
-  buildSlashCommandsConfig,
   getAllTaskSlugs,
-  getRequiredMCPsFromTasks,
   getTaskTemplate,
+  isInlineStep,
+  isStepReferenceObject,
   isTaskRegistered
 });
 //# sourceMappingURL=index.cjs.map