docs(prompts): add inprogress labeling instructions
This commit is contained in:
@@ -5,16 +5,17 @@ Analyze GitHub issue(s): $ARGUMENTS
|
|||||||
|
|
||||||
For each issue:
|
For each issue:
|
||||||
|
|
||||||
1. Read the issue in full, including all comments and linked issues/PRs.
|
1. Add the `inprogress` label to the issue via GitHub CLI before analysis starts. If adding the label fails, report that explicitly and continue.
|
||||||
2. Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
|
2. Read the issue in full, including all comments and linked issues/PRs.
|
||||||
|
3. Do not trust analysis written in the issue. Independently verify behavior and derive your own analysis from the code and execution path.
|
||||||
|
|
||||||
3. **For bugs**:
|
4. **For bugs**:
|
||||||
- Ignore any root cause analysis in the issue (likely wrong)
|
- Ignore any root cause analysis in the issue (likely wrong)
|
||||||
- Read all related code files in full (no truncation)
|
- Read all related code files in full (no truncation)
|
||||||
- Trace the code path and identify the actual root cause
|
- Trace the code path and identify the actual root cause
|
||||||
- Propose a fix
|
- Propose a fix
|
||||||
|
|
||||||
4. **For feature requests**:
|
5. **For feature requests**:
|
||||||
- Do not trust implementation proposals in the issue without verification
|
- Do not trust implementation proposals in the issue without verification
|
||||||
- Read all related code files in full (no truncation)
|
- Read all related code files in full (no truncation)
|
||||||
- Propose the most concise implementation approach
|
- Propose the most concise implementation approach
|
||||||
|
|||||||
@@ -4,20 +4,21 @@ description: Review PRs from URLs with structured issue and code analysis
|
|||||||
You are given one or more GitHub PR URLs: $@
|
You are given one or more GitHub PR URLs: $@
|
||||||
|
|
||||||
For each PR URL, do the following in order:
|
For each PR URL, do the following in order:
|
||||||
1. Read the PR page in full. Include description, all comments, all commits, and all changed files.
|
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. Identify any linked issues referenced in the PR body, comments, commit messages, or cross links. Read each issue in full, including all comments.
|
2. Read the PR page in full. Include description, all comments, all commits, and all changed files.
|
||||||
3. Analyze the PR diff. Read all relevant code files in full with no truncation from the current main branch 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.
|
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. Check for a changelog entry in the relevant `packages/*/CHANGELOG.md` files. Report whether an entry exists. If missing, state that a changelog entry is required before merge and that you will add it if the user decides to merge. Follow the changelog format rules in AGENTS.md. Verify:
|
4. Analyze the PR diff. Read all relevant code files in full with no truncation from the current main branch 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. Check for a changelog entry in the relevant `packages/*/CHANGELOG.md` files. Report whether an entry exists. If missing, state that a changelog entry is required before merge and that you will add it if the user decides to merge. Follow the changelog format rules in AGENTS.md. Verify:
|
||||||
- Entry uses correct section (`### Breaking Changes`, `### Added`, `### Fixed`, etc.)
|
- Entry uses correct section (`### Breaking Changes`, `### Added`, `### Fixed`, etc.)
|
||||||
- External contributions include PR link and author: `Fixed foo ([#123](https://github.com/badlogic/pi-mono/pull/123) by [@user](https://github.com/user))`
|
- External contributions include PR link and author: `Fixed foo ([#123](https://github.com/badlogic/pi-mono/pull/123) by [@user](https://github.com/user))`
|
||||||
- Breaking changes are in `### Breaking Changes`, not just `### Fixed`
|
- Breaking changes are in `### Breaking Changes`, not just `### Fixed`
|
||||||
5. 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.
|
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.
|
||||||
6. Provide a structured review with these sections:
|
7. Provide a structured review with these sections:
|
||||||
- Good: solid choices or improvements
|
- Good: solid choices or improvements
|
||||||
- Bad: concrete issues, regressions, missing tests, or risks
|
- Bad: concrete issues, regressions, missing tests, or risks
|
||||||
- Ugly: subtle or high impact problems
|
- Ugly: subtle or high impact problems
|
||||||
7. Add Questions or Assumptions if anything is unclear.
|
8. Add Questions or Assumptions if anything is unclear.
|
||||||
8. Add Change summary and Tests.
|
9. Add Change summary and Tests.
|
||||||
|
|
||||||
Output format per PR:
|
Output format per PR:
|
||||||
PR: <url>
|
PR: <url>
|
||||||
|
|||||||
Reference in New Issue
Block a user