Borrowing it
Nothing to install: this file belongs to opagani/cassini-workshop. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/opagani/cassini-workshop/main/.claude/skills/github/SKILL.mdgit clone --depth 1 https://github.com/opagani/cassini-workshopWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/opagani/cassini-workshop/github)<a href="https://agentmods.dev/skills/opagani/cassini-workshop/github"><img src="https://agentmods.dev/badge/skills/opagani/cassini-workshop/github/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/opagani/cassini-workshop/github"><img src="https://agentmods.dev/badge/skills/opagani/cassini-workshop/github.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00083 | $0.01511 |
| Opus 5.5 | $0.00033 | $0.00604 |
| Sonnet 5.5 | $0.00017 | $0.00302 |
| Haiku 4.5 | $0.00008 | $0.00151 |
Grade A, and why
github scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to github — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 212 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub workflow
The point: write commits, issues, and PRs that read clearly weeks later. Be direct, be specific, skip the filler.
Branching — when to branch, when not
Trunk-based (commit straight to main) when:
- Single-file or single-concept fix.
- Typo, doc tweak, version bump, comment, lint fix.
- Test-only addition that doesn't change behavior.
- Anything that takes one commit and reviews itself in 30 seconds.
Short-lived branch when:
- More than ~2 commits expected.
- New feature or capability, even a small one.
- Schema/migration change.
- Anything that could break
mainfor someone else. - A spec / plan task that has its own id (e.g.
T052fromdocs/PLAN.md).
Branch naming: <type>/<short-slug> — type is one of
feat, fix, chore, docs, refactor, test. Examples:
feat/order-fulfillment-tx
fix/signature-verify-header-case
chore/bump-drizzle
Keep branches short-lived. Open the PR early, even as draft.
Commits — Conventional Commits, kept honest
Format:
<type>(<optional scope>): <imperative summary, lower-case, no period>
<body — what changed and why, wrapped at ~72 cols>
<footer — refs, breaking changes>
Types: feat, fix, chore, docs, refactor, test, perf,
build, ci, revert.
Summary line rules:
- 50 chars or fewer when possible, hard cap 72.
- Imperative mood (
add, notadded/adds). - No trailing period.
- Scope is optional; use it when there's an obvious area
(
feat(webhook): …,fix(db): …).
Body rules:
- Always include one if the change isn't self-evident from the diff.
- Explain what changed and why — never restate the diff line by line. Mention trade-offs or alternatives rejected if relevant.
- One blank line between summary and body.
- Reference issues with
Refs #123orCloses #123.
Footers:
Closes #Nto auto-close an issue on merge.BREAKING CHANGE: <what breaks, how to migrate>for breakages.Co-Authored-By:lines when pairing.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 212 lines · 83 tokens per session scan A 6106a7e4b318
github is a skill published in the GitHub repository opagani/cassini-workshop (0 stars, last pushed 4mo ago), licensed MIT. It adds 83 tokens to every session and 1,511 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to github, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
git-workflow
Trunk-based git workflow with worktrees, switch/restore over checkout, Conventional Commits, force-with-lease. Use whenever the user asks me to commit, push, branch, or rebase.
papi-build
Invoke when executing a build via buildexecute. Covers branching, gestalt pre-build check, and post-build audit.
papi-auto
Continue an approved PAPI cycle through implementation, verification and review using bounded autonomy. Resume durable work without rebuilding it; propose new scope before persisting it.
git-wrapup
Land working-tree changes as logical commits — the work grouped by concern, topped by a release commit (version bump, changelog, regenerated artifacts). The work commits land first, then the version bump, verification, and the release commit on top. Stops at "committed locally on main" — or, when the project releases…
engineer-bot-ops
A workflow for carrying an engineering task from scope through implementation and reviewable delivery. It works with a repository's branch, existing changes, rules, checks, and permissions while separating completed, unverified, and next-step work.
mcore-split-pr
Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.