homebrew-packaging
Skill27 starsChanged 2 months agoMITView on GitHub
Use when preparing or maintaining Homebrew distribution for a CLI associated with a TypeScript library, including formula updates, archive naming, checksums, and release compatibility.
- Installs packages
In this repository167 other files it gives its agents.
- AGENTS.mdAGENTS.md
- src/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- add-agent-targetSkill
- add-global-mode-targetSkill
- am-agent-code-debuggerSkill
- am-agent-code-documenterSkill
- am-agent-code-refactorSkill
- am-agent-code-reviewerSkill
- am-agent-code-security-auditorSkill
- am-agent-code-standards-enforcerSkill
- am-agent-security-auditorSkill
- am-agent-test-engineerSkill
- am-agent-test-runnerSkill
- am-agent-typescript-developerSkill
- am-command-buildSkill
- am-command-code-simplifySkill
- am-command-commitSkill
- am-command-planningSkill
- am-command-planSkill
- am-command-ponytail-auditSkill
- am-command-ponytail-debtSkill
- am-command-ponytail-gainSkill
- am-command-ponytail-helpSkill
- am-command-ponytail-reviewSkill
- am-command-ponytailSkill
- am-command-reviewSkill
- am-command-shipSkill
- am-command-specSkill
- am-command-testSkill
- api-and-interface-designSkill
- browser-testing-with-devtoolsSkill
- changelog-generatorSkill
- ci-cd-and-automationSkill
- code-review-and-qualitySkill
- code-reviewerSkill
- code-simplificationSkill
- context-engineeringSkill
- debugging-and-error-recoverySkill
- deprecation-and-migrationSkill
- docs-and-examplesSkill
- documentation-and-adrsSkill
- doubt-driven-developmentSkill
- frontend-ui-engineeringSkill
- git-workflow-and-versioningSkill
- grillingSkill
- grill-meSkill
- handoffSkill
- idea-refineSkill
- incremental-implementationSkill
- interview-meSkill
- lessonsSkill
- library-testingSkill
- package-release-engineeringSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- ponytail-auditSkill
- ponytail-debtSkill
- ponytail-gainSkill
- ponytail-helpSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 12 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Ensure Homebrew installation is reproducible.
- Distinctive: line 15
Keep formula updates correct and easy to review.
- Distinctive: line 17
Avoid brew distribution when the package is not a real CLI product.
- Distinctive: line 21
Use this skill only when the project distributes an actual command-line tool or executable artifact.
- Distinctive: line 22
If the project is only an importable npm library, do not recommend Homebrew as a primary distribution channel.
- Distinctive: line 44
When generating or updating a formula:
- Distinctive: line 45
use stable release URLs
- Distinctive: line 46
update version and checksum together
- Distinctive: line 49
avoid brittle install logic when possible
- Distinctive: line 58
Document runtime requirements clearly.
- Distinctive: line 61
When assisting with brew packaging, provide:
- Distinctive: line 68
Do not overcomplicate the formula.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Purpose
Homebrew Packaging
You are responsible for Homebrew distribution of a CLI or executable package that may be implemented in TypeScript/Node.
Goals
- Ensure Homebrew installation is reproducible.
- Keep formula updates correct and easy to review.
- Align GitHub release assets with Homebrew expectations.
- Avoid brew distribution when the package is not a real CLI product.
Applicability
Use this skill only when the project distributes an actual command-line tool or executable artifact. If the project is only an importable npm library, do not recommend Homebrew as a primary distribution channel.
Packaging principles
- Homebrew is for installable tools.
- Release assets must be stable and versioned clearly.
- Checksums must match the exact published archive.
- Installation instructions must be tested on a clean macOS environment where possible.
Checklist
Verify:
- the package exposes a real CLI entry point
- GitHub release assets are versioned consistently
- archive naming is predictable
- SHA256 is computed from the final release artifact
- formula URLs match the release layout
- install step places binaries correctly
brew installandbrew testpaths are valid
Formula guidance
When generating or updating a formula:
- use stable release URLs
- update version and checksum together
- keep dependencies explicit
- include a meaningful
test doblock - avoid brittle install logic when possible
Node/TS-specific concerns
For Node-based CLIs, check whether you are distributing:
- raw source requiring Node at install/runtime
- bundled JS output
- standalone binary via a packager
Document runtime requirements clearly.
Output format
When assisting with brew packaging, provide:
- Whether Homebrew is appropriate
- Required release asset format
- Formula changes
- Validation steps
- User-facing install instructions
Do not overcomplicate the formula. Optimize for stable installs.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

