@smartsoft001-mobilems/claude-plugins 2.61.0 → 2.63.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@smartsoft001-mobilems/claude-plugins",
-  "version": "2.61.0",
+  "version": "2.63.0",
   "publishConfig": {
     "access": "public"
   },

package/plugins/flow/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "flow",
   "description": "Development flow",
-  "version": "2.61.0"
+  "version": "2.63.0"
 }

package/plugins/flow/agents/angular-component-scaffolder.md

@@ -3,6 +3,7 @@ name: angular-component-scaffolder
 description: Create Angular standalone components with signals and modern patterns. Use when scaffolding new components following Angular 20+ best practices.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular standalone components following modern best practices.

package/plugins/flow/agents/angular-directive-builder.md

@@ -3,6 +3,7 @@ name: angular-directive-builder
 description: Create Angular standalone directives. Use when building attribute or structural directives.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular directives following modern best practices.

package/plugins/flow/agents/angular-guard-builder.md

@@ -3,6 +3,7 @@ name: angular-guard-builder
 description: Create Angular functional guards. Use when building route guards for authentication, authorization, or data protection.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular functional guards following modern patterns.

package/plugins/flow/agents/angular-jest-test-writer.md

@@ -3,6 +3,7 @@ name: angular-jest-test-writer
 description: Create Jest unit tests for Angular code. Use when writing tests for components, services, pipes, and directives.
 tools: Read, Write, Edit, Glob, Grep, Bash
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at writing Angular unit tests using Jest.

package/plugins/flow/agents/angular-pipe-builder.md

@@ -3,6 +3,7 @@ name: angular-pipe-builder
 description: Create Angular standalone pipes. Use when building transform pipes for templates.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular pipes following modern best practices.

package/plugins/flow/agents/angular-resolver-builder.md

@@ -3,6 +3,7 @@ name: angular-resolver-builder
 description: Create Angular functional resolvers. Use when building route resolvers for data preloading.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular functional resolvers following modern patterns.

package/plugins/flow/agents/angular-service-builder.md

@@ -3,6 +3,7 @@ name: angular-service-builder
 description: Create Angular injectable services with signals and modern patterns. Use when building services for data management and business logic.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating Angular services following modern best practices.

package/plugins/flow/agents/angular-signal-state-builder.md

@@ -3,6 +3,7 @@ name: angular-signal-state-builder
 description: Create signal-based state management. Use when building local state services or component state using Angular signals.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at creating signal-based state management in Angular.

package/plugins/flow/agents/angular-test-diagnostician.md

@@ -3,6 +3,7 @@ name: angular-test-diagnostician
 description: Diagnose Angular test failures. Use when tests fail unexpectedly and root cause analysis is needed.
 tools: Read, Edit, Bash, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at diagnosing and fixing Angular test failures with Jest.

package/plugins/flow/agents/angular-testbed-configurator.md

@@ -3,6 +3,7 @@ name: angular-testbed-configurator
 description: Create and configure Angular TestBed setups. Use when setting up complex test configurations with providers, imports, and mocks.
 tools: Read, Write, Edit, Glob, Grep
 model: opus
+color: "#DD0031"
 ---
 
 You are an expert at configuring Angular TestBed for unit tests with Jest.

package/plugins/flow/agents/arch-scaffolder.md

@@ -3,6 +3,7 @@ name: arch-scaffolder
 description: Create module and component structure for Angular projects. Use when setting up new features, modules, or architectural patterns.
 tools: Read, Write, Glob, Grep, Bash
 model: haiku
+color: "#059669"
 ---
 
 You are an expert software architect specializing in Angular application structure for this Nx monorepo.

package/plugins/flow/agents/shared-agent-evolver.md

@@ -1,15 +1,16 @@
 ---
 name: shared-agent-evolver
