| name | post-pr-for-review |
| description | Post a pull request to the LI.FI `#dev-sc-review` Slack channel for smart-contract team review. Enables auto-merge (squash) on the PR by default, posts the PR URL + title as a top-level message (matching the existing channel format `<URL> << <title>`), then replies in-thread tagging the `@smartcontract_core` user group. Use when the user says "post PR for review", "send to sc review", "share PR with sc team", "post to dev-sc-review", or supplies a PR URL with intent to request review from the smart-contract core team. Requires the Slack MCP server to be connected. |
Post PR for Review
When to trigger
User says any of:
- "post PR for review" / "send PR to sc review" / "share for review"
- "post to dev-sc-review"
- Provides a GitHub PR URL with review intent
/post-pr-for-review [url]
Inputs
- PR URL (optional). If omitted, resolve from current branch via
gh pr view --json url,title,body,number. If no PR exists for the current branch, ask the user for the URL.
Channel + audience (fixed)
- Channel:
#dev-sc-review (resolve ID via slack_search_channels; known ID at time of writing: C088UJWC8PR)
- Tag in thread:
@smartcontract_core — Slack user group, subteam ID S096X6MCB0C
- Mention syntax (REQUIRED):
<!subteam^S096X6MCB0C> — plain @smartcontract_core does NOT trigger notifications (verified 2026-05-13)
Format (match existing channel convention exactly)
Top-level message:
<PR_URL> << <PR_TITLE>
Example from the channel:
https://github.com/lifinance/contracts/pull/1776 << claude skill for creating user stories
Do not add prefixes like "New PR:" or emoji to the top-level message. Match the channel's terse style.
Thread reply (first reply, posted by the same skill run):
<!subteam^S096X6MCB0C> please review 🙏
That's it. No long description, no checklist. The channel is high-signal/low-noise.
Workflow
-
Resolve PR
- If URL given, parse
owner/repo/pull/N.
- Else:
gh pr view --json url,title,number,body,headRefName,isDraft (in the current repo).
- Extract
title, url, number, isDraft.
-
Pre-flight checks — run all three before touching Slack. The goal is simple: don't waste the SC team's attention on a PR that obviously isn't ready. We surface problems to the executor and let them decide what to fix — this skill does NOT auto-create fix PRs (a sibling skill, planned as address-pr-review-comments, owns that separate concern).
a) Unresolved review threads — especially CodeRabbit, but any unresolved thread counts. REST doesn't expose isResolved, so use GraphQL:
gh api graphql -f query='
query($owner:String!,$repo:String!,$num:Int!){
repository(owner:$owner,name:$repo){
pullRequest(number:$num){
reviewThreads(first:100){
nodes{
isResolved
isOutdated
comments(first:1){ nodes{ author{login} body url path } }
}
}
}
}
}' -f owner=<owner> -f repo=<repo> -F num=<N> \
--jq '.data.repository.pullRequest.reviewThreads.nodes
| map(select(.isResolved == false and .isOutdated == false))'
Group results by author. CodeRabbit appears as coderabbitai / coderabbitai[bot].
b) CI status
gh pr checks <N>
Treat as blockers: non-success terminal states (FAILURE, CANCELLED, TIMED_OUT, ACTION_REQUIRED) except for review-gated checks (see allowlist below). IN_PROGRESS/QUEUED/PENDING/SKIPPED is informational, not a blocker on its own.
Review-triggered check allowlist — workflows wired to GitHub's pull_request_review event only fire after a reviewer submits a review. Pre-review they sit in SKIPPED/PENDING/ACTION_REQUIRED by design — they haven't been triggered yet. GitHub renders these in the checks list with a suffix on the check name. Posting to is literally how we trigger them, so blocking on them would be circular.
Failure modes
- MCP not connected: Tell user to connect the Slack MCP and retry. Do NOT fall back to webhooks (different identity model — see notes below).
- Channel not found: Surface the search results; channel may have been renamed.
- gh CLI missing or unauthenticated: Ask user to paste the PR URL directly; skip pre-flight checks and warn that they were skipped.
- GraphQL query fails / rate limited: Fall back to
gh pr view --json reviewDecision,comments and surface raw comment count; warn that resolution-state could not be determined.
Design notes (why this skill exists)
- Posts via Slack MCP → message appears as the human user, preserving thread-reply notifications and author attribution. This is the right channel etiquette for
#dev-sc-review.
- Webhook-based posting (used by
audit-request-slack-relay in CI) is intentionally NOT used here — it would post as a bot and lose attribution.
- No secrets stored anywhere; each teammate authenticates the Slack MCP once via their own Claude Code config.
Variations the user may request
- "Also @ Daniela specifically" → add
@Daniela after the group tag in the thread reply.
- "Add context: " → append the message as a second thread reply, NOT to the top-level post.
- "Quiet ping" → drop the 🙏 emoji; keep just
@smartcontract_core please review.
