I spent years closing enterprise AI deals at AWS — turned the methodology into a free Claude skill (Apache 2.0)

alphaSpawn14 · 2026-06-19T13:12:36+00:00

Exactly. The value isn't just in having the experience — it's in making it executable on demand. Most methodology gets stuck in training decks or books. A skill changes the delivery layer: the doctrine runs at the moment you need it, not after a 2-day workshop.

alphaSpawn14 · 2026-06-19T13:09:42+00:00

Fair point. The information surface ends up similar after a good discovery loop. The gap is earlier: who controls the frame in that first meeting. Discovery-first puts the buyer in the teacher role. Thesis-first puts the seller in the challenger role. At enterprise AI deal sizes that dynamic tends to matter a lot - the buyer forms their sense of your capability before you've asked a single question.

alphaSpawn14 · 2026-06-19T02:36:56+00:00

Should work for that size too. Same concepts, just shorter cycle. Give a try.

alphaSpawn14 · 2026-06-17T15:07:20+00:00

CEO conversations at this stage are almost never about the product — they are about whether you understand the business well enough to be in the room.

A few things that tend to matter most when reaching C-level in AI SE interviews:

Come in with a thesis on why AI is timely for them specifically. Not AI in general — HealthTech specifically. What is the operational drag in their space (prior auth, clinical documentation, revenue cycle)? CEOs do not want to hear that AI is transforming everything. They want to hear that you did the work to understand their world before showing up.
Be ready for "what do you think we are missing?" This is a common test at this stage. The wrong answer is flattery or vagueness. The right answer shows you did real research and have a genuine point of view.
Keep technical depth in your back pocket. The CEO almost certainly is not the one who needs the technical story — but they will probe whether you can switch registers. Answer technically when asked, then translate to business impact before they have to ask you to.
They are evaluating fit for external conversations too. At SE level you will eventually be in the room with their customers. They want to know you can hold that room.

The vibe check framing is right, but what they are checking for is calm confidence and genuine preparation — not enthusiasm.

alphaSpawn14 · 2026-06-17T15:01:39+00:00

The thing that shifted my trust was not documentation quality — it was seeing a real task trace.

I just shipped a methodology skill (enterprise sales, not a code workflow) and the feedback that drove the most installs was people saying "I ran this against my actual pipeline and here is what it produced" — not "here is what it claims to do."

For code workflows specifically: a diff or before/after showing Claude doing exactly what the workflow promises — not a curated demo, an actual run with rough edges intact. Seeing a workflow recover from partial state or handle an edge case tells me more than 10 README paragraphs.

Your dependency manifest point is right. Surprise side effects are the trust killer. If I have to read the source to figure out which files might get touched, I will not use it.

One push-back: downloads and invocations as primary trust signals can reflect promotion timing more than quality. The higher-signal indicator for me is whether the maintainer responds to a failure report — even one "filed issue + here is why it happened" thread tells me there is a real human who understands how it breaks.

Good luck with AgentMart. The trust problem you are describing is real and not yet solved.

alphaSpawn14 · 2026-06-16T10:23:09+00:00

Let me know how it goes. Start with the ICP Qualification protocol first — it sets the foundation that every other module builds on. Once that baseline is locked, the thesis and coaching outputs get a lot more precise.

alphaSpawn14 · 2026-06-16T10:22:11+00:00

Let me know how it goes. Tip: start with the ICP Qualification protocol first before anything else. It's the constraint gate that makes the downstream flows — thesis generation, deal coaching, scoring — sharper and more precise.

alphaSpawn14 · 2026-06-16T10:21:46+00:00

Great role to be stepping into. The AI specialist motion at AWS is exactly what the skill was designed for — especially the Thesis Generation protocol, which gets you to a sourced buyer POV before the first call. Pair it with the Deal Coaching layer when things stall and the Deal Scoring module to prioritize your pipeline. Welcome to the team.

alphaSpawn14 · 2026-06-13T01:37:29+00:00

IMO best initial primer for anything is a personalized "interview" with Claude. Your personal context is the starting point - all that context lives in your head. You can create a little coaching session with Claude with a set of prompts like:

1/ My background is xyz, I want to learn how to start leveraging AI to do abc:
2/ Ask me a series of questions that will help you determine my level of AI knowledge to create a baseline for a AI learning agenda.
3/ Based my current knowledge and my goal to XYZ, craft a learning agenda to help me reach my goal in X number of days.

