mycr

name

mycr

description

Repo-managed MyCR workflow for reviewing and merging ready trpc-agent-go pull requests, maintaining the user's own pull requests without self-review comments, archiving reports, and improving the MyCR skill itself. Use when the user says "执行 mycr", "run mycr", or asks Codex to batch-review open trpc-agent-go GitHub PRs, filter out WIP/draft/unready PRs, directly fix own ready PRs, check CI and previously raised review threads, run one xhigh subagent review per review candidate, post only Flash-LHR style inline comments for real issues, approve perfect external PRs with "LGTM", merge mergeable approved external PRs, write an xhigh-quality Chinese-first standalone engineering report, publish that report under the MyCR archive, and capture concrete self-improvement opportunities for the skill.

MyCR

Overview

Run the maintainer review loop for trpc-group/trpc-agent-go from the repo-managed MyCR workspace. The canonical workspace is /Users/guoqizhou/projects/github/mycr; it owns this skill, the report renderer, the report archive, the /mycr website, and the self-evolution records.

Prefer repo-relative paths from the MyCR workspace. Resolve the target trpc-agent-go checkout in this order:

1. MYCR_TARGET_CHECKOUT
2. ../trpc-agent-go relative to the MyCR workspace
3. /Users/guoqizhou/projects/github/trpc-agent-go as the local fallback

Prefer gh when it is authenticated; otherwise use the GitHub connector tools.

Workflow

1. Identify the target repo as trpc-group/trpc-agent-go, identify the MyCR workspace as the current repo when it contains skill/SKILL.md and scripts/render_mycr_report.py, otherwise as /Users/guoqizhou/projects/github/mycr, and resolve the target checkout using the order in the overview.
2. Determine the authenticated reviewer login. Treat PRs authored by that login as own PRs. Also treat WineChord / winechord as own PR authors when they appear, because this workflow is run for the repository owner's account. Own PRs are not skipped by default. They enter the own-PR maintenance path below: review them for real issues, but never post review comments, approve, or merge them from this run.
3. Start with incremental planning, but keep a lightweight full-open-PR ledger:
   • Collect a cheap index for every open PR before doing any expensive diff, thread-body, log, source, or report-writing work. This index is a cache invalidation input, not a review artifact. It must include at least title, author, author association, labels, draft/WIP state, base branch, head SHA, mergeability, review decision, locked state and active lock reason, updated/latest-activity time, commit/check fingerprint, review-thread fingerprint, and comment/review fingerprint. Build those fingerprints from stable IDs, authors, states, timestamps, check names and conclusions, head SHAs, close/reopen/lock/unlock timeline events, and changed-file path summaries. Do not put full PR bodies, full review/comment bodies, diff hunks, source files, workflow logs, or long CodeRabbit comments into the cheap index. When small excerpts from external GitHub text are needed for fingerprints or blocker evidence, sanitize invalid Unicode and truncate by Unicode code point rather than UTF-16 index so emoji or other surrogate-pair text cannot produce invalid JSON.
   • Compare that index with the latest successful run-state snapshot by using node scripts/mycr-incremental-plan.mjs --current <current-index.json> --previous <previous-report-or-state.json> --output <plan.json> from the MyCR workspace when a previous state exists. Use a small overlap window instead of a strict timestamp boundary so updates that happen during the prior run are not missed. Keep the default --force-full-sweep-action probe: an old but otherwise unchanged PR should enter refresh_probe, not heavy_review. Use --force-full-sweep-action heavy only when the user explicitly asks for a full code re-review or the metadata looks corrupt. If the previous state is missing, unreadable, or does not contain the needed fingerprints, fall back to the conservative behavior and treat all open PRs as heavy_review.
   • After planning, generate a cache manifest with node scripts/mycr-cache-manifest.mjs --plan <plan.json> --output <cache-manifest.json>. For carry_forward and refresh_probe entries whose metadata_cache_key matches the previous key, reuse the previous full metadata/report-entry cache and do not read diffs, source, full comments, full threads, logs, or subagent output. For refresh_probe, refresh only the cheap index fields; if the probe changes any fingerprint or cache key, rerun the planner and promote that PR to heavy_review. For heavy_review, fetch full metadata once and write it under the manifest's full-metadata cache path so the next run can reuse it.
   • A PR enters the heavy path when it is new, its head SHA changed, CI/check fingerprint changed, review/comment/thread fingerprint changed, readiness markers changed, mergeability/base changed, it was previously , it has activity after the overlapped watermark that was not already seen in the previous snapshot, or a discovers a changed cache key. Missing required fingerprints must also promote the PR to the heavy path. A periodic freshness sweep by itself is only a ; it is not a reason to reread the diff or re-run xhigh review. A PR with an unchanged concrete blocker can be carried forward in the ledger, but only as a carried-forward blocker with its previous evidence and ; never approve, merge, post comments, or mark an own PR maintained from carried-forward data alone.
