mirror of
https://github.com/luckyyzh/pi-agent-integrated.git
synced 2026-10-03 02:59:35 +00:00
feat: integrate Pi backend and Pi Web
This commit is contained in:
luckyyzh
@@ -0,0 +1,54 @@
|
||||
---
|
||||
description: Audit changelog entries before release
|
||||
---
|
||||
Audit changelog entries for all commits since the last release.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Find the last release tag:**
|
||||
```bash
|
||||
git tag --sort=-version:refname | head -1
|
||||
```
|
||||
|
||||
2. **List all commits since that tag:**
|
||||
```bash
|
||||
git log <tag>..HEAD --oneline
|
||||
```
|
||||
|
||||
3. **Read each package's [Unreleased] section:**
|
||||
- packages/ai/CHANGELOG.md
|
||||
- packages/tui/CHANGELOG.md
|
||||
- packages/coding-agent/CHANGELOG.md
|
||||
|
||||
4. **For each commit, check:**
|
||||
- Skip: changelog updates, doc-only changes, release housekeeping
|
||||
- Skip: changes to generated model catalogs (for example `packages/ai/src/models.generated.ts`) unless accompanied by an intentional product-facing change in non-generated source/docs.
|
||||
- Determine which package(s) the commit affects (use `git show <hash> --stat`)
|
||||
- Verify a changelog entry exists in the affected package(s)
|
||||
- For external contributions (PRs), verify format: `Description ([#N](url) by [@user](url))`
|
||||
|
||||
5. **Cross-package duplication rule:**
|
||||
Changes in `ai`, `agent` or `tui` that affect end users should be duplicated to `coding-agent` changelog, since coding-agent is the user-facing package that depends on them.
|
||||
|
||||
6. **Add New Features section after changelog fixes:**
|
||||
- Insert a `### New Features` section at the start of `## [Unreleased]` in `packages/coding-agent/CHANGELOG.md`.
|
||||
- Propose the top new features to the user for confirmation before writing them.
|
||||
- Link to relevant docs and sections whenever possible.
|
||||
|
||||
7. **Report:**
|
||||
- List commits with missing entries
|
||||
- List entries that need cross-package duplication
|
||||
- Add any missing entries directly
|
||||
|
||||
## Changelog Format Reference
|
||||
|
||||
Sections (in order):
|
||||
- `### Breaking Changes` - API changes requiring migration
|
||||
- `### Added` - New features
|
||||
- `### Changed` - Changes to existing functionality
|
||||
- `### Fixed` - Bug fixes
|
||||
- `### Removed` - Removed features
|
||||
|
||||
Attribution:
|
||||
- Internal: `Fixed foo ([#123](https://github.com/earendil-works/pi-mono/issues/123))`
|
||||
- External: `Added bar ([#456](https://github.com/earendil-works/pi-mono/pull/456) by [@user](https://github.com/user))`
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
description: Analyze GitHub issues (bugs or feature requests)
|
||||
argument-hint: "<issue>"
|
||||
---
|
||||
Analyze GitHub issue(s): $ARGUMENTS
|
||||
|
||||
For each issue:
|
||||
|
||||
1. If running under CI (`CI=true`), do not add the `inprogress` label and do not assign the issue. Otherwise, add the `inprogress` label to the issue via GitHub CLI and assign the issue to the local `gh` user before analysis starts. If either action fails, report that explicitly and continue.
|
||||
2. Read the issue in full, including all comments and linked issues/PRs. Use fields supported by GitHub CLI, for example:
|
||||
```sh
|
||||
gh issue view <issue> --json title,body,comments,labels,assignees,state,url,author,createdAt,updatedAt,closedByPullRequestsReferences
|
||||
```
|
||||
3. Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
|
||||
|
||||
4. **For bugs**:
|
||||
- Ignore any root cause analysis in the issue (likely wrong)
|
||||
- Read all related code files in full (no truncation)
|
||||
- Trace the code path and identify the actual root cause
|
||||
- Propose a fix
|
||||
|
||||
5. **For feature requests**:
|
||||
- Do not trust implementation proposals in the issue without verification
|
||||
- Read all related code files in full (no truncation)
|
||||
- Propose the most concise implementation approach
|
||||
- List affected files and changes needed
|
||||
|
||||
Do NOT implement unless explicitly asked. Analyze and propose only.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
description: Review PRs from URLs with structured issue and code analysis
|
||||
argument-hint: "<PR-URL>"
|
||||
---
|
||||
You are given one or more GitHub PR URLs: $@
|
||||
|
||||
For each PR URL, do the following in order:
|
||||
1. Add the `inprogress` label to the PR via GitHub CLI before analysis starts. If adding the label fails, report that explicitly and continue.
|
||||
2. Read the PR page in full. Include description, all comments, all commits, and all changed files.
|
||||
3. Identify any linked issues referenced in the PR body, comments, commit messages, or cross links. Read each issue in full, including all comments.
|
||||
4. Analyze the PR diff without checking out or switching to the PR branch. Use `gh pr diff`, `gh pr view`, `gh api`, and local main-branch files; if PR file contents are needed, use fetched refs with `git show <ref>:<path>` or temporary files. Read all relevant code files in full with no truncation and compare against the diff. Do not fetch PR file blobs unless a file is missing on main or the diff context is insufficient. Include related code paths that are not in the diff but are required to validate behavior.
|
||||
5. Do not check for a changelog entry. Per CONTRIBUTING.md, contributor PRs must not edit `CHANGELOG.md` — the maintainer adds the entry when merging.
|
||||
6. Check if packages/coding-agent/README.md, packages/coding-agent/docs/*.md, packages/coding-agent/examples/**/*.md require modification. This is usually the case when existing features have been changed, or new features have been added.
|
||||
7. Provide a structured review with these sections:
|
||||
- What it does: one short paragraph describing the change and its intent.
|
||||
- Good: solid choices or improvements.
|
||||
- Bad: concrete issues, regressions, missing tests, or risks.
|
||||
- Ugly: subtle or high impact problems.
|
||||
- Tests: what is covered, what is missing, and whether existing tests are adequate.
|
||||
- Open questions for you: only things blocking a merge decision that need the user's input. Omit the section entirely if there are none.
|
||||
|
||||
Output format per PR:
|
||||
PR: <url>
|
||||
What it does:
|
||||
- ...
|
||||
Good:
|
||||
- ...
|
||||
Bad:
|
||||
- ...
|
||||
Ugly:
|
||||
- ...
|
||||
Tests:
|
||||
- ...
|
||||
Open questions for you:
|
||||
- ...
|
||||
|
||||
If no issues are found, say so under Bad and Ugly.
|
||||
@@ -0,0 +1,163 @@
|
||||
---
|
||||
description: Update a GitHub security advisory for publication
|
||||
argument-hint: "<advisory-url-or-draft-path>"
|
||||
---
|
||||
Update a GitHub security advisory for publication: $ARGUMENTS
|
||||
|
||||
Use `gh` for all GitHub operations. Do not publish the advisory, change its state, or request a CVE unless the user explicitly agrees or the draft markdown explicitly says `request_cve: true`.
|
||||
|
||||
GitHub does not expose repository security advisory comments/discussion through the documented REST OpenAPI schema or public GraphQL schema. A 404 from guessed API endpoints such as `api.github.com/repos/.../security-advisories/<GHSA>/comments`, `.../timeline`, or `.../events` is expected and is not, by itself, an auth failure. Do not use a browser session, browser cookies, or cookie extraction to fetch advisory comments. Instead, clearly tell the user that advisory comments were not included and that they can paste any relevant comments if they want them considered.
|
||||
|
||||
## Input handling
|
||||
|
||||
- If `$ARGUMENTS` is a GitHub security advisory URL, start the investigation and drafting workflow.
|
||||
- If `$ARGUMENTS` is a path to an existing markdown draft, read it and apply that draft to the advisory.
|
||||
- In a follow-up message after this prompt, if the user says "update", "apply", "looks good", or similar, treat it as approval to apply the previously written temp markdown draft. Re-read the file from disk before updating GitHub.
|
||||
- If applying a draft and there is no known draft path, ask the user for the markdown file path.
|
||||
|
||||
## Initial advisory workflow
|
||||
|
||||
1. Parse the advisory URL into `owner`, `repo`, and `GHSA` id.
|
||||
2. Fetch the advisory with:
|
||||
```sh
|
||||
gh api repos/<owner>/<repo>/security-advisories/<GHSA>
|
||||
```
|
||||
Record the advisory's original severity, CVSS vector, and CVSS score exactly as returned before proposing changes.
|
||||
3. Do not fetch advisory comments/discussion unless the user pasted them into the conversation:
|
||||
- Inspect the advisory JSON for references, credits, linked issues/PRs, and any discussion fields.
|
||||
- Do not rely on invented API endpoints such as `/comments`, `/timeline`, or `/events`; they commonly return 404 because GitHub does not expose draft advisory comments through the public API.
|
||||
- Do not use a browser session, browser cookies, or cookie extraction to fetch comments.
|
||||
- Explicitly tell the user: `Advisory comments were not included because GitHub does not expose them through the public API. Paste any relevant comments if you want them considered.`
|
||||
- If the user pasted comments, read and consider them.
|
||||
- Never pretend comments were read.
|
||||
4. Investigate independently:
|
||||
- Read the advisory text, metadata, affected package(s), version ranges, CVSS, CWE, references, and linked issues/PRs/commits.
|
||||
- Inspect relevant code history, releases, changelogs, package metadata, and tags.
|
||||
- Determine whether the vulnerability is already fixed.
|
||||
- If fixed, identify the patched version(s) and the correct affected version range.
|
||||
- Do not trust the reporter's analysis without verification.
|
||||
5. Discuss CVSS with the user before drafting the final update:
|
||||
- Propose a CVSS vector, score, and severity.
|
||||
- Explain the controversial metrics briefly.
|
||||
- Ask the user to confirm or adjust it.
|
||||
6. Ask whether a CVE should be requested from GitHub for this advisory.
|
||||
7. Draft a publication-ready advisory markdown file under `/tmp`, for example `/tmp/sa-<GHSA>.md`. Include both the original CVSS from the advisory and the proposed/confirmed updated CVSS.
|
||||
8. Tell the user:
|
||||
- the path to the temp markdown file
|
||||
- the original advisory URL
|
||||
- that they can edit the file and then say "update" or provide the path
|
||||
|
||||
## Draft markdown format
|
||||
|
||||
The draft file must contain YAML frontmatter followed by the advisory body. Include all fields needed to update GitHub and to decide whether to request a CVE.
|
||||
|
||||
```markdown
|
||||
---
|
||||
advisory_url: https://github.com/<owner>/<repo>/security/advisories/<GHSA>
|
||||
owner: <owner>
|
||||
repo: <repo>
|
||||
ghsa_id: <GHSA>
|
||||
summary: <short advisory summary>
|
||||
original_severity: <low|medium|high|critical|null>
|
||||
original_cvss_vector: <original CVSS:3.1/... or null>
|
||||
original_cvss_score: <original number or null>
|
||||
severity: <proposed/confirmed low|medium|high|critical>
|
||||
cvss_vector: <proposed/confirmed CVSS:3.1/...>
|
||||
cvss_score: <proposed/confirmed number>
|
||||
cwe_ids:
|
||||
- CWE-...
|
||||
vulnerabilities:
|
||||
- package:
|
||||
ecosystem: npm
|
||||
name: <package-name>
|
||||
vulnerable_version_range: <range>
|
||||
patched_versions: <range-or-version>
|
||||
request_cve: false
|
||||
---
|
||||
|
||||
# <Advisory title>
|
||||
|
||||
<Concise description of the vulnerability and vulnerable behavior.>
|
||||
|
||||
## Info
|
||||
|
||||
<Technical explanation of the root cause and affected component. Focus on facts needed by defenders and maintainers. Do not include PoC steps, exploit payloads, or copy-pastable exploit strings.>
|
||||
|
||||
## Impact
|
||||
|
||||
<Who can exploit it, prerequisites, confidentiality/integrity/availability impact, and realistic deployment assumptions.>
|
||||
|
||||
## Affected versions
|
||||
|
||||
- Affected: `<range>`
|
||||
- Patched: `<version or range>`
|
||||
|
||||
## The solution
|
||||
|
||||
<Describe the fix and the patched release.>
|
||||
|
||||
## Recommendations
|
||||
|
||||
<Upgrade guidance and operational mitigations.>
|
||||
|
||||
## Workarounds
|
||||
|
||||
<Workarounds if any; otherwise skip this section entirely>
|
||||
|
||||
## Timeline
|
||||
|
||||
- YYYY-MM-DD: Report received
|
||||
- YYYY-MM-DD: Fix committed
|
||||
- YYYY-MM-DD: Fixed version released
|
||||
- YYYY-MM-DD: Advisory published
|
||||
|
||||
## Credits
|
||||
|
||||
<Reporter/researcher attribution if appropriate, otherwise skip section.>
|
||||
|
||||
## References
|
||||
|
||||
- <links to releases, commits, advisories, documentation>
|
||||
```
|
||||
|
||||
Use the curl advisory style as inspiration: clear sections, direct language, affected/fixed version facts, recommendations, timeline, and credits. Do not include a PoC.
|
||||
|
||||
## Applying a draft to GitHub
|
||||
|
||||
When the user approves with "update"/similar or provides a markdown path:
|
||||
|
||||
1. Re-read the markdown file from disk. Never rely on the previously generated content in memory.
|
||||
2. Parse the YAML frontmatter and body.
|
||||
3. Build a JSON payload in a temporary file. Map fields as follows:
|
||||
- `summary` from frontmatter
|
||||
- `description` from the markdown body after frontmatter
|
||||
- `severity` from frontmatter if present
|
||||
- `cvss_vector_string` from `cvss_vector`
|
||||
- `cwe_ids` from frontmatter
|
||||
- `vulnerabilities` from frontmatter
|
||||
- Do not send `original_severity`, `original_cvss_vector`, or `original_cvss_score`; those fields are retained only for audit context.
|
||||
4. Update the advisory with:
|
||||
```sh
|
||||
gh api -X PATCH repos/<owner>/<repo>/security-advisories/<GHSA> --input /tmp/<payload>.json
|
||||
```
|
||||
5. If and only if the markdown frontmatter has `request_cve: true`, request a CVE with:
|
||||
```sh
|
||||
gh api -X POST repos/<owner>/<repo>/security-advisories/<GHSA>/cve
|
||||
```
|
||||
Treat "already requested" or "already assigned" as non-fatal and report it.
|
||||
6. Report what was updated:
|
||||
- advisory URL
|
||||
- summary
|
||||
- affected range
|
||||
- patched versions
|
||||
- original CVSS vector/score/severity
|
||||
- updated CVSS vector/score/severity
|
||||
- whether CVE was requested
|
||||
|
||||
## Safety rules
|
||||
|
||||
- Do not include PoC material in the final advisory body.
|
||||
- Do not request a CVE unless `request_cve: true` is present in the markdown file.
|
||||
- Do not publish the advisory or change its state unless the user explicitly asks.
|
||||
- Do not fetch advisory comments through browser sessions or cookies. State that comments were not included and invite the user to paste relevant comments if they want them considered.
|
||||
- If there is uncertainty in affected ranges, patched versions, CVSS, or CVE request status, ask the user before applying.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
description: Finish the current task end-to-end with changelog, commit, and push
|
||||
argument-hint: "[instructions]"
|
||||
---
|
||||
Wrap it.
|
||||
|
||||
Additional instructions: $ARGUMENTS
|
||||
|
||||
Determine context from the conversation history first.
|
||||
|
||||
Rules for context detection:
|
||||
- If the conversation already mentions a GitHub issue or PR, use that existing context.
|
||||
- If the work came from `/is` or `/pr`, assume the issue or PR context is already known from the conversation and from the analysis work already done.
|
||||
- If there is no GitHub issue or PR in the conversation history, treat this as non-GitHub work.
|
||||
|
||||
Unless I explicitly override something in this request, do the following in order:
|
||||
|
||||
1. Add or update the relevant package changelog entry under `## [Unreleased]` using the repo changelog rules.
|
||||
2. If this task is tied to a GitHub issue or PR and a final issue or PR comment has not already been posted in this session, draft it in my tone, preview it, and post exactly one final comment. The comment must end with this exact standalone disclaimer line, with no variations:
|
||||
|
||||
```text
|
||||
This comment is AI-generated by `/wr`
|
||||
```
|
||||
3. Commit only files you changed in this session.
|
||||
4. If this task is tied to exactly one GitHub issue, include `closes #<issue>` in the commit message. If it is tied to multiple issues, stop and ask which one to use. If it is not tied to any issue, do not include `closes #` or `fixes #` in the commit message.
|
||||
5. Check the current git branch. If it is not `main`, stop and ask what to do. Do not push from another branch unless I explicitly say so.
|
||||
6. Push the current branch.
|
||||
7. If this task is tied to exactly one GitHub issue, explicitly close that issue with reason `completed` after the push so the issue-close workflows in `.github/` run. This applies to issues only, not PRs.
|
||||
- Inspect `gh issue view <issue> --json state,stateReason,labels`.
|
||||
- If the issue is open, run `gh issue close <issue> --reason completed`.
|
||||
- If the issue is already closed with any reason other than `COMPLETED`, reopen it first, then close it with `gh issue close <issue> --reason completed` so GitHub emits a fresh close event.
|
||||
- If the issue is already closed as `COMPLETED`, leave it closed unless the `inprogress` label is still present; in that case reopen it and close it again with reason `completed`.
|
||||
|
||||
Constraints:
|
||||
- Never stage unrelated files.
|
||||
- Never use `git add .` or `git add -A`.
|
||||
- Run required checks before committing if code changed.
|
||||
- Do not open a PR unless I explicitly ask.
|
||||
- If this is not GitHub issue or PR work, do not post a GitHub comment.
|
||||
- If a final issue or PR comment was already posted in this session, do not post another one unless I explicitly ask.
|
||||
Reference in New Issue
Block a user