handshake

Que fait handshake ?

Un plan est pour le fondateur. Un pitch est pour une seule personne et un seul oui. Cette compétence le rédige à partir de ce qui est réellement connu, afin que le fondateur puisse l'envoyer sans avoir à défendre un chiffre qu'il ne peut pas justifier.

Ce que l'utilisateur a tapé après /handshake : $ARGUMENTS

Lisez d'abord ${CLAUDE_SKILL_DIR}/../receipts/rules.md. L'outil de registre :

python3 "${CLAUDE_SKILL_DIR}/../receipts/ledger.py" <gate | scan | summary>

Ci-dessous, LEDGER désigne exactement cela.

Étape 1 : qui, et quel oui

Demandez pour qui c'est et le oui que le fondateur souhaite, si cela n'est pas précisé. Nommez le destinataire : un client, un financeur, un investisseur, un prêteur, quelqu'un au sein de son entreprise, ou les personnes qui l'utiliseront. Lisez ${CLAUDE_SKILL_DIR}/receivers.md pour savoir ce que ce destinataire a besoin de voir.

S'il existe un document de leur part (un RFP, un appel à subventions, un courriel, une offre d'emploi), lisez-le d'abord, extrayez exactement ce qu'ils demandent et enregistrez-le sous founder/opportunities/<nom>.md (format : ${CLAUDE_SKILL_DIR}/../first-dollar/opportunity.md).

Réduisez la demande au plus petit oui réel (règle 7). Si le fondateur veut demander à un inconnu des frais initiaux élevés, dites clairement qu'un pilote limité dans le temps sur les propres chiffres du destinataire a plus de chances d'obtenir un oui, et proposez les deux options.

Étape 2 : ce que le dossier peut soutenir

LEDGER check
LEDGER gate --audience <public | anonymise | permission>

Choisissez l'audience en fonction de la façon dont le pitch sera diffusé : public pour tout ce qui pourrait être transféré, anonymise pour un envoi privé, permission uniquement si chaque personne liée à une revendication ASK FIRST a donné son accord dans founder/evidence/people.md.

Construisez uniquement à partir de ce que gate affiche. Si le destinataire a besoin de quelque chose que le dossier ne peut pas soutenir, ne le contournez pas : listez-le sous Lacunes à la fin de la sortie, avec la façon de l'obtenir (le job 4 de /receipts va plus loin). Ne comblez jamais une lacune avec une supposition, une citation de panel ou une opinion de conseil d'administration.

Si rien concernant la demande n'est MESURÉ, le pitch le dit honnêtement dans son libellé : « nous cherchons trois entreprises pour réaliser un pilote », pas « les entreprises font la queue ».

Étape 3 : rédigez-le

1. La phrase unique, les trois phrases, le plan de trois minutes.
2. Le format du destinataire issu de receivers.md. Répondez dans les propres rubriques du destinataire lorsqu'ils vous ont donné un appel ou un RFP. Respectez leurs limites (comptez les caractères pour les sections NSF et indiquez le compte).
3. Citez chaque fait avec son identifiant de revendication, comme [c04], dans le brouillon de travail. Écrivez les revendications PLANNED comme des objectifs (« nous prévoyons », « le pilote testera »), jamais comme des résultats.
4. Une courte section Ce qui pourrait mal tourner en termes simples. Les destinataires lui font confiance.
5. Lacunes : ce dont ce pitch aurait besoin pour être plus solide, et le moyen le moins coûteux d'obtenir chaque élément.

Enregistrez-le sous founder/outputs/<YYYY-MM-DD>-<destinataire>.md.

Étape 4 : vérifiez-le avant l'envoi

LEDGER scan founder/outputs/<fichier>.md --audience <la même audience>

scan refuse toute revendication citée que l'audience ne peut pas voir (une revendication SIMULATED ou PRIVATE, une ASK FIRST sans permission) et signale les mots de preuve (« validé », « prouvé », « forte demande ») lorsqu'aucun acheteur réel n'a payé ou signé. Corrigez chaque problème qu'il imprime et relancez-le jusqu'à ce qu'il soit propre. Ensuite, faites une copie prête à envoyer sans les identifiants [c..] si le fondateur le souhaite, et conservez le brouillon cité.

Règles

• Aucun acheteur simulé, membre du conseil ou résultat de modèle n'est jamais cité, compté ou décrit comme un client, un utilisateur, un conseiller ou une étude de marché provenant de personnes réelles.
• Aucun conseiller, partenaire, logo, nom de client ou chiffre inventé. « Conseillers en comptabilité » nécessite un conseiller réel dans people.md qui a accepté d'être listé.
• Aucune taille de marché sans source ; sinon, écrivez-la comme une estimation avec la méthode.
• L'envoi est le travail du fondateur. Rédigez le courriel ou le message ; ne l'envoyez pas.

Sortie

founder/outputs/<date>-<destinataire>.md (plus une copie propre si demandée), et founder/opportunities/<nom>.md s'il y avait un appel ou un RFP. Terminez par la phrase unique, les lacunes et l'action suivante : à qui envoyer cette semaine, et quoi enregistrer avec /receipts lorsqu'ils répondent.