4. Split PRs into two auditable processing paths before applying the candidate gates:
   • External PR review path: PRs not authored by an own login. These are the only PRs eligible for inline review comments, approval with exactly LGTM, and merge.
   • Own-PR maintenance path: PRs authored by an own login. For these PRs, do the same quality audit you would do for an external PR, but convert valid findings into direct branch fixes instead of review comments. Prefer a separate git worktree for the PR branch so existing local changes in the main target checkout are not disturbed. Fetch the PR head, check out the contributor branch when it is pushable from the authenticated account, run the relevant tests/tooling, commit with project-style commit messages when changes are needed, and push back to the PR branch. If the branch is not pushable, report the exact blocker instead of posting review comments. Do not approve, request changes, submit LGTM, merge, or resolve review threads on own PRs as if you were a third-party reviewer. The goal is to leave each own PR at the quality level where the external PR path would have approved it.
5. Keep external review candidates only when they satisfy every gate:
   • state is open
   • title and labels do not indicate WIP
   • PR is not draft and is ready for review
   • base branch is the repository default branch unless the user said otherwise
   • for bugfixes and linked-issue fixes, the source problem has sufficient current evidence on the target base. A PR whose premise is only inferred from the diff, copied from a suggested issue fix, or supported only by branch-local tests must remain blocked until the current base behavior and root-cause path are verified. A stale, non-reproducible, or contradicted problem premise is a hard approval and merge blocker even when CI is green.
   • the implementation approach is a reasonable fit for the confirmed problem and the repository's public contract. Do not approve a PR merely because it satisfies the issue's literal proposed fix or a bot's linked-issue check if that fix uses the wrong knob, weakens default behavior, hides a contract decision in documentation, or broadens semantics beyond the actual need.
   • the PR is not under a manual-review gate. If issue labels, issue text, maintainer comments, code owner requests, active competing PRs, security/architecture scope, or product/roadmap ownership indicate that a human maintainer must choose the accepted PR, block approval and merge as manual_review until that explicit selection exists.
   • all commit statuses and workflow runs for the current head SHA are green before starting review, except the soft CI cases described below
   • pending, queued, in-progress, cancelled, timed out, missing required checks, or failures outside the soft CI cases mean do not review yet
   • CI readiness must be computed from the current head's effective latest checks, not from an undeduplicated statusCheckRollup that may include historical runs left behind by close/reopen cycles. Prefer gh pr checks --watch=false, current commit status, or latest check-suite/check-run data grouped by check name and workflow for the current head. If statusCheckRollup contains both an old failure and a newer success for the same effective check on the same head, treat the newer effective check as authoritative and record the stale rollup discrepancy instead of skipping the PR as CI-failed.
   • if the only non-green checks are go-apidiff and/or codecov/patch, do not skip automatically. Inspect the PR diff, PR description, reviewer discussion, and the concrete apidiff/codecov information. Treat the PR as reviewable when the API break is explicitly acceptable for this change or the codecov patch miss is not hiding a correctness risk. Record the judgment in the report. If the apidiff/codecov failure exposes a real compatibility, test-coverage, or quality blocker, skip or comment as appropriate.
