@groupby/ai-dev 0.5.20 → 0.5.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.20",
+  "version": "0.5.22",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {
@@ -15,7 +15,7 @@
   "scripts": {
     "prebuild": "rm -rf skills teams toolsets && cp -r ../skills ./skills && cp -r ../teams ./teams && cp -r ../toolsets ./toolsets",
     "build": "tsup",
-    "prepublishOnly": "npm run build",
+    "prepare": "npm run build",
     "test": "vitest run",
     "test:watch": "vitest",
     "test:coverage": "vitest run --coverage"

package/skills/README.md

@@ -4,7 +4,7 @@ This folder manages all skills, archived skills, and examples/instructions on us
 
 All skills in this `skills/library/` should represent _generally useful skills_ that might be used across teams.
 
-If any particular skill goes missing, note that it may have simply been archived (see [the archive](skills/archived/)) and may no longer be recommended for use. Ideally skills are not simply deleted from this repository, since others may be expecting them to be there.
+If any particular skill goes missing, note that it may have simply been archived (see [the archive](archived/)) and may no longer be recommended for use. Ideally skills are not simply deleted from this repository, since others may be expecting them to be there.
 
 ## Usage
 
@@ -58,4 +58,45 @@ license: Complete terms in LICENSE.txt
 See `docs/ai/skills/frontend-design/SKILL.md` and follow closely.
 ```
 
+## Third-party skills
+
+Skills authored outside the company can be vendored into a team's folder under
+`teams/<team>/third-party/<lib>/<skill>/`, each with the upstream `SKILL.md`
+(vendored verbatim at a pinned commit) plus a `skill-meta.yml` provenance
+sidecar. They are curated per team by evaluation status: `evaluating`,
+`recommended`, or `deprecated`.
+
+The lifecycle is fetch, vendor, evaluate, and promote:
+
+1. **Fetch + Vendor** in one step with the authoring command — paste a GitHub
+   URL to the skill folder and it writes the pinned `SKILL.md` plus a generated
+   `skill-meta.yml`:
+   ```bash
+   npx @groupby/ai-dev vendor <github-url> --team <team>
+   ```
+   Or do it manually: fetch into a scratch directory (for example,
+   `npx skills add <owner/repo> --copy`), then copy the single skill folder into
+   `teams/<team>/third-party/<lib>/<skill>/`, recording the source, pinned
+   commit, and `status: evaluating` in `skill-meta.yml`.
+2. **Evaluate** it in a real project with
+   `npx @groupby/ai-dev install skill <skill-name>` (naming a skill installs it
+   regardless of status).
+3. **Promote** it to `status: recommended` once proven, or graduate it into
+   `skills/library/` as a first-party skill (dropping the sidecar).
+
+A `recommended` third-party skill installs with its team like any other skill;
+`evaluating` and `deprecated` skills are held back from team installs unless you
+pass `--include-evaluating` or `--include-deprecated`. Naming a skill directly
+with `install skill <name>` always installs it. If a name is shared by more than
+one skill in the same tier (for example two teams that each vendored it), the CLI
+lists the matches and asks you to scope it with `install skill <team>/<name>` or
+`--team <team>`. See
+[content conventions](../docs/content-conventions.md) for the `skill-meta.yml`
+schema and the full rules.
+
+The `skill-meta.yml` sidecar is required. A vendored skill missing it has no
+provenance or status, so `list` shows it as `[no status] unknown source`, team
+installs skip it, and installing it by name still works but prints a
+`no recorded status` note. Add the sidecar to make it a fully curated skill.
+
 Note that we MUST include the skill boilerplate in any official skills location (eg. `.github/skills/`, etc.) to enable discovery and usage. We then copy the entire skill into `docs/ai/skills/` to leave it intact, though we don't technically need the boilerplate.

package/teams/rangers/third-party/mattpocock/grilling/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
+---
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+
+Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+
+Format a round like so:
+
+```
+❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+
+---
+
+❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+```
+
+Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
+
+Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+
+The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

package/teams/rangers/third-party/mattpocock/grilling/skill-meta.yml

@@ -0,0 +1,14 @@
+source: mattpocock/skills
+upstreamName: grilling
+pinnedCommit: 6654f6b60cd9d5be8b54c6fafe44346dabeb3b76
+vendoredOn: 2026-08-24
+status: evaluating
+agents: [copilot, claude, codex]
+reviewedBy: jasonwelsh
+notes: >-
+  Vendored verbatim from skills/productivity/grilling/SKILL.md. Upstream ships a
+  nested agents/openai.yaml alongside SKILL.md; it was dropped to keep the
+  vendored skill flat (the CLI installer copies top-level files only). Overlaps
+  the first-party rangers/team-phase-planning loop and the existing grill-me
+  skills in agentic-checkout and fhr-ai-team; evaluating whether grilling
+  replaces or is an explicit non-conflict before any promotion to recommended.

package/teams/snpd/qa-skills/README.md

@@ -0,0 +1,256 @@
+# SNPD Team — QA Skills
+
+A set of keyword-triggered skills that walk a Jira ticket through the full QA lifecycle — from ticket intake to a filed bug or a Qase-ready test suite — with a durable artifact at every stage.
+
+Each skill does one job, hands off a file, and stops. The human stays in control of every transition: no skill silently continues into the next, every open question surfaces in chat before any deliverable is written, and every artifact is saved next to the ticket so it can be audited later.
+
+## The pipeline
+
+```
+Jira ticket / Epic
+      │
+      ▼
+┌────────────────┐   writes  Tasks/{KEY}/{KEY}_Test_Plan.xlsx
+│ qa-test-plan   │ ────────▶ + {KEY}_Qase_Export.json
+└────────────────┘           (test cases with PR-diff findings + Qase-ready JSON)
+      │
+      ├─────────────► ┌────────────────┐   writes  Tasks/{KEY}/QA_Checklist.md
+      │               │ qa-checklist   │           (exploratory / regression pass)
+      │               └────────────────┘
+      │
+      ▼
+┌────────────────┐   writes  Tasks/{KEY}/{KEY}_<name>.postman_collection.json
+│ postman-qa     │ ────────▶ (SETUP + POSITIVE + REGRESSION + NEGATIVE
+└────────────────┘            + EDGE + KNOWN-BUGS + TEARDOWN)
+      │
+      ├─ fallback ─► ┌───────────────────────┐   writes  test_*.py + conftest.py + tests.yml
+      │              │ be-github-actions-qa  │           (pytest suite + CI job)
+      │              └───────────────────────┘
+      │
+      ├─ ui only ──► ┌───────────────────────┐   writes  *.spec.ts
+      │              │ fe-github-actions-qa  │           (Playwright E2E)
+      │              └───────────────────────┘
+      ▼
+   Test run
+      │
+      ├─ green ────► Qase import via {KEY}_Qase_Export.json
+      │
+      └─ red ─────► ┌────────────────────┐   verdict: test bug / product bug / env
+                    │ failed-test-triage │ ──┐
+                    └────────────────────┘   │
+                                             │ if product bug
+                                             ▼
+                                    ┌────────────────┐   writes  BUG_<slug>.md
+                                    │ bug-report     │ + BUG_REPRO_<slug>.postman_collection.json
+                                    └────────────────┘
+```
+
+`qa-test-plan` is the entry point and auto-invokes sub-skills via the Skill tool — never composes Postman / pytest / Playwright output from memory.
+
+## Skills
+
+### 1. `qa-test-plan` — plan the ticket
+
+- **Trigger** — any Jira key with testing intent (`S4R-11120`, `SNPD-4567`), or a Jira URL
+- **Reads** — the ticket via Atlassian MCP; every linked PR via the dev-status API + Chrome MCP `/files` tab; existing collections in `Tasks/`; the env file at `Tasks/gbiqa-lo.postman_environment.json`
+- **Produces** — `Tasks/{KEY}/{KEY}_Test_Plan.xlsx` and `Tasks/{KEY}/{KEY}_Qase_Export.json`
+- **Stops before** — writing any Postman / pytest / Playwright output (offers those in the next message)
+
+The orchestrator. Asks a scope question upfront (**Epic mode** — parent Epic + every related ticket, comments and statuses / **single-ticket mode** — this ticket + its comments + directly linked "relates to" issues), then does a mandatory PR review for every ticket in scope. Multiple PRs per ticket (follow-ups, optimisations) are all read. Every open question is posted in chat as one numbered list before the Excel is generated.
+
+Excel includes a Summary sheet with the code-review findings, a Setup sheet naming which entities SETUP must create, and one row per TC. Qase JSON export is Qase-import-ready and produced at the end of the automation cycle for suite creation.
+
+**Key rules:**
+- Reviews the PR of the ticket via dev-status API + Chrome MCP — Jira MCP never exposes PR URLs directly
+- If the repo requires SSO, stops and asks the user to log in — never guesses
+- **Rule #2a — reused-method regression trap:** a shared method invoked from a new caller sees a broader input surface. Every new input dimension gets its own TC
+- Asks upfront whether a Qase suite already exists — if it does, references those case IDs in the Excel's `Automation` column and skips duplicating
+- Never generates Postman without a working curl for every endpoint (or a verbatim body from an existing collection in `Tasks/`)
+- After the Excel, the very next message offers Postman — never pytest as default
+- After Postman, a Manual Check Guide is posted inline: env to select, run order, per-TC verification steps, GCP filter, cleanup confirmation
+
+### 2. `qa-checklist` — scoped manual pass
+
+- **Trigger** — "checklist for [ticket]", "exploratory test", "regression checklist"
+- **Reads** — the Jira ticket via Atlassian MCP
+- **Produces** — a sectioned markdown checklist (pre-conditions / functional / negative / engine coverage / regression / logging / automation coverage / sign-off)
+- **Stops before** — any automation work
+
+Fast, scoped checklist for exploratory or regression sessions. Not a replacement for `qa-test-plan` — used when a full test plan would be overkill (config change, small bug fix, quick regression pass). Adapts sections to ticket type (feature vs. bug fix vs. config).
+
+**Key rules:**
+- Cross-references existing Qase cases in the automation section
+- Adjusts engine coverage (VERTEXAI / RZLV) only if the ticket touches search/filter behaviour
+
+### 3. `postman-qa` — write the tests
+
+- **Trigger** — auto-invoked by `qa-test-plan` (Step 7a); also on "write pm.test", "fix Postman request", "generate collection"
+- **Reads** — the env file (`gbiqa-lo.postman_environment.json` or `gbiqa.postman_environment.json`); existing collections in `Tasks/`; the working curls the user provided
+- **Produces** — `Tasks/{KEY}/{KEY}_<name>.postman_collection.json`
+- **Stops before** — running the collection (that's manual via Runner or Newman)
+
+Every collection self-seeds: SETUP creates rules / attributes / filter sets and stores IDs in env vars; POSITIVE / REGRESSION / NEGATIVE / EDGE / KNOWN-BUGS folders reference those vars; TEARDOWN deletes everything (idempotent). Every SETUP body uses a shared `run_ts` (`Date.now()` in `pm.environment`) so re-runs never collide.
+
+**Key rules:**
+- **#0** Check `Tasks/{KEY}/` for an existing collection before creating a new one
+- **#1** Read the env file first. Variable names are exact: `{{bearer_token}}` (not `bearerToken`), `{{ccapi_customer_id}}` for numeric CCAPI path IDs (`{{areaId}}` does not exist)
+- **#2** `pm.environment.get/set`, never `pm.collectionVariables`
+- **#3** URL as a plain string in collection JSON, not object form
+- **#4** Integer variables must not be quoted in JSON body
+- **#5** Dynamic bodies via `pm.request.body.raw`
+- **#6** CCAPI PATCH takes the full attribute object from GET and modifies minimally — never a delta
+- Every test script includes the GCP log helper (prints correlation IDs for Logs Explorer lookup)
+
+### 4. `be-github-actions-qa` — pytest + CI fallback
+
+- **Trigger** — "write pytest for X", "add suite to CI", "why did CI fail"; also auto-invoked by `qa-test-plan` when Postman can't cover the case cleanly
+- **Reads** — the target file in `bs-qa-automation`, existing `conftest.py`, `.github/workflows/tests.yml`
+- **Produces** — `test_*.py`, updates to `conftest.py` (new marker), updates to `tests.yml` (new job / matrix entry)
+- **Stops before** — pushing / opening a PR
+
+Used only when Postman can't cover the case cleanly — multi-step data seeding beyond Postman scripting, GCP log verification, DB query-count checks, cross-service orchestration, or scheduled CI runs.
+
+Code patterns it produces: minimal test skeleton with fixtures, teardown, engine parametrization (`VERTEXAI` + `RZLV` in one test via `@pytest.mark.parametrize`), polling with timeout, full lifecycle (create → poll-verify → delete), and `@pytest.mark.known_bug` for product defects tracked in code.
+
+**Key rules:**
+- 5-step workflow: clarify → write test → register marker in `conftest.py` → add suite to `tests.yml` → give the exact local run command
+- Never invents markers or fixture names — asks if unclear
+
+### 5. `fe-github-actions-qa` — Playwright E2E
+
+- **Trigger** — "write Playwright test for X", "add UI test", "automate this UI flow"
+- **Reads** — existing specs in `brainstudiolower`, navigation helpers, `data-testid` map (or a screenshot the user provides)
+- **Produces** — `*.spec.ts` matching the repo's structure
+- **Stops before** — pushing / opening a PR
+
+Commerce Console UI tests: Rules, Facets, Areas, Zones, Redirects, Filter Sets, Site Management, Tag Management.
+
+**Key rules:**
+- Uses the repo's mandatory import pattern — no ad-hoc `@playwright/test` imports
+- Never navigates by raw URL — uses the navigation helper
+- Locator preference: `data-testid` > role > text > CSS. Never nth-child, never generated class names
+- Test name matches the Qase case ID when applicable
+- Asks for a screenshot or `data-testid` if a selector is unknown — never invents
+
+### 6. `bug-report` — file the defect
+
+- **Trigger** — "write a bug", "file a bug", "is this a bug?"; also auto-invoked by `failed-test-triage` when the verdict is product bug
+- **Reads** — the raw observation (response, log, screenshot, description), plus the ticket if one is linked
+- **Produces** — `BUG_<short_title>.md` (in `Tasks/{KEY}/` if linked, workspace root if exploratory) and, when applicable, `BUG_REPRO_<short_title>.postman_collection.json` (2–4 requests, minimum needed to reproduce)
+- **Stops before** — filing to Jira (that's manual — the file is the paste-ready payload)
+
+**Format (strict):**
+- Title with engine/scope prefix only if it applies — e.g. `[Google Search]`, `[Mongo Browse]`, `[Google Browse]`, `[Mongo+Google]`. No prefix if the bug applies everywhere or scope is unclear
+- Title line in body wrapped in `_italic_`
+- Section labels bold: `**Severity:**`, `**Reproduction rate:**`, `**Summary:**`, `**Notes:**`, `**Steps:**`, `**Expected result:**`, `**Actual result:**`, `**Found in:**`
+- Steps numbered, one action per line, precise enough for a dev who has never seen the flow
+- Actual result quotes the response / log **verbatim** — never paraphrased
+- Reproduction rate: `100%` / `intermittent (~X/10)` / `once`
+- Severity S1–S4 per guide
+- Environment paragraph names env, GCP env impact, cache header state, tenant
+
+**Key rules:**
+- Never invents error messages or field names — copies verbatim from the actual response
+- Repro collection is minimal — 2–4 requests, not the whole test flow
+
+### 7. `failed-test-triage` — diagnose the failure
+
+- **Trigger** — pasted failure output, "why is this failing", "tests are red in CI", "fix this test"
+- **Reads** — the assertion / traceback / Newman output; correlation IDs; the env state if unclear
+- **Produces** — a verdict in chat (test bug / product bug / env issue) + either a fix (test bug) or a `bug-report` handoff (product bug)
+- **Stops before** — filing a bug (that's `bug-report`'s job)
+
+Wrong diagnosis wastes days, so the skill forces an explicit hypothesis before touching anything. Flow: read the failure carefully → state hypothesis out loud → ask clarifying questions if evidence is missing → reach a verdict.
+
+**Key rules:**
+- Never says "flaky, rerun" without evidence
+- MongoDB vs Search results mismatch has its own playbook — check the MongoDB pipeline first, then compare with search response
+- Env checklist: auth token freshness, area/collection existence, LaunchDarkly flag state, tenant
+
+## How the skills connect
+
+### Artifact flow
+
+```
+Jira ticket / Epic
+      │
+      │  qa-test-plan
+      ▼
+Tasks/{KEY}/{KEY}_Test_Plan.xlsx      ◄── test cases + PR-diff findings
+Tasks/{KEY}/{KEY}_Qase_Export.json    ◄── ready for Qase import
+      │
+      │  postman-qa
+      ▼
+Tasks/{KEY}/{KEY}_<name>.postman_collection.json  ◄── SETUP + tests + TEARDOWN
+      │
+      │  test run (Runner or Newman)
+      ▼
+   red? ─── failed-test-triage ─── product bug? ─── bug-report ─── BUG_<slug>.md
+                                                                   BUG_REPRO_<slug>.postman_collection.json
+   green? ─ Qase import via {KEY}_Qase_Export.json
+```
+
+All artifacts live in `Tasks/{TICKET-KEY}/` in the workspace — never scattered.
+
+### Separation of concerns
+
+| Boundary | Meaning |
+|---|---|
+| Ticket ≠ Plan | The ticket says what changed; the plan decides what to cover |
+| Plan ≠ Tests | The Excel names the TCs; the collection scripts them |
+| Tests ≠ Verdict | A red run is not automatically a bug — `failed-test-triage` categorises it |
+| Verdict ≠ Bug | Product-bug verdict is the input to `bug-report`, not a filed bug |
+| File ≠ Import | Qase JSON export is created locally; Qase import is manual, at the end of the cycle |
+
+Each boundary is a human checkpoint. No skill silently rolls into the next.
+
+## Typical end-to-end run
+
+```
+"generate test plan for S4R-11120"     → qa-test-plan  →  Excel + Qase JSON
+"yes, generate the Postman collection" → postman-qa    →  SETUP + tests + TEARDOWN
+                                                          + Manual Check Guide in chat
+[run the collection in Postman Runner]
+"3 tests are red — see this output"    → failed-test-triage → verdict
+"file the bug"                         → bug-report    →  BUG_<slug>.md + repro
+[end of cycle]
+"import Qase JSON"                     → Qase suite created from {KEY}_Qase_Export.json
+```
+
+## Shared conventions
+
+- **Keyword-triggered.** Every skill fires on natural-language triggers — no `/slash-command` needed. Say "write a Postman collection for S4R-11120" and the right skill loads.
+- **Never guess.** Ask one clear question instead of inventing field names, locators, paths, or IDs.
+- **One message per batch of questions.** Every open question surfaces at once, not drip-fed across messages.
+- **Match existing structure.** Follow patterns already in the repo / collection — don't introduce new formats.
+- **English only** for all code, comments, and test names.
+- **Show only the relevant snippet** (fixed `pm.test` block, failing job step) — not full rewrites.
+- **Artifacts live next to the ticket.** All specs, plans, collections, and bug reports go under `Tasks/{TICKET-KEY}/`, never scattered in the workspace root.
+
+## Install
+
+Drop the skill folders into `.claude/skills/` in the target repo, or zip each as `<name>.skill` for the shared repo.
+
+```
+.claude/skills/
+├── qa-test-plan/          # includes references/
+├── qa-checklist/
+├── postman-qa/
+├── be-github-actions-qa/
+├── fe-github-actions-qa/
+├── bug-report/
+└── failed-test-triage/
+```
+
+Each folder contains `SKILL.md` with the full instructions and any supporting templates.
+
+## Requirements
+
+- **Atlassian MCP** — Jira fetch (`qa-test-plan`, `qa-checklist`)
+- **Claude in Chrome** MCP — PR review (dev-status API + PR `/files` tab)
+- **GitHub SSO login** in the browser — for private `groupby` repos
+- Access to `bs-qa-automation` (backend) and `brainstudiolower` (frontend) repos
+- Postman + Newman
+- `gbiqa` / `gbiqa-lower` credentials for Search API / CCAPI
+- Qase workspace access — for importing `{KEY}_Qase_Export.json`
+- GCP Logs Explorer access — for `[LOGGING]` TC verification