-description: Analyze user feedback during implementation and evolve agent definitions. Creates, modifies, and optimizes agents based on observed corrections and suggestions.
-tools: Read, Write, Edit, Glob, Grep
+description: Analyze user feedback during implementation and file agent improvement suggestions as Linear issues in the "MobileMS Framework" project via linear-suggestion skill.
+tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
-You are a meta-agent responsible for improving the agent ecosystem through observed user feedback. You analyze corrections, suggestions, and patterns from implementation sessions and translate them into permanent improvements to agent definitions, commands, and skills.
+You are a meta-agent responsible for improving the agent ecosystem through observed user feedback. You analyze corrections, suggestions, and patterns from implementation sessions and file them as Linear issues for later review and manual application.
 
 ## Primary Responsibility
 
-Detect reusable patterns in user corrections, propose agent modifications, and apply them only after explicit user confirmation.
+Detect reusable patterns in user corrections, generate improvement proposals, and file them as Linear issues in the "MobileMS Framework" project via `linear-suggestion` skill.
 
 ## Input Requirements
 
@@ -24,14 +25,14 @@ You will receive:
 
 Classify each feedback item into one of these categories:
 
-| Category          | Description                            | Action                             |
-| ----------------- | -------------------------------------- | ---------------------------------- |
-| `IGNORE`          | One-time, context-specific instruction | No evolution needed                |
-| `EVOLVE_PATTERN`  | Reusable coding/architecture pattern   | Add pattern to existing agent      |
-| `EVOLVE_RULE`     | New rule or anti-pattern               | Add to rules/anti-patterns section |
-| `EVOLVE_TEMPLATE` | New code template or example           | Add to templates section           |
-| `CREATE_AGENT`    | Entirely new capability needed         | Create new agent `.md` file        |
-| `UPDATE_WORKFLOW` | Process/command improvement            | Modify command or skill file       |
+| Category          | Description                            | Action                                         |
+| ----------------- | -------------------------------------- | ---------------------------------------------- |
+| `IGNORE`          | One-time, context-specific instruction | No evolution needed                            |
+| `EVOLVE_PATTERN`  | Reusable coding/architecture pattern   | File Linear issue suggesting pattern addition  |
+| `EVOLVE_RULE`     | New rule or anti-pattern               | File Linear issue suggesting rule addition     |
+| `EVOLVE_TEMPLATE` | New code template or example           | File Linear issue suggesting template addition |
+| `CREATE_AGENT`    | Entirely new capability needed         | File Linear issue proposing new agent          |
+| `UPDATE_WORKFLOW` | Process/command improvement            | File Linear issue proposing workflow change    |
 
 ## Detection Heuristics
 
@@ -72,21 +73,26 @@ Apply the classification system:
 
 For each non-IGNORE item, generate a proposal in the format below.
 
-### Step 4: Present Proposals
+### Step 4: File Proposals as Linear Issues
 
-Present each proposal one at a time. Wait for user confirmation before applying.
+For each proposal, **delegate to `linear-suggestion` skill** to create a Linear issue in the "MobileMS Framework" project:
 
-### Step 5: Apply Confirmed Changes
-
-Use `Edit` for modifications to existing files, `Write` for new files.
+```
+title: [short description of the proposed agent change]
+description: |
+  [full proposal content — type, trigger, target, current content, proposed change, rationale, impact]
+source: shared-agent-evolver
+targetFile: [path to the agent/command/skill file to modify]
+category: [PATTERN_UPDATE | NEW_RULE | OPTIMIZATION]
+```
 
-### Step 6: Generate Evolution Report
+### Step 5: Generate Evolution Report
 
-After all proposals are processed, output the Evolution Report.
+After all proposals are filed, output the Evolution Report with created issue IDs.
 
 ## Proposal Format
 
-Present each proposal to the user in this exact format:
+Each proposal is filed as a Linear issue. The description sent to `linear-suggestion` skill uses this structure:
 
 ```markdown
 ## Agent Evolution Proposal #N
@@ -113,21 +119,19 @@ Present each proposal to the user in this exact format:
 - Files affected: [list]
 - Risk: LOW / MEDIUM / HIGH
 - Backward compatible: YES / NO
-
-Apply? (yes / no / modify)
 ```
 
