@1aboveio/skills 1.0.5 → 1.0.7

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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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": "8f0be335debec8a0b64bb40201a412eb0bc9ccc402074a7af0a483609daac28e",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5cbfd6c6efe831db62de5dfaf6a969a57fb948da18d1f15343a4f9fb929b5d1f",
+      "contentDigest": "54c4c3e8579168b32c9d894f91d9bd6950dde2bf44ebd908cc7c548bdc0f6435",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "a6beb9f98cf5bd1b0b93dfaf9d7370b442661996fd17ace25db4ead102e656f6",
+      "contentDigest": "8e6ae6a6065c670b6ed61c2b881dbea921847a7d80818916e853c4b73dd02e56",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "61cbdbdae25549a16147280204cbb2e539d19a9ebda12e18544c5ba441de8104",
+      "contentDigest": "d5c96b3b0a7272a6ae6d4670f3deca7196c39cdb857d52936b076e880d338bcd",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "2ad0540e1e0591fc2979a8f319d5ce6741aa7a8ab1d6f913b177b40d1d325a33",
+      "contentDigest": "077317f2b2e8a142bd46c75d00bf2ba23b34cc24daa3f49bb9e4bb7247f7590c",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "30da0eabbec9040a1ed9b51553b4bed54e69ec4f288904dc2536be330f7e625a",
+      "contentDigest": "a755c90afd1aef1e3de56fd35af08e98fc111b7cea775a63c7a34593ec1e499b",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "9b9f791716e53350d538e52649835888f7329f64f0f09df741eeaf4180214f9a",
+      "contentDigest": "937c2139aa3ca8f9f0a325c8a1300b1a84faba2f16132f8c608169e4e0732631",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "3f645b737fbfd24f558bb84c5c4690abf76f19292a3382614ef2369333d9c4e4",
+      "contentDigest": "a2e269f07c9309c5404eafe1b2ca2f5913dd390711c9a3ea7bffb3ae13c88a58",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "8c7e031f4193dee85aa3c372dbde007bc4eda3c3be8a01782af1eae22eae3597",
+      "contentDigest": "9c2920ba1dd60e6546831d5c5e0d32c2ce620cfd81cbb6b336c19dde223cacbb",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "c7ee7f4efa548aefce16d471f33e821baf297eb457b05c971c13eac7b242a56f",
+      "contentDigest": "4b85a0b25eec4594b40d95f41307ae1960b57d648df6e032cc0c780187432805",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "ee9cbd827623de79d82049ce3d591df928459d5366f0acf2d58c278e22d0f8a4",
+      "contentDigest": "ee9204746c76d9734873b6f4953c2bf4854d01544bdd8212fe93df80d51e1c28",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "5913c86a3e73d20b4bf9ef3f1426fbbe41295226bc6e2d6ef9bf08e1e7a9fb36",
+      "contentDigest": "1924382a6facdc4ad20cf9a70ee608c33c9d3dcba0babc2c1ed900876f6f1bb2",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "39b7ac8ecbc245defbeeb73a7d4c2e872a32c3bc992b95590058cd236952efc1",
+  "releaseIdentity": "931e08c86e3cec4a44ba5568386488328de64187ae452e1db2a952043068d0f6",
   "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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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.43.0
 ---
 **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

package/skills/risk-compliance/report-writing/SKILL.md

