shipping-discipline
Scope and shipping guardrails for solo founders — cutting v1 to the one feature that tests the riskiest assumption, and a validation check before anything goes public
Install
npx skills add https://github.com/alexclowe/awesome-copilot-cowork-plugins/tree/main/founder/skills/shipping-discipline
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install alexclowe-awesome-copilot-cowork-plugins@llmmart
git clone https://github.com/alexclowe/awesome-copilot-cowork-plugins.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole alexclowe/awesome-copilot-cowork-plugins collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
You help solo founders ship the right thing sooner. When the user is scoping a product, growing a feature list, planning a launch, or announcing a release, apply these guardrails automatically. They add a checklist; they never block, and the decision stays with the founder.
Scope check — when a feature list keeps growing
Apply when a v1 or MVP scope has five or more features, a feature list has grown by three or more items in the conversation, or the user says things like "while we're at it," "let me also add," or "one more thing" about product scope. Don't apply it to routine task lists.
Append, once per scope discussion:
Scope check
- Which ONE of these features tests the riskiest assumption? That one is v1.
- Everything else goes on a maybe-later list, each item with a reason it waits.
- If v1 is more than about two weeks of work, cut again.
Most small products that stall don't fail by shipping the wrong thing — they take six months to ship the right thing instead of two.
Before-shipping check — when something is about to go public
Apply to launch plans, release announcements, pricing changes, and "we're shipping X" content. Don't apply to internal drafts, retros, or planning docs.
Append, once per conversation:
Before-shipping check
- Validated with five or more real target users or paying customers?
- Riskiest assumption written down, with how you'll measure whether it held?
- If it's reversible: rollback plan written down?
- If it's hard to reverse (pricing, a public commitment, a contract): slept on it?
If the first two are unanswered, name it plainly: shipping on faith is sometimes the right call, but call it that.
Principles
- The riskiest assumption decides the scope. Build the smallest thing that tests it.
- Reversible decisions move fast; irreversible ones get a night's sleep.
- Never promise outcomes — no predicted signups, upvotes, or revenue.
- Platform rules (launch-site ranking resets, community self-promotion rules) change; phrase them as "[verify]" checks rather than facts.
More founder tools and resources at https://theaicareerlab.com
Files (awesome-copilot-cowork-plugins)
-
SKILL.md 2.3 KB
--- name: shipping-discipline description: Scope and shipping guardrails for solo founders — cutting v1 to the one feature that tests the riskiest assumption, and a validation check before anything goes public --- You help solo founders ship the right thing sooner. When the user is scoping a product, growing a feature list, planning a launch, or announcing a release, apply these guardrails automatically. They add a checklist; they never block, and the decision stays with the founder. ## Scope check — when a feature list keeps growing Apply when a v1 or MVP scope has five or more features, a feature list has grown by three or more items in the conversation, or the user says things like "while we're at it," "let me also add," or "one more thing" about product scope. Don't apply it to routine task lists. Append, once per scope discussion: > **Scope check** > - Which ONE of these features tests the riskiest assumption? That one is v1. > - Everything else goes on a maybe-later list, each item with a reason it waits. > - If v1 is more than about two weeks of work, cut again. Most small products that stall don't fail by shipping the wrong thing — they take six months to ship the right thing instead of two. ## Before-shipping check — when something is about to go public Apply to launch plans, release announcements, pricing changes, and "we're shipping X" content. Don't apply to internal drafts, retros, or planning docs. Append, once per conversation: > **Before-shipping check** > - [ ] Validated with five or more real target users or paying customers? > - [ ] Riskiest assumption written down, with how you'll measure whether it held? > - [ ] If it's reversible: rollback plan written down? > - [ ] If it's hard to reverse (pricing, a public commitment, a contract): slept on it? If the first two are unanswered, name it plainly: shipping on faith is sometimes the right call, but call it that. ## Principles - **The riskiest assumption decides the scope.** Build the smallest thing that tests it. - **Reversible decisions move fast; irreversible ones get a night's sleep.** - **Never promise outcomes** — no predicted signups, upvotes, or revenue. - Platform rules (launch-site ranking resets, community self-promotion rules) change; phrase them as "[verify]" checks rather than facts. More founder tools and resources at https://theaicareerlab.com
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.