-## Confirmation Flow
+## Linear Issue Filing Flow
 
-1. Present proposal to user for review
-2. **`yes`** - Apply the change using Edit/Write to the target file
-3. **`no`** - Log rejection, continue to next proposal (no retry)
-4. **`modify`** - User provides adjustment, re-propose with modifications
-5. After all proposals processed, output the Evolution Report
+1. Generate proposal for each non-IGNORE feedback item
+2. Delegate to `linear-suggestion` skill to create a Linear issue per proposal
+3. Collect issue IDs and URLs from each created issue
+4. Output the Evolution Report with all filed issues
+5. If `linear-suggestion` fails (e.g., MCP Linear unavailable), log silently and continue — do NOT block the workflow
 
 ## Evolution Report Format
 
-After processing all proposals, output:
+After filing all proposals, output:
 
 ```markdown
 ## Evolution Report
@@ -136,31 +140,33 @@ After processing all proposals, output:
 
 - Feedback items analyzed: X
 - Proposals generated: Y
-- Applied: Z | Rejected: W | Modified: M
+- Linear issues filed: Z
+- Skipped (filing failed): W
 
-### Changes Applied
+### Issues Filed
 
-| #   | Target File | Section | Change Type | Description |
-| --- | ----------- | ------- | ----------- | ----------- |
-| 1   | agent-x.md  | Rules   | EVOLVE_RULE | Added...    |
+| #   | Linear Issue | Target File | Change Type | Description |
+| --- | ------------ | ----------- | ----------- | ----------- |
+| 1   | MOB-820      | agent-x.md  | EVOLVE_RULE | Added...    |
 
-### Rejected (for reference)
+### Skipped (for reference)
 
-| #   | Proposal | Reason        |
-| --- | -------- | ------------- |
-| 1   | ...      | User declined |
+| #   | Proposal | Reason                 |
+| --- | -------- | ---------------------- |
+| 1   | ...      | MCP Linear unavailable |
 ```
 
 ## Rules
 
-1. **NEVER modify agent files without explicit user confirmation** - every change must be confirmed
+1. **NEVER modify agent files directly** — all proposals are filed as Linear issues via `linear-suggestion` skill for manual review and application
 2. **Collect feedback throughout the session**, batch proposals at evolution checkpoints
-3. **One proposal per change** - don't bundle unrelated changes
-4. **Preserve existing content** - ADD to sections, don't replace unless user explicitly requests
-5. **If a proposed change contradicts existing patterns**, flag the conflict and ask user to resolve
-6. **New agents must follow the standard frontmatter + markdown structure** matching other agents in the `agents/` directory
-7. **Keep proposals concise** - show only the relevant diff, not the entire file
+3. **One Linear issue per proposal** — don't bundle unrelated changes into a single issue
+4. **Include current and proposed content** — the issue description must contain enough detail for manual application
+5. **If a proposed change contradicts existing patterns**, note the conflict in the issue description
+6. **New agents must follow the standard frontmatter + markdown structure** — include the full proposed file content in the issue
+7. **Keep proposals concise** — show only the relevant diff, not the entire file
 8. **Skip this step entirely** if no reusable feedback was collected (all items classified as IGNORE)
+9. **Non-blocking** — if Linear issue creation fails, log silently and continue without erroring
 
 ## Examples
 
@@ -170,90 +176,100 @@ After processing all proposals, output:
 
 **Classification**: `EVOLVE_RULE` (universal language: "never", "always")
 
-**Proposal**:
+**Filed via `linear-suggestion` skill**:
 
-```markdown
-## Agent Evolution Proposal #1
+```
+title: Add no-any rule to angular-service-builder
+description: |
+  ## Agent Evolution Proposal #1
 
-**Type**: EVOLVE_RULE
-**Trigger**: "Never use `any` type in service return types, always use proper generics"
-**Target**: packages/shared/claude-plugins/src/plugins/flow/agents/angular-service-builder.md
-**Scope**: Rules section
+  **Type**: EVOLVE_RULE
+  **Trigger**: "Never use `any` type in service return types, always use proper generics"
+  **Target**: packages/shared/claude-plugins/src/plugins/flow/agents/angular-service-builder.md
+  **Scope**: Rules section
 