6. For own PRs, apply the same readiness audit, but use own-PR outcomes:
   • If an own PR is draft, WIP, has non-soft failing CI, has a merge conflict, or has a live human-review blocker that requires product/design input, record the exact blocker. Do not post comments.
   • If an own PR is ready enough to inspect, perform the full review locally. Run one xhigh subagent review when the change is non-trivial, verify every finding yourself, then fix valid issues directly in the PR branch. Prefer creating a dedicated git worktree for the target branch and then running gh pr checkout <number> --repo trpc-group/trpc-agent-go inside that worktree, or use explicit fetch/checkouts when that is more reliable. Preserve unrelated worktree changes and never reuse a dirty checkout for own-PR fixes.
   • After pushing fixes, re-check the PR's CI and latest comments/threads. If CI is pending, report it as waiting for CI. If CI is green or only has acceptable soft-CI findings, report the PR under maintained with the commits, tests, and residual risks. Do not self-approve or merge it.
   • If the audit finds no needed code changes, report the PR under maintained as "no direct fix needed" with the evidence that would have made the external PR path approve it. Do not submit an approving review.
7. For skipped PRs, record the concrete skip reason for the final report. The reason must identify the exact gate that blocked review. Use structured blockers entries when possible. Do not group PRs under vague combined reasons such as "human review thread, Changes Requested, or API discussion" unless each item also lists the exact thread/comment/check/conflict that is actually blocking it. A manual_review gate must name the specific label, issue sentence, maintainer statement, code owner decision point, competing PR, security/architecture scope, broad verification contract, or product/roadmap ownership reason that makes MyCR approval or merge unsafe. If a PR is otherwise reviewable but was not processed because of time or candidate ordering, say that plainly as "not reached this run" and put it in follow-up, not in a blocker group. Before processing candidates and again before writing the report, compare the reviewability ledger with the processed list. If a PR looks reviewable but was not processed, promote it into the candidate queue when practical; otherwise report it as not_reached and include the specific reason it was deferred. The report must make this visible enough that the user can spot missed CR opportunities immediately.
8. Process external candidates one at a time. When the active Codex tool policy permits subagent delegation, spawn exactly one subagent per candidate with reasoning effort xhigh. Give it the PR number, repo, diff access instructions, and ask for a code-review result only; do not let the subagent post comments, approve, merge, or modify files. If the active tool policy or runtime does not permit subagent spawning, perform the same review depth locally and record the delegation limitation in the report's run capability or skill-evolution section instead of silently pretending a subagent ran.
9. Ask the subagent to first assess problem necessity and implementation derivation, then code quality. It must state whether the PR's claimed problem is confirmed on the current base, what evidence supports or contradicts it, which code path explains the root cause, and whether the chosen implementation follows from that evidence. Then ask it to focus on design, compatibility, likely bugs, cross-module impact, severity, and the smallest correct fix. Require code findings to include path, changed-side line or position, concise English body, Chinese translation, and why the issue matters. Allow a non-inline necessity or implementation_scope blocker when the problem premise or solution path is not sufficiently established and no changed line is the right anchor. Allow a solution_fit blocker when the user pain is real but the chosen API, default, option, documentation, or runtime behavior is the wrong abstraction for that pain.
10. Verify each returned finding against the current PR diff. Keep only concrete, actionable issues that can be anchored to changed lines. Discard style, preference, broad design commentary, or findings outside the diff unless the changed line directly creates the risk. Verify each returned necessity or implementation-scope blocker against the source issue/report, latest PR discussion, and current base code path; keep it only when the missing or contradicting evidence would make approval unsafe. Verify each returned solution-fit blocker against the intended user pain, public contract, alternative designs, and current implementation constraints; keep it when the submitted approach would leave a confusing or brittle contract even if the original symptom is real.
11. For valid external-PR findings, submit a GitHub review with only inline file comments. Use the flash-lhr-pr-comment skill shape: one or two direct English sentences, then a Chinese translation in <details><summary>中文</summary>...</details>. Do not post a top-level PR comment when inline comments are available. If the only valid blocker is a problem-evidence or implementation-scope blocker, or a solution-fit blocker that cannot be anchored to a changed line, do not invent an inline anchor. Leave one concise top-level PR review comment asking for the missing reproduction, raw payload/log, current-base verification, better control surface, or contract decision, and report the PR as blocked; do not approve or merge.
12. Before any approving review, refresh the PR head SHA, linked issue metadata, review threads, review decision, maintainer comments, and manual-review evidence. If manual_review still applies, do not approve. Record the blocker and the evidence that still requires a human decision.
13. If an external PR has no valid findings and is not blocked by manual_review, approve it with a GitHub pull-request review whose state is approve and whose body is exactly LGTM. This must be the same visible effect as a human submitting an approving review from the GitHub UI, not a standalone issue comment that says LGTM.
14. After approval, refresh the current head SHA, effective checks, mergeability, codecov state, manual_review state, and merge_policy before attempting a merge. If merge_policy.mode is human_required, do not merge; leave the PR approved or reviewed-clean as appropriate and report the required human merge evidence. If manual_review became applicable during the refresh, do not merge even if MyCR already approved earlier in the run.
15. Merge the external PR using the repository-supported merge method only when it has no non-green codecov/patch check and no merge_policy blocking MyCR from merging. For this repo, prefer squash merge when repository metadata says only squash merge is allowed. The merge must preserve GitHub's default squash commit title and body, the same as clicking the UI "Squash and merge" button without editing the generated message. Do not pass custom merge subjects or bodies. With gh pr merge, use --squash and --match-head-commit as needed, but do not use --subject, --body, or --body-file. With the GitHub connector _merge_pull_request, pass merge_method: "squash" and expected_head_sha as needed, but leave commit_title and commit_message unset/null. If a tool path cannot omit custom title/body fields, do not use that path. This keeps the PR number suffix generated by GitHub, for example (#1844). If codecov/patch is still non-green, leave the approved PR unmerged and report it as approved but waiting for codecov.
16. Before ending, fetch each processed PR's latest comments and review threads again. For external PRs, if new actionable comments appeared and can be fixed by the author or require a different outcome, handle them before reporting; otherwise include them in the report. For own PRs, convert any newly discovered actionable issue into another direct branch fix when possible, then re-check CI and threads. If any PR head moved after comments or fixes, require CI to be all green again before approving or merging, except for documented soft CI failures that were explicitly re-evaluated after the head movement. A re-evaluated codecov/patch soft failure can still allow external review/approval, but never merge while it remains non-green.
17. Report all reviewed PRs, maintained own PRs, skipped PRs with reasons, comments posted, direct fixes, approvals, merge results, and any blocked operations. Generate the interactive HTML report described below before sending the final answer. Follow the detailed reporting contract below. Treat report writing as an xhigh-quality pass, not as a short run log: synthesize the PR content, implementation design, review judgment, and follow-up priorities so the user can understand the engineering state without opening GitHub or reading a diff.
18. Before committing or final-answering a meaningful run, run the post-report QA pass from the MyCR workspace. Prefer archiving through node scripts/archive-report.mjs <summary.json>, which normalizes and validates the source report before rendering. If the report was edited after archiving, run node scripts/report-quality.mjs --file src/data/reports/<report>.json --write --check, copy the normalized JSON to public/reports/, render the HTML again with scripts/render_mycr_report.py, and then run npm run verify. Treat quality failures as workflow failures, not cosmetic warnings.
19. Inspect the generated HTML contract, not only the JSON. At minimum verify that reviewed PR cards, skipped groups, follow-up entries, inline comments, and self-evolution notes are renderable and not empty placeholders. When the report renderer or UI changed, use a browser or static DOM check to confirm the page visibly contains the expected sections before publishing.

