docs(pi): add experimental pi support (Phase 1)#500
docs(pi): add experimental pi support (Phase 1)#500
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds experimental Pi support documentation: new Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan for PR comments
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
sheurich
force-pushed
the
feature/pi-support
branch
from
11a6b67 to
d025851
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.pi/INSTALL.md (1)
3-6: Prerequisites omit the Pi installation command itself.Since this file doubles as human-readable documentation, consider adding the npm install step so new users have a fully self-contained guide.
npm install -g@mariozechner/pi-coding-agent`` is the command that installs Pi.📝 Suggested addition
## Prerequisites +- [Node.js](https://nodejs.org/) (for `npm install -g `@mariozechner/pi-coding-agent``) - [Pi](https://github.com/mariozechner/pi-coding-agent) installed - Git🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.pi/INSTALL.md around lines 3 - 6, Add the missing npm install step to the Prerequisites section of .pi/INSTALL.md so the guide is self-contained: under the "Prerequisites" heading insert the global install command for Pi (npm install -g `@mariozechner/pi-coding-agent`) and ensure it appears above or alongside the existing Git bullet so new users can copy/paste the full installation step.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.pi/INSTALL.md:
- Around line 36-38: Replace the ambiguous example `pi update` in the HTTPS
install path with a source-specific command to avoid updating all installed
packages: change the code block that currently shows `pi update` to `pi update
https://github.com/obra/superpowers` so the example updates only that repository
rather than all globally installed Pi packages.
---
Nitpick comments:
In @.pi/INSTALL.md:
- Around line 3-6: Add the missing npm install step to the Prerequisites section
of .pi/INSTALL.md so the guide is self-contained: under the "Prerequisites"
heading insert the global install command for Pi (npm install -g
`@mariozechner/pi-coding-agent`) and ensure it appears above or alongside the
existing Git bullet so new users can copy/paste the full installation step.
d025851 to
6b0dc4d
Compare
|
Does pi have a way to autoload the using-superpowers bootstrap at startup? |
|
Pi doesn't have a hooks system like Claude Code's A small This is a code change, not documentation. I'll track it as Phase 2 work. The docs already note the limitation under "Known Differences from Claude Code":
|
|
Re: CodeRabbit's nitpick about adding Declining. This INSTALL.md is reached after the user already has Pi (they found it via |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.pi/INSTALL.md:
- Around line 48-52: The Uninstalling section only shows the HTTPS removal
command and lacks the local-clone variant referenced earlier under "Alternative:
Local Clone"; update the "Uninstalling" section (heading "Uninstalling" and the
existing example `pi remove https://github.com/obra/superpowers`) to include an
additional example for removing an install performed from a local path, e.g. add
a short sentence "Or, if installed from a local path:" followed by the command
`pi remove /path/to/superpowers` so users who followed the local-clone
instructions can remove that installation.
---
Duplicate comments:
In @.pi/INSTALL.md:
- Around line 38-40: The example now shows using "pi update
https://github.com/obra/superpowers" which fixes the earlier problem of
unintentionally updating all packages; update the documentation to ensure the
"pi update" examples explicitly show both behaviors — (1) "pi update" updates
all installed packages and (2) "pi update <source-url>" updates a single package
— by keeping the explicit URL example "pi update
https://github.com/obra/superpowers" and adding a short note clarifying the
difference in behavior for the plain "pi update" command.
|
Sorry about the coderabbit nitpicks. It hasn't generally been very helpful for us. I've finally gotten it turned off. Is there a way to get 'extensions/bootrstrap.ts' inside a .pi directory? As we support more harnesses, we are trying to have us do our best to keep harness-specific stuff in a named directory for this harness. |
You can also configure it to not raise nitpicks... @coderabbitai can you output the current/default coderabbit.yml please and tailor it to not generate so much noise over nitpicks to suit the repo maintainers preferences above |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain
🛠 Debug Information Gathered
Current Configuration SummaryYour repository is using mostly default settings with the Recommended ConfigurationCreate or update language: en-US
reviews:
# Keep chill profile - less nitpicky feedback
profile: chill
# Disable non-essential walkthrough features to reduce noise
high_level_summary: false
poem: false
in_progress_fortune: false
review_status: false
suggested_labels: false
suggested_reviewers: false
sequence_diagrams: false
related_issues: false
related_prs: false
# Keep essential features
collapse_walkthrough: true
changed_files_summary: true
# Disable automatic reviews - require explicit trigger
auto_review:
enabled: false
# Only review when PR description contains this keyword
description_keyword: '@coderabbitai review'
# Selectively disable linting tools that tend to be noisy
tools:
# Keep critical security scanners
gitleaks:
enabled: true
trufflehog:
enabled: true
# Disable style/formatting tools if you have your own CI for these
markdownlint:
enabled: false
languagetool:
enabled: false
biome:
enabled: false
ruff:
enabled: false
eslint:
enabled: false
shellcheck:
enabled: false
# Disable other potentially noisy tools
github-checks:
enabled: false
# Optional: Exclude specific paths from review
path_filters:
- '!**/node_modules/**'
- '!**/dist/**'
- '!**/build/**'
- '!**/*.lock'
- '!**/*.min.js'
chat:
# Disable auto-reply to reduce unsolicited responses
auto_reply: false
art: falseKey Changes to Reduce Noise
Alternative: Even More MinimalIf you want CodeRabbit only for chat/on-demand help: reviews:
auto_review:
enabled: falseThis disables automatic reviews entirely while keeping chat available when you explicitly tag Would you like me to adjust any of these settings further? |
@coderabbitai can you also answer this |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🌐 Web query: 💡 Result: Pi Coding Agent ( Discovery paths (automatic)
Configuring where “global” lives (agent dir)
If you’re using recent versions:
|
|
e
@coderabbitai can you challenge all of that? are you certain? think deeply. can you reflect deeply over this repository, and recent issues/PRs where coderabbit was triggered, and strategize the optimal coderabbit.yml configuration to suit this project specifically (@obra this was a brief demonstration that coderabbit can in fact be very helpful, to everyone!) |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain
🏁 Script executed: Length of output: 274934 🛠 Debug Information Gathered
Below is a repo‑specific configuration that turns off the noisy bits, keeps guardrails (secret scanning), and makes reviews explicitly on-demand. I also added path-scoped guidance so reviews focus on what matters in this project. Proposed .coderabbit.yml language: en-US
reviews:
profile: chill
# Keep concise, useful context; drop the fluff
high_level_summary: false
in_progress_fortune: false
poem: false
review_status: false
suggested_labels: false
suggested_reviewers: false
related_issues: false
related_prs: false
sequence_diagrams: false
estimate_code_review_effort: false
assess_linked_issues: false
collapse_walkthrough: true
changed_files_summary: true
# On-demand reviews only (quiet by default)
auto_review:
enabled: false
description_keyword: '@coderabbitai review' # manual trigger
labels: ['ai:review'] # or add a label to trigger
auto_incremental_review: false
auto_pause_after_reviewed_commits: 0
drafts: false
base_branches: ['main', 'dev'] # adjust if you use another long-lived branch
# Turn off pre-merge gatekeeping for a docs/shell repo
pre_merge_checks:
docstrings:
mode: off
title:
mode: off
description:
mode: off
issue_assessment:
mode: off
custom_checks: []
# Disable noisy style linters; keep security scanners
tools:
gitleaks:
enabled: true
trufflehog:
enabled: true
# Disable generic style/grammar linters and language linters you don't use
markdownlint:
enabled: false
languagetool:
enabled: false
eslint:
enabled: false
ruff:
enabled: false
pylint:
enabled: false
yamllint:
enabled: false
actionlint:
enabled: false
github-checks:
enabled: false
# ShellCheck: enable when you want it (see note below)
shellcheck:
enabled: false
# Repo-aware guidance that adds signal when you do request a review
path_instructions:
- path: 'skills/**/SKILL.md'
instructions: |
Focus on content quality, not grammar/style. Check:
- Frontmatter completeness (title/description/triggers).
- Consistency with writing-skills guidance (e.g., avoid “what it does” contradictions).
- Trigger overlap with existing skills; highlight duplicates or ambiguous triggers.
- Clear, actionable steps; progressive disclosure; links to related skills.
- path: 'hooks/**'
instructions: |
Focus on cross-platform robustness:
- Windows compatibility (run-hook.cmd, git-bash discovery, cygpath usage) vs POSIX shells.
- LF normalization (.gitattributes) and safe path resolution (no brittle dirname assumptions).
- Quoting, set -euo pipefail, and predictable exit codes for hook runners.
- path: '.**/INSTALL.md'
instructions: |
Harness-specific docs should:
- Live under the matching dot-dir (e.g., .pi/, .qwen/, .factory/, .trae/).
- Avoid duplicating skill content; prefer symlink/auto-discovery guidance.
- Provide update/uninstall parity for each install path (https/clone/local).
- path: 'docs/**'
instructions: |
Prioritize contradictions, broken flows, or missing parity across harnesses over style. Flag only high-signal issues.
# Keep reviews from traversing heavy generated/vendor paths
path_filters:
- '!**/node_modules/**'
- '!**/dist/**'
- '!**/build/**'
- '!**/*.lock'
- '!**/*.min.*'
- '!**/.DS_Store'
chat:
auto_reply: false # respond only when explicitly `@mentioned`
art: falseNotes and options
Would you like me to open a small PR that adds this .coderabbit.yml to the repo, or tweak any of the toggles (e.g., keep sequence diagrams, enable ShellCheck by default for hooks)? |
|
|
Tip For best results, initiate chat on the files or code changes.
|
|
what happens with the subagents mentioned in the skills? When I did my personal port of superpowers for |
|
@obra @rentorm Addressed both points in 5ef132d.
|
|
Thanks for the added agent, however there are more agents needed for true superpowers to be unlocked. For example subagent-driven development workflow etc. Here is the list I had to create: Agents Directly Used in Superpowers Skills
And these ones generally are good to have to unlock good agentic workflow Infrastructure Agents (not referenced in skills)
None of this comes out of the box for |
Thanks — this is good feedback, and I agree that additional Pi agent profiles improve the full subagent-driven For this PR, I kept scope to Phase 1 of #435 (docs + smoke tests) and added code-reviewer because that is the The other roles you listed (implementer, spec-reviewer, code-quality-reviewer) are currently modeled as role-specific I’ll track this for Phase 2 in #435 (workflow mapping/integration), and I can add a follow-up issue/PR for a |
|
I’m really looking forward to this feature! Is there any update on the plan for this PR? Happy to help test it out if that would be useful for the maintainers. Thanks for all your work on this project! |
|
@obra Rebased onto current main and resolved the README.md conflict. Current status:
I also made one small docs consistency fix while rebasing:
This PR remains Phase 1 of #435 only:
Still intentionally deferred to Phase 2:
|
sheurich
force-pushed
the
feature/pi-support
branch
from
8b58b05 to
2b5ba7b
Compare
Add documentation for using superpowers with pi coding agent: - .pi/INSTALL.md: machine-readable install instructions - docs/README.pi.md: full guide with tool mapping, architecture, troubleshooting, and known differences from Claude Code - README.md: add pi section alongside Codex/OpenCode Pi discovers skills from the skills/ directory via its native package system. No plugins, hooks, bootstrap scripts, or CLI wrappers needed. Refs: obra#435
Bare `pi update` updates all installed packages. Specify the source URL so the example only updates superpowers.
The doc covers two install paths (HTTPS and local clone) but only showed the HTTPS removal command.
sheurich
force-pushed
the
feature/pi-support
branch
from
2b5ba7b to
f2583a5
Compare
|
Rebased this PR onto current Current status:
Included here:
Still intentionally deferred to Phase 2:
If the Phase 1 docs/tests/agent-profile scope looks right, this should be ready for review. |
| name: code-reviewer | ||
| description: | | ||
| Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Examples: <example>Context: The user is creating a code-review agent that should be called after a logical chunk of code is written. user: "I've finished implementing the user authentication system as outlined in step 3 of our plan" assistant: "Great work! Now let me use the code-reviewer agent to review the implementation against our plan and coding standards" <commentary>Since a major project step has been completed, use the code-reviewer agent to validate the work against the plan and identify any issues.</commentary></example> <example>Context: User has completed a significant feature implementation. user: "The API endpoints for the task management system are now complete - that covers step 2 from our architecture document" assistant: "Excellent! Let me have the code-reviewer agent examine this implementation to ensure it aligns with our plan and follows best practices" <commentary>A numbered step from the planning document has been completed, so the code-reviewer agent should review the work.</commentary></example> | ||
| model: inherit |
There was a problem hiding this comment.
I tested the bundled Pi code-reviewer profile locally and there’s a problem with this line:
model: inheritIn practice, this does not inherit the currently active Pi model. When the code-reviewer subagent is invoked from a live Pi session, it runs under a different/fallback configured
model instead of the model currently selected in the parent session.
If it can help, I'm attaching the export of the session when I reproduced the issue
6 participants
Summary
Add experimental support for pi (
@mariozechner/pi-coding-agent) as Phase 1 of #435.Pi already discovers package
skills/directories automatically, so baseline support is lightweight. This PR adds Pi installation docs, a bundled Pi agent profile for current subagent workflows, and smoke tests for isolated install plus skill discovery.Changes
Documentation
.pi/INSTALL.md— machine-readable install/update/remove instructions, matching the.codex/INSTALL.mdand.opencode/INSTALL.mdpatterndocs/README.pi.md— full Pi guide covering installation options, requiredcode-reviewerprofile setup, tool mapping, architecture notes, troubleshooting, and known differencesREADME.md— add Pi to the top-level installation matrix.pi/agents/README.md— Pi agent-profile installation docs.pi/agents/code-reviewer.md— bundledcode-reviewerprofile forrequesting-code-reviewand workflows that depend on itSmoke tests (Phase 1 requirement)
tests/pi/test-smoke.shPI_CODING_AGENT_DIRbrainstormingskill discoverability through Pi package resolutionpi listincludes the installed package~/.pi/agent/settings.jsonis unchangedtests/pi/run-tests.sh— runner wrapper consistent with othertests/*/run-tests.shsuitestests/pi/README.md— run instructions and requirementsWhy no repo-local integration code?
Unlike Codex and OpenCode, Pi does not need repo-local bootstrap or plugin glue for basic skill loading:
skills/by convention..opencode/plugins/*equivalent is required for baseline compatibility.Smoke test scope
This smoke test validates deterministic package install and skill discoverability, and it runs locally without model credentials.
It does not validate interactive runtime UI behavior such as
/skill:brainstormingappearing in-session.Tool mapping
Skilltoolread//skill:nameSKILL.mdviareadTodoWriteTask(subagents)subagentRead,Write,Edit,BashPhase tracking