What it does: Reads a long request for proposal in Kimi and gives you the must-haves, the deadlines, and a bid or no bid call with reasons.
Use it when: A 60 page bid request lands and you can't tell if it's worth a week of work.
You get: A one page summary, a must-have check list against what you can do, the key dates, and BID or NO BID.
Open in
See the prompt
You are my bid reader. I uploaded a request for proposal.
What my business can do: [your services, size, area, licenses or insurance you have]
Jobs we won before that are like this: [list or none]
1. Summarize it on one page: who, what they want, where, how big, when.
2. List every must-have (licenses, insurance amounts, experience, forms). For each: do we meet it, YES, NO or CHECK, and the page number.
3. List all dates: questions due, site visit, bid due, start date.
4. List how they'll score bids, with weights if given.
5. Say BID or NO BID, with 3 reasons. Any NO on a must-have means NO BID unless I can fix it before the due date.
6. If BID: the 5 questions to send them before the questions deadline.
Rules:
- Every must-have and date needs a page number. Write dates exactly as the document does.
- If it lists no rule for a kind of must-have (like licenses), write [check: not listed].
- Don't guess if we meet a must-have. Use CHECK.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Bid Or No Bid' so you do it this way each time a bid request comes in.
Built from: New Sales Simplified, Mike Weinberg, Chapter 5: Selecting Targets: First for a Reason
What it does: Turns your rough notes into a short 6 slide pitch with Kimi's slides, where the buyer's problem comes first and you're the guide.
Use it when: You have a meeting on Thursday and your notes are a mess.
You get: 6 slides of words, speaker notes for each, and the outline to paste into Kimi's slide maker.
Open in
See the prompt
You are my pitch builder. I'll make the slides in Kimi.
Who I'm meeting: [name, company, what they do]
Their problem, from my notes: [paste notes]
What I sell and how it works: [3 steps]
Proof I can show: [a real result, or none]
What I want them to do next: [one step]
Write 6 slides:
1. Their problem, in their words.
2. What it costs them if nothing changes, only from my notes.
3. What it looks like when it's fixed.
4. How it works, my 3 steps.
5. Proof, if I gave some. If not, a slide on how we'd start small to show it works.
6. The next step, one ask.
For each slide: a title under 8 words, 3 lines max, and speaker notes under 50 words.
Then give me the outline in one block to paste into Kimi's slide maker.
Rules:
- They're the hero. I'm the guide.
- No numbers, results or promises I didn't give you. Speaker notes use only my notes. Use my words for what I sell. Don't promise more.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Pitch Slides' so you do it this way each time I make a pitch deck.
Built from: Building a StoryBrand, Donald Miller, Chapter 3: The Simple SB7 Framework
What it does: Reads the old and new version of a contract in Kimi and lists every change, what it means for you, and what to push back on.
Use it when: A client or supplier sent back 'a few small edits' to a long contract.
You get: Every change with section numbers, what it means for you in plain words, and a list of what to push back on.
Open in
See the prompt
You are my contract reader. I uploaded 2 versions of the same contract. This is not legal advice.
Which is old and which is new: [file names]
My side: [which party I am]
What I care about most: [for example: payment terms, how to end it, liability]
1. List every change: section number, old words (under 15 words), new words (under 15 words).
2. For each, say what it means for me in one plain line: better, worse or same.
3. Mark the changes that touch what I care about most.
4. List the changes they didn't mention, if they sent a note on what they changed: [paste their note, or blank].
5. Write a short list of what to push back on, with the change I'd ask for.
Rules:
- Only list real changes between the 2 files. Don't review the whole contract.
- If a change is unclear, say "unclear" and give the section.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Contract Changes' so you do it this way each time a contract comes back with edits.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 9: Plan