Static reading edition · s10-05

Choose high-value, bounded CLI tasks

Working from the command line14 min estimatedApp-based lab / Optional CLI

Select a repeatable local task whose inputs, permissions and verification make scripted execution useful.

Understand the approach

The strongest first CLI use case is a task with clear local inputs and an easy result check. Examples include summarizing documented setup, drafting release notes from a selected diff, identifying unsupported README claims or explaining a failing test log. These tasks reduce repetitive reading without requiring the agent to publish, change accounts or coordinate a complex external workflow. Start with a real recurring need, not with a desire to automate everything.

Choose an input boundary and output contract before running the agent. A release-note draft should name the exact diff or commit range. A log explanation should separate observed error messages from hypotheses. A small code fix should identify the failing behavior and the relevant test. A large prompt that simply says “improve the repository” lacks a stable basis for either safe execution or meaningful acceptance.

Repeatability requires more than a command that runs twice. Record the source version, working directory, client assumptions and validation method. If a report changes, you should be able to tell whether the source changed or the task was underspecified. For edits, preserve a baseline and inspect the final diff. For read-only analysis, compare the answer with the named inputs. Keep publication, scheduling and external communication as separate authorized actions.

Select a bounded useful task, run it manually, validate its inputs and output, and only then reuse it in a script. A regression or a missing input returns to the tested task definition.
Open the full diagram

A useful pipeline has an input and an acceptance rule

The batch has two explicit inputs, two distinct project names and two documented commands. verify-extraction.cjs accepts each current answer against its own source and rejects a crossed directory, fabricated claims, malformed JSON, missing fields and undocumented source. These results establish the offline consumer contract, not AI generation quality.

The provided synthetic log shows uppercase and padded-query failures. A grounded draft cites expected=2 actual=0 and proposes normalization as a hypothesis tied to notes.cjs; it does not announce a deployment outage or claim a fix ran. Use the app while exploring the task, then a one-shot pipeline after its inputs and check are stable.

When to stay interactive

Stay interactive when exploring requirements or reviewing a visual result. Scripted execution fits a stable contract. Once the task works, package its repeatable guidance as a focused skill or reviewed script, keeping the uncertainty and verification requirements visible.

About your environment

Checked 21 October 2026. Feature availability varies by client and host.

Try it step by step

Name two source directories and separate outputs for the same narrow extraction contract.
Run the offline current, wrong-directory and missing-source cases.
Draft a log explanation from the supplied exact expected/actual lines and inspect its claims.
Choose any authenticated batch or pipe separately, preserving actual status and keeping publication or schedules outside the lab.

A useful starting example

Illustration · adapt before use.

Two current sources and failure cases without an authenticated model shell

node labs/cli-pipeline/verify-extraction.cjs
node --test labs/cli-pipeline/extraction.test.cjs

Optional PowerShell input piping — authenticated CLI execution powershell

Get-Content -Raw ./sample.log | codex exec --sandbox read-only -o ./log-triage.md "Explain only the supplied synthetic failures. Cite exact log evidence; distinguish hypotheses from observed facts. Do not edit source files or contact services."

A local, read-only release-note draft shell

codex exec --sandbox read-only -o ./release-notes-draft.md "Inspect the current uncommitted diff in this practice repository. Draft release notes describing only observed user-visible changes. Flag uncertain impact and exclude unrelated existing changes. Do not commit, create a PR, send messages or publish a release."

From input to result

Prove a repeatable local reporting contract

Evaluate the supplied fixtures before connecting any real agent process. This is an offline workflow test.

Worked input text

Input cases: completed / failed / malformed / incomplete / producer failure
Output contract: Markdown report + meaningful process exit
Acceptance: correct classification and preserved failure evidence

Expected result · compare with your run

Only the completed fixture returns exit 0.
Every failure class remains visible to a downstream caller.
No report is automatically published or treated as accepted business output.

A useful repeatable task needs a consumer that behaves correctly on missing and failed inputs, not merely a pleasant success summary.

Hands-on exercise

Your turn

Use the two fixture projects as a bounded batch: one output per named source and separate paths. Compare red and blue authored answers, then validate red against blue and a missing source contract. Inspect sample.log and draft a source-cited explanation in the app. If you choose actual CLI piping later, retain producer status and keep publication or scheduled execution separate.

Try the exercise before opening its reference answer. Use a disposable practice folder.

Run the practice

Offline CLI event pipeline

Extract into a new practice folder and keep the included labs folder. Run these commands from that extraction root, or from the course folder, using an existing Node.js installation.

Download this lab ↓

Command 1 text
```
node labs/cli-pipeline/verify-extraction.cjs
```
Check: Two named sources accepted individually; crossed and missing inputs rejected with explicit reasons.
Command 2 text
```
node --test labs/cli-pipeline/extraction.test.cjs
```
Check: 12 local counterexample tests pass; no credentials, Codex task or schedule is used.

Inspect the actual filesBatch and failure verification ↗Counterexample tests ↗Synthetic local error log ↗Command-family answer matrix ↗

Commands are relative to the course folder. Open the lab in the Codex app first. Lesson-specific artifacts separate offline execution from optional authenticated CLI observations; a dry-run plan is not a live model result.

Check your result

The chosen task has bounded inputs, a concrete output and a verification method that fits the result.
Changed and missing inputs produce appropriately different answers, with uncertainty reported rather than hidden.
The workflow remains local and does not silently add publication, messaging or recurring execution.

Reference answer & rubric Try the exercise before opening

Choose one bounded reporting task and prove its failure behavior before considering reuse or automation.

Name both source folders and separate output paths before planning a batch.
Run verify-extraction.cjs and inspect crossed-directory and missing-source counterexamples.
Explain sample.log from expected/actual lines, keeping the cause a hypothesis until checked.
Choose real CLI execution separately; capture status and keep publishing/schedules outside the lab.

Think it through

Check your understanding

Which is the best first scripted task?

Improve everything and publish the result.
Summarize one selected local diff into a draft that you inspect.
Rotate credentials whenever a command fails.

Reveal the answer and explanation

Answer 2: Summarize one selected local diff into a draft that you inspect.

A selected local diff gives a bounded source and an inspectable drafting output, making usefulness and correctness easier to assess.

Take this quiz in the interactive lesson to save your answer in the browser.

When it does not work

A clean or missing input produces invented release notes.

Likely cause: The prompt or consumer lacks an explicit empty-input outcome.

What to try: Require an honest no-relevant-changes result and test it before reuse.

The workflow is scheduled before its contract is stable.

Likely cause: A single successful run was mistaken for dependable repeatability.

What to try: First pass the local failure matrix and review the output; scheduling requires a separate decision.

Common mistakes

Automating a broad vague task before proving a small manual workflow works.
Treating a polished draft as evidence that it was reviewed, sent or accepted by its intended audience.

Source mapping & differences · equivalent

The source’s high-value CLI scenarios transfer as bounded local workflows, with Codex commands, explicit input contracts and separate authorization for consequential actions.

Source topic: High-value use cases ↗

Go to the source

Official documentation, checked 21 October 2026. Product names, controls and availability may vary with your version, platform or account.

Continue in the interactive lesson →

Completion and quiz progress are saved
only in the interactive course.