@smartsoft001/pro-claude-plugins 0.10.0 → 0.12.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@smartsoft001/pro-claude-plugins",
-  "version": "0.10.0",
+  "version": "0.12.0",
   "publishConfig": {
     "access": "public"
   },

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

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

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

@@ -23,6 +23,8 @@ Execute test suites and provide clear reporting of results.
 
 ### Unit Tests
 
+Every command below runs through `2>&1 | tail -80`; on failure re-run the single failing command through `2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120` (see `nx-conventions` §3a). The examples omit the suffix for readability.
+
 ```bash
 # Run tests for specific project
 nx test web

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

@@ -12,6 +12,8 @@ You are the verification orchestrator responsible for running the complete verif
 
 Coordinate all verification stages to ensure code quality before completion.
 
+Output discipline: every `nx` command runs through `2>&1 | tail -80`; on failure re-run that one command through `2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120`. Never paste a full log into the conversation (see `nx-conventions` §3a).
+
 ## When to Use
 
 - After completing implementation
@@ -27,8 +29,8 @@ Run style and security checks in parallel for quick feedback.
 
 ```bash
 # Style enforcement (linting + type-check)
-nx lint web &
-nx lint shared-angular &
+nx lint web 2>&1 | tail -80 &
+nx lint shared-angular 2>&1 | tail -80 &
 
 # Security scanning
 npm audit --audit-level=moderate &
@@ -44,8 +46,8 @@ Run unit tests with coverage verification.
 
 ```bash
 # Run tests with coverage
-nx test web --coverage --coverageReporters=text-summary
-nx test shared-angular --coverage --coverageReporters=text-summary
+nx test web --coverage --coverageReporters=text-summary 2>&1 | tail -80
+nx test shared-angular --coverage --coverageReporters=text-summary 2>&1 | tail -80
 ```
 
 **Pass criteria**: All tests pass, coverage >= 80%.
@@ -56,7 +58,9 @@ Verify production build succeeds.
 
 ```bash
 # Production build
-nx build web --configuration=production
+nx build web --configuration=production 2>&1 | tail -80
+# on failure, errors only:
+# nx build web --configuration=production 2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120
 ```
 
 **Pass criteria**: Build completes without errors.
@@ -188,7 +192,7 @@ For quick pre-commit verification, run stages 1-3 only:
 
 ```bash
 # Quick verification script
-nx lint web && \
-nx test web --coverage && \
-nx build web
+nx lint web 2>&1 | tail -80 && \
+nx test web --coverage 2>&1 | tail -80 && \
+nx build web 2>&1 | tail -80
 ```

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

@@ -23,11 +23,27 @@ Create a conventional commit message based on Linear task and staged changes.
 
 ```
 /commit [linearTaskId]
+/commit [linearTaskId] --auto    # Non-interactive mode for fully autonomous runs
 ```
 
 ## Parameters
 
 - `linearTaskId` - Linear task ID (e.g., ENG-123)
+- `--auto` - Non-interactive mode: skip ALL `AskUserQuestion` prompts and the message-approval step. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent.
+
+## Auto Mode (`--auto`)
+
+**When `--auto` is set, the skill MUST run end-to-end without any human-in-the-loop prompts.** Apply these overrides:
+
+| Default behavior                                                       | `--auto` override                                                                                                                                                                                                             |
+| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Analyze only staged changes; if nothing staged, warn and don't commit  | If nothing is staged but the working tree has task-related modifications, STAGE THEM AUTOMATICALLY (`git add -A`, excluding obvious non-source artifacts — loose `*.png` in the repo root, `.playwright-mcp/`, `docs/mockups/`, `.benchmark-test/`, `.claude/settings.json`) and continue. Never ask "would you like me to stage" |
+| Completeness prompt (Step 2.5 `AskUserQuestion`)                       | Skip the prompt; commit the current changes and note any suspected gaps in the commit body                                                                                                                                     |
+| Show message to user for approval before committing                    | Skip the approval; create the commit immediately with the generated message                                                                                                                                                   |
+| Any other `AskUserQuestion`                                            | Use the option marked **(Recommended)**; if none, pick the safest option and continue                                                                                                                                          |
+| Nothing to commit at all                                               | If an existing commit already references this task (e.g. `/impl` committed the work itself), exit cleanly with a one-line statement naming that commit. Otherwise exit cleanly stating there was nothing to commit. No question either way |
+
+**Hard requirement in `--auto`**: the run MUST end in exactly one of two states — a created commit, or an explicit one-line clean-exit statement that nothing needed committing. Ending the run with a question is a skill failure (in one-shot `--print` execution nobody can answer, the commit is silently lost, and the caller has to fall back to an emergency commit).
 
 ## Execution Checklist
 
