For a human contributor, onboarding is genuinely good: README's Coding Harness section → CODING_HARNESS.md orientation → install-hooks.sh one-liner → harness-tools install table. The main friction is that toolchain verification is manual across ~7 external tools; a /doctor command (check php/composer/npm/sass/uglifyjs/semgrep/ocr/gitleaks/git-cliff presence + versions, report a table) would compress first-day setup and is trivially generated from the README table. 🌍🔧
For a fresh AI session, the design is sound: OpenCode auto-loads AGENTS.md, opencode.json adds conventions.md, and the build prompt carries the enforcement triggers. The residual risks are the anti-rationalization gap (§1.6.2) and post-compaction amnesia — after a compaction, the always-loaded files persist but the momentum of "we're mid-pipeline at step 4" can be lost; Superpowers re-injects its bootstrap on compaction for exactly this reason.
For an open-source audience 🌍, two documentation gaps matter more than anything internal: (1) provenance/attribution — brainstorming, writing-plans, verification-before-completion, and parts of @tdd are recognizably derived from obra/superpowers (MIT, © Jesse Vincent); your repo is AGPL-3.0. MIT→AGPL incorporation is fine provided the MIT notice is preserved for the derived material — add a NOTICE/CREDITS.md naming Superpowers (and anything else you adapted) before promoting. Beyond the legal floor, visible attribution converts "another superpowers clone" criticism into "a serious OpenCode-native adaptation with stack-specific improvements," which is the honest and stronger positioning. (2) A "why OpenCode / why no framework" positioning doc — your differentiators (OpenCode-native permissions model, PHP/no-framework stack, fast-path, validate-harness CI, prototype integration branch) are real but currently discoverable only by reading everything.
For a human contributor, onboarding is genuinely good: README's Coding Harness section →
CODING_HARNESS.mdorientation →install-hooks.shone-liner → harness-tools install table. The main friction is that toolchain verification is manual across ~7 external tools; a/doctorcommand (check php/composer/npm/sass/uglifyjs/semgrep/ocr/gitleaks/git-cliff presence + versions, report a table) would compress first-day setup and is trivially generated from the README table. 🌍🔧For a fresh AI session, the design is sound: OpenCode auto-loads AGENTS.md,
opencode.jsonadds conventions.md, and the build prompt carries the enforcement triggers. The residual risks are the anti-rationalization gap (§1.6.2) and post-compaction amnesia — after a compaction, the always-loaded files persist but the momentum of "we're mid-pipeline at step 4" can be lost; Superpowers re-injects its bootstrap on compaction for exactly this reason.For an open-source audience 🌍, two documentation gaps matter more than anything internal: (1) provenance/attribution —
brainstorming,writing-plans,verification-before-completion, and parts of@tddare recognizably derived from obra/superpowers (MIT, © Jesse Vincent); your repo is AGPL-3.0. MIT→AGPL incorporation is fine provided the MIT notice is preserved for the derived material — add aNOTICE/CREDITS.mdnaming Superpowers (and anything else you adapted) before promoting. Beyond the legal floor, visible attribution converts "another superpowers clone" criticism into "a serious OpenCode-native adaptation with stack-specific improvements," which is the honest and stronger positioning. (2) A "why OpenCode / why no framework" positioning doc — your differentiators (OpenCode-native permissions model, PHP/no-framework stack, fast-path, validate-harness CI, prototype integration branch) are real but currently discoverable only by reading everything.