Build a Repeatable ChatGPT Skill Stack for Ops, Sales, and Product Decisions

The operational problem is routing: the snapshot documents a large set of tool interfaces and complete main skill files. That is enough surface area to confuse a team, so the first move is to narrow the path before adding prompts. Most founder teams do not fail at the assistant because the model is weak. They fail because the workflow is weak. The assistant gets used for many small asks, then the useful patterns die in a thread, a message, or a half-remembered prompt. The result is not intelligence. It is friction with a better vocabulary.

The fix is to stop treating the assistant like a chatbot and start treating it like a permissioned internal service. A service has a name, a scope, a set of allowed actions, and a review path. A skill is the unit that makes that possible: it packages the prompt, the tools, and the review gates for a specific decision type.

The distinction that matters

The underlying distinction is simple: tools are callable endpoints. The skill is the control layer around them. In practice, that means a skill is a reusable instruction package that guides how tools are used. It is a small operating procedure: when to run it, what it may touch, what it must return, and who must approve the result.

Tool availability varies by session configuration, permissions, connected apps, and installed plugins. A skill that assumes every tool is present may be affected by changes in tool availability. Each skill must therefore name required capabilities, disallowed modes, and what to do when a required capability is missing. That is not bureaucracy. It is the difference between a repeatable process and a lucky prompt.

Some tools are blunt. The apply_patch tool is a freeform file-editing tool. The skill should say what may be edited, what must be diffed, and what requires a human sign-off before anything leaves the draft stage.

A skill-file template for founder decisions

The template below is a SKILL.md-style file; skill pages are verbatim copies of their current main SKILL.md definitions. It is a control document, not a spec sheet. The useful loop is short: state the allowed tools, the permissions, the output shape, the missing-capability behavior, and the human review gate.

Trigger: A recurring operational exception, a deal review question, or a circling decision.

Allowed registry tools and direct session controls: List the registry tools and direct session controls the skill may use, and the modes it may not use.

Permissions: State what the skill may touch, what it may not use, and what requires a human sign-off before anything leaves the draft stage.

Output shape: A recommended action with the owner and the next step, a short recommendation with the strongest objection and the evidence needed to close the gap, or a decision memo with the recommendation, the assumptions, the trade-offs, and the smallest test that would change the answer.

Missing-capability behavior: State what the skill needs, what it may not use, and what to do when a required capability is missing.

Human review gate: Confirm the action before it is sent or executed, confirm the commercial terms and the tone before anything goes to the customer, or approve the memo before the call is made.

The review checkpoint is the part most teams skip. It is also the part that decides whether the skill becomes infrastructure or just another place for confident mistakes to accumulate.

Three skills to build first

Start with the decision types that already consume founder time: ops exception handling, sales deal review, and product decision memo. Three are usually enough to prove the pattern. Run each as the same operator sequence.

Trigger: Ops runs on a recurring operational exception. Sales runs on a deal review question. Product runs on a circling decision.

Allowed tools: Each skill lists the registry tools and direct session controls it may use, and the modes it may not use. Ops may take the raw incident, classify it, pull the relevant context, and draft an action. Sales may take the deal stage, the buyer signals, the open risks, and the proposed next step. Product may take the problem, the user evidence, the cost, the risk, and the alternatives. None may send, execute, or make the call without the review gate.

Output: Ops returns a recommended action with the owner and the next step. The value is not speed. It is consistency. Sales returns a short recommendation, the strongest objection, and the evidence needed to close the gap. It should not invent confidence. It should make the missing information visible. Product returns a decision memo with the recommendation, the assumptions, the trade-offs, and the smallest test that would change the answer.

Human review gate: Ops requires a human to confirm the action before it is sent or executed. Sales requires a human to confirm the commercial terms and the tone before anything goes to the customer. Product requires the founder or product owner to approve the memo; the skill should be allowed to draft the memo, not to make the call.

Version update when tool availability changes: Update the allowed tools. When a skill fails, update the file. When a review gate is too loose, tighten it. The goal is not a perfect AI workflow. It is a set of repeatable decisions that survive the next hire, the next quarter, and the next tool update.