Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Manage a single GitHub repository via chat for non-technical requesters—after they share the repo URL and a temporary personal token, pull status, summarize who did what and when, and create/follow up on issues directly through the GitHub API.
Manage a single GitHub repository via chat for non-technical requesters—after they share the repo URL and a temporary personal token, pull status, summarize who did what and when, and create/follow up on issues directly through the GitHub API.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
Use this skill whenever a non-technical person (often over WhatsApp) needs lightweight GitHub help without cloning or forking a repo. Typical asks: "Tell me what changed recently and who did it." "Create an issue describing X." "Follow up on existing issues or PRs." The workflow relies entirely on the GitHub REST API using a personal access token (PAT) the requester provides during the chat.
Repo identifier – ask for full URL or owner/name. PAT – confirm it has repo scope (private repos) or public_repo (public). Remind them to generate a short-lived token and send it in the chat; you’ll discard it afterward. Task brief – what they need (issue, summary, follow-up) plus timeframe (e.g., "last 7 days"). Always restate the inputs back to them before acting. If anything is missing, pause and ask.
Paste the token into a temporary shell variable in the current session only: export GITHUB_TOKEN="<token-from-chat>" Never save tokens to disk or log files. When finished, run unset GITHUB_TOKEN. Every API call must set Authorization: Bearer $GITHUB_TOKEN and Accept: application/vnd.github+json.
Health check: GET /repos/{owner}/{repo} – confirms access and surfaces default branch. Recent commits (for summaries / who-did-what): GET /repos/{owner}/{repo}/commits?since=<ISO8601>&until=<ISO8601> For per-author breakdown, add author=<username> or group results locally. Issues & PRs: GET /repos/{owner}/{repo}/issues?state=all&since=<ISO8601>. Distinguish PRs via pull_request key. Record the raw JSON responses (e.g., save to /tmp/commits.json) if you need to run jq filters before summarizing.
When you need file-level context (to quote code in an issue or explain why a commit matters), walk the tree via the REST API: List directories/files: GET /repos/{owner}/{repo}/contents/<path>?ref=<branch> returns metadata plus download URLs. Fetch raw blobs: reuse the download_url or call GET /repos/{owner}/{repo}/contents/<path> with header Accept: application/vnd.github.raw. Large trees: GET /repos/{owner}/{repo}/git/trees/<sha>?recursive=1 to grab the whole structure, then request the files you care about. Cache what you read per session (e.g., store under /tmp/github-chat-ops/<repo>/...) so subsequent lookups avoid extra API calls. Always mention the file + path + relevant snippet when writing summaries or issues.
Translate activity into plain language: Group commits by contributor, then describe what actually changed (features/tests/configs) rather than just commit titles. For each commit, hit GET /repos/{owner}/{repo}/commits/{sha} to see files[] (filenames, additions/removals, patch). Extract the top 1–2 bullets per contributor: e.g., "Updated quiz_generator.py to support context prompts and added 3 YAML fixtures." Mention timestamps in the user’s timezone (Africa/Lagos unless told otherwise). Highlight status (merged, open, blocked) and outstanding follow-ups. Keep summaries short, bullet-style, and avoid jargon.
Clarify the problem, expected outcome, priority, and owners while chatting. Draft the issue body locally in Markdown (include background, repro steps, acceptance criteria). Create the issue via POST /repos/{owner}/{repo}/issues with JSON payload: { "title": "...", "body": "...", "assignees": ["username"], "labels": ["priority:high"] } Echo the created issue URL back to the user and summarize what was filed. For follow-ups, use PATCH /repos/{owner}/{repo}/issues/{number} to update state or assignees, and POST /repos/{owner}/{repo}/issues/{number}/comments for status notes.
Confirm: "I’ll need the repo URL + a temporary token with repo scope—can you share those now?" After each action, report in natural language first, then share links/details. Keep tokens out of summaries. If the user sends screenshots or sensitive info, acknowledge and avoid re-sharing it elsewhere.
Store long-lived secrets outside the skill (e.g., .env.github-chat-ops with GITHUB_CHAT_OPS_TOKEN, repo, timezone). Build reusable scripts under scripts/ (see scripts/github_chat_ops_daily.py) that load env vars, call the same APIs, and print a ready-to-send summary. When scheduling via cron, run the script from the workspace root, capture stdout verbatim for the message, and surface errors if the script exits non-zero. Let end users customize repo/timezone by editing the env file; document that in the skill release notes so downstream consumers know where to look.
Use references/github-api-cheatsheet.md for ready-made curl templates covering the endpoints above plus pagination tips.
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.