@roopesh.yadava/qa-pack 1.5.1 → 1.6.1

package/README.md

@@ -92,6 +92,8 @@ and `/write-acceptance-criteria`, which are also available as explicit slash com
 | `/write-acceptance-criteria PROJ-123` | write-acceptance-criteria | Generates AC, appends to the Jira card description |
 | `/impacted-tests` / `which tests are impacted by this pull` | impacted-tests | After pulling dev changes into a test branch, reports which Cucumber feature files are at risk — report-only, no card needed |
 | `set up k6` / `scaffold performance tests` | k6-framework-scaffold | Scaffolds a `k6-performance-tests/` framework (Grafana Cloud, protocol + optional browser layers) with commented templates to fill in — no card needed |
+| `set up mobile testing` / `set up mobilewright` / `scaffold mobile BDD tests` | mobilewright-setup | Scaffolds Cucumber.js + Mobilewright + a living-documentation HTML reporter into a mobile app repo (Expo, bare React Native, or native iOS/Android), plus one real smoke feature/step file — no card needed. Run once, before `mobile-automation` has anything to plug into |
+| `automate mobile PROJ-123` / `write mobile automation for this card` | mobile-automation | Reuse-first Gherkin → step defs → Screen POM → real device run + self-heal for native iOS/Android apps, via Mobile MCP + Mobilewright — the mobile counterpart to `automation` (web) |
 | `roam mode` / `explore the app` | roam-testing | Card-free exploratory testing — capped breadth-first crawl, report + optional bug filing + charter |
 | `qa dashboard` / `weekly digest` / `token roi` | qa-insights | Cross-product health dashboard, weekly digest, or token-spend/ROI view — 100% script-generated, no card needed |
 
