@1aboveio/skills 1.0.20 → 1.0.21

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

@@ -369,7 +369,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "46f0a76cadebab0a7de8dabf7a93eb194c7f41e0c872fa9c1a04dec86ee0fd88",
+      "contentDigest": "528de8e948bcd1cfdbe92bcb4c14129cbb78d5d9037d8d378d5ac540017cd248",
       "digestExcludes": []
     },
     {
@@ -382,7 +382,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "e1a794446b04b5b70d356ceb9bbbe2a3c518eac486286d5905da98a3d038de65",
+      "contentDigest": "1b1074c002a7d3ca2dfebe625b65128aee10a662f7f9d4060a018fbaecf3225f",
       "digestExcludes": []
     },
     {
@@ -395,7 +395,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "451349ddb0393831abe922cd66c77dd96ea6a4bdd6950c1546e507f5d056dc84",
+      "contentDigest": "61d744eeddd5b3a5d2fa7a94ea01ec3a570c72a7c19ad526761f21aac993abff",
       "digestExcludes": []
     },
     {
@@ -408,7 +408,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "b4c6ae8cb2e708e3695330e65567aab4a301b963d86a4b6706c324fd5e56a36e",
+      "contentDigest": "3140da610485146538ee76048446ea7bac8927890a1469eb8108e63e4056d655",
       "digestExcludes": []
     },
     {
@@ -421,7 +421,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "2dc4ffd9d459c1c61ff9472caf6b318bd45531995d8b8f142e775252c496b22b",
+      "contentDigest": "12f5230e47afdeab750cb6b1454b3172edb29b922155b2994e96a93f386b6dbd",
       "digestExcludes": []
     },
     {
@@ -434,7 +434,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "25ac49e98ce28203feccc17b4f85c67627db9c979511cca349df9dd1fe156d58",
+      "contentDigest": "b8d908580483f3954545e392c11d439ed100688eadc3b41ce508569f6dddc3bc",
       "digestExcludes": []
     },
     {
@@ -447,7 +447,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "bde840d0e6ea6d333c48b47f2635c31c54e1e86a1beee21e26d5a9788c5f7977",
+      "contentDigest": "256eac4a31f95d536ef487359df4c84fe7e85436c3b7550f6200f1b15cca4d0b",
       "digestExcludes": []
     },
     {
@@ -460,7 +460,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "be04047cebb486d9f0b56c59705210038c13ce8f3f10c5ecf7acb361f3a56d0c",
+      "contentDigest": "25ad674c96748cb5313d13c80dd1ac4be5bdb287e75e7f978d8e5b97f5892833",
       "digestExcludes": []
     },
     {
@@ -473,7 +473,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "d7c62210fdfdfa3504a056a8977aa3b67370b65f92d5d32e001fd394fabd44bd",
+      "contentDigest": "1d10c734eaef6bb20bf99bf9fa6dcfde6460ea2eecb84c33d7c0474e470684a9",
       "digestExcludes": []
     },
     {
@@ -486,7 +486,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "f1acfff02ba2ddb0e0d4ffbcd9b5411a394b3b38e9a48ab2ab01ba46fb9bed1f",
+      "contentDigest": "229a6d752c9b17c298172a022c36f8e28e409d665df4ed89f1655c17f37db3f3",
       "digestExcludes": []
     },
     {
@@ -499,7 +499,7 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "cd858ed046f7c4ecb10817307e906a8057db5b8fb5a8c8e9334ef04aff34b9b2",
+      "contentDigest": "c44aa11db1f62995c8b77929143892e421d7068193c959930c8af4fbe8a2d7f5",
       "digestExcludes": []
     },
     {
@@ -512,13 +512,13 @@
         "repository": "1aboveio/ai",
         "revision": "main"
       },
