@smartsoft001-mobilems/claude-plugins 2.70.0 → 2.72.0

package/package.json

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

package/plugins/flow/.claude-plugin/README.md

@@ -1,11 +1,11 @@
 # Flow Plugin for Claude Code
 
-Development flow commands for Linear-driven development workflow.
+Development flow skills for Linear-driven development workflow.
 
-## Commands
+## Workflow Skills
 
-| Command | Description |
-|---------|-------------|
+| Skill | Description |
+|-------|-------------|
 | `/commit` | Create conventional commit based on Linear task |
 | `/impl` | Implement plans from Linear task comments |
 | `/plan` | Create implementation plan and save to Linear |
@@ -58,15 +58,15 @@ Configure these in your `.mcp.json`:
 - Nx commands (test, lint, build)
 - Linear API (read/write issues, comments)
 - Playwright (screenshots)
-- Internal skills
+- Utility skills
 
 ### Requires Confirmation (ask)
-- Flow commands (/commit, /impl, /plan, /push)
+- Workflow skills (/commit, /impl, /plan, /push)
 - `git commit` - creating commits
 - `git push` - pushing to remote
 - `gh pr create` - creating pull requests
 
-## Skills
+## Utility Skills
 
 | Skill | Description |
 |-------|-------------|
@@ -79,4 +79,4 @@ Configure these in your `.mcp.json`:
 
 ## Agents
 
-See `agents/` directory for full list of specialized agents used by flow commands.
+See `agents/` directory for full list of specialized agents used by flow skills.

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

@@ -1,5 +1,5 @@
 {
   "name": "flow",
-  "description": "Development flow commands for Linear-driven development workflow",
-  "version": "2.70.0"
+  "description": "Development flow skills for Linear-driven development workflow",
+  "version": "2.72.0"
 }

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

@@ -38,6 +38,7 @@
       "mcp__linear-server__list_issues",
       "mcp__linear-server__list_comments",
       "mcp__linear-server__create_comment",
+      "mcp__linear-server__delete_comment",
       "mcp__linear-server__update_issue",
       "mcp__linear-server__list_issue_statuses",
       "mcp__linear-server__create_issue",
@@ -72,4 +73,4 @@
   "enabledPlugins": {
     "flow@mobilems": true
   }
-}
+}

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

@@ -3,7 +3,7 @@ name: shared-agent-evolver
 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"
+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 file them as Linear issues for later review and manual application.
@@ -32,7 +32,7 @@ Classify each feedback item into one of these categories:
 | `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    |
+| `UPDATE_WORKFLOW` | Process/skill improvement              | File Linear issue proposing workflow change    |
 
 ## Detection Heuristics
 
@@ -82,7 +82,7 @@ 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]
+targetFile: [path to the agent/skill file to modify]
 category: [PATTERN_UPDATE | NEW_RULE | OPTIMIZATION]
 ```
 
@@ -99,7 +99,7 @@ Each proposal is filed as a Linear issue. The description sent to `linear-sugges
 
 **Type**: [EVOLVE_PATTERN | EVOLVE_RULE | EVOLVE_TEMPLATE | CREATE_AGENT | UPDATE_WORKFLOW]
 **Trigger**: "[exact user feedback that prompted this]"
-**Target**: [file path of agent/command/skill to modify]
+**Target**: [file path of agent/skill to modify]
 **Scope**: [section within the file to modify]
 
 ### Current Content
@@ -281,14 +281,14 @@ category: PATTERN_UPDATE
 
 ### Example 5: UPDATE_WORKFLOW
 
-**User feedback**: "The impl command should always run lint before tests, not after"
+**User feedback**: "The impl skill should always run lint before tests, not after"
 
 **Classification**: `UPDATE_WORKFLOW` (process improvement, explicit request)
 
-**Action**: File Linear issue proposing the verification order change in `impl.md`.
+**Action**: File Linear issue proposing the verification order change in `skills/impl/SKILL.md`.
 
 ## When to Use This Agent
 
-- At evolution checkpoints during implementation (Step 3g-evolve in impl.md)
-- After completing all subtasks for session-wide analysis (Step 4a-evolve in impl.md)
+- At evolution checkpoints during implementation (Step 3g-evolve in skills/impl/SKILL.md)
+- After completing all subtasks for session-wide analysis (Step 4a-evolve in skills/impl/SKILL.md)
 - When explicitly requested by the user to analyze and improve agents

package/plugins/flow/{commands/commit.md → skills/commit/SKILL.md}

@@ -1,4 +1,17 @@
-# Commit Command
+---
+name: commit
+description: Create a conventional commit message based on Linear task and staged changes. Fetches task details, analyzes changes, generates commit message, and optionally runs parallelization analysis.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_comments
+---
+
+# Commit Skill
 
 Create a conventional commit message based on Linear task and staged changes.
 
@@ -12,6 +25,20 @@ Create a conventional commit message based on Linear task and staged changes.
 
 - `linearTaskId` - Linear task ID (e.g., ENG-123)
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+- [ ] **1. Fetch Linear task** — get title, description, labels/type from MCP Linear server
+- [ ] **2. Analyze staged changes** — run `git diff --cached` to understand scope
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop
+- [ ] **4. Read commitlint config** — read `commitlint.config.js` for valid scopes and format
+- [ ] **5. Generate commit message** — draft `<type>(<scope>): <subject>` with body and `Refs: <linearTaskId>`
+- [ ] **6. Show message to user** — present commit message for approval before proceeding
+- [ ] **7. MANDATORY: Pre-commit preparation** — run `nvm use 24` then `npm run format`, stage any formatting changes
+- [ ] **8. Create commit** — execute `git commit` with the approved message
+- [ ] **9. Parallelization analysis (optional)** — fetch Linear comments, search for orchestration plan, delegate to `shared-parallelization-analyzer` if found
+
 ## Instructions
 
 You are tasked with creating a git commit based on a Linear task and staged changes.

package/plugins/flow/{commands/impl.md → skills/impl/SKILL.md}

@@ -1,7 +1,59 @@
-# Implementation Command
+---
+name: impl
+description: Implement plans from Linear task comments. Iteratively processes subtasks with TDD, UI classification, agent orchestration, screenshot capture, and 3x3 rule checkpoints.
+allowed-tools:
+  - Bash
+  - Read
+  - Edit
+  - Write
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Task
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__update_issue
+  - mcp__linear-server__list_issue_statuses
+---
+
+# Implementation Skill
 
 Implement plans from Linear task comments. For tasks with subtasks, iteratively implement each subtask that is in "To Do" status.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+### Initial Setup
+
+- [ ] **1. Fetch task and subtasks** — delegate to `shared-linear-subtask-iterator` agent
+
+### Per Subtask (repeat for each "To Do" subtask)
+
+- [ ] **2. Set status to "In Progress"** — update subtask status via MCP (subtasks only, not parent)
+- [ ] **3. Fetch implementation plan** — find `## Implementation Plan` in task comments
+- [ ] **4. MANDATORY: UI change classification** — delegate to `shared-ui-classifier` agent, output `UI_CHANGE_REQUIRED: YES/NO`
+- [ ] **5. MANDATORY: Agent orchestration plan** — delegate to `shared-impl-orchestrator`, post plan to Linear
+- [ ] **6. Check external library blockers** — if blockers found, set status to Blocked and skip
+- [ ] **7. Capture "before" screenshots** — if `UI_CHANGE_REQUIRED: YES`, launch `screenshot-reporter` in background
+- [ ] **8. MANDATORY: Implement with 3x3 rule** — pause every 3 changes, use `shared-tdd-developer` for ALL code (RED → GREEN → REFACTOR)
+- [ ] **9. Verify implementation** — run tests, lint, build check
+- [ ] **10. Capture "after" screenshots** — if `UI_CHANGE_REQUIRED: YES`, capture + post comparison to Linear + cleanup
+- [ ] **11. MANDATORY: Screenshot verification** — output `SCREENSHOT_REQUIREMENT_MET: YES/NO`, block if missing
+- [ ] **12. Create completion comment** — delegate to `shared-impl-reporter`, post to Linear
+- [ ] **13. MANDATORY: Write reports in Polish** — all Linear comments must be in Polish language
+- [ ] **14. Update status** — delegate to `shared-linear-subtask-iterator` for status determination
+- [ ] **15. Agent evolution** — if user confirmed feedback, delegate to `shared-agent-evolver`
+- [ ] **16. Pause for user confirmation** — ALWAYS wait before proceeding to next subtask
+
+### Finalization
+
+- [ ] **17. Final summary** — present summary of all subtasks with statuses
+- [ ] **18. Session-wide evolution** — analyze all feedback across session
+- [ ] **19. ALWAYS pause** — wait for user confirmation at end
+
 ## Role
 
 **You are a highly experienced senior TypeScript developer** with:
