@chrono-meta/fh-gate 1.1.0 → 1.2.1

package/plugins/fh-meta/skills/pipeline-conductor/SKILL.md

@@ -0,0 +1,430 @@
+---
+name: pipeline-conductor
+description: Chains the four core FH verification pipelines (harvest-loop → steel-quench → source-grounding-audit → sim-conductor) into a single gated sweep. Accepts a scope (single skill, specific asset, full harness) and aggregates results into one structured report. Supports --quick mode (steps 2+3 only) and --full mode (all four steps). Triggered by "run the full pipeline", "chain all verifications", "end-to-end sweep", "pipeline-conductor", or "verify everything".
+user-invocable: true
+allowed-tools: ["Read", "Write", "Bash", "Grep", "Glob", "Agent"]
+model: sonnet
+---
+
+# 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, source-grounding-audit, 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"
+
+> **Disambiguation**: "run the pipeline" alone may trigger harvest-loop (which uses identical phrasing). Prefer "run pipeline-conductor" or "chain all verifications" for unambiguous activation.
+
+## Modes
+
+| Flag | Steps run | When to use |
+|---|---|---|
+| `--full` (default) | Steps 1 → 2 → 3 → 4 | Complete verification sweep |
+| `--quick` | Steps 2 → 3 only | Fast adversarial + phantom check; skip knowledge loop and simulation |
+| `--no-sim` | Steps 1 → 2 → 3 | Skip sim-conductor (e.g., no sim environment available) |
+
+**Mode qualifier on verdicts**: `CLEAN (--quick)` and `CLEAN (--no-sim)` do not qualify as pre-release gates. Only `CLEAN (--full)` is sufficient for external publish or PR approval.
+
+## Verdict Format
+
+Every step emits exactly one verdict line before handing control to the next step:
+
+```
+Verdict: PASS | CONDITIONAL_PASS | FAIL | ESCALATE
+Basis:   [one-line summary of deciding factor]
+```
+
+| Verdict | Meaning | Chain behavior |
+|---|---|---|
+| `PASS` | Step complete, no blocking issues | Proceed to next step |
+| `CONDITIONAL_PASS` | Issues found but none are blockers; must be resolved before final report | Capture items, proceed to next step; flag in final report |
+| `FAIL` | Blocking issue found | Halt chain, surface to user immediately |
+| `ESCALATE` | Ambiguous state requiring human judgment | Pause chain, present three options to user |
+
+`CONDITIONAL_PASS` means proceed, not skip. Items captured under `CONDITIONAL_PASS` accumulate into the final report's Pending section and must be addressed before the sweep is considered clean.
+
+`FAIL` halts the chain. The user decides whether to fix-and-resume or abandon the sweep.
+
+`ESCALATE` pauses the chain. The user chooses one of three paths — the chain resumes or closes based on their decision.
+
+### ESCALATE Handling
+
+When any step returns `ESCALATE`, present:
+
+> "Step N returned ESCALATE: [basis]. Choose:
+> (a) Make a decision — state your judgment and I will incorporate it and continue the chain.
+> (b) Accept and continue — mark this as PENDING in the report and proceed to the next step.
+> (c) Abort — close the sweep as BLOCKED."
+
+- Option (a): User provides judgment → incorporate as resolution note → re-evaluate step gate with decision context → continue chain.
+- Option (b): Mark ESCALATE item as PENDING → continue chain from step N+1.
+- Option (c): Halt, output BLOCKED report with ESCALATE item in blocking section.
+
+---
+
+## Step 0. Scope, Mode, and Translation
+
+Determine the following before running any pipeline step.
+
+**1. Scope**: What is being verified?
+   - Single skill: path to `SKILL.md` (e.g., `plugins/fh-meta/skills/foo/SKILL.md`)
+   - Specific asset: file or directory path
+   - Full harness: all assets under `plugins/` and `templates/`
+
+**2. Mode**: `--quick`, `--no-sim`, or `--full` (default)
+
+**3. Branch**: Current git branch (used for regression guard and report header)
+
+If scope is not specified, ask:
+> "What should I sweep? (e.g., a specific skill path, a directory, or the full harness)"
+
+Do not infer scope — a wrong scope produces misleading verdicts.
+
+### Scope Translation Table
+
+The four constituent skills use heterogeneous scope models. Translate the pipeline scope to each skill's invocation form before running any step:
+
+| Pipeline scope | harvest-loop (Step 1) | steel-quench (Step 2) | source-grounding-audit (Step 3) | sim-conductor (Step 4) |
+|---|---|---|---|---|
+| Single SKILL.md | Check session findings relevant to this skill; propose mode only | Adversarial attack on this SKILL.md | Back-trace claims in this SKILL.md to declared sources | Area D (artifact review) on this SKILL.md |
+| Specific directory | Check session findings in this domain | Attack all SKILL.md files in directory | Back-trace all claims in directory | Area A + Area D on the domain |
+| Full harness | Check all recent session findings | Attack all harness assets under scope | Back-trace all claims across harness | Area A + Area B + Area D |
+
+### Step 0 Output
+
+```
+pipeline-conductor — Sweep Plan
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Scope:  {scope}
+  Mode:   {--full / --quick / --no-sim}
+  Branch: {branch name}
+  Steps:  {1 → 2 → 3 → 4 / 2 → 3 / 1 → 2 → 3}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Proceed? (Y: run / N: cancel)
+```
+
+---
+
+## Step 0.5. return-path-gate — Pre-flight Chain Audit
+
+> Skip if return-path-gate is not installed or scope is a single non-pipeline skill.
+
+Run `/return-path-gate --skill [scope]`.
+
+| return-path-gate result | Step 0.5 verdict | Chain behavior |
+|---|---|---|
+| 0 OPEN chains | `PASS` | Proceed |
+| MEDIUM/LOW severity OPEN chains only | `CONDITIONAL_PASS` | Proceed; capture in Pending |
+| 1+ HIGH severity OPEN chains | `FAIL` | **Halt sweep** — fix chains before running pipeline |
+
+**On FAIL (HIGH severity OPEN chains)**:
+
+```
+[Step 0.5 — return-path-gate]
+  Verdict: FAIL
+  Basis:   HIGH severity OPEN chain(s) — inter-step verdicts unreliable with broken chains
+  Open:    [list of OPEN chains with severity]
+
+Fix OPEN chains then re-run pipeline-conductor.
+Skip? (S: override gate — records as degraded, disqualifies CLEAN (--full) status)
+```
+
+`S` (skip) is available but must be declared explicitly. Skipping records as `degraded: return-path-gate (user override)` in the final report and the sweep cannot reach `CLEAN (--full)` status regardless of subsequent step verdicts.
+
+**On CONDITIONAL_PASS (MEDIUM/LOW only)**: Capture OPEN chains in Pending. Continue to Step 1.
+
+---
+
+## Step 1. harvest-loop — Knowledge Loop Check
+
+> Skipped in `--quick` mode.
+
+Check for harvest-loop signals in the current session. pipeline-conductor reads session context for harvest-loop findings rather than invoking harvest-loop directly — invoking harvest-loop mid-sweep would start a new harvest cycle that conflicts with the sweep's own pattern collection. If no harvest-loop run exists in this session, pipeline-conductor can invoke harvest-loop in proposal mode (`/harvest-loop`) as a pre-Step-1 option, but this is not automatic.
+
+**What it checks**: Whether recent session learnings have been absorbed, whether duplicate skill candidates are pending, whether knowledge loop integrity issues exist in the current session.
+
+**Invocation path**:
+- If harvest-loop ran in this session: read its output and incorporate findings.
+- If harvest-loop did not run in this session: output `CONDITIONAL_PASS` — knowledge loop not validated in this sweep.
+- If harvest-loop auto-skipped (fewer than 3 patterns found): output `CONDITIONAL_PASS` — sub-threshold, knowledge loop not validated.
+
+**Verdict criteria**:
+
+| harvest-loop result | pipeline-conductor verdict |
+|---|---|
+| Ran this session — all steps pass, no pending patterns | `PASS` |
+| Ran this session — patterns found but no blockers | `CONDITIONAL_PASS` — capture pattern list |
+| Ran this session — semantic drift or loop failure detected | `FAIL` |
+| Did not run this session | `CONDITIONAL_PASS` — note: knowledge loop not validated |
+| Auto-skipped (< 3 patterns) | `CONDITIONAL_PASS` — note: sub-threshold, not validated |
+
+**On FAIL**: Output the harvest-loop failure reason. Ask:
+> "harvest-loop reported a blocking issue. Fix and re-run Step 1, or abort the sweep?"
+
+**On CONDITIONAL_PASS**: Log all pending patterns or unvalidated notes. Continue to Step 2.
+
+```
+[Step 1 — harvest-loop]
+  Verdict: {verdict}
+  Basis:   {one-line}
+  Pending: {list of items if CONDITIONAL_PASS, else "none"}
+```
+
+---
+
+## Step 2. steel-quench — Adversarial Verification
+
+Run steel-quench against the target scope.
+
+**What it checks**: Design attack surface, trigger phrase collisions, over-engineered steps, self-declaration language, structural flaws surfaced by devil-advocate rounds.
+
+**Invocation**: Run steel-quench in its standard mode. For `--quick`, this is the first step.
+
+**steel-quench severity vocabulary** (S/A/B grade — not M/S/R):
+- **S-grade**: Immediate blocker — must fix before proceeding
+- **A-grade**: Required before deployment — fix before external release
+- **B-grade**: Improvement recommended — non-blocking
+
+**Verdict criteria**:
+
+| steel-quench result | pipeline-conductor verdict |
+|---|---|
+| 0 S-grade findings | `PASS` |
+| A-grade or B-grade findings only | `CONDITIONAL_PASS` — capture finding list |
+| 1+ S-grade findings | `FAIL` |
+| Wave 4 (Meta-Aware Adversary) surfaces structural ambiguity | `ESCALATE` |
+
+**On FAIL**: Output S-grade finding(s) from steel-quench. Ask:
+> "steel-quench found a blocking issue. Fix and re-run Step 2, or abort the sweep?"
+
+**On CONDITIONAL_PASS**: Capture A-grade and B-grade findings. Continue to Step 3.
+
+```
+[Step 2 — steel-quench]
+  Verdict: {verdict}
+  Basis:   {one-line}
+  Findings:
+    S-grade: {count} — {top item or "none"}
+    A-grade: {count} — {top item or "none"}
+    B-grade: {count} — {top item or "none"}
+```
+
+---
+
+## Step 3. source-grounding-audit — Phantom Claim Detection
+
+Run source-grounding-audit against the target scope.
+
+**What it checks**: Proper nouns, numerical values, file paths, and branching conditions back-traced to declared source files. Claims not found in source are marked Phantom.
+
+**Invocation**: Run source-grounding-audit scoped to the same target as Steps 1 and 2.
+
+**Load-bearing Phantom** (binary test — apply mechanically):
+
+A Phantom is load-bearing if it appears in any of:
+- `§Done When` section of the skill under audit
+- Any numbered `§Step N` execution body
+- `§Chains` with mandatory dispatch language (`→ Mandatory next`)
+
+All other locations (§Triggers, advisory §Chains language, frontmatter description) are non-load-bearing by definition.
+
+**Verdict criteria**:
+
+| source-grounding-audit result | pipeline-conductor verdict |
+|---|---|
+| 0 Phantoms, all claims grounded | `PASS` |
+| Phantom claims found, none load-bearing (binary test) | `CONDITIONAL_PASS` — list Phantoms |
+| 1+ load-bearing Phantoms | `FAIL` |
+| Grounding ambiguous (source file exists but content unclear) | `ESCALATE` |
+
+**On FAIL**: Output the load-bearing Phantom(s). Ask:
+> "source-grounding-audit found a load-bearing Phantom claim. Fix and re-run Step 3, or abort the sweep?"
+
+**On CONDITIONAL_PASS**: Capture non-load-bearing Phantoms. Continue to Step 4.
+
+```
+[Step 3 — source-grounding-audit]
+  Verdict: {verdict}
+  Basis:   {one-line}
+  Phantoms: {count} — {load-bearing: Y/N} — {top item or "none"}
+```
+
+---
+
+## Step 4. sim-conductor — Pre-Deploy Simulation
+
+> Skipped in `--quick` and `--no-sim` modes.
+
+Run sim-conductor against the target scope.
+
+**What it checks**: Transferability to external users, new-user entry point friction, power-user edge cases, artifact quality from an outside perspective.
+
+**Area B cadence check** (sim-conductor Area B has a once-per-week frequency limit):
+
+```bash
+find tracks/_meta/ -name "*sim_conductor*" -newer "$(date -v-7d +%Y-%m-%d 2>/dev/null || date -d '7 days ago' +%Y-%m-%d 2>/dev/null)" 2>/dev/null | head -1
+```
+
+- Result found (Area B ran within 7 days): skip Area B → run Area A + Area D only. Capture as `CONDITIONAL_PASS` with note: "Area B skipped — within 7-day cadence limit."
+- No result (Area B not run within 7 days): run Area A + Area B + Area D (scope permitting).
+
+**Invocation**: Area A + Area B (if cadence allows) + Area D (if scope is a specific SKILL.md or document).
+
+**Verdict criteria**:
+
+| sim-conductor result | pipeline-conductor verdict |
+|---|---|
+| 0 M-tier findings across all personas | `PASS` |
+| S/R-tier findings only | `CONDITIONAL_PASS` — capture finding list |
+| 1+ M-tier findings from any persona | `FAIL` |
+| Persona results conflict, resolution requires human judgment | `ESCALATE` |
+
+**On FAIL**: Output M-tier finding(s) from sim-conductor. Ask:
+> "sim-conductor found a blocking issue. Fix and re-run Step 4, or accept findings and close with FAIL status?"
+
+**On CONDITIONAL_PASS**: Capture S/R-tier findings. Proceed to final report.
+
+```
+[Step 4 — sim-conductor]
+  Verdict: {verdict}
+  Basis:   {one-line}
+  Area B:  {ran / skipped — cadence limit}
+  Findings:
+    M: {count} — {top item or "none"}
+    S: {count} — {top item or "none"}
+    R: {count} — {top item or "none"}
+```
+
+---
+
+## Step 5. Aggregated Report
+
+After all steps complete (or after chain halt), output the aggregated report.
+
+```
+pipeline-conductor — Sweep Report
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+  Scope:  {scope}
+  Mode:   {mode}
+  Branch: {branch}
+  Date:   {YYYY-MM-DD}
+
+  Step 0.5 — return-path-gate:       {PASS / CONDITIONAL_PASS / FAIL / SKIPPED / degraded}
+  Step 1   — harvest-loop:           {PASS / CONDITIONAL_PASS / FAIL / ESCALATE / SKIPPED}
+  Step 2   — steel-quench:           {verdict}
+  Step 3   — source-grounding-audit: {verdict}
+  Step 4   — sim-conductor:          {verdict}
+
+  Overall: {CLEAN (--full) / CLEAN (--quick) / CLEAN (--no-sim) / PENDING / BLOCKED}
+
+  ── Pending items (CONDITIONAL_PASS steps + accepted ESCALATE) ──
+  {item list, or "none"}
+
+  ── Blocking items (FAIL steps + unresolved ESCALATE) ──
+  {item list, or "none — sweep completed cleanly"}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+**Overall verdict logic**:
+
+| Condition | Overall |
+|---|---|
+| All steps PASS | `CLEAN ({mode})` |
+| Any step CONDITIONAL_PASS or accepted ESCALATE; none FAIL | `PENDING` |
+| Any step FAIL or unresolved ESCALATE (option c) | `BLOCKED` |
+
+**Mode semantics**:
+- `CLEAN (--full)`: Safe to proceed with commit, PR, or external release.
+- `CLEAN (--quick)` / `CLEAN (--no-sim)`: Safe for internal iteration only — not sufficient for external publish or PR approval gate.
+- `PENDING`: Resolve captured items before external release.
+- `BLOCKED`: Do not proceed. Fix blocking items and re-run affected step(s).
+
+### Report Persistence
+
+Save the report to:
+```
+tracks/_meta/pipeline_conductor_{YYYY-MM-DD}_{scope-slug}.md
+```
+
+If `tracks/_meta/` does not exist, output a B-grade warning and skip persistence.
+
+---
+
+## Resume After Fix
+
+**After FAIL**:
+
+1. User fixes the issue.
+2. User says "resume from step N" or "re-run step N".
+3. pipeline-conductor re-runs only the failed step and its gate.
+4. On PASS, continues the chain from step N+1.
+5. Does not re-run steps that already passed (unless user explicitly requests a full restart).
+
+Resume is scope-bound — the scope from Step 0 is preserved across resume calls.
+
+**After ESCALATE**:
+
+1. Present the three options (see ESCALATE Handling above).
+2. Option (a) — user provides decision: incorporate as resolution note, re-evaluate the step gate with decision context, continue chain from step N or N+1.
+3. Option (b) — accept and continue: mark ESCALATE item as PENDING, continue chain from step N+1.
+4. Option (c) — abort: close sweep, output BLOCKED report with ESCALATE item in blocking section.
+
+---
+
+## Simplification Guards
+
+- Do not propose pipeline-conductor for single-file read tasks or exploratory sessions.
+- If the user invokes one of the four constituent skills directly, do not auto-redirect to pipeline-conductor.
+- If only one step is needed, guide the user to call that skill directly.
+- For `--quick` mode on a trivial scope (single short SKILL.md), Steps 2+3 should complete in one pass without sub-Wave fan-out.
+
+---
+
+## Chains
+
+After a `CLEAN (--full)` or `PENDING` sweep, the following are natural follow-ons:
+
+- `field-harvest` — harvest patterns surfaced during the sweep
+- `hub-cc-pr-reviewer` — if sweep was run pre-PR, feed results into PR review
+- `agent-composer` — if multiple fix tasks are needed across the Pending list, compose agents to resolve them in parallel
+- `return-path-gate --all` — if Step 0.5 surfaced OPEN chains, run a full chain closure audit
+
+## Complexity Routing
+
+```yaml
+complexity_routing:
+  base: sonnet
+  escalate_when:
+    - high_stakes      # pre-external-publish or pre-deploy sweep
+    - full_revalidation # user requested "start over"
+    - cross_project    # scope spans 3+ projects
+  high: opus
+```
+
+---
+
+## Done When
+
+```
+Step 0 scope confirmed and scope translation table applied
++ Step 0.5 return-path-gate pre-flight: PASS / CONDITIONAL_PASS / FAIL (halts sweep) / explicitly skipped / degraded (user override)
++ All in-scope steps executed and verdicts emitted
++ Aggregated report output (Step 5 format)
++ Report saved to tracks/_meta/ (or skip warning issued)
++ Overall verdict qualified with mode: CLEAN (--full) / CLEAN (--quick) / CLEAN (--no-sim) / PENDING / BLOCKED
++ If BLOCKED: blocking items listed and user notified
++ If PENDING: pending items listed in report
++ If ESCALATE occurred: user presented three options; choice recorded in report
+```
+
+Verdict: PASS (all conditions met, sweep complete) | CONDITIONAL_PASS (sweep complete, pending items captured) | FAIL (chain halted, blocking items remain) | ESCALATE (chain paused, human decision required)
+
+A sweep is not done until the Step 5 report is output. Emitting per-step verdicts without the aggregated report is incomplete.

package/plugins/fh-meta/skills/plugin-recommender/SKILL.md

@@ -0,0 +1,221 @@
+---
+name: plugin-recommender
+description: 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.
+user-invocable: true
+allowed-tools: ["Grep", "GoogleWebSearch", "Bash"]
+model: sonnet
+---
+
+> **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` §.
+
+## Processing Steps (Step 0 Pre-check + 5-Step)
+
+### Step 0: Search Pre-check — GitHub Token Auth Status
+
+Before entering Step 2 multi-layer search, **gh CLI auth status check is mandatory**. Internal GHE + external GitHub auth are separate — if unauthenticated, guide user on how to generate and store tokens.
+
+Run `gh auth status`. For full PAT setup commands and host-branching scripts, see `SKILL_detail.md §Discovery-Bash`.
+
+**External users** (no internal GHE): skip internal GHE auth check — verify `gh auth status` for github.com only, then proceed to Step 1.
+
+**Internal non-hub users**: run Step 0 as-is, but remap Step 2 [Priority 1.5] sister asset clusters to your own org. See `## External User Environment Adaptation Path`.
+
+### Step 1: User Goal Analysis and Core Keyword Extraction
+
+Analyze the user's natural language request to extract core **domain** and **task** keywords.
+- `"I want to create Jira tickets and update their status"` → `domain: jira`, `task: create, update`
+- `"I want to auto-generate API docs"` → `domain: api, documentation`, `task: generate, auto`
+
+### Step 2: Multi-Layer Search Space Setup
+
+Search in priority order based on extracted keywords.
+
+#### Tier Classification Table (Quality-Validation Based)
+
+Tier is **independent of platform origin** (Anthropic / OpenAI / community). A well-benchmarked community plugin ranks higher than an official plugin with no performance data.
+
+| Tier | Criteria | Sources |
+|---|---|---|
+| **Tier 1** | Marketplace-listed + performance-validated (benchmark data or production usage evidence) | Anthropic official · Codex marketplace verified · CC marketplace verified · FH community reviewed (steel-quench + sim-conductor validated) |
+| **Tier 2** | Marketplace-listed, no explicit performance data | Any marketplace source (CC marketplace · Codex marketplace · npm · GHE) |
+| **Tier 3** | Not marketplace-listed, source-available (GitHub/npm) | Repo-only agents/plugins |
+| **Tier 4** | Not verified, private/internal | Internal team builds · unreviewed local experiments |
+
+1. **[Priority 1] Internal Curated List**: `knowledge/shared/plugin-catalog/recommended_plugins.md` — check this first for verified internal/external plugin list + Tier 1·2·3·4 classification. If user's task domain already appears in catalog, use results immediately.
+
+2. **[Priority 1.5] Internal GHE Sister Assets (partially completed work — Tier 2)**: Check if user's task domain already exists in internal sister asset clusters. Prioritize direct use or adoption of sister assets if the user's task falls within these cluster domains.
+
+3. **[Priority 2.5] Project Reference/Contribution Path**:
+
+    For cases where referencing or contributing to the project itself is more appropriate than installing a plugin. Provide guidance when there's intent for medium-term contribution rather than immediate use.
+
+    - **Fork reference**: Fork a similar project and customize for your environment
+    - **PR contribution**: Propose a PR to the relevant project if the desired feature is missing
+    - **Issue filing**: Guide on how to file a feature request issue
+
+    **Role separation (boundary with cross-ecosystem-synergy-detection)**:
+    - `plugin-recommender` [Priority 2.5]: When no immediately usable plugin is available → guide to project-level reference/contribution path (alternative to installing)
+    - `cross-ecosystem-synergy-detection`: Discover hidden synergies among already-installed skills (post-install utilization optimization)
+
+    Activation condition: Automatically entered when Step 2 [Priority 1]~[Priority 2] search yields no suitable plugin.
+
+4. **[Priority 2] Organization's Internal GHE (Tier 1–4)**: Search internal GHE with keywords like `claude-plugin`, `gemini-plugin` + user keywords / API search. Replace with your organization's internal GHE orgs.
+
+5. **[Priority 3] External Open-Source Ecosystem**: WebSearch / WebFetch — "best github actions for X", "claude plugin for Y", etc. Simplification guard: defer external install if internal assets suffice.
+
+   **Verified external search targets (as of 2026-05):**
+   - [`anthropics/claude-plugins-official`](https://github.com/anthropics/claude-plugins-official) — Anthropic-curated official plugin directory. Search here first for any task domain.
+   - [`Chat2AnyLLM/awesome-claude-plugins`](https://github.com/Chat2AnyLLM/awesome-claude-plugins) — Community aggregator: 75+ marketplaces, 1,196+ plugins catalogued (2026-05-25). Use for broad discovery.
+   - [`anthropics/claude-code/plugins/`](https://github.com/anthropics/claude-code/tree/main/plugins) — Anthropic first-party plugins bundled with Claude Code (e.g., `code-review` with 5 parallel Sonnet agents).
+
+### Step 2.5: Platform-Aware Discovery
+
+When queried for a specific capability (e.g., "adversarial reviewer for bash code"), search across all platforms before narrowing to candidates.
+
+**Discovery order (stop when sufficient Tier 1 candidates found):**
+
+1. **Installed locally** — `.claude/agents/`, `plugins/` in current cwd
+2. **FH native skills** — always-loaded knowledge in `plugins/fh-meta/` and `plugins/fh-commons/`
+3. **Claude Code marketplace** — `claude mcp search [capability]` or known CC registry (see verified targets above)
+4. **Codex marketplace** — `npx @openai/codex list-agents [capability]` or known Codex registry
+5. **npm ecosystem** — `@chrono-meta/`, `@anthropic/`, and other known-quality scoped packages
+
+**Discovery priority**: installed > FH native > Tier 1 (any platform) > Tier 2 > Tier 3 > Tier 4
+
+**When sim-conductor chains here for persona discovery**: apply the same platform-aware search scoped to persona/simulation/review capability tags. Return discovered agents with their Tier rating so sim-conductor can decide whether to install or use a built-in brief.
+
+For discovery bash commands (`claude mcp search`, `npx @openai/codex list-agents`, npm scoped search), see `SKILL_detail.md §Discovery-Bash`.
+
+### Step 2.6: Quality Validation Signals
+
+Use this table to determine Tier placement when a candidate's tier is ambiguous.
+
+| Quality signal | Weight |
+|---|---|
+| Published benchmark (accuracy/precision, reproducible) | High |
+| Production usage evidence (download count, GitHub stars > 100) | Medium |
+| Marketplace listing (official review process passed) | Medium |
+| FH community reviewed (steel-quench + sim-conductor validated) | High |
+| Author reputation (known team: Anthropic, chrono-meta, etc.) | Low |
+
+**Tier assignment rule**: two or more High-weight signals → Tier 1. One High or two Medium → Tier 2. Listed but no signals → Tier 2. Not listed, source-only → Tier 3. No external presence → Tier 4.
+
+### Step 3: Candidate Plugin Analysis and Ranking
+
+Analyze each candidate plugin's `README.md` and `plugin.json` to score and rank based on:
+
+- **Feature relevance**: How well does the description and keywords match user goals?
+- **Reliability and recency**: Recent commit date, star/fork count (external), internal usage frequency, etc.
+- **Install convenience**: Does it support `claude plugin install` directly?
+- **Synergy effect**: Call `cross-ecosystem-synergy-detection` to check synergy grade (★~★★★) with other currently installed plugins.
+- **Tier** (from §Tier Classification Table): report each candidate's Tier in the recommendation table.
+
+### Step 4: Present Recommendation List
+
+Output top 2-3 plugins in the following table format. Include Tier and Platform so the user can see the quality-validation basis at a glance. For full example outputs, see `SKILL_detail.md §Examples`.
+
+| Rank | Plugin Name | Tier | Platform | Recommendation Reason | Key Features | Synergy Effect |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| 1 | `[name]` | Tier N | [source] | [reason + evidence] | [features] | [synergy grade] |
+
+### Step 5: Install and Configuration Support
+
+When user selects desired plugin from recommendation list, help with installation.
+
+**5-0. Pre-install Duplicate Detection (pre-check — mandatory)**: check `claude plugin list`, `.claude/settings.json` `enabledPlugins`, and same-name conflict. For full duplicate detection procedure and same-name conflict handling steps, see `SKILL_detail.md §Install-Procedure`.
+
+**5-1 through 5-3. Install**: confirm intent → run install command → post-install configuration (API token, MCP connection, verify). Full install commands and configuration guidance at `SKILL_detail.md §Install-Procedure`.
+
+**5-B. External Asset Migration Path** (when non-plugin asset found): migration suitability check (3 criteria) → SKILL.md conversion template → location guidance. Full procedure at `SKILL_detail.md §Install-Procedure`.
+
+---
+
+## Constraints
+
+- **Recommendations, not guarantees**: Does not guarantee plugin performance, stability, or security.
+- **User consent required**: Does not auto-install without explicit consent.
+- **Search scope limitations**: Only searches within configured search space.
+
+## External User Environment Adaptation Path
+
+The internal GHE org inventory + sister asset clusters in this skill are examples from the original developer's environment. External user (mode C install) environment adaptation path — following forge-harness core proposition *"Beta + public release = obligation to have practical capabilities"*.
+
+### External User Environment Assumptions
+
+External users in 2 tiers:
+
+| Type | Internal GHE access | Applicable path |
+|---|---|---|
+| **Internal non-hub** (org employee, not owner) | Yes — run Step 0 as-is / remap Step 2 [1.5 priority] to own org sister assets | Use original developer environment as reference baseline / search based on own sister assets/org |
+| **External** (outside org) | No — apply entire Fallback Matrix below | Auto-skip internal GHE steps / search based on external GitHub |
+
+The core 5-step procedure (goal analysis → multi-layer search → candidate analysis → recommendation → install support) is cross-applicable to both types.
+
+> The Fallback Matrix below is for **external users**. Internal non-hub users can use Step 0·2 as-is.
+
+### Fallback Matrix (Original Developer Environment → External Environment Replacement)
+
+| Original developer environment dependency | External user environment fallback |
+|---|---|
+| **Step 0** internal GHE auth check | Check external GitHub auth only (`gh auth status` default host) — auto-skip internal GHE step |
+| **Step 2 [Priority 1.5]** internal sister asset clusters | User's own sister assets (personal/team GitHub org · internal marketplace) — this skill auto-maps user's own sister asset matrix |
+| **Step 2 [Priority 2]** internal GHE org inventory | External GitHub default org inventory (`anthropics` · `oh-my-claudecode` etc. plugin ecosystem marketplace) |
+| **Step 2 Tier table** Tier 1·2·3·4 classification | User's own Tier classification — use the quality-validation signals table (§Step 2.6) to assign tiers in your environment |
+
+### External User Usage Scenarios
+
+1. **External GitHub priority recommendations**: In environments without internal GHE access, call only Step 2 [Priority 1] curated list + [Priority 3] external GitHub search / auto-skip [Priority 1.5]·[Priority 2] internal GHE steps
+2. **Plugin marketplace discovery assistance**: Auto-search external ecosystems like `anthropics/claude-code` marketplaces · `oh-my-claudecode` · personal/team marketplaces
+3. **Core synergy evaluation**: Step 3 synergy evaluation + auto-calling cross-ecosystem-synergy-detection is cross-applicable to all environments
+4. **Same install support baseline**: Step 5 token generation path · MCP connection · 3 verification sub-paths work the same in external GitHub environments
+
+### Limitations (Explicit)
+
+- **Internal GHE org inventory** (Step 0 / Step 2 [Priority 2]) = original developer's organization-specific environment / external users should treat as reference baseline (auto-skipped)
+- **Sister asset clusters** (Step 2 [Priority 1.5]) = original developer's own environment / external users should map their own sister assets
+- **Core 5-step of this skill** (goal analysis + multi-layer search + candidate analysis + recommendation + install) = cross-applicable to all user environments / original developer examples are for reference
+- **catalog `recommended_plugins.md`** = original developer environment accumulated operation baseline / external users should create their own catalog or use this as reference baseline
+
+## Return Path (when chained from sim-conductor)
+
+When invoked as sim-conductor's **③ external-fetch branch** (Activation Trigger 4), this skill hands control back after install so the simulation can run with the new personas.
+
+```
+sim-conductor needs persona X (no installed/built-in match)
+  → plugin-recommender: scope search to persona/simulation/review plugins (e.g., deep-insight)
+  → recommend → install (user approval)
+  → RETURN to sim-conductor: report "[plugin] installed, personas [list] now available"
+  → sim-conductor re-runs the Area with persona X
+```
+
+**Done When (chained mode)**: install complete **AND** control returned to sim-conductor with the available-persona list. Ending at install without the return handoff = incomplete chain.
+
+**Simplification guard**: If a suitable persona is already installed or a built-in role brief covers the need, do not search/install — report the existing match and return immediately. The cheapest persona is the one already present.
+
+## Done When
+
+```
+All Steps 0~5 completed
++ Recommendation list table output (top 2~3 items, Tier + Platform + synergy grade included)
++ Install completed after user selection (or install skipped / 5-B migration path guided)
++ Duplicate detection results reported
+```
+
+## Failure Response
+
+On Claude API / MCP failure → refer to [`references/fallback-guide.md`](../../references/fallback-guide.md) manual checklist.
+
+---