feat: add Factory Droid plugin support

[Skyline-9]

What problem are you trying to solve?

Factory Droid users cannot install Superpowers through the native plugin system. Droid has a .factory-plugin/ plugin convention (parallel to .claude-plugin/ and .cursor-plugin/) and a native skill discovery mechanism, but Superpowers does not ship the required manifests.

I use Droid daily and wanted Superpowers without the manual copy-and-symlink workarounds that the existing open PRs propose. Those approaches break on upgrade -- you have to re-copy skills after every git pull.

What does this PR change?

Adds .factory-plugin/plugin.json and marketplace.json manifests (mirroring the existing .claude-plugin/ pattern), adds a DROID_PLUGIN_ROOT environment check to hooks/session-start so the hook skips context injection on Droid (which has native skill discovery and shows hook stdout in the UI), registers the new manifests in .version-bump.json, and adds a Factory Droid section to README.md.

Is this change appropriate for the core library?

Yes. This is a new harness, same as the Cursor support added in #467 and the Copilot CLI support. Factory Droid's plugin system is explicitly compatible with Claude Code plugins (per Factory docs). The change follows the exact same pattern as .cursor-plugin/ -- manifest files plus a platform detection guard in the hook.

No skills are copied, duplicated, or modified. The plugin system discovers skills directly from the repo's skills/ directory.

What alternatives did you consider?

1. Copy skills to ~/.factory/skills/ (PR feat: Add Factory Droid CLI support #139 approach) -- Rejected because upgrades break. @obra raised this exact concern: "upgrades are going to be nearly impossible." Users would need to re-copy after every git pull.

2. Symlink skills (also PR feat: Add Factory Droid CLI support #139) -- Droid does not require symlinks when using the plugin system. The plugin system reads skills from the plugin's own directory, so symlinks are unnecessary.

3. Add custom skills/superpowers/SKILL.md (PR Add .factory directory with installation docs and scripts #519 approach) -- Rejected because @obra flagged this as "duplicative of standard content, and maintenance is going to be a nightmare."

4. Do nothing and rely on .claude-plugin/ compatibility -- Droid's docs say Claude Code plugins are interoperable, so this might already work. But adding .factory-plugin/ gives first-class support and is consistent with how .cursor-plugin/ exists alongside .claude-plugin/.

The approach I took mirrors #467 (Cursor support) exactly: add the platform's plugin manifest and a hook detection guard. Minimal diff, no duplication, upgrades work via droid plugin update.

Does this PR contain multiple unrelated changes?

No. All changes serve a single purpose: enabling Factory Droid plugin support.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: feat: Add Factory Droid CLI support #139, feat: add Factory Droid support #370, Add .factory directory with installation docs and scripts #519 (open), feat: add Droid CLI (Factory AI) support #127, Add support for Factory's Droid CLI #129, Add Factory's Droid CLI support #130 (closed)

Why a new PR instead of building on existing ones:

All three open PRs take fundamentally different approaches that the maintainer has already raised concerns about:

• feat: Add Factory Droid CLI support #139 copies skills to ~/.factory/skills/ and requires manual re-copy on update. @obra commented: "my biggest worry about this is upgrades. Because we're copying files rather than linking them... it feels like upgrades are going to be nearly impossible."
• feat: add Factory Droid support #370 proposes a plugin-based approach but @obra asked why it was opened instead of building on feat: Add Factory Droid CLI support #139, and it uses .factory/ instead of .factory-plugin/ for its manifests.
• Add .factory directory with installation docs and scripts #519 is the most comprehensive but adds duplicate skill files, custom install scripts, and a full test suite. @obra commented: "Is there some way to get rid of the custom skills/superpowers skill? It's duplicative of standard content, and maintenance is going to be a nightmare."
• feat: add Droid CLI (Factory AI) support #127, Add support for Factory's Droid CLI #129, Add Factory's Droid CLI support #130 (closed) all copied full skill content into .factory/. @obra commented on Add Factory's Droid CLI support #130: "this looks autogenerated and not human reviewed... not if it means full copies of all the skills."

This PR takes the approach @obra has already accepted for other platforms: the .cursor-plugin/ pattern from #467. Two manifest files, a hook guard, version tracking, and a README section. No skill duplication, no copy scripts, no maintenance burden.

Environment tested

Harness	Harness version	Model	Model version/ID
Factory Droid CLI	0.84.0	Claude Opus 4.6	claude-opus-4-6-20250410

Evaluation

Tested on a Linux server with Droid 0.84.0 installed:

1. droid plugin marketplace add https://github.com/Skyline-9/superpowers -- succeeded
2. droid plugin install superpowers@superpowers -- succeeded, installed at commit 917e5f5
3. droid plugin list -- shows superpowers@superpowers [user]
4. Verified all 15 skills auto-discovered under ~/.factory/plugins/marketplaces/superpowers/skills/ (brainstorming, test-driven-development, systematic-debugging, etc.)
5. Verified hooks/session-start produces empty output with exit code 0 when DROID_PLUGIN_ROOT is set
6. Verified hooks/session-start still produces full JSON context (5903 bytes) when DROID_PLUGIN_ROOT is not set (Claude Code/Cursor/Copilot behavior unchanged)
7. droid plugin uninstall and droid plugin marketplace remove both clean up correctly

Rigor

• If this is a skills change: I used superpowers:writing-skills and completed adversarial pressure testing
• This change was tested adversarially, not just on the happy path
• I did not modify carefully-tuned content (Red Flags table, rationalizations, "human partner" language) without extensive evals

No skill content was modified. The only behavioral change is the 4-line guard in hooks/session-start that exits early when DROID_PLUGIN_ROOT is set. This variable is only set by Factory Droid when running plugin hooks -- Claude Code, Cursor, and Copilot CLI are unaffected.

Human review

• A human has reviewed the COMPLETE proposed diff before submission

[obra]

Thanks for the contribution! I'm going to need to test it out, but at first blush, this looks like the right shape for a harness-adding PR.

[obra]

Hi! I just signed up for Factory to be able to test this and, at least in their CLI, I was 100% able to install the native superpowers claude code plugin in Factory with zero hiccups. It appears to have..just worked?

@Skyline-9 can you tell me more about how it fails when you try to use it?

[Skyline-9]

Hi @obra! I actually just retested on a newer version of droid and it works out of the box. I swear it was not like this in the older CLI, but great to know that it works out of the box, I just updated the PR to mention how to install it out of the box. Thanks for catching that!

Tested it on a brand new RHEL VM with droid and it worked.