@@ -258,7 +310,23 @@ 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 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.
+During 3x3 checkpoints, when the user provides corrections or suggestions about coding patterns, implementation approach, or agent behavior — **ASK the user explicitly** if they want to create a Linear issue for the improvement.
+
+**When user provides a correction or pattern suggestion, ASK:**
+
+```
+🔄 Detected potential improvement suggestion:
+"[summary of user's correction]"
+
+Would you like to create a Linear issue for this pattern improvement?
+- Yes - File as Linear issue in "MobileMS Framework"
+- No - Note for this session only
+- Skip - Ignore this feedback
+```
+
+**Only feedback confirmed with "Yes"** should be collected as **evolution feedback items** and processed in Step 3g-evolve 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:
 
@@ -400,12 +468,14 @@ The agent will determine the correct status and provide MCP command to execute.
 
 #### Step 3g-evolve: Agent Evolution Checkpoint
 
+**Prerequisites**: Only execute this step if user confirmed at least one feedback item with "Yes" during 3x3 checkpoints.
+
 **Delegate to `shared-agent-evolver` agent:**
 
 ```
 Analyze feedback from current subtask implementation:
 - Subtask ID: [current subtask ID]
-- User corrections collected during implementation: [list of feedback items]
+- User-confirmed corrections: [list of feedback items where user answered "Yes"]
 - Files that were implemented: [list of files modified/created]
 - Patterns the user corrected or suggested: [specific corrections]
 ```
@@ -420,7 +490,8 @@ The agent will:
 **IMPORTANT**:
 
 - 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
+- **Only process feedback explicitly confirmed by user** — do not auto-collect without asking
+- If no user-confirmed 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
 