@@ -35,10 +51,10 @@ 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
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop (in `--auto`: no prompt — continue and note gaps in the body)
 - [ ] **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
+- [ ] **6. Show message to user** — present commit message for approval before proceeding (skipped in `--auto`: commit immediately)
 - [ ] **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
@@ -208,7 +224,7 @@ After the commit is created, perform an optional parallelization analysis:
 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
+6. If there are no staged changes, warn the user and don't create commit (default mode only; in `--auto` stage task-related working-tree changes automatically per Auto Mode and proceed)
 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
@@ -256,4 +272,4 @@ If no orchestration plan is found in Linear comments, this step is silently skip
 
 ---
 
-**Important**: Before committing, show the generated commit message to the user for approval.
+**Important**: Before committing, show the generated commit message to the user for approval. In `--auto` mode skip the approval entirely — commit immediately and never end the run with a question (see Auto Mode).

package/plugins/flow/skills/impl/SKILL.md

@@ -41,6 +41,14 @@ These rules override ANY other instruction, ANY surrounding example, and ANY def
 
 4. **Replace, don't duplicate.** Before creating a new `orchestration.md` attachment, delete the existing one (if any) via `mcp__linear__delete_attachment`. Same for re-running `/plan` (handled by `/plan` skill).
 
+5. **Read files with `Read`, never with `cat` / `head` / `tail` in Bash.** `Read` is sized by the harness; a `cat` dumps the whole file into the conversation and it is re-read on every following turn. Compound `cd … && cat a; cat b` is doubly forbidden. The only Bash reads allowed are `tail -30` on a dev-server log under `/tmp`.
+
+6. **Every `nx` command ends with `2>&1 | tail -80`.** `nx` prints its summary last, so 80 lines cover a passing run. On a non-zero exit run the SAME command once more through `2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120` — errors in full, everything else cut. Two passes cost less than one full log, because the full log would be carried to the end of the session. Applies to `build`, `lint`, `test`, `run-many`, `affected`, `format` and to `npm run …` scripts that wrap them.
+
+7. **The Linear issue is fetched once per session** into `.ai/tasks/<issue>/issue.md` (see Step 1-2). Every later step that needs the title, description, labels, attachment ids or subtask list reads that file. Do not call `mcp__linear__get_issue` again unless the file is missing.
+
+8. **Each mockup export is read at most twice per session**: once when first needed (write `.ai/tasks/<issue>/mockup-notes.md` right after — layout order, grid and spacing, colours as token names, typography, field order on card and list item, states, header and footer elements) and once in the Step 3e-mockup comparison. Every other reference to the mockup is a read of the note, not of the image. A `Read` of a `.png`/`.jpg` costs ~2.5k tokens that are re-read on every following turn; batch P read the same file four times in one session.
+
 If any of these would be violated, stop and ask the user instead.
 
 ## Execution Checklist
