schmug
UserDaily-digest podcast skill — turns a list of saved articles into a fully-produced Spotify episode using Qwen3-TTS, on top of the save-to-spotify CLI.
Categories
Indexed Skills (27)
daily-podcast
Use when the user asks to ship a daily digest podcast — turns a list of saved items (URLs / articles) into a fully-produced episode using Qwen3-TTS, a deterministic script template, and publishes it to the show's public RSS feed. Skips the standard production interview because defaults are pre-set.
frontier-commits
Use when the user asks to ship the Frontier Commits weekly podcast — turns the frontier labs' GitHub org activity (new repos, releases, archivals, star trends) into a speculation-forward episode published to the public RSS feed via the daily snapshot store and render.py. Skips the standard production interview because defaults are pre-set.
surface-tension
Use when the user asks to ship the Surface Tension weekly podcast — turns personal independent blog posts surfaced by community vote on bubbles.town into a four-voice call-in radio episode published to its own public RSS feed via st_gather / st_script_plan / st_write and render.py. Skips the standard production interview because defaults are pre-set.
tts-eval
Use when the user asks to evaluate, bench, or compare a TTS model or engine for the shows — renders a fixed corpus through render.py's engine registry on the candidate engine and on the production engine as a re-rendered control, measures a fixed metric set, appends a dated ledger entry and writes one self-contained HTML report with side-by-side players. Not a show; nothing here ships audio.
ask-board
Post a durable unknown to the cross-session agent question board, or answer an open one. Use when you hit something you genuinely cannot resolve and a later session in different context might — "I don't know and can't find out", "park this question for another agent", "answer the board". The board is Q&A discussions in schmug/agent-notes; open questions are injected into every session by this plugin's SessionStart hook, and answers get promoted to memory. Not for questions only the user can answer (ask in chat, now) or ones a grep or command would settle (investigate instead). Not a Workflow wrapper; this is a process skill.
critic-gated-build
Autonomous greenfield build loop gated by an independent third-party LLM critic. Use when the user wants a project (or major feature) built end-to-end with minimal supervision and an objective ship bar — "build this and tell me when it's actually done" — via spec → TDD PR loop → deploy → fresh-context critic scoring a fixed rubric, until every category ≥8 on two consecutive cycles. Not a Workflow wrapper; this is a session-long process skill.
factory-land
The software factory's gated landing step — gather ONE PR, its linked issue, the required-check rollup, and the repo's gate config (read from the BASE ref, never the PR), run the deterministic model-free merge gate, post the verdict table as an audit comment, and squash-merge only when all nine fail-closed conditions pass. Stages by default and writes nothing; execute:true is the explicit approval that merges. Use when a factory PR has been trust-tagged fix-verified and you want the deterministic gate to decide whether it may land unattended; for an ordinary (non-factory) PR use merge-pr-with-gate, and for a chain of stacked PRs use stacked-merge-walk.
file-concerns
File this session's unresolved concerns to schmug/agent-notes. Use when the Stop hook blocks and asks for concerns to be recorded, or when you are wrapping up and something is unresolved — a completion claim you never actually verified, a scope cut you did not state plainly, a question that never got answered, a doubt about whether the change is right. There is no bar; if it nagged, it counts. Not for durable technical unknowns a later session could answer (use ask-board) and not for friction with the tooling itself (use the vent tool). Not a Workflow wrapper; this is a process skill.
parallel-build-orchestrator
Drive a multi-node build across parallel git worktrees behind an adversarial review gate. Use this whenever the user hands over an epic, a batch of issues, or any multi-part build and wants it orchestrated end-to-end — "build these five issues in parallel", "orchestrate this epic", "fan this out and review before merging", "run a parallel build" — even if they never say "orchestrator". Plans a task DAG (scope, files touched, exact verification command, dependencies), serializes file-overlapping nodes and parallelizes the rest, delegates fan-out to stacked-impl-lanes and landing to stacked-merge-walk, and accepts no node until a reviewer that did NOT write the code has re-run the commands itself. Not a Workflow wrapper; this is a session-long process skill.
pr-workflow
Use when creating PRs, finishing features, or preparing code for merge. Use after local work is complete and ready for review/deployment. Not a Workflow wrapper; this is a session-long process skill.
ship
Use when a feature branch is ready to become a pull request and land — before opening the PR, when the user says "ship it", or when work is done and needs the pre-PR gates (tests, lint, typecheck, spec re-read) run in order. Not a Workflow wrapper; this is a session-long process skill.
merge-pr-with-gate
Gates ONE pull request and squash-merges it only if green (mergeStateStatus + required-check rollup, UNKNOWN=must-verify) — a standalone single-PR slice of stacked-merge-walk's landing gate with no stacking/rebasing. Stages by default; execute:true records the caller's gate decision to merge (gated-autonomous — agent-decided when the deterministic gate passes). Use when you want to land ONE already-green, non-factory PR through the same gate stacked-merge-walk uses, without any stacking or rebasing; for a chain of stacked PRs use stacked-merge-walk, and for a factory-produced PR use factory-land.
pr-review-fanout
Read-only deep review of ONE PR diff — fan out review dimensions, adversarially verify each finding (a skeptic tries to refute it, and refuted or low-confidence findings are dropped), and emit one deduped HTML+markdown review traced to file:line. Reviews and reports only — never comments, never merges. Use when you want a specific PR actually read rather than classified — review PR 412, what is wrong with this diff, is this change safe to land. Not for sorting your whole PR queue by mergeability (use pr-triage-fanout, whose COMMENT verdict this sits behind), not for a security-focused pass over a change (use security-diff-scan), and not for merging (use merge-pr-with-gate).
routine-anti-noise
Read-only skip/anti-duplicate GATE the fleet routines run FIRST on ONE PR or issue → { skip, reason, duplicateComment }. Skips human-flagged/paused/resolved targets and avoids re-posting a comment already left. Never comments/labels/merges. Use before a fleet routine triages, reviews, or comments on a target, so it leaves alone anything a human has flagged, paused, or already resolved. Not for judging a PR or issue on its merits (use pr-triage-fanout or issue-triage-fanout), not for reviewing a diff (use pr-review-fanout), and not for posting the comment it clears — acting on the decision is always the caller's job.
factory-issue-fix
The software factory engine — turn ONE GitHub issue into a reproduced, diagnosed, independently-verified, fixed DRAFT PR. Reproduce (a bug that will not reproduce is never fixed) → Diagnose (root cause + narrowest boundary) → Verify (an INDEPENDENT model family decides real bug vs intended behaviour) → Fix (worktree-isolated, fixture-first, draft PR only). Self-bootstraps from the factory queue when given no issue; never merges and never pushes main. Use when you want one bug driven from unverified report to reviewable draft PR unattended — run the factory on this, fix this issue end to end. Not for choosing which issues to fix (use issue-triage-fanout), not for a straightforward already-diagnosed issue (use implement-issue, or stacked-impl-lanes for a wave of them), and not for landing the PR it produces (use factory-land).
stacked-impl-lanes
Implements issue-lanes into review-only PRs (parallel if file-disjoint, sequential + stacked if hub-coupled); security-hardening review on invariant lanes. Use when triage has produced a set of buildable issues and you want them implemented as one reviewable chain rather than one at a time — build this wave, implement these lanes. Not for deciding what to build (use issue-triage-fanout, then issue-research-fanout on its RESEARCH bucket), not for a single issue (use implement-issue, or factory-issue-fix for an unreproduced bug), and not for landing the stack it opens (use stacked-merge-walk).
deep-security-scan
Higher-recall security audit of a whole repo or a scoped path — prefilter + K threat-model-lensed workers → disprove-first validation → one HTML+markdown report. Use to audit a codebase/path for vulnerabilities (not a diff/PR).
defense-scan
Defense-in-depth security orchestrator — composes deep-security-scan with opt-in supply-chain / DAST / LLM-red-team / network / governance layers into one merged report with a per-layer coverage statement. Use when one static pass is not enough and you want layered or dynamic coverage plus an explicit statement of what was NOT covered — audit this the way an attacker would, check the supply chain and the running service too. Not for a plain whole-repo or scoped-path audit (use deep-security-scan, which this composes), not for reviewing a change or PR (use security-diff-scan), and not for triaging findings you already have (use triage-finding).
dependabot
Front door for GitHub Dependabot alerts. A read-only agent fetches a repo's open Dependabot alerts via `gh api`, the workflow normalizes each into a triage-finding descriptor (id, manifest, package/version-range, CWE, severity, first-patched, runtime-vs-dev scope), and the array is delegated to the `triage-finding` engine for disprove-first triage against THIS repo + a `/ghsa`- (public) or `/issue`-ready handoff payload. Intake only — it adds no triage logic and never files. Use whenever the user wants to triage, review, or act on Dependabot alerts / vulnerable dependencies / dependency vulnerabilities; not for bumping a version (use fix-finding) or filing (use track-findings).
fix-finding
Minimally remediate ONE confirmed security finding — or prove it is already fixed. Read-only reachability triage first, then a failing regression test, the smallest behavior-preserving fix, and an adversarial control-not-weakened review; opens a draft PR and never pushes to main. Use once triage has confirmed a finding is really exploitable here and you want the narrowest safe patch — fix this vulnerability, patch this CVE in our code, bump this vulnerable dependency. Not for deciding whether a finding is actionable in the first place (use triage-finding, or dependabot for alert intake), not for discovering findings (use deep-security-scan or security-diff-scan), and not for filing them (use track-findings).
issue-research-fanout
Web-enabled fan-out over the RESEARCH bucket — one agent per issue investigates (codebase + gh + web) and returns GREEN/DECISION/BLOCKED/STILL_RESEARCH, aiming to move each issue to GREEN with an implementable spec and a lane-shaped handoff. Read-only on GitHub. Use after issue-triage-fanout has bucketed the backlog and you want its RESEARCH issues resolved into buildable ones — work out what this issue actually needs, unblock the research pile. Not for classifying the backlog in the first place (use issue-triage-fanout, which produces the numbers this takes) and not for implementing the result (use stacked-impl-lanes).
issue-triage-fanout
Read-only fan-out triage of open GitHub issues → GREEN/DECISION/RESEARCH/DONE/BLOCKED with grouping + dependencies, synthesized into a dependency-ordered roadmap. Auto-gathers all open issues when none are given. Use when you want the whole open-issue backlog sorted into what is buildable now, what needs a human decision, and what is already done — triage my issues, what should I work on next, is this backlog stale. Not for investigating one unresolved issue in depth (use issue-research-fanout, which consumes the RESEARCH bucket this produces), not for triaging PRs (use pr-triage-fanout), and not for implementing the result (use stacked-impl-lanes).
pr-triage-fanout
Read-only fan-out triage of your open PRs → MERGE/CLOSE/REBASE/FIX_CI/COMMENT/AWAITING_HUMAN/ESCALATE with CI verdict + mergeability. Auto-gathers all your open PRs when none are given (bots and other authors excluded). Use when you want everything you have in flight sorted into what can land, what needs a rebase or a CI fix, and what is waiting on a human — triage my PRs, what is mergeable, why is this one stuck. Not for reading one PR diff in depth (use pr-review-fanout, which sits behind this skill COMMENT verdict), not for triaging issues (use issue-triage-fanout), and not for landing anything (use merge-pr-with-gate or stacked-merge-walk).
security-diff-scan
Change-scoped security review of a git diff / PR / working tree → one HTML+markdown report with a coverage statement. Use to review a change for security regressions (not a whole-repo audit). Also covers CI/CD pipeline abuse — workflow injection, secret exfiltration, self-hosted runner abuse, pwn requests, cache poisoning, permission widening — when the change touches `.github/workflows`, GitLab CI, Azure pipelines, or other build/release automation.
stacked-merge-walk
Lands a chain of stacked PRs onto a moving base (base-first, gate-verified, rebase-own-commits, escalate real conflicts). The terminal write step of the dev-lifecycle pipeline. Use after stacked-impl-lanes has opened a chain of stacked PRs and you want to land the whole stack in order; for a single ordinary PR use merge-pr-with-gate, and for a factory-produced PR use factory-land.
track-findings
Deduped, preview-gated bridge that files a scan bundle's confirmed findings into a tracker — by-fingerprint create/reuse/skip, exact payload preview, draft-GHSA (public) vs security-issue (private) routing, serial file + readback. Stage-by-default; pass execute=true to actually file. Use after a scan to turn its findings into tracked work without re-filing duplicates. Not for producing findings in the first place (use deep-security-scan or security-diff-scan), not for deciding whether an external finding is actionable here (use triage-finding), and not for fixing one (use fix-finding).
triage-finding
Triage external findings (a SARIF file, a scanner report, a CVE/GHSA reference, or a list of finding descriptors) against the CURRENT repo into confirmed | not_actionable | needs_review — each with an exploitability rank + evidence, disprove-first and trace-only. Confirmed items yield a /ghsa- (public) or /issue-ready handoff payload. Use to burn down a security-finding backlog; not for triaging your own PRs/issues (use pr-/issue-triage-fanout) or authoring detection rules.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.