@@ -609,7 +680,7 @@ 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` which files improvement proposals as Linear issues in "MobileMS Framework" via `linear-suggestion` skill.
+23. **Ask before collecting feedback for agent evolution**: When user provides corrections or suggestions during implementation, **explicitly ask** if they want to create a Linear issue for the improvement. Only user-confirmed feedback (answered "Yes") should be processed at evolution checkpoints (Step 3g-evolve, Step 4a) via `shared-agent-evolver` agent.
 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

package/plugins/flow/skills/linear-suggestion/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: linear-suggestion
-description: Create a Linear issue in the "MobileMS Framework" project with a suggestion for agent, command, or skill improvements.
+description: Create a Linear issue in the "MobileMS Framework" project with a suggestion for agent or skill improvements.
 allowed-tools: mcp__linear-server__create_issue
 ---
 
 # Linear Suggestion
 
-Create a Linear issue in the **MobileMS Framework** project containing a suggestion for improving agent definitions, commands, or skills. Used by automated analysis agents to propose changes without blocking the workflow.
+Create a Linear issue in the **MobileMS Framework** project containing a suggestion for improving agent definitions or skills. Used by automated analysis agents to propose changes without blocking the workflow.
 
 ## When to Use
 
-- When an automated agent (e.g., `shared-parallelization-analyzer`) identifies a recurring pattern that could improve an agent, command, or skill
+- When an automated agent (e.g., `shared-parallelization-analyzer`) identifies a recurring pattern that could improve an agent or skill
 - When proposing orchestrator rule changes based on parallelization analysis
 - When any non-interactive process needs to suggest framework improvements
 
@@ -18,13 +18,13 @@ Create a Linear issue in the **MobileMS Framework** project containing a suggest
 
 The invoking agent must provide:
 
-| Parameter     | Required | Description                                                     |
-| ------------- | -------- | --------------------------------------------------------------- |
-| `title`       | YES      | Short summary of the suggestion (max 100 chars)                 |
-| `description` | YES      | Full markdown description with rationale and proposed changes    |
+| Parameter     | Required | Description                                                                   |
+| ------------- | -------- | ----------------------------------------------------------------------------- |
+| `title`       | YES      | Short summary of the suggestion (max 100 chars)                               |
+| `description` | YES      | Full markdown description with rationale and proposed changes                 |
 | `source`      | YES      | Agent that generated the suggestion (e.g., `shared-parallelization-analyzer`) |
-| `targetFile`  | NO       | Path to the file to be modified (e.g., `agents/shared-impl-orchestrator.md`) |
-| `category`    | NO       | One of: `OPTIMIZATION`, `NEW_RULE`, `PATTERN_UPDATE`, `BUG_FIX` |
+| `targetFile`  | NO       | Path to the file to be modified (e.g., `agents/shared-impl-orchestrator.md`)  |
+| `category`    | NO       | One of: `OPTIMIZATION`, `NEW_RULE`, `PATTERN_UPDATE`, `BUG_FIX`               |
 
 ## Issue Format
 

package/plugins/flow/{commands/plan.md → skills/plan/SKILL.md}

@@ -1,7 +1,42 @@
-# Plan Create Command
+---
+name: plan
+description: Create an implementation plan for a Linear task and save it as a comment. Analyzes codebase, previous commits, and external dependencies to generate detailed plans for tasks and subtasks.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__delete_comment
+---
+
+# Plan Skill
 
 Create an implementation plan for a Linear task and save it as a comment. If the task has subtasks, create individual plans for each subtask.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+- [ ] **1. Fetch Linear task** — get title, description, labels, priority, estimate from MCP Linear server
+- [ ] **2. Fetch subtasks** — check for children; if present, plan each subtask individually
+- [ ] **3. Fetch existing comments** — check parent task and each subtask for existing context
+- [ ] **4. Determine planning needs** — check for existing plans and plan change requests; record old plan comment IDs for replacement; skip tasks with valid plans
+- [ ] **5. Analyze previous commits** — `git log --all --grep="<taskId>"` for each task/subtask
+- [ ] **6. Analyze staged changes** — `git status` and `git diff --cached` for work in progress
+- [ ] **7. MANDATORY: Analyze codebase** — explore affected files, patterns, dependencies, and test coverage
+- [ ] **8. Analyze external library deps** — check if `@smartsoft001` or `@smartsoft001-mobilems` changes are needed (mark as separate process)
+- [ ] **9. Create implementation plans** — generate structured plans per task/subtask with all required sections
+- [ ] **10. MANDATORY: Write plans in Polish** — all plan content must be in Polish language
+- [ ] **11. Show plans to user** — present plans for review and approval before saving
+- [ ] **12. MANDATORY: Confirm old plan deletion** — if replacing existing plans, ask user to confirm deletion of old plan comments before proceeding
+- [ ] **13. Delete old plan comments and save new ones** — delete outdated plan comments from Linear, then post new plans via MCP
+- [ ] **14. Confirm to user** — list saved plans with summaries and Linear links
+
 ## Role
 
 **You are a highly experienced software architect** with:
@@ -105,6 +140,9 @@ Create a list of tasks/subtasks that need planning:
 
 - `tasksNeedingPlan`: Array of task IDs that need a new or updated plan
 - `tasksWithExistingPlan`: Array of task IDs that already have valid plans (skip these)
+- `oldPlanCommentIds`: Map of task ID → comment ID for existing plan comments that will be replaced (needed for deletion in Step 9)
+
+**Important**: When a plan change is requested, record the **comment ID** of the existing plan comment. This ID is needed later to delete the old plan before saving the new one.
 
 **Important**: If ALL tasks already have valid plans and no changes are requested, inform the user and ask if they want to regenerate plans anyway.
 
@@ -405,7 +443,45 @@ _Plan generated by Claude Code_
 _Plan generated by Claude Code_
 ```
 
-### Step 9: Save Plans as Comments
+### Step 9: Confirm and Delete Old Plan Comments
+
+**This step applies only when replacing existing plans** (i.e., `oldPlanCommentIds` from Step 3a is not empty).
+
+Before saving new plans, ask the user to confirm deletion of old plan comments:
+
+```markdown
+## Zastąpienie istniejących planów
+
+Następujące komentarze z planami zostaną usunięte i zastąpione nowymi:
+
+| Task      | Stary komentarz (ID) |
+| --------- | -------------------- |
+| <task-id> | <comment-id>         |
+
+Czy potwierdzasz usunięcie starych planów i zapisanie nowych?
+```
+
+Use `AskUserQuestion` tool with options:
+
+- "Tak, usuń stare plany i zapisz nowe" (Recommended)
+- "Nie, zachowaj stare plany (zapisz nowe obok)"
+- "Anuluj"
+
+**If user confirms deletion:**
+
+1. For each task in `oldPlanCommentIds`, delete the old plan comment using `mcp__linear-server__delete_comment`
+2. If `delete_comment` is not available, add a strikethrough header to the old comment body: `~~## Implementation Plan~~ (Zastąpiony nowym planem)` — use `mcp__linear-server__update_comment` as fallback
+3. Then proceed to save new plan comments
+
+**If user chooses to keep old plans:**
+
+- Skip deletion, save new plans as additional comments (old plans remain)
+
+**If user cancels:**
+
+- Stop the entire process, do not save any plans
+
+### Step 9a: Save New Plans as Comments
 
 Use the MCP Linear server to create comments:
 
@@ -443,6 +519,7 @@ After successfully saving the plans, confirm to the user:
 12. **Identify external library changes**: Always check if task requires changes in `@smartsoft001` (repo: `../smartsoft001`) or `@smartsoft001-mobilems` (repo: `../mobilems-framework`). Mark these as separate process items, not part of current implementation
 13. **Skip tasks with existing plans**: Only create plans for tasks that don't have a plan yet, or where a newer comment requests plan changes. Don't regenerate plans unnecessarily.
 14. **Detect plan change requests**: Look for keywords in newer comments that indicate a plan change is needed (e.g., "zmień plan", "zaktualizuj plan", "popraw plan", "uwagi do planu")
+15. **Delete old plans when replacing**: When creating a replacement plan, always ask user to confirm deletion of the old plan comment. Delete old comment before saving new one to keep Linear comments clean. Record old plan comment IDs during Step 3a for use in Step 9
 
 ## Example with Subtasks
 

package/plugins/flow/{commands/push.md → skills/push/SKILL.md}

@@ -1,7 +1,63 @@
-# Push Command
+---
+name: push
+description: Push local changes to remote repository, update Linear task status, monitor CI pipeline, verify QA deployment, and optionally create pull requests for feature branches.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - WebFetch
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__update_issue
+  - mcp__linear-server__list_issue_statuses
+---
+
+# Push Skill
 
 Push local changes to remote and optionally update Linear task status.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+### Pre-Push
