delivery-start
Skill7 starsChanged 19 days agoMITView on GitHub
The front door to the Delivery pack: get ready to deliver client work and gate it before it ships. Trigger on "get me ready to deliver this", "help me deliver this client work", "I have client work due", "prep this delivery", "ready this for the client", "is this ready to send to the client", or any open-ended request about doing or shipping client work where the user has not picked a step. You name what you owe a client; the OS reads what it knows, then routes you to the move you need: prep the session, write the update, document the process, build the branded document, or run the ship gate before it goes out. One honest disclaimer, no full onboarding, and it never sends to the client for you. Routes to meeting-prep, client-update, sop-writer, your-deliverable-template, blind-spot-review, pre-send-check, or ship-deliverable depending on the step.
In this repository100 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- notion-package/CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- add-handsSkill
- add-mouthSkill
- add-voiceSkill
- approval-gatesSkill
- auditSkill
- backupSkill
- blind-spot-reviewSkill
- bottleneck-diagnosticSkill
- brain-logSkill
- brain-passSkill
- brain-snapshotSkill
- brand-interviewSkill
- brand-voice-interviewSkill
- business-context-loaderSkill
- campaign-from-themeSkill
- capture-sweepSkill
- catch-upSkill
- client-updateSkill
- connectSkill
- content-repurposerSkill
- content-startSkill
- context-persistenceSkill
- cross-linkSkill
- data-securitySkill
- decision-frameworkSkill
- decisions-startSkill
- email-drafterSkill
- employee-reviewSkill
- finance-importSkill
- forcing-questionsSkill
- founder-coachingSkill
- founder-next-moveSkill
- founder-os-setupSkill
- founder-reviewSkill
- founder-scope-challengeSkill
- github-opsSkill
- handoff-protocolSkill
- hireSkill
- historySkill
- housekeepingSkill
- ingestSkill
- knowledge-captureSkill
- legal-complianceSkill
- linkedin-brand-directionSkill
- linkedin-network-scanSkill
- linkedin-postSkill
- linkedin-power-auditSkill
- linkedin-startSkill
- linkedin-warm-revivalSkill
- lintSkill
- list-prunerSkill
- log-archiveSkill
- log-replySkill
- meeting-prepSkill
- memory-passSkill
- menuSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
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 30
Not sure which? Say "I have client work due, ready it" and the OS asks the one question that sorts it (are you preparing, producing, or …
- Distinctive: line 40
Before asking anything, check what the OS already knows:
- Distinctive: line 50
Before routing, say one true thing and only one:
- Distinctive: line 54
Never imply the OS contacted the client or that passing the gate makes the work correct.
- Distinctive: line 64
Follow the skill you route to for the actual run.
- Distinctive: line 72
When the routed skill finishes, frame the result as the path from owed-work to shipped-and-checked: here is the prepped session, here is …
- Distinctive: line 89
When the user already named the step ("prep my call with <client>", "write the status update", "run the ship checks") - route straight to …
≈ “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
Delivery Start
Runs on: reasoning - this skill reads what the OS knows about the client and the work, then routes you to the member skill that does the step. It does not produce the deliverable itself and it never sends anything to a client. On a read-only or cloud surface, it explains the same route without claiming a file was written.
This is the front door to delivery. You owe a client something: a session you need to be ready for, a status update, a process to hand off, a document to build, or a finished piece that needs checking before it ships. This skill reads what the OS holds, then points you at the step you actually need, and it makes sure the ship gate runs before anything leaves your machine.
The principle: do more for you than you asked, in the order a careful operator would, and never let weak work ship as if it were checked. A solo founder has no one to catch the blind spot; the OS is that check.
The steps behind one delivery
| You want | What it means | Where it routes |
| Prep the session | a brief for the client call: what to cover, what to watch for | meeting-prep |
| Write the update | a client-facing status or milestone report in your voice | client-update |
| Hand off a process | a delegation-ready SOP someone else can follow | sop-writer |
| Build the document | a branded proposal, deck, one-pager, or CV in your identity | your-deliverable-template |
| Ship it safely | the final gate before it goes to the client | ship-deliverable (runs blind-spot-review + pre-send-check) |
Not sure which? Say "I have client work due, ready it" and the OS asks the one question that sorts it (are you preparing, producing, or shipping), then routes from your answer.
Read the state before routing
The route is only as good as what it knows. Before choosing, read brain/.snapshot.md. If it is missing, or its date: line is more than 3 days old, run python scripts/brain-snapshot.py --write first and read the fresh one. The open-flags block tells you what is stuck, the must-do block tells you what this week is actually about, and the patterns block tells you what keeps happening - a front door that routes without them is a cold start at the exact moment the user is deciding whether this OS knows them. If Python is unavailable, route from the files you can read and say so.
The flow
1. Read the state first
Before asking anything, check what the OS already knows:
- Is there client history in
context/clients.md? A company file incompanies/? A brand profile for branded output (core/brand-profile.ymlorbrands/<slug>/visual.yml)? - Cold install (no client context, no brand profile): route to the step they named and note what a brand profile or client history would add later. Do not block a delivery on full onboarding.
- An OS that knows the client: prep and updates read from real history instead of a blank page. Use it.
Branch on the state you actually find. Do not assume cold.
2. One honest disclaimer
Before routing, say one true thing and only one:
I can prep, write, and check this, but I do not send it to the client, and the ship gate is a check, not a guarantee, it surfaces risk, it does not remove it. Branded documents need your brand profile to render in your identity. Tell me where this delivery is and I will aim the right step at it.
Never imply the OS contacted the client or that passing the gate makes the work correct. The gate raises what you missed; the judgment stays yours.
3. Route to the step
- Prep the session ->
meeting-prep, which builds the brief from client context and your commitments. - Write the update ->
client-update, which writes the status in your voice (setcore/voice-profile.ymlso it sounds like you). - Hand off a process ->
sop-writer, which documents the steps so someone unfamiliar can follow them to completion. - Build the document ->
your-deliverable-template, which inherits your brand colors, fonts, and logo (needs a real brand profile, not placeholders). - Ship it safely ->
ship-deliverable, the composition gate. It runsblind-spot-review(nine risk categories) andpre-send-check(seven final checks) and reports every failure in one pass. Run this before anything goes to a client.
Follow the skill you route to for the actual run. This skill hands off; it does not produce the deliverable.
4. Always offer the gate
Whatever they came to produce, before it ships, offer ship-deliverable. A solo founder is the only reviewer they have. The gate is the single most valuable habit in this pack: it catches the legal exposure, the broken cross-reference, the wrong recipient, the missing asset, before the client sees it. Make the offer every time; never force it.
5. Deliver the path, not a file dump
When the routed skill finishes, frame the result as the path from owed-work to shipped-and-checked: here is the prepped session, here is the draft, here is the gate result. Update context/clients.md and the log so the next session knows where the engagement stands.
<!-- private-tag: not applicable: delivery-start is a router. It does not capture user speech to write; the member skills it routes to (client-update, meeting-prep) own any write to context/clients.md and carry their own private-tag handling. -->6. Offer more than they asked
After delivering, name the steps they did not pick, in one line each. "You came to write the update. Before it goes out, the ship gate can catch what a second reader would. And the same client file holds your next session's prep." Invite, never gate the offer itself. If they say no, stop cleanly.
Honest positioning (say this, do not oversell)
Lead with the defensible truth: the OS preps from your real client history, writes in your voice, builds in your brand, and runs a real second-pass check before anything ships. It is the reviewer a solo operator does not have. It needs no extra service, and nothing reaches the client unless you send it.
Be honest about the limits: the ship gate surfaces risk, it does not certify the work; branded rendering needs a brand profile; and the OS does not send, schedule, or track delivery on the client's side. It readies and checks; you ship.
When NOT to use
- When the user already named the step ("prep my call with
<client>", "write the status update", "run the ship checks") - route straight to that skill; the front door is for the open-ended "I owe a client something". - To send to the client. The OS readies and gates; it does not deliver on your behalf.
Files this skill routes to
skills/meeting-prep/SKILL.md- the pre-session brief.skills/client-update/SKILL.md- a status update in your voice.skills/sop-writer/SKILL.md- a delegation-ready SOP.skills/your-deliverable-template/SKILL.md- a branded document in your identity.skills/ship-deliverable/SKILL.md- the final gate (composes blind-spot-review + pre-send-check).skills/blind-spot-review/SKILL.md- the nine-category risk pass.skills/pre-send-check/SKILL.md- the seven-check pre-send gate.skills/delivery-pack.md- the pack manifest, with the full member map.
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.