@@ -107,6 +109,28 @@ token beyond the one line of output. This is also why `qa-insights` (dashboard/d
 across every product you've ever tested) costs about the same whether you have 2 products or
 200 — the script does the aggregation, not the model.
 
+### Team dashboard (optional, off by default)
+
+`qa-insights`' dashboard is local and per-repo — it only sees runs on your own machine.
+To see the whole team's runs across every product, set `QA_DASHBOARD_REPO` and
+`QA_DASHBOARD_TOKEN` in `.env` (see `.env.example`). Once set, **every skill** reports its
+own execution as its last step — one small JSON file pushed to that shared GitHub repo via
+the GitHub Contents API. No local `git commit`/`git push`, so it never touches this repo's
+`.git` or shows up in `git status`. Leave the variables unset and nothing changes; the
+call is a silent no-op, same as the optional `QA_TRACKING_DIR` token tracking.
+
+One record is one *skill execution*, not one card: a single card taken through `qa-agent` →
+`manual-testing` → `bug-reporting` reports three. The dashboard counts both ("skill runs"
+and "cards covered") so neither number is misleading.
+
+What each record contains: product, card (when the skill has one), skill name, outcome, bug
+IDs, reuse %, date, calling repo name, and an author label taken from `git config user.name`
+— never `user.email`, since the dashboard repo is typically public and its history is
+permanent. Set `QA_DASHBOARD_AUTHOR` in `.env` to override the label. A push that fails
+(expired PAT, wrong repo, no network) stays silent and is appended to
+`outputs/report-run-errors.log`; add `--verbose` to a manual `report-run` call to see the
+result directly, which is the way to verify a freshly issued token.
+
 ## What postinstall does
 
 | File | Behaviour |

package/claude/commands/bug-report.md

@@ -1,185 +1,11 @@
-You are a Jira bug reporting assistant. Follow these steps precisely and in order.
-
----
-
-## Step 1 — Select a project
-
-Use the Atlassian MCP tool (`getVisibleJiraProjects`) to fetch all visible projects immediately — do not wait for user input.
-
-Display the list and ask:
-"Which board are you working on? You can reply with the number or the board key:
-1. [KEY] — [Project Name]
-2. [KEY] — [Project Name]
-..."
-
-Wait for the user to select a project by number or board key. Save the selected project key for the rest of the flow.
-
----
-
-## Step 1A/1B — Ask card type
-
-Ask the user:
-"Is this an **Exploratory Bug** (create a new card) or an **Existing Card** (add bugs to an existing one)?"
-
-Wait for the user's choice before proceeding.
-
-- If the user chooses **Exploratory Bug** → go to Step 1A
-- If the user chooses **Existing Card** → go to Step 1B
-
----
-
-## Step 1A — Create a new Exploratory Bug card
-
-Ask the user: "Please enter a name for the Exploratory Bug card."
-
-Wait for the user's input.
-
-Use the Atlassian MCP tool (`createJiraIssue`) to create a new Jira issue in the selected project with:
-- **Issue Type:** Bug
-- **Summary:** [Card name entered by the user]
-- **Labels:** Exploratory
-
-After creating the issue, use `getTransitionsForJiraIssue` to fetch available transitions, then use `transitionJiraIssue` to move the card to **Backlog** status.
-
-Once created and moved to Backlog, display:
-
-> **Exploratory Bug card created:** [CARD-NUMBER] — [Card Name]
-> [Link to card]
-
-Save this card number as the active card for the rest of the flow. Then proceed to Step 2.
-
----
-
-## Step 1B — Use an existing card
-
-Ask the user: "Please enter the card number (e.g. 123 or [KEY]-123) to attach this bug report to."
-
-Wait for the user's input.
-
-If the user enters only a number (e.g. `2446`), construct the full card number using the selected project key (e.g. QE-2446).
-
-Use the Atlassian MCP tool (`getJiraIssue`) to fetch the card details. Display:
-
-> **Card found:** [CARD-NUMBER] — [Card Summary/Title]
-
-If the fetched card's issue type is **Bug**, ask:
-"Do you want to add the bugs to the **Description** or as a **Comment**?"
-
-Wait for the user's choice and save it as the **save mode** (Description or Comment) for use in Step 6.
-
-Save this card number as the active card for the rest of the flow. Then proceed to Step 2.
-
----
-
-## Step 2 — Collect bug details
-
-Ask the user: "Please describe the bug."
-
-Wait for the user's input. Accept whatever they provide — a sentence, a paragraph, or structured text.
-
-From the input, infer and derive all necessary fields:
-- **Bug Title** — extract or summarise from what was given
-- **Expected Outcome** — infer from context if not explicitly stated
-- **Actual Outcome** — extract the described problem
-- **Steps to Reproduce** — extract or derive from the description
-
-Do NOT ask the user for any missing fields. Use what was given and proceed.
-
 ---
-
-## Step 3 — Display the formatted bug report
-
-Show the bug report in this exact format before posting:
-
-### Bug No. [n]: [Bug Title]
-
-### Expected Outcome:
-[Expected Outcome]
-
-### Actual Outcome:
-[Actual Outcome]
-
-### Steps to Reproduce:
-[Steps]
-
-After showing the report, ask:
-"Is this the only bug, or do you have another bug to add?"
-
-- If the user says **yes (another bug)** — go back to Step 2 and collect the next bug. Append it to the report using the same format with an incremented Bug No. Repeat until the user says no more bugs.
-- If the user says **no more bugs** — proceed to Step 4.
-
+name: bug-report
+description: File a bug to Jira — new Exploratory Bug card or attached to an existing card.
+argument-hint: "[bug description | Jira card ID]"
+user-invocable: true
 ---
 
-## Step 4 — Ask who to mention
-
-Before posting, ask:
-"Who should I notify about this bug? Please enter the person's name, or type **none** to skip."
-
-Wait for the user's input.
-
-- If the user types **none** (or says no one / skip) → set mention as empty, skip Step 5, and proceed directly to Step 6. Do NOT add any mention or "Please check this" line in the report.
-- Otherwise → proceed to Step 5.
-
----
-
-## Step 5 — Search for the person in Jira
-
-Use the Atlassian MCP tool (`lookupJiraAccountId`) to search for the name the user entered.
-
-If multiple results are found, list them and ask:
-"Is this the right person? [Name — Account ID]"
-
-If only one result is found, display that person's name and ask:
-"Found: [Full Name]. Is this the right person? (yes / no)"
-
-Wait for confirmation before proceeding.
-
----
-
-## Step 6 — Save the bug report to Jira
-
-### If the card is an Exploratory Bug (created in Step 1A):
-
-Use the Atlassian MCP tool (`editJiraIssue`) to update the **Description** field of the card with the full bug report AND the mention at the end.
-
-The description body must follow this structure:
-
-```
-h3. Bug No. [n]: [Bug Title]
-
-h3. Expected Outcome:
-[Expected Outcome]
-
-h3. Actual Outcome:
-[Actual Outcome]
-
-h3. Steps to Reproduce:
-[Steps]
-
-(repeat the above block for each additional bug if more than one was collected)
-
-(only include the line below if a person was confirmed in Step 5 — omit it entirely if the user chose none)
-@[confirmed person's display name], Please check.
-```
-
-Do NOT post a comment. Write everything into the Description field of the card.
-
----
-
-### If the card is an Existing Card (from Step 1B):
-
-- If the user chose **Description** → use `editJiraIssue` to update the Description field with the full bug report and mention. Do NOT post a comment.
-- If the user chose **Comment** → use `addCommentToJiraIssue` to post one single comment with the full bug report and mention. Do NOT post a second separate comment.
-
-In both cases the content structure is the same as above.
-
----
-
-## Step 7 — Confirm completion
-
-Show a summary:
-- Jira card: [Card number with link]
-- Bug report posted: ✓
-- Notified: [Confirmed person's name]
+Invoke the `bug-reporting` skill.
 
-Done.
+If the user provided an argument (e.g. a bug description or a Jira card ID), pass it
+directly into the skill as the initial intent so it does not re-ask for input already given.

package/claude/commands/write-acceptance-criteria.md

@@ -14,8 +14,9 @@ user-invocable: true
 ## Core Workflow
 
 0. **Detect Jira card ID** — If the argument matches the pattern `[A-Z]+-[0-9]+` (e.g. `FF-420`, `AA-12`),
-   fetch the issue using the `getJiraIssue` tool with cloudId `853e134e-6574-491a-a075-1b06f7d4b478`.
-   Use the issue summary and description as the feature input for the next steps.
+   fetch the issue using the `getJiraIssue` tool. Use the issue summary and description as the
+   feature input for the next steps. Store the card's own URL (returned by the fetch) for the
+   confirmation step later — never hardcode a Jira domain.
    If the issue has no description, use the summary only and note this in the Assumptions section.
    If the argument is not a Jira card ID, treat it as a raw feature description and skip to step 1.
 
@@ -33,8 +34,8 @@ user-invocable: true
    - Fetch the current description of the issue using `getJiraIssue`
    - Preserve the full existing description exactly as-is (do NOT remove or overwrite any content, including COS or any other existing sections)
    - Append the generated acceptance criteria at the very bottom of the existing description, separated by a divider line (`---`)
-   - Update the issue description using `editJiraIssue` with cloudId `853e134e-6574-491a-a075-1b06f7d4b478`
-   - After updating, confirm to the user with the Jira issue URL: `https://7edge.atlassian.net/browse/<CARD-ID>`
+   - Update the issue description using `editJiraIssue`
+   - After updating, confirm to the user with the card's own URL (from the fetch in step 0) — never a hardcoded domain
 
 ---
 
@@ -125,43 +126,3 @@ If the feature description is vague:
 ---
 
 *Assumed: web-based product with a registered user model and a transactional email provider already in place. Adjust if this is a mobile or API-only context.*
-
-
-
-<!-- Created by Roopesh Yadava
-
-Generate detailed documentation for the feature: {{feature_description}}
-
-Follow these steps:
-
-1. **Identify scenarios** — Analyze the feature description and derive all possible user flows, including standard usage and edge cases.
-
-2. **Understand expected behavior** — Determine:
-
-   * What the user is trying to achieve
-   * System responses for valid and invalid inputs
-   * Possible failure points or UX gaps
-
-3. **Generate output** with the following structure:
-
-## Acceptance Criteria
-
-(Leave this section empty — do not list or rewrite anything here.)
-
-## Happy Paths
-
-* List all happy paths using numbered bullets.
-* Each step should describe one clear user action or system result.
-* Keep steps concise, realistic, and sequential.
-
-## Unhappy Paths
-
-* List all unhappy paths using numbered bullets.
-* Include:
-
-  * User errors
-  * Validation failures
-  * System issues
-  * Edge cases
-  * Missing or incorrect feedback
-  * Be specific and practical in each scenario. -->

package/claude/skills/SKILLS_CONTEXT.md

@@ -96,6 +96,7 @@ node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs <command> [--flags]
 | `trust-record` / `trust-status` --product P [--namespace N] | automation, mobile-automation (`--namespace mobile` — routes to a separate `trust.mobile.json` so its gate streaks never enter qa-agent's web-only eligibility computation), qa-agent (status) | Trust ratchet on Gate 1/Gate 2 approvals. `--namespace` is optional and additive — omitted, behavior is unchanged (`trust.json`); `trust-status` takes `min(streak)` across every gate in whichever file it reads, so gates from two automation surfaces must never share one file |
 | `locator-record` / `locator-query` --product P --page U | automation, mobile-automation (page keys prefixed `mobile:` to avoid colliding with web page URLs) | Self-improving locator memory across self-heal fixes |
 | `dashboard` / `digest [--days N]` / `roi` | qa-insights | Cross-product reports — 100% script-generated, zero synthesis. Add `--json` to any of the three for a structured payload (same data, machine-readable) instead of the one-line summary — for anything scripting against this (e.g. an external dashboard app) rather than chatting with it. |
+| `report-run` --skill S --outcome Y [--product P] [--card C] [--bugs "a,b"] [--reuse N] [--phase X] [--verbose] | **every skill, as its own last step** — `qa-agent`, `automation`, `manual-testing`, `mobile-automation`, `accessibility-testing`, `ui-test-figma`, `roam-testing`, `bug-reporting`, `impacted-tests`, `test-charter`, `k6-framework-scaffold` | Optional team dashboard: pushes one JSON file per **skill execution** to a shared GitHub repo (Contents API — no local git commit/push). Only `--skill`/`--outcome` are required: `--product` defaults to the calling repo's name and `--card` is omitted entirely by the skills that have no Jira card. Silent no-op unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env`, same convention as `QA_TRACKING_DIR`. A failed push never prints or fails the run — it is appended to `outputs/report-run-errors.log`; `--verbose` prints the result, which is how you verify a new PAT once. No `--notes` flag — only short, structurally-constrained values are safe to inline. |
 
 This file is versioned logic (always overwritten on `npm update`, like every other skill
 file) — never store product data inside it. Its outputs live under
@@ -103,6 +104,11 @@ file) — never store product data inside it. Its outputs live under
 `locator-learnings.md` — all new, all gitignored the same way `context.md` already is) or
 `outputs/` (`dashboard.html`, `qa-weekly-digest-*.md`, `roi-report.md`).
 
+The toolkit reads `.env` from the repo root itself (real environment variables win), so
+every `QA_*` value documented for `.env` reaches it without the calling skill exporting
+anything. Before this, `QA_DASHBOARD_*` and `QA_TRACKING_DIR` were read straight off
+`process.env` and were therefore permanently unset in normal skill use.
+
 **Never inline arbitrary text into a toolkit shell call.** Bug descriptions, locator
 strings, and anything else that isn't a short agent-controlled token (a card ID, a product
 folder name, a URL) can contain quotes, `` ` ``, `$(...)`, or `|` — inlined into a bash
@@ -155,6 +161,13 @@ skill (same status as `roam-testing`/`k6-framework-scaffold`), not wired into qa
 Phase 2 dispatch, which remains web/Playwright-only via `automation`. Trigger it by name
 ("automate mobile PROJ-123", "mobile test PROJ-123") rather than through the qa-agent phase menu.
 
+`mobilewright-setup` sits outside this diagram too — a one-time scaffolder (same role as
+`k6-framework-scaffold`, but for a mobile app's BDD test stack instead of a perf-test stack),
+not a Jira-card-driven skill and not wired into qa-agent. It's what a repo needs *before*
+`mobile-automation` has anything to plug into — run it once on a repo with no existing
+Cucumber/Mobilewright setup, then use `mobile-automation` for ongoing card-driven test
+authoring against what it scaffolded.
+
 ## Skills — One-Line Summary
 
 | Skill | Input | Output | MCP Needed |
@@ -162,6 +175,7 @@ Phase 2 dispatch, which remains web/Playwright-only via `automation`. Trigger it
 | `qa-agent` | Jira card ID or menu choice | Dispatches to correct skill | Atlassian |
 | `automation` | Jira card ID | Reuse audit + Gherkin + Step Defs + POM + real run (reuse % reported) | Atlassian, Playwright |
 | `mobile-automation` | Jira card ID | Reuse audit + mobile Gherkin + Step Defs + Screen POM + real device run (reuse % reported) | Atlassian, Mobile MCP, MobileWright/mobilecli |
+| `mobilewright-setup` | Nothing (a repo to scaffold into) — no card needed | Cucumber.js + Mobilewright + living-documentation HTML reporter installed and wired into `package.json`, plus one real smoke feature/step file | None — pure file scaffolding + `npx mobilewright doctor`/local test run |
 | `manual-testing` | Jira card ID + app URL | Execution report + bugs + charter | Atlassian, Playwright |
 | `ui-test-figma` | Figma URL + app URL | UI mismatch report, Jira comment | Playwright (CLI+MCP), Figma (optional) |
 | `accessibility-testing` | Full page URL + Jira card (optional) | WCAG 2.1 A/AA report + Jira bugs | Playwright (CLI+MCP), Atlassian |
@@ -294,6 +308,8 @@ First run will always be 0% (cold cache). Second and subsequent runs should cach
 | Token analytics | `~/.claude/token_analytics.png` |
 | Knowledge graph | `graphify-out/graph.html` (open in browser) |
 | Product QA context | `.claude/skills/qa-agent/product_context/[PRODUCT]/context.md` |
+| Team QA dashboard data (shared, cross-repo, not in this repo) | `runs/[PRODUCT]/[date]-[card]-[skill]-[id].json` inside the repo named by `QA_DASHBOARD_REPO` — see `report-run` |
+| Team dashboard push failures (local, gitignored) | `outputs/report-run-errors.log` — the only place a failed `report-run` is visible |
 | DOM fingerprint cache | `.claude/skills/qa-agent/product_context/[PRODUCT]/dom-fingerprints.json` |
 | Trust ratchet state | `.claude/skills/qa-agent/product_context/[PRODUCT]/trust.json` |
 | Locator learnings | `.claude/skills/qa-agent/product_context/[PRODUCT]/locator-learnings.md` |

package/claude/skills/accessibility-testing/SKILL.md

@@ -315,3 +315,19 @@ Accessibility Testing Complete
 | Jira bug creation fails | Note failure, continue remaining bugs, report failures at end |
 | OTP screen appears unexpectedly | Type the `QA_OTP_CODE` value from `.env`, proceed |
 | Page requires further navigation after login | Follow redirect, confirm TARGET_URL loads |
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill accessibility-testing --card {JIRA_CARD_ID, omit if none} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}"
+```
+This skill has no `PRODUCT_FOLDER`; omit `--product` and the record is filed under the
+calling repo's name automatically. Omit `--card` too when the run had no Jira card.

