Presales with docs
Run live presales discovery one question at a time, preserve a decision ledger, and produce an auditable ballpark/ROM for services, infrastructure, timeline, and BAU. Use when a presales operator is scoping a client project, qualifying requirements, estimating man-days, loading an approved rate card from Notion, or preparing an indicative cost for client discussion.From its SKILL.md
npx -y skills add thattimc/skills --skill presales-with-docsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
- runs commandsInstructs the agent to run 2 commands, including `python3 "<this skill dir>/scripts/calculate_ballpark.py" estimate.json --output-dir ./ballpark-output` and 1 more.
SKILL.md
5.0 KB, 981 tokens by cl100k_base, as published. Nobody here has run it
Presales with Docs
Guide a client conversation from desired outcome to a reviewable, non-binding ballpark. The presales operator owns the meeting and every commercial approval.
Start
-
Read references/live-discovery.md. Ingest supplied requirements before asking anything. Ask the operator whether the conversation is client-visible or private, then create
<client-slug>-presales/discovery-record.mdfrom the reference template. State that this is discovery for an indicative ROM. Complete when: visibility is known and the record contains every fact already available from supplied material. -
Ask: “What outcome would make this project successful for you?” Ask exactly one client-facing question, then wait. Honor operator controls:
park,skip,revisit,summarize,private checkpoint, andend discovery. Complete when: the client has answered or the item is explicitly parked.
Discovery loop
-
Update
discovery-record.mdafter every answer: confirmed facts, client decisions, assumptions, exclusions, unresolved items, and conflicts remain distinct. Choose the next question by this order: conflict, readiness blocker, largest estimate swing, then output detail. Ask one question and wait. Offer a recommended answer only when the operator or client needs options; label it as a recommendation. Complete when: every readiness-gate field is confirmed, assumed with a stated basis, or recorded as non-blocking, and no blocking conflict remains. -
Present one scope checkpoint: outcomes, scope in/out, work breakdown, assumptions, unresolved items, and proposed effort ranges. Ask the operator for one confirmation. Revise through the discovery loop when they reject it. Complete when: the operator explicitly approves the estimate basis.
Ballpark
-
Read references/estimate-input.md. Build the JSON input from the approved basis and controlled sources. For a Notion-backed rate card, also read references/notion-rate-card.md, load an approved/effective card into a private snapshot, and map every estimate role to one composite rate key. Use the inline rate card only as the documented fallback. Keep tokens, private rates, snapshots, and role math out of client-visible conversation. Complete when: every service line has role, day range, rate-card match, and basis; snapshot provenance verifies when used; every external cost has source and as-of date; timeline has a stated basis.
-
Run the deterministic calculator in draft mode:
python3 "<this skill dir>/scripts/calculate_ballpark.py" estimate.json \ --output-dir ./ballpark-outputWhen step 5 produced a Notion snapshot, add
--rate-card-snapshot ./private/rate-card-snapshot.json. Never run the loader in a client-visible terminal.Validation errors return to the discovery loop. Review
internal-estimate.mdprivately; the client artifact contains totals but no day rates. Complete when: every total traces to an input line and the operator accepts the range, confidence, assumptions, exclusions, contingency, and validity period. -
Ask one approval question: “Do you approve this ROM for client discussion?” After explicit approval, record the human reviewer:
python3 "<this skill dir>/scripts/calculate_ballpark.py" estimate.json \ --output-dir ./ballpark-output --approved-by "Reviewer name"Present
client-ballpark.md. If approval is withheld, present the discovery summary and missing decisions instead. Complete when: approved output names its reviewer, or the session ends without a commercially usable estimate.
Hard gates
- A ballpark is a range. The client artifact states ROM status, confidence, basis, assumptions, exclusions, contingency, validity, unresolved items, and non-binding use.
- Critical unknowns stay in
blocking_unknowns; the calculator refuses an estimate. - Services, one-time infrastructure, and recurring cloud/BAU remain separate totals.
- Keep private rates, margins, discounts, and role-level math in internal artifacts.
- Fetch Notion rates through the read-only deterministic loader, not through model context.
- Reject changed snapshots, ambiguous active versions, mixed currency, and missing mappings.
- The calculator performs arithmetic; the model performs discovery and decomposition.
For a complete synthetic run, read examples/sample-session.md and use examples/sample-estimate.json.
What ships with it: 12 files
105.8 KB alongside SKILL.md, 4 of them executable
agents/
- openai.yaml240 B
examples/
references/
- estimate-input.md5.2 KB
- live-discovery.md5.8 KB
- notion-rate-card.md5.1 KB
scripts/
- calculate_ballpark.pyruns31.0 KB
- load_notion_rate_card.pyruns19.1 KB
tests/
- test_calculate_ballpark.pyruns9.3 KB
- test_load_notion_rate_card.pyruns19.8 KB
Gives 0 of the 12 instructions most docs writing skills give in 981 tokens
Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06
- Use third-person for skill descriptionsin 54 of 1951, across 35 files
- Start descriptions with Use whenin 43 of 1951, across 29 files
- Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
- Use active voicein 40 of 1951, across 36 files
- Map file responsibilities before defining tasksin 36 of 1951, across 29 files
- Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
- Ask one question at a timein 35 of 1951
- Offer execution options after saving the planin 33 of 1951, across 24 files
- Include complete code in every stepin 33 of 1951, across 27 files
- Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
- Announce the skill usage at the startin 30 of 1951
- Verify agent compliance after adding the skillin 29 of 1951, across 17 files
Said here and by no other author read
- Ingest requirements before asking questions
- Create a discovery record from the template
- Ask exactly one client-facing question at a time
- Update the discovery record after every answer
- Present one scope checkpoint for operator confirmation
- Load rate cards into a private snapshot
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.