agentleFS
p10ns11yp10ns11y/skills/verification-cockpit/SKILL.md

verification-cockpit

Skill2 starsChanged 40 days agoMITView on GitHub

Generates project-specific tmux verification cockpits for repos that use an av-style agent verify workflow. Reads target project AGENTS.md, setup docs, and scripts; writes .agents/verification/ with SOC-style panes and tiered auto-launch. Use when setting up av layouts, mission-control verify panes, or regenerating .agents/verification after stack changes.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read in order (stop when you have enough signal):

    line 54
  2. Very specific:

    Rule: if it writes deps, data, or project structure → mutate.

    line 74
  3. Distinctive:

    Mandatory: every pane answers *what failure does this surface?* If it does not, omit it.

    line 80
  4. Very specific:

    Golden ratio: all splits use φ ≈ 1.618 → 62% major / 38% minor (bin/lib/verify-layout.sh).

    line 82
  5. Very specific:

    Use verify_layout_build_golden_grid from verify-layout.sh for the default 4-pane skeleton.

    line 96
  6. Very specific:

    Use templates from templates/ in this skill directory.

    line 151
  7. Distinctive:

    Must run inside tmux

    line 156
  8. Distinctive:

    If no cockpit section exists, add under setup/verify:

    line 173

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Verification Cockpit Generator

Portable skill — install from the agent skills library (verification-cockpit/). Primary use: generate layouts in app/library repos you are verifying.

Output: .agents/verification/ in the workspace you are verifying. av auto-delegates when tmux-layout.sh exists there.

Adopt in a target project

Copy or symlink this skill into the project you are verifying:

SKILLS_ROOT=~/skills   # or wherever you cloned the skills library
mkdir -p /path/to/my-app/.cursor/skills
ln -sfn "$SKILLS_ROOT/verification-cockpit" /path/to/my-app/.cursor/skills/verification-cockpit
# or: cp -a "$SKILLS_ROOT/verification-cockpit" /path/to/my-app/.cursor/skills/

Open that project in Cursor, then invoke the skill. It generates .agents/verification/* in that repo — tweak manifest and layout for that stack.

Prerequisite: av workflow with verify-launch.sh + verify-layout.sh on the host. See shell-av-workflow overlay in the skills library.

When to run

  • Target project (or this shell repo as dogfood/stress test) needs a verification dashboard
  • AGENTS.md / README lists verify commands not reflected in panes
  • Stack changed (new pnpm scripts, Rust crate, CI jobs)
  • User asks for "verification cockpit", "av layout", or "mission control"

Workflow

Copy this checklist and track progress:

- [ ] 1. Discover verification commands
- [ ] 2. Classify launch tiers
- [ ] 3. Design pane layout
- [ ] 4. Write .agents/verification/*
- [ ] 5. Symlink .cursor/verify
- [ ] 6. Optional: AGENTS.md cockpit row

1. Discover

Read in order (stop when you have enough signal):

SourceLook for
AGENTS.mdverify-before-done, post-change commands, stability hotspots
docs/SETUP.md, README.mdbuild/test/lint commands
package.json scriptstest, build, lint, dev
Makefile, Cargo.toml, justfilecheck/test targets
.github/workflows/*CI verify steps
.agents/skills/*/SKILL.mddomain-specific verify

2. Classify tiers

TierAuto on av?Examples
monitoryeslazygit, empty console — omit yazi/btop unless they surface verify failures
watchyespnpm test --watch, cargo watch -x check, vitest --watch
verifyconfirm [y/N]pnpm test, cargo test, pnpm build, tsc --noEmit
mutateblocked unless av --launch-mutate + type YESpnpm install, migrations, deploy, format-all

Rule: if it writes deps, data, or project structure → mutate. If it only reads/compiles/tests → verify or watch.

Set risk_profile in manifest: low | medium | high (from AGENTS.md stability contracts).

3. Design layout (two-pass, golden ratio)

Mandatory: every pane answers what failure does this surface? If it does not, omit it. Prefer four high-signal panes over six decorative ones.

