Skip to main content

/ready-pr — Review + sync PR metadata

Prepare a merge-ready branch in one shot: load and execute the full code-review and pr-description workflows together (same base branch scope), and create a Lark technical design for large PRs when Lark CLI is configured. Use when the user runs /ready-pr, asks to polish a PR for review, or wants a rules-based review report, updated PR metadata, and an optional drafted Lark PR review message; if no PR exists, ask before creating one unless the user explicitly requested PR creation.

Source: .agents/skills/ready-pr/SKILL.md

Metadata​

  • name: ready-pr

Content​

/ready-pr — Review + sync PR metadata

Invoking /ready-pr means the agent performs the review and PR metadata workflows in a single invocation, without asking which skill to run first. It may also run the Lark technical design workflow when the branch is large enough or the user explicitly asks for it. It may prepare a Lark PR review message, but it must never send the message without asking the user first.

  1. Code review first — follow every step of .agents/skills/code-review/SKILL.md.
  2. PR description immediately after — follow every step of .agents/skills/pr-description/SKILL.md.
  3. Lark tech design when applicable — follow .agents/skills/fe-tech-design/SKILL.md after the PR description step if the changed-line threshold is met or the user asks /ready-pr to include a FE tech design.
  4. Lark PR message draft when useful — follow .agents/skills/send-pr-message/SKILL.md only to collect metadata and draft the message. Always ask before sending, even if the user invoked /ready-pr and even if Lark auth is already available.

Treat the linked files as authoritative; do not skip rule loading or GitHub updates unless a prerequisite genuinely fails (gh auth, etc.—then report honestly). Because both linked skills may need feature context, load relevant .agents/references/features/*.md files once and reuse that context for both the review and PR narrative.

If no GitHub PR exists for the current branch, follow pr-description: draft the title/body and ask before creating the PR unless the user already explicitly asked to create or open one.

Unified scope (<base>)​

Use one default base branch for both steps so review and PR narrative match GitHub:

  • Prefer gh repo view --json defaultBranchRef --jq .defaultBranchRef.name
  • If that fails: git symbolic-ref refs/remotes/origin/HEAD → short name (commonly develop)

Code review diff for this skill: Prefer the same breadth as an open PR — review git diff <base>...HEAD on the branch that will merge (plus read changed files / context as required by code-review). Optionally also run /code-review pr (gh pr diff) when a PR exists; if it disagrees with git diff, prefer git diff <base>...HEAD plus gh pr base for narration.

Do not use “staged-only” (git diff --cached) for /ready-pr unless the user explicitly says their PR only contains staged work and their workflow differs.

Lark tech design trigger​

After code review and PR description are complete, evaluate whether a Lark technical design should be created:

  • Count additions plus deletions from the same <base>...HEAD diff used by review.
  • If additions plus deletions exceed 1000, run .agents/skills/fe-tech-design/SKILL.md unless the user explicitly opted out.
  • If the user explicitly asks /ready-pr to create or include a FE tech design, run the same Lark workflow even below the threshold.
  • Before creating a Lark doc, run the tech-design skill preflight: command -v lark-cli and lark-cli auth status.
  • Only create the Lark doc when lark-cli is installed and the user identity has the needed docs/wiki permission. If auth, scope, or parent access is missing, report the exact missing prerequisite and return the draft/outline instead of failing the whole /ready-pr flow.
  • If no Lark parent token or destination is specified, use the default frontend tech-design parent defined in .agents/skills/fe-tech-design/SKILL.md. Do not ask again unless that default parent cannot be resolved or the user requests a different destination.

Lark PR message handoff​

After code review, PR description, and any Lark tech design step are complete, decide whether a Lark PR review message should be prepared:

  • If a GitHub PR exists or was created during /ready-pr, draft a message using .agents/skills/send-pr-message/SKILL.md.
  • Use the final PR title/body context, PR URL, head branch, base branch, changed-line count, tech design link, and self-test link when available.
  • Default the draft target to Pull Request Goes Here unless the user requested another channel, such as Frontend Squad.
  • Reviewer lookup is allowed during drafting. Resolve the default or requested reviewers with .agents/skills/send-pr-message/SKILL.md so the draft can show real mentions.
  • Do not check Lark send scopes or send the message unless the user confirms they want to send.
  • Always ask before sending. The confirmation must include the target channel and the drafted message or a concise summary of it.
  • If the user confirms sending, then run .agents/skills/send-pr-message/SKILL.md from the beginning, including reviewer resolution, auth checks, idempotency, and final send reporting.
  • If the user does not confirm sending, leave the message as a draft in the final output.

Deliverables​

  1. Single response structured as:

    • Code review: Full output prescribed by code-review (Rules compliance, Critical / Warnings / Suggestions / What’s Good), grounded in <base>...HEAD rule checks.
    • PR: Confirm title/body updated (or created), with link. If gh pr edit fails (e.g. GraphQL Projects classic deprecation), patch via gh api repos/&#123;owner&#125;/&#123;repo&#125;/pulls/&#123;number&#125; -X PATCH --input <json-with-title-body>.
    • Lark tech design: When triggered, include the created Lark URL/token, changed-line count, sections included, and any missing context or permission caveats. If not triggered, omit this section unless it clarifies why a large-doc requirement was skipped.
    • Lark PR message: Include the drafted target channel and message, or the sent message ID only if the user separately confirmed sending during the /ready-pr run.

  2. If Critical findings exist, complete the pr-description update anyway, but state clearly at the top of the reply that merge is blocked until those are addressed (unless the user asked only to refresh copy).

Order​

Run code-review before pr-description so the reviewer output reflects the branch as-is; refreshing the GitHub uses the latest commits and does not rewrite local code.

Run the Lark tech design step after PR description. It depends on the reviewed diff and the final PR title/body, and it must not block the code-review or PR-description deliverables when Lark CLI, auth, scopes, or parent permissions are missing.

Run the Lark PR message draft after PR description and any tech design step. Sending is a separate write action and always requires user confirmation.