daily-chief
Run the user-invoked Daily Chief Plan today workflow with device login, a local preview, and explicit confirmation before remote…
The step-back skill for pitching as a person - given an audience (hackathon judges, VCs, investors, customers) and a time slot, it budgets the slot, decides what to build or reuse (deck, demo video, live speech), settles the voice, music, branding and rights questions before
$ npx -y skills add ooiyeefei/ccc --skill pitch-package --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/pitch-packageContext preview
The summary Claude sees to decide when to auto-load this skill.
The step-back skill for pitching as a person - given an audience (hackathon judges, VCs, investors, customers) and a time slot, it budgets the slot, decides what to build or reuse (deck, demo video, live speech), settles the voice, music, branding and rights questions before
name: pitch-package description: The step-back skill for pitching as a person - given an audience (hackathon judges, VCs, investors, customers) and a time slot, it budgets the slot, decides what to build or reuse (deck, demo video, live speech), settles the voice, music, branding and rights questions before anything is built, and orchestrates the pitch-deck, demo-video, and pitch-craft skills into one rehearsed package with a stitch plan, Q&A prep, and a day-of checklist. Use whenever the user says they need to pitch, present, or demo at a hackathon or demo day, to investors or a customer, mentions an N-minute slot, or asks to "prepare the whole pitch" end to end. Not for - a single artifact in isolation (call pitch-deck, demo-video, or pitch-craft directly) or written-only submission forms.
A pitch is one argument delivered through three instruments: the deck (setup), the demo (proof), and the speaker (trust). **The demo is the proof; the deck is the setup.** This skill's job is sequencing and budget, so the instruments never fight each other. Two rules govern everything: **interview before you build**, and **budget the slot first**.
STOP: produce no artifacts in this phase. Ask (adapting to what's already known):
1. **Audience**: hackathon judges, VCs, or a customer? What do they explicitly judge or care about (rubric, thesis, their own pain)? 2. **Slot**: total minutes? Is Q&A inside or after it? 3. **Inventory**: what already exists - working product? demo video? deck? scripts? Reuse beats rebuild. 4. **Demo mode**: live product on stage (higher wow, higher risk) or recorded film (deterministic)? Default to recorded unless the live path has been rehearsed with a fallback. 5. **Speakers**: who talks, and are there real credentials to weave into the intro? 6. **Constraints**: venue machine? offline? projector resolution? phone-as-teleprompter? 7. **Voice and music**: a model voice (Kokoro `af_heart` at 1.0 is the default) or a human? A music bed, and whose rights? For a model voice, agree to audition one segment two ways after the brief is confirmed, then let them choose; never pick for them. 8. **Branding and rights**: the company logo under the picture? A copyright and distribution line, in which words? A disclaimer card for a public copy? Whose logo, if a prospect's brand is in the product? Ask; a brand in every frame cannot be cut out later. 9. **Where it plays**: a portal, a stage, YouTube, a feed? A film with a caption band needs its own 16:9 cut; captions burned in, as a sidecar file, or both. 10. **Film guardrails**: if a demo film will be made or reused, what is it for and what must be burned in - any third-party logo or name in the frame, generic or personalised disclaimer card, a persistent "Demo purposes only" label, the rights line and company mark, and where it may live (private streaming link, our website's unlisted showcase, direct file, public platform)? Optional guardrails, mandatory questions: `demo-video/references/distribution.md`.
Reflect the answers back as a one-paragraph brief and get a nod before Phase 2. Skipping this interview is how pitches end up with a beautiful deck for the wrong audience.
Before writing or building anything, write the budget line:
5:00 slot = ~2:30 spoken deck + 2:36 demo video + ~0:10 transitions (runs ~5:15 as written -> trim points named in the script)
The budget decides scope: how many slides get narrated, whether the demo needs a shorter cut, what gets trimmed live. Every downstream artifact inherits this budget. If the pieces don't sum inside the slot on paper, they won't on stage.
Pick the audience lens from `references/audiences.md` - same assets, different lead, emphasis, and close. Then fill only the gaps the inventory revealed:
One throughline threads all three artifacts - if the deck's tagline, the video's close, and the speech's refrain differ, unify them before rehearsal.
The joins are part of the throughline work. Wherever the film or the talk changes person, case or topic, a transition line says so before the screen does, and nowhere else (pitch-craft's `references/storytelling.md`). The close lands the throughline, then the ask for customers or investors, or the name for judges, as the last thing heard; for a film that is a recap card walked by the voice, with the pilot line last (demo-video's `references/structure.md`).
Run the user-invoked Daily Chief Plan today workflow with device login, a local preview, and explicit confirmation before remote…
Web app MVP launch checklist knowledge. Auto-triggered when conversation involves "launch readiness", "MVP checklist",…
This skill should be used when the user asks to "analyze my product", "research competitors", "find feature gaps", "create…
Design, critique, or scaffold surveys grounded in Caroline Jarrett, Dillman, and Tourangeau methods. Use when designing a new…
Prescriptive Q&A workflow for designing agentic pipelines, multi-model councils, sub-agent hierarchies, and tool-loop hardening…
Blueprint for wiring many apps to one shared login plus a central accounts database, so a person has a single account across…