Adapter authoring
Choose the simplest implementation that reliably performs the requested task.
Use an existing site adapter when it already covers the capability:
opencli list search --site example
opencli example search --help -f json
list returns {ok:true,data:{commands,total,nextOffset?}}; use --offset to
continue, --limit to adjust page size. Detailed arguments belong in command help.
Evidence available to you
opencli browser open https://example.com --session research
opencli browser state --diagnostics --session research
opencli browser network --session research
opencli browser network --static --session research
opencli browser network --detail RequestKey --session research
Network captures describe observed requests. Static analysis adds candidates
from loaded scripts without executing them. Inspect source locations, unresolved
expressions and capture provenance. Replay read requests when useful and compare
business data with the page. Write commands have real effects, including when run
through adapter test; use a suitable test account or a supported dry-run.
Prefer public APIs with a stable contract when available. Browser fetch, captured
responses, page state and semantic UI interactions are also valid choices. Select
based on the task and observed reliability. Do not guess endpoint parameters or
hide failed operations behind empty success results.
JS interface
Adapters are ordinary files under ~/.opencli/clis/<site>/<command>.js or repository
clis/<site>/. There is no draft directory, promotion step or required memory file.
opencli adapter init example/search
The existing cli({...}) interface is unchanged: func(args) for Node execution,
func(page, args) with browser: true. Reuse neighboring adapters and shared helpers.
Return business data; the CLI adds the JSON success envelope. Throw a typed error
with an actionable hint for failures. Use access: 'read'|'write' accurately.
columns controls human table exports; JSON preserves nested results.
import { cli, Strategy } from '@jackwener/opencli/registry';
cli({
site: 'example', name: 'search', description: 'Search example items',
access: 'read', strategy: Strategy.PUBLIC, browser: false,
args: [{ name: 'query', positional: true, required: true }],
func: async (args) => {
const response = await fetch(`https://example.com/api/search?q=${encodeURIComponent(args.query)}`);
if (!response.ok) throw new Error(`Search failed: HTTP ${response.status}`);
return response.json();
},
});
Check and exercise
opencli adapter check example/search
opencli example search 'query'
opencli adapter test example/search --args '{"query":"query"}'
check validates definitions without executing adapters. test executes the normal
CLI and optionally compares an existing fixture. --write-fixture, --update-fixture
and --no-fixture control optional expectations; no row-shape or site-memory gate
is imposed. --trace retain-on-failure helps diagnose browser execution.
For repository changes, cover the core behavior and failure paths with focused
production-path tests, typecheck and build. Verify IDs, fields, units, pagination
and empty/error semantics relevant to the task. Do not automatically replay a
write with an unknown outcome; inspect state first.
Optional references
Read only what is useful for the current task: references/adapter-template.md
for adapter patterns, api-discovery.md for request investigation,
output-design.md for result fields, field-decode-playbook.md for opaque fields,
and deep-recon.md for difficult private protocols. Site notes and fixtures are
optional knowledge aids; older reference checklists are not mandatory workflows.