Reporting Contract

In the final report:

• Use Chinese as the primary reporting and analysis language. When writing Chinese sections, summaries, skip reasons, follow-up judgments, timelines, and plain-text final answers, make them as fully Chinese as practical. Preserve original English only for source material that should stay exact, such as PR titles, code identifiers, file paths, check names, branch names, commit messages, quoted review bodies, and GitHub UI/status literals.
• Create a structured JSON summary of the run and render it with scripts/render_mycr_report.py. The HTML report must be default Chinese, switchable to English, and include visual/interactive UI for status totals, reviewed PRs, skipped PR groups, comment details, CI/thread state, search, and status filtering.
• Include the incremental planner result or equivalent fields in the JSON summary as incremental_plan, and include the next run-state snapshot as run_state. These fields are the workflow's memory: they should record the lightweight open-PR index, planning reasons such as head_sha_changed or checks_changed, carried-forward blockers, and the latest successful verification time. The public report renderer may ignore these fields, but future MyCR runs must be able to use them to avoid repeating expensive work.
• The HTML report should feel like a polished engineering dashboard, inspired by high-quality developer tools such as GitHub/Graphite review timelines, Linear-style dense status lists, Vercel-style deployment/status cards, and Raycast-style detail panes. Keep it self-contained, fast, responsive, and readable: clear hierarchy, restrained color, strong scanability, sticky search/filter controls, status dots, compact metrics, readable long-form PR details, and obvious reviewed / commented / maintained / skipped / follow-up sections. Avoid decorative clutter, marketing-page layout, or generic blog styling.
• The report must be a self-contained engineering brief, not merely an action log. A reader should be able to understand, from the report alone, what each reviewed PR changes, why the change exists, which modules and code paths are affected, how the implementation works, what behavior/API/docs/tests changed, why the review outcome was chosen, and which items still deserve attention. If this cannot be understood without opening the PR diff, the report is not good enough.
• Every reviewed PR entry must include beginner-friendly technical background for all important modules and concepts touched by the PR, not just the PR's immediate motivation. Explain the underlying technical principles from zero: what the module is responsible for, how it fits into the agent runtime, what data flows through it, which lifecycle/callback/tool/session/model concepts matter, and why those concepts make the PR's change non-trivial. When a PR touches multiple modules, explain each module's role and how they cooperate. The goal is that a reader unfamiliar with this area of the codebase can first learn the relevant domain model, then understand the PR.