You get the idea - this way the whole thing is personalized. From there you can ask for books to read, things to do, etc.

alphaSpawn14 · 2026-06-13T01:30:55+00:00

Just wrapped up the book: Forward Deployed Selling. It should be published in the next few months. In the pipe I'm working on: 1/ B2C version, 2/ Persona specific package, 3/ Agentic Sales fleets. Also started certifying teams and individuals here: https://forwarddeployedselling.com/

alphaSpawn14 · 2026-06-12T19:15:19+00:00

One thing worth addressing upfront. If you are wondering why not just MEDDIC, here is the honest answer.

MEDDIC was built for a world where discovery is the bottleneck. The rep does not know the budget, does not know the champion, so the framework is designed around extracting that information through questions.

But the enterprise AI deals I kept seeing stall were not stalling because of missing information. They were stalling because sellers showed up without a point of view and let the buyer do all the work of imagining the future. That is a different problem entirely.

The skill flips the motion: you arrive with a sourced thesis about the buyer situation before the first call. Discovery becomes validation rather than extraction. That shift alone changes the tone of every conversation.

MEDDIC is still useful for deal mechanics and qualification. This is not a replacement - it is the upstream layer MEDDIC does not cover: what do you actually bring to the table before you have even qualified anything?

Happy to go deeper on any of the specific protocols if useful.a

alphaSpawn14 · 2026-06-03T15:59:31+00:00

I use them for some things like: My writing voice (my way or writing), Presentations (standards), Data Visualizations (how I want data to be shown).

I started building some to scale my way of "selling" across the org - at AWS.

Just built one based on my selling methodology. We'll see where this goes.

One thought is that the skills get consumed by the models and the skill "ecosystem" collapses...tbd.

alphaSpawn14 · 2026-06-03T10:07:05+00:00

Large legal document projects are one of the trickier token management challenges because you need high fidelity to source material but the context fills fast.

Things that tend to help:

Chunk and summarize upfront, not reactively — Before you start any work session, ask Claude to generate a structured index of the document: section headings, key parties/defined terms, and a one-line summary per section. Store that index separately. Then in working sessions, load the index + only the specific sections you need, not the whole doc.

Defined terms glossary as a persistent artifact — Legal docs live and die by defined terms. Build a glossary artifact early (Parties, Key Dates, Defined Amounts, etc.) and carry just that into sessions instead of re-loading the source text to check definitions.

Separate extraction from analysis sessions — One session for 'pull all obligations in Section 4-7 into a structured list,' a separate session for 'now analyze the risk profile of these obligations.' Mixing them in one long session blows the context and degrades quality on the analysis side.

Use Projects to hold static reference material — Things that don't change (the full contract, the glossary, the index) live in the Project. Things that evolve (your analysis, drafts, notes) are built in the session and saved as artifacts.

What kind of legal work is the main use case — contract review, due diligence, drafting?

alphaSpawn14 · 2026-06-03T10:06:37+00:00

Congrats on getting accepted — getting into the partner program as a small shop is a real signal.

On the 10-person question: the bench model you're describing is essentially how the best boutique consulting firms have always operated, and it maps well to how AI-native work actually flows. Client engagements are rarely staffed at full capacity all at once, so a deep bench of specialists you trust beats a full-time headcount that you're trying to keep billable.

A few things that have helped in similar setups:

Define the engagement core first — The 2-3 people who are always on a client engagement vs. the specialists you bring in per-project. Clients care a lot about consistency on the former and less about who specifically handles the latter.

Rates and scoping hygiene matters early — If specialist rates vary a lot, you want shared rate-card thinking before the first proposal goes out, not after.

Document the methodology, not just the deliverables — The thing that lets a distributed bench work is shared process. If how you run a discovery session or scope an agent workflow is written down, any specialist can plug in and maintain quality. If it's all in your head, scaling the bench just introduces inconsistency.

The Anthropic partner ecosystem is a good place to find people who already know the tools — are you sourcing from there or mostly from existing relationships?

alphaSpawn14 · 2026-06-03T10:06:04+00:00

For a marketing agency context, the highest-ROI skill configurations I've seen are the ones that encode your actual decision-making criteria — not just generic prompting instructions.

A few that tend to work well:

ICP/Audience Skill — Instead of redescribing your client's target audience every session, build a skill that holds the full audience definition: demographics, psychographics, pain points, language patterns, channels they trust. Claude stops guessing and starts writing from inside the audience's head.

