@smartsoft001/pro-claude-plugins 0.2.0

package/plugins/flow-legacy/skills/browser-capture/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: browser-capture
+description: Manage browser sessions and capture screenshots. Ensures dev server is running, navigates to pages, captures responsive screenshots, and uploads them to temporary storage.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - mcp__playwright__browser_navigate
+  - mcp__playwright__browser_snapshot
+  - mcp__playwright__browser_take_screenshot
+  - mcp__playwright__browser_resize
+  - mcp__playwright__browser_close
+---
+
+# Browser Capture Skill
+
+Manage browser sessions for capturing screenshots of web pages. Automatically ensures the development server is running before capturing.
+
+## Capabilities
+
+1. **Server Management**: Check if dev server is running, start if needed
+2. **Page Navigation**: Navigate to specified URLs using Playwright
+3. **Screenshot Capture**: Take screenshots at multiple viewport sizes
+4. **Upload Screenshots**: Upload captured images to maia-api for use in reports
+
+## Server Management
+
+### Read Port Configuration
+
+```bash
+# Default port location (Nx 14 / Angular 14)
+grep -o '"port":[^,}]*' apps/web/project.json | head -1
+# Default: 4200
+```
+
+### Check if Server is Running
+
+```bash
+lsof -i :4200 -t
+```
+
+- If returns PID -> server is running
+- If returns nothing -> server needs to be started
+
+### Start Server if Needed
+
+```bash
+# Start in background (Nx 14 / @nrwl)
+npm start &
+
+# Wait for server to be ready (check every 2 seconds, max 30 seconds)
+for i in {1..15}; do
+  curl -s http://localhost:4200 > /dev/null && break
+  sleep 2
+done
+```
+
+## Screenshot Capture Process
+
+### 1. Ensure Server is Running
+
+Before any screenshot capture:
+
+1. Read port from `apps/web/project.json` (default: 4200)
+2. Check if port is occupied: `lsof -i :PORT -t`
+3. If not running: `npm start &` and wait ~15 seconds
+
+### 2. Navigate to Page
+
+Use `mcp__playwright__browser_navigate` to open the target URL.
+
+```
+URL format: http://localhost:{port}/{path}
+```
+
+### 3. Capture at Multiple Viewports
+
+Standard viewport sizes:
+
+| Name    | Width | Height |
+| ------- | ----- | ------ |
+| Desktop | 1920  | 1080   |
+| Tablet  | 768   | 1024   |
+| Mobile  | 375   | 667    |
+
+Process for each viewport:
+
+1. `mcp__playwright__browser_resize` -> set dimensions
+2. `mcp__playwright__browser_take_screenshot` -> save to temp file
+
+### 4. Upload Screenshots
+
+After capturing, delegate upload to `maia-api` agent:
+
+```
+Input: /tmp/screenshot-desktop.png
+Output: { id: "abc123", url: "https://maia-ai-api.smartsoft.biz.pl/files/abc123" }
+```
+
+## Usage Examples
+
+### Capture Single Page
+
+```
+Input: { path: "/articles", viewports: ["desktop", "mobile"] }
+
+Process:
+1. Check server running on port 4200
+2. Start if needed, wait for ready
+3. Navigate to http://localhost:4200/articles
+4. Resize to 1920x1080, screenshot -> /tmp/articles-desktop.png
+5. Resize to 375x667, screenshot -> /tmp/articles-mobile.png
+6. Upload both via maia-api agent
+7. Return URLs
+
+Output:
+{
+  "desktop": "https://maia-ai-api.smartsoft.biz.pl/files/abc123",
+  "mobile": "https://maia-ai-api.smartsoft.biz.pl/files/def456"
+}
+```
+
+### Capture Before/After
+
+```
+Input: {
+  path: "/profile",
+  phase: "before" | "after",
+  viewports: ["desktop", "mobile"]
+}
+
+Output:
+{
+  "phase": "before",
+  "desktop": { "id": "abc123", "url": "https://..." },
+  "mobile": { "id": "def456", "url": "https://..." }
+}
+```
+
+## Viewport Presets
+
+| Preset     | Dimensions | Use Case                 |
+| ---------- | ---------- | ------------------------ |
+| `desktop`  | 1920x1080  | Full desktop view        |
+| `laptop`   | 1366x768   | Common laptop resolution |
+| `tablet`   | 768x1024   | iPad portrait            |
+| `mobile`   | 375x667    | iPhone SE/8              |
+| `mobile-l` | 414x896    | iPhone XR/11             |
+
+## Server Ready Check
+
+```bash
+# Check if server responds
+check_server() {
+  local port=$1
+  local max_attempts=$2
+  local attempt=1
+
+  while [ $attempt -le $max_attempts ]; do
+    if curl -s "http://localhost:$port" > /dev/null 2>&1; then
+      echo "Server ready"
+      return 0
+    fi
+    echo "Waiting for server... ($attempt/$max_attempts)"
+    sleep 2
+    ((attempt++))
+  done
+
+  echo "Server not ready after $max_attempts attempts"
+  return 1
+}
+
+check_server 4200 15
+```
+
+## Output Format
+
+When capturing screenshots, return structured data:
+
+```json
+{
+  "serverStarted": true,
+  "port": 4200,
+  "screenshots": [
+    {
+      "viewport": "desktop",
+      "dimensions": "1920x1080",
+      "localPath": "/tmp/screenshot-desktop.png",
+      "uploadedId": "abc123",
+      "uploadedUrl": "https://maia-ai-api.smartsoft.biz.pl/files/abc123"
+    },
+    {
+      "viewport": "mobile",
+      "dimensions": "375x667",
+      "localPath": "/tmp/screenshot-mobile.png",
+      "uploadedId": "def456",
+      "uploadedUrl": "https://maia-ai-api.smartsoft.biz.pl/files/def456"
+    }
+  ]
+}
+```
+
+## Cleanup
+
+After screenshots are used (embedded in Linear comments), cleanup local temp files:
+
+```bash
+rm /tmp/screenshot-*.png
+```
+
+For API cleanup, delegate to `maia-api` agent with collected IDs.
+
+## Error Handling
+
+### Server Won't Start
+
+If server fails to start after 30 seconds:
+
+1. Check for port conflicts: `lsof -i :4200`
+2. Check npm logs for errors
+3. Report error and skip screenshot capture
+
+### Screenshot Fails
+
+If Playwright screenshot fails:
+
+1. Verify navigation succeeded
+2. Check for JavaScript errors: `mcp__playwright__browser_console_messages`
+3. Try alternative viewport
+4. Report partial success
+
+### Upload Fails
+
+If maia-api upload fails:
+
+1. Verify file exists and has content
+2. Retry upload once
+3. Report error with local file path as fallback

