plan-eng-review: substrate-neutral existing-capability check (follow-up to #1587)

## Intent

Carry the *intent* of the rejected #1587 ("check existing capability before building new substrate code") into `/plan-eng-review` **without** any substrate-specific mechanics. The original baked in `gbrain integrations list`, SSH, `launchctl`, and `ops//` paths — that correctly got closed for not generalizing. This issue scopes what the substrate-neutral version looks like.

## The generalizable principle

Before a plan proposes building **new long-running infrastructure** (a daemon, queue, worker, scheduled job, or integration glue layer) to connect a source/sink to some platform, the reviewer should verify the platform doesn't *already* expose an extension surface that delivers the same pattern. Prefer **configure/extend an existing surface** over **build parallel infrastructure**.

This is a generic engineering-review heuristic ("don't reinvent the platform's own plugin system"), not a gbrain rule. It applies to any plan that targets a platform with a capability/extension surface.

## Proposed substrate-neutral Step 0.5

**Trigger:** the plan introduces new persistent infra (background process, queue, consumer binary, scheduled task, webhook receiver, OAuth/integration glue) whose job is to move data into or out of an existing platform.

**Check (reviewer-supplied, not hardcoded):** identify whether the target platform exposes a capability surface, using *that platform's own discovery mechanism*. Examples by platform shape — the reviewer picks the relevant one:
- Plugin / extension registry (editors, CMSes, CI systems)
- Integration / app catalog (SaaS platforms, Slack/GitHub apps)
- Recipe / manifest directory (agent runtimes, knowledge-graph substrates)
- Capabilities or feature-flags endpoint (internal services)
- Package / module registry (language ecosystems)

**Decision branches:**
1. Capability exists and is available → configure it; do not build.
2. Capability exists but is dormant/misconfigured → investigate why before building anything new.
3. Platform supports user-authored extensions but none covers this case → author one *in the platform's extension format*, don't build a bespoke parallel system.
4. Platform has no extension surface at all → only now is new infrastructure justified.

**Skip when:** the plan targets greenfield code the team fully owns, with no external platform whose capability surface could pre-empt the work (pure web apps, standalone libraries, CLIs).

## What changed vs #1587

| #1587 (rejected) | substrate-neutral |
|---|---|
| `ssh 'gbrain integrations list && launchctl list ...'` | reviewer names the platform's own discovery mechanism |
| Assumes `ops//` layout | no path assumptions |
| Lists gbrain/OpenClaw/Hermes by name | describes platform *shapes*, not products |
| "submit a markdown recipe upstream" | "author an extension in the platform's format" |

## Open questions for scoping

1. Is this a new **Step 0.5**, or a bullet folded into the existing Step 0 scope-challenge ("is this actually new, or platform-provided")?
2. Should it be advisory (reviewer notes it) or a hard gate (STOP like the complexity check)?
3. Worth a one-line example in the SKILL.md, or keep it purely principle-level to avoid re-introducing substrate bias?

Happy to send a PR once the shape is agreed.