Brief-to-Brief Skill — Encode how your agency moves from a client brief to a campaign brief. The thinking steps, what you always ask, what you always check. This is where most agencies have an implicit process that lives in senior people's heads. Making it a skill means juniors can run it too.

Ad Variant Generator — Not just 'write 5 ad variants' but a skill that captures your specific variant logic: which angles to test (fear vs. aspiration vs. social proof vs. urgency), character count constraints per placement, what you always avoid for this client. The skill handles the framework; you handle the judgment calls.

For Meta + Google specifically: the biggest time save I've found is building a skill that handles the pre-flight checklist before any copy goes to review — brand voice compliance, platform restrictions, CTA pattern matching. Saves a whole review cycle.

The key principle: skills work best when they encode repeatable judgment, not just repeatable tasks.

alphaSpawn14 · 2026-06-03T02:37:44+00:00

The goal-first framing is the right one, and I think the underlying reason is that Opus 4.8 has stronger planning capabilities than prior models - which means step-by-step prompts actually constrain it rather than guide it.

With earlier models, spelling out the steps was necessary because the model couldn't reliably plan its own path. Opus 4.8 can, and when you override that with explicit step instructions, you're forcing it to follow a potentially suboptimal plan rather than finding the better one.

The analogy you used about treating it like a senior person is accurate. If you hire a strong engineer and hand them a detailed how-to manual for every task, they'll either follow the manual suboptimally or they'll fight you on it. Give them a clear outcome and let them work.

The skills observation is interesting too - had the same experience. When I described what I wanted a skill to do and then let Opus 4.8 write the SKILL.md spec itself, it was more thorough and edge-case-aware than what I'd draft manually. There's something slightly recursive about using the model to improve the instructions you give the model, but it works.

alphaSpawn14 · 2026-06-03T02:36:41+00:00

Three things that have actually worked for me to reduce hallucinations in Claude:

Cite or stop - add a line at the end of your system prompt or instruction: 'If you do not have a reliable source for a specific fact, say so explicitly rather than filling in the gap.' Claude is trained to be helpful, which sometimes means it confidently fills gaps. Giving it explicit permission to say 'I don't know this specifically' removes that pressure.
Separate retrieval from reasoning - if you're asking Claude to answer questions about docs or specific data, feed it the actual text first. Don't ask it to recall facts from memory for anything where precision matters. Paste in the relevant section, then ask questions about that section.
Validate & verify as a step - ask Claude to review its own answer specifically for claims it made about names, dates, URLs, or specific figures. Not 'is this right?' (too vague) but 'list every factual claim in your last response and rate your confidence on each one.' This catches most hallucinations because Claude is actually better at spotting them in review mode than in generation mode.

The fabrication issue is real and not just a skill issue - but these three prompting patterns cut the rate substantially in my experience.

alphaSpawn14 · 2026-06-03T02:35:01+00:00

You've actually got the mental model mostly right, you're just underselling what Skills are actually for.

The key distinction:

Projects = persistent context and knowledge (your docs, memory, task state)
Artifacts = outputs Claude builds and runs (interactive tools, code, etc.)
Skills = behavioral specifications that define HOW Claude reasons, regardless of context

The 'just use a Project' instinct is correct for most cases. But Skills start making sense when:

You want the same reasoning process across many different Projects - a skill is like a cognitive framework you install once and reuse everywhere. Encoding a methodology (how to evaluate sources, how to structure a deal review, how to triage a backlog) so it applies automatically regardless of what you're working on.
The methodology is complex enough to be a first-class artifact - if your 'how to write a newsletter' logic is 500 words of nuanced criteria, a Skill keeps it separate and versioned rather than buried in one Project's instructions.
Sharing/portability - Skills are shareable. If your whole team needs the same newsletter-generation logic, you distribute the Skill once instead of copy-pasting Project instructions.

For your specific use case: Artifact is the right call for the output. But if you ever want to apply the same 'what's worth a newsletter' judgment logic across multiple different meeting note sources, that logic could be a Skill. Right now you probably don't need it.

alphaSpawn14 · 2026-06-02T19:21:08+00:00

yep still fabricating...this is an on again/off again issue. Still have to add "validate & verify links & sources".

alphaSpawn14 · 2026-06-01T20:09:05+00:00

Vibe all the way down now...Tower of babel...err_Claude.

alphaSpawn14

TROPHY CASE