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…
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.
/daily-code-reviewContext 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",
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.
> **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.
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.
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."
Check for config files matching `~/.claude/skills/flagrare/daily-code-review/teams/*.json`. If none exist, run the first-time setup flow.
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.
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.
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.
Use **only** these GitHub API endpoints. The comments API is noisy and `mergeable_state` is unreliable, skip both. Staleness comes from `updated_at` alone.
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.
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.
| 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.
Determine per-PR by reading the reviews list chronologically:
Show reviewer names in each state (e.g., "approved by Alice, Bob").
# {team_name} Code Review Report: {YYYY-MM-DD}
> Generated for **{display_name}** | {n} open PRs across {m} membersAll open PRs across the team (including drafts) where `updated_at` > 24h. Only exclude drafts older than 30 days, those go in the
Thirty-three 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
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…
Generate a comprehensive, impact-framed brag-doc entry for a chosen time window (day, week, biweek, month, or custom). Pulls authored PRs, reviews given,…
Programmatic bug bashing, ingest a prescribed test plan (Notion, markdown, pasted spec), drive a real running system (browser via Chrome DevTools / Playwright…
Explore the codebase to map conventions, reusable utilities, analogous features, and data flows relevant to a planned change. Returns raw findings (file paths,…
Evidence-first debugging for bugs that are hard to reproduce, intermittent, performance-related, or where previous static-analysis fixes have failed. Declares…
Evaluate and refine UI the way a senior product designer would, visual hierarchy, spacing and rhythm, typographic scale, legibility, information density,…