@1aboveio/skills 1.0.5 → 1.0.6

package/skills/core/write-doc/references/compliance-reports.md

@@ -0,0 +1,163 @@
+# Compliance reports
+
+Use this reference within the `write-doc` workflow when audit findings become a report.
+It replaces the retired `report-writing` skill. For a narrow edit to an existing report, use
+[the edit branch](#edit-an-existing-report) before the full-report steps below.
+Do not repeat the audit or silently change
+its conclusions while writing. The report layouts are retained source layouts, not general
+house-style template skeletons; this reference supplies their inputs, reasoning and checks.
+
+## Choose the report
+
+| Report | Reader and purpose | Bundled layout |
+| --- | --- | --- |
+| VARS Review Report | Visa and acquirer leadership; Visa Acceptance Risk Standards engagement | [VARS](reports/vars-report-template.md) |
+| Audit Report | Compliance team and internal auditors; technical findings and remediation | [Audit](reports/audit-report-template.md) |
+| External Assessment | Regulators, external auditors and certification bodies; formal submission | [External](reports/external-assessment-template.md) |
+| Management Report | Board, C-suite and risk committee; posture and resource decisions | [Management](reports/management-report-template.md) |
+
+Infer the report from the stated audience or purpose. Ask once if neither is clear;
+default to Audit Report for a technical requestor. A VARS engagement always uses the
+VARS layout, not the board or technical alternative. VARS has externally mandated structure;
+ordinary audit, external and management layouts are adaptable defaults. For those reports,
+use the shared house-style selector: an explicit template, then a matching project template,
+then the bundled layout. A project template replaces the bundled structure, not the evidence,
+finding coverage, source ratings or review checks in this reference. Apply house style to prose.
+Use a gap analysis instead for a standalone comparison of requirements and current state
+that is not a report of an assessment.
+
+## Edit an existing report
+
+A copy-edit that changes no finding, rating, scope, count, recommendation or mandated text
+follows `write-doc`'s narrow-edit workflow. Read the existing report and applicable guidance;
+verify only the passages and facts affected by the change. Do not require the complete tracker
+for an unrelated spelling or formatting correction, re-audit the report, or call the edit a
+new assessment or finalization. Preserve protected text and all unaffected content.
+
+An edit that changes a substantive assessment claim requires its supporting source. A new
+report, a request to reassess findings, or a request to finalize a submission uses the full
+evidence and coverage checks below. If a requested change touches mandated wording, surface
+that conflict before changing it; do not silently paraphrase it.
+
+## Inputs and evidence
+
+Read the full findings file. For a generic assessment, retain each finding's ID, title,
+category, status (Pass / Fail / Partial / N/A), severity (Critical / Major / Minor /
+Observation), observations, evidence and recommendations. Normalize other input shapes
+without inventing missing values. Flag missing status or severity; never turn an unknown
+into Pass or a lower severity. Mark missing evidence as **Evidence Pending**, keeping
+the finding visible. Missing facts follow `write-doc`'s gap rules.
+
+Preserve original IDs. Assign `F-001`, `F-002`, and so on only when IDs are absent.
+Link findings to remediation and evidence by ID. Keep source ratings, scales, findings
+and input counts unchanged; house terminology applies to prose, not rating values.
+If an external layout uses another status vocabulary, show its mapping to the source
+values and retain the source values for reconciliation. Do not infer a new rating.
+
+For mixed frameworks, organize by framework first, then requirement. State the actual
+scope, period, assessor and framework when supplied. Root causes, financial impacts,
+likelihoods, costs, owners, dates and effort estimates must come from sources or be
+clearly marked proposals or gaps, never copied from layout examples.
+
+Count the unit actually present: findings, controls and requirements are not interchangeable.
+A findings-only extract cannot establish the total controls assessed, pass count or overall
+compliance rate. State each percentage's numerator, denominator and treatment of N/A or
+unassessed items. Use an overall rating only when the source supplies it or an authorized
+rubric derives it; otherwise describe the known posture and its limits without a new grade.
+
+### VARS gate
+
+VARS requires the complete per-control assessment, normally `tracker.md` from
+`compliance-audit` against its VARS checklist or a parsed equivalent from `reg-parser`.
+A summary, verbal findings or a partial sub-domain review is not enough. Verify the
+tracker against the applicable control checklist, not merely a list of headings: all
+nine sub-domains and all in-scope controls must be assessed. If the tracker is absent,
+incomplete or has a sub-domain marked Not Assessed, stop and ask for the complete
+tracker, or offer `compliance-audit` first. Do not draft a final report around that gap.
+
+Use the tracker's Control Effectiveness Rating (Satisfactory / Improvement Recommended /
+Unsatisfactory / N/A), not the generic finding severity, for VARS rollups. Flag missing
+ratings or mandatory tracker fields and resolve them before finalizing; do not invent
+generic severities for a VARS tracker that has no severity field. Record the tracker
+filename and version for Section 5 and its companion *VARS Control Testing and
+Remediation Tracking* Excel spreadsheet. Do not claim the Excel exists or is synchronized
+without checking it.
+
+## Draft and review
+
+Use `write-doc`'s outline, draft, editorial review, fix and delivery steps. Apply the
+nearest WRITING.md from the findings file's directory, or for pasted input the output
+directory, else the working directory, under the shared lookup rules. Never edit it.
+For non-VARS reports, follow the selected template's structure. House style must not change
+scope, ratings or findings. Give editorial-review both the selected layout and the checks
+below, including Additional VARS checks when applicable. The table above supplies the reader
+and purpose (`Use when`); these checks supply the layouts' `Done when`. Review against both,
+not a generic checklist alone.
+
+**VARS exception:** ignore WRITING.md for the VARS report. Keep Visa's headings, ordering,
+canonical sub-domains and mandated boilerplate verbatim, including the Purpose,
+reliance statement and recommendation-summary stem. General length limits, terminology,
+translation and editorial advice must not rewrite them. Treat mandated passages as
+locked even where the retained Visa layout presents them as quotations. A requested
+translation is a separate companion, not a replacement Visa deliverable. Never claim
+Visa conducted or approved work unless the sources establish it; stop and resolve any
+conflict between mandated language and the actual assessor or scope before finalizing.
+
+Before delivery, check the saved report against the input and selected layout:
+
+- **Audit:** every finding has its own section, with evidence, root cause when known,
+  risk and remediation. Reconcile all severity and status counts to the source.
+- **External:** map every finding to the actual regulatory requirement and retain
+  traceability to the source ID. Unknown mappings stay explicit gaps. Scope, methods,
+  limitations and any attestation must match the evidence and assessor authority;
+  never fabricate a signature or certification. Distinguish total reviewed, applicable,
+  N/A and unassessed items, and reconcile those populations without counting a finding
+  as a requirement. Include an attestation only when the authorized assessor's conclusion
+  is supplied. Otherwise state that no attestation is provided, without a signature stub.
+- **Management:** lead with at most one page on posture, key risks and decisions.
+  Aggregate all categories without losing findings or changing severity counts.
+  Explain technical risks in business terms; quantify only supported impacts.
+  Without prior data, omit the progress section and note
+  "Baseline assessment - no prior data" in methodology.
+- **All reports:** lead with overall posture when there are no critical findings.
+  Check all totals and percentages using their source counts and denominator. No
+  unresolved layout filler such as `{{...}}`, `____` or `MM/YEAR` may remain in a final
+  deliverable. Label unresolved material facts as draft or pending and disclose their
+  effect on the conclusion. Do not invent a regulator's submission acceptance criteria
+  or claim acceptance, rejection or readiness without the applicable requirements.
+
+### Additional VARS checks
+
+- Section 3.d has an overall headline and a business-oriented, 2-3 sentence posture
+  for every canonical sub-domain. No operational or evidence-document detail.
+- Section 4 has one row per sub-domain in canonical order, including rows without
+  adverse findings. Each row takes its worst control rating: Unsatisfactory before
+  Improvement Recommended before Satisfactory; N/A only when all controls are N/A.
+  No findings alone does not establish Satisfactory without the underlying ratings.
+- If ATPA is in scope, consolidate all ATPA controls into one additional **Third Party
+  Agent** row and a corresponding Section 3.d bullet, not the AACQ rows.
+- Section 4 uses an inline observed, finding, comments narrative in the report's own
+  words. Evidence-document, clause and sample citations stay in the tracker; lightweight
+  control-ID pointers are allowed. Copy Actions Required and Recommendations word for
+  word from the tracker's Issue Description, each item on its own line. Close a fully
+  Satisfactory row with `No remediation required.`
+- Section 5 identifies the companion tracker. Section 6 uses sourced remediation
+  commitments. Use sequential rows 1-9; legacy Regulatory Risk #10 only if the Visa
+  engagement lead requests it.
+
+## Export checks
+
+Markdown is the authored default. Use the brief's path, else WRITING.md's output folder,
+else `{style}-{framework}-{YYYY-MM-DD}.md`; for VARS,
+`vars-review-report-{acquirer}-{YYYY-MM-DD}.md`. Do not invent an assessment date.
+When DOCX or PDF is requested, also render and inspect that output; Markdown alone is
+not the requested export.
+
+For VARS Section 4, plain pandoc conversion collapses `<br>` lines inside wide table
+cells. Render each separated line as its own cell paragraph, using a DOCX renderer such
+as `python-docx` or post-processing the conversion. Render labels such as
+`**Actions Required:**` as real bold, not literal asterisks. Shade Compliance Status
+cells green for Satisfactory, amber for Improvement Recommended, red for Unsatisfactory
+and grey for N/A, and use landscape pages for the table. Inspect the rendered file
+to confirm each action and recommendation remains visible on its own line. PDF has
+the same line-break requirement.

