بنقرة واحدة
gh-sync
Sync GitHub issues and pull requests into the Distillery knowledge base as searchable, linkable entries
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Sync GitHub issues and pull requests into the Distillery knowledge base as searchable, linkable entries
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Onboarding wizard — verify MCP connectivity, detect transport, and configure scheduled tasks via Claude Code routines
Synthesize multiple knowledge entries into a cohesive narrative with citations
Contrast internal implementation knowledge against ambient intelligence, find where they meet, and emit a directional assessment (ahead / exposed / decide / confirm)
Generate an ambient intelligence digest from recent feed activity with source suggestions
Produce a knowledge dashboard with recent entries, corrections, expiring soon, stale knowledge, and unresolved items. In team mode, also shows team activity, related entries from teammates, and the review queue.
Compile deep context on a topic by combining semantic search with relationship traversal across 4 retrieval phases
| name | gh-sync |
| description | Sync GitHub issues and pull requests into the Distillery knowledge base as searchable, linkable entries |
| allowed-tools | ["mcp__*__distillery_status","mcp__*__distillery_gh_sync","mcp__*__distillery_sync_status"] |
| context | fork |
| effort | low |
gh-sync dispatches a background GitHub sync to the Distillery MCP server. The server fetches issues and pull requests, stores them as github entries, dedupes, and wires cross-reference relations. The skill itself returns immediately with a job_id; status is checked on demand.
/gh-sync owner/repo)/gh-sync status [job_id])See CONVENTIONS.md — skip if already confirmed this conversation.
Detect the flow from the first argument:
| First token | Flow | Next steps |
|---|---|---|
status | Status (all) if no second token → Step 4 | |
status <job_id> or status <source_url> | Status (one) → Step 4 | |
| anything else | Start sync → Step 3 (treat as owner/repo or GitHub URL) |
For the start flow, validate owner/repo or full GitHub URL. If invalid, report:
Error: Invalid repository format. Expected "owner/repo" or "https://github.com/owner/repo".
and stop. If no argument at all, ask:
Which GitHub repository would you like to sync? (e.g.,
owner/repoorhttps://github.com/owner/repo)
Determine author and project per CONVENTIONS.md. Accept an optional --project <name> flag to override the git-derived project.
Flags --issues, --prs, --since, --limit are not currently passed through — the backend tool does not accept them. If the user supplies any of these flags, do not silently start an unfiltered sync. Stop and ask the user for explicit confirmation, e.g.:
The
--issues/--prs/--since/--limitflags are not yet supported by the backend. Running this will trigger a full, unfiltered sync of all issues and PRs. Proceed anyway? (yes / no)
Only start the sync if the user confirms with yes. Otherwise abort without calling distillery_gh_sync.
Call the server tool in background mode:
distillery_gh_sync(
url="<owner/repo or URL>",
author="<author>",
project="<project>", # omit if unset
background=true,
)
Read sync_job.job_id from the response. Report:
Started gh-sync job <job_id> for <owner/repo>.
Running in the background — ask "how's the sync" or run `/gh-sync status <job_id>` to check.
Stop. Do NOT poll distillery_sync_status in this turn — the point of the async path is to return fast.
Two sub-flows:
4a. Single job (status <id> or status <url>):
distillery_sync_status(job_id="<id>") # if looks like a UUID
# or
distillery_sync_status(source_url="<url>")
Render the response as a one-liner:
<job_id> (<source_url>): <status> — <entries_created> new, <entries_updated> updated, <pages_processed> pages. <elapsed>
If error_message is set, surface it verbatim on a second line and suggest re-running.
4b. All recent jobs (status alone):
distillery_sync_status()
Render as a table of the top 5 rows sorted by created_at desc:
| job_id (short) | source_url | status | new | updated | created_at |
|---|
Start flow:
gh-sync: <owner/repo>
Started job <job_id> in background.
Check with: /gh-sync status <job_id>
Status (single):
<job_id> (<owner/repo>): <status>
<entries_created> new, <entries_updated> updated, <pages_processed> pages
[if errors]: <error_message>
Status (list): Markdown table as above.
distillery_gh_sync and distillery_sync_status. Do NOT hand-roll fetch/dedup/store — the server does it.background=true on distillery_gh_sync. Never call it synchronously.distillery_sync_status in a loop within one skill turn. If the user wants to "wait", tell them to re-run /gh-sync status <id> after a minute.distillery_gh_sync error: surface the error verbatim and STOP. No retries.owner/repo argument is required for the start flow — ask if not provided.--issues, --prs, --since, --limit are not currently supported by the backend tool. Warn the user if supplied.--project to the project= parameter when provided; otherwise use the git-derived project from CONVENTIONS.md.GITHUB_TOKEN is read from environment by the backend adapter — not handled by the skill.