From distillery
Sync GitHub issues and pull requests into the Distillery knowledge base as searchable, linkable entries
npx claudepluginhub norrietaylor/distillery --plugin distilleryThis skill is limited to using the following tools:
<!-- Trigger phrases: gh-sync, /gh-sync, sync github, sync issues, sync prs, github sync, sync repo issues -->
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
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.