package/skills/{risk-compliance/report-writing/references → core/write-doc/references/reports}/audit-report-template.md

@@ -1,6 +1,6 @@
 # Audit Report Template
 
-Use this structure for the full technical audit report (audience: compliance team).
+Use this structure with [compliance reports](../compliance-reports.md) for the full technical audit report (audience: compliance team).
 
 ---
 
@@ -50,7 +50,7 @@ Repeat this block for each finding, ordered by severity (Critical → Observatio
 | **ID** | F-{NNN} |
 | **Category** | {e.g., Access Control} |
 | **Control Reference** | {e.g., CC6.1, A.9.2.3} |
-| **Status** | {Pass / Fail / Partial} |
+| **Status** | {Source status, including Pass / Fail / Partial / N/A} |
 | **Severity** | {Critical / Major / Minor / Observation} |
 
 **Observation:**

package/skills/{risk-compliance/report-writing/references → core/write-doc/references/reports}/external-assessment-template.md

@@ -1,6 +1,6 @@
 # External Assessment Template
 
-Use this structure for regulatory or external auditor submissions (audience: regulators,
+Use this structure with [compliance reports](../compliance-reports.md) for regulatory or external auditor submissions (audience: regulators,
 certification bodies, external auditors).
 
 ---
@@ -65,6 +65,11 @@ AICPA Trust Services Criteria).}
 
 ## 3. Compliance Status by Requirement
 
