Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add smallnest/goal-workflow --skill ship-itgit clone --depth 1 https://github.com/smallnest/goal-workflowWrote 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/smallnest/goal-workflow/ship-it)<a href="https://agentmods.dev/skills/smallnest/goal-workflow/ship-it"><img src="https://agentmods.dev/badge/skills/smallnest/goal-workflow/ship-it/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/smallnest/goal-workflow/ship-it"><img src="https://agentmods.dev/badge/skills/smallnest/goal-workflow/ship-it.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk pass
- NVIDIA SkillSpector pass
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.00096 | $0.01868 |
| Opus 5.5 | $0.00038 | $0.00747 |
| Sonnet 5.5 | $0.00019 | $0.00374 |
| Haiku 4.5 | $0.00010 | $0.00187 |
Grade A, and why
ship-it 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 1mo 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.
How it starts
The opening of the file, as written. The whole thing — 225 lines — stays where its author put it; the contents beside it link to each section on GitHub.
After-Goal: 代码提交、PR 合入、Issue 关闭工作流(GitHub)
完成 GitHub Issue 实现后的标准收尾流程:提交代码 → 推送分支 → 创建 PR → 合入 → 关闭 Issue。
前置条件
- 当前 git 仓库有已实现的代码变更
- 已知 Issue 编号(如
#42) - gh CLI 已登录(
gh auth status可验证)
工作流
Step 1: 提交代码
# 1a. 检查变更状态
git status
git diff --stat HEAD
# 1b. 暂存本次 Issue 相关的文件(不要 add 不相关的文件)
git add <files related to this issue>
# 1c. 提交,commit message 关联 Issue
git commit -m "$(cat <<'EOF'
{简要描述} (#issue-number)
{可选的详细说明}
EOF
)"
关键规则:
- commit message 中包含
#issue-number以关联 Issue - 只暂存当前 Issue 相关的文件,不要混入其他变更
Step 2: 推送分支
# 如果还在 main/master 上,先创建功能分支
git checkout -b {branch-name} # 如已在功能分支则跳过
# 推送到远程
git push -u origin {branch-name}
分支命名建议:feat/issue-42-short-desc 或 fix/issue-42-short-desc
Step 3: 创建 PR
gh pr create \
--title "{简要描述}" \
--body "$(cat <<'EOF'
## Summary
- 实现内容概述
Closes #{issue-number}
## Test plan
- [ ] 测试项 1
- [ ] 测试项 2
EOF
)"
关键规则:
- PR body 中写
Closes #N或Fixes #N,合入后 GitHub 自动关闭 Issue - title 简洁,不超过 70 字符
Step 4: 合入 PR
# 4a. 查看 PR 状态(确认 checks 通过)
gh pr checks
# 4b. 合入(默认 merge commit,可选 --squash 或 --rebase)
gh pr merge --squash --delete-branch
参数说明:
--squash: 压缩为单个 commit 合入(推荐)--rebase: rebase 合入--merge: 普通 merge commit--delete-branch: 合入后删除远程分支
Step 5: 添加实现总结评论
PR 合入 / Issue 关闭时,始终在 Issue 上添加实现总结评论,方便后续直接从 Issue 回溯设计决策与代码变更。
参考 note-it 的四类结构组织总结内容:Design Decisions(设计决策)、Deviations(偏离)、Tradeoffs(权衡)、Open Questions(待确认)。某一类无内容时写 None 并简要说明。
gh issue comment {issue-number} --body "$(cat <<'EOF'
## 实现总结
**核心变更**
- {从 PR body Summary 提取的实现摘要,3-5 条 bullet}
**实现亮点(Highlights)**
- {值得强调的技术亮点:性能优化、优雅设计、复用抽象、关键测试覆盖等},或 None
**设计决策(Design Decisions)**
- {spec 模糊/未定处所做的选择及理由},或 None
**偏离(Deviations)**
- {有意偏离 spec 之处:spec 怎么说 → 实际怎么做 → 为什么},或 None
**权衡(Tradeoffs)**
- {考虑过的备选方案及最终选择的原因},或 None
**待确认(Open Questions)**
- {需用户确认的假设或后续跟进项},或 None
---
- **PR**: #{pr-number}
- **Commit**: {hash}
EOF
)"
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.
- 1mo ago First seen · 225 lines · 96 tokens per session scan A 559d9ec4552f
ship-it is a skill published in the GitHub repository smallnest/goal-workflow (293 stars, last pushed 1mo ago), licensed MIT. It adds 96 tokens to every session and 1,868 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
verification-gate
You MUST use this when work is about to be called complete, done, fixed, ready, or mergeable - before a completion claim, a merge or pull request, a branch finish, or a handoff report.
review-request
You MUST use this when a completed or partially committed implementation needs an independent code review against explicit requirements, a defined task scope, and the actual Git diff, including committed and working-tree changes.
commit-all
You MUST use this when the user asks to commit all current changes at once, via /commit-all or in words ("commit everything", "commit all changes"), without giving a commit message of their own.
development-workflow
Detailed development workflow with modular patterns for git, review, testing, and deployment.
branch-finish
You MUST use this when verified development work is ready for an integration or handoff decision - merging, pushing, opening a pull request, preserving or discarding a branch, or cleaning up its workspace. Covers safe completion choices based on the actual Git state and verification evidence.
git-worktree-isolation
You MUST use this when deciding whether development work needs workspace isolation - before implementing plans, risky multi-file changes, parallel agent work, or clean-environment bug reproduction. Covers safe work in place, existing workspaces, and Git worktrees.