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.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.1 | $0.00102 | $0.00790 |
| Opus 5 | $0.00051 | $0.00395 |
| Sonnet 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 7d 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.
- 7d ago First seen · 54 lines · 102 tokens per session scan A 126be3f61f79
consultation-loop is a skill published in the GitHub repository PIsberg/vibetags (15 stars, last pushed yesterday), licensed MIT. It adds 102 tokens to every session and 790 once invoked, about $0.0005 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-30.
Other skills, from other repositories
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.
pr-reviewer
Fetches PR review comments, analyzes requested changes, implements fixes, commits and pushes the resolution. Use after a reviewer has left comments on an open PR to close the feedback loop efficiently.
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…
056-design-avoid-breaking-changes
Use when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review…
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…