agentic-workflowCAUTION
Your agent says the tests passed. wf makes it prove it: a delivery workflow for Claude Code and Codex with engine-written evidence, independent review, and tracker readback.
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
Your agent says the tests passed. wf makes it prove it.
[](CHANGELOG.md) [](https://github.com/o-m-a-r-k/agentic-workflow/actions/workflows/ci.yml) [](LICENSE)
Coding agents are fast; checking what they report is the slow part. agentic-workflow is a delivery workflow for Claude Code and Codex, and every "done" it reports comes with a receipt: a hash-chained ledger of which tree the gate ran on and which steps it reused, who reviewed the change (never its author, checked from the agent transcripts where they exist), what they found, and the tracker's own readback of the handoff. The wf CLI is the only thing that writes that record; agents can say anything, and wf accepts only what its engine recorded.
Status: v0.4, early. The engine, CLI, onboarding, three lanes and three built-in trackers (Linear, GitHub Issues, tickets as files) are covered by scenario tests on real git repositories, run on macOS and Linux in CI (the badge above). It has not been proven on a production project yet; expect rough edges and breaking changes before 1.0. Changelog · design.
See it
The recording is real wf output from examples/hello-ticket (plain text); run it yourself with the command under Try it.
The problem
An agent's report is a claim. The failures that cost the most time are the ones a claim hides:
- the agent says the tests pass, but they never ran on the code being
05dfa1ab7673OBSERVED · 2026-10-11Install
Commands as the repository documents them. They are shown, not run.
claude plugin install agentic-workflow@agentic-workflow
git clone https://github.com/o-m-a-r-k/agentic-workflow && cd agentic-workflow
claude plugin install agentic-workflow@agentic-workflow
Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned | |
| codex | mentioned | |
| cursor | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
--- name: onboard description: Onboard the current project to agentic-workflow. Use when the user asks to set up, onboard or enable agentic-workflow (or "wf") in a project. Detects repos, components, commands and secrets, confirms them with the user, and proves the setup with wf doctor. --- # Onboard a project `wf` is the agentic-workflow CLI. If `wf` is not on PATH, run `node <this plugin's root>/bin/wf install` once (the plugin root is the folder holding this skill's `skills/` directory), or call `node <plugin root>/bin/wf` directly. 1. **Detect.** Run `wf init` at the project root (the repo, or the folder holding several repos). It drafts `.workflow/project.yaml` (disabled), `.workflow/secrets.yaml` (names only) and `.workflow/AGENTS.invariants.md`. In a multi-repo folder the adapter is written into the first repo and the folder's `.workflow` links to it; change `adapterRepo` if another repo should hold it. 2. **Confirm the system with the user.** Show a table of components (id, kind, repo/package, what it provides, what it depends on) and a dependency diagram. Ask them to confirm, rename, add missing components (including services in repos not checked out and third parties), and mark contracts that must never break. 3. **Ask only what you can't detect.** First the tracker, as two questions: - **Where do your tasks live?** Linear (`kind: linear`, its team), GitHub Issues (`kind: github`, `repo: owner/name`), markdown tickets in the repo (`kind: files`, one `tickets/<id>.md` each with YAML frontmatter `id, title, status, labels`; `wf init` drafts this when it finds them), or nowhere (`kind: none`, requests passed as files). Then the status names for started / delivered / done (on GitHub these are labels). - **How should wf reach it?** Prefer a route where the engine acts and reads back itself: `via: files` (files), `via: cli` (GitHub through the owner's existing `gh` login; wf never sees or prints the token), `via: api` (Linear or GitHub with a key the owner enters in step 5 with `wf secrets guide <KEY>`, catalogued in `.workflow/secrets.yaml` with `required: true`: `LINEAR_API_KEY` or `GITHUB_TOKEN`). `via: connector` is a first-class choice (you call the tracker's MCP tools; no key for wf). In Claude Code and Codex its handoff is host-recorded: `wf tracker record --from-transcript` takes the tracker's answer from the session transcript the host writes and checks it like an API readback; elsewhere it is agent-reported (unverified). `api`, `cli` and `files` are engine-read. Run `wf doctor` and tell the user the level it prints. Say this trade-off in those words and let the user choose. Write the choice with `wf tracker mode <via> --write` and tell the user what `wf doctor` prints as verifiable for that combination. On GitHub, screenshots go to a `wf-attachments` prerelease as assets. If the repository is public (`gh repo view <owner/name> --json isPrivate`; treat unknown as public), tell the user plainly that delivered screenshots will be publicly downloadable and ask which they want: keep it (write `publicAssets: acknowledged` under `tracker:` and commit it on the base branch; without it `wf deliver` refuses to upload screenshots there), switch to the files tracker, or keep the issues in a private repository. Then lanes (quick, standard, batch), the real invariants, and the product stage (pre-launch or live) — write the stage and invariants into `.workflow/AGENTS.invariants.md`. 4. **Gate steps.** Walk through each detected step: command, inputs, tier (light/heavy), lease, workers. Fix anything wrong in the draft. Add steps the detection missed. 5. **Secrets.** `wf init` catalogues only keys a detected step's command names; the rest are listed in a comment in `.workflow/secrets.yaml`. Add a key only when a gate step needs it, with `usedBy: [step ids]` (or `required: true`). Show the catalogued keys as a table (key, purpose, used by, kind, state from `wf secrets status`). Fill in `obtain` (console URL and steps) for each provided key. Run `wf secrets init` for generated and test keys. Only if `wf secrets status` reports a needed key missing, ask the user to run `wf secrets guide` **in their own terminal** — never in this session, never with `!`, never pasting values into chat. Poll `wf secrets status` until it says `nothing to enter`. 6. **Skills, connectors, tools.** List what the roles need. Vendor skills into `.workflow/skills/<name>/` only when the license allows (show it), add them under `requires.skills`, run `wf sync`. For connectors (the tracker), check with one read-only call and tell the user exactly where to connect it if missing. 7. **Prove.** After committing and pushing the adapter, run `wf doctor`. Config problems: fix the draft and rerun. Tests already failing on a clean base: fix them as the first quick fix; if the fix is large, stop and show the user the failing suites and logs. 8. **Enable.** Commit `.workflow/` on the base branch of the adapter repo and push it (the gate trusts only the adapter on the base it starts from), then `wf enable`. Tell the user what was set up and what is still pending.
Trust audit
CAUTIONgrade C · trust 70/100 Install with care. The audit found things worth knowing before you trust its output.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | WARN |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- declared (10 observation(s))
- Network
- declared (5 observation(s))
- Shell
- declared (5 observation(s))
- Dependencies
- not all pinned
- Secrets in source
- found
Findings (25)
const secret = 'tok_ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
const token = 'ghp_echoedTokenValue12345';
const TOKEN = 'ghp_fakeApiTokenForTests123';
process.stdout.write('github.com\n ✓ Logged in to github.com account tester (keyring)\n - Token: gho_fakeTokenThatMustNeverBePrinted\n');import { readRegular, writeNoFollow } from '../../engine/evidence.mjs';import { canonical, isInside, touchesEvidence } from '../../engine/paths.mjs';import { YAML } from '../../engine/util.mjs';import { cliEnv } from '../../engine/scrub.mjs';var identity = require('../../nodes/identity.js');const p = singleRepoProject('exfil-gh-env', { tracker: { kind: 'github', repo: 'acme/app', via: 'cli', statuses, publicAssets: 'acknowledged' } });const dbDir = tmp('exfil-echo');const p = singleRepoProject('exfil-echo-proj', { tracker: { kind: 'github', repo: 'acme/app', via: 'api', apiUrl: url, statuses } }, keys('GITHUB_TOKEN'));const p = singleRepoProject(`exfil-linear-${apiUrl.length}`, { tracker: { kind: 'linear', via: 'api', apiUrl, statuses } }, keys('LINEAR_API_KEY'));const ok2 = singleRepoProject('exfil-linear-other', { tracker: { kind: 'linear', via: 'api', apiUrl: 'https://linear.example.test/graphql', statuses } }, keys('LINEAR_API_KEY'));return { url: `http://127.0.0.1:${fs.readFileSync(`${file}.port`, 'utf8')}/graphql`, read: () => JSON.parse(fs.readFileSync(file, 'utf8')), stop: () => child.kill() };return reply(200, { data: { fileUpload: { uploadFile: { uploadUrl: `http://127.0.0.1:${port}/upload/${encodeURIComponent(variables.filename)}`, assetUrl: `https://uploads.linear.app/fake/${encodeURICoconst url = `http://127.0.0.1:${fs.readFileSync(`${db}.port`, 'utf8')}`;return { url: `http://127.0.0.1:${fs.readFileSync(`${file}.port`, 'utf8')}`, stop: () => child.kill() };const str = atob(src.replace(/[\n\r]/g, ''));
for (const id of ['../x', '..', 'a/b', '/abs', '.hidden', '-flag', 'a\u0000b', 'x'.repeat(200), 'OK-1', 'ОK-1', 'a\\b', 'trail.']) {{ name: 'an invisible character', value: () => path.join(f.root, '.wf-evidence', 'x.json'), re: /is inside \.wf-evidence/ },'cat .wf-ev$(echo)idence/a', 'cat *evidence/a', 'cat .wf-evidence/a', 'cat .wf-evidence/a', 'cat .wf-evidence/a',
{ file_path: '/p/.wf-evidence/a' }, { file_path: '~/p/.wf-evidence/a' }, { file_path: '/p/.wf-evidence/a', edits: [{ old_string: 'a', new_string: 'b' }] },for (const id of ['../outside', '../../x', 'a/b', '/abs/path', '.hidden', '-dash', 'a.b', 'a_b', 'x'.repeat(65), 'L‐1', 'L-1', 'ok id', '']) {for (const id of ['../x', '..', 'a/b', '/abs', '.hidden', '-flag', 'a\u0000b', 'x'.repeat(200), 'OK-1', 'ОK-1', 'a\\b', 'trail.']) {Gates applied: no_behavioural_pass.
05dfa1ab7673full audit observations/trust-audit/skill/o-m-a-r-k__agentic-workflow.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-11 | 05dfa1ab7673 | CAUTION | C | 70 | first audit |
Questions
What does the agentic-workflow skill do?
Your agent says the tests passed. wf makes it prove it: a delivery workflow for Claude Code and Codex with engine-written evidence, independent review, and tracker readback.
Is agentic-workflow safe to install?
With care. The audit graded it C (70/100) and found 25 things worth knowing before you trust this skill, listed below with the exact line each was found on.
What can agentic-workflow access on my machine?
The audit observed that it reaches the network, runs shell commands and reads or writes files. Each of those is consistent with what it says it does. Secrets in the source: found — see the findings.
Which assistants does agentic-workflow work with?
Its documentation mentions claude-code, codex and cursor. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (05dfa1ab7673), read on 2026-10-11. The repository is watched, and a new audit runs when it changes — this is the first audit.