feat!: drop GitHub App mode from the skill - #41
Merged
Merged
Conversation
BREAKING for anyone who asked the skill for App mode: it no longer offers it. One install path — the Action. Removed: the mode-choice step, the whole App-mode section, the "do not install both" warning, and the App trigger phrases in the frontmatter description. The install flow starts at Preflight again and the steps renumber 1-8. App mode was always the weaker half. Installing a GitHub App is a permission grant that GitHub requires a human to approve on a web page, so the agent could only ever hand over a link and wait — and on an org repo the person running the skill usually cannot approve it anyway. The Action needs write access and the agent finishes it. The double-review symptom stays in troubleshooting, reworded. The App still exists at github.com/apps/orcacode-review and somebody may install it directly, so a repo can still end up with two reviewers; the entry now says plainly that this skill is not what put it there. Tests swapped rather than deleted: three that assert App mode is gone, that the install flow opens on Preflight with no mode question, and that the step numbers are contiguous 1-8 — removing a step is exactly where an off-by-one would hide, and a skill that skips a number reads as a truncated file. README alt text no longer claims the demo covers App mode. The recording itself still shows it and is not re-cut here. 151 lines out of SKILL.md.
akf66
added a commit
that referenced
this pull request
Aug 26, 2026
…ps itself (#44) Cuts the release that carries #41 (App mode gone from the skill) and #42 (reactions on the default token, judge model from the recipe), and fixes a dependency the package should never have had. THE PACKAGE DEPENDED ON ITSELF. 1.1.0 added `@orcarouter/code-review: ^1.0.2` to its own `dependencies` and five releases carried it. Every `npx` therefore downloaded a second, older copy of the CLI into node_modules before running the one it came for — latency on the first thing a new user does, and RELEASE.md already said the CLI has no dependencies. Nothing failed, which is why it survived: the bin resolves from the top level, so the nested copy is dead weight rather than a wrong entry point. A self-reference is also a registry dependent, and npm reads dependents when deciding whether a version may be withdrawn. Pinned by a test rather than a note — `dependencies`, `peerDependencies` and `optionalDependencies` must all be empty. The invariant was already documented in prose and still broken for five releases. 2.0.0, not 1.5.1. 1.5.0 shipped the App-mode removal as a minor, and the 1.x line is being unpublished inside npm's 72-hour window, so 2.0.0 is the first version on the registry that a user can actually install — the major is where the break belongs, and a lone `1.5.1` would imply a history the packument no longer has. RELEASE.md records what went with the withdrawn versions, because a packument with one version reads as a truncated upload. It also says plainly that unpublishing was defensible only for a two-day-old line with no known consumers, and that deprecation is the default everywhere else. Three versions move together (gate 1): package.json, plugin.json, marketplace.json.
akf66
added a commit
that referenced
this pull request
Aug 26, 2026
* release: 2.0.0 — the Action is the only install path, and the CLI drops itself Cuts the release that carries #41 (App mode gone from the skill) and #42 (reactions on the default token, judge model from the recipe), and fixes a dependency the package should never have had. THE PACKAGE DEPENDED ON ITSELF. 1.1.0 added `@orcarouter/code-review: ^1.0.2` to its own `dependencies` and five releases carried it. Every `npx` therefore downloaded a second, older copy of the CLI into node_modules before running the one it came for — latency on the first thing a new user does, and RELEASE.md already said the CLI has no dependencies. Nothing failed, which is why it survived: the bin resolves from the top level, so the nested copy is dead weight rather than a wrong entry point. A self-reference is also a registry dependent, and npm reads dependents when deciding whether a version may be withdrawn. Pinned by a test rather than a note — `dependencies`, `peerDependencies` and `optionalDependencies` must all be empty. The invariant was already documented in prose and still broken for five releases. 2.0.0, not 1.5.1. 1.5.0 shipped the App-mode removal as a minor, and the 1.x line is being unpublished inside npm's 72-hour window, so 2.0.0 is the first version on the registry that a user can actually install — the major is where the break belongs, and a lone `1.5.1` would imply a history the packument no longer has. RELEASE.md records what went with the withdrawn versions, because a packument with one version reads as a truncated upload. It also says plainly that unpublishing was defensible only for a two-day-old line with no known consumers, and that deprecation is the default everywhere else. Three versions move together (gate 1): package.json, plugin.json, marketplace.json. * ci: a manual, guarded way to withdraw a version from npm Publishing 2.0.0 was the easy half. Withdrawing 1.0.2-1.5.0 needs a credential that can unpublish, and the only one this project has is the NPM_TOKEN repository secret — nobody's laptop holds it, and npm's window is 72 hours from publish, so "log in later" is not a plan. This runs the withdrawal where the token already lives and leaves a run log of who removed what. Guards, because the failure mode is deleting the live release rather than the dead ones: * `confirm` must be typed as the word "unpublish". A dispatch button is one click; this job's blast radius is the whole package. * The version in package.json is refused outright. It is what dist-tags.latest points at and what every npx resolves. * Verification reads the ANONYMOUS packument afterwards and fails if the live version is missing or if `latest` moved. `npm unpublish` exiting 0 is not evidence, for the same reason gate 6 exists in publish.yml. A version that cannot be withdrawn warns and the loop continues, then the job fails at the end. Aborting mid-list would leave the line half-withdrawn, which is the one state worse than either end. Inputs reach the shell through `env`, never interpolated into a run block. This job holds a publish token, and `${{ inputs.versions }}` inside a script is a command-injection hole. Shares the publish-npm concurrency group so it can never race a publish.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One install path now — the Action. BREAKING for anyone who asked the skill for App mode.
Gone
### 0. Pick the modestep## Install — GitHub App modesection## Do not install bothwarningdescriptionInstall opens on Preflight again, steps renumbered 1–8. 151 lines out of SKILL.md.
Why it was the weaker half
Installing a GitHub App is a permission grant, and GitHub requires a human to approve it on a web page. The agent could only ever hand over a link and wait. On an org repo the person running the skill usually can't approve it at all — which we proved on this very account:
admin: false,role: member.The Action needs write access, and the agent finishes it end to end.
What stays
The double-review symptom, reworded. The App still exists at
github.com/apps/orcacode-reviewand someone may install it directly, so a repo can still end up with two reviewers. The entry now says plainly that this skill isn't what put it there.Tests swapped, not deleted
The four App-mode assertions described a path that no longer exists. Three replace them:
GitHub App mode, noinstallations/newURL410 passing.
One thing I did not do
The demo recording still contains the App-mode segment. I changed the README alt text so it no longer claims otherwise, but didn't re-cut the video — say the word and I'll rebuild it as install + Action only, which also brings it under a minute.
1.5.0 — merging publishes it.