@groupby/ai-dev 0.5.17 → 0.5.19

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groupby/ai-dev",
-  "version": "0.5.17",
+  "version": "0.5.19",
   "description": "Interactive installer for Rezolve Ai development content",
   "type": "module",
   "bin": {

package/teams/OOF/skills/oof-release-impact-analysis/README.md

@@ -0,0 +1,37 @@
+# OOF Release Impact Analysis
+
+Generates a structured, human-reviewed **Release Impact Analysis** for a critical OOF
+release by correlating the git diff with the surrounding code, linked Jira tickets, and
+live operational signal (GCP Cloud Logging / BigQuery), then optionally publishes it to
+Confluence. Output is AI-generated decision-support and requires human sign-off.
+
+## What it does
+- Resolves the release range (last prod tag → release candidate, or a supplied `base..head`)
+  and gathers signal: diff + changed code and its call sites, linked Jira keys (revert-aware),
+  and — for critical releases — live cloud/outage status, GCP Cloud Logging, and BigQuery.
+- Classifies the blast radius (API/contract, DB/migrations, auth/security, infra/terraform,
+  per-region config, dependencies, cross-service, client compatibility, observability).
+- Produces a consistent, readable report: Found issues → Overview → Cross-service blast
+  radius → Risk assessment + Top risks → Suggested QA focus (non-technical) → Validation
+  performed → Unknowns; with optional Operational context, Pre-launch checklist, and an
+  Engineer detail appendix (`detail=engineer`).
+- Optionally publishes the report to Confluence.
+
+## Prerequisites
+- Read-only git access to the target repo (local clone or `glab` / `gh`).
+- For `depth=full` cloud signal: `gcloud` / `bq` authenticated to the target GCP project.
+- For `publish=confluence`: the Atlassian MCP connector connected.
+- An approved enterprise assistant (no-training / no-retention) — the skill's security
+  guardrails (never ingest secrets, cost-aware cloud access) must be met.
+
+## Inputs
+`repo`, `range`, `critical`, `depth` (`light` | `full`), `detail` (`summary` | `engineer`),
+`publish` (`confluence` | `none`), `gcp_project`.
+
+## Trigger phrases
+- "run impact analysis"
+- "release impact analysis"
+- "analyse this release before we ship"
+
+## Team
+OOF

package/teams/OOF/skills/oof-release-impact-analysis/SKILL.md

@@ -0,0 +1,310 @@
+---
+name: oof-release-impact-analysis
+description: 'Generate a structured Release Impact Analysis for a critical OOF release by correlating git changes with the surrounding code, linked Jira tickets, and live operational signal (cloud/outage status, GCP Cloud Logging, BigQuery), classify the blast radius, and optionally publish to Confluence. Use when the user says "run impact analysis", "release impact analysis", or before a critical release.'
+---
+
+# OOF Release Impact Analysis
+
+**Goal:** For a critical release, produce a structured, human-reviewed **Release Impact
+Analysis** that focuses QA, documents blast radius, and serves as SOC2 change-management
+evidence. The git diff is the *starting point*, not the whole picture — the analysis
+correlates the diff with the surrounding code, the linked Jira tickets, and **live
+operational signal** (cloud/outage status, GCP Cloud Logging, BigQuery) to judge real-world
+impact, not just what a static diff shows.
+
+**Your Role:** You are a release engineer performing change-impact analysis. You are
+precise and conservative: you never overstate confidence, you flag what you *cannot*
+determine from the available signal, and you treat the output as decision-support for a
+human reviewer — never as an automatic release gate.
+
+> ⚠️ AI-generated. This report assists a human decision. It must be reviewed and
+> signed off before it is relied upon. A release is never gated solely on this output.
+
+> 💰 **This deep, multi-source analysis is thorough but expensive** — it burns
+> engineer/agent time, LLM tokens, and real query cost (GCP Logging / BigQuery scanned
+> bytes). Run the **full** analysis only for **critical** releases, and **confirm depth up
+> front** (Step 0) rather than defaulting into it. Non-critical releases should use the
+> lightweight, git-only pass (`depth=light`, no cloud queries, no publish) — or skip the
+> analysis entirely.
+
+## Inputs
+
+- **repo** — Repository to analyse (defaults to the current workspace repo).
+- **range** (optional) — Git range `<base>..<head>`. If omitted, resolve it (see Step 1).
+- **critical** (optional) — Whether this is a critical release. Critical forces `depth=full`
+  **and** `detail=engineer`, and turns on the CDT-parity uplift (deployment/rollback
+  second-order analysis, per-risk severities, a mandatory **Required before production** gate
+  + go/no-go recommendation, and an exhaustive engineer-detail appendix).
+- **depth** (optional) — `light` (git + code only) or `full` (also pulls Jira, cloud/outage
+  status, GCP logs, BigQuery). Defaults to `full` when `critical`, else `light`.
+- **detail** (optional) — output verbosity: `summary` (default) or `engineer`. `engineer`
+  appends the **Required before production** gate and an **Engineer detail** appendix for
+  high-risk / infra-heavy releases; the readable summary stays on top either way. **Critical
+  releases force `engineer`.**
+- **publish** (optional) — `confluence` to publish the report, or `none` (default) to
+  only produce Markdown.
+- **gcp_project** (optional) — GCP project(s) to query for logs/BigQuery (e.g.
+  `bluedot-prod-ause1`). Required for `depth=full` cloud signal.
+
+## Security guardrails (MANDATORY — read before running)
+
+1. **Approved LLM only.** Run this only via an approved enterprise assistant with
+   no-training / no-retention terms. Do not paste diffs into ad-hoc consumer tools.
+2. **Never ingest secrets.** Exclude and never echo the contents of secret-bearing files.
+   Deny-list at minimum: `*.env`, `_config.*.env`, `*.pem`, `*.key`, `*credentials*`,
+   `*secret*`, `serviceAccount*.json`, terraform state, `*.tfvars`. If a diff touches one,
+   report **only the filename and that it changed** — never the values.
+3. **Least privilege.** Read-only git access. Do not push, tag, or modify anything.
+4. **Access-controlled output.** Publish only to an access-controlled Confluence space.
+   Do not expose internal implementation detail to a broad audience.
+5. **Cost-aware cloud access.** GCP Logging / BigQuery queries cost money and scan real
+   data. Always bound queries by the release time window + relevant service/resource, cap
+   scanned bytes, and prefer summaries/counts over dumping rows. Never run unbounded
+   `SELECT *`. Read-only only.
+6. **HALT** if you cannot confirm guardrails 1–2 for the current environment.
+
+## Signal sources (the diff is the starting point, not the whole picture)
+
+Git tells you *what text changed*; these sources tell you *what it actually affects and
+whether it is safe to ship now*. Use them according to `depth`:
+
+- **Git diff + history** (always) — changed files, churn, commit messages, linked tickets.
+- **Surrounding code** (always) — read the changed functions *and their call sites /
+  dependents* in the repo, not just the `+/-` lines, to judge real blast radius. A one-line
+  change to a shared helper can be higher impact than a large isolated feature.
+- **Linked Jira tickets** (`full`) — pull the `BD-xxxx` keys for intent, acceptance
+  criteria, and whether the change is a fix for a known incident.
+- **Cloud / outage status** (`full`) — is the platform currently healthy? Check GCP service
+  health and any ongoing SRE incidents for the target project/region. Releasing into an
+  active outage or degraded dependency raises risk and may warrant a hold.
+- **GCP Cloud Logging (Logs Explorer)** (`full`) — for the services touched, check recent
+  error rates / 5xx / notable log signatures so the analysis reflects the *current* prod
+  behaviour of the code being changed (bounded to a short window).
+- **BigQuery** (`full`) — where relevant (e.g. event/analytics tables), sample real volumes
+  or error patterns for the affected flow (bounded, capped-bytes, aggregate queries only).
+
+## Execution
+
+### Step 0: Confirm scope & depth (ask before spending)
+
+The full analysis costs real time and money, so **confirm depth up front** rather than
+silently defaulting into the expensive path. Unless the user has already specified, ask:
+
+- **Critical release?** The full multi-source pass is intended for critical releases only.
+- **Depth?** `full` — code + Jira + cloud/outage status + GCP Logging + BigQuery: thorough,
+  but burns agent time, LLM tokens, and **real GCP query charges** (Logging + BigQuery
+  scanned bytes). `light` — git + code only: fast and free, no cloud queries, no publish.
+- **Publish?** `confluence`, or Markdown-only (`none`).
+
+If the user defers, default to `full` + `detail=engineer` + publish when `critical`, else
+`light` + `none` — but **don't assume `full` for an unspecified release; ask first.**
+Non-critical releases use `light` or skip the analysis entirely. State the chosen depth (and
+why) at the top of the report.
+
+### Step 1: Resolve the release range
+
+- If `range` is given, use it.
+- Otherwise resolve `<base>` = most recent production tag/release, `<head>` = the release
+  candidate (target branch or RC tag). Prefer, in order:
+  - `git describe --tags --abbrev=0` on the last prod tag, or the last tag matching the
+    project's release pattern (e.g. semantic-release tags), through `HEAD`.
+- State the resolved `base..head`, both short SHAs, and the commit count. If you cannot
+  resolve it confidently, ask the user for the range and HALT.
+
+### Step 2: Gather signal (read-only)
+
+Gather from the sources above, without ever printing secret values. Scale effort to
+`depth`.
+
+**Always (both `light` and `full`):**
+- Changed files with status + churn: `git diff --stat <base>..<head>` and
+  `git diff --name-status <base>..<head>`.
+- Commit messages: `git log --no-merges --pretty='%h %s' <base>..<head>`.
+- Linked work items: Jira keys parsed from commit messages / branch names (e.g. `BD-\d+`).
+  **Revert-aware (critical):** a ticket only counts as *in the release* if its changes survive
+  in the **net** diff. When commits were reverted within the range (net ≠ history), verify
+  whether each ticket's files/content actually survive (e.g. a feature file added then deleted
+  is reverted). List reverted tickets **separately** as *reverted in-range (not shipped)* —
+  never imply reverted work is part of the release.
+- For non-secret files, inspect the diff **and the surrounding code / call sites** to judge
+  real blast radius. For deny-listed files, record filename + "changed (contents not
+  inspected)".
+
+**Additionally when `depth=full` (critical releases):**
+- **Jira:** read each linked ticket for intent / acceptance criteria / incident linkage.
+- **Cloud / outage status:** confirm the target project/region is healthy (GCP service
+  health + any ongoing SRE incidents). Note anything degraded.
+- **GCP Cloud Logging:** for each touched service, sample recent error/5xx signatures in a
+  bounded window (e.g. last 1–24h) for `gcp_project` — e.g.
+  `gcloud logging read '<filter> severity>=ERROR' --project <p> --freshness=24h --limit=50`.
+- **BigQuery:** where the change touches an event/analytics flow, run a bounded, aggregate
+  query (capped bytes, `--maximum_bytes_billed`) to sample real volume / error rate for the
+  affected path. Never `SELECT *` unbounded.
+- Record every source actually consulted (feeds the "Data sources consulted" report field).
+- If cloud access is unavailable or `gcp_project` is missing, note it as a gap and continue
+  with git+code+Jira signal only (do not fabricate cloud findings).
+
+### Step 3: Classify into impact areas (internal analysis)
+
+Bucket every change into the areas below. This classification is **internal** — it drives
+the report's `Found issues`, `Cross-service blast radius`, and the Overview `What changed`
+summary. Do **not** emit a standalone per-area "What changed" section (the report no longer
+uses one). For each touched area capture the concrete files/commits and a one-line "so what";
+note clean areas so their absence can be reflected in the risk assessment.
+
+- **API / contract changes** — swagger/openapi specs, route handlers, request/response
+  shapes. Flag anything **breaking** for consumers.
+- **Database / migrations** — schema changes, migration scripts, index changes,
+  destructive operations.
+- **Auth & security-sensitive** — `auth/`, `security/`, token/session logic, permissions,
+  crypto, dependency CVE-relevant bumps. Any change here raises the risk rating.
+- **Infrastructure** — terraform, Dockerfiles, CI/CD pipelines, service definitions.
+- **Config / environment** — per-region config (**AU / EU / US incl. DR**), feature flags,
+  env keys added/removed. Note if a change lands in some regions but not others.
+- **Dependencies** — `package.json` / lockfiles and other manifests; separate security
+  bumps from feature bumps; note major-version jumps.
+- **Cross-service blast radius** — shared patterns/libraries or contracts that other OOF
+  services depend on (a change here can affect repos outside this diff).
+- **Client backwards-compatibility** — impact on Android / native / web clients consuming
+  the changed contracts.
+- **Observability / operational** — logging, metrics, alerts, rollback affordances.
+- **Deployment & rollback effects (second-order)** — reason beyond *what code changed* to
+  *what the deploy does*: artifact/checksum changes that force a **new revision** even with no
+  logic change; provider/toolchain upgrades (e.g. Terraform / `google` provider pins) that can
+  cause **state or computed-field drift** → require a `terraform plan` review **per environment
+  incl. DR**; CI rules that don't match the release config (e.g. `hotfix/*` allowed in CI but not
+  in `.releaserc`) that can tag a build semantic-release later refuses to release; and whether
+  the change also gates the **rollback path** (e.g. an auth / Workload Identity migration that
+  affects deploy *and* rollback). These are the subtle, high-impact issues a raw diff misses —
+  always assess them on `full` / critical runs.
+
+### Step 4: Risk rating
+
+Assign an overall risk rating with a one-paragraph justification:
+
+- **Low** — isolated, non-breaking, well-tested, easy rollback.
+- **Medium** — touches a shared/contract surface OR config across regions OR notable deps.
+- **High** — breaking API, auth/security, DB migration (esp. destructive), or infra with
+  no clean rollback.
+
+Bias upward when auth/security, migrations, or cross-service contracts are involved, when
+you had to inspect deny-listed files by name only, or when **live signal is adverse** —
+e.g. an active outage / degraded dependency in the target region, or an elevated error rate
+in Cloud Logging for a service this release touches.
+
+**Critical releases (CDT-parity uplift):** tag **each Top risk with its own severity**
+(High / Med / Low), consolidate the concrete pre-production validations into a **Required
+before production** gate, and finish with an explicit **go/no-go recommendation** ("promote
+only after X, Y, Z pass"). Populate the **Engineer detail** appendix in full — exact
+versions/pins, **every** affected environment (incl. DR), and per-item failure mode +
+required validation. This mirrors the manual CDT analysis's audit-grade evidence trail and
+clear release gate.
+
+### Step 4b: Synthesise the findings
+
+From the classification + risk, distil a short **Found issues** list for the top of the
+report — **only realistic, critical items**; omit perfect-world / low-tier concerns (e.g.
+dev-only paths with no production impact, pre-existing standing gaps, or future / in-flight
+fixes). Favour: risky or changed semantics, real deploy/rollout hazards, security-relevant
+changes, and cross-service latent bugs. Each issue = a **bold one-line title** + a 1–3
+sentence description. If there are genuinely none, say so explicitly rather than padding.
+
+### Step 4c: Record what you verified
+
+Keep a running list of what you **actually checked** while analysing (e.g. "confirmed
+app/API/test paths identical via `git diff --name-status`", "confirmed dependency pin",
+"ran `git diff --check` (clean)", "verified WAF rules are `preview=true`"). This feeds the
+**Validation performed** section and, together with **Unknowns**, gives an auditable
+evidence trail — what was, and was not, confirmed.
+
+### Step 5: Produce the report
+
+Output this structure in Markdown, in this order (the layout must match the published
+report). Every section is required **except** the ones marked *[OPTIONAL]*: *Operational
+context* (include only if significant), and *Required before production* + *Engineer detail*
+(**required for critical releases**; otherwise include only when `detail=engineer`, or the
+release is high-risk / infra-heavy).
+
+```
+# Impact Analysis of Release — <repo> `<base>` → `<head>` (<short change summary>)
+
+## Found issues
+
+1. **<issue title>.** <1–3 sentence description of the issue and why it matters.>
+2. **<issue title>.** <...>
+   <If genuinely none: "No notable issues found — see Overview.">
+
+## Overview
+- **What changed:** <concise 1–2 sentence summary of the change and its intent>
+- **Repo / range:** `<repo>` `<base>` (`<sha>`) → `<head>` (`<sha>`) — <N> commits
+- **Changed:** <N> files, +<X> / -<Y> — `<file>` (+n), `<file>` (+m)
+- **Linked tickets (in this release):** <tickets whose changes survive in the net diff | none referenced>
+- **Reverted in-range (not shipped):** <tickets whose commits were reverted within the range — omit this line entirely if none>
+- **Depth:** <light|full> · **Data sources consulted:** <git, code, jira, outage-status, gcp-logs, bigquery> · **Not consulted:** <sources skipped / unavailable>
+- **Overall risk:** **<LOW|MEDIUM|HIGH>** — <one-line reason>
+
+## Cross-service blast radius
+<shared patterns/contracts other OOF services depend on that this change (or the bug it
+fixes) also affects; "None identified" if isolated>
+
+## Operational context   [OPTIONAL — include ONLY if there is something significant to report]
+<Include this section only when live signal is material — e.g. an active outage, a degraded
+dependency, or a notable error/volume pattern in Cloud Logging / BigQuery for a touched
+service. If nothing significant (or live queries were not run), OMIT this section entirely
+and record the "not queried" fact under Unknowns instead.>
+
+## Risk assessment
+**<LOW|MEDIUM|HIGH>.** <justification paragraph; note if live signal changed the rating.>
+
+### Top risks
+<only material, realistic risks — omit perfect-world / low-tier concerns; for critical
+releases tag each with a severity — **High / Med / Low**>
+1. **<High|Med|Low>** — <...>
+2. **<High|Med|Low>** — <...>
+
+## Suggested QA focus
+<solely the QA / functional areas a non-coder QA reviewer should confirm — assume engineers
+have already completed their technical and infrastructure checks. Concise, plain-language, no
+code or jargon. For a purely infra change with no user-facing effect, state what to confirm
+still works after go-live.>
+
+## Validation performed
+<short bullet list of what this analysis ACTUALLY checked / verified — the evidence behind the
+conclusions above. E.g. "confirmed app/API/test paths identical", "confirmed dependency pin",
+"ran git diff --check (clean)", "verified WAF rules are preview=true". Pairs with Unknowns.>
+
+## Unknowns / could not determine from available signal
+<explicit list — never leave this empty by guessing; include any source that was
+unavailable, e.g. "no GCP access — live cloud rates not checked">
+
+## Required before production   [REQUIRED for critical releases; else OPTIONAL — include when detail=engineer or high-risk / infra-heavy]
+<concrete boxes the release owner must tick before go-live — each naming the *validation*, not
+just the risk; cover auth/deploy, `terraform plan` per env incl. DR, artifact/revision
+expectations, CI vs `.releaserc` alignment, and that the **rollback path** still works under any
+changed auth>
+- [ ] <check 1 — e.g. production Workload Identity auth validated for all prod + DR projects>
+- [ ] <check 2 — e.g. `terraform plan` reviewed per env; no unexpected replace / delete / IAM change>
+
+**Recommendation:** **<GO | NO-GO / HOLD>** — <promote only after the named validations pass; one-line rationale.>
+
+## Engineer detail   [REQUIRED for critical releases; else OPTIONAL — include only when detail=engineer]
+<the exhaustive, engineer-grade specifics the summary above intentionally omits — **exact
+versions / pins**, **every** affected environment (incl. DR), per-item failure mode + required
+validation, and the deployment/rollback second-order effects (artifact/revision changes,
+provider state drift, CI-vs-`.releaserc` mismatch, rollback-path auth). Kept at the bottom so
+the summary stays readable for non-technical readers.>
+
+---
+*AI-generated by the `oof-release-impact-analysis` skill (BD-8139) · reviewer: TBD · <date> · decision-support only. Range `<base>..<head>`. Rerun with valid GCP credentials to populate live Operational context.*
+```
+
+### Step 6: Publish (only if `publish=confluence`)
+
+- Publish the report as a **child page** of the **Impact Analysis** folder page in the
+  **OOF Skills** folder: Confluence space **`BNM1`**, parent page id **`5915476067`**
+  (`https://rezolvetech.atlassian.net/wiki/spaces/BNM1/folder/5912657922/OOF+Skills` →
+  *Impact Analysis*). Use markdown format, page emoji 🚦. Page **title**:
+  `Release Impact Analysis — <repo> <base> → <head> (<summary>)`. The page **body** begins
+  with the `# Impact Analysis of Release — …` heading from the template above.
+- Add the Confluence page link back to the release Jira ticket.
+- Never publish if any guardrail check failed.

package/teams/dqm/skills/check-jenkins-build/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: check-jenkins-build
+description: Check Jenkins CI build status for current branch or PR and report merge readiness. Use for CI/build status and failed pipeline investigation. Requires Crownpeak Jenkins MCP and user confirmation when job path is ambiguous.
+---
+
+# Check Jenkins Build
+
+Requires Crownpeak Jenkins MCP:
+
+`https://github.com/Crownpeak/dqm-ai-tools/tree/main/jenkins-mcp`
+
+## Fast Path (Primary)
+
+1. Probe Jenkins MCP with `jenkins_list_jobs`.
+2. If probe fails, report the exact tool error and stop.
+3. Resolve branch: `git branch --show-current`.
+4. If `gh` is available and authenticated, check PR:
+
+```bash
+gh pr list --head <branch> --state open --json number,title,url
+```
+
+5. If PR exists, target `PR-<number>`.
+6. If PR does not exist, target URL-encoded branch name.
+7. If user expects a PR but none is found, ask for PR number directly.
+8. If `gh` is unavailable/unauthenticated, ask user whether to check branch or PR; if PR, ask PR number.
+9. Discover job candidates with `jenkins_list_jobs`.
+10. Validate candidate with `jenkins_get_latest_build`.
+11. If candidate path is not found, call `jenkins_get_job_info` on nearest existing path segment and refine.
+12. If multiple plausible paths exist, stop and ask user to confirm. Do not guess.
+13. Report target, job, build status, duration, and link.
+14. For in-progress builds, include elapsed time and current stage when available via `jenkins_get_build_status`.
+15. On failure, ask before pulling logs.
+16. If user agrees, call `jenkins_get_console_log` and show only first failure excerpt (<= 40 lines).
+
+## Report Template
+
+```text
+Target: <PR # or branch>
+Job: <resolved-job-path>
+Build: #<n> - ✅ SUCCESS | ❌ FAILURE | 🔄 IN_PROGRESS | ⏸ ABORTED (<duration>)
+Link: https://<jenkins-host>/job/<seg1>/job/<seg2>/.../<build>/
+```
+
+## Reference Notes (Secondary)
+
+- Branches with `/` in the name must be URL-encoded before using as Jenkins sub-jobs.
+- Jenkins foldered links require repeating `/job/<segment>/` for each path segment.
+- If branch has never been built, report that explicitly instead of generic failure.
+- If Jenkins MCP is not connected, suggest connecting it and running `/mcp`.
+- If access is denied for a job, report permissions issue and ask for alternate path or access.
+- Jenkins layout varies (top-level, foldered, multibranch); discover dynamically with `jenkins_list_jobs`.

package/teams/dqm/skills/create-pr/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: create-pr
+description: >-
+  Create or complete PRs to team standard: ticketed title, fully filled template
+  body, AI trailer, and "AI Assisted" label.
+---
+
+# Create PR
+
+## Fast Path (Primary)
+
+1. Find PR for the current branch:
+
+```sh
+gh pr view --json number,isDraft,title,body,url,baseRefName
+```
+
+2. If PR exists:
+  - Update it in place with `gh pr edit`.
+  - Keep `baseRefName` unchanged unless the user explicitly asks to change base.
+
+3. If PR does not exist, resolve effective base in this order:
+  - User-specified base branch.
+  - Repository default branch from:
+
+```sh
+gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
+```
+
+  - Topology candidate from:
+
+```sh
+git fetch --prune
+git log --oneline origin/<default-branch>..HEAD --decorate=short \
+  | grep -o 'origin/[^ ,)]*' | grep -v HEAD | sort -u
+```
+
+  - If one non-default candidate is found, use it as the candidate base.
+  - If candidate is non-default, ask the user to confirm.
+  - Verify chosen base exists on `origin`; if missing, fall back to `<default-branch>` and report fallback.
+
+4. Build title as `<TICKET>: <short description>`.
+  - Ticket source: spec Ticket field or branch name (for example, `feature/OCD-1234/...`).
+  - If no ticket is found, ask user; do not invent one.
+  - Keep description concise; put detail in body.
+
+5. Build PR body from repository template in this order:
+  - `.github/pull_request_template.md`
+  - `.github/PULL_REQUEST_TEMPLATE.md`
+  - `.github/PULL_REQUEST_TEMPLATE/*`
+  - platform default if none exists
+
+6. Fill every template section truthfully (no placeholders). Append this exact final line:
+
+```text
+🤖 - Assembled by AI
+```
+
+7. Write body to a temp file and apply:
+
+```sh
+gh pr edit <number> --title "<TICKET>: <short description>" --body-file <path>
+gh pr create --title "<TICKET>: <short description>" --body-file <path> --base <effective-base>
+```
+
+8. Ensure `AI Assisted` label exists, then apply to PR:
+
+```sh
+gh label list --search "AI Assisted" --json name --jq '.[].name'
+gh label create "AI Assisted" --description "AI created PR" --color fcd119
+gh pr edit <number> --add-label "AI Assisted"
+```
+
+9. If Jira skills are available, offer to post PR URL comment:
+
+```text
+**PR:** [<PR title>](<PR URL>)
+
+🤖 **Posted by (AI)**
+```
+
+## Command Reference (Secondary)
+
+- Never merge the PR.
+- Keep draft state as-is unless user asks to change it.
+- Keep existing PR base unchanged unless user asks.
+- Do not assume `main`; always resolve repository default branch.
+- Use `--body-file` for body updates/creation to avoid quoting issues.
+
+## Done
+
+Report PR URL and confirm all:
+- title format is correct
+- template sections are fully filled
+- trailer line is present
+- `AI Assisted` label is applied

package/teams/dqm/skills/dqm-implementation-plan/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: dqm-implementation-plan
+description: >-
+  Produce a structured DQM implementation plan from assembled ticket context or
+  any written source. Handles scope determination, NNNN folder naming, clarifications,
+  architecture scan, phased checklists, and DQM-specific next steps. Typically
+  invoked by dqm-jira-plan but can be used standalone with any source material.
+---
+
+# DQM Implementation Plan
+
+Self-contained. Produces planning files in `docs/planning/` following DQM conventions.
+
+## Input
+
+One of:
+- Assembled context passed from `dqm-jira-plan`
+- A path to an existing document
+- Inline notes or requirements pasted into the conversation
+
+## Defaults
+
+| Setting | Value |
+|---------|-------|
+| Project | `OCD` |
+| Team | `Tardigrades` |
+| Product Line | `DQM` |
+
+## Fast Path
+
+1. **Determine scope:**
+   - Small (1–3 tasks, single concern): single file `docs/planning/<name>.md`
+   - Larger (4+ tasks or cross-cutting): folder `docs/planning/<name>/`
+
+2. **Choose name:** list `docs/planning/`, find the highest existing 4-digit prefix, increment by 1 (start at `0001` if none exist). Pattern: `{NNNN}-{ticket-key-lowercase}-{short-slug}`. Short slug = 2–4 kebab-case words from the summary. Confirm with user if ambiguous; use user-supplied name verbatim if provided.
+
+3. **Scan architecture docs:**
+   - Read `docs/architecture/` — at minimum the README and any file relevant to the task. Note the gap if absent.
+   - Read the project's framework/dependency constraint documentation (e.g. `AGENTS.md`, `CLAUDE.md`, or equivalent) before proposing any concrete type, API, or library construct.
+   - For any dependency or framework version that may post-date the model training window, verify the API exists in that version before naming it in the plan — do not rely on training data for version-specific details.
+   - If the project provides a docs-fetching skill for the framework in use, invoke it. Otherwise use `WebFetch` or `WebSearch` against the library's official docs.
+   - A plan that names the wrong type propagates the mistake to every downstream agent.
+
+4. **Scan existing plans:** check `docs/planning/` for related plans. Note any this plan relates to or supersedes.
+
+5. **Write clarifications:** surface ambiguities from the source with assumed answers. See Clarifications Template below. Write the file immediately and proceed to the plan without stopping.
+
+6. **Write plan:** include all required sections (see Plan Output Templates below). Always include:
+   - Architecture context citing specific files from `docs/architecture/`
+   - Decisions (including those inherited from clarifications)
+   - Open questions that could not be assumed away
+   - Phased checklist with testing and documentation steps
+   - Per-task detail: exact files to create/modify, patterns to follow, edge cases, test requirements
+   - DQM next steps:
+     - Update OCD ticket status to In Progress
+     - Add comment to ticket linking to `docs/planning/<name>/`
+     - Create Jira subtasks for each phase if Tardigrades team tracks at that level
+
+## Reference Notes
+
+### Clarifications Template
+
+```markdown
+# Clarifications: {TICKET-KEY} — {Summary}
+
+Ambiguities identified before planning. Override any ANSWER: line and ask for the plan to be updated.
+
+---
+
+### 1. {Short question title}
+
+{Why this is ambiguous.}
+
+ANSWER: {Assumed answer with brief reasoning.}
+```
+
+### Plan Output Templates
+
+**Single file** (`docs/planning/<name>.md`):
+
+```
+# <Title>
+
+<One-paragraph summary of what this plan accomplishes and why.>
+
+## Source
+## Architecture context
+## Decisions
+## Open questions
+## Implementation checklist
+## Detail (per task)
+## Next steps
+```
+
+**Folder** (`docs/planning/<name>/`):
+
+```
+README.md          # intent, source, links to plan/
+clarifications.md
+plan/
+  README.md        # decisions, checklist, links to sub-plans
+  <sub-plan-1>.md
+  ...
+```
+
+### Edge Cases
+
+- No `docs/architecture/`: note gap in plan; suggest creating it as follow-up.
+- Source has no acceptance criteria: proceed with summary + comments; note gap in clarifications.
+- Conflicting decisions in source: surface each as an open question.
+- User disagrees with a clarification assumption: edit the `ANSWER:` line and ask for the plan to be regenerated.

package/teams/dqm/skills/dqm-jira-plan/README.md

@@ -0,0 +1,33 @@
+# dqm-jira-plan
+
+Generate an implementation plan starting from a DQM Jira ticket (`OCD-XXXX`). Fetches the full ticket context — epic hierarchy, acceptance criteria, subtasks, linked issues, recent comments, and linked Confluence pages — then produces a structured plan inline using the `implementation-plan` format.
+
+## Requirements
+
+Prefers `atlassian-rovo` MCP — no setup needed if it's available in your environment.
+
+**REST API fallback:** set these environment variables when MCP is unavailable:
+
+```sh
+export JIRA_EMAIL=your.email@example.com
+export JIRA_API_TOKEN=<token from https://id.atlassian.com/manage-profile/security/api-tokens>
+```
+
+The skill connects to `https://attraqt.atlassian.net` by default. The same credentials cover both Jira and Confluence.
+
+## Example prompts
+
+- `/dqm-jira-plan OCD-1234`
+- "Plan the implementation for OCD-567"
+- "Create a plan from ticket 1234" *(bare number resolves to OCD-1234)*
+
+## DQM context
+
+- Project key: `OCD-XXXX`
+- Product line filter: `"Crownpeak Product Line" = DQM`
+- Assigned team: Tardigrades
+
+## Related
+
+- [`jira-plan`](../../../../skills/library/jira-plan/) — the library version of this skill; requires Atlassian MCP and delegates to `implementation-plan`
+- [`implementation-plan`](../../../../skills/library/implementation-plan/) — use directly when you have ticket details but no Jira access

package/teams/dqm/skills/dqm-jira-plan/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: dqm-jira-plan
+description: >-
+  Fetch a DQM Jira ticket from attraqt.atlassian.net and assemble full context,
+  then delegate to dqm-implementation-plan to produce the plan. Prefers Atlassian
+  MCP (atlassian-rovo); falls back to REST API with JIRA_EMAIL + JIRA_API_TOKEN.
+  DQM tickets use OCD-XXXX.
+---
+
+# DQM Jira Plan
+
+Fetches ticket context and delegates planning to `dqm-implementation-plan`.
+
+## Defaults
+
+| Setting | Value |
+|---------|-------|
+| Project | `OCD` — bare numbers resolve to `OCD-N` |
+| Instance | `https://attraqt.atlassian.net` (override with `JIRA_URL`) |
+| Team | `Tardigrades` |
+| Product Line | `DQM` |
+
+## Fast Path
+
+1. **Resolve key:** Full key → use directly. Bare number → prepend `OCD-`. Try git branch (e.g. `OCD-1234-slug` → `OCD-1234`). Unknown → ask user. Non-OCD key → proceed as-is and note deviation.
+2. **Connectivity:**
+   - MCP available (`atlassian-rovo`): use MCP tools for all calls.
+   - MCP unavailable: verify `JIRA_EMAIL` + `JIRA_API_TOKEN` are set. If missing, stop — see missing credentials message in Reference Notes. All REST calls target `${JIRA_URL:-https://attraqt.atlassian.net}`.
+3. **Fetch ticket:** `jira_get_issue(issue_key="{TICKET-KEY}")`. Extract: summary, description, status, assignee, priority, story points, acceptance criteria (`customfield_10016` or field containing "acceptance"), issue type, Team field, Crownpeak Product Line field. Flag if Team ≠ `Tardigrades` or Product Line ≠ `DQM`.
+4. **Fetch subtasks:** `jira_search(jql="parent = {TICKET-KEY} ORDER BY status ASC, priority DESC")`
+5. **Fetch linked issues:** extract from `fields.issuelinks` in the issue response.
+6. **Fetch comments:** last 10, most recent first. REST: see Reference Notes.
+7. **Fetch epic context:**
+   - Detect: `fields.parent` (issuetype = Epic) or `fields.customfield_10014`.
+   - If found: fetch epic summary/description; fetch siblings: `jira_search(jql='"Epic Link" = {EPIC-KEY} AND "Crownpeak Product Line" = DQM AND key != {TICKET-KEY} ORDER BY status ASC, priority DESC')`. If JQL fails on that field, drop the filter and retry.
+   - Large epics (20+ siblings): summarise; focus on In Progress and To Do.
+   - No epic: note as orphaned and continue.
+8. **Fetch Confluence pages:** get remote links from issue (`/rest/api/3/issue/{TICKET-KEY}/remotelink`); filter for `atlassian.net/wiki` URLs; fetch each page truncated to ~500 words. Extract page ID from URL path after `/pages/`. MCP: `confluence_get_page(page_id="{PAGE_ID}")`. If 403/404: include title + URL only.
+9. **Delegate to `dqm-implementation-plan`:** pass the assembled context as source material. The ticket key becomes the story name (e.g. `ocd-1234`) unless the user specified otherwise.
+
+## Reference Notes
+
+### REST Fallback Commands
+
+Base: `curl -s -u "$JIRA_EMAIL:$JIRA_API_TOKEN" -H "Content-Type: application/json" "${JIRA_URL:-https://attraqt.atlassian.net}"`
+
+| Data | Path |
+|------|------|
+| Issue | `/rest/api/3/issue/{TICKET-KEY}` |
+| Subtasks | `/rest/api/3/search?jql=parent+%3D+{TICKET-KEY}+ORDER+BY+status+ASC` |
+| Comments | `/rest/api/3/issue/{TICKET-KEY}/comment?maxResults=10&orderBy=-created` |
+| Remote links | `/rest/api/3/issue/{TICKET-KEY}/remotelink` |
+| Confluence page | `/wiki/rest/api/content/{PAGE_ID}?expand=body.view` — extract `body.view.value`, strip HTML tags |
+
+### Missing Credentials Message
+```
+Missing Jira credentials. Please set:
+  export JIRA_EMAIL=your.email@example.com
+  export JIRA_API_TOKEN=<token from https://id.atlassian.com/manage-profile/security/api-tokens>
+```
+
+### Edge Cases
+
+- Ticket not found (404): report clearly; may be moved, deleted, or inaccessible.
+- Non-OCD key: proceed as-is; note deviation from standard DQM project.
+- No description: proceed with summary + comments; note gap in clarifications.
+- Conflicting decisions in comments: pass them as open questions in the assembled context.
+- `"Crownpeak Product Line"` JQL not searchable: drop filter, retry, note fallback.

package/teams/dqm/skills/promote-to-harness/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: promote-to-harness
+description: Promote an approved harness candidate into `coding-guidelines.md`, `AGENTS.md`, or `.github/copilot-instructions.md` to prevent repeat AI mistakes.
+---
+
+Add one rule at a time to the correct harness file.
+
+Do not edit harness files until the user confirms both rule text and target file.
+
+## Harness file responsibilities
+
+- `coding-guidelines.md`: coding patterns, naming, Java/Spring conventions, test strategy.
+- `AGENTS.md`: workflow, TDD, packaging, release, AWS, pipeline constraints.
+- `.github/copilot-instructions.md`: quick inline Copilot constraints.
+
+When in doubt: technical rule -> `coding-guidelines.md`; process rule -> `AGENTS.md`.
+
+## 1. Receive the candidate
+
+Accept one candidate with all required fields:
+- issue description
+- proposed rule text (one imperative sentence)
+- target file (one of the three above)
+- source (PR/comment/reference)
+
+If any field is missing, ask before proceeding.
+
+## 2. Check for duplicates
+
+Read the target harness file and check whether an equivalent rule already exists.
+
+- Match found: quote existing text and ask whether to refine instead of adding.
+- No match: proceed.
+
+## 3. Propose placement
+
+Identify section and exact insertion point, then show:
+- Section
+- Position (after line N / anchor text)
+- Proposed addition (`- <rule text>`)
+
+Ask for confirmation before writing.
+
+## 4. Apply
+
+On confirmation, insert the rule into the target file at the agreed position.
+
+Prefer appending to an existing relevant list; keep surrounding style.
+
+## 5. Confirm and summarise
+
+Report:
+
+- file and section updated
+- rule text as written
+- source reference
+
+Suggested commit message:
+`docs: (<JIRA-KEY>) promote harness rule from <source>` (when available), otherwise `docs: promote harness rule from <source>`

package/teams/dqm/skills/publish-pr/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: publish-pr
+description: >-
+  Publish a draft PR for review: verify it's review-ready (description in sync with
+  the Jira ticket and the actual diff, no unchecked checklist items, reviewed by an AI
+  agent with no open agent comments), take it out of draft, and announce it in the team
+  Slack channel. Use when the user says "publish/release this PR", "take the PR out of
+  draft", or invokes /publish-pr.
+---
+
+# Publish PR
+
+Stages run in order: **verify → un-draft → announce**. Verify is blocking: if any check fails, report
+all results and STOP — do not un-draft or post. Continue only if the user says "publish anyway".
+Never merge; never change the base.
+
+## 1) Locate
+
+```sh
+gh pr view --json number,isDraft,title,body,url,baseRefName,headRefName
+```
+
+No PR → stop, suggest `create-pr`. Resolve ticket (`OCD-XXXX`) from title/branch; if none, ask.
+
+## 2) Verify (BLOCKING — run all, report together)
+
+- **a. PR-body checklist** — no unticked `- [ ]` in the PR description (unless user marked one N/A).
+- **a2. Spec/plan checklists** — for any spec/planning doc in this PR's diff (`specs/**`,
+  `docs/planning/**`), no unticked `- [ ]` remains; these track the story's ACs/phases. List file+line of any.
+- **b. Jira sync** — fetch ticket from `attraqt.atlassian.net` (Atlassian MCP; fall back to REST with
+  `JIRA_EMAIL`+`JIRA_API_TOKEN`). Fail if PR claims scope the ticket lacks, omits a stated AC, or
+  summaries materially disagree. Wording differences are fine.
+- **c. Diff sync** — `gh pr diff <number>`. Fail if the body describes work absent from the diff, or
+  the diff makes significant changes the body never mentions.
+- **d. AI review** — PR must have ≥1 AI-agent review and no unresolved threads it started. Agent =
+  reviewer login like `copilot-pull-request-reviewer[bot]`, `Copilot`, or a clearly-review `[bot]`.
+
+  ```sh
+  gh pr view <number> --json reviews --jq '.reviews[] | {author:.author.login, state:.state}'
+  gh api graphql -f query='query($o:String!,$r:String!,$p:Int!){repository(owner:$o,name:$r){
+    pullRequest(number:$p){reviewThreads(first:100){nodes{isResolved comments(first:1){nodes{author{login}}}}}}}}' \
+    -F o=<owner> -F r=<repo> -F p=<number>
+  ```
+
+  Fail (and list specifics) if no agent review exists — request one via `request_copilot_review` —
+  or if any thread whose first comment is by an agent has `isResolved:false`.
+
+## 3) Un-draft (only after all pass)
+
+```sh
+gh pr ready <number>
+```
+
+Already non-draft → note it, continue.
+
+## 4) Announce in Slack
+
+No Slack tool → skip, report "published, Slack skipped (no connection)". Otherwise:
+
+1. Resolve `#tardigrades` (Crownpeak) via `slack_search_channels` (query `tardigrades`); if ambiguous, confirm with user.
+2. Compose a short message: **repo name**, **ticket title + key**, **PR link**, **1–2 line summary**.
+   Get the repo via `gh repo view --json name --jq .name`. Example:
+   ```text
+   :eyes: Ready for review — `dqm-scim-service` — *OCD-33443: GET /Users/{id}*
+   <PR_URL|#NN Add GET /Users/{id}>
+   Returns a single user by id; DELETE now 404s on unknown/cross-tenant.
+   ```
+3. Show the exact text + target channel and wait for explicit approval (revise + re-confirm on edits).
+4. Post with `slack_send_message` only after approval (or `slack_send_message_draft` if user prefers to send it).
+
+## Done
+
+Report: checks passed · PR now ready (or already was) · Slack posted to `#tardigrades` / skipped / not approved.

