config/agents/skills/github/SKILL.md
Use when the task is primarily about GitHub operations through gh CLI, such as working with issues, pull requests, review comments, inline comments, sub-issues, or fetching PR diffs with line numbers. Do NOT use for local Git-only workflow questions that do not touch GitHub; use the git skill for those. Trigger especially when the user mentions GitHub, gh, issue, pull request, PR review, inline comment, review reply, or diff with line numbers.
npx skillsauth add kumewata/dotfiles githubInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Guide for GitHub operations using gh CLI.
For mandatory rules, see rules/git-github.md.
gh issue view NUMBER --repo OWNER/REPO --json title,body,comments
gh issue create --repo OWNER/REPO --title "Title" --body "Body"
With template:
# Check templates first
ls .github/ISSUE_TEMPLATE/
# Create with specific template
gh issue create --template "bug_report.md"
Standard gh CLI does not support sub-issues.
Use the gh sub-issue extension.
gh extension install agbiotech/gh-sub-issue
# Add sub-issue
gh sub-issue add <parent> --sub-issue-number <child>
# List sub-issues
gh sub-issue list <parent>
# Remove sub-issue
gh sub-issue remove <parent> --sub-issue-number <child>
Basic information:
gh pr view NUMBER --repo OWNER/REPO --json title,body,author,state,baseRefName,headRefName,url
Get current branch PR number:
gh pr view --json number -q '.number'
Get latest commit SHA (required for inline comments):
gh pr view NUMBER --repo OWNER/REPO --json commits --jq '.commits[-1].oid'
Diff with line numbers (for identifying inline comment positions):
gh pr diff NUMBER --repo OWNER/REPO | awk '
BEGIN { old_line=0; new_line=0; in_hunk=0 }
/^diff --git/ { in_hunk=0; print; next }
/^---/ || /^\+\+\+/ { print; next }
/^@@/ {
in_hunk=1
match($0, /-([0-9]+)/, old)
match($0, /\+([0-9]+)/, new)
old_line = old[1]
new_line = new[1]
print
next
}
in_hunk && /^-/ { printf "L%-4d | %s\n", old_line++, $0; next }
in_hunk && /^\+/ { printf " R%-4d| %s\n", new_line++, $0; next }
in_hunk { printf "L%-4d R%-4d| %s\n", old_line++, new_line++, $0; next }
{ print }
'
Output format:
L123 | - Deleted line (left side line number)R456 | - Added line (right side line number)L123 R456 | - Unchanged line (both line numbers)Issue comments (PR-wide):
gh api repos/OWNER/REPO/issues/NUMBER/comments --jq '.[] | {id, user: .user.login, created_at, body}'
Review comments (inline):
gh api repos/OWNER/REPO/pulls/NUMBER/comments --jq '.[] | {id, user: .user.login, path, line, body, in_reply_to_id}'
Get all at once:
FILE1=$(${CLAUDE_CONFIG_DIR}/scripts/touchfile.sh .i9wa4/tmp --type output)
FILE2=$(${CLAUDE_CONFIG_DIR}/scripts/touchfile.sh .i9wa4/tmp --type output)
gh api repos/OWNER/REPO/issues/NUMBER/comments > "$FILE1"
gh api repos/OWNER/REPO/pulls/NUMBER/comments > "$FILE2"
PR-wide comment:
gh pr comment NUMBER --repo OWNER/REPO --body "Comment body"
For multiple lines:
gh pr comment NUMBER --repo OWNER/REPO --body "$(cat <<'EOF'
## Review Results
- Issue 1
- Issue 2
EOF
)"
Inline comment:
# Get latest commit SHA
COMMIT_SHA=$(gh pr view NUMBER --repo OWNER/REPO --json commits --jq '.commits[-1].oid')
# Post inline comment
gh api repos/OWNER/REPO/pulls/NUMBER/comments \
--method POST \
-f body="Comment body" \
-f commit_id="$COMMIT_SHA" \
-f path="path/to/file.py" \
-F line=15 \
-f side=RIGHT
| Parameter | Description | | --------- | ----------------------------------------------- | | body | Comment body | | commit_id | Target commit SHA | | path | File path (relative from repository root) | | line | Line number (use R number from diff right side) | | side | RIGHT (added line) or LEFT (deleted line) |
Reply to comment:
gh api repos/OWNER/REPO/pulls/NUMBER/comments/COMMENT_ID/replies \
--method POST \
-f body="Reply body"
side=LEFT and left side (L) line number| Resource | Purpose | | ---------------- | ------------------------------- | | rules/git-github | Mandatory rules and permissions | | skills/git | Git-specific operations |
tools
Use when creating a new skill or making a substantial change to an existing skill and you also need to design, update, or review Waza-based executable evaluations. This includes deciding whether Waza is warranted, mapping `evals.json` cases into Waza tasks, choosing fixtures and graders, selecting a valid model with `waza models --json`, and running a local-first `waza run` workflow. Do NOT use for installing the Waza CLI itself or for general skill-authoring advice that does not involve Waza; use `skill-creator` for skill design and this skill for the Waza execution layer. Trigger especially when the user mentions Waza, `waza run`, `waza models`, executable evals, compare, graders, fixtures, or wants to validate a skill change with model-backed evaluation.
tools
Use when the user wants Codex to ask Claude Code for a second opinion or review on code, docs, diffs, PR changes, or design notes without modifying files. This delegates bounded review-only analysis through the Claude Code CLI (`claude -p`). Do NOT use for implementation or file edits; keep this skill review-only. Trigger especially when the user says ask Claude, ask Claude Code, cc-delegate, Claude review, second opinion from Claude, compare Codex and Claude, or review this diff/document with Claude Code.
tools
Airflow DAG development skill for writing, reviewing, testing, and debugging Apache Airflow workflows. Use whenever the user mentions Airflow, DAGs, tasks, operators, sensors, schedules, retries, catchup, DAG import errors, DAG parse performance, or workflow orchestration in Python. Also use for Amazon MWAA / Managed Workflows for Apache Airflow work, including MWAA DAG deployment, requirements.txt, plugins.zip, aws-mwaa-docker-images, S3 DAG folders, CloudWatch logs, and MWAA-specific dependency or IAM issues.
development
Use when the user asks for help drafting a GitHub PR description, a PR review comment, or a Slack post in their own tone (i.e., their personal writing voice). The skill detects the context (formal for PR / review, casual for Slack) and target_type (pr_description, pr_review, slack), drafts the body with an explicit reflection step that avoids verbose, mechanical phrasing, and stages the draft to `~/.local/state/tone/drafts/` via `tone-stage-draft.sh`. The user later runs `/tone-capture <url>` after posting, which pairs the staged draft with the final body to build a corpus for future tone tuning. Trigger especially when the user mentions PR description, PR review comment, Slack post, または「文を書いて」「文面を作って」「自分らしく」「トーン」「tone」.