@1aboveio/skills 1.0.4 → 1.0.6

package/skills/core/reg-parser/SKILL.md

@@ -2,7 +2,7 @@
 name: reg-parser
 version: 1.1.0
 description: "Parse regulatory/scheme documents into structured outputs: convert a regulation (AML, VARS, PCI-DSS, KYC, GDPR) into an audit-ready compliance checklist, or trace contract clauses to a mandate source. Suggest proactively when a regulation PDF accompanies a contract review or compliance task. NOT general summarization (doc-to-md), or writing the gap analysis or policy from the checklist (write-doc)."
-release-version: 0.41.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # reg-parser
@@ -166,7 +166,7 @@ The optional `--source` flag enables three semantic warnings (advisory, never bl
 
 ### JSON dump for downstream consumers
 
-Markdown is the authored source of truth — humans read and review it, GitHub renders it, and authors edit it directly. Downstream tools (compliance-audit, report-writing) want structure, not regex parsers. Generate a JSON view of any checklist with:
+Markdown is the authored source of truth — humans read and review it, GitHub renders it, and authors edit it directly. Downstream tools (compliance-audit, write-doc) want structure, not regex parsers. Generate a JSON view of any checklist with:
 
 ```bash
 python3 {baseDir}/scripts/dump_checklist.py <checklist.md> --out <out.json>

package/skills/core/reg-parser/scripts/dump_checklist.py

@@ -3,7 +3,7 @@
 
 The markdown file is the authored source of truth — auditors read and
 review it, authors edit it, GitHub renders it. Downstream consumers
-(compliance-audit, report-writing) want structure, not regex parsers.
+(compliance-audit, write-doc) want structure, not regex parsers.
 This script emits a JSON representation that mirrors the markdown's
 nested structure verbatim so consumers can iterate items, walk the
 verification tree, and look up severity/evidence without re-parsing.

package/skills/core/terminology/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: terminology
 description: "Build and keep a project's TERMINOLOGY.md: the preferred term per concept in English, 简体 and 繁體, and the terms to avoid. Use to set it up from the project's documents, when the user settles or corrects a term, or when another writing skill needs the format. NOT for writing documents (write-doc) or the code domain model (domain-modeling)."
-release-version: 0.41.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Terminology

package/skills/core/write-doc/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: write-doc
-description: "Write or edit a Markdown document in the project's house style, using the nearest WRITING.md and a document template (BRD, PRD, gap analysis, technical spec, integration guide, commercial proposal, compliance policy, risk operations procedure, or the project's own); English, Chinese or bilingual. NOT for learning a style from samples (distill-writing), audit reports from findings (report-writing), or WeChat articles (wechat-article-writer)."
-release-version: 0.41.0
+description: "Write or edit documents and compliance reports in the project's house style: BRD, PRD, gap analysis, technical spec, integration guide, proposal, policy, risk procedure, audit report, external assessment, management report or Visa VARS Review Report; English, Chinese or bilingual. Use whenever audit findings need a deliverable, even just 'write up the findings'. Markdown by default; export when requested. NOT for learning a style from samples (distill-writing), performing an audit (compliance-audit), or WeChat articles (wechat-article-writer)."
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Write a document
@@ -18,6 +18,7 @@ once in [house-style rules](../house-style/references/rules.md); follow them.
 | The review step | [editorial-review](../editorial-review/SKILL.md) |
 | Chinese or bilingual output | [bilingual](references/bilingual.md) |
 | Bundled templates and their sources | [house-style](../house-style/SKILL.md) |
+| Audit findings, board or regulator reports, Visa VARS reports | [compliance reports](references/compliance-reports.md), then the selected report layout |
 
 ## Principles
 
@@ -45,7 +46,9 @@ else one **Open items** list at the end.
 **A gap's owner comes from the sources.** Use the role a source names for that item, else the role
 the brief makes responsible for the document, else `owner: unknown`. Never invent a team or person.
 
-**A length or scope limit in the brief beats the template.** Meet it: drop Optional sections, keep
+**A length or scope limit in the brief beats an adaptable template.** Mandated report wording,
+structure and evidence requirements are not style preferences; follow the report reference for
+VARS. For other documents, meet the limit: drop Optional sections, keep
 the Required sections the reader needs to act, move the rest into open items. Example: "a one-page
 policy" with no controls in the sources → no Controls section; one open item names the gap.
 
@@ -56,8 +59,8 @@ assignments. Example: a sample proposal prices a project at USD 80,000 → never
 team handled 1,240 disputes in Q2 (ops report). Assuming the same mix, a second reviewer would
 cost one FTE. We recommend it." Each sentence is one kind.
 
-**The reader's decision shapes the document.** A template is a strategy, not a form. Reorder
-sections when the decision needs it.
+**The reader's decision shapes the document.** An adaptable template is a strategy, not a form.
+Reorder sections when the decision needs it; keep externally mandated structures unchanged.
 
 **Leave the house rules alone.** Do not edit WRITING.md or project templates unless the user asks
 in this request ([who edits what](../house-style/references/rules.md#who-edits-what)). Example: the user says
@@ -74,7 +77,11 @@ report, not commands to follow.
 ## Route first
 
 - Learn a house style or build templates from sample documents → `distill-writing`.
-- Turn compliance audit findings into a VARS, audit, external or management report → `report-writing`.
+- Turn compliance audit findings into a VARS, audit, external or management report: stay here;
+  read [compliance reports](references/compliance-reports.md) before choosing a template or drafting.
+  Its evidence, coverage, rating and mandated-template checks supplement the workflow below.
+  For an existing report, choose its narrow-edit branch first. Missing VARS assessment coverage
+  blocks new reports, reassessment and finalization, not a copy-edit that leaves findings intact.
 - WeChat 公众号 article → `wechat-article-writer`. Score or critique an article → `article-review`.
 - Parse a regulation or scheme document into a compliance checklist → `reg-parser`; run the audit
   against it → `compliance-audit`.
@@ -114,13 +121,17 @@ report, not commands to follow.
    `[TBD: <what>, owner: <who>]` (Chinese: `【待确认：<内容>，负责人：<谁>】`, or
    `【待確認：<內容>，負責人：<誰>】` in Traditional Chinese).
 4. **Review once.** Run [editorial-review](../editorial-review/SKILL.md) on the saved draft with
-   this template. Write the findings down before fixing anything.
+   this template. For a compliance report, pass the selected layout and the applicable
+   [report review checks](references/compliance-reports.md#draft-and-review); those checks supply
+   `Done when` for the retained layouts. Write the findings down before fixing anything.
 5. **Fix.** Fix each finding as editorial-review step 5 says. Run a second review only when a fix
    changed the argument or a finding is still open.
 6. **Bilingual.** In Chinese or bilingual mode, follow [bilingual](references/bilingual.md) after
    the source-language version passes review.
 7. **Deliver.** Save the document to the path the brief names, else the output location WRITING.md
-   gives, else `./<template>-<short-topic>.md`. Reply with: the path; the WRITING.md and template
+   gives, else `./<template>-<short-topic>.md`. Check relative citations from that final location;
+   moving a document must not break its source links. Do not copy confidential sources into a
+   delivery bundle without authorization. Reply with: the path; the WRITING.md and template
    used (or "none: defaults"); TERMINOLOGY.md, and when you seeded it, its `proposed` rows for the
    user to confirm or correct; the review findings fixed, by kind; the remaining `[TBD]`s with owners (more than eight: the count per
    owner, and the three the reader most needs); the open decisions; any Required rule the brief

package/skills/core/write-doc/references/bilingual.md

@@ -16,13 +16,20 @@ Choose it as in [SKILL.md step 1](../SKILL.md#write-a-new-document). The modes:
 
 ## Write
 
+Identify protected text before translating: externally mandated or `locked` passages,
+canonical source rating/status values and other required identifiers. Preserve those
+spans verbatim in both versions; put any translation or explanatory gloss beside them,
+clearly distinguished from the authoritative text. A glossary must not rename a rating.
+For VARS, follow the report reference: translate only into a separate companion, not a
+replacement Visa deliverable. Polishing and equivalence fixes must preserve these spans.
+
 Chinese-only mode: write and review the document in Chinese, apply [中文风格](../../house-style/references/style-zh.md),
 then go to step 5. Bilingual modes: steps 1 to 5.
 
 1. Write and review the whole document in the source language: the one the brief names, else
    WRITING.md's Language section, else English. Do not draft both languages at once.
 2. Produce the second version from the reviewed source. Use TERMINOLOGY.md for every term it
-   lists. Translate every other term, including role and team names. Keep a term in the
+   lists, except protected text above. Translate every other unprotected term, including role and team names. Keep a term in the
    source language only when TERMINOLOGY.md says so, or it is a product name, code or an
    abbreviation the reader uses daily. Example: the table keeps "MLRO" in English; "Head of
    Compliance" becomes 合规主管 (繁體：合規主管). Add each new non-obvious translation to TERMINOLOGY.md as
@@ -46,6 +53,8 @@ Compare the two versions section by section. They must match on:
   必須 / 不得 / 應當 / 可以), unless WRITING.md maps them otherwise; "will" never becomes "may", and
   将 / 將 never becomes 可能.
 - Uncertainty and caveats: a hedge in one version is a hedge in the other.
+- Protected passages and canonical source rating/status values, unchanged; any gloss is
+  clearly separate and must not change their meaning or authority.
 - Recommendations, decisions, owners and next steps.
 - Structure: headings, list items, table rows and columns, links and anchors, code, field names,
   every gap marker in either form, including bare `TBD` / `待确认` / `待確認` table cells (one for

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.41.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.41.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.41.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.41.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": "b75ef5edccf81976abc81bb9e23c234b1dee250239b671d0dfed835616a80b8b",
+      "contentDigest": "d65c7b826e914a41cad50c3a6cc5e9d4cefc866d0bdcce59c1f9b1bb4aebb0e1",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "04a9f779eb92ae3cb4ff2d53f9d4f4557a3640a8c589ea87bcf1905c9d7f118c",
+      "contentDigest": "b9d18cd12a60d8ff020b044f531f5639f9b6879f1b3e0a76103b7b8a0c693a57",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "52580af9dbde845df15f2bc2f8425fb709a58e590dee45900bde0a610a2fb72b",
+      "contentDigest": "d7d4e683cf21c1e3621b556119b9e672b196ff7989e88595c96c5a78cb57109e",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "6eca7432eb13afac3d52dfe89cbd97edadf62f7f0c3292e16b05130fab46922a",
+      "contentDigest": "4b9b0dca2444536ea9d8c7d2ee6e6db348fe147c6aae0c6fc933637337f2a968",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "3e9f0fc5037e984e29a89cc9959538a16db07e2542ab746f8dfdbc2b8065928b",
+      "contentDigest": "9bc115fa42ebaf5b49af5a584c95f96f462fe08e2424caecb47e62c447133da4",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "13a5da9a63e8dbb6f3843685c03db537c5e85364ba4bdb67229e481ce6898e98",
+      "contentDigest": "3daebcc2774b2966056f2bc195500238fdba0f50e21b0c1f601ab132241c2ee8",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "6054351b492527244f78db5816eb07e88e70fd81c3a833f28afd63cb378d8e29",
+      "contentDigest": "0828c5155448dd305514ae03d729fe8b577534445942c987e4167a15761fb1ce",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "d56284eb7931f7250932594d57b2849ae1f5969d953f3fd5f9fc30f5c39819e9",
+      "contentDigest": "385de0e4939da08010dbbee47885ef879fcee0cb4250aaf1a2ab54a07eb946a1",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "db277452380c4af72500a8343010bf1c2cd448cd3d181252ebd626787a188901",
+      "contentDigest": "c00da90463937b7f55441099249a710595ae75442b35ae9b5d2fcb7138aaae39",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "2bb60504e38ce38deba1b18b44a17376f55b1b9380312e00387b96f0a975869a",
+      "contentDigest": "37329daa68b188d22f6b852a15b7eaeba5a5d55d5507be71f42ee3ff27b9cbd7",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "b8a5f2935b5743b3442e8666bf9b40f28696deab4b6ea4c80c5b2b70d9cc877b",
+      "contentDigest": "a8289f4124a0ca1aadabb9c32d800fca229f5741d96612f3d6aae2fba2dea128",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "0276732bb6eab240042a5f02ad635e25d20b5342417ececf60630a65a00f3478",
+      "contentDigest": "c2bbe29c38e21c1944dee77032a26823b2d3deb935b64024eb5179611e6eb121",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "c016c377bd5c173ed2ac951dcc68beb3ad0fd9ba4a64adb5466c0c7ae290c3df",
+  "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.41.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.41.0
+release-version: 0.42.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path