Skip to content

feat(plan-eng-review): add Step 0.5 — existing-capability check before new substrate code#1587

Open
anoopkansupada wants to merge 1 commit into
garrytan:mainfrom
anoopkansupada:feat/plan-eng-review-step-05-substrate-check
Open

feat(plan-eng-review): add Step 0.5 — existing-capability check before new substrate code#1587
anoopkansupada wants to merge 1 commit into
garrytan:mainfrom
anoopkansupada:feat/plan-eng-review-step-05-substrate-check

Conversation

@anoopkansupada
Copy link
Copy Markdown

What

Adds a Step 0.5: Existing-capability check to /plan-eng-review, between the Step 0 Scope Challenge and Section 1 (Architecture review).

When a plan proposes new code under ops/<substrate>/ (gbrain, OpenClaw, Hermes, or similar recipe-driven substrates), the reviewer must first run a 60-second check:

ssh <host> 'gbrain integrations list && launchctl list | grep -i gbrain'

Recipe-driven substrates ship a senses + reflexes system that IS the signal-detector / autopilot / ingest pattern. Most "wire X into the flow" plans should be configuring an existing recipe (or writing a markdown recipe modeled on an existing one), NOT building new infrastructure. The new step codifies the three decision branches: configure if AVAILABLE, investigate if CONFIGURED-but-dormant, write a markdown recipe if no recipe exists, build new code only if all three fail.

Why

Real incident, 2026-05-17 on a downstream user's hash-lemma project: /plan-eng-review accepted a plan to extract a JSONL queue lib + producer + consumer bin + LaunchAgent + OAuth-DCR migration to wire "signal-detector on every Slack message" — when gbrain's integrations system (11 senses + 1 reflex) already shipped exactly that pattern, recipe-based. The user's instinct caught it ("this feels like a wrong buildout vs the garry way"), but the eng-review didn't.

Garry's own writings in docs/ethos/thin_harness_fat_skills and docs/ethos/markdown_skills_as_recipes explicitly name this as the anti-pattern: "fat harness with thin skills," "REST API wrappers as tools," "push intelligence UP to skills, execution DOWN to deterministic tooling." The 60-second check operationalizes the rule at the review-skill level.

Net savings (this case): ~3-5 days of misdirected code, replaced with one markdown recipe (slack-to-brain) submitted upstream separately.

Coverage

  • Substrates this affects: gbrain, OpenClaw, Hermes (recipe-driven agent / knowledge-graph runtimes)
  • Substrates this skips: pure web apps, libraries, CLIs — no capability surface to check against

Test plan

  • bun run gen:skill-docs regenerates SKILL.md without errors
  • Diff confirms Step 0.5 inserted between Step 0 and Section 1 in both .tmpl and .md
  • Manual: run /plan-eng-review on a plan touching ops/gbrain — verify Step 0.5 fires and the 60-second check shows in the review output
  • Validation: confirm Substep doesn't fire on a non-substrate plan (e.g. a pure web-app feature)

🤖 Generated with Claude Code

…e new substrate code

When a plan touches a knowledge-graph or agent-runtime substrate (gbrain,
OpenClaw, Hermes), run a 60-second check before designing new infrastructure:

  ssh <host> 'gbrain integrations list && launchctl list | grep -i gbrain'

Most recipe-driven substrates already ship a senses + reflexes system that IS
the signal-detector / autopilot / ingest pattern. Configure or extend existing
recipes (markdown files) instead of building parallel ops/ infrastructure.

Why: 2026-05-17 in hash-lemma, /plan-eng-review accepted a plan to extract a
JSONL queue lib + producer + consumer bin + LaunchAgent + OAuth-DCR migration to
wire "signal-detector on every Slack message" — when gbrain's `integrations`
system already shipped the pattern (11 senses + 1 reflex, recipe-based). The
60-second check would have flagged the wrong-buildout at scope-lock, saving
~3-5 days of misdirected code.

Substrates with no equivalent capability surface (pure web apps, libraries,
CLIs) skip the step.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant