verify-llm-artifacts
Confirms or rejects findings from review-llm-artifacts before deletes or risky refactors. Loads review-verification-protocol-style checks per finding. Use after a review run, when the user wants to reduce false positives, before fix-llm-artifacts on dead code, or when validating a full-project scan.
What this skill does
# Verify LLM Artifacts Findings
Second-pass verification for `.beagle/llm-artifacts-review.json`. The detection pass optimizes for recall; this pass optimizes for **precision** so agents do not remove or “clean” code that is still required.
## When to run
- After the [review-llm-artifacts](../review-llm-artifacts/SKILL.md) skill (especially full-project scans).
- Before the [fix-llm-artifacts](../fix-llm-artifacts/SKILL.md) skill when findings include **deletions**, **dead code**, or **High** risk.
- Whenever past runs flagged artifacts that should not have been removed.
## Inputs
- **Required:** `.beagle/llm-artifacts-review.json` from a completed review.
- **Optional:** `$ARGUMENTS` — `--priority-only` (verify `dead_code` and any `fix_action` of `delete` first; then others), `--id N` (single finding id).
If the review file is missing, exit with: `Run the review-llm-artifacts skill first.`
## Prerequisite skills
1. Load the [review-verification-protocol](../review-verification-protocol/SKILL.md) skill — general anti–false-positive discipline, including the **Anti-confabulation gate** (echo the artifact from a freshly read source before any verdict). The Load + ECHO gate in step 1 is this skill's concrete instance of that rule.
2. Load the [llm-artifacts-detection](../llm-artifacts-detection/SKILL.md) skill — category criteria for what counts as a real issue.
## Instructions
### Hard gates
Objective pass conditions before you claim verification is done:
1. **Input parse:** The JSON load command in step 1 exits 0 (no traceback). **Pass:** valid JSON on disk at `.beagle/llm-artifacts-review.json`.
2. **Echo before adjudicate:** Step 1 has printed the full finding table (one row per `findings[]` entry: id, file, line, category, description) sourced from the parsed JSON in **this** turn. **Pass:** the table exists in your output and its row count equals `len(findings)` — you have not begun any verdict before it.
3. **ID lock:** Step 1 has recorded the exact id set from `findings[]` and stated it explicitly. Every `results` entry maps 1:1 to a locked id — none added, none dropped. **Pass:** the locked id list is printed; if at any point an apparent finding has no matching locked id, you STOP (see step 1, ID lock).
4. **Evidence before verdict:** For each finding you adjudicate, you have applied [references/verification-checklist.md](references/verification-checklist.md) for its `category` (or documented why the category is N/A) and recorded matching strings in `checks_performed`. **Pass:** no `status` without at least one checklist-backed check or an explicit N/A note in `notes`.
5. **Output contract:** After writing `.beagle/llm-artifacts-verification.json`, the validate command in step 4 exits 0; `summary` counts equal the number of `results` entries by `status`; the `results` id set equals the **locked id set** from gate 3 exactly. **Pass:** schema-valid JSON and `results` ids == locked ids == source `findings[]` ids.
### 1. Load, ECHO, and lock ids
This is a two-part gate. **Parsing is not loading** — a `json.load` that exits 0 only proves the file is well-formed, not that you have the findings in context. You must echo the actual content before any adjudication.
**1a. Parse and echo the finding table.**
Print every finding from the parsed `findings[]` array — not from memory, not from the branch name, not from surrounding files:
```bash
python3 - <<'PY'
import json
r = json.load(open('.beagle/llm-artifacts-review.json'))
f = r['findings']
print(f"git_head={r.get('git_head')} scope={r.get('scope')} count={len(f)}")
print("| id | file | line | category | description |")
print("|----|------|------|----------|-------------|")
for x in f:
desc = (x.get('description') or '').replace('|', '\\|')[:80]
print(f"| {x['id']} | {x.get('file')} | {x.get('line')} | {x.get('category')} | {desc} |")
print("ids=" + ",".join(str(x['id']) for x in f))
PY
```
**Pass:** the command exits 0 and the table (one row per finding) appears in your output.
> **The only source of findings is the parsed `findings[]` array.** Do not infer findings from the branch name, the working directory, or surrounding files. If your mental model of the findings differs from the echoed table, **the table wins** — discard the mental model and adjudicate only the rows above.
**1b. ID lock (hard gate, before any adjudication).**
Record the exact set of ids from the `ids=` line above and state it now, e.g. `Locked ids: {1, 2, 3, 4, 5, 6, 7}`. This is the **locked id set**. Every result you write in step 4 must map 1:1 to this set: no id added, none dropped. The output id-check in step 4 references this locked set, not a re-derived one.
If, while verifying, you find yourself about to adjudicate a finding whose id is **not** in the locked set — or about to write a result for a file that does not appear in any locked row — **STOP**. That is an agent error (you are reasoning from memory or context, not the report). Re-read `findings[]` via the echo command above and restart adjudication. Do **not** record such a finding as `false_positive` (see step 3, Status discipline).
Record `git_head` and `scope` from the report (already printed by 1a). If the working tree no longer matches (optional strict mode: compare to `git rev-parse HEAD`), warn that line numbers may drift.
### 2. Order findings
Default order:
1. `category == "dead_code"` or `fix_action == "delete"` or `risk == "High"`
2. Remaining findings by `(risk descending, id ascending)`
With `--priority-only`, stop after processing category `dead_code` and all `fix_action: delete` (still write full output for those processed).
### 3. Verify each finding
For each finding, follow [references/verification-checklist.md](references/verification-checklist.md). Its **first** check for every category is the existence precondition: confirm the cited `file` exists at `source_git_head` before running any symbol/usage check.
**Minimum evidence per finding:**
- **Existence first:** Confirm `file` exists at `source_git_head` (`git cat-file -e <head>:<file>` or `test -f`). A nonexistent cited file is **not** routine — it is either a deleted-file finding (note it) or a sign you are not looking at the real report. A **wall** of missing-file results means STOP and re-read `findings[]` (step 1a). Do not absorb missing files silently.
- Read the **file** at the cited location and enough context to judge (parent symbol, imports).
- For unused/dead claims: **search** the repo (symbols, exports, string hooks) unless the issue is purely stylistic with no removal.
**Pass:** `checks_performed` lists only checks you actually ran (e.g. `file_exists`, `read_symbol`, `ripgrep_symbol`); `notes` cite the decisive observation.
Assign one status:
| `status` | Meaning |
|----------|---------|
| `confirmed_issue` | The finding in the report is valid; acting on it is appropriate. |
| `false_positive` | The finding **in the report** is invalid (factually wrong, or harmful if "fixed"); do not auto-fix. |
| `inconclusive` | Needs human or product context; treat like risky in `fix-llm-artifacts`. |
Set `confidence`: `high` | `medium` | `low` based on how direct the evidence was.
**Status discipline (hard rule):** `false_positive` means *"the finding present in the report is invalid."* It never means *"this finding is not in the report."* If you encounter an apparent finding that cannot be matched to an entry in the locked id set (step 1b), that is **agent error, not a false positive** — STOP, re-read `findings[]` via the step-1a echo command, and restart adjudication. Writing a `false_positive` (or any status) for an id outside the locked set is forbidden.
### 4. Write output
Create `.beagle` if needed. Write **`.beagle/llm-artifacts-verification.json`**:
```json
{
"version": "1.0.0",
"created_at": "2026-04-19T12:00:00Z",
"source_report": ".beagle/llm-artifacts-review.json",
"source_git_head": "<from review>",
"review_scope": "all|chRelated in AI Agents
skill-development
IncludedComprehensive meta-skill for creating, managing, validating, auditing, and distributing Claude Code skills and slash commands (unified in v2.1.3+). Provides skill templates, creation workflows, validation patterns, audit checklists, naming conventions, YAML frontmatter guidance, progressive disclosure examples, and best practices lookup. Use when creating new skills, validating existing skills, auditing skill quality, understanding skill architecture, needing skill templates, learning about YAML frontmatter requirements, progressive disclosure patterns, tool restrictions (allowed-tools), skill composition, skill naming conventions, troubleshooting skill activation issues, creating custom slash commands, configuring command frontmatter, using command arguments ($ARGUMENTS, $1, $2), bash execution in commands, file references in commands, command namespacing, plugin commands, MCP slash commands, Skill tool configuration, or deciding between skills vs slash commands. Delegates to docs-management skill for official documentation.
reprompter
IncludedTransform messy prompts into well-structured, effective prompts — single or multi-agent. Use when: "reprompt", "reprompt this", "clean up this prompt", "structure my prompt", rough text needing XML tags and best practices, "reprompter teams", "repromptception", "run with quality", "smart run", "smart agents", multi-agent tasks, audits, parallel work, anything going to agent teams. Don't use when: simple Q&A, pure chat, immediate execution-only tasks. See "Don't Use When" section for details. Outputs: Structured XML/Markdown prompt, quality score (before/after), optional team brief + per-agent sub-prompts, agent team output files. Success criteria: Single mode quality score ≥ 7/10; Repromptception per-agent prompt quality score 8+/10; all required sections present, actionable and specific.
adaptive-compaction
IncludedAdaptive add-on policy and recovery layer that decides WHEN to compact, prune, snapshot, or fork -- replacing fixed-percent auto-compaction across Claude Code, Codex, and MCP-capable hosts. Trigger on auto-compact timing or damage: "when should I compact", "is it safe to compact now or start a fresh session", "auto-compact fires too early/mid-task", "switching to an unrelated task but the window still has space", "context rot", "answers get worse the longer the session runs", "the agent forgot the plan or my decisions after it summarized", "add a layer on top that manages context without changing the agent", raising autoCompactWindow to give the policy room, or installing/tuning a cross-tool compaction policy or PreCompact hook -- even when "compaction" is never said but the problem is context-window pressure or post-summarization memory loss. Do NOT use to summarize a conversation, build RAG, write a summarization prompt (decides WHEN not HOW), or answer max-context-length trivia.
agent-skill-creator
IncludedCreate cross-platform agent skills from workflow descriptions. Activates when users ask to create an agent, automate a repetitive workflow, create a custom skill, or need advanced agent creation. Triggers on phrases like create agent for, automate workflow, create skill for, every day I have to, daily I need to, turn process into agent, need to automate, create a cross-platform skill, validate this skill, export this skill, migrate this skill. Supports single skills, multi-agent suites, transcript processing, template-based creation, interactive configuration, cross-platform export, and spec validation.
llm-wiki
IncludedUse when building or maintaining a persistent personal knowledge base (second brain) in Obsidian where an LLM incrementally ingests sources, updates entity/concept pages, maintains cross-references, and keeps a synthesis current. Triggers include "second brain", "Obsidian wiki", "personal knowledge management", "ingest this paper/article/book", "build a research wiki", "compound knowledge", "Memex", or whenever the user wants knowledge to accumulate across sessions instead of being re-derived by RAG on every query.
skill-master
IncludedAgent Skills authoring, evaluation, and optimization. Create, edit, validate, benchmark, and improve skills following the agentskills.io specification. Use when designing SKILL.md files, structuring skill folders (references, scripts, assets), ingesting external documentation into skills, running trigger evals, benchmarking skill quality, optimizing descriptions, or performing blind A/B comparisons. Keywords: agentskills.io, SKILL.md, skill authoring, eval, benchmark, trigger optimization.