@@ -49,25 +57,25 @@ 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
+- [ ] **1. Fetch task and subtasks ONCE** — delegate to `shared-linear-subtask-iterator` agent; write the result to `.ai/tasks/<issue>/issue.md` (title, description, labels, state, `attachments[]` with ids and titles, subtasks with ids and states). Every later step reads this file (Hard Rule #7).
 
 ### 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** — `mcp__linear__get_issue` to find `plan.md` attachment id, then `mcp__linear__get_attachment({ id })` to read content. **Do NOT use `WebFetch`/`curl` on the attachment URL.**
+- [ ] **2. Set status to "In Progress"** — update subtask status via MCP (subtasks only, not parent). This and step 14 are the ONLY two status writes per subtask.
+- [ ] **3. Fetch implementation plan** — take the `plan.md` attachment id from `.ai/tasks/<issue>/issue.md`, then `mcp__linear__get_attachment({ id })` once and save the content to `.ai/tasks/<issue>/plan.md`; read the file from then on. **Do NOT use `WebFetch`/`curl` on the attachment URL.**
 - [ ] **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`, save result as `orchestration.md` attachment via `mcp__linear__create_attachment` (replace any existing one). **Calling `mcp__linear__save_comment` with the orchestration body is FORBIDDEN.**
+- [ ] **5. MANDATORY: Agent orchestration plan** — delegate to `shared-impl-orchestrator`, write result to `.ai/tasks/<issue>/orchestration.md`. Upload it as the `orchestration.md` attachment via `mcp__linear__create_attachment` ONCE, in step 12 together with the completion comment (replace any existing one). **Calling `mcp__linear__save_comment` with the orchestration body is FORBIDDEN.**
 - [ ] **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 (skip pause in `--auto`, log checkpoint as Linear comment instead), use `shared-tdd-developer` for ALL code (RED → GREEN → REFACTOR)
+- [ ] **8. MANDATORY: Implement with 3x3 rule** — pause every 3 changes (in `--auto`: append the checkpoint to `.ai/tasks/<issue>/checkpoints.md` and continue; the file is posted to Linear as ONE comment in step 12), use `shared-tdd-developer` for ALL code (RED → GREEN → REFACTOR)
 - [ ] **9. Verify implementation** — run tests, lint, build check
 - [ ] **9.5. E2E tests (conditional)** — if `E2E_TESTS_RECOMMENDED: YES`, delegate to `test-e2e` skill
 - [ ] **10. Capture "after" screenshots** — if `UI_CHANGE_REQUIRED: YES`, capture + post comparison to Linear + cleanup
 - [ ] **10.5. Mockup fidelity check (conditional)** — if `UI_CHANGE_REQUIRED: YES` and `docs/mockups/` exists, compare the changed page against its mockup export and fix divergences (max 2 fix-and-recheck iterations) before the screenshot verification checkpoint (11); after any fix, re-run tests/lint/build on the touched projects
 - [ ] **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
+- [ ] **12. Create completion comment** — delegate to `shared-impl-reporter`, post to Linear as ONE comment; in `--auto` append the full content of `.ai/tasks/<issue>/checkpoints.md` under a `## Checkpointy` heading. Upload `orchestration.md` (step 5) in the same step.
 - [ ] **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
+- [ ] **14. Update status** — delegate to `shared-linear-subtask-iterator` for status determination; the second and last status write of this subtask
 - [ ] **15. Agent evolution** — if user confirmed feedback, delegate to `shared-agent-evolver`
 - [ ] **16. Pause for user confirmation** — wait before proceeding to next subtask (skipped in `--auto`; post completion comment and continue)
 
@@ -168,13 +176,13 @@ You implement code that is:
 | Default behavior                                         | `--auto` override                                                                                         |
 | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
 | Post comment "no plan.md found, run /plan first" + skip  | Inline-invoke `/plan` flow for the task to generate `plan.md` attachment + `AI Plan` label, then continue |
-| 3x3 rule pauses every 3 changes asking "Continue?"       | Log the checkpoint summary as a status comment, then continue automatically                               |
+| 3x3 rule pauses every 3 changes asking "Continue?"       | Append the checkpoint summary to `.ai/tasks/<issue>/checkpoints.md`, then continue automatically          |
 | Pause after each subtask waiting for user confirmation   | Post subtask completion comment, then proceed to next subtask                                             |
 | Final end pause "wait for user confirmation"             | Post final summary comment and exit cleanly                                                               |
 | `AskUserQuestion` for any decision                       | Use the option marked **(Recommended)**; if none, fail fast with a Linear comment explaining why          |
 | Confirmation before destructive ops (delete attachments) | Proceed without confirmation — replace old `orchestration.md` automatically                               |
 
-**Hard requirement in `--auto`**: every checkpoint, decision, or skip MUST be logged as a Linear comment in Polish so the run remains auditable after the fact. Comments replace the interactive prompts — they are the audit trail.
+**Hard requirement in `--auto`**: every checkpoint, decision, or skip MUST be logged in Polish so the run remains auditable after the fact. Checkpoints and decisions go to `.ai/tasks/<issue>/checkpoints.md` and reach Linear as ONE comment with the completion report (Step 3f). Two things are still posted immediately, because they are signals, not a diary: a **blocker** (Step 3c) and an **unexpected error** (Pause Points table). The audit trail is identical — it is sent once instead of thirty-five times.
 
 **Detection**: The flag `--auto` is provided as a positional/named arg. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent. Combinable with `--team` (parallel squad mode runs without per-subtask approval).
 
@@ -199,6 +207,33 @@ The agent will:
 
 **Output:** Task structure with subtasks to process (or parent task if no subtasks)
 
+**Persist the result (Hard Rule #7).** Write `.ai/tasks/<issue>/issue.md` (create the directory; it is gitignored like `plan.md`):
+
+```markdown
+# <IDENTIFIER> — <title>
+
+- state: <state name>
+- labels: <comma-separated>
+- assignee: <name or —>
+
+## Description
+
+<description verbatim>
+
+## Attachments
+
+| id | title |
+|----|-------|
+| <attachment id> | plan.md |
+
+## Subtasks
+
+| id | identifier | title | state |
+|----|------------|-------|-------|
+```
+
+From here on, whenever a step says "find the attachment id", "check the status", "read the description" or "list subtasks", it means: read this file. `mcp__linear__get_issue` is called again ONLY if the file is missing or a step explicitly requires fresh data from Linear (none in this skill does).
+
 ### Step 1b: Team Mode Decision (if --team flag provided)
 
 **Prerequisites**:
@@ -308,14 +343,16 @@ For each task to implement (subtasks in "To Do" status, or parent task if no sub
 
 Do NOT change status for parent tasks.
 
+This is the first of exactly two status writes per subtask; the second is Step 3g. No status writes in between.
+
 #### Step 3b: Fetch Implementation Plan from `plan.md` Attachment
 
 **⛔ DO NOT use `WebFetch` or `Bash(curl)` on the attachment URL. Use `mcp__linear__get_attachment({ id })` only.** Re-read Hard Rule #1 if tempted.
 
 Two-step retrieval:
 
-1. `mcp__linear__get_issue({ id: taskId })` → response includes `attachments[]`. Find the entry where `title == "plan.md"` (or `filename == "plan.md"`) and capture its `id`. Do NOT use the `url` field for fetching.
-2. `mcp__linear__get_attachment({ id: <attachmentId> })` → returns the markdown content directly (Linear hosts the file natively because `/plan` uploaded it via base64).
+1. Take the `plan.md` attachment `id` from the **Attachments** table in `.ai/tasks/<issue>/issue.md` (Hard Rule #7 — no second `get_issue`). Do NOT use any `url` field for fetching.
+2. `mcp__linear__get_attachment({ id: <attachmentId> })` **once** → returns the markdown content directly (Linear hosts the file natively because `/plan` uploaded it via base64). Save it verbatim to `.ai/tasks/<issue>/plan.md` and read the file from now on — the attachment is not fetched a second time in this session.
 
 Parse the markdown for:
 
@@ -486,10 +523,10 @@ This ensures:
 
 Use tools:
 
-- `Read` to read existing files
+- `Read` to read existing files (Hard Rule #5 — never `cat` in Bash)
 - `Edit` to modify files
 - `Write` to create new files
-- `Bash` to run tests and commands
+- `Bash` to run tests and commands — every `nx` call through `2>&1 | tail -80` (Hard Rule #6)
 - `Glob` and `Grep` for additional exploration if needed
 
 **3x3 Checkpoint Format:**
@@ -517,6 +554,8 @@ Use tools:
 Continue? (yes/no/adjust)
 ```
 
+**In `--auto`**: do not post the checkpoint. Append it to `.ai/tasks/<issue>/checkpoints.md` (create on first use, one `## Checkpoint N — <time>` section per checkpoint, in Polish) and continue. The whole file is posted with the completion comment in Step 3f. Exceptions that ARE posted immediately: a blocker (Step 3c) and an unexpected error (Pause Points table).
+
 **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.
@@ -547,10 +586,11 @@ Look for signals like: universal language ("always", "never"), pattern-level cor
 
 After implementing:
 
-1. **Run relevant tests**: Execute tests mentioned in the Testing Strategy
-2. **Run linting**: `nx lint` for affected projects
-3. **Build check**: Verify build doesn't break
-4. **Manual verification**: Check if implementation matches requirements
+1. **Run relevant tests**: `nx test <project> 2>&1 | tail -80` for the projects named in the Testing Strategy
+2. **Run linting**: `nx lint <project> 2>&1 | tail -80` for affected projects
+3. **Build check**: `nx build web 2>&1 | tail -80`
+4. **On any non-zero exit**: re-run that one command through `2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120`, fix, repeat the single step — never paste a full log (Hard Rule #6)
+5. **Manual verification**: Check if implementation matches requirements
 
 #### Step 3e-e2e: E2E Tests (Conditional on E2E_TESTS_RECOMMENDED)
 
@@ -665,10 +705,7 @@ is still loaded, instead of leaving it to post-hoc review.
    `-kontrast` exports are out of scope for this loop unless the subtask
    changed contrast/dark-mode styling — the high-contrast mode is owned by
    the shared WCAG widget and dedicated a11y checks.
-3. **Read both images side by side** and list every divergence in: section
-   layout, component structure (thumbnail / metadata / action-button
-   arrangement), brand palette and tokens, typography, ornaments and
-   decorative assets, raw translation keys visible on screen.
+3. **Read both images side by side — once.** If `.ai/tasks/<issue>/mockup-notes.md` already describes this export (written when the mockup was first read during styling), read the note plus the local screenshot instead of re-reading the export; read the export image only if the note is missing (Hard Rule #8). List every divergence in: section layout, component structure (thumbnail / metadata / action-button arrangement), brand palette and tokens, typography, ornaments and decorative assets, raw translation keys visible on screen.
 4. **Judge structure over theme, and scope to THIS subtask.** Component
    exports may come from a shared, multi-project design system: the project's
    own palette and typography win over the sample's theme. Ignore content
@@ -678,8 +715,7 @@ is still loaded, instead of leaving it to post-hoc review.
    check the README's notes. A divergence caused by a page or module that a
    DIFFERENT subtask owns (e.g. a section not implemented yet) is out of
    scope: note it for the completion comment, do not fix it here.
-5. **Fix real divergences NOW**, re-capture, re-compare. **Hard bound: at most
-   2 fix-and-recheck iterations.** Whatever still diverges after the second
+5. **Fix real divergences NOW**, re-capture, re-compare **against the note and the divergence list from item 3 — do not read the mockup export again** (Hard Rule #8); each iteration reads only the NEW local screenshot, once. **Hard bound: at most 2 fix-and-recheck iterations.** Whatever still diverges after the second
    pass goes into the completion comment as an explicit list — do not keep
    looping; structural and brand fidelity is the bar, pixel-perfection is not.
    Fixes are code changes: after the loop, re-run the Step 3e verification
@@ -755,7 +791,7 @@ Blocker Info: [if blocked]
 
 The agent will generate a formatted Implementation Report and return it.
 
-**Post the report** as a comment on the Linear task/subtask.
+**Post the report** as ONE comment on the Linear task/subtask. In `--auto`, append the content of `.ai/tasks/<issue>/checkpoints.md` under a `## Checkpointy` heading at the end of the same comment — one `save_comment` call, not one per checkpoint. In the same step upload `.ai/tasks/<issue>/orchestration.md` as the `orchestration.md` attachment (Hard Rule #2 and #4: `create_attachment`, replacing any existing one) — this is the single upload of the orchestration plan for this subtask.
 
 #### Step 3g: Update Status
 
@@ -772,6 +808,8 @@ The agent will determine the correct status and provide MCP command to execute.
 
 **Execute the status update** via MCP Linear server.
 
+This is the second and last status write for this subtask (the first was Step 3a).
+
 #### Step 3g-evolve: Agent Evolution Checkpoint
 
 **Prerequisites**: Only execute this step if user confirmed at least one feedback item with "Yes" during 3x3 checkpoints.

package/plugins/flow/skills/nx-conventions/SKILL.md

@@ -97,6 +97,24 @@ nx affected --target=build
 nx graph
 ```
 
+## 3a. Output discipline
+
+Every `nx` invocation in an agent session ends with `2>&1 | tail -80`. `nx`
+prints its summary last, so 80 lines cover a passing run; a full build log
+(often 400+ lines) would be re-read on every following turn of the session.
+
+On a non-zero exit, run the SAME command once more, errors only:
+
+```bash
+nx build web 2>&1 | tail -80
+# exit != 0 →
+nx build web 2>&1 | grep -iE 'error|ERR!|✖|FAIL' -B2 -A5 | head -120
+```
+
+Two passes cost less than one full log. Applies to `build`, `lint`, `test`,
+`run-many`, `affected`, `format`, and to `npm run …` scripts wrapping them.
+Read files with `Read`, never with `cat` in Bash.
+
 ## 4. Affected Commands
 
 Run tasks only on changed projects:

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

@@ -41,6 +41,10 @@ These rules override ANY other instruction, ANY surrounding example, and ANY def
 
 5. **Plain `--auto` NEVER asks and NEVER mutates issue structure.** In `--auto` without `--post-questions` (the benchmark path), the Question Gate posts no questions, no status or assignee is changed, and no subtasks are created — ambiguities become assumptions logged in the audit comment, and `plan.md` is ALWAYS produced. The benchmark runner depends on this contract; breaking it silently corrupts measurement.
 
+5. **Fetch each issue once.** Step 1 writes `.ai/tasks/<issue>/issue.md` (title, description, labels, state, `attachments[]` with ids and titles, subtasks) and every later step reads that file. `mcp__linear__get_issue` is not called again for the same issue in this session; `list_comments` is called once per issue (Step 3) and its result is appended to the same file under `## Comments`.
+
+6. **Read files with `Read`, never with `cat` / `head` / `tail` in Bash**, and end every `nx` command with `2>&1 | tail -80`. Codebase exploration in Step 6 is `Glob`, `Grep` and `Read` — a `cat` dumps the whole file into the conversation and it is re-read on every following turn.
+
 If any of these would be violated, stop and ask the user instead.
 
 ## Execution Checklist
@@ -168,6 +172,38 @@ Use the MCP Linear server to fetch task details for the provided `linearTaskId`.
 - Task priority
 - Task estimate (if available)
 
+**Persist it (Hard Rule #5).** Write `.ai/tasks/<issue>/issue.md` (create the directory; gitignored like `plan.md`):
+
+```markdown
+# <IDENTIFIER> — <title>
+
+- state: <state name>
+- labels: <comma-separated>
+- priority: <n>
+- estimate: <n or —>
+
+## Description
+
+<description verbatim>
+
+## Attachments
+
+| id | title |
+|----|-------|
+
+## Subtasks
+
+| id | identifier | title | state |
+|----|------------|-------|-------|
+
+## Comments
+
+| id | createdAt | body (first line) |
+|----|-----------|-------------------|
+```
+
+Steps 2–3 fill the **Subtasks**, **Attachments** and **Comments** tables from their single calls; Steps 3a–8 read the file.
+
 ### Step 2: Fetch Subtasks
 
 Use the MCP Linear server to check if the task has subtasks (children). If subtasks exist:
@@ -182,8 +218,8 @@ Use the MCP Linear server to check if the task has subtasks (children). If subta
 
 Use the MCP Linear server to fetch, for the parent task and each subtask (if any):
 
-- Attachments via `mcp__linear__get_issue({ id })` — the response includes an `attachments` array; look for one where `title == "plan.md"` (or filename — whichever field the MCP surfaces)
-- Comments via `mcp__linear__list_comments({ issueId })` — keep `id`, `createdAt`, body text
+- Attachments: from the `attachments` array already captured in Step 1 (`.ai/tasks/<issue>/issue.md`, **Attachments** table) — look for `title == "plan.md"` (or filename — whichever field the MCP surfaces). No second `get_issue`.
+- Comments via `mcp__linear__list_comments({ issueId })` — **once per issue**; append `id`, `createdAt`, first line of body to the **Comments** table of `issue.md`
 
 This is used to:
 
@@ -282,7 +318,7 @@ Use tools like:
 
 - `Glob` to find relevant files
 - `Grep` to search for related code patterns
-- `Read` to understand specific implementations
+- `Read` to understand specific implementations — never `cat`/`head`/`tail` in Bash (Hard Rule #6); read the files you need, one at a time, not whole directories
 
 ### Step 6a: Analyze External Library Dependencies
 

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

@@ -1,5 +1,5 @@
 {
   "name": "flow-external",
   "description": "Development flow skills for standalone Angular 6-11 projects without framework (Angular CLI, Karma/Jasmine, Bootstrap 4)",
-  "version": "0.10.0"
+  "version": "0.12.0"
 }

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

@@ -19,20 +19,36 @@ Create a conventional commit message based on Linear task and staged changes.
 
 ```
 /commit [linearTaskId]
+/commit [linearTaskId] --auto    # Non-interactive mode for fully autonomous runs
 ```
 
 ## Parameters
 
 - `linearTaskId` - Linear task ID (e.g., FRA-123)
+- `--auto` - Non-interactive mode: skip ALL `AskUserQuestion` prompts and the message-approval step. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent.
+
+## Auto Mode (`--auto`)
+
+**When `--auto` is set, the skill MUST run end-to-end without any human-in-the-loop prompts.** Apply these overrides:
+
+| Default behavior                                                       | `--auto` override                                                                                                                                                                                                             |
+| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Analyze only staged changes; if nothing staged, warn and don't commit  | If nothing is staged but the working tree has task-related modifications, STAGE THEM AUTOMATICALLY (`git add -A`, excluding obvious non-source artifacts — loose `*.png` in the repo root, `.playwright-mcp/`, `docs/mockups/`, `.benchmark-test/`, `.claude/settings.json`) and continue. Never ask "would you like me to stage" |
+| Completeness prompt (`AskUserQuestion`)                                | Skip the prompt; commit the current changes and note any suspected gaps in the commit body                                                                                                                                     |
+| Show message to user for approval before committing                    | Skip the approval; create the commit immediately with the generated message                                                                                                                                                   |
+| Any other `AskUserQuestion`                                            | Use the option marked **(Recommended)**; if none, pick the safest option and continue                                                                                                                                          |
+| Nothing to commit at all                                               | If an existing commit already references this task (e.g. `/impl` committed the work itself), exit cleanly with a one-line statement naming that commit. Otherwise exit cleanly stating there was nothing to commit. No question either way |
+
+**Hard requirement in `--auto`**: the run MUST end in exactly one of two states — a created commit, or an explicit one-line clean-exit statement that nothing needed committing. Ending the run with a question is a skill failure (in one-shot `--print` execution nobody can answer, the commit is silently lost, and the caller has to fall back to an emergency commit).
 
 ## Execution Checklist
 
 - [ ] **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
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop (in `--auto`: no prompt — continue and note gaps in the body)
 - [ ] **4. Determine commit type and scope** — based on changes and task type
 - [ ] **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
+- [ ] **6. Show message to user** — present commit message for approval before proceeding (skipped in `--auto`: commit immediately)
 - [ ] **7. Create commit** — execute `git commit` with the approved message
 
 ## Commit Message Format
@@ -93,6 +109,8 @@ Refs: FRA-548
 
 ### No Staged Changes
 
+Default mode only — in `--auto` do NOT print this and do NOT stop: stage task-related working-tree changes automatically and continue (see Auto Mode).
+
 ```markdown
 ## No staged changes
 
@@ -108,7 +126,7 @@ If linearTaskId is not provided or task not found:
 
 ## Guidelines
 
-1. **Always show commit message for approval** before creating the commit
+1. **Always show commit message for approval** before creating the commit (default mode; in `--auto` skip the approval and commit immediately — see Auto Mode)
 2. **Use Polish branch naming** if branch follows FRA-XXX pattern
 3. **Include Refs:** with Linear task ID when available
 4. **Keep subject line under 72 characters**

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

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

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

@@ -23,11 +23,27 @@ Create a conventional commit message based on Linear task and staged changes.
 
 ```
 /commit [linearTaskId]
+/commit [linearTaskId] --auto    # Non-interactive mode for fully autonomous runs
 ```
 
 ## Parameters
 
 - `linearTaskId` - Linear task ID (e.g., ENG-123)
+- `--auto` - Non-interactive mode: skip ALL `AskUserQuestion` prompts and the message-approval step. Treat any of `--auto`, `--ci`, `--non-interactive` as equivalent.
+
+## Auto Mode (`--auto`)
+
+**When `--auto` is set, the skill MUST run end-to-end without any human-in-the-loop prompts.** Apply these overrides:
+
+| Default behavior                                                       | `--auto` override                                                                                                                                                                                                             |
+| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Analyze only staged changes; if nothing staged, warn and don't commit  | If nothing is staged but the working tree has task-related modifications, STAGE THEM AUTOMATICALLY (`git add -A`, excluding obvious non-source artifacts — loose `*.png` in the repo root, `.playwright-mcp/`, `docs/mockups/`, `.benchmark-test/`, `.claude/settings.json`) and continue. Never ask "would you like me to stage" |
+| Completeness prompt (`AskUserQuestion`)                                | Skip the prompt; commit the current changes and note any suspected gaps in the commit body                                                                                                                                     |
+| Show message to user for approval before committing                    | Skip the approval; create the commit immediately with the generated message                                                                                                                                                   |
+| Any other `AskUserQuestion`                                            | Use the option marked **(Recommended)**; if none, pick the safest option and continue                                                                                                                                          |
+| Nothing to commit at all                                               | If an existing commit already references this task (e.g. `/impl` committed the work itself), exit cleanly with a one-line statement naming that commit. Otherwise exit cleanly stating there was nothing to commit. No question either way |
+
+**Hard requirement in `--auto`**: the run MUST end in exactly one of two states — a created commit, or an explicit one-line clean-exit statement that nothing needed committing. Ending the run with a question is a skill failure (in one-shot `--print` execution nobody can answer, the commit is silently lost, and the caller has to fall back to an emergency commit).
 
 ## Execution Checklist
 
@@ -35,10 +51,10 @@ 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
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop (in `--auto`: no prompt — continue and note gaps in the body)
 - [ ] **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
+- [ ] **6. Show message to user** — present commit message for approval before proceeding (skipped in `--auto`: commit immediately)
 - [ ] **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
@@ -198,7 +214,7 @@ After the commit is created, perform an optional parallelization analysis:
 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
+6. If there are no staged changes, warn the user and don't create commit (default mode only; in `--auto` stage task-related working-tree changes automatically per Auto Mode and proceed)
 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
@@ -212,4 +228,4 @@ For Linear task "ENG-123: Add dark mode toggle to settings":
 
 ---
 
-**Important**: Before committing, show the generated commit message to the user for approval.
+**Important**: Before committing, show the generated commit message to the user for approval. In `--auto` mode skip the approval entirely — commit immediately and never end the run with a question (see Auto Mode).

package/plugins/smart-pro/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "smart-pro",
   "description": "Smart-pro integration - safety validation, audit logging, and auto-formatting hooks",
-  "version": "0.10.0"
+  "version": "0.12.0"
 }