package/claude/skills/automation/SKILL.md

@@ -531,3 +531,21 @@ Print one line only (omit entirely if file not found):
 ```
 Selectors written to product context ({N} elements, {N} flows).
 ```
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill automation --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --outcome {Pass|Fail|Partial} --reuse {reuse % number} --phase Automation
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/bug-reporting/SKILL.md

@@ -293,4 +293,21 @@ Show a summary:
 - Notified: [Confirmed person's name]
 - Screenshots attached: [list of filenames, or "none" / "credentials not set"]
 
----
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill bug-reporting --product {PRODUCT_FOLDER} --card {the card just filed/updated} \
+  --outcome {Pass if the bug posted, Fail if it did not} \
+  --bugs "{the bug key(s) filed}"
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/impacted-tests/SKILL.md

@@ -108,4 +108,19 @@ Rules for each entry:
 
 ## Step 5 — Stop
 
-The report is the deliverable. Do NOT run any test, do NOT ask whether to run them — the QA reviews the report and runs files manually using the footer command. End the turn after printing the report.
+The report is the deliverable. Do NOT run any test, do NOT ask whether to run them — the QA reviews the report and runs files manually using the footer command. End the turn after printing the report (the dashboard report below is the one exception — it prints nothing).
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Run this after the report is printed and before ending the turn. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill impacted-tests --outcome Pass
+```
+No product folder and no card in this skill — omit both flags; the record is filed under
+the calling repo's name.

package/claude/skills/k6-framework-scaffold/SKILL.md

@@ -56,3 +56,17 @@ After it runs, tell the tester the next steps:
 - Keep real tokens out of version control (the scaffold's `.gitignore` covers `secrets.local.*`).
 - If the user wants the structure tailored (their user types, real endpoints from a Postman
   collection), scaffold first, then edit the generated templates to match.
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill k6-framework-scaffold --outcome {Pass|Fail}
+```
+No product folder and no card — omit both flags.

package/claude/skills/manual-testing/SKILL.md

@@ -627,3 +627,22 @@ Do NOT stream: full charter text, all test results (save to file), full bug repo
 | Figma URL missing / user says no | Skip UI Testing, note in final summary |
 | `browser_evaluate` returns null for element | Log "element not captured" in hints, continue |
 | Bug creation fails | Note failure, continue with remaining bugs, report at end |
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill manual-testing --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}" \
+  --phase Manual
+```
+`report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/mobile-automation/SKILL.md

