> Reviews proposals from the perspective of **top-level organizational decision-makers**, not field practitioners. > Technically excellent and "this person will approve it" are different things.

Automatically generates a weekly audit draft by finding recurring patterns in accumulated session records. Proposes promotion and deprecation candidates and guides through commit and PR creation. Use --dry-run flag to run only through scan and draft generation (no promotion/commit/PR gates; compatible with bg dispatch).

The lever for catching a model's blind spots is **decorrelation, not repetition** — a model cannot find its own family's flaws by repeating itself. FH's adversarial verification (Axis-2 challenger) dispatches in-session at the session tier, **same family** as the governor. When frontier CLIs are i

When two skills conflict, **harvest the signal** instead of discarding one. Find the validation angle that neither skill addressed, and onboard new skill candidates into the FH ecosystem according to their routing path.

> A single pass declaration is hard to trust. A fix exposes new FAILs, and round 2 catches what round 1 missed. convergence-loop assigns a "truly passed" criterion to any gate.

Automatically discovers useful combinations (synergy pairs) across multiple installed plugins and skills, and presents them as a ranked table. Proactively suggests undiscovered synergies when new projects or skills are registered in the registry. Activates on phrases like "do my installed tools work well together?", "they seem to work in isolation", "find synergies".

A skill for cross-referencing externally distributed assets by audience type, created after reaching Phase I completion and Phase II entry signals. No asset transformation — invocation tools only (consistent with simplification principle — 0 new assets created).

When a PR is submitted, checks consistency against the user environment's baseline assets (CLAUDE.md · memory · naming · asset classification) and attaches a review comment. 5-step: diff read → 8-matrix check → self-catch → comment attachment → merge recommendation.

Diagnoses potential conflicts, duplicates, and overwrite risks that may occur when installing meta-harness plugins into an existing project.

Evaluates whether a repository meets marketplace listing criteria via a 5-point check and outputs a listing suitability verdict. Checks README completeness, zero-config readiness, maintenance signals, duplication, and public safety.

Input-tracing grounding audit for artifacts such as test cases, analysis reports, and design docs. Extracts proper nouns, numbers, citations, version claims, and branching conditions, then back-traces each to declared local files by grep or to external sources by fetch-and-support checks. Marks missing anchors as Phantom Claims and cited-but-unsupporting anchors as Unsupported. A claim is grounded only by non-model evidence: a local hit or literal source span, never another model's agreement. Renamed from source-grounding-audit; old-name references still route here. Triggered by: "phantom detection", "phantom claim", "source back-trace", "where did this come from", "verify source", "does the source support this claim", "grounding audit", "source grounding audit", "citation support check".

Given a task description, searches internal and external open-source ecosystems (including Codex marketplace and Claude Code marketplace) to find and recommend suitable plugins with installation guidance. Recommendation is quality-validation based (marketplace-listed + performance-validated), not source-origin based. Activates on "recommend a plugin", "what tool should I use?", "is there a plugin for this?", "recommend a tool". Also checks for duplicate installations.

Monitors for incoming PR reviews and summarizes their content. Determines approval/change-request/comment verdicts and extracts action items. Triggers on "did the PR review come in?", "when will the review arrive", "PR waiting" utterances.

Scans the git-tracked file set (the public surface) for operator-private tokens that were supposed to stay in gitignored files (e.g. `CLAUDE.local.md`, companion store). After a public/private split, a front-door fix is not enough — a leaked username or absolute home path anywhere in the tracked s

One entry point for people who want to **dynamically test a web or desktop app with a QA lens from inside Claude Code**. Three stages, each its own skill, each leaving files:

Input: a target that passed `qp_tools.sh target-class` (PUBLIC or PROFILE_OK) and an adapter line from `adapter-probe`. Optional: a plan/spec document path (`--plan <file>`). Optional profile.

Input: a baseline `qp/run/<ts>/` and the same `qp/plan/tcs.tsv`. Output: `qp/regress/<ts>/`.

Audits SKILL.md files in plugins/ for return-path gate compliance. Detects fire-and-forget chains where a caller dispatches a downstream skill but does not gate its next step on the callee's verdict. Reports each chain as CLOSED or OPEN and outputs specific fix suggestions. Triggered by "chain audit", "return-path check", "fire-and-forget detection", "chain closure audit", "skill chain compliance".