-      "contentDigest": "c3cbfef912ac7448710a7ed5a5014a76928d0350e2032c264c3e0a3212468b6d",
+      "contentDigest": "14439c4b1390b3dde50dcf8d56ff5c578bbbe08b17627f7bd504db099ba5e92a",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "b2e273424d4ceb9a24d78ad163daeb516538defae3f7e6ebea4f59edb055df9a",
+  "releaseIdentity": "d7ab71565826655a05f576e53932870e4d0176329a1b4110a460457e5cb2d0b8",
   "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.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Ensure Coverage
@@ -16,6 +16,13 @@ Read the relevant source and governing project guidance. When product behavior o
 
 ## Scope and proof
 
+- Start from the issue's Acceptance Criteria, requirements elsewhere in the issue,
+  and later human corrections. Map each criterion to sufficient existing tests or
+  missing automation, its qualifying CI lane, and any human or physical-device
+  remainder. One test may prove several criteria; choose the lowest sufficient level.
+  Record this in the existing issue or findings without requiring a new ledger.
+  Workers deliver the tests; CI executes automated acceptance. Grade a criterion
+  satisfied only when the relevant assertions and candidate's results support it.
 - Choose the smallest sufficient proof for the outcome and material risks; reuse existing tests and required CI results when they prove the behavior. Do not automatically require multiple test layers, a ledger, a criteria document, a presentation campaign, or reconciliation of every ADR.
 - Existing required repository checks and adopted coverage floors remain binding unless an approved change alters them. Authentication, money, tenancy, and data-integrity protections remain binding. Read applicable ADRs and project policy for the touched work, not every ADR in the repository.
 - Consider breadth, depth, and presentation where relevant: what behavior is in scope, whether evidence actually exercises it, and whether a user can perceive and use a changed interface. Do not turn every axis or hypothetical state into a separate blocking obligation.

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.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Golden path
@@ -42,6 +42,10 @@ repo has a copy.
 
 ## Rules
 