package/plugins/flow-legacy/skills/commit/SKILL.md

@@ -0,0 +1,215 @@
+---
+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
+  - TaskCreate
+  - TaskUpdate
+  - TaskList
+  - TaskGet
+  - mcp__linear__get_issue
+  - mcp__linear__list_comments
+---
+
+# Commit Skill
+
+Create a conventional commit message based on Linear task and staged changes.
+
+## Usage
+
+```
+/commit [linearTaskId]
+```
+
+## Parameters
+
+- `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
+
+### Task Progress Tracking
+
+**MANDATORY**: Use Claude Code's built-in task tracking to provide real-time progress visibility.
+
+**Task naming convention**: Every task subject MUST be prefixed with the Linear task ID:
+
+```
+<linearTaskId> <step description>
+```
+
+**At skill start**: Create tasks for each checklist step using `TaskCreate`:
+
+```
+TaskCreate({
+  subject: "MM-123 Fetch Linear task",
+  description: "Get title, description, labels/type from MCP Linear server",
+  activeForm: "MM-123 Fetching Linear task"
+})
+TaskCreate({
+  subject: "MM-123 Analyze staged changes",
+  description: "Run git diff --cached to understand scope",
+  activeForm: "MM-123 Analyzing staged changes"
+})
+```
+
+**During execution**:
+
+- Before starting a step → `TaskUpdate({ taskId, status: "in_progress" })`
+- After completing a step → `TaskUpdate({ taskId, status: "completed" })`
+
+**At checkpoints**: Use `TaskList` to review overall progress before presenting status to user.
+
+## Instructions
+
+You are tasked with creating a git commit based on a Linear task and staged changes.
+
+### Step 1: Fetch Linear Task Details
+
+Use the MCP Linear server to fetch task details for the provided `linearTaskId`. Extract:
+
+- Task title
+- Task description
+- Task labels/type (bug, feature, improve etc.)
+
+### Step 2: Analyze Staged Changes
+
+Run `git diff --cached` to see what files have been changed and understand the scope of changes.
+
+### Step 2.5: Verify Implementation Completeness
+
+Before proceeding with the commit, verify that all requirements from the Linear task have been implemented:
+
+1. **Compare task requirements with actual changes**:
+
+   - Review the Linear task description and acceptance criteria
+   - Analyze the staged changes from `git diff --cached`
+   - Identify any requirements from the task that are not reflected in the code changes
+
+2. **Ask user if implementation is incomplete**:
+
+   - If any task requirements appear to be missing from the staged changes, use `AskUserQuestion` to ask the user:
+     - Option 1: "Continue with commit" (Proceed with committing only the current changes)
+     - Option 2: "Complete implementation first" (Recommended) - Stop the commit process so user can implement missing requirements
+
+3. **Handle user decision**:
+   - If user chooses "Continue with commit": Proceed to Step 3
+   - If user chooses "Complete implementation first": Stop the commit process and inform the user about what's missing
+
+**Note**: This verification step helps ensure commits are complete and aligned with task requirements, reducing the need for follow-up commits.
+
+### Step 3: Read Commitlint Configuration
+
+Read the `commitlint.config.js` file to understand:
+
+- Available scopes (from the `scope-enum` rule)
+- Commit message format requirements
+
+### Step 4: Generate Commit Message
+
+Based on the Linear task details and code changes, generate a commit message following conventional commits format:
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+Refs: <linearTaskId>
+```
+
+Where:
+
+- **type**: Choose from: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `build`, `ci`, `perf`, `style`
+  - Use task labels/type to determine (bug → fix, feature → feat, etc.)
+- **scope**: Select from available scopes in commitlint.config.js based on changed files
+  - If multiple scopes affected, choose the primary one or use a general scope
+  - The scope must be one of the valid scopes from commitlint config
+- **subject**: Brief description (use Linear task title as base, keep under 72 chars)
+- **body**: Optional detailed explanation if needed (from task description or complex changes)
+- **footer**: Always include `Refs: <linearTaskId>` to link to Linear task
+
+### Step 4.5: Pre-commit Preparation (Mandatory)
+
+Before creating the commit, **always** run the following commands:
+
+1. **Switch to Node.js 18** (legacy projects use Node 18):
+
+   ```bash
+   source ~/.nvm/nvm.sh && nvm use 18
+   ```
+
+### Step 5: Create Commit
+
+Execute the commit with the generated message:
+
+```bash
+git commit -m "<type>(<scope>): <subject>" -m "<body>" -m "Refs: <linearTaskId>"
+```
+
+### Step 6: Post-Commit Parallelization Analysis (Optional)
+
+After the commit is created, perform an optional parallelization analysis:
+
+1. **Fetch Linear comments** for the task using the MCP Linear server
+2. **Search for `🎭 Agent Orchestration Plan` blocks** in the comments
+3. **If found**: Delegate analysis to `shared-parallelization-analyzer` agent:
+
+   ```
+   Analyze orchestration plan for parallelization opportunities:
+   - Linear Task ID: [linearTaskId]
+   - Orchestration Plan: [the 🎭 Agent Orchestration Plan block content]
+   ```
+
+   The agent will:
+
+   - Parse the orchestration plan (agents table, execution flow, TDD cycles)
+   - Build a dependency graph from file I/O analysis
+   - Identify false sequential dependencies and parallelization opportunities
+   - Generate a console report with current vs proposed execution
+
+4. **If not found**: Skip silently — no message needed (common for hotfixes, config-only commits)
+
+**IMPORTANT**:
+
+- This step is **non-blocking** and **advisory only**
+- The analysis report is shown to the user in the console but is NOT auto-applied
+- Recurring orchestrator improvement suggestions (if any) are filed as Linear issues in the "Framework 2.0" project via `linear-suggestion` skill — no user interaction required
+- A commit failure or missing orchestration plan should never cause this step to error
+
+### Guidelines
+
+1. Keep the subject line concise and imperative mood
+2. Choose the most appropriate type based on task nature and code changes
+3. Select scope based on the primary area of code changes
+4. If task type is unclear, analyze the code changes to determine type
+5. Always include the Linear task reference in the footer
+6. If there are no staged changes, warn the user and don't create commit
+7. After a successful commit, run the optional parallelization analysis (Step 6) to surface optimization opportunities from the orchestration plan. Recurring patterns are filed as Linear issues automatically via `linear-suggestion` skill
+
+### Example
+
+For Linear task "ENG-123: Add dark mode toggle to settings":
+
+- Type: `feat` (new feature)
+- Scope: `shared-angular` (if changes are in libs/shared/angular)
+- Subject: "add dark mode toggle to settings"
+- Result: `feat(shared-angular): add dark mode toggle to settings`
+
+---
+
+**Important**: Before committing, show the generated commit message to the user for approval.