diff --git a/.pi/prompts/landpr.md b/.pi/prompts/landpr.md deleted file mode 100644 index 2d0553a7336..00000000000 --- a/.pi/prompts/landpr.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -description: Land a PR (merge with proper workflow) ---- - -Input - -- PR: $1 - - If missing: use the most recent PR mentioned in the conversation. - - If ambiguous: ask. - -Do (end-to-end) -Goal: PR must end in GitHub state = MERGED (never CLOSED). Prefer `gh pr merge --squash`; use `--rebase` only when preserving commit history is required. - -1. Assign PR to self: - - `gh pr edit --add-assignee @me` -2. Repo clean: `git status`. -3. Identify PR meta (author + head branch): - - ```sh - gh pr view --json number,title,author,headRefName,baseRefName,headRepository --jq '{number,title,author:.author.login,head:.headRefName,base:.baseRefName,headRepo:.headRepository.nameWithOwner}' - contrib=$(gh pr view --json author --jq .author.login) - head=$(gh pr view --json headRefName --jq .headRefName) - head_repo_url=$(gh pr view --json headRepository --jq .headRepository.url) - ``` - -4. Fast-forward base: - - `git checkout main` - - `git pull --ff-only` -5. Create temp base branch from main: - - `git checkout -b temp/landpr-` -6. Check out PR branch locally: - - `gh pr checkout ` -7. Rebase PR branch onto temp base: - - `git rebase temp/landpr-` - - Fix conflicts; keep history tidy. -8. Fix + tests + changelog: - - Implement fixes + add/adjust tests - - Update `CHANGELOG.md` and mention `#` + `@$contrib` -9. Decide merge strategy: - - Squash (preferred): use when we want a single clean commit - - Rebase: use only when we explicitly want to preserve commit history - - If unclear, ask -10. Full gate (BEFORE commit): - - `pnpm lint && pnpm build && pnpm test` -11. Commit via committer (final merge commit only includes PR # + thanks): - - For the final merge-ready commit: `committer "fix: (#) (thanks @$contrib)" CHANGELOG.md ` - - If you need intermediate fix commits before the final merge commit, keep those messages concise and **omit** PR number/thanks. - - `land_sha=$(git rev-parse HEAD)` -12. Push updated PR branch (rebase => usually needs force): - - ```sh - git remote add prhead "$head_repo_url.git" 2>/dev/null || git remote set-url prhead "$head_repo_url.git" - git push --force-with-lease prhead HEAD:$head - ``` - -13. Merge PR (must show MERGED on GitHub): - - Squash (preferred): `gh pr merge --squash` - - Rebase (history-preserving fallback): `gh pr merge --rebase` - - Never `gh pr close` (closing is wrong) -14. Sync main: - - `git checkout main` - - `git pull --ff-only` -15. Comment on PR with what we did + SHAs + thanks: - - ```sh - merge_sha=$(gh pr view --json mergeCommit --jq '.mergeCommit.oid') - gh pr comment --body "Landed via temp rebase onto main.\n\n- Gate: pnpm lint && pnpm build && pnpm test\n- Land commit: $land_sha\n- Merge commit: $merge_sha\n\nThanks @$contrib!" - ``` - -16. Verify PR state == MERGED: - - `gh pr view --json state --jq .state` -17. Delete temp branch: - - `git branch -D temp/landpr-` diff --git a/.pi/prompts/reviewpr.md b/.pi/prompts/reviewpr.md deleted file mode 100644 index 1b8a20dda90..00000000000 --- a/.pi/prompts/reviewpr.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -description: Review a PR thoroughly without merging ---- - -Input - -- PR: $1 - - If missing: use the most recent PR mentioned in the conversation. - - If ambiguous: ask. - -Do (review-only) -Goal: produce a thorough review and a clear recommendation (READY FOR /landpr vs NEEDS WORK vs INVALID CLAIM). Do NOT merge, do NOT push, do NOT make changes in the repo as part of this command. - -0. Truthfulness + reality gate (required for bug-fix claims) - - Do not trust the issue text or PR summary by default; verify in code and evidence. - - If the PR claims to fix a bug linked to an issue, confirm the bug exists now (repro steps, logs, failing test, or clear code-path proof). - - Prove root cause with exact location (`path/file.ts:line` + explanation of why behavior is wrong). - - Verify fix targets the same code path as the root cause. - - Require a regression test when feasible (fails before fix, passes after fix). If not feasible, require explicit justification + manual verification evidence. - - Hallucination/BS red flags (treat as BLOCKER until disproven): - - claimed behavior not present in repo, - - issue/PR says "fixes #..." but changed files do not touch implicated path, - - only docs/comments changed for a runtime bug claim, - - vague AI-generated rationale without concrete evidence. - -1. Identify PR meta + context - - ```sh - gh pr view --json number,title,state,isDraft,author,baseRefName,headRefName,headRepository,url,body,labels,assignees,reviewRequests,files,additions,deletions --jq '{number,title,url,state,isDraft,author:.author.login,base:.baseRefName,head:.headRefName,headRepo:.headRepository.nameWithOwner,additions,deletions,files:.files|length}' - ``` - -2. Read the PR description carefully - - Summarize the stated goal, scope, and any "why now?" rationale. - - Call out any missing context: motivation, alternatives considered, rollout/compat notes, risk. - -3. Read the diff thoroughly (prefer full diff) - - ```sh - gh pr diff - # If you need more surrounding context for files: - gh pr checkout # optional; still review-only - git show --stat - ``` - -4. Validate the change is needed / valuable - - What user/customer/dev pain does this solve? - - Is this change the smallest reasonable fix? - - Are we introducing complexity for marginal benefit? - - Are we changing behavior/contract in a way that needs docs or a release note? - -5. Evaluate implementation quality + optimality - - Correctness: edge cases, error handling, null/undefined, concurrency, ordering. - - Design: is the abstraction/architecture appropriate or over/under-engineered? - - Performance: hot paths, allocations, queries, network, N+1s, caching. - - Security/privacy: authz/authn, input validation, secrets, logging PII. - - Backwards compatibility: public APIs, config, migrations. - - Style consistency: formatting, naming, patterns used elsewhere. - -6. Tests & verification - - Identify what's covered by tests (unit/integration/e2e). - - Are there regression tests for the bug fixed / scenario added? - - Missing tests? Call out exact cases that should be added. - - If tests are present, do they actually assert the important behavior (not just snapshots / happy path)? - -7. Follow-up refactors / cleanup suggestions - - Any code that should be simplified before merge? - - Any TODOs that should be tickets vs addressed now? - - Any deprecations, docs, types, or lint rules we should adjust? - -8. Key questions to answer explicitly - - Is the core claim substantiated by evidence, or is it likely invalid/hallucinated? - - Can we fix everything ourselves in a follow-up, or does the contributor need to update this PR? - - Any blocking concerns (must-fix before merge)? - - Is this PR ready to land, or does it need work? - -9. Output (structured) - Produce a review with these sections: - -A) TL;DR recommendation - -- One of: READY FOR /landpr | NEEDS WORK | INVALID CLAIM (issue/bug not substantiated) | NEEDS DISCUSSION -- 1–3 sentence rationale. - -B) Claim verification matrix (required) - -- Fill this table: - - | Field | Evidence | - | ----------------------------------------------- | -------- | - | Claimed problem | ... | - | Evidence observed (repro/log/test/code) | ... | - | Root cause location (`path:line`) | ... | - | Why this fix addresses that root cause | ... | - | Regression coverage (test name or manual proof) | ... | - -- If any row is missing/weak, default to `NEEDS WORK` or `INVALID CLAIM`. - -C) What changed - -- Brief bullet summary of the diff/behavioral changes. - -D) What's good - -- Bullets: correctness, simplicity, tests, docs, ergonomics, etc. - -E) Concerns / questions (actionable) - -- Numbered list. -- Mark each item as: - - BLOCKER (must fix before merge) - - IMPORTANT (should fix before merge) - - NIT (optional) -- For each: point to the file/area and propose a concrete fix or alternative. -- If evidence for the core bug claim is missing, add a `BLOCKER` explicitly. - -F) Tests - -- What exists. -- What's missing (specific scenarios). -- State clearly whether there is a regression test for the claimed bug. - -G) Follow-ups (optional) - -- Non-blocking refactors/tickets to open later. - -H) Suggested PR comment (optional) - -- Offer: "Want me to draft a PR comment to the author?" -- If yes, provide a ready-to-paste comment summarizing the above, with clear asks. - -Rules / Guardrails - -- Review only: do not merge (`gh pr merge`), do not push branches, do not edit code. -- If you need clarification, ask questions rather than guessing.