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 agentmods add skills/eyalbpm/sessiondeck/manual-verifynpx skills add eyalBPM/SessionDeck --skill manual-verifygit clone --depth 1 https://github.com/eyalBPM/SessionDeckWrote 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/eyalbpm/sessiondeck/manual-verify)<a href="https://agentmods.dev/skills/eyalbpm/sessiondeck/manual-verify"><img src="https://agentmods.dev/badge/skills/eyalbpm/sessiondeck/manual-verify.svg" alt="Measured on agentmods" 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 | $0.00070 | $0.03101 |
| Opus 5 | $0.00035 | $0.01550 |
| Sonnet 5 | $0.00014 | $0.00620 |
| Haiku 4.5 | $0.00007 | $0.00310 |
Grade A, and why
manual-verify 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 4d 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 — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Manual verification
The 38 automated tests cover the install-hooks merge and nothing else. Everything below
needs a human looking at the screen. Run the sections that the change actually touches;
run all of them before a release.
Running it: bin\Debug\net10.0-windows\SessionDeck.exe (or F5 from Visual Studio).
Remember the deploy order — quit, build, start (see CLAUDE.md).
CLI: SessionDeck.exe <command> from that folder; help lists everything.
Config: %APPDATA%\SessionDeck\config.json. Log: %APPDATA%\SessionDeck\logs.
1. Workspace cards — adding and binding
- "+ Add workspace" → pick a folder → a card named after the folder.
- A VSCode window already open on that workspace binds immediately (live thumbnail).
-
SessionDeck.exe add "D:\path"— same behaviour from the CLI. - Adding the same folder twice is blocked with a message.
- A git project shows its branch (⎇); switching branch updates within ~10s (instantly with the extension).
- A Peacock project (
.vscode/settings.json) takes the Peacock colour on border and title. - Closing the VSCode window keeps the card ("No VSCode window open"); reopening re-binds.
- Dragging a VSCode window onto the deck creates/binds a card; a non-VSCode window is blocked.
2. Session cards — statuses from the hooks
Install the hooks per hooks/README.md, then open a Claude Code session:
- Opening a session → a grey (idle) sub-card, creating the workspace if needed.
- Submitting a prompt → steady blue (working).
- A permission request → blinking orange (waiting).
- Turn ends → blinking green (done); clicking → steady green + focus.
- Closing the session → the card goes; ▼ shows it dimmed as closed.
- Without Claude Code: run the command sequence at the end of
hooks/README.md. -
session status --id <sid> --state error→ blinking red until clicked.
3. Managing the deck
- Clicking a card focuses its VSCode window in place; with no window open it launches VSCode on the folder and binds.
- ▶ moves the window to the configured Stage.
- Edit → title/description/colour, including returning to "Automatic colour".
- Hide → the card goes; 👁 brings it back dimmed, and the menu item becomes "Show on the deck again".
- Active cards (open window / live session) float to the top.
- Many cards → vertical scrolling, wrapping by window width.
- 🔍 opens/closes the search row; ✕ and Escape both close it and clear the filter.
- Search filters by workspace fields (name/path/branch/description) or a matching session (title/detail/id); a matching session shows even when closed.
- "Search content too" also matches transcript contents; the status bar reports the count.
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.
- 4d ago First seen · 165 lines · 70 tokens per session scan A d2c9c32f33f1
manual-verify is a skill published in the GitHub repository eyalBPM/SessionDeck (1 stars, last pushed 26d ago), licensed MIT. It adds 70 tokens to every session and 3,101 once invoked, about $0.0003 per session on Opus 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-08-31.
Other skills, from other repositories
e2e-testing
E2E test authoring for Backseat Driver. Use when: writing, modifying, or debugging e2e tests under e2e-test-ws/, adding new MCP test scenarios, investigating test failures, understanding test infrastructure, or working with files matching test.cljs in the e2e workspace.
qa-sweep
Run a multi-lens agent QA sweep of the RUNNING product: spawn qa agents (one per lens — user-flow · edge-state · honesty · contract · ux-critique), collect their structured findings, integrator-verify the load-bearing ones, and land verified findings as backlog tickets + a run record in the project's qa/ folder. Use…
e2e-test-skill
E2E test skill for validation.
autonomous-review
Use to perform an end-to-end PR review and reach an approve/request-changes verdict — including verifying acceptance criteria, running E2E tests via browser automation, resolving merge conflicts, and (when verdict passes) merging the PR. Triggers on phrases like "review this PR", "decide whether to approve and merge"…
maestro-flutter
Maestro E2E testing knowledge for Flutter apps. YAML-based flows, TestKeys, visual regression, Maestro MCP integration. Background knowledge for QE E2E testing phase.
roblox-validation-and-qa
Use when deciding whether a change in a Roblox project counts as tested, verified, or done, before claiming PASS or "works", when writing or running Jest Lua unit specs (.spec.luau), adding a tests/scenarios/.md playtest scenario, adding a UI Labs storybook story, moving a board card into or out of the Testing lane…