+
+- [ ] **1. Check git status** — verify branch, commits ahead, warn about uncommitted changes
+- [ ] **2. Get commits to push** — `git log origin/<branch>..HEAD --oneline`; exit if none
+- [ ] **3. Fetch Linear task** — get title, status, subtasks and their statuses via MCP
+- [ ] **4. Analyze subtasks** — classify completed vs incomplete, find reasons for incomplete ones
+- [ ] **5. MANDATORY: Show summary to user** — present commits + subtask status, ask about status change
+- [ ] **6. Update Linear status** — BEFORE push: set completed subtasks to "In Review", post summary comment in Polish
+- [ ] **7. MANDATORY: Write Linear comments in Polish** — all comments must be in Polish language
+
+### Push
+
+- [ ] **8. Push to remote** — `git push`; handle errors gracefully
+
+### Post-Push (branch-specific)
+
+#### If `development` branch:
+
+- [ ] **9a. Ask about deployment verification** — offer optional CI monitoring + QA check
+- [ ] **10a. Monitor CI pipeline** — poll `gh run view` every 30s until completion
+- [ ] **11a. Handle CI failure** — revert task to "To Do", post error comment to Linear
+- [ ] **12a. Verify package.json update** — `git pull`, compare versions
+- [ ] **13a. Verify QA deployment** — wait 5 min, check `<meta name="app-version">` matches
+
+#### If feature branch:
+
+- [ ] **9b. Check for existing PR** — `gh pr list --head <branch> --base development`
+- [ ] **10b. Ask about PR creation** — if no PR exists and subtasks are ready
+- [ ] **11b. Create PR** — `gh pr create` with structured summary
+
+### Final
+
+- [ ] **12. Show final status** — complete summary of all actions taken
+
 ## Usage
 
 ```
@@ -336,19 +392,78 @@ If user chooses not to verify, end the command here.
 
 **If workflow FAILED**:
 
-```markdown
-## ❌ CI Pipeline Failed
+1. **Get failed job logs**:
 
-**Workflow**: <workflow-name>
-**Run ID**: <run-id>
-**Conclusion**: failure
+   ```bash
+   gh run view <run-id> --log-failed 2>&1 | tail -100
+   ```
 
-### View logs
+2. **Revert Linear task to "To Do"**:
 
-Run `gh run view <run-id> --log-failed` to see error details.
+   If Linear task was provided and status was changed to "In Review":
 