@@ -591,3 +591,21 @@ One-line confirmation either way:
 ```
 Mobile context saved → .claude/skills/qa-agent/product_context/{PRODUCT_FOLDER}/context.md ({N} elements, {N} flows).
 ```
+
+**Then report to the team dashboard (optional, silent)** — using the same values just
+written to the Runs Log row:
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill mobile-automation --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --phase Automation \
+  --outcome {OUTCOME} --bugs "{comma-separated bug IDs or empty}" \
+  --reuse {reuse % number}
+```
+
+Only pass `--product`/`--card`/`--phase`/`--outcome`/`--bugs`/`--reuse` — short,
+structurally-constrained values (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`). `report-run` has no `--notes` flag; don't inline the freeform
+Runs Log note here. This is a no-op unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are
+set in `.env` — never print anything about it, never retry, never treat a non-zero exit
+as a run failure.

package/claude/skills/mobilewright-setup/SKILL.md

@@ -0,0 +1,365 @@
+---
+name: mobilewright-setup
+description: >
+  Scaffolds a complete BDD end-to-end test automation setup for a mobile app repo —
+  Cucumber.js (Gherkin feature files + step definitions), Mobilewright (a
+  Playwright-style device automation framework for iOS/Android, native or
+  React Native/Expo), and a "living documentation" HTML report generator
+  (multiple-cucumber-html-reporter). Works on any mobile app project: Expo,
+  bare React Native, native iOS (UIKit/SwiftUI), or native Android
+  (Views/Jetpack Compose) — it detects the project shape and adapts.
+  Use this skill when the user asks to "set up mobile testing", "add BDD /
+  Cucumber tests", "set up mobilewright", "scaffold e2e tests for the mobile
+  app", "add a living documentation / test report generator", "wire up
+  test:report / living-doc script", or generally wants end-to-end mobile UI
+  test automation added to a repo from scratch. Also use it as a reference
+  when adding new feature files or step definitions to a project that
+  already has this setup, so conventions stay consistent.
+---
+
+# Mobile BDD Test Setup
+
+Sets up a full BDD test-automation stack for a mobile app repo, end to end:
+**Gherkin features → step definitions → Mobilewright device driver → Cucumber
+JSON reports → an HTML "living documentation" report.** Everything is created
+fresh in a single pass, adapted to whatever mobile project you're dropped into.
+
+This skill does the scaffolding. It does not know the target app's screens —
+budget time to explore the app's source (or a running build) to write the
+first real feature/step files with correct locators.
+
+## 0. Mental model
+
+- **Cucumber.js** runs `.feature` files (Gherkin) against step definitions in
+  `test/step-definitions/**/*.mjs`. It owns test discovery, execution, and
+  JSON report output.
+- **Mobilewright** (`mobilewright` npm package) is the device driver —
+  Playwright's API (`getByRole`, `getByText`, `expect(...).toBeVisible()`,
+  auto-waiting) but pointed at a real/emulated/simulated mobile device
+  instead of a browser. One config file (`mobilewright.config.mjs`) declares
+  which platform/device/app to drive; Cucumber's `World` uses it to launch
+  the app before each scenario.
+- **multiple-cucumber-html-reporter** turns the Cucumber JSON output into a
+  browsable "living documentation" HTML report — this is the `report` /
+  `living-doc.mjs` script.
+- Nothing here is React-Native-specific. Mobilewright drives the OS
+  accessibility tree, so this setup works for native iOS/Android apps too —
+  only the locators change (see §6).
+
+## 1. Discover the target project
+
+Before writing anything, gather facts. Do this with direct reads/greps, not
+guesses:
+
+1. **Package manager & repo shape** — read `package.json`. Note the `name`
+   and `version` (used later for report branding). Check for `expo` in
+   dependencies (Expo/RN project) vs. presence of `ios/`/`android/` native
+   folders only (bare RN or native project).
+2. **Bundle / package identifier** — look in this order and stop at the
+   first match:
+   - `app.config.ts` / `app.config.js` / `app.json` (Expo) — read
+     `ios.bundleIdentifier` and `android.package`. These are sometimes
+     computed by a function (env-variant based, like a `getBundleIdentifier()`
+     helper) rather than a plain string — if so, read the function to find
+     the actual default value, don't just grab the string "getBundleIdentifier()".
+   - `ios/*/Info.plist` → `CFBundleIdentifier`, or `*.xcodeproj` → `PRODUCT_BUNDLE_IDENTIFIER`.
+   - `android/app/build.gradle` (or `.kts`) → `applicationId`.
+   - If genuinely ambiguous (multiple variants/flavors: dev/qa/preprod/prod),
+     ask the user which build variant to test against — don't silently pick one.
+3. **Existing test setup** — check for `test/`, `e2e/`, `cucumber.js`,
+   `*.feature` files, or an existing `mobilewright.config.*`. If any of this
+   already exists, this is an **update**, not a fresh scaffold: read what's
+   there and extend it rather than overwriting. Never blindly clobber an
+   existing `mobilewright.config.*`, `cucumber.js`, or `world.mjs`.
+4. **Testing platform** — infer if possible (e.g. only `android/` present →
+   android; only `ios/` → ios). If both exist and the user didn't say, ask.
+
+Only ask the user (via a clarifying question) for facts you could not
+determine from the repo: target **platform** (`ios`/`android`), a
+**device** to run against (a specific simulator/emulator name, or "use
+auto-discovery"), and the **bundle/app id** if it's genuinely ambiguous.
+Everything else, infer and proceed — this skill runs under an
+auto/no-interruption workflow by default, so don't stop for things you can
+reasonably derive.
+
+## 2. Install dependencies
+
+Detect the package manager from the lockfile present (`package-lock.json` →
+npm, `yarn.lock` → yarn, `pnpm-lock.yaml` → pnpm, `bun.lockb` → bun) and
+install as **devDependencies**:
+
+```bash
+npm install -D @cucumber/cucumber mobilewright multiple-cucumber-html-reporter
+```
+
+(swap `npm install -D` for the equivalent `yarn add -D` / `pnpm add -D` /
+`bun add -d` as appropriate). Do not add these as runtime `dependencies`.
+
+## 3. Create `mobilewright.config.mjs`
+
+Write to the project root. Fill in the platform/bundleId/device values
+discovered or confirmed in step 1 — never leave placeholder text in the
+committed file.
+
+```javascript
+import { defineConfig } from 'mobilewright';
+
+export default defineConfig({
+  platform: '{{PLATFORM}}', // 'android' | 'ios'
+  bundleId: '{{BUNDLE_ID}}', // e.g. com.example.myapp(.qa)
+  deviceId: '{{DEVICE_ID}}', // named emulator/simulator profile, if the user gave one — omit this line if using auto-discovery instead
+  deviceType: '{{DEVICE_TYPE}}', // 'emulator' | 'simulator' | 'real-device' — omit if unknown
+  timeout: 30_000,
+});
+```
+
+Notes:
+- `deviceId`/`deviceType` are optional — Mobilewright auto-discovers the
+  first booted device matching `platform` if omitted. Prefer auto-discovery
+  unless the user specifically named a device/profile.
+- If the project already targets both platforms via CI, consider the
+  `projects` array (Mobilewright's multi-device/platform matrix — see the
+  `projects` option in the mobilewright package's own `README.md` under
+  `node_modules/mobilewright/README.md`, or https://mobilewright.dev) instead
+  of a single flat config. Only do this if the user asks for multi-platform
+  runs; default to a single flat config otherwise.
+- A one-line comment noting *why* a value was picked (e.g. "QA build shared
+  for testing") is fine and matches existing convention, but keep it to one
+  line.
+
+## 4. Create `cucumber.js`
+
+Root-level Cucumber profile. This wires feature discovery, step import, and
+report output:
+
+```javascript
+module.exports = {
+  default: [
+    'test/features/**/*.feature',
+    '--import test/step-definitions/**/*.mjs',
+    `--format json:reports/cucumber-report-${Date.now()}.json`,
+    '--format summary',
+    '--format progress-bar',
+  ].join(' '),
+};
+```
+
+Keep the feature/step-definition globs as-is unless the target repo already
+uses a different test root (e.g. `e2e/` instead of `test/`) — match whatever
+already exists rather than introducing a second convention.
+
+## 5. Create `test/step-definitions/support/world.mjs`
+
+This is the Cucumber `World` — it owns the device lifecycle (launch before
+each scenario, close after). This file is intentionally app-agnostic; do not
+add app-specific logic here.
+
+```javascript
+import { setWorldConstructor, setDefaultTimeout, Before, After } from '@cucumber/cucumber';
+import { ios, android } from 'mobilewright';
+import config from '../../../mobilewright.config.mjs';
+
+setDefaultTimeout(config.timeout ?? 30_000);
+
+class MobileWorld {
+  async launch() {
+    const launcher = config.platform === 'android' ? android : ios;
+    this.device = await launcher.launch({
+      bundleId: config.bundleId,
+      deviceId: config.deviceId,
+      deviceName: config.deviceName,
+      installApps: config.installApps,
+    });
+    this.screen = this.device.screen;
+  }
+
+  async teardown() {
+    await this.device?.close();
+  }
+}
+
+setWorldConstructor(MobileWorld);
+
+Before(async function () {
+  await this.launch();
+});
+
+After(async function () {
+  await this.teardown();
+});
+```
+
+Every step definition gets `this.device` and `this.screen` from this World —
+step files never construct their own device connection.
+
+## 6. Write the first feature + step definitions
+
+Don't hand-wave this — a setup with zero real assertions isn't done. Find one
+real, stable entry point in the app under test and write one smoke scenario
+against it:
+
+1. **Find a locator.** Grep the app source for existing test hooks in
+   priority order (this matches Mobilewright's own locator priority:
+   `getByTestId` > `getByRole` > `getByLabel` > `getByText`):
+   - React Native/Expo: search for `testID=`, `accessibilityLabel=`,
+     `accessibilityRole=` props on the first/home screen's root and key
+     interactive elements.
+   - Native iOS: `accessibilityIdentifier` / `accessibilityLabel` in
+     SwiftUI/UIKit source.
+   - Native Android: `contentDescription` / view `id`s, or Compose
+     `Modifier.testTag(...)` / `semantics { }`.
+   - If nothing is tagged yet, don't invent testIDs blindly — either add a
+     minimal `testID`/`accessibilityIdentifier` to the one element you need
+     (small, targeted, and tell the user you did it), or fall back to
+     `getByText('...')` against real on-screen copy you found in source.
+2. **If you can run a booted simulator/emulator**, `npx mobilewright inspect`
+   opens a live element inspector against the connected device — use it to
+   confirm real locators instead of guessing from source alone.
+3. Write `test/features/<area>.feature`:
+
+```gherkin
+Feature: <Screen or flow name>
+
+  Scenario: <one concrete, observable outcome>
+    Given <a starting state, e.g. "the app has launched">
+    Then <an assertion tied to a real locator>
+```
+
+4. Write the matching `test/step-definitions/<area>.steps.mjs`:
+
+```javascript
+import { Given, When, Then } from '@cucumber/cucumber';
+import { expect } from 'mobilewright';
+
+Given('the app has launched', async function () {
+  await expect(this.screen.getByTestId('<real-test-id>')).toBeVisible();
+});
+```
+
+Step conventions to follow:
+- One `Given`/`When`/`Then` per file topic; keep step text reusable across
+  scenarios in the same feature area rather than one-off phrasing per
+  scenario.
+- Prefer `getByTestId` / `getByRole` over `getByText`/coordinate taps —
+  they're the least brittle across locale and copy changes.
+- Never hardcode secrets (passwords, tokens) directly in `.feature` files if
+  the repo has an env/secrets convention already (`.env`, CI variable
+  groups, etc.) — follow that repo's existing pattern instead. If unsure, ask.
+
+## 7. Create `scripts/living-doc.mjs`
+
+Generates the browsable HTML report from the Cucumber JSON output. Pull
+branding from `package.json` — never hardcode a project name:
+
+```javascript
+import { readFileSync } from 'fs';
+import { generate } from 'multiple-cucumber-html-reporter';
+import config from '../mobilewright.config.mjs';
+
+const { name, version } = JSON.parse(readFileSync(new URL('../package.json', import.meta.url)));
+
+const displayName = '{{DISPLAY_NAME}}'; // human-readable project name, e.g. derived from package.json `name`
+
+generate({
+  jsonDir: 'reports/',
+  reportPath: 'living-documentation/',
+  pageTitle: displayName,
+  pageFooter: `<div class="created-by"><p>${displayName} QA</p></div>`,
+  reportName: displayName,
+  metadata: {
+    device: config.deviceName ?? config.deviceId,
+    platform: { name: config.platform === 'ios' ? 'iOS' : 'Android', version: '' },
+    app: { name, version },
+  },
+  customData: {
+    title: 'Run info',
+    data: [{ label: 'Project', value: name }],
+  },
+});
+```
+
+Derive `displayName` from `package.json`'s `name` (title-cased, hyphens/
+underscores replaced with spaces) unless the repo already has an obvious
+human-readable product name elsewhere (README title, app display name in
+`app.config.*`/`app.json`) — prefer that if present.
+
+## 8. Wire up `package.json` scripts
+
+Add (don't replace unrelated existing scripts):
+
+```json
+{
+  "scripts": {
+    "test": "cucumber-js",
+    "test:doctor": "mobilewright doctor",
+    "report": "node scripts/living-doc.mjs",
+    "test:report": "npm run test && npm run report"
+  }
+}
+```
+
+If a `test` script already exists for a different test runner (unit tests,
+etc.), don't clobber it — use a distinct name instead
+(`test:e2e`/`test:bdd`/`test:mobile`) and say so to the user, then adjust
+`test:report` to reference the new name.
+
+## 9. Update `.gitignore`
+
+Ensure generated test artifacts aren't committed. Add if missing:
+
+```
+# cucumber JSON reports + generated living documentation
+reports
+living-documentation
+
+# test app binaries (built artifacts, not source)
+test/app/
+```
+
+Only add the `test/app/` line if the repo's test setup installs app binaries
+locally (check whether `installApps` is used in the config); skip it
+otherwise.
+
+## 10. Verify the environment
+
+Run the doctor check and report its output to the user — don't just assume
+success:
+
+```bash
+npx mobilewright doctor
+```
+
+This validates Xcode/Android SDK/emulator-simulator availability and tells
+you exactly what's missing. Surface any failures verbatim; don't try to
+silently work around a missing SDK/toolchain.
+
+If a device is booted and reachable, also do a real run to confirm the
+scaffold works end to end:
+
+```bash
+npm run test:report
+```
+
+## 11. Summary to the user
+
+After setup, tell the user concretely:
+- What was installed and created (file list).
+- Which platform/device/bundle id the config targets, and why (inferred vs.
+  user-provided).
+- The doctor check result.
+- How to run tests day to day: `npm test` (or the chosen script name),
+  `npm run report` / `npm run test:report`, and where the living-doc report
+  lands (`living-documentation/index.html`).
+- That new features go in `test/features/*.feature` with matching
+  `test/step-definitions/*.steps.mjs`, and that `world.mjs` under
+  `test/step-definitions/support/` should stay app-agnostic — device
+  lifecycle only, no scenario-specific logic.
+
+## Reference
+
+Full Mobilewright API (locators, assertions, config options, CLI commands)
+is documented in the installed package at `node_modules/mobilewright/README.md`
+and `node_modules/mobilewright/reference.md` once installed — read those
+directly rather than relying on memory when writing non-trivial step
+definitions (e.g. WebView bridging, multi-device `projects` config, role
+mapping tables).

package/claude/skills/qa-agent/SKILL.md

@@ -370,6 +370,21 @@ Write `context.md`, then print one line:
 Product context saved → .claude/skills/qa-agent/product_context/{PRODUCT_FOLDER}/context.md
 ```
 
+### 6f — Report to team dashboard (optional, silent)
+
+Immediately after 6e, using the same values just written to the Runs Log row, shell out:
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill qa-agent --product {PRODUCT_FOLDER} --card {CARD_ID} \
+  --phase {Manual|Automation|Both} \
+  --outcome {OUTCOME} --bugs "{comma-separated bug IDs or empty}" \
+  --reuse {reuse % number, omit for manual-only runs}
+```
+
+This is a no-op unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never
+print anything about it, never retry, never treat a non-zero exit as a run failure.
+
 ---
 
 ## Post-run Cleanup (all phases)

package/claude/skills/qa-agent/toolkit/qa-toolkit.cjs

@@ -17,11 +17,35 @@
  */
 
 const fs = require('fs');
+const os = require('os');
 const path = require('path');
 const crypto = require('crypto');
 const { spawnSync } = require('child_process');
 
 const ROOT = process.cwd();
+
+// ── .env loading ─────────────────────────────────────────────────────────
+// Every doc in the pack tells users to put QA_* config in `.env`, but this is a
+// plain `node` script invoked by skills via Bash — nothing exports that file into
+// the environment, and the pack ships no dotenv. Without this, every
+// `process.env.QA_*` read below is permanently undefined and the features gated
+// on them (report-run, token tracking) are silent no-ops no matter what the user
+// configures. Real env vars always win, so an explicit `export` still overrides.
+function loadDotEnv() {
+  let raw;
+  try { raw = fs.readFileSync(path.join(ROOT, '.env'), 'utf8'); } catch { return; }
+  for (const line of raw.split(/\r?\n/)) {
+    const m = /^\s*(?:export\s+)?([A-Za-z_][A-Za-z0-9_]*)\s*=\s*(.*)$/.exec(line);
+    if (!m) continue; // blank line, comment, or malformed — skip
+    let val = m[2].trim();
+    // strip one layer of matching quotes; leave inner content untouched
+    if (val.length >= 2 && ((val[0] === '"' && val.endsWith('"')) || (val[0] === "'" && val.endsWith("'")))) {
+      val = val.slice(1, -1);
+    }
+    if (process.env[m[1]] === undefined) process.env[m[1]] = val;
+  }
+}
+loadDotEnv();
 const PRODUCT_CONTEXT_ROOT = path.join(ROOT, '.claude', 'skills', 'qa-agent', 'product_context');
 const OUTPUTS_DIR = path.join(ROOT, 'outputs');
 const TRUST_THRESHOLD = 5;
@@ -719,6 +743,109 @@ function cmdRoi(args) {
   );
 }
 
+// ── report-run: optional team dashboard reporting (git-based, silent opt-in) ──
+//
+// Mirrors the QA_TRACKING_DIR convention (see SKILLS_CONTEXT.md "Token Tracking"):
+// unset config = silent no-op, never mention it, never retry, never break the run.
+// When configured, pushes one JSON file per run to a shared GitHub repo via the
+// Contents API (a plain create — no local git commit/push in the calling repo, no
+// read-modify-write race with other teammates' concurrent runs).
+
+function gitConfigValue(key) {
+  const res = spawnSync('git', ['config', key], { cwd: ROOT, encoding: 'utf8' });
+  return res.status === 0 ? res.stdout.trim() : '';
+}
+
+function currentRepoName() {
+  const remote = spawnSync('git', ['remote', 'get-url', 'origin'], { cwd: ROOT, encoding: 'utf8' });
+  if (remote.status === 0 && remote.stdout.trim()) {
+    return remote.stdout.trim().replace(/\.git$/, '').split(/[/:]/).pop();
+  }
+  return path.basename(ROOT);
+}
+
+async function cmdReportRun(args) {
+  const repo = process.env.QA_DASHBOARD_REPO;
+  const token = process.env.QA_DASHBOARD_TOKEN;
+  if (!repo || !token) return; // team dashboard not configured — silent no-op
+
+  // Only --skill and --outcome are universal. Half the skills in the pack have no
+  // Jira card at all (impacted-tests, k6-framework-scaffold, test-charter, and
+  // roam-testing when run without one) and some have no product context, so
+  // requiring either would make "log every skill" impossible to satisfy.
+  requireArgs(args, ['skill', 'outcome']);
+
+  // No freeform --notes flag: only short, structurally-constrained values (product/card/
+  // phase/outcome/bug IDs) are safe to inline into the caller's shell command — see the
+  // "Never inline arbitrary text" rule in SKILLS_CONTEXT.md.
+  const payload = {
+    product: args.product || currentRepoName(),
+    card: args.card || null,
+    // One record per skill execution. `skill` is what ran (manual-testing,
+    // automation, ...); `phase` stays for backward compat with records already
+    // in the dashboard repo, defaulting to the skill name when a caller omits it.
+    skill: args.skill,
+    phase: args.phase || args.skill,
+    outcome: args.outcome,
+    bugsFiled: String(args.bugs || '').split(',').map((s) => s.trim()).filter(Boolean),
+    reusePct: args.reuse !== undefined ? parseFloat(args.reuse) : null,
+    date: args.date || todayStr(),
+    // Display name only — never user.email. The dashboard repo is public, so an
+    // email here is published permanently in git history; the "runs by teammate"
+    // panel only ever needs a label. QA_DASHBOARD_AUTHOR overrides.
+    author: process.env.QA_DASHBOARD_AUTHOR || gitConfigValue('user.name') || os.userInfo().username,
+    repo: currentRepoName(),
+    reportedAt: new Date().toISOString(),
+  };
+
+  // These land in a URL path, so restrict them to a safe charset rather than
+  // trusting the caller — a stray `/` or `..` in a product name would otherwise
+  // write outside runs/ in the dashboard repo.
+  const seg = (v, fallback) => String(v || fallback).replace(/[^A-Za-z0-9._-]/g, '-').replace(/^[.-]+/, '') || fallback;
+  const filePath = `runs/${seg(payload.product, 'unknown')}/${payload.date}-${seg(payload.card, 'no-card')}-${seg(payload.skill, 'skill')}-${crypto.randomBytes(4).toString('hex')}.json`;
+  const content = Buffer.from(JSON.stringify(payload, null, 2)).toString('base64');
+
+  const controller = new AbortController();
+  const timeout = setTimeout(() => controller.abort(), 5000);
+  try {
+    const res = await fetch(`https://api.github.com/repos/${repo}/contents/${filePath}`, {
+      method: 'PUT',
+      signal: controller.signal,
+      headers: {
+        Authorization: `Bearer ${token}`,
+        Accept: 'application/vnd.github+json',
+        'Content-Type': 'application/json',
+        'User-Agent': 'qa-pack-toolkit',
+      },
+      body: JSON.stringify({ message: `run: ${payload.product} ${payload.card}`, content }),
+    });
+    // A 401 (dead/expired PAT — fine-grained tokens cap at 1 year), a 404 (wrong
+    // QA_DASHBOARD_REPO, or a token without Contents:write) and a success are all
+    // indistinguishable if the status is never read. Stay silent on stdout so a
+    // broken dashboard can't derail a QA run, but always leave a trace on disk.
+    if (!res.ok) reportRunFailure(args, `HTTP ${res.status} ${res.statusText} — ${(await res.text().catch(() => '')).slice(0, 200)}`);
+    else if (args.verbose) console.log(`report-run OK → ${repo}/${filePath}`);
+  } catch (err) {
+    reportRunFailure(args, err && err.name === 'AbortError' ? 'timed out after 5s' : String(err && err.message || err));
+  } finally {
+    clearTimeout(timeout);
+  }
+}
+
+// Failure trail for report-run. stdout stays clean (the calling skill must never
+// print or retry), so the evidence goes to outputs/ — already gitignored — and to
+// stdout only under --verbose, which is how you verify a fresh PAT once.
+function reportRunFailure(args, detail) {
+  const line = `${new Date().toISOString()} report-run failed: ${detail}\n`;
+  if (args.verbose) console.log(line.trim());
+  try {
+    ensureDir(OUTPUTS_DIR);
+    fs.appendFileSync(path.join(OUTPUTS_DIR, 'report-run-errors.log'), line);
+  } catch {
+    // last resort: swallow — a dashboard problem must never fail a QA run
+  }
+}
+
 // ── dispatch ────────────────────────────────────────────────────────────
 
 function main() {
@@ -741,6 +868,7 @@ function main() {
     dashboard: cmdDashboard,
     digest: cmdDigest,
     roi: cmdRoi,
+    'report-run': cmdReportRun,
   };
   const handler = handlers[command];
   if (!handler) {
@@ -748,11 +876,11 @@ function main() {
       'Usage: qa-toolkit.cjs <command> [--flags]\n' +
       'Commands: list-products, get-bugs, get-runs, get-selectors, fingerprint, pii-scan, dup-bug,\n' +
       '          cost-estimate, risk-score, trust-record, trust-status,\n' +
-      '          locator-record, locator-query, dashboard, digest, roi'
+      '          locator-record, locator-query, dashboard, digest, roi, report-run'
     );
     process.exit(command ? 1 : 0);
   }
-  handler(args);
+  Promise.resolve(handler(args)).catch(() => {});
 }
 
 main();

package/claude/skills/roam-testing/SKILL.md

@@ -185,3 +185,22 @@ If yes: `Skill: test-charter`, pre-filled with the roam report path just saved.
 | A page 500s on load | Record as 🔴, do not retry, continue the loop |
 | Page cap hit with queue still non-empty | Stop cleanly, report `{visited} of {discovered}` coverage — never silently keep going |
 | `browser_network_requests` unavailable | Skip failed-request detection for that page, note it once in the report, continue |
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill roam-testing --product {PRODUCT_FOLDER} --card {CARD_ID, omit if none} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}"
+```
+A card is optional in this skill (Step 0 allows `skip`) — omit `--card` entirely when
+there isn't one rather than passing a placeholder. `report-run` takes only short, structurally-constrained values (product folder, card ID,
+skill name, outcome, bug IDs). It has no `--notes` flag — never inline freeform text such as
+a finding, a page title, or a bug description (see "Never inline arbitrary text" in
+`SKILLS_CONTEXT.md`).

package/claude/skills/test-charter/SKILL.md

@@ -298,3 +298,17 @@ TEST CHARTER PUBLISHED
   Published: [published_url or "URL not returned by API"]
   ✅ Uploaded to decision record
 ```
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill test-charter --outcome {Pass|Fail}
+```
+No product folder and no card — omit both flags.

package/claude/skills/ui-test-figma/SKILL.md

@@ -236,3 +236,18 @@ JIRA UPDATED
 ```
 
 Run `end + report + session` token close-out.
+
+---
+
+## Final Step — Report to team dashboard (optional, silent)
+
+Always the last action of the run, after everything else has printed. This is a no-op
+unless `QA_DASHBOARD_REPO`/`QA_DASHBOARD_TOKEN` are set in `.env` — never print anything
+about it, never retry, never treat a non-zero exit as a run failure.
+
+```
+node .claude/skills/qa-agent/toolkit/qa-toolkit.cjs report-run \
+  --skill ui-test-figma --card {CARD_ID, omit if none} \
+  --outcome {Pass|Fail|Partial} --bugs "{comma-separated bug IDs, or omit if none}"
+```
+Omit `--product` (no product folder in this skill) and omit `--card` when no card was given.

package/package.json

@@ -1,9 +1,10 @@
 {
   "name": "@roopesh.yadava/qa-pack",
-  "version": "1.5.1",
+  "version": "1.6.1",
   "description": "AI-powered QA agent skills for Claude Code — manual testing, BDD automation, accessibility, UI/Figma diff, bug reporting",
   "scripts": {
-    "postinstall": "node bin/postinstall.js"
+    "postinstall": "node bin/postinstall.js",
+    "test": "node --test test/"
   },
   "files": [
     "bin/",

package/templates/.env.example

@@ -24,3 +24,16 @@ JIRA_API_TOKEN=
 # ── Optional: model-tier recommendation for qa-agent (see SKILLS_CONTEXT.md) ──
 # recommend (default) | off | subagent (advanced — see "Model Routing" in SKILLS_CONTEXT.md)
 # QA_MODEL_ROUTING=recommend
+
+# ── Optional: team QA dashboard (shared, git-based, no server to host) ────────
+# Point at the shared dashboard-data repo ("owner/repo") + a fine-grained PAT
+# scoped to only that repo with Contents: Read and write access.
+# When either is unset, runs are skipped silently — nothing is sent anywhere.
+# Once set, EVERY skill reports its own execution as its last step.
+# Note: if the dashboard repo is public, everything below is published permanently
+# in its git history — product folder names, Jira card IDs, bug IDs and the author
+# label. The author label is git config user.name (never your email); override it
+# here if you'd rather publish something else, e.g. a first name or initials.
+# QA_DASHBOARD_REPO=your-org/qa-dashboard-data
+# QA_DASHBOARD_TOKEN=
+# QA_DASHBOARD_AUTHOR=