← Back to Programming and automation
OpenClaw program-building

Artifact-first utility requests

This page is a useful request-shape database: what kind of helper to ask for, when that helper shape fits, and examples of real deliverables worth building.

Request ruleThe output should be a named artifact at a known path with a real verification step, not just “some code.”
Helper shapes

The utility types worth asking for repeatedly

Small script helperBest for one-command automation of a repeated manual task.
Local viewer or preview helperBest for repeatedly inspecting generated files, PDFs, screenshots, or outputs.
QA or validation helperBest for repeated pass/fail checks on a workflow, bundle, or route set.
Import/export converterBest for deterministic file or data reshaping.
Tiny status helperBest for repeated monitoring or health snapshots.
Useful examples

Concrete artifact-first utilities that are genuinely worth building

Live route validatorA CLI that checks URLs for status, title, canonical, hero asset, and outputs a CSV report.
Screenshot batch toolA helper that captures mobile and desktop screenshots for a URL list into predictable folders.
Content inventory exporterA scanner that maps slugs, titles, dates, assets, and missing metadata across a site section.
Repair helperA narrow script that updates one known broken URL pattern or content defect across many files.
Ops watchdogA status-and-recovery helper that detects stalled work and recommends or performs the next safe restart step.
Repair path

How to request a fix when the utility already exists

When the helper already exists, name the current path, preserve working behavior, fix only the exact defect, and ask for verification against both the old baseline and the repaired path. That prevents “helpful” rebuild drift.

Open deeper reference links for this page