feat(junie): add support for Junie harness

[mpbalmeida]

What problem are you trying to solve?

Added support for Junie, JetBrains' AI coding agent. Junie users currently have no easy way to install Superpowers, as Junie lacks a plugin marketplace and uses a different skill loading mechanism than Claude Code.

What does this PR change?

Adds Junie support via installation/uninstallation scripts, dedicated documentation, and a bootstrap mechanism that auto-triggers skills in Junie sessions.

Is this change appropriate for the core library?

Yes, it adds support for a new harness, which is explicitly permitted in the contributor guidelines.

What alternatives did you consider?

Considered using AGENTS.md for guidelines, but settled on guidelines.md as it is the Junie standard. Evaluated using flat superpowers- prefixes for skill folders, but chose a superpowers/ subfolder for better organization and consistency with other harnesses.

Does this PR contain multiple unrelated changes?

No, all changes are related to adding Junie support.

Existing PRs

• I have reviewed all open AND closed PRs for duplicates or prior art
• Related PRs: none found

Environment tested

Harness	Harness version	Model	Model version/ID
Junie	v.build 1543.13	Gemini	gemini-2.0-flash

New harness support (required if this PR adds a new harness)

Clean-session transcript for "Let's make a react todo list"

~/dev/test

/ available commands
@ search for a file or a folder
! bash command
? show help

IDE Integration 🥋
Extend Junie with IDE integration — run /ide to install the plugin
With IDE integration, Junie can run tests, use your run configurations and IDE settings to gather richer context and provide more accurate results.

> Let's make a react todo list

● Read skill documentation: superpowers:using-superpowers

● Read skill documentation: superpowers:brainstorming

● Bash: node -v && npm -v && npx -v
  │ v22.22.0
  │ 11.3.0
  │ 11.3.0

  Node.js, npm, and npx are installed with versions 22.22.0, 11.3.0, and 11.3.0 respectively.

● Read skill documentation: superpowers:writing-plans

● I am starting the brainstorming process to design the React todo list application. I have explored the project context and found it to be empty. Now I am offering the visual companion for the brainstorming
  phase.

  Your answers

  Some of what we're working on might be easier to explain if I can show it to you in a web browser. I can put together mockups, diagrams, comparisons, and other visuals as we go. This feature is still new and
  can be token-intensive. Want to try it? (Requires opening a local URL)
  No (Continue with text-only brainstorming.)

● The user declined the visual companion. I am now proceeding with clarifying questions to define the scope and requirements of the React todo list.

  Your answers

  What are the core features you want in this todo list? (e.g., just add/toggle/delete, or do you also need filters, persistence, or multiple lists?)
  add  toggle delete

● The user specified the core features: add, toggle, and delete. I am now asking about styling preferences.

  Your answers

  Do you have a preference for how the application should be styled?
  Plain CSS (Standard CSS files.)

● The user prefers Plain CSS for styling. I'll ask one final clarification about data persistence.

  Your answers

  Should the todo list persist after refreshing the page?
  In-memory only (Todos are lost on refresh.)

● I have gathered all requirements: a React app with add/toggle/delete features, styled with Plain CSS, and using in-memory state. Now I am proposing different architectural approaches.

  Your answers

  Which architectural approach should we use?
  Modular Components (Separate components for form, list, and items. (Recommended for clean code))

● The user chose the Modular Components approach. I am now presenting the design for approval.
                                                                                                                                                                                                                        Here is the proposed component structure:                                                                                                                                                                                                                                                                                                                                                                                                   - **App**: Root component, manages the `todos` state and logic.                                                                                                                                                       - **TodoForm**: Handles user input for new tasks.                                                                                                                                                                     - **TodoList**: A wrapper for the list of items.                                                                                                                                                                      - **TodoItem**: Represents a single task with toggle and delete actions.                                                                                                                                                                                                                                                                                                                                                                    Does this structure meet your expectations?                                                                                                                                                                           >

Evaluation

• What was the initial prompt you (or your human partner) used to start the session that led to this change?
  "Let's make a react todo list"
• How many eval sessions did you run AFTER making the change?
  5+ sessions
• How did outcomes change compared to before the change?
  The brainstorming skill now auto-triggers correctly in Junie, whereas before it would require manual intervention or fail to load.

Rigor

• This change was tested adversarially, not just on the happy path
• I did not modify carefully-tuned content without extensive evals showing the change is an improvement

Human review

• A human has reviewed the COMPLETE proposed diff before submission

[obra]

Hi! Thanks for contributing this. Does Junie not have a plugin install system? I'd love to not need those shell scripts. Also, how does it load the Superpowers bootstrap at startup? It looks like we're depending on the model to choose to load using-superpowers?

[mpbalmeida]

Hi! Thanks for contributing this. Does Junie not have a plugin install system? I'd love to not need those shell scripts. Also, how does it load the Superpowers bootstrap at startup? It looks like we're depending on the model to choose to load using-superpowers?

Junie currently doesn't have any plugin, and this was the only way that I was able to install the skills reliable.

Regarding how it's loaded it's indeed through the AGENTS.md file in the junie user folder. I'm now adding commands to trigger the skiils, at least this will enforce the use of the skill

[rijnhard]

FYI: the agent skills documentation is at https://junie.jetbrains.com/docs/agent-skills.html
and the closest that they have to a design (albeit project level is https://github.com/JetBrains/junie-extensions)

So yeah, right now there isn't a simple dedicated way to install extensions.

[mpbalmeida]

@obra @rijnhard any suggestions on how to move forward?