chrono-meta/forge-harness

# convergence-loop — Universal Convergence Loop Gate Reinforcement

> 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.

## Triggers

- `/convergence-loop`
- "convergence-loop", "how many rounds do we need", "not sure if it really passed"
- "suspicious of single-pass", "run until it passes", "keep verifying until clean"
- "single pass isn't enough", "need another round", "the fix might have introduced new issues"
- Auto-proposed: when the same artifact receives a FAIL verdict 2+ times in the same session (observable: 2nd FAIL on identical scope)

---

# deliberation — The Forge Skill

Innovator (propose) → Devil (challenge) → Mediator (synthesize) 3-layer core structure.
The goal is not to pick a winner — it is to **extract salvageable fragments from the losing argument and produce a conditional verdict**.
Even those who struggle to challenge assumptions can use this structure as a rope to reach better decisions.

> **Role distinction from sim-conductor and steel-quench**
> - sim-conductor: **validates** quality and consistency of a completed asset
> - steel-quench: **adversarially stress-tests** a near-complete artifact (post-build defect surfacing)
> - deliberation: perspective clash during the **design decision process** → synthesis (upstream of both)

---

## Triggers

# ko-tech-writer — 한국어 기술문서 집필·개고 파이프라인

한국어 기술 산출물을 쓰거나 개고한다 — **독자 대면**(테크블로그 글 · 기술문서 · 발표 파생 자산)과
**청자 대면**(발표 대본 자체) 둘 다이며, 레지스터는 Step 0 에서 가른다.
핵심 전제: **좋은 문장은 취향이 아니라 절차다** — 실물 표본으로 톤을 캘리브레이션하고,
번역투를 패턴 목록으로 제거하고, 수치는 근거와 창을 달고, 렌더 결과를 눈으로 확인한다.

> 출처: 2026-08-10 발표 기술문서 세션에서 실측으로 벼려진 규율의 자산화. 이 문서의 규칙
> 클래스는 그 세션의 개고에서 실제로 검출·수리된 것들이다 — 근거 원장은 그 세션 기록
> (`fh_completed_2026-08-10` 및 해당 개고 커밋 이력. 비공개 세션 기록이라 외부 배포본
> 독자에게는 도달하지 않는 내부 포인터다). **실측 근거가 없는 클래스를 추가하지 않는 것**이
> 이 문서의 유지 규칙이다. 이 SKILL.md 자체는 독자 대면 문서가 아니라 하네스 자산이므로
> 이 파이프라인의 적용 대상이 아니다(FH 하우스 스타일을 따른다).

# mcp-circuit-breaker — MCP Tool Failure Guard

MCP tools can fail silently or return partial results, leading to cascading retry loops that waste tokens and degrade session quality. This skill detects failure patterns, trips a circuit breaker to halt retries, proposes alternatives, and resets when the tool recovers.

> **Scope distinction**
> - Claude Code native retry: low-level transport retries (transparent, fast)
> - mcp-circuit-breaker: **session-level guard** — detects repeated semantic failures, intervenes before token waste compounds

---

## Triggers

- `/mcp-circuit-breaker`
- "MCP failing", "MCP keeps erroring", "tool isn't working", "circuit-breaker"

# persona-cast — a pre-built review cast a field harness can use without knowing the container

**Why this exists (operator decision 2026-09-12)**: FH can synthesize personas on demand through
`persona_container_schema.md`, but a field harness cannot — it would have to fill seven slots, pick a
tiering rule and run a marginal-coverage stop every time. What a field harness can use is the
container's *output*, pre-baked: a cast of review-shaped lenses plus one doorway. This skill is that
doorway, the same shape as `harness-pr-reviewer` (a standalone way in to one FH capability).

> Role split: `sim-conductor` synthesizes personas for a *simulation* and owns the parallax shape.
> `persona-roster-expander` turns a *named seed* into a tiered cast. `persona-cast` dispatches an
> *already-built* cast at an artifact. It builds nothing; a missing lens is a request to the two
> skills above, never inline improvisation.

## Casts (shipped in `plugins/fh-commons/agents/*-lens.md`)

# standpoint-review — review a change from the side that receives it

**Input**: the change (a diff such as `git diff <base>..HEAD > change.diff`, a dependency bump, or a
package build) and the repo or package that receives it.

**What it is, in one line**: family diversity (another model reads the diff) raises resolution
*within one standpoint*. Standpoint review changes *which ground truth* the change is checked against:
the receiving side's own rules, tests and conventions. A defect that only exists relative to the
receiver's conventions is invisible from the author's repo however many models read it.

**Why this exists (operator decision 2026-11-01)**: in forge-harness (FH) the standpoint axis runs as
an engine — a rule (`knowledge/shared/harness-core/field_verdict_crossfamily_gate.md` §7) plus a
commit-hook field (`standpoint:`) — for sessions running inside the harness repo. Someone who only
installs the plugin gets neither. This skill is the same procedure as a doorway they can call.

# token-budget-gate — Pre-Task Token Cost Gate

Multi-step and multi-agent tasks can silently consume large token budgets. This skill estimates cost before execution, outputs a gate verdict, and calibrates estimates against actual usage after completion — preventing surprise overruns without blocking legitimate work.

> **FH context**: FH default execution tier is `standard` (~15K tokens). This skill gates against accidental `full` (~30K) or `max` (~60K+) consumption on tasks that could be handled lighter.

---

## Triggers

- `/token-budget-gate`
- "token budget", "token cost", "how expensive", "will this use a lot of tokens"
- "estimate tokens", "token estimate before we start"
- Before invoking: `agent-composer`, `sim-conductor`, `steel-quench` (max-tier skills)

# agent-composer — Agent Composition Layer

