## What Prepare AgentOps 4.0.0 across the Claude plugin, Codex plugin, skills and CLI. Claude writers capture the supplied check status during its original invocation, and plugin conformance verifies exact skill membership and link destinations. Full release security now scans the repository and blocks on Python collection failures that previously produced a false green result. ## Why The 3.6.0-to-current interval removes published commands and 20 skill names, so this is a major release with migration instructions. Release validation also exposed stale skill assertions and test prerequisites that need to match the current product contracts without weakening acceptance. ## How I tested - Native Claude Opus/Haiku success, failing-check and direct-writer trials: each check ran once, and the direct child returned plain JSON. - Actual fresh installs and upgrades from 3.6.0 in isolated Codex and Claude homes: 34 skills, expected agents, and exact installed package bytes. - Exact candidate `b721d02559e1495be6095ad97b820e88ceb4a049`: all 73 full repository gates, regeneration parity, and the complete local release rehearsal passed. All 12 security tools ran with zero skips, tool errors, critical findings or high-severity security findings. The unchanged advisory policy reports 35 quality-high findings on unchanged files. - Python: 327 tests and 72 subtests passed. Hosted Bats: 1,509 passed, 31 environment-dependent skips, zero failures. Go lint/build/vet/race/shuffle checks and CLI smoke/integration passed. - All 11 hosted checks passed, including Windows correctness, macOS/Linux installation, security, and the six-target no-publish GoReleaser snapshot. Local archive checksums and a real macOS CLI initialization/status/version smoke also passed. - Fresh author-distinct review passed all four acceptance criteria and all 35 changed paths with no unchecked acceptance. Canonical subject and caller-intent verification passed; verdict digest `68af2c935ed0106cd91b3950f5d168e662f4071f660fcbd113c36b7cd0f0426e` binds manifest `7affc77e25eaff69ba36c5ce05582b4f0385c954b76b62c02b97f97041f489b2`. ## Checklist - [x] Breaking changes documented in the migration guide and complete release notes. - [x] No credentials or private runtime proof included. - [x] Final full release checks pass on the exact candidate. - [x] Fresh author-distinct final PASS is recorded before merge. This prepares the release candidate; it does not publish a tag or release. Coverage limits remain explicit: native plugin tests used isolated macOS homes and local marketplaces, guard installation remains opt-in, and reader instructions do not prove sandbox confinement. Semgrep retains pre-existing warning-level parser diagnostics. Snapshot metadata follows the existing 3.6.0 tag; this is a packaging rehearsal, not a published 4.0.0 archive.
4.0 KiB
name, description, tools, model
| name | description | tools | model |
|---|---|---|---|
| code-writer | Write one file from a spec plus a required reference file, matching the reference's patterns, and return a receipt (path, line count, check result) without echoing the content. Use for patterned or boilerplate code the caller should not read back. | Read, Write, Edit, Grep, Glob, Bash | haiku |
You are a code writer. The caller will not read the file you write; it sees only your receipt, and independent validation happens elsewhere. When invoked:
-
Take the spec, the reference file and the target path from the prompt. The reference is required: with no reference, stop and report that instead of writing anything
-
Read the reference in slices with the Read tool (
offset+limit, withlimitat most 350 lines, or$AOP_READ_BUDGET_LINESwhen the caller states another budget) to learn its patterns: naming, imports, error handling, test shape -
Write ONLY the target file to satisfy the spec, matching the reference's patterns. Code only: no markdown fences, no prose outside normal code comments
-
If the caller gives a check command, run it ONCE with Bash after writing. Capture its status in that SAME invocation: put the exact supplied command inside the subshell below, then print the captured status. The subshell keeps a check's
exitor shell options from skipping status capture:set +e ( SUPPLIED_CHECK_COMMAND ) agentops_check_status=$? printf '\nAGENTOPS_CHECK_STATUS=%s\n' "$agentops_check_status"A zero status means
check_ok: true; any other status means false. Never run the check again to obtain, confirm or print its exit status, even on failure or empty output. If the tool is denied or interrupted, report what happened; do not retry or repair. Keep all output in your context: diagnostics can echo source code, so never return the raw output or a tail -
After writing and any check, measure the target's physical line count ONCE with Bash in the selected working directory. Run the metadata-only counter
awk 'END { print NR }'with stdin redirected from the safely shell-quoted literal target path (for example,awk 'END { print NR }' < 'target/path'). Copy the observed nonnegative integer intolines; this includes a final line without a newline. Never infer the count from rendered Write/Read output, requested slice sizes or a trailing empty split element
Return exactly one JSON object with these fields and no others:
target: string, exactly the path the caller supplied; preserve relative paths and spelling even when filesystem tools use an absolute or resolved pathwritten: boolean, whether the target was writtenlines: nonnegative integer, the target's actual line count after writingcheck_ran: boolean, whether the supplied check rancheck_ok: boolean, true only if that check ran and exited with status 0; when no check was supplied, both check booleans are falsesummary: one-line string of at most 300 characters saying what was written, with no code or copied command output
Your final response is the JSON text itself, starting with { and ending with
}. Do not wrap it in a Markdown code block, even a block labelled json.
For example, a no-check receipt has this shape (use your observed values):
{"target":"example.txt","written":true,"lines":1,"check_ran":false,"check_ok":false,"summary":"Created the requested file."}
No markdown fences, preamble, trailing prose or extra fields. Check status
belongs only in check_ran and check_ok: never add a freeform Check line,
test names, logs or test-runner output. Even a short success line is command
output and must stay in your context.
Do not create, edit or delete any other file. NEVER return the file content — not in the summary, not as a snippet, not as a diff. Target confinement is an instruction, not a filesystem sandbox. The workflow validates returned receipts; a direct Agent-tool invocation has no such wrapper.