Self-Evolution Loop

• Treat the MyCR repo as the skill's long-term memory and implementation home. The installed ~/.codex/skills/mycr copy should stay a bootstrap that points back to this repo.
• At the end of each real MyCR run, capture concrete friction, repeated manual work, missed edge cases, brittle path assumptions, weak report fields, confusing UI, or unclear review gates in data/evolution/backlog.md.
• Treat report QA as part of self-evolution. Empty rendered fields, review actions written into PR-content fields, non-canonical display statuses, skipped groups without per-PR blockers, follow-up entries that render as blank cards, or missing HTML-visible self-evolution notes must produce a local fix or an explicit backlog item before the run is considered done.
• When the user explicitly asks for an independent reviewer, or the active tool policy otherwise permits it, spawn a fresh xhigh reviewer after the report is generated. The reviewer should inspect the latest JSON/HTML and MyCR flow read-only, then return concrete quality gaps and evolution suggestions. The main agent must validate those suggestions, implement low-risk local fixes, and record longer-term work in data/evolution/backlog.md.
• If subagent tools are unavailable or not permitted by the active tool policy, do the same checklist locally and record the limitation as a run capability or skill_evolution note so the report remains auditable.
• When the user asks for MyCR maintenance, or when a low-risk improvement is clearly local to this repo, update the relevant canonical files here: skill/SKILL.md, scripts/, src/, data/specs/, or data/evolution/. Then run npm run verify, commit, and push to main.
• Prefer environment overrides and repo-relative paths. Document the rare absolute fallback in README.md, AGENTS.md, or this skill instead of scattering hardcoded paths through scripts.
• Keep self-evolution changes separate from target PR review judgments. Do not let a MyCR skill improvement modify trpc-agent-go unless the user asked for that target-repo change.
• For durable design decisions, add a dated note under data/evolution/ so future runs can explain why the skill or report workflow changed.