+Retain source statuses and severities, including Observation and N/A. The alternatives
+below are examples, not a new rating scale. If the destination mandates different labels,
+show the mapping and retain source values for reconciliation. Never replace an unknown
+requirement with an invented legal citation.
+
 Organize by regulation article or standard control domain. Each requirement gets a
 status determination with supporting rationale.
 
@@ -77,7 +82,7 @@ status determination with supporting rationale.
 | **Requirement** | {Full text or summary of the regulatory requirement} |
 | **Regulation Reference** | {e.g., Article 32(1)(a), Regulation (EU) 2016/679} |
 | **Compliance Status** | {Compliant / Partially Compliant / Non-Compliant / Not Applicable} |
-| **Severity of Gap** | {Critical / Major / Minor / N/A} |
+| **Severity of Gap** | {Source severity, including Critical / Major / Minor / Observation / N/A} |
 
 **Assessment Rationale:**
 {Explain the basis for the status determination. Reference specific controls observed,
@@ -105,6 +110,11 @@ Summary view mapping each requirement to its compliance status.
 
 ### Summary Statistics
 
+Count requirements only when the input establishes that population; otherwise label
+these as finding counts. State the denominator for percentages and whether N/A is
+excluded from the applicable population. Keep unassessed items visible rather than
+counting them as compliant or N/A.
+
 | Status | Count | Percentage |
 |---|---|---|
 | Compliant | {n} | {%} |
@@ -125,6 +135,11 @@ Summary view mapping each requirement to its compliance status.
 
 ## 6. Attestation Statement
 
+Use the wording below only when the authorized assessor supplied that conclusion and
+the engagement calls for attestation. Otherwise state that no attestation is provided;
+do not invent credentials, a signature, an overall rating or approval. The stem is
+adaptable, not locked. Reconcile source populations, including N/A and unassessed items.
+
 > Based on the assessment conducted during the period {Start Date} to {End Date},
 > applying the methodology described in Section 2, and having reviewed the evidence
 > documented herein, {Assessor Organization} [attests/concludes] the following:
@@ -132,15 +147,16 @@ Summary view mapping each requirement to its compliance status.
 > {Organization} has demonstrated {[full/substantial/partial]} compliance with
 > {Regulation/Standard} within the defined scope.
 >
-> {Number} requirements were assessed. Of these, {n} were found fully compliant,
-> {n} partially compliant, and {n} non-compliant.
+> {Number} requirements were reviewed: {n} were assessed as fully compliant,
+> {n} partially compliant, {n} non-compliant, {n} not applicable, and {n} unassessed.
+> Of the {n} applicable requirements, {n} were assessed. {State the denominator for any rate.}
 >
 > The findings documented in this report represent the compliance posture as of
 > {Report Date}. This attestation does not guarantee future compliance.
 >
 > **Assessor:** {Name, Title, Qualification}
 > **Date:** {YYYY-MM-DD}
-> **Signature:** ____________________
+> **Signature:** {Supplied authorized signature, only when provided}
 
 ---
 

package/skills/{risk-compliance/report-writing/references → core/write-doc/references/reports}/management-report-template.md

@@ -1,6 +1,6 @@
 # Management Report Template
 
-Use this structure for leadership and board-level reporting (audience: C-suite, board,
+Use this structure with [compliance reports](../compliance-reports.md) for leadership and board-level reporting (audience: C-suite, board,
 risk committee).
 
 ---
@@ -22,7 +22,12 @@ risk committee).
 {One page maximum. This section stands alone — a reader should understand the
 organization's compliance posture without reading further.}
 
-**Overall Compliance Posture:** {Strong / Adequate / Needs Improvement / Critical}
+**Overall Compliance Posture:** {Source rating, or a narrative conclusion limited to the evidence}
+
+Do not introduce an overall scale unless the source or an authorized rubric defines it.
+A findings-only extract does not establish the full assessment posture or pass rate.
+In the headline figures below, use only populations the source supplies; omit an unknown
+control total or compliance percentage and explain that limit instead.
 
 **Headline Numbers:**
 - **{N}** controls assessed across **{N}** categories

package/skills/{risk-compliance/report-writing/references → core/write-doc/references/reports}/vars-report-template.md

@@ -1,5 +1,7 @@
 # VARS Review Report Template
 
+Read [compliance reports](../compliance-reports.md) before using this layout.
+
 Authoritative template for **Visa Acceptance Risk Standards (VARS)** review reports
 distributed by Visa to acquirers. Mirrors Visa's official 2025 *Visa Acceptance Risk
 Standards Report Template* (Confidential, Final).
@@ -20,8 +22,9 @@ Remediation Tracking* spreadsheet, which is the same tracker in Visa's Excel for
 Before drafting:
 1. Confirm the tracker exists and covers all nine sub-domains. If any are missing or
    marked "Not Assessed", stop and raise it — do not paper over gaps in the report.
-2. Confirm every control row has a status and a severity. Section 4 priorities and
-   Section 3.d summary statements both depend on these.
+2. Confirm every control row has a Control Effectiveness Rating and the mandatory
+   fields required by the tracker schema. Sections 3.d and 4 use these ratings;
+   VARS has no generic severity-priority field. Do not invent one.
 3. Note the tracker's filename and version — it will be referenced from Section 5 and
    should accompany the report when distributed.
 
@@ -173,7 +176,7 @@ TPA controls across the AACQ sub-domains (so e.g. a TPA-agreement gap does not p
 "Written Agreement" or "Onboarding" rows down). Omit row 10 when ATPA is out of scope.
 
 **Compliance Status values:** Satisfactory / Improvement Recommended / Unsatisfactory / N/A — the tracker's Control Effectiveness Rating. A sub-domain takes the **worst** rating among its controls (any Unsatisfactory ⇒ Unsatisfactory; else any Improvement Recommended ⇒ Improvement Recommended; else Satisfactory; N/A only if every control is N/A).
-**Findings and Comments:** written as an **inline auditor narrative** — flowing prose (no bold sub-headings) that conveys, in order, what was **observed** (the controls and practices in place), the **finding** (the rating and any mandatory gaps), and **comments** (recommendations and scoping notes such as N/A controls). Describe the controls in the report's **own words**; do **not** cite the underlying evidence documents, clauses, attestation numbers, or specific samples — that detail lives in the tracker (Section 5), and repeating it here duplicates the tracker. Lightweight control-ID cross-references (e.g. `AACQ.C8.1`) may be included as pointers. The **Actions Required** and **Recommendations** items must be reproduced **verbatim — word for word — from the tracker's Issue Description** (only the observations narrative is in the report's own words); put each item on its own line so they stay visible. For a fully **Satisfactory** row, close with `No remediation required.` When rendering to DOCX/PDF, each `<br>`-separated line in this cell must appear on its own line — see the rendering note in `SKILL.md` (a plain pandoc table conversion collapses them).
+**Findings and Comments:** written as an **inline auditor narrative** — flowing prose (no bold sub-headings) that conveys, in order, what was **observed** (the controls and practices in place), the **finding** (the rating and any mandatory gaps), and **comments** (recommendations and scoping notes such as N/A controls). Describe the controls in the report's **own words**; do **not** cite the underlying evidence documents, clauses, attestation numbers, or specific samples — that detail lives in the tracker (Section 5), and repeating it here duplicates the tracker. Lightweight control-ID cross-references (e.g. `AACQ.C8.1`) may be included as pointers. The **Actions Required** and **Recommendations** items must be reproduced **verbatim — word for word — from the tracker's Issue Description** (only the observations narrative is in the report's own words); put each item on its own line so they stay visible. For a fully **Satisfactory** row, close with `No remediation required.` When rendering to DOCX/PDF, each `<br>`-separated line in this cell must appear on its own line — see [export checks](../compliance-reports.md#export-checks) (a plain pandoc table conversion collapses them).
 
 ---
 

package/skills/engineering/better-review/SKILL.md

@@ -4,7 +4,7 @@ description: "Slash/explicit-only (/better-review). Single-agent adversarial rev
 disable-model-invocation: true
 dependencies:
   - engineering-runtime
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Better Review

package/skills/engineering/contributing/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contributing
 description: "The conventions a repo's CONTRIBUTING.md holds, starting with tracker routing: which tracker an issue belongs in (GitHub for engineering, Linear for product), duplicate search, and linking back to the source requirement. Use before creating any issue, spec, epic, ticket or sub-issue on GitHub or Linear, including inside /to-spec, /to-tickets and /triage, and whenever work that started from a Linear issue turns into engineering work. Also writes the rules as the Issue tracking section of the repo's CONTRIBUTING.md. NOT for delivering a PR (github-flow) or splitting work into slices (to-tickets)."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Contributing

package/skills/engineering/e2e-test/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: e2e-test
 description: "Playwright end-to-end standard: the 3-tier suite (render-health / functional / journey), generated route manifest, and presentation sweep. Use when browser routes or user flows ship or change, or a Playwright test flakes. NOT for non-browser tests, defining what to test (ensure-coverage), the curated ALIVE/DEAD golden-path gate (golden-path), or CI workflow YAML (github-actions)."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # E2E Testing Standard

package/skills/engineering/engineering-runtime/SKILL.md

@@ -3,7 +3,7 @@ name: engineering-runtime
 description: Internal support package for shared Engineering Workflow executable behavior. Never select or invoke this package as a user capability.
 disable-model-invocation: true
 user-invocable: false
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Engineering Runtime

package/skills/engineering/engineering-runtime/coherence/workflow.json

@@ -369,7 +369,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "29dda87aaa4090bbc1b8ac3f3eaa66261cdea76c88f9eac034eb8c85ad767431",
+      "contentDigest": "d65c7b826e914a41cad50c3a6cc5e9d4cefc866d0bdcce59c1f9b1bb4aebb0e1",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5cbfd6c6efe831db62de5dfaf6a969a57fb948da18d1f15343a4f9fb929b5d1f",
+      "contentDigest": "b9d18cd12a60d8ff020b044f531f5639f9b6879f1b3e0a76103b7b8a0c693a57",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "a6beb9f98cf5bd1b0b93dfaf9d7370b442661996fd17ace25db4ead102e656f6",
+      "contentDigest": "d7d4e683cf21c1e3621b556119b9e672b196ff7989e88595c96c5a78cb57109e",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "61cbdbdae25549a16147280204cbb2e539d19a9ebda12e18544c5ba441de8104",
+      "contentDigest": "4b9b0dca2444536ea9d8c7d2ee6e6db348fe147c6aae0c6fc933637337f2a968",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "2ad0540e1e0591fc2979a8f319d5ce6741aa7a8ab1d6f913b177b40d1d325a33",
+      "contentDigest": "9bc115fa42ebaf5b49af5a584c95f96f462fe08e2424caecb47e62c447133da4",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "30da0eabbec9040a1ed9b51553b4bed54e69ec4f288904dc2536be330f7e625a",
+      "contentDigest": "3daebcc2774b2966056f2bc195500238fdba0f50e21b0c1f601ab132241c2ee8",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "9b9f791716e53350d538e52649835888f7329f64f0f09df741eeaf4180214f9a",
+      "contentDigest": "0828c5155448dd305514ae03d729fe8b577534445942c987e4167a15761fb1ce",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "3f645b737fbfd24f558bb84c5c4690abf76f19292a3382614ef2369333d9c4e4",
+      "contentDigest": "385de0e4939da08010dbbee47885ef879fcee0cb4250aaf1a2ab54a07eb946a1",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "8c7e031f4193dee85aa3c372dbde007bc4eda3c3be8a01782af1eae22eae3597",
+      "contentDigest": "c00da90463937b7f55441099249a710595ae75442b35ae9b5d2fcb7138aaae39",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "c7ee7f4efa548aefce16d471f33e821baf297eb457b05c971c13eac7b242a56f",
+      "contentDigest": "37329daa68b188d22f6b852a15b7eaeba5a5d55d5507be71f42ee3ff27b9cbd7",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "ee9cbd827623de79d82049ce3d591df928459d5366f0acf2d58c278e22d0f8a4",
+      "contentDigest": "a8289f4124a0ca1aadabb9c32d800fca229f5741d96612f3d6aae2fba2dea128",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5913c86a3e73d20b4bf9ef3f1426fbbe41295226bc6e2d6ef9bf08e1e7a9fb36",
+      "contentDigest": "c2bbe29c38e21c1944dee77032a26823b2d3deb935b64024eb5179611e6eb121",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "39b7ac8ecbc245defbeeb73a7d4c2e872a32c3bc992b95590058cd236952efc1",
+  "releaseIdentity": "321b0da7bd6d9c65417863048fdef2183a0aa2b87a569c12ceaab0b09fcac600",
   "lifecycleAuthority": "native-skills-cli",
   "repairRecipe": {
     "id": "engineering-workflow-dependency-first",

package/skills/engineering/ensure-coverage/SKILL.md

@@ -2,7 +2,7 @@
 name: ensure-coverage
 description: "Define or audit behavior-first test criteria — ACs, required test levels, mock/integration/E2E policy — across three axes: breadth (Coverage Ledger), depth (over-mocking), presentation (perceivability of browser surfaces). NOT judging whether a single test is any good (test-quality), authoring browser tests (e2e-test), reviewing a PR (better-review), or delivering issues (resolve-issues)."
 disable-model-invocation: true
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Ensure Coverage

package/skills/engineering/golden-path/SKILL.md

@@ -3,7 +3,7 @@ name: golden-path
 description: "Golden-path E2E: the short list of user journeys whose failure blocks a release, kept in a repo as one contract (golden-paths.json) with a generated GOLDEN_PATHS.md and a generated GitHub Actions workflow, and run against a local build or a deployed URL for an ALIVE/DEAD verdict. Use to set golden paths up in a repo ('init golden paths', 'add golden-path CI'), to migrate an older smoke.manifest.json or a hand-built smoke setup ('audit', 'migrate smoke'), to add, change, or remove a golden path, to ask 'is the build alive?' or run them before a PR or release, or when a change touches a flow listed in GOLDEN_PATHS.md. NOT for writing the Playwright specs themselves (e2e-test), deciding what a change must prove (ensure-coverage), or general workflow YAML (github-actions)."
 dependencies:
   - e2e-test
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path

package/skills/engineering/harness-runtime/SKILL.md

@@ -3,7 +3,7 @@ name: harness-runtime
 description: Internal import-only library shared by first-party engineering packages. Not a workflow skill; never select or invoke it as a user capability.
 disable-model-invocation: true
 user-invocable: false
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Harness Runtime

package/skills/engineering/resolve-issues/SKILL.md

@@ -8,7 +8,7 @@ dependencies:
   - better-review
   - golden-path
   - harness-runtime
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues

package/skills/engineering/resolve-release/SKILL.md

@@ -4,7 +4,7 @@ description: "Slash/explicit-only (/resolve-release). Full GitHub Flow release f
 disable-model-invocation: true
 metadata:
   workflow-role: coordinator
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve release

package/skills/engineering/rush-issues/SKILL.md

@@ -6,7 +6,7 @@ metadata:
   workflow-role: coordinator
 dependencies:
   - resolve-issues
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Rush issues (shortcut of resolve-issues)

package/skills/engineering/rush-release/SKILL.md

@@ -6,7 +6,7 @@ metadata:
   workflow-role: coordinator
 dependencies:
   - resolve-release
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Rush release (shortcut of resolve-release)

package/skills/engineering/test-quality/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: test-quality
 description: "Seven principles for tests that catch real bugs, and an audit that reports weak, redundant, and not-coverage tests without fixing them. Use when writing, changing, or reviewing tests, or when asked whether tests are useful, redundant, over-mocked, flaky, only assert static text, or test config files, or asked to make a slow test suite faster without losing coverage, or when the user asks to write the testing conventions into a repo's CONTRIBUTING.md. NOT defining what a spec must prove (ensure-coverage) or authoring browser tests (e2e-test)."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Test Quality

package/skills/risk-compliance/compliance-audit/SKILL.md

@@ -2,7 +2,7 @@
 name: compliance-audit
 version: 2.9.0
 description: "Audit operations against financial-compliance checklists (AML/KYC, VARS, PCI-DSS, TPA oversight, onboarding, transaction monitoring). Produces tracker.md (with a tracker.xlsx export) and phase-trail.md with layered validation; cites evidence by original filename. Input: reg-parser or the built-in VARS checklist."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Compliance Audit

package/skills/risk-compliance/contract-compare/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contract-compare
 description: "Compare two or more contracts side-by-side for structured diff, gap analysis, and benchmarking. Use when: comparing contracts or agreements, contract diff, compare terms, vendor-vs-vendor, compare our template vs theirs, compliance gap between contracts. NOT for single-contract risk review — use contract-review for that."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Contract Compare

package/skills/risk-compliance/contract-review/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: contract-review
 description: "Review contracts for legal, commercial, and compliance risks via convert → chunk review → merge → validate (+ optional mandate preprocessing). Use for reviewing, auditing, or checking any contract, agreement, NDA, MSA, or SLA; input a file path (PDF/DOCX/TXT) or pasted text."
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Contract Review

package/skills/risk-compliance/doc-authenticity/SKILL.md

@@ -3,7 +3,7 @@ name: doc-authenticity
 version: 0.4.1
 description: "Screen PDF documents and raster images for fabrication, tampering, Photoshop or other image-editor use, and content validity. Detects file type, runs format-specific authenticity forensics, classifies bank statements, conversation logs, invoices, agreements, and other documents, then applies type-specific validity checks. Produces separate authenticity (NO_EVIDENCE_OF_MODIFICATION / SUSPICIOUS / LIKELY_MODIFIED / INCONCLUSIVE) and validity (VALID / INVALID / INCONCLUSIVE) verdicts. Use whenever a user asks whether a document, screenshot, scan, statement, invoice, contract, chat log, receipt, or payment evidence is genuine, original, edited, Photoshopped, manipulated, fake, or valid."
 disable-model-invocation: true
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Document and Image Authenticity

package/skills/risk-compliance/fraud-analysis/SKILL.md

@@ -10,7 +10,7 @@ description: >
   impact, and a business report. Use for fraud, scam, mule, account-takeover,
   chargeback, dispute, transfer, collection, or payout risk analysis even when the
   user does not name this skill.
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Fraud Analysis

package/skills/risk-compliance/payment-analysis/SKILL.md

@@ -14,7 +14,7 @@ description: >
   transactions" — even if they do not say payment-analysis. Do NOT use for
   supervised fraud-rule mining (fraud-analysis) or TLD / MCC-miscoding
   clusters (tld-detection).
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Payment Analysis

package/skills/risk-compliance/similar-domain/SKILL.md

@@ -8,7 +8,7 @@ description: >
   links, an entity chain, and a watchlist for the operator's next domains.
   Not transaction data (tld-detection) or fraud rules (fraud-analysis).
 disable-model-invocation: true
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Similar Domain

package/skills/risk-compliance/tld-detection/SKILL.md

@@ -11,7 +11,7 @@ description: >
   with a ≤3-sentence summary.
   Not payment-analysis, fraud-analysis, or website research (similar-domain).
 disable-model-invocation: true
-release-version: 0.42.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # TLD Detection

package/skills/risk-compliance/report-writing/LICENSE

@@ -1,3 +0,0 @@
-MIT License
-
-Copyright (c) 2026 1AboveIO