+Golden paths are the curated release-critical subset, not the full set of issue
+Acceptance Criteria. Keep other automated acceptance tests in their appropriate CI
+suites; an ALIVE verdict proves only the selected paths and their assertions.
+
 1. **A person decides which flows are golden.** Draft candidates; never promote one
    on your own judgment. A flow the user names in the request is confirmed, and so
    are paths carried over from an older smoke manifest (ask about trimming them).

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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Resolve issues
@@ -119,15 +119,31 @@ Read each procedure right before its stage; never substitute your own.
 - **Proof.** Treat producer reports as claims until the reviewer or CI checks them. Tests and diagnostic probes
   encode failure in their exit status under [Proof](references/implementation.md#proof); printing an exception
   and returning 0 is not a passing check. Coordination CLIs keep their documented structured-verdict contracts.
-  A unit owes coding acceptance only: its criteria at its `proof.level` plus the required CI
-  on its final HEAD. Integrated release acceptance (a device or system campaign the spec or repository assigns
-  to a release or campaign gate) runs at that gate, never per unit; the handback links its owning issue. Produce
-  no evidence documents; the plan, findings, and reviews are the only records.
+  Apply the [Acceptance criteria](#acceptance-criteria) contract below. Use the plan,
+  findings, reviews and CI artifacts as the records; produce an additional checklist or
+  evidence document only when the issue or repository requires it, deriving results from actual runs.
 - **Delivery.** A dependent starts on its parent's finished code. Stack its PR on the parent's (a GitHub-native
   stack) under a live Mergify queue; chain it when the merge keeps commits; else open it once the parent merges. Live
   steps are only the read-only warehouse canary (never blocks) and the isolated, run-owned resources
   [preflight.md](references/preflight.md#never-block-on-the-human) allows.
 
+## Acceptance criteria
+
+Treat Acceptance Criteria, other issue requirements and later corrections as the contract.
+Reuse or implement automated tests at the lowest sufficient level. Workers deliver behavior
+and tests, run focused local checks, and return with CI pending. CI qualifies the candidate;
+the coordinator verifies results. Human or hardware criteria stay pending until their step passes.
+
+At preflight, record coverage, missing automation, the CI lane and manual remainder in
+findings. Reuse sufficient tests; one may cover several criteria. Acceptance-focused issues
+are supported: automate criteria, fix in-scope defects and qualify results in CI.
+Tests added or code merged alone do not satisfy acceptance.
+
+Defer acceptance only when the issue or agreed policy assigns it to a later gate; link
+its owner. An issue requesting the campaign remains incomplete until its criteria pass.
+Preserve required checks and merge rules. Surface missing execution or enforcement;
+change neither branch protection nor acceptance scope without authorization.
+
 ## Delivery progress
 
 Before briefing or continuing a unit, read [delivery-progress.md](references/delivery-progress.md).
@@ -219,6 +235,9 @@ that same `planRevision`.
 
 ## Done
 
+Check each issue's [acceptance contract](#acceptance-criteria) against qualifying results;
+record later-gate obligations. A merged PR does not close pending acceptance.
+
 First [clean every delivered unit's environment](references/done.md#clean-before-handoff), then
 [settle blocked units](references/done.md#settle-blocked-units). Every PR is reviewed, green on its exact HEAD, and merged (`autonomous`) or
 handed back merge-ready (`supervised`). For a blocked unit, hand back it, its

package/skills/engineering/resolve-issues/references/ci.md

@@ -7,6 +7,18 @@ the queue owner's watcher where applicable. Workers may make short status reads
 fetch failed logs for diagnosis, but must not run `gh run watch`,
 `gh pr checks --watch`, a delivery watcher, or create background monitoring.
 
+Qualify the issue's Acceptance Criteria as well as required repository checks.
+Verify that the mapped tests actually ran in the assigned lane against the intended
+candidate and their assertions cover the claimed behavior. A skipped case, missing
+acceptance job, or green unrelated check is not acceptance. Use CI results and artifacts
+for any required checklist; retain manual or explicitly later-gate obligations with
+their owner. Worker completion with CI pending is not issue acceptance. Queue checks
+qualify the combined candidate; post-deploy checks qualify the deployed revision.
+Require each result at its assigned stage: PR admission checks before enqueue,
+queue acceptance before merge, and deployed acceptance after deployment or before
+promotion as specified. Queue-only acceptance is pending at admission, not missing
+PR CI; it cannot be required to pass before the queue candidate exists.
+
 1. Watch the required checks for every pushed HEAD. Pushes to the unit's own
    PR branch need no approval. Green means every required check ran and passed
    on that HEAD: a check that never reported is missing, not passed. Example: a

package/skills/engineering/resolve-issues/references/delivery-progress.md

@@ -59,6 +59,8 @@ acceptance bar, launch-authority rules and history; it is not a new setup or pro
 - model id, effort, and a required read-back
 - an absolute skill path when the stage invokes a leaf skill; for validating, the unit's `proof.suite` `skill` (read it first) and `local`, when set
 - the outcome and validation, with no prescribed method or evidence format
+- the Acceptance Criteria mapping: existing or missing tests, qualifying CI lane,
+  and manual or explicitly later-gate obligations; include any issue-required checklist
 - the [immediate acceptance checkpoint](#delivery-progress), existing baseline (or none),
   and, for a continuation, the last result, remaining uncertainty and next distinguishing
   test; retain the same checkpoint/history when changing workers

package/skills/engineering/resolve-issues/references/done.md

@@ -31,6 +31,11 @@ cancelled, pending, or merge-ready handed-back unit that keeps its environment.
 
 ## Close the run
 
+Before closing, distinguish run completion from issue acceptance. Verify the issue's
+Acceptance Criteria against qualifying CI results and required manual results. Keep
+an issue open when its own acceptance remains pending, even if its automation PR
+merged or its human-only remainder was excluded. Link that obligation in the report.
+
 After the report ([SKILL.md](../SKILL.md#done)):
 
 The run is done when nothing it can do is left: every unit landed,

package/skills/engineering/resolve-issues/references/exploration.md

@@ -125,6 +125,12 @@ The coordinator and any delegated explorer use these rules:
 5. **`layers`:** the parts changed (`backend`, `web`, `android`, `shared`,
    `migration`).
 6. **`proof`:**
+   Map the issue's Acceptance Criteria and other binding requirements to existing
+   tests, missing automation, the qualifying CI lane, and any manual remainder in
+   the existing notes/proof fields. Preserve criterion identifiers when supplied;
+   no new ledger or schema is required. For acceptance-focused issues, include
+   implementing the cases and connecting their execution to CI in the unit's scope.
+
    - `level`: the weakest the run can reach that shows the behaviors work:
      `unit`, `database`, `browser`, or `emulator`.
    - `suite` (`browser`/`emulator` only): the repository's end-to-end suite
@@ -157,9 +163,10 @@ The coordinator and any delegated explorer use these rules:
      Example: a campaign's 25 scenario groups each cover one feature issue; 20
      share "owned emulator, database, and fixture pool" (900 lines).
 
-   `level` is coding acceptance. Integrated acceptance the spec or repository
-   assigns to a later gate (a release device campaign, all-ABI or signed
-   builds, a cross-feature journey) goes in `handback`, naming its gate.
+   `level` selects the test depth for automated acceptance. Put integrated acceptance
+   in `handback`, naming its gate and owner, only when the issue or agreed repository
+   policy assigns it to a later gate. A cross-feature or device journey is not deferred
+   merely because it is expensive; an issue requesting that acceptance still owes it.
 7. **`estimatedLines`: your honest estimate of changed source and test
    lines,** excluding generated files and docs, including every missing
    prerequisite. Do not pad it: the size check scales it by 1.3.

package/skills/engineering/resolve-issues/references/implementation.md

@@ -27,7 +27,8 @@ the coordinator.
    not the backend suite.
 5. **Run focused checks locally; CI runs the rest.**
    Example: run the touched package's tests and typecheck, push, and let CI
-   run the full matrix. Never rebuild a release device campaign in a unit.
+   run the full matrix. Run release campaigns only at their assigned gate;
+   implement campaign automation when the current issue requests it.
 6. **Report in one short record and return.**
    Example: "Persists the Charge layout per installation. Ran charge tests
    and typecheck: pass. CI: pending. Pending: release device campaign
@@ -156,8 +157,10 @@ On `resume` (in flight, no worker, code not done), continue the unit's
    step, error message and evidence path the worker observed. An exit code alone is
    not a failure; keep the first failure separate from cleanup errors. Fix workers
    write the same file. Return
-   nothing else: no artifact hashes, version inventories, screenshots,
-   copied logs, or earlier attempts. For a continuation, include the current checkpoint,
+   only that result by default. When the issue or repository requires a checklist
+   or evidence document, produce it from actual results and link CI artifacts;
+   otherwise omit artifact hashes, inventories, screenshots and copied logs.
+   For a continuation, include the current checkpoint,
    outcome and relevant prior-result links in the existing integration notes; do not
    duplicate the full attempt history. After focused validation, the permitted push,
    and the result, return without waiting for external CI or PR monitoring. Report
@@ -176,6 +179,11 @@ workers those local facts rather than copying the old transcript. Keep all progr
 
 ## Proof
 
+- **Implement the acceptance contract.** Read the issue's Acceptance Criteria and
+  the preflight mapping. Reuse sufficient tests and add missing assertions at the
+  lowest level that exercises the required behavior. Ensure CI selects and executes
+  them in the assigned lane. Return test/criterion references and pending CI or manual
+  obligations in the existing result; the coordinator qualifies acceptance.
 - **Make diagnostic failures executable.** Reuse the existing test runner/assertions.
   A standalone probe exits nonzero for an unexpected exception, failed assertion or
   result outside the expected contract. A catch used to add context rethrows or sets
@@ -226,12 +234,11 @@ workers those local facts rather than copying the old transcript. Keep all progr
   failure ([expire.md](expire.md#infrastructure-failures)): one bounded
   investigation that fixes what the run can; a shared blocker issue only
   when the cause stays unfound or its fix is human-only. Keep the rest moving.
-- Keep `proof.physical` and integrated release acceptance out of the unit's
-  acceptance. A device campaign, all-ABI or signed build, or cross-feature
-  journey the spec or repository assigns to a release or campaign gate runs
-  at that gate: never rebuild it in the unit. Report it as pending in the
-  result; the coordinator records it once in its owning issue, never as
-  passed.
+- Keep `proof.physical` and explicitly assigned later release acceptance pending
+  at their named gate and owning issue. Build the automated tests the current issue
+  requests even when CI runs them as a campaign. If the current issue requests the
+  campaign's result, test implementation alone is not completion. Report manual or
+  unavailable checks as pending, never passed.
 
 ## Scheduling
 
@@ -384,11 +391,15 @@ parent another child holds.
    line's PRs bottom first (`--base <targetBranch>` when it is not the default
    branch); with the Mergify stack hooks installed, push with the `mergify`
    skill's `stack-push.mjs` instead. Keep the body to one short record:
-   `Closes #<issue>`, the behavior delivered, the checks run with their
+   the issue link, the behavior delivered, the checks run with their
    results, and any outstanding blocker or pending obligation as an issue
    link; add the parent PR in `stack` and `chain` mode. CI posts its own run link; cite
    CI-generated artifacts where provenance is required, never hashes or
    logs copied by hand.
+   Use `Closes #<issue>` only when merging this PR will satisfy that issue's own
+   acceptance contract. With outstanding manual or post-merge acceptance, use
+   `Refs #<issue>` in both the PR body and commit message so merging automation
+   does not close the original issue. The coordinator closes it after acceptance.
 3. Record the PR URL and `headSha`; once the code is done, start review while CI runs. Mark the
    PR ready only when review passes and CI is green on the same HEAD
    ([ci.md](ci.md)).

package/skills/engineering/resolve-issues/references/preflight.md

@@ -155,6 +155,12 @@ Example: epic #12's #20 (signed release and go/no-go) and #21
 (physical acceptance) stay out of the plan; the run ends when its code units
 land instead of waiting on them.
 
+An automated browser or emulator acceptance campaign is implementable work, including
+when it proves already-merged features. Include its tests, CI execution and requested
+results in scope. For mixed automated/manual criteria, keep the automation unit and
+record the human-only remainder with its owner; report the original issue incomplete
+until that remainder passes. Exclusion records a pending obligation, not acceptance.
+
 ## 4. Assess the plan
 
 Follow [exploration.md](exploration.md#choose-the-owner) on the provisional

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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.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.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Document and Image Authenticity

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

@@ -12,7 +12,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.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Fraud Detection

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
   fraud rule discovery (fraud-detection) or TLD / MCC-miscoding
   clusters (tld-detection).
-release-version: 0.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Payment Analysis

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

@@ -5,7 +5,7 @@ description: >
   and investigate selected merchants' authorization, settlement and disputes,
   including descriptor mapping and overlapping exports. Portfolio-level payment
   overviews belong to payment-analysis; fraud rule discovery belongs to fraud-detection.
-release-version: 0.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Portfolio 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-detection).
 disable-model-invocation: true
-release-version: 0.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # Similar Domain

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

@@ -6,7 +6,7 @@ description: >
   patterns, with USD and BIN-country currency views, group profiles and priorities.
   Not payment-analysis, fraud-detection, or website research.
 disable-model-invocation: true
-release-version: 0.50.0
+release-version: 0.50.1
 ---
 **Updates:** Once/session run `node <skill-base-dir>/release-check.mjs`.
 # TLD detection