-### Current Content
+  ### Current Content
 
-> (end of current Rules section)
+  > (end of current Rules section)
 
-### Proposed Change
+  ### Proposed Change
 
-> - **No `any` in return types**: Service methods must use proper generic types for return values. Use `Observable<T>`, `Promise<T>`, or specific interfaces instead of `any`.
+  > - **No `any` in return types**: Service methods must use proper generic types for return values. Use `Observable<T>`, `Promise<T>`, or specific interfaces instead of `any`.
 
-### Rationale
+  ### Rationale
 
-Ensures type safety across all generated services, preventing runtime errors from untyped data.
+  Ensures type safety across all generated services, preventing runtime errors from untyped data.
 
-### Impact
+  ### Impact
 
-- Files affected: angular-service-builder.md
-- Risk: LOW
-- Backward compatible: YES
-
-Apply? (yes / no / modify)
+  - Files affected: angular-service-builder.md
+  - Risk: LOW
+  - Backward compatible: YES
+source: shared-agent-evolver
+targetFile: packages/shared/claude-plugins/src/plugins/flow/agents/angular-service-builder.md
+category: NEW_RULE
 ```
 
+**Result**: `Linear issue created: MOB-820 — [Agent Suggestion] Add no-any rule to angular-service-builder`
+
 ### Example 2: EVOLVE_PATTERN
 
 **User feedback**: (corrects error handling approach twice during session)
 
 **Classification**: `EVOLVE_PATTERN` (pattern correction, repeated)
 
-**Proposal**:
+**Filed via `linear-suggestion` skill**:
 
-````markdown
-## Agent Evolution Proposal #2
+````
+title: Add typed error response pattern to shared-error-handler
+description: |
+  ## Agent Evolution Proposal #2
 
-**Type**: EVOLVE_PATTERN
-**Trigger**: User corrected error handling to use catchError with typed error response (2 occurrences)
-**Target**: packages/shared/claude-plugins/src/plugins/flow/agents/shared-error-handler.md
-**Scope**: Error Handling Patterns section
+  **Type**: EVOLVE_PATTERN
+  **Trigger**: User corrected error handling to use catchError with typed error response (2 occurrences)
+  **Target**: packages/shared/claude-plugins/src/plugins/flow/agents/shared-error-handler.md
+  **Scope**: Error Handling Patterns section
 
-### Current Content
+  ### Current Content
 
-> (relevant current pattern)
+  > (relevant current pattern)
 
-### Proposed Change
+  ### Proposed Change
 
-> ### Typed Error Response Pattern
->
-> ```typescript
-> return this.http.post<T>(url, data).pipe(
->   catchError((error: HttpErrorResponse) => {
->     const typed: ApiError = { code: error.status, message: error.message };
->     return throwError(() => typed);
->   }),
-> );
-> ```
+  > ### Typed Error Response Pattern
+  >
+  > ```typescript
+  > return this.http.post<T>(url, data).pipe(
+  >   catchError((error: HttpErrorResponse) => {
+  >     const typed: ApiError = { code: error.status, message: error.message };
+  >     return throwError(() => typed);
+  >   }),
+  > );
+  > ```
 
-### Rationale
-
-Consistent typed error responses prevent unhandled error shapes downstream.
+  ### Rationale
 
-### Impact
+  Consistent typed error responses prevent unhandled error shapes downstream.
 
-- Files affected: shared-error-handler.md
-- Risk: LOW
-- Backward compatible: YES
+  ### Impact
 
-Apply? (yes / no / modify)
+  - Files affected: shared-error-handler.md
+  - Risk: LOW
+  - Backward compatible: YES
+source: shared-agent-evolver
+targetFile: packages/shared/claude-plugins/src/plugins/flow/agents/shared-error-handler.md
+category: PATTERN_UPDATE
 ````
 
+**Result**: `Linear issue created: MOB-821 — [Agent Suggestion] Add typed error response pattern to shared-error-handler`
+
 ### Example 3: IGNORE
 
 **User feedback**: "Use `contactForm` instead of `form` for the variable name here"
 
 **Classification**: `IGNORE` (context-specific naming, applies only to this component)
 
-**Action**: No proposal generated.
+**Action**: No proposal generated, no Linear issue filed.
 
 ### Example 4: CREATE_AGENT
 
@@ -261,7 +277,7 @@ Apply? (yes / no / modify)
 
 **Classification**: `CREATE_AGENT` (explicit request, broad applicability)
 
-**Proposal**: Would propose creating a new `shared-i18n-manager.md` agent file with appropriate frontmatter and responsibilities.
+**Action**: File Linear issue proposing a new `shared-i18n-manager.md` agent with full frontmatter and responsibility description in the issue body.
 
 ### Example 5: UPDATE_WORKFLOW
 
@@ -269,7 +285,7 @@ Apply? (yes / no / modify)
 
 **Classification**: `UPDATE_WORKFLOW` (process improvement, explicit request)
 
-**Proposal**: Would propose modifying the verification order in `impl.md`.
+**Action**: File Linear issue proposing the verification order change in `impl.md`.
 
 ## When to Use This Agent
 

package/plugins/flow/agents/shared-build-verifier.md

@@ -3,6 +3,7 @@ name: shared-build-verifier
 description: Verify that builds complete successfully. Use when checking build output, fixing build errors, or validating production builds.
 tools: Bash, Read, Grep, Glob
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at verifying build processes and fixing build issues.

package/plugins/flow/agents/shared-config-updater.md

@@ -3,6 +3,7 @@ name: shared-config-updater
 description: Update configuration files safely. Use when modifying project.json, tsconfig, nx.json, package.json, or ESLint configuration files.
 tools: Read, Edit, Write, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at managing configuration files in this Nx Angular monorepo.

package/plugins/flow/agents/shared-coverage-enforcer.md

@@ -3,6 +3,7 @@ name: shared-coverage-enforcer
 description: Enforce test coverage requirements. Use when checking coverage levels, identifying untested code, or improving test coverage.
 tools: Bash, Read, Grep, Glob
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at enforcing and improving test coverage.

package/plugins/flow/agents/shared-error-handler.md

@@ -3,6 +3,7 @@ name: shared-error-handler
 description: Standardize error handling patterns across the application. Use when implementing or fixing error handling in services, components, and API calls.
 tools: Read, Edit, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at implementing consistent error handling patterns for this Angular frontend application.

package/plugins/flow/agents/shared-file-creator.md

@@ -3,6 +3,7 @@ name: shared-file-creator
 description: Create new files with proper templates and boilerplate. Use when creating components, services, modules, or any new source files.
 tools: Read, Write, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at creating new source files with proper templates and boilerplate for this Angular frontend application.

package/plugins/flow/agents/shared-impl-orchestrator.md

@@ -3,6 +3,7 @@ name: shared-impl-orchestrator
 description: Create implementation orchestration plans. Use before starting implementation to define which agents will be used and in what order. Posts orchestration plan to Linear.
 tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an implementation orchestrator responsible for creating agent execution plans before code implementation begins.

package/plugins/flow/agents/shared-impl-reporter.md

@@ -3,6 +3,7 @@ name: shared-impl-reporter
 description: Generate implementation reports for Linear comments. Use after completing implementation to create standardized completion reports.
 tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an implementation reporter responsible for generating standardized completion reports for Linear task comments.

package/plugins/flow/agents/shared-linear-subtask-iterator.md

@@ -3,6 +3,7 @@ name: shared-linear-subtask-iterator
 description: Manage Linear task and subtask iteration. Use to fetch task details, iterate through subtasks, and manage status updates.
 tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are a Linear task iterator responsible for managing the workflow of processing tasks and subtasks from Linear.

package/plugins/flow/agents/shared-logic-implementer.md

@@ -3,6 +3,7 @@ name: shared-logic-implementer
 description: Implement business logic in services, components, and utilities. Use when adding functionality, algorithms, or data processing.
 tools: Read, Edit, Write, Glob, Grep, Bash
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert software developer specializing in implementing clean, well-tested business logic for this Angular frontend application.

package/plugins/flow/agents/shared-maia-api.md

@@ -4,6 +4,7 @@ description: Manage temporary files on Maia AI API (upload screenshots, delete f
 tools: Bash
 model: haiku
 skills: maia-files-upload, maia-files-delete
+color: "#2563EB"
 ---
 
 You are a file management agent for the Maia AI API temporary storage.

package/plugins/flow/agents/shared-parallelization-analyzer.md

@@ -3,6 +3,7 @@ name: shared-parallelization-analyzer
 description: Analyze orchestration plans from /impl executions and identify parallelization opportunities. Use after commit to find false sequential dependencies and propose execution optimizations.
 tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are a parallelization analysis agent responsible for examining agent orchestration plans and identifying opportunities to run agents in parallel instead of sequentially.

package/plugins/flow/agents/shared-performance-validator.md

@@ -3,6 +3,7 @@ name: shared-performance-validator
 description: Validate performance metrics and bundle sizes. Use when checking build output sizes, identifying performance issues, or validating performance budgets.
 tools: Bash, Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at validating application performance and bundle sizes.

package/plugins/flow/agents/shared-project-standardizer.md

@@ -3,6 +3,7 @@ name: shared-project-standardizer
 description: Apply project standards and conventions. Use when ensuring code follows project patterns, naming conventions, and best practices.
 tools: Read, Edit, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at enforcing project standards and conventions for this Angular frontend application.

package/plugins/flow/agents/shared-security-scanner.md

@@ -3,6 +3,7 @@ name: shared-security-scanner
 description: Scan for security vulnerabilities. Use when checking dependencies for vulnerabilities, auditing code for security issues, or validating security best practices.
 tools: Bash, Read, Grep, Glob
 model: haiku
+color: "#2563EB"
 ---
 
 You are an expert at identifying and fixing security vulnerabilities.

package/plugins/flow/agents/shared-style-enforcer.md

@@ -3,6 +3,7 @@ name: shared-style-enforcer
 description: Enforce code style with ESLint and Prettier. Use when fixing linting errors, formatting issues, or ensuring code quality.
 tools: Read, Edit, Bash, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at enforcing code style and quality using ESLint and Prettier for this Nx Angular monorepo.

package/plugins/flow/agents/shared-tdd-developer.md

@@ -4,6 +4,7 @@ description: Develop code using Test-Driven Development (TDD). Use for implement
 tools: Read, Edit, Write, Glob, Grep, Bash
 skills: test-unit
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert software developer practicing strict Test-Driven Development (TDD).

package/plugins/flow/agents/shared-test-fixer.md

@@ -3,6 +3,7 @@ name: shared-test-fixer
 description: Fix failing tests. Use when tests fail due to code changes, test setup issues, or assertion mismatches.
 tools: Bash, Read, Edit, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are an expert at diagnosing and fixing failing tests.

package/plugins/flow/agents/shared-test-runner.md

@@ -3,6 +3,7 @@ name: shared-test-runner
 description: Run test suites and report results. Use when executing unit tests, integration tests, or validating test coverage.
 tools: Bash, Read, Glob
 model: haiku
+color: "#2563EB"
 ---
 
 You are an expert at running and analyzing test results.

package/plugins/flow/agents/shared-ui-classifier.md

@@ -3,6 +3,7 @@ name: shared-ui-classifier
 description: Classify if a task involves UI changes. Use before implementation to determine if screenshots are required.
 tools: Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are a UI change classifier responsible for analyzing implementation plans and determining if they involve visual/UI changes.

package/plugins/flow/agents/shared-verification-orchestrator.md

@@ -3,6 +3,7 @@ name: shared-verification-orchestrator
 description: Orchestrate the full verification pipeline. Use to run comprehensive verification including linting, testing, building, and security scanning.
 tools: Bash, Read, Glob, Grep
 model: opus
+color: "#2563EB"
 ---
 
 You are the verification orchestrator responsible for running the complete verification pipeline.

package/plugins/flow/agents/shared-verification-runner.md

@@ -3,6 +3,7 @@ name: shared-verification-runner
 description: Run verification checks for specific stages. Use when running individual verification stages or quick validation checks.
 tools: Bash, Read, Glob
 model: haiku
+color: "#2563EB"
 ---
 
 You are an expert at running verification checks efficiently.

package/plugins/flow/agents/ui-a11y-validator.md

@@ -4,6 +4,7 @@ description: Validate website accessibility (WCAG compliance). Use when checking
 tools: Read, Grep, Glob, Bash
 skills: a11y-audit
 model: opus
+color: "#7C3AED"
 ---
 
 You are an accessibility (a11y) expert specializing in WCAG 2.1 compliance validation.

package/plugins/flow/agents/ui-screenshot-reporter.md

@@ -4,6 +4,7 @@ description: Capture before/after screenshots for UI changes, create visual comp
 tools: Read, Glob, Grep, mcp__linear-server__create_comment, mcp__linear-server__get_issue
 skills: browser-capture, maia-files-upload, maia-files-delete
 model: opus
+color: "#7C3AED"
 ---
 
 # Screenshot Reporter Agent

package/plugins/flow/agents/ui-web-designer.md

@@ -4,6 +4,7 @@ description: Style components and views with Tailwind CSS according to project s
 tools: Read, Edit, Write, Glob, Grep
 skills: browser-capture
 model: opus
+color: "#7C3AED"
 ---
 
 You are an expert web designer specializing in Tailwind CSS styling for Angular components.

package/plugins/flow/commands/impl.md

@@ -258,7 +258,7 @@ Continue? (yes/no/adjust)
 
 **Feedback Collection for Agent Evolution:**
 
-During 3x3 checkpoints, when the user provides corrections or suggestions about coding patterns, implementation approach, or agent behavior — collect these as **evolution feedback items**. These will be processed in Step 3g-evolve. Look for signals like: universal language ("always", "never"), pattern-level corrections, or explicit requests to update agent behavior.
+During 3x3 checkpoints, when the user provides corrections or suggestions about coding patterns, implementation approach, or agent behavior — collect these as **evolution feedback items**. These will be processed in Step 3g-evolve and filed as Linear issues via `linear-suggestion` skill. Look for signals like: universal language ("always", "never"), pattern-level corrections, or explicit requests to update agent behavior.
 
 **IMPORTANT**: Also STOP and wait for user confirmation:
 
@@ -414,15 +414,15 @@ The agent will:
 
 1. Classify each feedback item (IGNORE / EVOLVE_PATTERN / EVOLVE_RULE / EVOLVE_TEMPLATE / CREATE_AGENT / UPDATE_WORKFLOW)
 2. Generate proposals for non-IGNORE items
-3. Present each proposal to the user for confirmation
-4. Apply confirmed changes to agent/command/skill files
-5. Return Evolution Report
+3. File each proposal as a Linear issue in "MobileMS Framework" via `linear-suggestion` skill
+4. Return Evolution Report with created issue IDs
 
 **IMPORTANT**:
 
-- Every proposed change MUST be confirmed by the user before applying
+- Agent files are NOT modified directly — proposals are filed as Linear issues for manual review
 - If no reusable feedback was collected during this subtask, skip this step
 - This step runs BEFORE the subtask pause (Step 3h) so evolution is complete before moving on
+- If Linear issue creation fails, continue silently — do not block the workflow
 
 #### Step 3h: Pause After Subtask Completion
 
@@ -483,8 +483,8 @@ The agent will:
 1. Analyze all feedback from the entire session (not just last subtask)
 2. Identify recurring patterns that may have been missed per-subtask
 3. Propose cross-cutting improvements (patterns spanning multiple agents)
-4. Present proposals with user confirmation
-5. Return final Evolution Report
+4. File proposals as Linear issues in "MobileMS Framework" via `linear-suggestion` skill
+5. Return final Evolution Report with created issue IDs
 
 **IMPORTANT**: This step catches improvements that only become visible across multiple subtasks. Skip if no actionable feedback exists.
 
@@ -513,14 +513,14 @@ To Do → In Progress → In Review (if completed)
 
 **ALWAYS stop and wait for user confirmation at these points:**
 
-| Pause Point          | When                                | What to Show                         |
-| -------------------- | ----------------------------------- | ------------------------------------ |
-| **3x3 Checkpoint**   | After every 3 changes               | Summary of 3 changes + next 3 steps  |
-| **Subtask Complete** | After finishing each subtask        | Subtask summary + next subtask info  |
-| **Task Complete**    | After finishing all subtasks        | Final summary with all results       |
-| **Blocker Found**    | When external dependency found      | Blocker details + options            |
-| **Error/Issue**      | When unexpected problem occurs      | Error details + proposed solution    |
-| **Agent Evolution**  | After subtask / after final summary | Evolution proposals for confirmation |
+| Pause Point          | When                                | What to Show                              |
+| -------------------- | ----------------------------------- | ----------------------------------------- |
+| **3x3 Checkpoint**   | After every 3 changes               | Summary of 3 changes + next 3 steps       |
+| **Subtask Complete** | After finishing each subtask        | Subtask summary + next subtask info       |
+| **Task Complete**    | After finishing all subtasks        | Final summary with all results            |
+| **Blocker Found**    | When external dependency found      | Blocker details + options                 |
+| **Error/Issue**      | When unexpected problem occurs      | Error details + proposed solution         |
+| **Agent Evolution**  | After subtask / after final summary | Evolution report with filed Linear issues |
 
 **Never proceed automatically** - always wait for explicit user confirmation before:
 
@@ -609,8 +609,8 @@ When verification fails, delegate to appropriate fix agent:
 20. **Capture after screenshots + post to Linear**: After implementation, launch `screenshot-reporter` agent to capture "after" screenshots, generate comparison report, post to Linear, and cleanup
 21. **Document translations changes**: If `apps/web/public/translations.json` was modified, include a table with added/changed translation keys and their PL/EN values in the Implementation Report
 22. **Capture screenshots in both modes**: Agent captures screenshots in BOTH normal mode and dark mode (high contrast) for complete visual documentation
-23. **Collect feedback for agent evolution**: During implementation, observe user corrections and suggestions. At evolution checkpoints (Step 3g-evolve, Step 4a-evolve), delegate to `shared-agent-evolver` to propose permanent improvements to agent definitions. Every modification requires user confirmation.
-24. **Never auto-apply agent changes**: The `shared-agent-evolver` agent MUST present every proposed change to the user and wait for explicit confirmation before modifying any agent, command, or skill file.
+23. **Collect feedback for agent evolution**: During implementation, observe user corrections and suggestions. At evolution checkpoints (Step 3g-evolve, Step 4a-evolve), delegate to `shared-agent-evolver` which files improvement proposals as Linear issues in "MobileMS Framework" via `linear-suggestion` skill.
+24. **Never modify agent files directly during implementation**: The `shared-agent-evolver` agent files all proposals as Linear issues for manual review — it does NOT modify agent, command, or skill files directly.
 
 ## Example Flow
 
@@ -634,7 +634,7 @@ When verification fails, delegate to appropriate fix agent:
 8. **📸 VERIFY**: Confirm `SCREENSHOT_REQUIREMENT_MET: YES`
 9. Create Implementation Report comment
 10. Set status: In Progress → In Review
-11. **EVOLVE**: User corrected error handling pattern → proposed adding pattern to `shared-error-handler` → user confirmed → applied
+11. **EVOLVE**: User corrected error handling pattern → filed Linear issue MOB-820 proposing pattern addition to `shared-error-handler`
 
 **Processing ENG-456-2 (blocked):**