Practical Notes

• If gh has no valid GitHub auth, use the GitHub connector instead of blocking unless a required action is unavailable there.
• Incremental planning is an optimization, not a correctness shortcut. The cheap full-open-PR index must still be refreshed every run, and any missing or suspicious planner input must make the run fall back to a conservative heavy scan. Before submitting review comments, approving, merging, or pushing own-PR fixes, refresh the PR's head SHA, checks, comments, and review threads even if the incremental plan selected it correctly.
• Use scripts/mycr-incremental-plan.mjs to compare the current lightweight index with the latest archived report's run_state. The planner only decides which PRs need expensive work; it does not decide review outcomes. Treat carry_forward entries as reportable unchanged blockers, not as permission to approve or merge.
• Run a periodic lightweight freshness probe when the prior state is older than the planner's --force-full-sweep-hours threshold, or sooner if GitHub metadata looks inconsistent. The default threshold is 24 hours, but the default action is probe, not full heavy review. A freshness probe refreshes only cheap index fields and reuses the full-metadata cache if the metadata_cache_key stays unchanged. Use full heavy sweep only for corrupt metadata, missing fingerprints, explicit user requests, or changed cache keys.
• For CI, check both combined commit statuses and GitHub Actions workflow runs. Treat pending, queued, in-progress, cancelled, timed out, skipped unexpectedly, or missing required checks as not ready.
• Soft CI exception: when the only non-green checks are go-apidiff and/or codecov/patch, inspect the concrete failure instead of skipping by rule. For go-apidiff, fetch the check details/logs or reproduce the relevant apidiff locally when practical, then decide whether the break is intentional, documented, and acceptable for the PR. For codecov/patch, inspect the diff and tests to decide whether the uncovered patch area creates a meaningful regression risk. Review can proceed when the only remaining concern is an acceptable API break or an acceptable patch-coverage miss. Approval can proceed when the review is clean, but merge must not proceed while codecov/patch remains non-green. Record the soft-CI judgment and any approval-without-merge decision in the report.
• Human review comments can be considered addressed when the author clearly replied fixed, done, or gave a concrete acceptable explanation, even if the GitHub thread is still unresolved. Verify the latest diff before relying on the reply.

Subagent Prompt

Use a prompt shaped like this for each candidate:

Review trpc-group/trpc-agent-go PR #<number> at xhigh depth.

First assess whether the PR's problem premise is established. Check the linked
issue or source problem report, PR description and discussion, available logs or
raw payloads, tests, and current base-branch code path. State whether the
problem is confirmed on the current base, plausible but unproven,
contradicted/stale, or waiting on a product/contract decision. Explain why the
edited code path follows from that evidence, or why it does not.

Separate the underlying user pain from any implementation proposed in the issue
or PR. Assess whether the selected API, default, configuration option,
documentation, or runtime control surface is the right fit, or whether a
different design would preserve a clearer contract.

Then focus only on changed behavior in this PR and directly related code.
Prioritize design soundness, API and semantic compatibility, potential bugs,
data races, streaming/session semantics, cross-module impact, and test gaps that
expose real regression risk.

Do not post comments, approve, merge, or edit files. Return only:
- "no findings" if the PR is clean
- or a `necessity` / `implementation_scope` blocker with the missing or
  contradicting evidence and the smallest evidence needed to proceed
- or a `solution_fit` blocker when the problem is real but the chosen control
  surface, default, option, or documentation contract is not a good design fit
- or a list of findings with path, changed-side line or diff position, exact
  problem, impact, and minimal fix

Only report code issues that would justify an inline review comment. Necessity,
implementation-scope, or solution-fit blockers may be unanchored when no changed
line is the right place to ask for missing source-problem evidence or a better
contract decision.