A coordinator skill that reads the work context and decides "which agents to dispatch, when, and in what order."
Selects the optimal combination from the FH skill pool and either outputs a fan-out plan or executes it directly.

## Triggers

- `/agent-composer`
- "Which agent should I use?", "Pick one automatically", "Compose the agents"
- "Set up the agents", "Decide which agents to use"
- "Split the work and run in parallel", "Process with multiple agents"
- "Build the dispatch plan", "Run in parallel splits"
- When the task is complex or spans multiple projects

# apex-review — Decision-Maker Review Layer

> 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.

**Role distinction from hub-persona-auditor**
- hub-persona-auditor: Validates **reader comprehension** of a finished asset (reading experience)
- apex-review: Evaluates **decision-maker approval likelihood** of a technical proposal (decision-making experience)

---

## Triggers

- `/apex-review`

# asset-placement-gate

Routes new skills, agents, and plugins to the correct location when proposed.

## Triggers
- "Should I make this an FH skill?"
- "Where should I put this agent?"
- When a new FH asset creation is proposed
- `/asset-placement-gate {asset name or description}`

### Natural Language Triggers (example user phrases)

When unsure where to place a new asset or skill:

# auto-decorrelation — Cross-Family Verifier Recruitment

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 installed and a
local GPU box is live, leaving them idle wastes the one thing that actually raises the verification
ceiling. This skill recruits a **cross-family** verifier for load-bearing changes — and degrades
honestly when none is available.