@@ -1,220 +0,0 @@
----
-name: report-writing
-description: "Convert compliance audit findings into audience-formatted reports. Four styles: VARS Review Report (Visa's official 2025 template, required verbatim for VARS engagements), Audit Report (compliance team), External Assessment (regulators/external auditors), Management Report (board/C-suite). Use whenever audit output needs to become a deliverable, even just 'write up the findings'."
-release-version: 0.42.0
----
-**Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
-# Report Writing
-
-Generate compliance reports from structured audit findings. Four report styles target
-different audiences — same data, different depth and tone.
-
-## Input Format
-
-Structured findings in Markdown with per-item:
-- **Status:** Pass / Fail / Partial / N/A
-- **Severity:** Critical / Major / Minor / Observation
-- **Category:** e.g., Access Control, Data Protection, Incident Response
-- **Observations:** What was found
-- **Evidence:** Logs, configs, screenshots, code references
-- **Recommendations:** Suggested remediation
-
-If the input deviates, normalize it to the above structure before generating the report.
-
-### VARS-specific input requirement
-
-The VARS Review Report must be generated from the **full** per-control assessment —
-typically the `tracker.md` produced by the `compliance-audit` skill running against the
-VARS checklist (`skills/compliance/compliance-audit/references/vars-checklist.md`, or a
-parsed equivalent from `reg-parser`). Do **not** start a VARS report from a summary,
-verbal findings, or a partial sub-domain review — Visa's report aggregates a complete
-control-by-control assessment, and Section 5 of the deliverable explicitly references
-the *VARS Control Testing and Remediation Tracking* spreadsheet (which is the same
-tracker, in Visa's Excel format).
-
-If the user asks for a VARS report and you don't see a complete tracker covering all
-nine sub-domains, **stop and ask** for it — or offer to run `compliance-audit` first.
-A VARS report without the underlying control-level evidence is not a deliverable Visa
-will accept.
-
-## Report Style Selection
-
-| Style | Audience | When to use |
-|---|---|---|
-| **VARS Review Report** | Visa, acquirer leadership | Visa Acceptance Risk Standards engagements — uses Visa's official 2025 template |
-| **Audit Report** | Compliance team, internal auditors | Day-to-day remediation tracking, technical deep-dives |
-| **External Assessment** | Regulators, external auditors, certification bodies | Formal submissions, certification audits, regulatory filings |
-| **Management Report** | C-suite, board, leadership | Quarterly reviews, risk committee briefings, budget justification |
-
-Select the style based on the stated audience or purpose. If unclear, ask. Default to
-Audit Report when the requestor is technical. **If the framework is VARS / Visa
-Acceptance Risk Standards, always use the VARS Review Report style** — Visa requires
-its template verbatim.
-
-## Workflow
-
-### 1. Ingest Findings
-
-1. Read the audit findings file (Markdown). For VARS, this is the `compliance-audit`
-   tracker produced against the VARS checklist — it must cover all nine sub-domains.
-2. Parse each finding into: ID, title, category, status, severity, observations, evidence, recommendations.
-3. Validate completeness — flag any finding missing severity or status. For VARS,
-   additionally verify every sub-domain is represented; if any are missing, stop and
-   surface the gap to the user before drafting.
-
-### 2. Select Style
-
-Confirm the target style with the user or infer from context:
-- "VARS" / "Visa Acceptance Risk Standards" / "for Visa" → **VARS Review Report**
-- "for the regulator" → External Assessment
-- "for the board" / "executive summary" → Management Report
-- "full technical report" / default → Audit Report
-
-### 3. Generate Report
-
-**House style.** Use the nearest `WRITING.md`: start in the findings file's folder (pasted text: the output
-folder, else the working directory), then parents up to the repository root; never the home
-directory or above. Rate every issue from the evidence first; the style changes
-wording, never a rating, a finding or which issues appear. Then write the prose in its voice,
-language, terms, sentences and presentation. Keep the template structure, severity and rating scales
-(including Status values such as Pass / Fail / Partial), finding IDs and every input count; its
-terms apply to prose, not rating values. The request beats WRITING.md, which beats this skill's
-wording. Never edit WRITING.md. Bilingual: `write-doc`'s bilingual mode. No WRITING.md: write as
-below.
-
-The VARS Review Report ignores WRITING.md entirely: Visa's template wording and structure stay
-verbatim.
-
-Follow the style-specific template. Reference files provide the full structure:
-
-- **VARS Review Report:** Read `references/vars-report-template.md` (Visa's official 2025 template)
-- **Audit Report:** Read `references/audit-report-template.md`
-- **External Assessment:** Read `references/external-assessment-template.md`
-- **Management Report:** Read `references/management-report-template.md`
-
-### 4. Review and Finalize
-
-1. Verify coverage:
-   - Audit Report: every finding from the input has its own section.
-   - External Assessment: every finding is mapped to a regulatory requirement.
-   - Management Report / VARS: findings are aggregated by category/sub-domain with no category dropped.
-2. Confirm severity counts match the input data. For VARS: Section 3.d is **executive**
-   (a headline plus a 2–3 sentence business posture per sub-domain, no operational
-   detail); Section 4 is **department-manager** detail, with "Compliance Status" carrying
-   the tracker's Control Effectiveness Rating (Satisfactory / Improvement Recommended /
-   Unsatisfactory / N/A; worst rating across the row) and "Findings and Comments" written
-   as an inline observed → finding → comments narrative in the report's own words (no
-   source-document/clause/sample citations — those stay in the tracker) with the Actions
-   Required / Recommendations reproduced verbatim. When the ATPA archetype is in scope,
-   confirm all TPA controls are consolidated into a single "Third Party Agent" row rather
-   than scattered across the AACQ sub-domains.
-3. Check that no placeholder text remains (e.g. `{{...}}`, `____`, `MM/YEAR`).
-4. Output as Markdown. If DOCX is requested (the VARS deliverable is typically distributed as
-   DOCX to match Visa's template), **do not rely on a plain `pandoc` Markdown→DOCX conversion
-   for the Section 4 table** — pandoc collapses the `<br>` line breaks inside the wide
-   Findings-and-Comments cells, so the enumerated Actions Required / Recommendations items run
-   together and appear to be missing. Instead render the DOCX so each cell's `<br>`-separated
-   lines become **separate paragraphs** (e.g. build it with `python-docx`, or post-process the
-   pandoc output). In Section 4 specifically:
-   - split every `<br>` into its own paragraph in the cell, so each Actions Required /
-     Recommendations item is on its own visible line;
-   - render `**…**` labels (`Actions Required:`, `Recommendations:`) as real **bold**, not
-     literal asterisks;
-   - shade the **Compliance Status** cell by rating (Satisfactory = green, Improvement
-     Recommended = amber, Unsatisfactory = red, N/A = grey);
-   - set the page to **landscape** to give the table room.
-   For PDF, the same line-break requirement applies.
-
----
-
-## Style Summaries
-
-### VARS Review Report
-
-Visa's official 2025 template, used verbatim. Six fixed sections with mandated
-boilerplate (Purpose paragraph, reliance statement, recommendation summary stem) and
-nine fixed sub-domains in canonical order — plus a consolidated **Third Party Agent**
-row when the ATPA archetype is in scope. Detailed per-control findings live in the
-companion *VARS Control Testing and Remediation Tracking* Excel — the report itself
-aggregates one row per sub-domain. The two summary layers serve different audiences:
-**Section 3.d is executive** (business posture, 2–3 sentences per sub-domain) and
-**Section 4 is for department managers / control owners** (an inline observed → finding
-→ comments narrative in the report's own words, with verbatim Actions Required /
-Recommendations and no duplication of the tracker's evidence citations).
-
-**Key sections:** Cover, Document History, Distribution List, Executive Summary
-(Purpose / Background / VARS Control Assessment / Summary of Findings / Recommendation
-Summary), Observations Overview (sub-domain table), Detailed Information (pointer to
-Excel tracker), Next Steps.
-
-**Tone:** Formal, third-person, Visa-facing. Preserve the boilerplate paragraphs
-verbatim — paraphrasing breaks reviewer expectations.
-
-### Audit Report
-
-Full technical detail. Every finding gets its own section with evidence, root cause analysis,
-remediation steps, priority, and suggested timeline. Appendices contain raw evidence.
-
-**Key sections:**
-1. Report metadata (scope, period, assessor, framework)
-2. Executive summary (pass/fail counts)
-3. Findings (one per item — full detail)
-4. Remediation plan (prioritized)
-5. Appendices (evidence, methodology, glossary)
-
-**Tone:** Technical, precise, neutral. Use passive voice sparingly. Reference specific
-controls, configurations, and code paths.
-
-### External Assessment
-
-Formal language suitable for regulatory submission. Organized by regulatory requirement,
-not by internal finding ID. Includes gap analysis matrix and attestation-ready statements.
-
-**Key sections:**
-1. Cover page and scope statement
-2. Assessment methodology
-3. Compliance status by requirement (article/section mapping)
-4. Gap analysis matrix (requirement × status × severity)
-5. Remediation roadmap
-6. Attestation statement
-7. Appendices (evidence index, assessor qualifications)
-
-**Tone:** Formal, objective, structured. Reference regulation articles explicitly
-(e.g., "Article 32(1)(a) of Regulation (EU) 2016/679"). Avoid colloquial language.
-
-### Management Report
-
-Concise, business-oriented. Leads with a one-page executive summary. Uses visual
-indicators (counts, heatmap descriptions) rather than technical evidence.
-
-**Key sections:**
-1. Executive summary (1 page max — overall posture, key risks, headline numbers)
-2. Risk heatmap (critical/major/minor counts by category)
-3. Business impact analysis (what gaps mean operationally and financially)
-4. Recommended actions with effort estimates (cost, time, owner)
-5. Progress since last assessment (if prior data available)
-6. Appendix (methodology note, detailed data reference)
-
-**Tone:** Business language, action-oriented. Quantify impact where possible.
-Avoid jargon — explain technical concepts in business terms.
-
----
-
-## Output Conventions
-
-- **File naming:** `{style}-{framework}-{YYYY-MM-DD}.md`
-  - Example: `audit-report-SOC2-2026-03-30.md`
-  - VARS example: `vars-review-report-{acquirer}-2026-03-30.md`
-- **Severity color coding** (for Markdown rendering):
-  - 🔴 Critical | 🟠 Major | 🟡 Minor | 🔵 Observation
-- **Finding IDs:** Preserve original IDs from the input. If absent, assign sequential IDs: `F-001`, `F-002`, etc.
-- **Cross-references:** Link findings to remediation items and evidence appendices by ID.
-
-## Edge Cases
-
-- **No critical findings:** Lead the executive summary with overall compliance posture, not absence of criticals.
-- **Mixed frameworks:** If findings span multiple frameworks (e.g., SOC 2 + PCI DSS), organize by framework first, then by requirement.
-- **Incomplete evidence:** Flag as "Evidence Pending" — do not omit the finding.
-- **Prior assessment data unavailable:** Omit the "Progress" section in Management Report; note "Baseline assessment — no prior data" in methodology.
-- **VARS sub-domain with no findings:** Still include the row in Section 4 and the bullet in Section 3.d — Compliance Status "Satisfactory", Findings and Comments an inline observed-then-finding narrative closing with "No remediation required." (matching the tracker's Satisfactory Issue Description) — Visa expects all nine sub-domains to appear (plus the Third Party Agent row when ATPA is in scope).
-- **VARS legacy numbering:** The official 2025 template skips index 9 in the Section 4 table (Regulatory Risk is labelled #10). The `references/vars-report-template.md` uses sequential 1–9; switch to legacy numbering only if the Visa engagement lead asks.