/daily-code-review
Generate a daily code review report showing stale PRs, items needing your attention, and active work for your team. Use whenever the user asks for a PR report, code review status, daily standup prep, team PR overview, "what needs review", "what's stale", "show me open PRs",
$ npx -y skills add Flagrare/agent-skills --skill daily-code-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/daily-code-review
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate a daily code review report showing stale PRs, items needing your attention, and active work for your team. Use whenever the user asks for a PR report, code review status, daily standup prep, team PR overview, "what needs review", "what's stale", "show me open PRs",
SKILL.md
daily-code-review.SKILL.mdname: daily-code-review
description: Generate a daily code review report showing stale PRs, items needing your attention, and active work for your team. Use whenever the user asks for a PR report, code review status, daily standup prep, team PR overview, "what needs review", "what's stale", "show me open PRs", "daily review", "PR check", "review report", "what should I look at today", or any question about tracking pull request activity across a team or pod. Also trigger when the user mentions a specific pod name that matches a saved config.
Daily Code Review Report
> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook that flags em-dashes in generated `.md`. See `/flagrare:write-docs`.
Generate a team-wide pull request status report focused on actionable next steps. The report surfaces stale PRs, items needing the runner's personal attention, and a quick FYI on active work, so the reader knows exactly what to do when they open GitHub.
Setup (first run only)
Team configs live at **`~/.claude/skills/flagrare/daily-code-review/teams/*.json`**: one file per team, outside the plugin tree so they survive plugin updates and reinstalls.
In Bash, expand `~` explicitly: `"$HOME/.claude/skills/flagrare/daily-code-review/teams"`. The directory may not exist yet, `mkdir -p "$HOME/.claude/skills/flagrare/daily-code-review/teams"` before writing.
Step 1: Migrate legacy configs (one-time)
If the new dir has no team files but the legacy per-plugin dir does, migrate them:
LEGACY="{skill_directory}/teams" # old location, lost on plugin reinstall
NEW="$HOME/.claude/skills/flagrare/daily-code-review/teams"
if [ -d "$LEGACY" ] && [ ! -d "$NEW" ]; then
mkdir -p "$NEW"
cp "$LEGACY"/*.json "$NEW"/ 2>/dev/null || true
fiTell the user once: "Migrated your team configs from the old per-plugin location to `~/.claude/skills/flagrare/daily-code-review/teams/` so they survive plugin updates."
Step 2: Check for existing configs
Check for config files matching `~/.claude/skills/flagrare/daily-code-review/teams/*.json`. If none exist, run the first-time setup flow.
First-time setup
Use `AskUserQuestion` to collect:
1. **GitHub org**: the GitHub organization to search (e.g., `acme-corp`) 2. **Team name**: a human label for the report header (e.g., `Platform Team`) 3. **Team members**: for each person, their GitHub login and display name. Ask in a single prompt, one member per line, format: `github_login / Display Name`
Save to `~/.claude/skills/flagrare/daily-code-review/teams/{team-name-slug}.json`:
{
"org": "acme-corp",
"team_name": "Platform Team",
"members": [
{ "github_login": "aturing", "display_name": "Alan Turing" },
{ "github_login": "ghopper", "display_name": "Grace Hopper" },
{ "github_login": "dknuth", "display_name": "Don Knuth" }
]
}Confirm the config with the user before proceeding.
Returning user
If exactly one team config exists, use it. If multiple exist, ask which team to report on.
If the user says "add a team" or "edit team," update or create the relevant config file and re-confirm.
Detect "Me"
Run:
gh api user --jq '.login'
Match against the team members list by `github_login`. If no match, ask the user which member they are, they might be authenticated with a personal account that differs from their team login.
Data Collection
Use **only** these GitHub API endpoints. The comments API is noisy and `mergeable_state` is unreliable, skip both. Staleness comes from `updated_at` alone.
Open PRs per member
The search/issues endpoint does NOT return draft status reliably (it comes back null). Run two searches per member to separate drafts from non-drafts:
gh api "search/issues?q=org:{org}+is:pr+is:open+-is:draft+author:{login}&per_page=100" \
--jq '.items[] | {number, title, html_url, updated_at, draft: false, repo: (.repository_url | split("/") | last), user: .user.login}'gh api "search/issues?q=org:{org}+is:pr+is:open+is:draft+author:{login}&per_page=100" \
--jq '.items[] | {number, title, html_url, updated_at, draft: true, repo: (.repository_url | split("/") | last), user: .user.login}'Run all searches in parallel across team members. Deduplicate by PR number + repo.
Reviews and requested reviewers
For each PR:
gh api "repos/{org}/{repo}/pulls/{number}/reviews" \
--jq '[.[] | select(.user.login | test("\\[bot\\]$") | not) | {user: .user.login, state}]'gh api "repos/{org}/{repo}/pulls/{number}/requested_reviewers" \
--jq '{users: [.users[].login], teams: [.teams[].slug]}'Filter out bot reviews (logins ending in `[bot]`), they're noise from CI integrations, not human review activity.
Run these in parallel across PRs where possible. If you hit rate limits, back off and retry.
Classification
Staleness thresholds
| Category | Threshold | |----------|-----------| | Stale (pod-wide) | `updated_at` > 24 hours ago | | Needs attention | `updated_at` > 12 hours ago | | Parked draft | draft + `updated_at` > 30 days ago |
Calculate hours (or days for parked drafts) since `updated_at` relative to now. Round to the nearest whole number.
Review state
Determine per-PR by reading the reviews list chronologically:
- **Approved**: at least one `APPROVED` review, no subsequent `CHANGES_REQUESTED`
- **Changes requested**: most recent non-dismissed review is `CHANGES_REQUESTED`
- **Pending**: has requested reviewers who haven't submitted a review
Show reviewer names in each state (e.g., "approved by Alice, Bob").
Report Format
# {team_name} Code Review Report: {YYYY-MM-DD}
> Generated for **{display_name}** | {n} open PRs across {m} membersSection 1: Stale PRs (>24h no action)
All open PRs across the team (including drafts) where `updated_at` > 24h. Only exclude drafts older than 30 days, those go in the
Read more
name: daily-code-review description: Generate a daily code review report showing stale PRs, items needing your attention, and active work for your team. Use whenever the user asks for a PR report, code review status, daily standup prep, team PR overview, "what needs review", "what's stale", "show me open PRs", "daily review", "PR check", "review report", "what should I look at today", or any question about tracking pull request activity across a team or pod. Also trigger when the user mentions a specific pod name that matches a saved config.
Daily Code Review Report
> **No em-dashes.** Nothing this skill writes may contain an em-dash; use a comma, colon, or parentheses instead. Enforced by a repo hook that flags em-dashes in generated `.md`. See `/flagrare:write-docs`.
Generate a team-wide pull request status report focused on actionable next steps. The report surfaces stale PRs, items needing the runner's personal attention, and a quick FYI on active work, so the reader knows exactly what to do when they open GitHub.
Setup (first run only)
Team configs live at **`~/.claude/skills/flagrare/daily-code-review/teams/*.json`**: one file per team, outside the plugin tree so they survive plugin updates and reinstalls.
In Bash, expand `~` explicitly: `"$HOME/.claude/skills/flagrare/daily-code-review/teams"`. The directory may not exist yet, `mkdir -p "$HOME/.claude/skills/flagrare/daily-code-review/teams"` before writing.
Step 1: Migrate legacy configs (one-time)
If the new dir has no team files but the legacy per-plugin dir does, migrate them:
LEGACY="{skill_directory}/teams" # old location, lost on plugin reinstall
NEW="$HOME/.claude/skills/flagrare/daily-code-review/teams"
if [ -d "$LEGACY" ] && [ ! -d "$NEW" ]; then
mkdir -p "$NEW"
cp "$LEGACY"/*.json "$NEW"/ 2>/dev/null || true
fiTell the user once: "Migrated your team configs from the old per-plugin location to `~/.claude/skills/flagrare/daily-code-review/teams/` so they survive plugin updates."
Step 2: Check for existing configs
Check for config files matching `~/.claude/skills/flagrare/daily-code-review/teams/*.json`. If none exist, run the first-time setup flow.
First-time setup
Use `AskUserQuestion` to collect:
1. **GitHub org**: the GitHub organization to search (e.g., `acme-corp`) 2. **Team name**: a human label for the report header (e.g., `Platform Team`) 3. **Team members**: for each person, their GitHub login and display name. Ask in a single prompt, one member per line, format: `github_login / Display Name`
Save to `~/.claude/skills/flagrare/daily-code-review/teams/{team-name-slug}.json`:
{
"org": "acme-corp",
"team_name": "Platform Team",
"members": [
{ "github_login": "aturing", "display_name": "Alan Turing" },
{ "github_login": "ghopper", "display_name": "Grace Hopper" },
{ "github_login": "dknuth", "display_name": "Don Knuth" }
]
}Confirm the config with the user before proceeding.
Returning user
If exactly one team config exists, use it. If multiple exist, ask which team to report on.
If the user says "add a team" or "edit team," update or create the relevant config file and re-confirm.
Detect "Me"
Run:
gh api user --jq '.login'
Match against the team members list by `github_login`. If no match, ask the user which member they are, they might be authenticated with a personal account that differs from their team login.
Data Collection
Use **only** these GitHub API endpoints. The comments API is noisy and `mergeable_state` is unreliable, skip both. Staleness comes from `updated_at` alone.
Open PRs per member
The search/issues endpoint does NOT return draft status reliably (it comes back null). Run two searches per member to separate drafts from non-drafts:
gh api "search/issues?q=org:{org}+is:pr+is:open+-is:draft+author:{login}&per_page=100" \
--jq '.items[] | {number, title, html_url, updated_at, draft: false, repo: (.repository_url | split("/") | last), user: .user.login}'gh api "search/issues?q=org:{org}+is:pr+is:open+is:draft+author:{login}&per_page=100" \
--jq '.items[] | {number, title, html_url, updated_at, draft: true, repo: (.repository_url | split("/") | last), user: .user.login}'Run all searches in parallel across team members. Deduplicate by PR number + repo.
Reviews and requested reviewers
For each PR:
gh api "repos/{org}/{repo}/pulls/{number}/reviews" \
--jq '[.[] | select(.user.login | test("\\[bot\\]$") | not) | {user: .user.login, state}]'gh api "repos/{org}/{repo}/pulls/{number}/requested_reviewers" \
--jq '{users: [.users[].login], teams: [.teams[].slug]}'Filter out bot reviews (logins ending in `[bot]`), they're noise from CI integrations, not human review activity.
Run these in parallel across PRs where possible. If you hit rate limits, back off and retry.
Classification
Staleness thresholds
| Category | Threshold | |----------|-----------| | Stale (pod-wide) | `updated_at` > 24 hours ago | | Needs attention | `updated_at` > 12 hours ago | | Parked draft | draft + `updated_at` > 30 days ago |
Calculate hours (or days for parked drafts) since `updated_at` relative to now. Round to the nearest whole number.
Review state
Determine per-PR by reading the reviews list chronologically:
- **Approved**: at least one `APPROVED` review, no subsequent `CHANGES_REQUESTED`
- **Changes requested**: most recent non-dismissed review is `CHANGES_REQUESTED`
- **Pending**: has requested reviewers who haven't submitted a review
Show reviewer names in each state (e.g., "approved by Alice, Bob").
Report Format
# {team_name} Code Review Report: {YYYY-MM-DD}
> Generated for **{display_name}** | {n} open PRs across {m} membersSection 1: Stale PRs (>24h no action)
All open PRs across the team (including drafts) where `updated_at` > 24h. Only exclude drafts older than 30 days, those go in the
Showing the first part of this file.
Thirty-two skills that wrap around your development cycle in Claude Code. They turn tickets into ATDD plans, smoke-test features against a running app or service, hunt down bugs with runtime evidence, guard commits against doc drift, run seven-axis code
Repo: Flagrare/agent-skills
Other skills on flagrare-agent-skills.
- /atdd-plan
Produce an ATDD-first implementation plan in Claude Code's native plan mode, with named design patterns called out where they earn their keep. The skill enters plan mode automatically (via the EnterPlanMode tool), runs /flagrare:codebase-explore to ground the plan in the actual
Open skill - /brag-doc
Generate a comprehensive, impact-framed brag-doc entry for a chosen time window (day, week, biweek, month, or custom). Pulls authored PRs, reviews given, commits, deploys, and linked tickets across GitHub, local git, and configured MCPs, then synthesises a themed narrative,
Open skill - /bug-bash
Programmatic bug bashing, ingest a prescribed test plan (Notion, markdown, pasted spec), drive a real running system (browser via Chrome DevTools / Playwright MCP, backend via API tools when relevant), run every prescribed case with evidence, then do exploratory passes
Open skill - /codebase-explore
Explore the codebase to map conventions, reusable utilities, analogous features, and data flows relevant to a planned change. Returns raw findings (file paths, patterns, code snippets), does NOT produce a plan. Used by /flagrare:atdd-plan as its codebase understanding step.
Open skill - /debug-hunt
Evidence-first debugging for bugs that are hard to reproduce, intermittent, performance-related, or where previous static-analysis fixes have failed. Declares an explicit goal via /goal (the bug no longer reproduces), then loops through Hypothesis → Instrument → Reproduce →
Open skill - /design-review
Evaluate and refine UI the way a senior product designer would, visual hierarchy, spacing and rhythm, typographic scale, legibility, information density, alignment, and restraint, then apply the highest-leverage fixes. Use this skill WHENEVER the user says a UI / page / screen /
Open skill

