Borrowing it
Nothing to install: this file belongs to PIsberg/vibetags. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/PIsberg/vibetags/main/.claude/skills/consultation-loop/SKILL.mdgit clone --depth 1 https://github.com/PIsberg/vibetagsWrote 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/pisberg/vibetags/consultation-loop)<a href="https://agentmods.dev/skills/pisberg/vibetags/consultation-loop"><img src="https://agentmods.dev/badge/skills/pisberg/vibetags/consultation-loop/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/pisberg/vibetags/consultation-loop"><img src="https://agentmods.dev/badge/skills/pisberg/vibetags/consultation-loop.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.00102 | $0.00790 |
| Opus 5.5 | $0.00041 | $0.00316 |
| Sonnet 5.5 | $0.00020 | $0.00158 |
| Haiku 4.5 | $0.00010 | $0.00079 |
Grade A, and why
consultation-loop 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 1mo 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Consultation loop
A voluntary pre-push interrogation of the branch diff. The reviewer must be a fresh context
that did not produce the change: spawn a subagent (or a fresh claude -p session) and give
it only the diff and the questions below. Never answer these questions from the session that
wrote the code; a session reviewing its own work confirms its own assumptions.
This loop is advisory. It produces ranked findings for the author to weigh, not a verdict. The blocking review is CI's job (tests, self-check, the Inquisitor); this one exists to catch what you can still fix cheaply, before the PR exists.
Procedure
-
Compute the diff scope:
git diff origin/main...HEAD(aftergit fetch origin main). -
Spawn a fresh reviewer with the framing: "You did not write this code. Assume the author took shortcuts. Answer each question for this diff only. Every claim cites a file:line from the diff; if the diff cannot answer, say 'cannot tell from here' and name what evidence would answer it. Do not reassure."
-
Ask the five questions, one at a time, each with its scope clause:
- Are we done? Enumerate what the task promised (the issue, the spec, the PR body draft) as a list, and mark each item present or absent in the diff. Done-ness is a list, not a feeling.
- Is it production ready? Error handling on the failure paths the diff introduces;
logging of the decisions it takes (
domain.event key=value,reason=on skips); behavior when its inputs are absent or malformed. Fail closed and loud. - Does it scale? Algorithmic findings visible in the diff itself (per-element work
inside per-file loops, unbounded accumulation, repeated I/O). Demand the distinction
between "this is quadratic, see line N" and "cannot tell from here; needs a
measurement" - for the latter,
load-tests/is the harness. - Is it secure? What new untrusted input does this diff accept, and where does that
input cross into generated files, shell commands, or paths? For this repo the classic
surface is annotation string values reaching generated guardrail files;
Escape.javaandMarkerInjectionTestare the precedents to check against. - Top three change requests, ranked by risk reduced, each citing a line. No line, no vote.
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.
- 1mo ago First seen · 54 lines · 102 tokens per session scan A 126be3f61f79
consultation-loop is a skill published in the GitHub repository PIsberg/vibetags (25 stars, last pushed today), licensed MIT. It adds 102 tokens to every session and 790 once invoked, about $0.0004 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-08-30.
Other skills, from other repositories
release-pr-review
Review pass on an open release PR (release/ → main) — the step between git-wrapup and release-and-publish when a project releases in gated release PR mode. Reads the PR's commit range through the code-simplifier lens plus a correctness review, verifies whatever an automated reviewer left on the PR, lands fixes as…
plugin-code-review-orchestrated
Orchestrates a code review of the spring-plugin repository through scope/context passes, routing, domain reviewer subskills, and per-artifact validation. Use when asked to review a PR, diff, commit, branch, module, or file set, to run a full orchestrated review, or to produce a validated review report.
review-ui-leak-via-listeners
Normative reviewer for memory leaks where UI components or view classes are retained by listeners on properties of long-lived services (APP/Project) or by strong references in singletons (object, companion object, static fields). Use when reviewing tool-window panels, settings pages, dialogs, wizard steps, or any code…
review-scope-resolver
Normalizes a PR, diff, commit, branch, file list, directory, module, class, or function into an exact review target with semantic clusters and routing signals for domain reviewer subskills. Use as the first pass of an orchestrated code review, when asked to resolve review scope, or when a raw review reference must be…
mulch-record-from-evidence
Turn the evidence of a finished work session — git commits, changed files, recently-touched seeds issues — into well-formed ml record invocations. Use at session close, when an agent has made changes worth preserving as mulch expertise but hasn't yet recorded them.
pre-pr
Prepare a Honcho change for a pull request to plastic-labs/honcho. Invoke before opening a PR, when drafting a PR body, when asked if a branch is PR-ready, or when filling the pull request template. Checks the linked issue, required tests and docs, then writes Description / Proofs / Fixes.