-Or visit: https://github.com/<owner>/<repo>/actions/runs/<run-id>
-```
+   - Move the parent task back to "To Do" status
+   - For tasks with subtasks: Move all subtasks that were changed to "In Review" back to "To Do"
+
+3. **Add error comment to Linear task**:
+
+   Create a comment on the **parent task** with CI error details:
+
+   ```markdown
+   ## ❌ CI Build Failed
+
+   ### Branch
+
+   `<branch-name>`
+
+   ### Workflow
+
+   **Name**: <workflow-name>
+   **Run ID**: <run-id>
+   **URL**: https://github.com/<owner>/<repo>/actions/runs/<run-id>
+
+   ### Error Details
+   ```
+
+   <last 50-100 lines of error logs from gh run view --log-failed>
+
+   ```
+
+   ### Status
+
+   Task przywrócony do "To Do" z powodu błędu CI.
+
+   ---
+
+   _Raport wygenerowany przez Claude Code_
+   ```
+
+4. **Show error to user**:
+
+   ```markdown
+   ## ❌ CI Pipeline Failed
+
+   **Workflow**: <workflow-name>
+   **Run ID**: <run-id>
+   **Conclusion**: failure
+
+   ### Linear Task Status
+
+   ⚠️ Task [linearTaskId] przywrócony do "To Do"
+   ✅ Komentarz z błędem dodany do taska
+
+   ### View logs
+
+   Run `gh run view <run-id> --log-failed` to see error details.
+
+   Or visit: https://github.com/<owner>/<repo>/actions/runs/<run-id>
+
+   ### Następne kroki
+
+   1. Przeanalizuj błędy w CI
+   2. Napraw problemy lokalnie
+   3. Uruchom `/push-local` ponownie
+   ```
 
 Stop here if workflow failed.
 
@@ -485,7 +600,8 @@ Show complete summary:
 8. **Deployment verification is optional**: Always ask user before starting the 10-minute verification process
 9. **Read SITE_URL from .env.dev**: Use the SITE_URL variable from `.env.dev` file for QA verification
 10. **Version comparison**: Compare `package.json` version with `<meta name="app-version">` tag on QA site
-11. **Branch-specific post-push actions**:
+11. **Revert on CI failure**: If CI pipeline fails, move task back to "To Do" and add error comment
+12. **Branch-specific post-push actions**:
     - **`development` branch**: Offer deployment verification (CI monitoring + QA version check)
     - **Feature branch (e.g., `MOB-123`)**: Check/create PR to `development` when all subtasks are ready
 

package/plugins/flow-legacy/.claude-plugin/README.md

@@ -1,6 +1,6 @@
 # Flow-Legacy Plugin for Claude Code
 
-Development flow commands for **legacy Angular 14 projects** with Linear-driven workflow.
+Development flow skills for **legacy Angular 14 projects** with Linear-driven workflow.
 
 ## Target Projects
 
@@ -22,10 +22,10 @@ This plugin is designed for older MobileMS projects using:
 | Components | NgModules | Standalone |
 | Nx packages | `@nrwl/*` | `@nx/*` |
 
-## Commands
+## Workflow Skills
 
-| Command | Description |
-|---------|-------------|
+| Skill | Description |
+|-------|-------------|
 | `/commit` | Create conventional commit based on Linear task |
 | `/impl` | Implement plans from Linear task comments |
 | `/plan` | Create implementation plan and save to Linear |
@@ -67,15 +67,15 @@ Configure these in your `.mcp.json`:
 - Nx commands (test, lint, build)
 - Linear API (read/write issues, comments)
 - Playwright (screenshots)
-- Internal skills
+- Utility skills
 
 ### Requires Confirmation (ask)
-- Flow commands (/commit, /impl, /plan, /push)
+- Workflow skills (/commit, /impl, /plan, /push)
 - `git commit` - creating commits
 - `git push` - pushing to remote
 - `gh pr create` - creating pull requests
 
-## Skills
+## Utility Skills
 
 | Skill | Description |
 |-------|-------------|

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

@@ -1,5 +1,5 @@
 {
   "name": "flow-legacy",
-  "description": "Development flow commands for legacy Angular 14 projects with Linear-driven workflow",
-  "version": "2.70.0"
+  "description": "Development flow skills for legacy Angular 14 projects with Linear-driven workflow",
+  "version": "2.72.0"
 }

package/plugins/flow-legacy/.claude-plugin/settings.template.json

@@ -38,6 +38,7 @@
       "mcp__linear-server__list_issues",
       "mcp__linear-server__list_comments",
       "mcp__linear-server__create_comment",
+      "mcp__linear-server__delete_comment",
       "mcp__linear-server__update_issue",
       "mcp__linear-server__list_issue_statuses",
       "mcp__linear-server__create_issue",
@@ -72,4 +73,4 @@
   "enabledPlugins": {
     "flow-legacy@mobilems": true
   }
-}
+}

package/plugins/flow-legacy/{commands/commit.md → skills/commit/SKILL.md}

@@ -1,4 +1,17 @@
-# Commit Command
+---
+name: commit
+description: Create a conventional commit message based on Linear task and staged changes. Fetches task details, analyzes changes, generates commit message, and optionally runs parallelization analysis.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_comments
+---
+
+# Commit Skill
 
 Create a conventional commit message based on Linear task and staged changes.
 
@@ -12,6 +25,20 @@ Create a conventional commit message based on Linear task and staged changes.
 
 - `linearTaskId` - Linear task ID (e.g., ENG-123)
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+- [ ] **1. Fetch Linear task** — get title, description, labels/type from MCP Linear server
+- [ ] **2. Analyze staged changes** — run `git diff --cached` to understand scope
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop
+- [ ] **4. Read commitlint config** — read `commitlint.config.js` for valid scopes and format
+- [ ] **5. Generate commit message** — draft `<type>(<scope>): <subject>` with body and `Refs: <linearTaskId>`
+- [ ] **6. Show message to user** — present commit message for approval before proceeding
+- [ ] **7. MANDATORY: Pre-commit preparation** — run `nvm use 18` (legacy Node.js version)
+- [ ] **8. Create commit** — execute `git commit` with the approved message
+- [ ] **9. Parallelization analysis (optional)** — fetch Linear comments, search for orchestration plan, delegate to `shared-parallelization-analyzer` if found
+
 ## Instructions
 
 You are tasked with creating a git commit based on a Linear task and staged changes.

package/plugins/flow-legacy/{commands/impl.md → skills/impl/SKILL.md}

@@ -1,7 +1,59 @@
-# Implementation Command
+---
+name: impl
+description: Implement plans from Linear task comments using Angular 14 legacy patterns. Iteratively processes subtasks with TDD, UI classification, agent orchestration, and 3x3 rule checkpoints.
+allowed-tools:
+  - Bash
+  - Read
+  - Edit
+  - Write
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Task
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__update_issue
+  - mcp__linear-server__list_issue_statuses
+---
+
+# Implementation Skill
 
 Implement plans from Linear task comments. For tasks with subtasks, iteratively implement each subtask that is in "To Do" status.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+### Initial Setup
+
+- [ ] **1. Fetch task and subtasks** — delegate to `shared-linear-subtask-iterator` agent
+
+### Per Subtask (repeat for each "To Do" subtask)
+
+- [ ] **2. Set status to "In Progress"** — update subtask status via MCP (subtasks only, not parent)
+- [ ] **3. Fetch implementation plan** — find `## Implementation Plan` in task comments
+- [ ] **4. MANDATORY: UI change classification** — delegate to `shared-ui-classifier` agent, output `UI_CHANGE_REQUIRED: YES/NO`
+- [ ] **5. MANDATORY: Agent orchestration plan** — delegate to `shared-impl-orchestrator` with `Angular Version: 14 (LEGACY)`, post plan to Linear
+- [ ] **6. Check external library blockers** — if blockers found, set status to Blocked and skip
+- [ ] **7. Capture "before" screenshots** — if `UI_CHANGE_REQUIRED: YES`, launch `screenshot-reporter` in background
+- [ ] **8. MANDATORY: Implement with 3x3 rule** — pause every 3 changes, use `shared-tdd-developer` for ALL code (RED → GREEN → REFACTOR)
+- [ ] **9. MANDATORY: Use Angular 14 patterns** — `*ngIf`/`*ngFor`, constructor DI, `@Input()`/`@Output()`, BehaviorSubject — NEVER signals, `@if`/`@for`, `inject()`
+- [ ] **10. Verify implementation** — run tests, lint, build check
+- [ ] **11. Capture "after" screenshots** — if `UI_CHANGE_REQUIRED: YES`, capture + post comparison to Linear + cleanup
+- [ ] **12. MANDATORY: Screenshot verification** — output `SCREENSHOT_REQUIREMENT_MET: YES/NO`, block if missing
+- [ ] **13. Create completion comment** — delegate to `shared-impl-reporter`, post to Linear
+- [ ] **14. MANDATORY: Write reports in Polish** — all Linear comments must be in Polish language
+- [ ] **15. Update status** — delegate to `shared-linear-subtask-iterator` for status determination
+- [ ] **16. Agent evolution** — if user confirmed feedback, delegate to `shared-agent-evolver`
+- [ ] **17. Pause for user confirmation** — ALWAYS wait before proceeding to next subtask
+
+### Finalization
+
+- [ ] **18. Final summary** — present summary of all subtasks with statuses
+- [ ] **19. ALWAYS pause** — wait for user confirmation at end
+
 ## Role
 
 **You are a highly experienced senior TypeScript developer** with:
@@ -30,6 +82,7 @@ You implement code that is:
 **ALWAYS use these patterns in legacy projects:**
 
 ### Components
+
 ```typescript
 // CORRECT (Angular 14)
 @Component({
@@ -45,7 +98,7 @@ export class ExampleComponent implements OnInit {
 
   constructor(
     private readonly dataService: DataService,
-    private readonly router: Router
+    private readonly router: Router,
   ) {}
 
   ngOnInit(): void {
@@ -61,13 +114,12 @@ export class ExampleComponent implements OnInit {
 ```
 
 ### Templates
+
 ```html
 <!-- CORRECT (Angular 14) -->
 <div *ngIf="isLoading">Loading...</div>
 <ul *ngIf="items.length > 0">
-  <li *ngFor="let item of items; trackBy: trackByFn">
-    {{ item.name }}
-  </li>
+  <li *ngFor="let item of items; trackBy: trackByFn">{{ item.name }}</li>
 </ul>
 
 <!-- WRONG (Angular 20+ - DO NOT USE) -->
@@ -76,6 +128,7 @@ export class ExampleComponent implements OnInit {
 ```
 
 ### Services
+
 ```typescript
 // CORRECT (Angular 14)
 @Injectable({ providedIn: 'root' })
@@ -295,6 +348,7 @@ Use tools:
 - `Glob` and `Grep` for additional exploration if needed
 
 **CRITICAL - Angular 14 Pattern Enforcement:**
+
 - ALWAYS use `*ngIf`, `*ngFor` in templates
 - ALWAYS use constructor injection
 - ALWAYS use `@Input()`, `@Output()` decorators
@@ -313,6 +367,7 @@ Use tools:
 3. ✅ [Change 3 description] - `path/to/file3.ts`
 
 ### Angular 14 Patterns Used
+
 - Constructor DI: ✅
 - *ngIf/*ngFor: ✅
 - @Input/@Output: ✅
@@ -332,6 +387,26 @@ Use tools:
 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 — **ASK the user explicitly** if they want to create a Linear issue for the improvement.
+
+**When user provides a correction or pattern suggestion, ASK:**
+
+```
+🔄 Detected potential improvement suggestion:
+"[summary of user's correction]"
+
+Would you like to create a Linear issue for this pattern improvement?
+- Yes - File as Linear issue in "MobileMS Framework"
+- No - Note for this session only
+- Skip - Ignore this feedback
+```
+
+**Only feedback confirmed with "Yes"** should be collected as **evolution feedback items** and processed in Step 3g-evolve via `linear-suggestion` skill.
+
+Look for signals like: universal language ("always", "never"), pattern-level corrections, or explicit requests to update agent behavior.
+
 #### Step 3e: Verify Implementation
 
 After implementing:
@@ -408,6 +483,35 @@ The agent will determine the correct status and provide MCP command to execute.
 
 **Execute the status update** via MCP Linear server.
 
+#### Step 3g-evolve: Agent Evolution Checkpoint
+
+**Prerequisites**: Only execute this step if user confirmed at least one feedback item with "Yes" during 3x3 checkpoints.
+
+**Delegate to `shared-agent-evolver` agent:**
+
+```
+Analyze feedback from current subtask implementation:
+- Subtask ID: [current subtask ID]
+- User-confirmed corrections: [list of feedback items where user answered "Yes"]
+- Files that were implemented: [list of files modified/created]
+- Patterns the user corrected or suggested: [specific corrections]
+```
+
+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. File each proposal as a Linear issue in "MobileMS Framework" via `linear-suggestion` skill
+4. Return Evolution Report with created issue IDs
+
+**IMPORTANT**:
+
+- Agent files are NOT modified directly — proposals are filed as Linear issues for manual review
+- **Only process feedback explicitly confirmed by user** — do not auto-collect without asking
+- If no user-confirmed 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
 
 **Delegate to `shared-linear-subtask-iterator` agent:**
@@ -460,13 +564,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   |
+| 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:
 
@@ -489,6 +594,7 @@ To Do → In Progress → In Review (if completed)
 11. **Follow existing patterns**: Match the codebase conventions when implementing
 12. **Commit changes**: After each subtask implementation, consider if a commit is needed
 13. **Ask for clarification**: If implementation plan is unclear, ask before proceeding
+14. **Ask before collecting feedback for agent evolution**: When user provides corrections or suggestions during implementation, **explicitly ask** if they want to create a Linear issue for the improvement. Only user-confirmed feedback (answered "Yes") should be processed at evolution checkpoints (Step 3g-evolve) via `shared-agent-evolver` agent.
 
 ---
 

package/plugins/flow-legacy/skills/linear-suggestion/SKILL.md

@@ -1,16 +1,16 @@
 ---
 name: linear-suggestion
-description: Create a Linear issue in the "MobileMS Framework" project with a suggestion for agent, command, or skill improvements.
+description: Create a Linear issue in the "MobileMS Framework" project with a suggestion for agent or skill improvements.
 allowed-tools: mcp__linear-server__create_issue
 ---
 
 # Linear Suggestion
 
-Create a Linear issue in the **MobileMS Framework** project containing a suggestion for improving agent definitions, commands, or skills. Used by automated analysis agents to propose changes without blocking the workflow.
+Create a Linear issue in the **MobileMS Framework** project containing a suggestion for improving agent definitions or skills. Used by automated analysis agents to propose changes without blocking the workflow.
 
 ## When to Use
 
-- When an automated agent (e.g., `shared-parallelization-analyzer`) identifies a recurring pattern that could improve an agent, command, or skill
+- When an automated agent (e.g., `shared-parallelization-analyzer`) identifies a recurring pattern that could improve an agent or skill
 - When proposing orchestrator rule changes based on parallelization analysis
 - When any non-interactive process needs to suggest framework improvements
 
@@ -18,13 +18,13 @@ Create a Linear issue in the **MobileMS Framework** project containing a suggest
 
 The invoking agent must provide:
 
-| Parameter     | Required | Description                                                     |
-| ------------- | -------- | --------------------------------------------------------------- |
-| `title`       | YES      | Short summary of the suggestion (max 100 chars)                 |
-| `description` | YES      | Full markdown description with rationale and proposed changes    |
+| Parameter     | Required | Description                                                                   |
+| ------------- | -------- | ----------------------------------------------------------------------------- |
+| `title`       | YES      | Short summary of the suggestion (max 100 chars)                               |
+| `description` | YES      | Full markdown description with rationale and proposed changes                 |
 | `source`      | YES      | Agent that generated the suggestion (e.g., `shared-parallelization-analyzer`) |
-| `targetFile`  | NO       | Path to the file to be modified (e.g., `agents/shared-impl-orchestrator.md`) |
-| `category`    | NO       | One of: `OPTIMIZATION`, `NEW_RULE`, `PATTERN_UPDATE`, `BUG_FIX` |
+| `targetFile`  | NO       | Path to the file to be modified (e.g., `agents/shared-impl-orchestrator.md`)  |
+| `category`    | NO       | One of: `OPTIMIZATION`, `NEW_RULE`, `PATTERN_UPDATE`, `BUG_FIX`               |
 
 ## Issue Format
 
@@ -129,4 +129,4 @@ Linear issue created:
 - ID: MOB-815
 - Title: [Agent Suggestion] Add parallel scaffolding rule to orchestrator
 - URL: https://linear.app/mobilems/issue/MOB-815
-```
+```

package/plugins/flow-legacy/{commands/plan.md → skills/plan/SKILL.md}

@@ -1,7 +1,43 @@
-# Plan Create Command
+---
+name: plan
+description: Create an implementation plan for a Linear task and save it as a comment. Analyzes codebase with Angular 14 legacy patterns, previous commits, and external dependencies.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__delete_comment
+---
+
+# Plan Skill
 
 Create an implementation plan for a Linear task and save it as a comment. If the task has subtasks, create individual plans for each subtask.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+- [ ] **1. Fetch Linear task** — get title, description, labels, priority, estimate from MCP Linear server
+- [ ] **2. Fetch subtasks** — check for children; if present, plan each subtask individually
+- [ ] **3. Fetch existing comments** — check parent task and each subtask for existing context
+- [ ] **4. Determine planning needs** — check for existing plans and plan change requests; record old plan comment IDs for replacement; skip tasks with valid plans
+- [ ] **5. Analyze previous commits** — `git log --all --grep="<taskId>"` for each task/subtask
+- [ ] **6. Analyze staged changes** — `git status` and `git diff --cached` for work in progress
+- [ ] **7. MANDATORY: Analyze codebase** — explore affected files, patterns, dependencies, and test coverage
+- [ ] **8. MANDATORY: Verify Angular 14 patterns** — confirm `*ngIf`/`*ngFor`, constructor DI, `@Input()`/`@Output()`, BehaviorSubject in existing code
+- [ ] **9. Analyze external library deps** — check if `@smartsoft001` or `@smartsoft001-mobilems` changes are needed (mark as separate process)
+- [ ] **10. Create implementation plans** — generate structured plans per task/subtask with all required sections, using Angular 14 patterns
+- [ ] **11. MANDATORY: Write plans in Polish** — all plan content must be in Polish language
+- [ ] **12. Show plans to user** — present plans for review and approval before saving
+- [ ] **13. MANDATORY: Confirm old plan deletion** — if replacing existing plans, ask user to confirm deletion of old plan comments before proceeding
+- [ ] **14. Delete old plan comments and save new ones** — delete outdated plan comments from Linear, then post new plans via MCP
+- [ ] **15. Confirm to user** — list saved plans with summaries and Linear links
+
 ## Role
 
 **You are a highly experienced software architect** with:
@@ -38,17 +74,20 @@ You create plans that are:
 When creating plans, always use these legacy patterns:
 
 ### Components
+
 - Use `@Component` with `NgModule` (NOT standalone)
 - Use `*ngIf` and `*ngFor` (NOT `@if` and `@for`)
 - Use constructor injection (NOT `inject()`)
 - Use `@Input()` and `@Output()` decorators (NOT `input()`, `output()`)
 
 ### Services
+
 - Use `BehaviorSubject` and `Observable` (NOT signals)
 - Use constructor injection
 - Use `@Injectable({ providedIn: 'root' })` or module providers
 
 ### State Management
+
 - Use NgRx Store/Effects or BehaviorSubject patterns
 - NO signals, computed(), or effect()
 
@@ -126,6 +165,9 @@ Create a list of tasks/subtasks that need planning:
 
 - `tasksNeedingPlan`: Array of task IDs that need a new or updated plan
 - `tasksWithExistingPlan`: Array of task IDs that already have valid plans (skip these)
+- `oldPlanCommentIds`: Map of task ID → comment ID for existing plan comments that will be replaced (needed for deletion in Step 9)
+
+**Important**: When a plan change is requested, record the **comment ID** of the existing plan comment. This ID is needed later to delete the old plan before saving the new one.
 
 **Important**: If ALL tasks already have valid plans and no changes are requested, inform the user and ask if they want to regenerate plans anyway.
 
@@ -185,6 +227,7 @@ Use tools like:
 - `Read` to understand specific implementations
 
 **Important**: Always check for Angular 14 patterns in existing code:
+
 - Look for `*ngIf`, `*ngFor` usage (NOT `@if`, `@for`)
 - Look for constructor injection patterns
 - Look for `@Input()`, `@Output()` decorators
@@ -297,6 +340,7 @@ Create a **separate plan for each subtask** that includes:
 [Key findings from codebase exploration]
 
 **Angular 14 patterns to follow:**
+
 - Use `*ngIf` / `*ngFor` for control flow
 - Use constructor injection for DI
 - Use `@Input()` / `@Output()` for component communication
@@ -393,6 +437,7 @@ _Plan generated by Claude Code (flow-legacy)_
 [Findings specific to this subtask]
 
 **Angular 14 patterns to follow:**
+
 - Use `*ngIf` / `*ngFor` for control flow
 - Use constructor injection for DI
 - Use `@Input()` / `@Output()` for component communication
@@ -443,7 +488,45 @@ _Plan generated by Claude Code (flow-legacy)_
 _Plan generated by Claude Code (flow-legacy)_
 ```
 
-### Step 9: Save Plans as Comments
+### Step 9: Confirm and Delete Old Plan Comments
+
+**This step applies only when replacing existing plans** (i.e., `oldPlanCommentIds` from Step 3a is not empty).
+
+Before saving new plans, ask the user to confirm deletion of old plan comments:
+
+```markdown
+## Zastąpienie istniejących planów
+
+Następujące komentarze z planami zostaną usunięte i zastąpione nowymi:
+
+| Task      | Stary komentarz (ID) |
+| --------- | -------------------- |
+| <task-id> | <comment-id>         |
+
+Czy potwierdzasz usunięcie starych planów i zapisanie nowych?
+```
+
+Use `AskUserQuestion` tool with options:
+
+- "Tak, usuń stare plany i zapisz nowe" (Recommended)
+- "Nie, zachowaj stare plany (zapisz nowe obok)"
+- "Anuluj"
+
+**If user confirms deletion:**
+
+1. For each task in `oldPlanCommentIds`, delete the old plan comment using `mcp__linear-server__delete_comment`
+2. If `delete_comment` is not available, add a strikethrough header to the old comment body: `~~## Implementation Plan~~ (Zastąpiony nowym planem)` — use `mcp__linear-server__update_comment` as fallback
+3. Then proceed to save new plan comments
+
+**If user chooses to keep old plans:**
+
+- Skip deletion, save new plans as additional comments (old plans remain)
+
+**If user cancels:**
+
+- Stop the entire process, do not save any plans
+
+### Step 9a: Save New Plans as Comments
 
 Use the MCP Linear server to create comments:
 
@@ -482,6 +565,7 @@ After successfully saving the plans, confirm to the user:
 13. **Skip tasks with existing plans**: Only create plans for tasks that don't have a plan yet, or where a newer comment requests plan changes. Don't regenerate plans unnecessarily.
 14. **Detect plan change requests**: Look for keywords in newer comments that indicate a plan change is needed (e.g., "zmień plan", "zaktualizuj plan", "popraw plan", "uwagi do planu")
 15. **Use Angular 14 patterns**: Always plan for `*ngIf`/`*ngFor`, constructor DI, `@Input()`/`@Output()`, BehaviorSubject - NOT signals, `@if`/`@for`, or `inject()`
+16. **Delete old plans when replacing**: When creating a replacement plan, always ask user to confirm deletion of the old plan comment. Delete old comment before saving new one to keep Linear comments clean. Record old plan comment IDs during Step 3a for use in Step 9
 
 ---
 

package/plugins/flow-legacy/{commands/push.md → skills/push/SKILL.md}

@@ -1,7 +1,63 @@
-# Push Command
+---
+name: push
+description: Push local changes to remote repository, update Linear task status, monitor CI pipeline, verify QA deployment, and optionally create pull requests for feature branches. Uses Angular 14 legacy patterns.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - WebFetch
+  - mcp__linear-server__get_issue
+  - mcp__linear-server__list_issues
+  - mcp__linear-server__list_comments
+  - mcp__linear-server__create_comment
+  - mcp__linear-server__update_issue
+  - mcp__linear-server__list_issue_statuses
+---
+
+# Push Skill
 
 Push local changes to remote and optionally update Linear task status.
 
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+### Pre-Push
+
+- [ ] **1. Check git status** — verify branch, commits ahead, warn about uncommitted changes
+- [ ] **2. Get commits to push** — `git log origin/<branch>..HEAD --oneline`; exit if none
+- [ ] **3. Fetch Linear task** — get title, status, subtasks and their statuses via MCP
+- [ ] **4. Analyze subtasks** — classify completed vs incomplete, find reasons for incomplete ones
+- [ ] **5. MANDATORY: Show summary to user** — present commits + subtask status, ask about status change
+- [ ] **6. Update Linear status** — BEFORE push: set completed subtasks to "In Review", post summary comment in Polish
+- [ ] **7. MANDATORY: Write Linear comments in Polish** — all comments must be in Polish language
+
+### Push
+
+- [ ] **8. Push to remote** — `git push`; handle errors gracefully
+
+### Post-Push (branch-specific)
+
+#### If `development` branch:
+
+- [ ] **9a. Ask about deployment verification** — offer optional CI monitoring + QA check
+- [ ] **10a. Monitor CI pipeline** — poll `gh run view` every 30s until completion
+- [ ] **11a. Handle CI failure** — revert task to "To Do", post error comment to Linear
+- [ ] **12a. Verify package.json update** — `git pull`, compare versions
+- [ ] **13a. Verify QA deployment** — wait 5 min, check `<meta name="app-version">` matches
+
+#### If feature branch:
+
+- [ ] **9b. Check for existing PR** — `gh pr list --head <branch> --base development`
+- [ ] **10b. Ask about PR creation** — if no PR exists and subtasks are ready
+- [ ] **11b. Create PR** — `gh pr create` with structured summary including Angular 14 tech stack
+
+### Final
+
+- [ ] **12. Show final status** — complete summary of all actions taken
+
 ## Usage
 
 ```
@@ -337,19 +393,78 @@ If user chooses not to verify, end the command here.
 
 **If workflow FAILED**:
 
-```markdown
-## ❌ CI Pipeline Failed
+1. **Get failed job logs**:
 
-**Workflow**: <workflow-name>
-**Run ID**: <run-id>
-**Conclusion**: failure
+   ```bash
+   gh run view <run-id> --log-failed 2>&1 | tail -100
+   ```
 
-### View logs
+2. **Revert Linear task to "To Do"**:
 
-Run `gh run view <run-id> --log-failed` to see error details.
+   If Linear task was provided and status was changed to "In Review":
 
-Or visit: https://github.com/<owner>/<repo>/actions/runs/<run-id>
-```
+   - Move the parent task back to "To Do" status
+   - For tasks with subtasks: Move all subtasks that were changed to "In Review" back to "To Do"
+
+3. **Add error comment to Linear task**:
+
+   Create a comment on the **parent task** with CI error details:
+
+   ```markdown
+   ## ❌ CI Build Failed
+
+   ### Branch
+
+   `<branch-name>`
+
+   ### Workflow
+
+   **Name**: <workflow-name>
+   **Run ID**: <run-id>
+   **URL**: https://github.com/<owner>/<repo>/actions/runs/<run-id>
+
+   ### Error Details
+   ```
+
+   <last 50-100 lines of error logs from gh run view --log-failed>
+
+   ```
+
+   ### Status
+
+   Task przywrócony do "To Do" z powodu błędu CI.
+
+   ---
+
+   _Raport wygenerowany przez Claude Code (flow-legacy)_
+   ```
+
+4. **Show error to user**:
+
+   ```markdown
+   ## ❌ CI Pipeline Failed
+
+   **Workflow**: <workflow-name>
+   **Run ID**: <run-id>
+   **Conclusion**: failure
+
+   ### Linear Task Status
+
+   ⚠️ Task [linearTaskId] przywrócony do "To Do"
+   ✅ Komentarz z błędem dodany do taska
+
+   ### View logs
+
+   Run `gh run view <run-id> --log-failed` to see error details.
+
+   Or visit: https://github.com/<owner>/<repo>/actions/runs/<run-id>
+
+   ### Następne kroki
+
+   1. Przeanalizuj błędy w CI
+   2. Napraw problemy lokalnie
+   3. Uruchom `/push` ponownie
+   ```
 
 Stop here if workflow failed.
 
@@ -416,7 +531,8 @@ Angular 14 (legacy patterns)
 7. **Document incomplete subtasks**: Always explain WHY a subtask wasn't completed
 8. **Deployment verification is optional**: Always ask user before starting the verification process
 9. **Read SITE_URL from .env.dev**: Use the SITE_URL variable from `.env.dev` file for QA verification
-10. **Branch-specific post-push actions**:
+10. **Revert on CI failure**: If CI pipeline fails, move task back to "To Do" and add error comment
+11. **Branch-specific post-push actions**:
     - **`development` branch**: Offer deployment verification (CI monitoring + QA version check)
     - **Feature branch (e.g., `MOB-123`)**: Check/create PR to `development` when all subtasks are ready