package/teams/dqm/skills/triage-pr-comments/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: triage-pr-comments
+description: Triage open PR review comments and return recommendations before any code/reply/git write actions.
+---
+
+Triage GitHub PR comments in analysis-only mode.
+
+## Operating mode (default)
+
+- No file edits.
+- No GitHub replies.
+- No `git add`, `git commit`, or `git push`.
+- Do not perform any write action unless explicitly approved by the user.
+- Do not auto-transition from triage to implementation; wait for explicit per-comment approval.
+
+Use `gh` when available. If `gh` is unavailable/unauthenticated, ask the user for PR link + comment context and continue manually.
+
+## 1) Build unresolved triage set
+
+Preferred source: review-thread metadata + issue-level comments.
+
+- Include review threads where:
+  - `isResolved == false`
+  - `isOutdated == false`
+- From each included thread, use only the latest comment as the actionable item.
+- Include issue-level PR comments that still require action.
+- Do not exclude bot authors.
+- De-duplicate by comment ID/URL.
+- Sort newest first by `updatedAt`/`updated_at`.
+
+If user asks for "today" or "recent", apply recency filter after unresolved-set construction.
+
+## 2) Classify each comment (exactly one)
+
+- `requires-code-change`
+- `requires-doc-change`
+- `explanation-only`
+- `needs-clarification`
+- `decline-with-reason`
+
+For each comment, capture:
+
+1. Assessment (request + validity)
+2. Proposed action (minimal code/doc/test change plan; no edits yet)
+3. Impact/risk (scope, regressions, dependencies)
+4. Verification plan (tests/lint/checks if implemented)
+5. Draft reply (concise, professional, technical refs in backticks)
+6. Harness candidate (optional):
+   - rule text (single imperative sentence)
+   - target file: `docs/coding-guidelines.md`, `AGENTS.md`, or `.github/copilot-instructions.md`
+
+Inline draft-reply protocol:
+- Start with `🤖 **(AI):**`
+- Use a factual/professional tone
+- If code change: what changed + why (1-2 sentences)
+- If no code change: clear technical reasoning, not acknowledgement-only text
+- Use backticks for technical references (`files`, `symbols`, `flags`, `variables`)
+
+## 3) Ambiguity rule
+
+If intent is ambiguous or multiple valid fixes exist, stop and ask user to choose:
+
+Comment <id> is ambiguous. Which direction should I take?
+1) <option-a>
+2) <option-b>
+3) <option-c>
+
+Do not guess.
+
+## 4) Return prioritized triage report
+
+Group by priority:
+
+- High: correctness/security/data loss/regression risk
+- Medium: behavior/test coverage/maintainability
+- Low: style/wording/non-functional nits
+
+For each comment, return:
+
+- ID + link/context
+- Classification
+- Decision: `implement` | `reply-only` | `clarify` | `decline`
+- Proposed change summary (no edits; specify code vs doc-only)
+- Draft reply
+- Verification commands (if implemented)
+- Harness candidate (rule + target file) or blank
+
+Also include totals:
+
+- comments by classification
+- decisions (`implement` / `reply-only` / `clarify` / `decline`)
+- harness candidate count by target file
+- open questions needing user input
+
+## 5) Ask for execution approval
+
+Ask exactly:
+
+1. Which comment IDs should be implemented now?
+2. Which draft replies should be posted now?
+3. Run verification commands after implementation? (yes/no)
+4. Stage/commit/push after verification? (yes/no)
+5. Promote any harness candidates now? (yes/no; list IDs)
+
+If posting replies is approved, use this posting protocol:
+
+- Post only after related implementation/verification is complete for that comment.
+- ID safety: never use GraphQL node IDs (for example `PRRC_*`) for REST reply endpoints; use numeric PR review comment IDs from `repos/<owner>/<repo>/pulls/<number>/comments`.
+- Inline review-comment reply endpoint:
+  - `repos/<owner>/<repo>/pulls/<number>/comments/<comment_id>/replies`
+- Issue-level PR comment endpoint:
+  - `repos/<owner>/<repo>/issues/<number>/comments`
+- JSON safety: do not build non-trivial `{"body":"..."}` payloads inline; serialize with a JSON tool and post via `--input <json-file>`.
+- Temp-file safety: create payload files with `mktemp`; if `/tmp` is not writable, use a workspace-local temp path.
+- Preflight: verify target comment exists and is replyable before posting.
+- On `404`/`400` posting errors, stop and fix ID/payload generation before retrying; do not mark as posted.
+- PowerShell safety: avoid `gh api -f body="..."` for markdown/backticks; write JSON body to a UTF-8 (no BOM) temp file and post with `--input <tmp-file>`.
+
+Do not execute write actions without explicit approval.