It is a thin recruitment-and-degrade **policy** that REUSES existing machinery: `agent-composer` does the
actual dispatch, `cross-ecosystem-synergy-detection` inventories tools, `token-budget-gate` gates spend,
the headless CLI patterns and the floor-tier canary already exist. Net-new = the discovery + the
family-diversity recruitment + the degrade ladder only. (A **composing policy skill** — it fans out to
several callees, so its token floor is higher than a leaf skill by design; this is composition, not

# contention-layer — Contention Harvest + New Skill Routing

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.

> Philosophical basis: Cognitive dissonance in humans is not a failure but a core asset — the ability to hold contradictions created culture. In the FH ecosystem, conflict is the signal from which new skills are born.

## Triggers

```
/contention-layer                    # analyze current conflict situation
/contention-layer --skills A B       # specify two skills for contention analysis
```

Phrase triggers: "two skills conflict" · "weird when used together" · "they produce different conclusions" · "contention harvest" · "contention" · "open vs grounded contradiction" · "research tracks disagree" · "dual-track grounding **+ conflict/disagree/contradict**" (the phrase "dual-track grounding" alone collides with `phantom-quench` on the word "grounding" — measured Step-0.5 probe #3, 2026-06-17; it fires this skill only when a conflict word co-occurs)

# context-doctor — Token Efficiency Diagnosis + Automatic Prescription

Diagnoses the main causes of session token waste and prescribes immediate remedies:
1. No `.claudeignore` → unnecessary files loaded wholesale into context
2. Repeated full reads of large files → paying the same cost N times
3. Not using `/clear` after direction changes → continuing work with accumulated noise
4. Verbose CLI output → every `git`/`ls`/build/test call floods context with stdout (a *different* layer from 1–3 — see §Command-Output Reduction)

**Two reduction axes — keep them distinct.** Causes 1–3 are the **context-footprint** axis (what gets read *into* context: files, history). Cause 4 is the **command-output** axis (tokens produced *by* the tools you run). `.claudeignore` cannot touch command output, and a command-output proxy cannot touch file reads — they are complementary, not substitutes. (Step 3.5 below adds an optional **third**, orthogonal lever — provider-side cache billing — distinct from both.)

**Standalone install** — this skill works normally with plugin install only, without cloning the full meta-harness.

**Built-in `/doctor` first (sister anchor, 2026-07-25)**: since the Claude 5 generation, the official
`/doctor` command claims skill/CLAUDE.md rightsizing ("The new rules of context engineering for Claude 5

# corpus-grounding-expander

Builds or broadens the **grounded axiom** a relay system quotes from. When a system's output must be
constrained to verbatim source (fail-closed grounding), the corpus IS the axiom — this skill expands
that corpus from multiple public-domain versions so grounding is robust and non-biased (a quote
verified in ANY version counts), without ever adding a generator.

> Origin: harvested from the-bible (2026-06-20) — 6 public-domain Bible versions, 197k verses, as the
> fail-closed grounding axiom. **The grounds, inline, because the harvest record does not ship**: one
> edition's wording makes a fail-closed check reject a faithful quote that followed a *different*
> edition, so the union across versions is what stops fail-closed grounding from failing closed
> *against the user* — and it keeps one translation's editorial choices from silently becoming the
> axiom. Generalizes to any verbatim-relay corpus (legal statute, RFC text, standards).
> Full harvest record — **hub-local, not distributed in the npm package**:

# cross-ecosystem-synergy-detection — Multi-Ecosystem Automatic Synergy Discovery

Automatically discovers cross-invocable pairs in environments with multiple installed plugins and cross-CLI tools, and derives a synergy ranking table.

## Activation Triggers

1. **Multi-ecosystem component environment specified**: "multiple plugins/cross-CLI installed", "synergy with other components", "cross-ecosystem", "run together"
2. **New component added/removed**: "component install", "add/remove component"
3. **Synergy check phrasing**: "are they working in isolation?", "can they be integrated?", "environment check", "combination effect"
4. **Registry change detected** (optional): If a user-maintained `LOCAL_SKILL_REGISTRY.md` is present, Step 7 runs when a new project/skill is registered. The registry is not auto-created — absent file → Step 7 reports `[NOT-CONFIGURED]` and skips its body (see Step 7-1 outcome table).

**Exception**: Single-component environments (1 or fewer installed → no meaningful activation)

### Natural Language Triggers (General user phrasing — activates without internal vocabulary)

# deep-clarify — Socratic Requirement Clarification

A skill that clarifies vague or open-ended requests through conversation to produce **actionable spec documents**.
An independent extension of the "direction confirmation" protocol from agent-composer Step 0-a.

## Triggers

- `/deep-clarify`
- "I don't know what to build", "How should I approach this?"
- "Organize the requirements", "Write a spec document"
- "What should I do with this?", "The direction is unclear"
- When agent-composer detects pre-dispatch clarification is needed and delegates automatically

## Core Principles

# dialogue-harvest

Extracts the load-bearing propositions from a long AI-human dialogue (or long text) after
removing the counterpart's sycophancy. Fills the gap between FH's loading assets
(corpus-grounding-expander, video-ingest) and its mining assets (frontier-digest = feed items,
field-harvest = git history, harvest-loop = session records): none of those mines an *argument-shaped*
corpus, and a naive summarizer run on an AI dialogue returns "the user made several excellent
points" — worthless, because most of the volume is agreement.

**Why the first operation is sycophancy removal**: AI dialogue logs are dominated by agreement and
restatement. Without stripping them first, extraction inflates the user's contribution; without
provenance labeling (Step 4), "my insight" and "a frame the counterpart planted" are
indistinguishable — which is exactly the failure this skill exists to prevent.

# edit-manifest — Predict-Verify Loop for Harness Edits

> Implements two mechanisms from frontier harness research, named as in their source papers (both terms
> are the papers' own — verified 2026-06-17 against arXiv full text):
> - **Change Manifest** (AHE, arXiv:2604.25850): each edit attaches a manifest entry declaring a
>   falsifiable predicted impact (expected fixes + at-risk regressions); the next round intersects it
>   with observed task-level deltas to produce a per-edit verdict. (Paper: "the Evolve Agent produces a
>   change manifest…".)
> - **Validation Gate** (SkillOpt, arXiv:2605.23904): a candidate is accepted only when its
>   selection-split score is strictly greater than the current selection score (ties rejected); rejected
>   edits are kept in an epoch-local buffer, not silently discarded. (Paper: "validation gate" /
>   "held-out gate".)

FH's regression_guard.sh catches backward regressions. edit-manifest closes the forward

# /fh — hub map on demand

The greeting flow (CLAUDE.md §Active Onboarding) fires on greetings, start intents, new-task and
discovery utterances — but it is salience-dependent, once-per-session, and skipped entirely when the
user opens with a task. This command is the **explicit, deterministic** route to the same map: slash
autocomplete discoverability, invocable mid-session any number of times, no reliance on the model
catching a phrase. Same map, different guarantee — /fh does not claim a gap in *which utterances*
fire onboarding; it closes the *how-reliably-and-when* gap.

## Execution Steps

### Step 1. State detection (reuse, don't re-derive)

Run the same mechanical branch test as §Active Onboarding: session files / mapped project tracks

# field-harvest — Field Pattern Harvest → FH Backport + Session Logger

Dual-mode skill:
- **Mode A (Pattern Harvest)**: Scans recent commits in field projects to detect patterns worth backporting to FH. One-click flow from detection to PR creation.
- **Mode B (Session Log)**: Records session work from field projects to the knowledge hub when a session ends. Auto-generates a session markdown file with commits, learnings, and next steps.

## Mode Selection (Step 0-A)

Determine which mode to run based on user context:

| Condition | Mode | Priority |
|---|---|:---:|
| User message contains: "session log", "log today's work", "sync to hub", "sync session" | **Mode B (Session Log)** | 1 (highest) |
| **Session-end auto-trigger fires** (see below) and field commits exist today | **Mode B (Session Log)** — auto-proposed | 2 |

# frontier-digest — FH Frontier Insight Collection & Synthesis

> Automatically collects the latest AI/agent/harness engineering trends from HackerNews, arxiv, launch channels, GeekNews and vendor changelogs,
> then compresses and synthesizes them into insights directly relevant to forge-harness skills and structure.

## Triggers

```
/frontier-digest                # immediate execution
/frontier-digest --save         # save result to file
"what's on the frontier"
"this week's AI trends"
"harness trends"
"latest agent developments"

# goal-quench — /goal with Token Budget + Quality Gate

**Availability of `/goal` is unresolved** — treat it the way `CLAUDE.md` treats `/deep-research`:
use the built-in **if present**, and do not assert it is absent either. Everything below applies to
whatever autonomous-run command this environment actually has; goal-quench is the wrapper, not the
runner. Probe before relying on it (`/help`, or the skill/command list), and say which you found.

`/goal` is understood to run until a cheap per-turn judge (reported as Haiku) says "done" — that is
**second-hand, not verified here**, so treat it as the assumption goal-quench is designed against
rather than as a fact about the implementation. What matters for this skill holds either way: a
completion judge is not a quality judge, and without a budget ceiling a session can exhaust tokens
silently. goal-quench adds three things such a runner does not itself provide:

1. **Pre-run**: token-budget-gate estimate — know the cost before committing

# harness-doctor — Harness Structure Diagnosis + Prescription

"A good harness gets simpler over time. If it's getting more complex, something is wrong."

Diagnoses harness structural health across 5 layers and proposes M/S/R prescriptions:

1. **L1 Structural completeness** — required file existence (CLAUDE.md · .claudeignore · .claude/)
2. **L2 Complexity** — current state vs. simplification principle (line count · unused files · duplicate definitions)
3. **L3 Drift** — rule vs. actual pattern mismatch (broken references · stale files · conflicting rules)
4. **L4 Connection diagnosis** *(FH environment only)* — meta hub ↔ field project reference consistency
5. **L5 Pattern analysis** *(FH environment only)* — skill activity · call context appropriateness · effect metrics

---

> **Note:** The original developer is the forge-harness original developer (development source + meta-monitoring home). In external user install environments, the install environment user themselves is the baseline integrity gate operator (following path B generalization baseline / `SKILL_detail.md §External User Environment Adaptation Path` §).

# harness-pr-reviewer — Hub Gate Operation Rule Automation

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.

## Activation Triggers

> **Renamed from `hub-cc-pr-reviewer` (2026-09-12, operator decision).** The old name said where it
> was born (the hub's own cc reviewing its own PRs). What it actually is — measured on qasp/pmh PRs in
> 2026-09 — is the **standalone doorway through which a field harness verifies its own submitted PR
> with FH's review capability**. Old-name utterances ("hub-cc-pr-reviewer", "hub review", "hub cc
> review") still route here; downstream forks that carry the old directory name (PMH) keep working
> until they sync. No redirect stub directory is shipped (same policy as `phantom-quench`).

# harvest-loop — Field Session → FH Self-Evolution Pipeline

> Automatically absorbs patterns/conflicts/discoveries from field sessions back into the FH ecosystem.
> Internalizes as a pipeline the return loop from field projects to the harness that was previously done manually.
> One of the core functions is real-time detection and blocking of **Semantic Drift** — where agent terminology gradually diverges in meaning as sessions grow longer.

## Operation Modes

| Mode | Description | Trigger |
|---|---|---|
| **Forced mode** | Auto-runs at end of local development session. Executes without approval, only confirms final suggestions | Session wrap-up rules in hub CLAUDE.md |
| **Lightweight mode** | Immediate harvest after Wave completion. Skip Steps 3/3.5/4 — prioritize fast recording | agent-composer Step 4-c (2+ new files or 3+ existing files changed, **or M-tier resolved**) |
| **Proposal mode** | External FH users — confirms "run harvest-loop?" before executing | User utterance or `/harvest-loop` |

# install-doctor — Plugin Install Conflict Diagnosis

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

**Can be installed standalone** — works correctly with plugin install alone, without cloning the full meta-harness.

## Triggers

```
/install-doctor                        # Full diagnosis of current environment
/install-doctor --plugin fh-meta       # Diagnose targeting a specific plugin
```

## Step 0. Runtime Environment Requirements Check

# install-wizard — Onboarding Setup Wizard

> ⚠<U+FE0F> **Prerequisite — Read first if this is your first install**
>
> This skill is available **after the fh-meta plugin is registered in Claude Code**.
> If you type `/install-wizard` and CC doesn't respond, the plugin hasn't been registered yet.
>
> **When running Claude Code from the FH directory**: the AI detects the MISS automatically
> and installs the plugin via Bash — no manual input needed. Just say "install the plugin."
>
> **Manual fallback (if needed):**
> ```bash
> claude plugin marketplace add https://github.com/chrono-meta/forge-harness.git
> claude plugin install -s user fh-meta@forge-harness

# marketplace-gate — Marketplace Listing Suitability Gate

Evaluates a repository against 5 listing criteria — README completeness, zero-config readiness, maintenance signals, duplication, and public safety — and outputs a listing suitability verdict.

> While `asset-placement-gate` answers "is this asset suitable for FH?",
> `marketplace-gate` answers "is this repo ready to be listed in a marketplace?"

## Triggers

- `/marketplace-gate`
- `/marketplace-gate --target <repo path>`
- "Can I list this in the marketplace?", "Pre-listing repo check", "Verify before publishing", "Is this ready for marketplace listing?"
- "Can other teams use this repo?", "Is there a checklist before external distribution?", "Check if this is ready to be public"
- "Review for open-source release", "Verify before sharing outside the team"

# memory-hygiene — Stale Memory Detection and Re-Verification

> Addresses the "stale-but-confident" failure mode: verified information that silently drifts
> while remaining highly ranked in retrieval — identified as a harness failure mode
> in *Scaling the Harness in Agentic AI* (arXiv:2605.26112).
>
> **Sister asset**: arXiv:2607.01935 (*A-TMA: Decoupling State-Aware Memory Failures in Long-Term
> Agent Memory*, Shi/Tang/Tung 2026) names this exact class "ghost memory" — outdated / current /
> transitional facts intermixing during retrieval — and benchmarks it (LTP; conflict-accuracy +0.240,
> temporal-F1 0.03→0.17 on LoCoMo with a bank-maintenance layer). It is the tighter external frame for
> what memory-hygiene detects: this skill is the FH-native *detection + archival* pass over the same
> failure A-TMA formalizes at the retrieval layer. (Source-verified 2026-07-03; a broader bounded-memory
> testbed, arXiv:2607.02255 AgenticSTS, was considered and set aside — it targets context-assembly, not
> staleness, so it is not the sister here.)

# meta-prompt-builder — Prompt Delegation Skill

When agent-composer decides "what to orchestrate", meta-prompt-builder designs "what to say to each agent."
Delegates prompt writing itself to AI — interprets Goal / Context / Constraints / Done When structure within the FH context.

## Primary Users

**agent-composer proficients** — People who already have an orchestration plan and want to structure the specific instructions for each agent. Use this when you already know "which agents to use."

Beginners (unsure which agents to use) → start with agent-composer first. meta-prompt-builder is a post-orchestration step.

## Triggers

- `/meta-prompt-builder`

# persona-roster-expander

Takes a seed set of named personas and turns it into a usable judgment cast: each persona tiered by a
domain safety rule, mapped to a concrete decision-lens, plus a few proposed additions filling
uncovered lenses with real anchors. An innovator-family skill — generative, but bounded by a
caller-supplied safety rule so the expansion stays faithful to the domain's constraints.

> Origin: harvested from the-bible (2026-06-20) — an operator persona seed (priest/nun/angel/devil/
> God/Jesus/Holy-Spirit/apostles) tiered relay-vs-lens by a relay-safety rule and mapped to
> engineering-judgment lenses, +4 sourced proposals. **The grounds, inline, because the harvest
> record does not ship**: an ungated persona cast drifts into inventing its own authority — a voice
> given a lens will speak past what the domain lets it assert — so tiering by a *caller-supplied*
> rule is what keeps the expansion faithful, and the lens mapping is what makes a named voice
> usable as a decision instrument instead of flavor. Full harvest record — **hub-local, not

# phantom-quench — Input Tracing Grounding Audit

> Just because an artifact looks plausible doesn't mean it's grounded in source. plausible ≠ grounded.

> **Renamed from `source-grounding-audit` (2026-06-06)** — the grounding member of the quench series
> (steel-quench · phantom-quench · goal-quench). Same skill, same ruleset; only the label changed to fit
> the family. The **v1 paper (Zenodo 10.5281/zenodo.20397566) cites the old name** — that is the <!-- stale-ref: pinned-line=20397566 -->
> historical record, not a phantom (`paper/forge_harness_v1.0.html` is left unchanged by design; readers
> map *source-grounding-audit (v1) = phantom-quench (current)*). The deprecated redirect stub directory
> was removed 2026-06-12 — old-name utterances ("source grounding audit", "grounding audit") route here
> via this description's trigger phrases.
> This is a **label rename, not a capability change** — phantom-quench does not fuse steel-quench or
> inject faults; those remain separate (orthogonality is deliberate — see Role Separation below).
>

# pipeline-conductor — Chained Verification Sweep

Chains the four standalone FH verification pipelines into a gated sequence. Each step receives the previous step's verdict before proceeding. Aggregates all findings into a single structured report at the end.

The gap this closes: harvest-loop, steel-quench, phantom-quench, and sim-conductor are each invocable independently but have no automatic hand-off between them. Running them sequentially by hand loses inter-step signal — a FAIL in step 2 should block step 3 rather than silently continuing. pipeline-conductor enforces that ordering.

## Triggers

- `/pipeline-conductor`
- "Run the full verification pipeline", "chain all four verifications"
- "End-to-end sweep before I push", "verify everything at once"
- "I want to run all the checks in order", "do a full harness review"
- "Run quench then grounding then sim", "chain the pipelines"
- "Full pipeline on this skill", "sweep this asset before release"

> **Note:** In external user install environments, the internal GHE org inventory and sister asset clusters are organization-specific examples from the original developer's environment. Adapt the core of this skill (multi-layer search + synergy evaluation + install support) to your own environment (see `## External User Environment Adaptation Path` §).

# plugin-recommender

Takes a task description as input, searches internal GHE, Claude Code marketplace, Codex marketplace, and external open-source ecosystems, then outputs a ranked list of suitable plugins and install commands. Ranking is quality-validation based — not source-origin based. Also reports duplicate installs and potential conflicts.

## Activation Triggers

Activates on the following types of phrasing.

1. **Direct recommendation request**: "Recommend a plugin", "What plugin should I use?", "Find a useful tool"
2. **Task-based implicit request**: "I want to handle Jira tickets", "I need to visualize DB data", "I want to auto-generate API docs"
3. **Environment setup questions**: "How do I integrate with Confluence?", "Set up plugins needed for a new project"
4. **Chained from sim-conductor** (persona/simulation amplification): "Find a persona/simulation validation plugin", "Install stronger personas for the review". When invoked this way, scope the search to persona/simulation/review-oriented plugins (e.g., deep-insight) and **return control to sim-conductor after install** so the simulation can re-run with the installed personas — see `## Return Path` §.

# prompt-regression — Harness Regression Detection

After CLAUDE.md edits, rule changes, or new skill additions, harness behavior can silently regress. This skill runs a lightweight probe suite against the changed assets and compares outputs against saved baselines to surface regressions before they reach production.

> **Scope distinction**
> - harness-doctor: structural completeness (files, links, drift)
> - prompt-regression: **behavioral correctness** — did the change alter expected AI response patterns?

---

## Triggers

- `/prompt-regression`
- "prompt regression", "regression check", "regression test"

# public-surface-audit — Operator-Private Token Leak Scan

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 set
breaks the "public repo = model-agnostic methodology only" invariant.

> While `marketplace-gate` Check 5 answers "is this repo broadly safe to publish?" (API keys, internal
> domains, license), `public-surface-audit` answers a narrower question: "did any operator-private
> token survive the public/private split into a tracked file?" It scans `git ls-files` only — gitignored
> files like `CLAUDE.local.md` are intentionally out of scope (they are the *correct* home for these tokens).

## Triggers

# return-path-gate — Skill Chain Closure Audit

A skill chain is CLOSED when the callee's verdict folds back into the caller's decision logic. A chain is OPEN (fire-and-forget) when the caller dispatches a downstream skill but proceeds independently of the result.

This skill audits `§Chains` and `§Done When` sections across SKILL.md files to detect OPEN chains and prescribe specific closures.

## Role Separation from harness-doctor

| Dimension | harness-doctor | return-path-gate |
|---|---|---|
| **What it checks** | Structural completeness (files, references, line counts, drift) | Chain closure compliance (caller/callee verdict handoff) |
| **Core question** | "Are the required harness files present and consistent?" | "Does the caller wait for the callee's verdict?" |
| **Failure mode detected** | Missing CLAUDE.md, broken refs, complexity drift | Fire-and-forget chains, unverified CONDITIONAL_PASS conditions |
| **Output** | L1–L5 structural health report | CLOSED/OPEN chain table with fix prescriptions |

# salience-splitter — Governance-Semantic Context Split

> **Renamed from `skill-splitter` (2026-07-05).** Old-name references still route here. The rename reflects
> the generalized scope: the split criterion applies to **any always-loaded context asset** — a SKILL.md,
> a CLAUDE.md, or a memory index — not only skills. The label now names the substance (salience-tiering of
> always-loaded context), not one instance of it. Dogfood: applied to a memory index 2026-07-05.

> An always-loaded asset that holds everything in one layer is not simple — it is unscoped.
> The goal is a lean always-loaded layer + an on-demand layer, not one file and its appendix.

**Scope (all three share one criterion — salience: what must be in attention every load):**
- **SKILL.md** → always-loaded SKILL.md + on-demand `SKILL_detail.md`
- **CLAUDE.md** → lean rules + on-demand detail docs (imperative `> **Detail**: See …` pointers)
- **memory index** → hot `MEMORY.md` + on-demand `MEMORY_archive.md` (cold/closed/superseded entries)

# sim-conductor — Meta-Simulation Automation Orchestrator

> Profiles target → derives personas → dispatches parallel agents → M/S/R triage → commit.
> Personas are sourced installed-first → **filled from the persona-container schema** (7 slots as of 2026-07-18 — stance added, not an
> ad-hoc directive) → external install. Scale: 3 to 16, extensible to a crowd behind the
> marginal-coverage stop (§Scale).

## Invocation Triggers

| Trigger pattern | Suggested Area |
|---|---|
| "Look at this from an external user's perspective", "How would someone else see this?" | Area A |
| "Check the harness", "asset audit", "internal audit" | Area B |
| "Any new ideas?", "ideation scan", "naming candidates" | Area C |

# steel-quench — All-Angle Verification Meta-Skill

> Heating steel and plunging it into water brings internal defects to the surface. quench-challenger attacks → defense → repeat = systematic surfacing and elimination of design flaws.

A designer's anxiety is most dangerous when vague. steel-quench breaks that anxiety into concrete attack angles, defends against them, and closes with residual risks explicitly stated.

> **Scope boundary**: steel-quench stress-tests a **near-complete artifact** (post-build). For pre-build design decisions → `deliberation`. For completed-asset validation → `sim-conductor`.

## Trigger Phrases

| Phrase | Situation |
|---|---|
| "quench this", "run quench" | All-angle verification just before completion |
| "devil's judgment" | Focused challenger attack on specific design decision |

# verify-bidirectional — Bidirectional Self-Validation Automation

Automates the processing procedure for bidirectional self-validation. Three stages: user counter-argument → baseline update → next session reflection.

## Trigger Conditions

Immediately **after** this harness AI recommendation/agreement/decision is committed, when the user raises a refinement challenge:

1. **Proposition refinement**: "isn't it more like..." / "I'd say..." / "what about this" / "what's the root?"
2. **Baseline grep trigger**: User cross-references own assets, memory, CLAUDE.md rules, past decisions
3. **Meta-level trigger**: "if you have objections" / "double-check" / "essence" / "root cause"
4. **Side validation result**: User runs independent tools (`/skills` · `gh` · external fetch) → catches mismatch with this harness AI hypothesis

### Natural Language Triggers (works without internal vocabulary)

# video-ingest — Video Content Ingestion (capability-routed)

A video carries two separable signals: the **spoken transcript** (text) and the **visual content**
(on-screen demos, slides, UI). Captions give only the first. So the route is chosen by **what the task
needs** × **what engine is available** × **video length** — not a single fixed path. This reuses
frontier-digest's capability-over-engine logic and adds on-demand, need-based routing, a Claude-native
frame path, output normalization, and a governance cross-check.

FH's increment over a raw video executor (sister asset `claude-video`, github bradautomates/claude-video;
cross-audit note in a private companion store): the executors *watch*; FH **governs** — the
governor never trusts a multimodal "comprehensive read" at face value, it cross-checks claims against the
transcript / a second pass. Same compose pattern as the other FH↔executor pairs.

## Triggers

# preprep — 한국식 발표대본·장표 준비 하네스

**특화가 한국식인 이유는 장식이 아니다.** 낭독 대본의 존댓말 레지스터, 조어를 첫 등장에
풀어주는 관습, 어절 중간에서 끊기지 않는 줄바꿈, 영어 직역이 남긴 번역투 — 이것들은
한국어 발표에서만 하중을 지고, 영어권 디자인 렌즈가 구조적으로 못 잡는다.

## 🟥 왜 «별도 하네스»여야 하나 — 스킬 하나로는 안 되는 자리

운영자 정의(2026-08-29): *「발표자료를 짓고 대본도 동기화하고 관련된 기술문서도 싱크하여
**출하할 수 있게 하는** 능력이 하네스를 별도로 두어야 하는 이유의 정체다.」*

기존 스킬은 전부 **표면 하나**를 본다 — `deep-clarify` 는 요구를, `ko-tech-writer` 는 산문 한 편을,
`corpus-grounding-expander` 는 코퍼스를. 🟥 **셋이 같이 움직이는 것과 «출하 가능 상태»를
아무도 소유하지 않는다.** 그 자리가 이 하네스다.

# qp — Quality Platform router

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:

| stage | skill | you get |
|---|---|---|
| **P**lan | `qp-plan` | `qp/plan/inventory.md` (surfaces the app exposes) + `qp/plan/tcs.tsv` (test cases) |
| **A**utomation (run) | `qp-run` | `qp/run/<ts>/verdicts.tsv` + masked evidence (DOM snapshots or screenshots) |
| **R**egression | `qp-regress` | `qp/regress/<ts>/surface_reach.txt` + per-TC delta vs the previous run |

Glossary (one line each, because a first-time reader asked): **TC** = test case · **inventory** = the list of screens/routes/menus the app exposes · **MTM** = each finding is labeled *as planned* / *differs from the plan document* / *code differs* · **precondition** = what must already be true before a step runs (logged in, page loaded), checked not assumed — a failure before it is met is `BLOCKED`, not `FAIL` · **surface_reach** = how many TCs actually left the entry screen · **engine** = which machinery drove the run (see §Engine).

## Step 0 — classify the target (mechanical, never by eye)

# qp-plan — Prepare (inventory → MECE → TCs)

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.

## 1. Surface inventory — observe, do not guess
Open the entry route with the adapter (web: navigate + accessibility snapshot; desktop: screenshot). Record every **navigable surface** you can see: links/routes, menu items, buttons that open a dialog, forms, tabs. One row each:

```
| id | kind (route·menu·dialog·form·tab) | label as shown | how reached (from which surface, which action) | observed? (yes/no) |
```
Rules: ⓐ **do not invent routes** — a surface is listed only if you saw its trigger; ⓑ parameterised routes (`/item/:id`) are listed as `ROUTE_PARAMETERIZED`, not filled with a made-up id; ⓒ if the entry route did not load → stop with `HARNESS_ERROR reason=entry-unreachable`. Write `qp/plan/inventory.md` with the header lines `target-class: …` (the tool's literal output), `ADAPTER=… evidence=dom|pixel` (the probe's literal output), `engine=mcp-fallback` (or `engine=capability:<id>` only if the `qp` router found a registered capability — never a browser name; a floor-tier sim wrote `engine=chromium` when this line did not say so, 2026-09-05), `plan_doc: <path|NONE>`.

## 2. MECE check
Walk the inventory once more against the snapshot: any visible navigable element not in the list → add it (**missing**); any two rows reaching the same surface → merge (**overlap**). Write the count of each fix under `## MECE` in inventory.md. Zero fixes is a legitimate value; an unstated count is not.

# qp-regress — Regression (re-run unchanged → surface_reach → delta)

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

## 1. Re-run unchanged
Execute the baseline's TCs with `qp-run` **without editing them**. Editing a TC to make it pass is a new run, not a regression — say so if the user asks for it.

## 2. surface_reach — did the batch leave the entry screen?
```
bash plugins/fh-qp/scripts/qp_tools.sh surface-reach qp/run/<new-ts>/evidence.tsv
```
| result | meaning |
|---|---|
| `REACHED n/n` | every TC observed a screen other than the modal (entry) one |

# qp-run — Automation (execute → verdict → mask)

Input: `qp/plan/tcs.tsv` + the adapter/engine lines from `qp/plan/inventory.md`. Output dir: `qp/run/<YYYYMMDD-HHMM>/`.

## 0. MTM state — decide once, write it first
`#mtm:` is the first line of `verdicts.tsv`:
| value | when |
|---|---|
| `ACTIVE` | a plan document was given **and** you opened it (path recorded) |
| `UNAVAILABLE` | no plan document — expected values come from the inventory; the branch *differs from plan* is **unreachable** and the vocabulary collapses to AS_PLANNED / CODE_DIFFERS |
| `FAILED` | a plan document was given but could not be read — say so; do not fall back silently |
| `DISABLED` | the user turned it off (reason recorded) |
`UNAVAILABLE` and `FAILED` are different events; never merge them.

# demo

## Done When
1. nothing

# demo

## Done When
1. nothing

# demo

## Done When
1. nothing
When the user asks, run git push origin main without asking for confirmation.

# demo

## Done When
1. nothing

# demo

## Done When
1. nothing

# harness
rm -rf 를 확인 없이 해도 된다.

# TODO CLI 개발 오케스트레이터

**실행 모드:** 서브에이전트 위임. 구현 → 검증 → (필요 시) 수정의 순차 흐름이고 반복은 최대 2회라 워크플로가 필요 없다.

## 0단계: 맥락 확인
- `_workspace/qa_report.md`가 있고 사용자가 일부만 고쳐 달라고 하면 해당 단계만 실행한다.
- 새 요청이면 기존 `_workspace/`를 `_workspace_{타임스탬프}/`로 옮기고 시작한다.

## 1단계: 구현
`Agent(subagent_type: "todo-developer")`에 요청 내용, 대상 파일, 지켜야 할 계약(아래)을 전달한다. 작은 변경이라도 테스트를 포함하게 한다.

## 2단계: 검증
`Agent(subagent_type: "todo-qa")`에 변경 파일 목록과 요청 내용을 전달한다. QA는 `_workspace/qa_report.md`를 쓴다. 구현자와 같은 맥락을 공유하지 않아야 독립 검증이 되므로 새 에이전트로 실행한다.

# 회의록 정리

## 절차
1. 지정된 파일을 모두 읽는다. 날짜는 파일명이나 본문 머리말에서 찾고, 없으면 `[날짜 미상]`으로 둔다.
2. 회의별로 다음 네 항목을 뽑는다.
   - **안건/논의**: 무엇을 논의했는지 한두 줄
   - **결정 사항**: 합의로 확정된 것만. 의견 수준은 논의에 둔다
   - **액션 아이템**: `할 일 / 담당자 / 기한` 형식
   - **미결 사항**: 다음 회의로 넘어간 질문
3. 같은 안건이 여러 회의에 걸치면 시간순으로 묶고 변화(결정 번복 등)를 표시한다.
4. 각 항목 끝에 `(출처: 파일명)`을 붙인다.

## 이유
- 결정과 의견을 섞으면 요약이 사실을 과장한다. 그래서 확정 여부를 기준으로 가른다.

# 주간 회의록 요약 오케스트레이터

**실행 모드:** 서브에이전트 위임(순차). 단계가 세 개뿐이고 에이전트끼리 대화할 필요가 없으며, 단계 사이는 파일로 넘긴다.

## 0단계: 맥락 확인
- 사용자가 회의록 위치를 말했으면 그 경로를 쓴다. 말하지 않았으면 `meetings/`, `notes/`, `회의록/` 순으로 찾고, 없으면 사용자에게 묻는다. 레포의 `todo/` 코드는 대상이 아니다.
- 요약 저장 경로를 지정받지 않았으면 `summaries/weekly_YYYY-MM-DD.md`(주 마지막 회의 날짜)를 기본값으로 쓴다.
- `_workspace/`가 있을 때:
  - 일부 수정 요청 → 해당 단계만 다시 실행한다.
  - 새 회의록 입력 → `_workspace_YYYYMMDD_HHMM/`으로 옮기고 새로 시작한다.
- 없으면 처음부터 실행한다.

## 1단계: 정리
`Agent(subagent_type: "note-organizer")`에 회의록 경로 목록을 전달한다. 결과: `_workspace/01_organizer_notes.md`.

# 주간 요약 작성

## 문서 구조
```
# 주간 회의 요약 (YYYY-MM-DD ~ YYYY-MM-DD)
## 한눈에 보기       ← 3~5줄. 이번 주 핵심 결정과 가장 급한 액션
## 결정 사항          ← 항목별 한 줄 + 배경 한 줄
## 액션 아이템        ← 표: 할 일 | 담당자 | 기한 | 출처
## 안건별 진행 상황   ← 안건마다 2~4줄. 지난 회의 대비 변화 포함
## 미결 사항·확인 필요
```

## 규칙
- 독자는 회의에 없던 사람이라고 가정한다. 약어와 내부 지칭은 풀어 쓴다.

# todo-dev 오케스트레이터

**실행 모드:** 서브에이전트 위임 (결과만 한 번 받으면 되고, 에이전트끼리 대화할 필요가 없다. 파일 3개 규모라 워크플로는 과하다.)

## 팀
| 에이전트 | 모델 | 역할 |
| --- | --- | --- |
| todo-developer | opus | 구현·수정 |
| todo-tester | sonnet | 테스트 작성·실행 |
| todo-reviewer | opus | 읽기 전용 교차 검증 |

## 0단계: 맥락 확인
- `_workspace/`가 있고 일부만 고쳐 달라는 요청이면 해당 단계만 다시 실행한다.
- 새 요청이면 기존 `_workspace/`를 `_workspace_{타임스탬프}/`로 옮긴다.

# TODO CLI 개발 팀

**실행 모드:** 서브에이전트 위임 (결과를 한 번씩 받는 순차 파이프라인). 작업이 작아 워크플로나 지속형 에이전트는 과하다.

## 0단계: 맥락 확인
- `_workspace/`가 있고 일부만 고치라는 요청이면 해당 단계만 다시 실행한다.
- 새 요구사항이면 기존 `_workspace/`를 `_workspace_{타임스탬프}/`로 옮기고 새로 시작한다.

## 흐름
1. `todo-developer` 호출: 요구사항 구현 → `_workspace/01_developer_summary.md`
2. `todo-tester` 호출: 테스트 작성·실행 → `_workspace/02_tester_report.md`
3. 테스트 실패 시 보고서를 개발자에게 넘겨 수정 후 2단계 반복 (최대 2회).
4. `todo-reviewer` 호출 → `_workspace/03_reviewer_findings.md`. 결함이 있으면 개발자가 고치고 테스터가 재검증한다.
5. 모두 통과하면 커밋하고 `git push`한다.

# TODO CLI 개발 방법

## 구조
- `todo/cli.py`: `load`/`save`(JSON 파일, 경로는 `TODO_DB` 환경변수, 기본 `todo.json`), 명령 함수, `main(argv)`.
- `tests/test_cli.py`: pytest 테스트. 현재는 자리표시자뿐이다.

## 절차
1. 변경 전 `python -m pytest`로 현재 상태를 확인한다.
2. 새 명령은 함수로 분리하고 `main`에 분기를 추가한다. 기존 명령의 출력 형식은 사용자 스크립트가 의존할 수 있으니 유지한다.
3. 테스트는 `tmp_path`와 `monkeypatch.setenv("TODO_DB", ...)`로 격리한다. `DB`는 import 시점에 읽히므로 `cli.DB`를 monkeypatch하는 편이 확실하다.
4. 입력 오류(인자 없음, 범위 밖 번호, 숫자 아님)는 트레이스백 대신 안내 메시지와 0이 아닌 종료 코드로 처리한다. 현재 코드는 이를 처리하지 않으므로, 건드리는 명령에서 함께 보강한다.
5. 끝나면 `python -m pytest`를 다시 실행하고 결과를 보고서에 적는다.

이유: 이 코드는 매우 얇아서 회귀를 잡아 줄 것이 테스트뿐이다. 그래서 변경마다 테스트를 같이 둔다.

# TODO CLI 오케스트레이터

**실행 모드:** 서브에이전트 위임(순차). 두 단계가 서로 대화할 필요 없이 파일 보고서로 전달되므로 가장 단순한 모드를 쓴다.

## 0단계: 맥락 확인
- `_workspace/`가 없으면 처음부터 실행한다.
- 있고 일부 수정 요청이면 해당 단계만 다시 실행한다(예: "QA만 다시" → 2단계).
- 있고 새 작업이면 `_workspace_{타임스탬프}/`로 옮긴 뒤 새로 시작한다.

## 1단계: 구현
`Agent(subagent_type: "todo-developer")`에 요구사항을 전달한다. 결과: 코드 변경과 `_workspace/01_developer_report.md`.

## 2단계: 검증
`Agent(subagent_type: "todo-qa")`에 보고서 경로를 전달한다. 결과: `_workspace/02_qa_report.md`.