en un clic
artifact-review
// Use this when the user wants a draft paper, figure bundle, README, release page, or experiment artifact reviewed before sharing. Checks evidence binding, claim scope, captions, layout clarity, and release readiness.
// Use this when the user wants a draft paper, figure bundle, README, release page, or experiment artifact reviewed before sharing. Checks evidence binding, claim scope, captions, layout clarity, and release readiness.
Use this when the user needs to choose between multiple ML routes after survey but before committing to implementation. Compares candidate approaches, selects one, records rejected routes, and keeps a fallback.
Use this when the project needs real baseline results before or alongside the main model. Runs classical or literature-aligned baselines under the same protocol and writes a reproducible baseline summary.
Use this when the project needs a dedicated data-quality review before model review. Checks data reality, split correctness, label health, leakage risk, shape consistency, and mock-data disclosure.
Use this when the user wants to improve chart quality, standardize plotting style, regenerate release figures, or add captions/protocol notes. Normalizes fonts, colors, legends, units, and scope notes across Scientify figures.
Use this when the user wants to improve README, docs pages, or microsites so a new reader can understand what the project is, how to use it, what artifacts exist, and what the scope boundaries are within one screen.
[Read when prompt contains /research-experiment]
| name | artifact-review |
| description | Use this when the user wants a draft paper, figure bundle, README, release page, or experiment artifact reviewed before sharing. Checks evidence binding, claim scope, captions, layout clarity, and release readiness. |
| metadata | {"openclaw":{"emoji":"🧾"}} |
Don't ask permission. Just do it.
This is a release-readiness review skill. It does not invent new claims or run new experiments. It checks whether the current artifacts are safe to share.
review/artifact_review.mdreview/release_checklist.mdreview/release_gate.jsonUse this for any mix of:
paper/draft.mdpaper/figures_manifest.mdreview/draft.mdexperiment_res.mdREADME.mddocs/index.htmlReview the artifact set in one or more of these modes:
paper review
figure review
release page review
style review
List the files being reviewed, the headline claims they appear to make, the source artifact path for each headline claim when available, which figures or tables support them, and which review mode applies to each file (paper review, figure review, release page review, or style review).
Write artifact_review.md as a findings-first review using severity levels:
P0 = unsafe to publish as-isP1 = materially weakens the claim or readabilityP2 = polish or consistency issueEach finding must include:
evidence_path (N/A if the issue is structural rather than evidence-bound)affected_claim_id (N/A if the issue is not tied to a specific claim)Also write a top-level line:
release_verdict: HOLD | CONDITIONAL_GO | GO
Use these verdict rules:
HOLD
P0 finding existsCONDITIONAL_GO
P0 findings exist, but one or more unresolved P1 findings remainGO
P0 findings remainP1 finding weakens a headline claimWrite release_checklist.md using the checklist in references/review-checklist.md.
If style review applies, also use references/style-review-checklist.md.
Then write review/release_gate.json using references/release-gate-template.md.
If a paper-facing figure set exists, explicitly check the figure-text contract across:
paper/claim_inventory.mdpaper/figures_manifest.mdrelease_gate.json should include:
release_verdictgenerated_atreview_scopeblocking_findingsp1_findingschecked_filesstale_if_any_newer_thanUse stale_if_any_newer_than to list the release-facing artifacts that would invalidate the current gate if they change later, for example:
paper/draft.mdpaper/claim_inventory.mdpaper/figures_manifest.mdREADME.mddocs/index.htmlsupports_claim_ids, a usable callout_sentence, and a caption that names baseline, metric, evidence type, and protocol when relevant.review/release_gate.json matches the current verdict and names the files that would make the gate stale if changed later.