Golden ratio: all splits use φ ≈ 1.618 → 62% major / 38% minor (bin/lib/verify-layout.sh). Nest splits so higher priority panes accumulate major shares.

Pass 1 — priority → area

Rank panes priority: 1 (highest) through N. Allocate area in golden proportions:

PrioTypical paneColumn / band
1Primary watcher (test/lint/health watch)Ops column — major height in right stack
2CMD consoleOps column — minor height bottom-right (default focus)
3GIT (lazygit)Left column — major width (62%), full height
4Verify-tier one-shotOps column — minor height top-right
5+Second watcher / domain verifyOnly if distinct failure signal; split ops stack again

Use verify_layout_build_golden_grid from verify-layout.sh for the default 4-pane skeleton.

Pass 2 — context → arrangement

Adjust using space_profile per pane (manifest + reference.md):

ProfileOutput shapeSpace rule
scrollstreaming logs, test outputLargest vertical band in ops stack (right center)
interactiveshort commands, agent_scanCompact bottom band (38% height), bottom-right
tui-sidelazygit, tigMajor left column (62% width), full height
confirm-burstbuild/test on demandSmall bottom band; confirm before run
omitbtop, yazi (default)Do not include in verify window

Default golden grid

+----------------------------+------------------+
|                            | VERIFY (minor)   |
|  GIT (tui-side, 62% w)     |------------------|
|  lazygit full height       | WATCH (scroll)   |
|                            |------------------|
|                            | CMD (interactive)|
+----------------------------+------------------+
     git column 62%              ops column 38%
  • CMD — tier: monitor, no command — agent_scan, gdf, vf
  • WATCH — highest-priority watcher for this stack
  • VERIFY — full-suite or build; confirm in pane
  • Optional second window verify-risk only when many amber/red commands would crowd one window

Value audit (before shipping)

- [ ] Each pane has `value:` in manifest — one concrete failure mode
- [ ] No system monitors (btop) unless debugging perf during verify
- [ ] No file browser unless verify workflow inspects files
- [ ] No duplicate signals (two panes showing same test output)
- [ ] WATCH pane shows live output without manual refresh

4. Write artifacts

Create under .agents/verification/:

FilePurpose
cockpit.yamlUnified verify + test manifest (cockpits.verify, cockpits.test)
manifest.yamlLegacy verify pane map (still supported)
tests.yamlLegacy test runners (still supported)
tmux-layout.shExecutable layout (chmod +x)
tmux-theme.confOptional project theme overrides
README.mdHuman pane legend

Use templates from templates/ in this skill directory. Fill PROJECT, RISK, and PANES from discovery.

tmux-layout.sh contract:

  • Args: [directory] (default .)
  • Must run inside tmux
  • Sets @workflow_dir, @workflow_mode verify
  • Idempotent: verify_layout_ok — recreate when CMD missing or placeholder panes (FILES/SYS/INSIGHT/VERIFY)
  • Resolves project layout by walking up from cwd for .agents/verification/tmux-layout.sh
  • Sources verify-launch.sh + verify-layout.sh
  • Calls verify_layout_build_golden_grid, verify_apply_theme, verify_launch_pane, verify_maybe_rescan
  • Ends with tmux select-pane on console

5. Symlink

mkdir -p .cursor
ln -sfn ../.agents/verification .cursor/verify

6. Optional AGENTS.md row

If no cockpit section exists, add under setup/verify:

| Verification cockpit | `.agents/verification/README.md` — run `av` in tmux after agent work |

Test

In Ghostty + tmux (not Cursor integrated terminal):

t && z <project>
av                  # project layout; watchers auto-start
av --scan           # + agent_scan in console
av --launch-mutate  # allow mutate-tier confirms
av --generic        # fallback to generic 4-pane cockpit

Reference

  • Manifest schema: reference.md
  • Starter templates: templates/ — copy into target project .agents/verification/
  • Runtime integration overlay: shell-av-workflow

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.