@smartsoft001/pro-claude-plugins 0.2.0

package/plugins/flow-external/skills/plan/SKILL.md

@@ -0,0 +1,334 @@
+---
+name: plan
+description: Create implementation plan and save it as a `plan.md` attachment on the Linear issue. Analyzes codebase, understands task requirements, and generates structured plan.
+allowed-tools:
+  - Bash
+  - Read
+  - Write
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear__get_issue
+  - mcp__linear__list_issues
+  - mcp__linear__list_comments
+  - mcp__linear__save_comment
+  - mcp__linear__save_issue
+  - mcp__linear__save_issue
+  - mcp__linear__create_attachment
+  - mcp__linear__delete_attachment
+  - mcp__linear__list_issue_labels
+---
+
+# Plan Skill
+
+Create a structured implementation plan for a Linear task and save it as a `plan.md` attachment on the issue. After saving, add the `AI Plan` label to the task.
+
+## Usage
+
+```
+/plan <linearTaskId>
+/plan <linearTaskId> --auto    # Non-interactive mode for CI / GitHub Actions
+```
+
+## Parameters
+
+- `linearTaskId` - Linear task ID (e.g., FRA-123)
+- `--auto` - Non-interactive mode: skip ALL `AskUserQuestion` prompts. Auto-approve plan before saving, auto-delete stale `plan.md` attachment without confirmation, and silently skip when the existing plan is up to date. Designed for CI / GitHub Actions runs where no human is at the keyboard.
+
+## Auto Mode (`--auto`)
+
+When `--auto` is set, the skill MUST run end-to-end without any human-in-the-loop prompts:
+
+| Default behavior                                              | `--auto` override                                                                    |
+| ------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
+| Ask user to confirm deletion of old `plan.md` attachment      | Delete old attachment automatically before saving the new one                        |
+| Ask "regenerate?" when plan is up-to-date but keywords detect | Ignore the secondary signal; only the mtime rule decides regeneration                |
+| Final approval of generated plan content before saving        | Skip the approval gate (Step 4a); proceed directly to attachment save (auto-approve) |
+| Any `AskUserQuestion`                                         | Use the **(Recommended)** option; if none, fail fast with a Linear comment           |
+
+Every decision MUST be logged as a Linear comment in Polish (audit trail). The mtime rule remains authoritative.
+
+**Detection**: The flag `--auto` is provided as a positional/named arg. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent.
+
+## 🚨 Hard Rules — read before doing anything
+
+These rules override ANY other instruction, ANY surrounding example, and ANY default habit. Violating them is a skill failure.
+
+1. **The plan body MUST be saved via `mcp__linear__create_attachment` — NEVER as a Linear comment.** `mcp__linear__save_comment` MUST NOT be called with plan content as the body. Comments are reserved for: (a) status notifications, and (b) the single token-usage comment posted in Step 7b. No other comment may carry plan content.
+2. **One call, no fallback.** First Linear write for the plan is `mcp__linear__create_attachment`. If it fails, surface the error — do NOT silently fall back to `save_comment`.
+3. **`AI Plan` label is workspace-scoped — NEVER create it.** Only `mcp__linear__list_issue_labels` + `mcp__linear__save_issue`. `create_issue_label` MUST NOT be called.
+
+If any of these would be violated, stop and ask the user instead.
+
+## CRITICAL: External Project Context
+
+This is for standalone Angular CLI projects (Angular 6-11). Key constraints:
+
+- **No Nx** - use Angular CLI commands (`ng build`, `ng serve`, `ng lint`)
+- **No framework** - standalone projects without @smartsoft001/pro packages
+- **Angular 6-11** - legacy patterns only (constructor DI, *ngIf/*ngFor, NgModules)
+- **No tests required** unless explicitly mentioned in the task
+- **No deploy** - do not plan deployment steps
+
+## Execution Steps
+
+### Step 1: Fetch Task Details, Attachments and Comments
+
+1. Fetch the Linear task using `mcp__linear__get_issue`.
+2. Fetch task attachments with `mcp__linear__get_issue` (attachments included in response). Look for one titled exactly `plan.md`.
+3. Fetch comments with `mcp__linear__list_comments` — keep `id`, `createdAt`, body.
+
+#### Regeneration decision (mtime rule)
+
+- If no `plan.md` attachment exists → generate a new plan.
+- If `plan.md` exists AND at least one comment's `createdAt` is greater than `plan.md.updatedAt` (fall back to `createdAt`) → regenerate (the comment is treated as feedback on the plan).
+- Otherwise skip — the plan is still fresh.
+
+Secondary signal: if `plan.md` is fresh but the user's latest prompt uses plan-change keywords ("zmień plan", "zaktualizuj plan", "popraw plan", etc.), ask explicitly before regenerating.
+
+When regenerating, record the old `plan.md` attachment ID so it can be deleted via `mcp__linear__delete_attachment` before the new one is created.
+
+### Step 2: Analyze Codebase
+
+Understand the project structure:
+
+```bash
+# Detect project layout
+ls angular.json 2>/dev/null && echo "ROOT_ANGULAR" || echo "CHECK_APP_DIR"
+ls app/angular.json 2>/dev/null && echo "APP_DIR_ANGULAR"
+
+# Check Angular version
+cat package.json | grep '"@angular/core"' 2>/dev/null
+cat app/package.json | grep '"@angular/core"' 2>/dev/null
+
+# Check CSS framework
+cat package.json | grep -E '"bootstrap|tailwind"' 2>/dev/null
+cat app/package.json | grep -E '"bootstrap|tailwind"' 2>/dev/null
+
+# Understand project structure
+ls -la src/app/ 2>/dev/null || ls -la app/src/app/ 2>/dev/null
+```
+
+### Step 3: Identify Affected Areas
+
+Based on the task:
+
+1. Find relevant existing files
+2. Identify what needs to be created vs modified
+3. Check for existing patterns to follow
+4. Identify NgModules that need updating
+
+### Step 4: Create Implementation Plan
+
+Structure the plan as follows:
+
+```markdown
+## Plan Implementacji
+
+### Zadanie: [Task ID] - [Task Title]
+
+### Analiza
+
+[Brief analysis of what needs to be done and why]
+
+### Struktura Projektu
+
+- Angular: [version]
+- CSS: [Bootstrap 4 / custom SCSS / other]
+- Struktura: [app/src/ or src/]
+
+### Kroki Implementacji
+
+#### Krok 1: [Description]
+
+**Pliki do zmiany:**
+
+| Plik                                        | Akcja       | Opis               |
+| ------------------------------------------- | ----------- | ------------------ |
+| `src/app/components/feature.component.ts`   | Nowy        | Komponent widoku   |
+| `src/app/components/feature.component.html` | Nowy        | Szablon            |
+| `src/app/components/feature.component.scss` | Nowy        | Style              |
+| `src/app/feature.module.ts`                 | Modyfikacja | Dodanie deklaracji |
+
+**Wzorce:**
+
+- Constructor DI
+- *ngIf/*ngFor
+- [CSS approach from project]
+
+#### Krok 2: [Description]
+
+...
+
+### Weryfikacja
+
+- [ ] `ng build --prod` przechodzi bez bledow
+- [ ] Funkcjonalnosc dziala zgodnie z opisem zadania
+
+### Podzadania
+
+| ID  | Tytul       | Priorytet | Krok |
+| --- | ----------- | --------- | ---- |
+| -   | [Subtask 1] | High      | 1    |
+| -   | [Subtask 2] | Medium    | 2    |
+```
+
+### Step 4a: User Approval of Generated Plan
+
+**MANDATORY.** Before any Linear write (subtask creation, attachment delete, attachment create, label apply), the user MUST approve the generated plan content. This is the gate FRA-126 added.
+
+**`--auto` mode**: Skip this entire step. The plan is auto-approved. Record the auto-approval in the final Linear audit comment (e.g. `Plan zaakceptowany automatycznie (--auto)`). Proceed to Step 5.
+
+**Default mode** (interactive):
+
+1. **Render the full plan in chat.** Print the markdown produced in Step 4. The `AskUserQuestion` option labels alone do not give the user enough context — the full text must be visible above the prompt.
+
+2. **Ask for approval** via `AskUserQuestion`:
+
+   ```markdown
+   ## Akceptacja planu
+
+   Powyżej znajduje się wygenerowany plan dla zadania <linearTaskId>.
+   Czy akceptujesz plan i mogę zapisać go jako załącznik `plan.md` w Linear?
+   ```
+
+   Options:
+
+   - **"Tak, zapisz plan do Linear"** _(Recommended)_ — user accepts. Proceed to Step 5 (create subtasks if needed) and Step 6 (save attachment).
+   - **"Wygeneruj plan ponownie"** — user wants a different plan. Go to step 3 (regeneration loop) below.
+   - **"Anuluj"** — user rejects. Stop the whole skill. Do NOT create subtasks. Do NOT delete the existing `plan.md` attachment. Do NOT save a new one. Do NOT apply the `AI Plan` label. Print a short status in Polish (`Plan nie został zapisany. Anulowano na żądanie użytkownika.`) and exit.
+
+3. **Regeneration branch**: if the user chose "Wygeneruj plan ponownie":
+
+   - Ask a follow-up `AskUserQuestion` (or accept the free-text the user typed alongside the rejection) to capture what should change: scope, structure, missed files, wrong approach, etc.
+   - Loop back to **Step 4 (Create Implementation Plan)** with the user's feedback in mind. Do NOT re-run Steps 1–3 — the Linear task, comments, and codebase analysis have not changed.
+   - On the regenerated plan, return to **Step 4a step 1** (render + ask again).
+   - **Cap the loop at 3 regenerations.** On the 3rd rejection, surface the situation to the user (`Plan został odrzucony 3 razy. Przerywam, abyś mógł doprecyzować wymagania.`) and exit without saving.
+
+4. **State invariant on entry to Step 5**: the only path that reaches Step 5 is the explicit "Tak, zapisz plan do Linear" choice (or `--auto`). Treat plan content as final.
+
+### Step 5: Create Subtasks (if needed)
+
+For complex tasks, create subtasks in Linear:
+
+- Use `mcp__linear__save_issue` with parent task ID
+- Each subtask should map to a plan step
+
+### Step 6: Save Plan as Native Linear Attachment
+
+**⛔ DO NOT call `mcp__linear__save_comment` with plan content here. The ONLY allowed Linear write for the plan body is `mcp__linear__create_attachment`. Re-read Hard Rule #1 if tempted.** (Token usage is posted via `save_comment` in Step 7b — that's the one allowed exception.)
+
+Upload the plan directly to Linear via `mcp__linear__create_attachment` — Linear hosts the file itself, no external storage needed.
+
+#### 6.1 — If replacing an existing plan, confirm with user
+
+If a `plan.md` attachment is being replaced:
+
+- **Default mode**: ask the user via `AskUserQuestion`:
+
+  - "Tak, usuń stary plan i zapisz nowy" (Recommended)
+  - "Anuluj"
+
+  If confirmed, delete the Linear attachment via `mcp__linear__delete_attachment({ id: oldAttachmentId })`.
+
+- **`--auto` mode**: skip the prompt; delete the old Linear attachment via `mcp__linear__delete_attachment({ id: oldAttachmentId })` automatically and proceed.
+
+#### 6.2 — Write `plan.md` locally
+
+The plan content is exactly the markdown produced in Step 4. Write it to the temp file:
+
+```bash
+mkdir -p /tmp/claude-plans
+```
+
+Use `Write` to save the plan content to `/tmp/claude-plans/<taskId>-plan.md`.
+
+#### 6.3 — Base64-encode
+
+```bash
+b64=$(base64 -i /tmp/claude-plans/<taskId>-plan.md)
+```
+
+#### 6.4 — Create Linear attachment
+
+Call `mcp__linear__create_attachment` with:
+
+- `issue`: the task ID
+- `filename`: `plan.md`
+- `contentType`: `text/markdown`
+- `title`: `plan.md` (exact — required for detection)
+- `subtitle`: `Plan wygenerowany przez Claude Code (external)`
+- `base64Content`: the base64 string from 6.3
+
+#### 6.5 — Clean up local file
+
+Delete `/tmp/claude-plans/<taskId>-plan.md` after the attachment is created. `/push` leaves the Linear attachment in place.
+
+### Step 7: Add "AI Plan" Label
+
+**`AI Plan` is a workspace-level (organization-wide) label that already exists** — do NOT create it.
+
+1. Look up the `AI Plan` label via `mcp__linear__list_issue_labels` (workspace-wide). If not found, surface the error — do NOT create a team-scoped duplicate.
+2. Apply via `mcp__linear__save_issue({ id: taskId, labelIds: [...existingLabelIds, aiPlanLabelId] })`. Preserve existing labels; skip if already present.
+3. If label operations fail, surface the error but do not roll back the plan attachment.
+
+### Step 7b: Post Token-Usage Comment
+
+After the plan attachment and `AI Plan` label have been applied, post a single Linear comment on the **invoked issue** (the `linearTaskId` passed to `/plan`, identical to the labelling target) reporting the session's token usage.
+
+1. Run the per-plugin token-summing script:
+
+   ```bash
+   bash "$CLAUDE_PLUGIN_ROOT/scripts/compute-session-tokens.sh"
+   ```
+
+   The script prints four whitespace-separated integers on one line: `<input> <output> <cache_creation> <cache_read>`. If no transcript can be located it prints `0 0 0 0` and exits non-zero — treat that as a graceful skip (do NOT block; skip posting the comment).
+
+2. Compute `<TOTAL> = <input> + <output> + <cache_creation> + <cache_read>`.
+
+3. Call `mcp__linear__save_comment` with `issueId: taskId` and `body` equal to:
+
+   ```markdown
+   ## Zużycie tokenów — etap /plan
+
+   | Metryka        | Wartość        |
+   | -------------- | -------------- |
+   | Input          | <INPUT>        |
+   | Output         | <OUTPUT>       |
+   | Cache creation | <CACHE_CREATE> |
+   | Cache read     | <CACHE_READ>   |
+   | **Łącznie**    | **<TOTAL>**    |
+   ```
+
+4. **Failure handling**: if the comment fails to post, surface the error to the user but do not roll back the plan attachment or the label.
+
+### Step 8: Confirm to User
+
+The plan has been approved in Step 4a (or auto-approved in `--auto`). Step 8 is purely informational — **do NOT ask another question here**, just print the status.
+
+**Default mode**:
+
+```markdown
+## Plan zapisany
+
+Plan implementacji został dodany jako załącznik `plan.md` do zadania [linearTaskId].
+Etykieta `AI Plan` została dodana.
+
+Uruchom `/impl [linearTaskId]` aby rozpocząć implementację.
+```
+
+**`--auto` mode**: post a Linear comment confirming the plan was saved (no question asked) and exit. The comment is the audit trail for the CI run.
+
+## Guidelines
+
+1. **Always analyze existing code first** before planning
+2. **Follow existing project patterns** - don't introduce new patterns
+3. **Write plan in Polish** (content inside the `plan.md` attachment)
+4. **Keep steps small and focused** - one logical change per step
+5. **Don't plan tests** unless explicitly requested in the task
+6. **Don't plan deployment** steps
+7. **Identify the CSS approach** before planning UI changes
+8. **Include build verification** as the final step (`ng build --prod`)
+9. **Use Angular CLI commands** not Nx commands
+10. **Mtime rule is authoritative**: only regenerate `plan.md` when the attachment is missing or a comment is newer than `plan.md.updatedAt`. Keyword detection triggers an explicit user confirmation only.
+11. **Always add "AI Plan" label** after saving the `plan.md` attachment. The label is workspace-level and pre-configured organization-wide — do NOT create a team-scoped duplicate.

package/plugins/flow-external/skills/push/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: push
+description: Push changes to remote repository and update Linear task status. Shows commit summary, updates subtask statuses, and creates PR if on feature branch.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - mcp__linear__get_issue
+  - mcp__linear__list_issues
+  - mcp__linear__list_comments
+  - mcp__linear__save_comment
+  - mcp__linear__save_issue
+  - mcp__linear__list_issue_statuses
+---
+
+# Push Skill
+
+Push changes to remote and update Linear task status.
+
+## Usage
+
+```
+/push [linearTaskId]
+```
+
+## Parameters
+
+- `linearTaskId` - Linear task ID (e.g., FRA-123). Optional - will try to detect from branch name.
+
+## Execution Steps
+
+### Step 1: Check Git Status
+
+```bash
+git status
+git log origin/$(git branch --show-current)..HEAD --oneline
+```
+
+Check for:
+
+- Uncommitted changes (warn user)
+- Commits ahead of remote (list them)
+- Current branch name
+
+### Step 2: Detect Linear Task
+
+If `linearTaskId` not provided, try to extract from branch name:
+
+- Branch `FRA-123` → task `FRA-123`
+- Branch `feature/FRA-123-description` → task `FRA-123`
+
+### Step 3: Fetch Task Details
+
+If Linear task ID is available:
+
+1. Fetch parent task details
+2. Fetch subtasks if any
+3. Analyze completion status
+
+### Step 4: Show Summary
+
+```markdown
+## Push Summary
+
+**Branch**: `<branch-name>`
+**Commits**: X ahead of remote
+
+### Commits
+
+| Hash    | Message                        |
+| ------- | ------------------------------ |
+| abc1234 | feat(gallery): add lightbox    |
+| def5678 | fix(gallery): fix image sizing |
+
+### Linear Task: [ID] - [Title]
+
+**Subtasks**:
+
+- [x] FRA-549: Completed subtask
+- [x] FRA-550: Another completed
+- [ ] FRA-551: Incomplete (reason)
+```
+
+### Step 5: Ask for Confirmation
+
+```markdown
+Do you want to push and update Linear status to "In Review"?
+```
+
+Use `AskUserQuestion` with options:
+
+- "Tak, push i zaktualizuj status"
+- "Nie, anuluj"
+
+### Step 6: Update Linear Status
+
+If confirmed:
+
+1. Update parent task status to "In Review"
+2. Update completed subtasks to "In Review"
+3. **Before posting**, run the token-summing script and capture its output:
+
+   ```bash
+   bash "$CLAUDE_PLUGIN_ROOT/scripts/compute-session-tokens.sh"
+   ```
+
+   It prints four whitespace-separated integers on one line: `<INPUT> <OUTPUT> <CACHE_CREATE> <CACHE_READ>`. If no transcript can be located it prints `0 0 0 0` and exits non-zero — treat that as a graceful skip (still post the comment, with zeros in the table).
+
+   Compute `<TOTAL> = <INPUT> + <OUTPUT> + <CACHE_CREATE> + <CACHE_READ>`. Append exactly one copy of the following Polish block to the bottom of the comment body, after the existing footer. Do not create a second Linear comment — the block belongs in **this** comment.
+
+   ```markdown
+   ## Zużycie tokenów — etap /push
+
+   | Metryka        | Wartość        |
+   | -------------- | -------------- |
+   | Input          | <INPUT>        |
+   | Output         | <OUTPUT>       |
+   | Cache creation | <CACHE_CREATE> |
+   | Cache read     | <CACHE_READ>   |
+   | **Łącznie**    | **<TOTAL>**    |
+   ```
+
+4. Create summary comment on parent task (in Polish):
+
+```markdown
+## Podsumowanie Implementacji
+
+### Zrealizowane Podzadania
+
+| Podzadanie | Tytul   | Status       |
+| ---------- | ------- | ------------ |
+| FRA-549    | [title] | Zrealizowane |
+| FRA-550    | [title] | Zrealizowane |
+
+### Niezrealizowane Podzadania
+
+| Podzadanie | Tytul   | Powod    |
+| ---------- | ------- | -------- |
+| FRA-551    | [title] | [reason] |
+
+### Commity
+
+| Commit  | Opis                        |
+| ------- | --------------------------- |
+| abc1234 | feat(gallery): add lightbox |
+
+### Status
+
+Task przeniesiony do "In Review".
+
+---
+
+_Raport wygenerowany przez Claude Code_
+```
+
+### Step 7: Push to Remote
+
+```bash
+git push
+```
+
+### Step 8: Branch-Specific Actions
+
+#### Feature Branch → Check/Create PR
+
+If on a feature branch (not `development` or `main`):
+
+1. Check if PR exists:
+
+   ```bash
+   gh pr list --head <branch-name> --base development --json number,title,state,url
+   ```
+
+2. If no PR, ask user:
+
+   ```markdown
+   ## Create Pull Request?
+
+   Branch `<branch-name>` has no open PR to `development`.
+   Do you want to create one?
+   ```
+
+3. If confirmed, create PR:
+   ```bash
+   gh pr create --base development --head <branch-name> --title "<Linear-ID>: <Task Title>" --body "..."
+   ```
+
+#### Development/Main Branch
+
+Just push and show confirmation.
+
+### Step 9: Final Confirmation
+
+```markdown
+## Gotowe
+
+Linear task [linearTaskId] przeniesiony do "In Review"
+Zmiany wyslane do `origin/<branch-name>`
+```
+
+## Error Handling
+
+### Push Rejected
+
+```markdown
+## Push Failed
+
+Updates were rejected. Options:
+
+1. `git pull --rebase` then push again
+2. `git pull` and merge
+```
+
+### No Commits to Push
+
+```markdown
+## Nothing to Push
+
+Branch is up to date with remote.
+```
+
+## Guidelines
+
+1. **Write all Linear comments in Polish**
+2. **Always confirm before status change**
+3. **Update Linear BEFORE push**
+4. **Document incomplete subtasks with reasons**
+5. **Offer PR creation on feature branches**
+6. **Do NOT monitor CI/CD pipelines**
+7. **Do NOT verify deployment**

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

@@ -0,0 +1,143 @@
+# Flow-Legacy Plugin for Claude Code
+
+Development flow skills for **legacy Angular 14 projects** with Linear-driven workflow.
+
+## Target Projects
+
+This plugin is designed for older standalone Angular projects using:
+
+- **Angular 14.x** (not Angular 20+)
+- **Nx 14.x** with `@nrwl/*` packages
+- **NgRx 14.x**
+- **Node.js 18** (not 24)
+
+### Legacy Patterns (what this plugin supports)
+
+| Feature | Legacy (Angular 14) | Modern (Angular 20+) |
+|---------|---------------------|----------------------|
+| Control flow | `*ngIf`, `*ngFor` | `@if`, `@for` |
+| Dependency injection | Constructor injection | `inject()` |
+| Inputs/Outputs | `@Input()`, `@Output()` | `input()`, `output()` |
+| State management | BehaviorSubject, Observable | Signals |
+| Components | NgModules | Standalone |
+| Nx packages | `@nrwl/*` | `@nx/*` |
+
+## Workflow Skills
+
+| 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 |
+| `/push` | Push changes and update Linear status |
+
+## Installation
+
+### 1. Enable plugin in project's `.claude/settings.json`:
+
+```json
+{
+  "enabledPlugins": {
+    "flow-legacy@smart-pro": true
+  }
+}
+```
+
+### 2. Merge permissions from template
+
+Run the merge script:
+
+```bash
+node node_modules/@smartsoft001/pro-claude-plugins/plugins/flow-legacy/.claude-plugin/merge-permissions.js
+```
+
+Or manually copy permissions from `settings.template.json` to your project's `.claude/settings.json`.
+
+## Required MCP Servers
+
+Configure these in your `.mcp.json`:
+
+- `linear` - Linear API integration (MCP prefix `mcp__linear__`)
+- `playwright` - Browser automation for screenshots
+
+## Permission Strategy
+
+### Automatic (allow)
+- Git read operations (status, diff, log, show)
+- Nx commands (test, lint, build)
+- Linear API (read/write issues, comments)
+- Playwright (screenshots)
+- Utility skills
+
+### Requires Confirmation (ask)
+- Workflow skills (/commit, /impl, /plan, /push)
+- `git commit` - creating commits
+- `git push` - pushing to remote
+- `gh pr create` - creating pull requests
+
+## Utility Skills
+
+| Skill | Description |
+|-------|-------------|
+| `maia-files-upload` | Upload files to Maia API |
+| `maia-files-delete` | Delete files from Maia API |
+| `browser-capture` | Capture screenshots with Playwright |
+| `linear-suggestion` | Create Linear issues for improvements |
+| `test-unit` | Run unit tests with coverage |
+| `a11y-audit` | Accessibility audit |
+
+## Agents
+
+See `agents/` directory for specialized agents adapted for Angular 14 patterns:
+
+### Angular Agents (Legacy patterns)
+- `angular-component-scaffolder` - Components with NgModules, `*ngIf`/`*ngFor`, constructor DI
+- `angular-service-builder` - Services with BehaviorSubject, constructor DI
+- `angular-state-builder` - State management with BehaviorSubject/Observable patterns
+- `angular-directive-builder` - Directives with constructor DI
+- `angular-pipe-builder` - Pipes with legacy patterns
+- `angular-guard-builder` - Guards with constructor DI
+- `angular-resolver-builder` - Resolvers with constructor DI
+
+### Shared Agents
+- `shared-tdd-developer` - TDD workflow
+- `shared-impl-orchestrator` - Implementation orchestration
+- `shared-impl-reporter` - Implementation reporting
+- `shared-linear-subtask-iterator` - Linear subtask iteration
+- `shared-verification-orchestrator` - Verification pipeline
+- And more...
+
+## Differences from `flow` plugin
+
+| Aspect | `flow` (modern) | `flow-legacy` |
+|--------|-----------------|---------------|
+| Angular version | 20+ | 14 |
+| Node.js version | 24 | 18 |
+| Component syntax | Standalone, signals | NgModules, *ngIf/*ngFor |
+| DI pattern | `inject()` | Constructor injection |
+| Nx packages | `@nx/*` | `@nrwl/*` |
+| State | Signals | BehaviorSubject/Observable |
+
+## Example Project Structure
+
+```
+libs/
+  shared/
+    angular/
+      src/
+        lib/
+          components/
+          services/
+          pipes/
+          directives/
+  museum-articles/
+    shell/
+      angular/
+  museum-objects/
+    shell/
+      angular/
+apps/
+  web/
+    src/
+      app/
+```