Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add VKirill/claude-lane-stack --skill codex-lanegit clone --depth 1 https://github.com/VKirill/claude-lane-stackWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vkirill/claude-lane-stack/codex-lane)<a href="https://agentmods.dev/skills/vkirill/claude-lane-stack/codex-lane"><img src="https://agentmods.dev/badge/skills/vkirill/claude-lane-stack/codex-lane/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/vkirill/claude-lane-stack/codex-lane"><img src="https://agentmods.dev/badge/skills/vkirill/claude-lane-stack/codex-lane.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00035 | $0.00948 |
| Opus 5.5 | $0.00014 | $0.00379 |
| Sonnet 5.5 | $0.00007 | $0.00190 |
| Haiku 4.5 | $0.00003 | $0.00095 |
Grade A, and why
codex-lane scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 20d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Codex Lane
Use the installed typed wrappers under ~/.agents/bin. Keep the run directory,
task file, and project root supplied by the user or existing run state. Do not
invent a run, task id, path, model, or receipt.
Dependencies
Check the wrappers before acting when the installation is uncertain:
command -v run-controller lane-ctl night-review
run-controller --help
lane-ctl --help
The wrappers may be invoked by absolute path (~/.agents/bin/...) when PATH
does not include ~/.agents/bin. Their lifecycle state lives under the run's
.agents/runs/<slug>/ directory.
Run and resume
For an existing schema-v2 run, validate and start the durable controller. Keep
the run's configured writer by default; add --provider codex only when Codex
is the explicitly selected writer:
run-validate --run-dir "$RUN_DIR" --phase pre-dispatch
run-controller start --run-dir "$RUN_DIR" --project-cwd "$PROJECT_CWD"
run-controller watch --run-dir "$RUN_DIR" --timeout 240 --json
run-controller start is idempotent and resumes persisted controller state.
Use a fresh bounded watch call after an interrupted session. Read the
controller receipt with:
run-controller status --run-dir "$RUN_DIR" --json
Preserve the run's selected native profile, provider, model, reasoning effort, and service tier unless the operator explicitly asks for a change. Do not silently route a run to Codex or override those values.
For one typed lane instead of the DAG controller (use --provider codex only
when explicitly selected):
lane-ctl start --run-dir "$RUN_DIR" --task-file "$TASK_FILE" \
--project-cwd "$PROJECT_CWD"
Status and evidence
Read compact state first, then inspect the bounded journal or a specific log:
lane-ctl status --run-dir "$RUN_DIR" --task-id "$TASK_ID" --json
lane-ctl events --run-dir "$RUN_DIR" --task-id "$TASK_ID" --json
lane-ctl tail --run-dir "$RUN_DIR" --task-id "$TASK_ID" --source report --lines 80
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 20d ago First seen · 114 lines · 35 tokens per session scan A b8c3b9c04ad4
codex-lane is a skill published in the GitHub repository VKirill/claude-lane-stack (122 stars, last pushed 2d ago), licensed MIT. It adds 35 tokens to every session and 948 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-26.
Other skills, from other repositories
issue-triage
3-phase issue backlog management with audit, deep analysis, and validated triage actions. Use when triaging GitHub issues, sorting bug reports, cleaning up stale tickets, or detecting duplicate issues. Args: 'all' to analyze all, issue numbers to focus (e.g. '42 57'), 'en'/'fr' for language, no arg = audit only.
plan-pipeline
Orchestrates the complete planning pipeline: product direction (ceo-review) -> architecture (eng-review) -> implementation plan (start) -> validation (validate) -> execution (execute). Run stages individually or let the orchestrator coordinate the full flow.
dev-docs
A documentation process for recording project progress, architecture decisions, development handovers, and user-visible releases. It organises these records into navigation, dated details, architecture notes, and a changelog.
routines-discover
Analyzes the current project to surface high-value Routines use cases across the three trigger types (schedule, API, GitHub events). Usage: /routines-discover.
ui-sync
A workflow for keeping the user interface's task status in sync when adding new features. It uses task.json as the source of truth and updates runtime progress during building and review.
sprint-end
Use when the user wants to ship a sprint's work to main via PR.