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 tranhieutt/software_development_department --skill launch-checklistgit clone --depth 1 https://github.com/tranhieutt/software_development_departmentWrote 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/tranhieutt/software_development_department/launch-checklist)<a href="https://agentmods.dev/skills/tranhieutt/software_development_department/launch-checklist"><img src="https://agentmods.dev/badge/skills/tranhieutt/software_development_department/launch-checklist/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/tranhieutt/software_development_department/launch-checklist"><img src="https://agentmods.dev/badge/skills/tranhieutt/software_development_department/launch-checklist.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.00044 | $0.01921 |
| Opus 5.5 | $0.00018 | $0.00768 |
| Sonnet 5.5 | $0.00009 | $0.00384 |
| Haiku 4.5 | $0.00004 | $0.00192 |
Grade A, and why
launch-checklist 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 — 221 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When this skill is invoked:
Explicit invocation only: This skill should only run when the user explicitly requests it with
/launch-checklist. Do not auto-invoke based on context matching.
-
Read the argument for the launch date or
dry-runmode. Dry-run mode generates the checklist without creating sign-off entries. -
Gather project context:
- Read
CLAUDE.mdfor tech stack, release surfaces, and team structure - Read the latest milestone in
production/milestones/ - Read any existing release checklist in
production/releases/ - Read any launch, support, or communications notes in
docs/launch/,docs/runbooks/, orproduction/releases/if they exist
- Read
-
Scan codebase health:
- Count
TODO,FIXME,HACKcomments and their locations - Check for any
console.log,print(), or debug output left in production code - Check for placeholder assets or copy (search for
placeholder,temp_,WIP_) - Check for hardcoded test/dev values (localhost, test credentials, debug flags)
- Count
-
Generate the launch checklist:
# Launch Checklist: [Product Title]
Target Launch: [Date or DRY RUN]
Generated: [Date]
---
## 1. Code Readiness
### Build Health
- [ ] Clean build or release artifact generated for all target surfaces
- [ ] Zero release-blocking compiler or linter errors
- [ ] All unit tests passing
- [ ] All integration tests passing
- [ ] End-to-end or smoke tests passing for critical user journeys
- [ ] Schema migrations tested with rollback or recovery plan
- [ ] Release version correctly set and tagged in source control
- [ ] Performance and reliability benchmarks within agreed targets
### Code Quality
- [ ] TODO count: [N] (zero required for launch, or documented exceptions)
- [ ] FIXME count: [N] (zero required)
- [ ] HACK count: [N] (each must have documented justification)
- [ ] No unintended debug output in production code
- [ ] No hardcoded dev/test values
- [ ] All feature flags reviewed for launch defaults
- [ ] Error handling covers all critical paths
- [ ] Crash reporting and structured logging integrated and verified
- [ ] Dependency vulnerabilities triaged and accepted risk documented
### Security and Privacy
- [ ] No exposed API keys or credentials in source or build artifacts
- [ ] Authentication, authorization, and input validation verified on public endpoints
- [ ] Network communication secured (TLS, signed webhooks, secret rotation as applicable)
- [ ] Abuse protection, rate limiting, or bot controls enabled where required
- [ ] Privacy policy and data handling compliance verified
- [ ] Backup and restore path validated for stateful systems
---
## 2. Product Readiness
### Functional Scope
- [ ] All launch-scope features implemented or explicitly deferred
- [ ] Critical user journeys tested end-to-end
- [ ] Admin, support, and internal operational workflows verified
- [ ] Billing, notifications, integrations, and webhooks tested if applicable
- [ ] Data import/export, retention, or deletion flows verified if applicable
- [ ] Release notes and known issues drafted
### UX, Content, and Localization
- [ ] All placeholder copy and visuals replaced
- [ ] All user-facing text proofread
- [ ] No hardcoded strings (all externalized for localization)
- [ ] All supported languages translated and verified
- [ ] Text fits UI in all supported languages
- [ ] Help content, onboarding, and empty states reviewed
- [ ] Customer-facing documentation links are current
---
## 3. Quality Assurance
### Testing
- [ ] Full regression test suite passed
- [ ] Zero Sev1 (Critical) bugs open
- [ ] Zero Sev2 (High/Major) bugs open, or documented exceptions with owner approval
- [ ] Smoke test passed in staging or release candidate environment
- [ ] User acceptance or stakeholder sign-off captured
- [ ] Edge cases tested (no network, expired session, low storage, rate limits, retries)
- [ ] Backup/restore or disaster recovery drill completed if applicable
### Accessibility and Compliance
- [ ] Accessibility basics covered for target surfaces
- [ ] Consent, privacy, and legal notices reviewed
- [ ] Audit logging or regulated workflow checks verified if required
- [ ] App store or platform policy requirements met, if applicable
### Performance and Reliability
- [ ] Response time or startup time within budget
- [ ] Memory and CPU usage within budget
- [ ] Queue lag, background jobs, and async workflows within targets
- [ ] No sustained error-rate spikes during release candidate soak window
- [ ] Capacity and scaling assumptions reviewed for launch traffic
---
## 4. Distribution and Customer-Facing Assets
### Release Assets
- [ ] Changelog complete and proofread
- [ ] Release notes complete and customer-appropriate
- [ ] Version numbers aligned across app, API, docs, and packaging
- [ ] Download links, package names, or deployment targets finalized
### Launch Communications
- [ ] Status page messaging prepared
- [ ] Customer announcement drafted
- [ ] In-app banner, modal, or changelog entry prepared if needed
- [ ] Support macros / FAQ updated
- [ ] Sales, customer success, and internal stakeholders briefed
### Public Metadata
- [ ] Marketing site or product page copy updated
- [ ] Screenshots or release visuals current
- [ ] Pricing, packaging, and plan entitlements verified
- [ ] App store listing metadata current, if applicable
---
## 5. Infrastructure
### Production Readiness
- [ ] Production infrastructure provisioned and sized for launch
- [ ] Database backups configured and restore tested
- [ ] CDN, cache invalidation, and asset delivery configured where applicable
- [ ] Feature flag rollout strategy documented
- [ ] Secrets and access reviews completed
- [ ] Deployment and rollback runbooks current
### Analytics and Monitoring
- [ ] Analytics pipeline verified and receiving expected events
- [ ] Crash reporting active and dashboard accessible
- [ ] Monitoring dashboards live for core technical and business metrics
- [ ] Alerts configured for critical thresholds
- [ ] Incident escalation path and owners documented
---
## 6. Support and Operations
### Team Readiness
- [ ] On-call schedule set for first 72 hours post-launch
- [ ] Incident response playbook reviewed by the team
- [ ] Hotfix pipeline tested
- [ ] Communication plan for launch issues documented
- [ ] Support team briefed on known issues and escalation path
### Launch Day Plan
- [ ] Go-live sequence documented step by step
- [ ] Rollback decision criteria documented
- [ ] War room or launch channel established
- [ ] Launch monitoring dashboard bookmarked by all leads
- [ ] Checkpoint times defined for launch-day review
---
## Go / No-Go Decision
**Overall Status**: [READY / NOT READY / CONDITIONAL]
### Blocking Items
[List any items that must be resolved before launch]
### Conditional Items
[List items that have documented workarounds or accepted risk]
### Sign-Offs Required
- [ ] Product Owner - Scope and customer readiness
- [ ] Engineering Lead - Technical health and stability
- [ ] QA Lead - Quality and test coverage
- [ ] Release Manager - Deployment and rollback readiness
- [ ] Security / Compliance Owner - Security and data handling
- [ ] Support Lead - Support and incident readiness
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 · 221 lines · 44 tokens per session scan A 72545ee6605a
launch-checklist is a skill published in the GitHub repository tranhieutt/software_development_department (74 stars, last pushed 5mo ago), licensed MIT. It adds 44 tokens to every session and 1,921 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
triage
Apply a formal state machine to issues — assign category (bug/enhancement/question/spike) and state (needs-triage → needs-info → ready-for-agent → ready-for-human → wontfix). Issues marked ready-for-agent become inputs to supergraph:plan. Use when processing a backlog, reviewing new issues, or preparing work for…
pudo-handoff
Write the PUDO session handoff (.pudo/session.md) so another session, tool or teammate can continue the work. Use when the user says "handoff", "save progress", "/pudo-handoff", before ending long work, or when switching tools.
task-code
A two-phase workflow for breaking coding work into tracked subtasks and progress records. It applies rules from the project's CLAUDE.md file, which is a set of instructions for the coding assistant.
cm-sprint-bus
Use to run the full sprint pipeline: brainstorm → plan → design → tdd → build → review → qa → security → ship → monitor → retro.
adopt
Take a folder that already holds research — papers, notes, code, half-written drafts — into MAGI, without breaking what is already there.
customer-onboarding-and-implementation
Takes a new customer from signature to working — setting a definition of live that both sides agreed before the contract was signed, planning and staffing the implementation, running data migration and integration realistically, training the people who will actually use it, and handing over to the ongoing…