Choosing And Executing logo

Choosing And Executing

Community
fatihguner
choosing-and-executing

Provides a toolkit for moving from deliberation to commitment and from commitment to results. Covers the cost of decision paralysis, the 70% rule for when to stop gathering information, implementation planning after the choice is made, transparency as a trust mechanism, handling challenges to decisions, and combating second-guessing through process review rather than outcome regret. Use when stuck in analysis paralysis, when a decision has been made but needs implementation momentum, when stakeholders challenge or resist a decision, when second-guessing erodes confidence, or when building a decision communication plan.

Overview

Publisherfatihguner
Repositoryforeman
Skill namechoosing-and-executing
Stars
63
Forks
10
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by fatihguner on GitHub. Read the source before you install it.

Installation

Install the Choosing And Executing AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/fatihguner/foreman/tree/main/plugins/foreman/skills/choosing-and-executing
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/fatihguner/foreman.git /tmp/foreman
mkdir -p .claude/skills
cp -r /tmp/foreman/plugins/foreman/skills/choosing-and-executing .claude/skills/choosing-and-executing
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Choosing And Executing in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Choosing And Executing on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Choosing And Executing is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Read runtime and advisory rules before applying this skill. Other Foreman layers and the catalog are in ../../content/, relative to this SKILL.md.

Choosing and Executing

The cost of searching for the perfect decision almost always exceeds the cost of making a "good enough" one and iterating. Scott McNealy, cofounder of Sun Microsystems, captured this asymmetry in a single observation: he spent far less energy worrying about making the right decision and far more ensuring that any decision he made turned out right. The distinction is not semantic. It relocates agency from the moment of choice -- where the entrepreneur has minimal control over future variables -- to the months of execution that follow, where nearly everything is within reach. Founders who internalise this shift stop treating decisions as bets to be perfected and start treating them as hypotheses to be tested, adapted, and driven to outcomes through disciplined follow-through.


The Toolkit

Technique 1: The Reversibility Test

Not all decisions deserve equal deliberation. Jeff Bezos famously divided choices into "one-way doors" (irreversible, high-stakes) and "two-way doors" (reversible, correctable). Most entrepreneurial decisions fall through the second door -- yet founders routinely treat them as though they are signing a blood oath.

The diagnostic question: If this decision proves wrong in six months, can the company course-correct without catastrophic loss? If yes, the decision is a two-way door. Make it quickly, monitor outcomes, and adjust.

Why founders over-deliberate on two-way doors:

  • Identity attachment. The choice feels like it defines the founder, not just the venture.
  • Anxiety amplification. Research by Francesca Gino demonstrates that anxiety makes people simultaneously more receptive to advice and less capable of distinguishing good advice from bad -- a dangerous combination that extends deliberation without improving quality.
  • Perfectionism as procrastination. Waiting for the "objectively correct" answer is often a socially acceptable form of avoidance.

Reserve deep analysis for one-way doors: market exits, large capital commitments, equity dilution events. Everything else deserves the 70% rule.

Technique 2: The 70% Rule

If a decision has been analysed to the point where approximately 70% of the relevant information is in hand, make the call. The remaining 30% is unlikely to arrive before the cost of delay exceeds the value of marginal certainty.

When to apply the rule:

  • The team has debated the same options across multiple meetings with no new data surfacing.
  • The competitive landscape is shifting while internal deliberation continues.
  • The decision maker's gut has already settled, but the rational mind insists on "one more data point."

When to override the rule:

  • The decision is genuinely irreversible (shutting down a product line, terminating a co-founder relationship).
  • The 70% of information gathered points in contradictory directions -- not ambiguous, but actively conflicting.
  • Regulatory or legal constraints demand a higher evidentiary threshold.

Thomas Davenport suggests a meta-decision framework: decide how to decide. Assess importance, frequency, and urgency before allocating deliberation time. Rare, strategic, high-stakes choices merit extended analysis. Recurring, operational, reversible choices merit a clock -- and when the clock runs out, the decision is made.

Technique 3: Buying an Option

When neither committing nor abandoning is palatable, consider a third move: buy an option. Rather than acquiring a company, form a partnership. Rather than launching nationally, pilot in one city. Rather than hiring a full-time executive, engage a fractional one for ninety days. Options convert large, irreversible decisions into small, reversible experiments -- providing real-world data that no amount of spreadsheet modelling can replicate.

The discipline here is to treat the option as a learning vehicle, not as a permanent hedge against commitment. Every option must have an expiration date and explicit criteria for converting to a full commitment or walking away.

Technique 4: Post-Decision Implementation Protocol

A decision without an implementation plan is a wish. The moment a choice is finalised, the following elements must be articulated:

ElementPurpose
Decision statementOne sentence: what was decided and why
Stakeholder notification listEveryone affected, responsible, or accountable
Implementation timelineMilestones, deadlines, and checkpoint dates
Success criteriaHow the team will know the decision is working
Escalation triggersConditions under which the decision should be revisited
OwnerA single accountable individual, not a committee

Communicate the decision before rumour fills the vacuum. Include the reasoning process, not merely the conclusion. Research consistently shows that perceived fairness of process predicts acceptance of outcome -- even among those who preferred a different option.

Technique 5: Transparency as Trust Architecture

Being transparent about how a decision was made is not a courtesy; it is a structural investment in trust. Liane Davey's work on organisational fairness identifies two dimensions that teams evaluate simultaneously: outcome fairness (did the result distribute burdens and benefits reasonably?) and process fairness (was the method of arriving at the result legitimate?).

The order-of-disclosure effect: Studies show that when people learn about the process before the outcome, process fairness dominates their satisfaction. When they learn the outcome first, outcome fairness dominates. The practical implication is clear: lead with process. Explain the criteria, the alternatives considered, and the trade-offs weighed before announcing the decision itself.

Transparency is especially critical when:

  • A decision overrides the preference of a vocal stakeholder.
  • Resources are being reallocated from one team or project to another.
  • The founder is making a judgment call that cannot be fully supported by data.
  • The decision involves equity, compensation, or role changes.

Technique 6: Handling Challenges to Decisions

Three patterns account for the majority of post-decision pushback:

  1. "You didn't ask me." A stakeholder feels excluded from the process. The fix is proactive: define decision roles at the outset using frameworks such as RACI or RAPID. If someone was intentionally excluded, be prepared to explain why.

  2. "I didn't say anything then, but I disagree now." Late-breaking dissent from someone who was present but silent. Establish the norm: silence denotes agreement. Those who wish to dissent must do so during the decision window, not after.

  3. "I agreed, but I'm implementing something different." The most corrosive pattern. The person nominally endorsed the decision but quietly modifies execution to suit their own preference. Counter this with explicit milestones, a single accountable owner, and periodic checkpoints that compare actual implementation against the decision as made.

The one legitimate reason to reopen: new facts have emerged that materially alter the calculus. Changed opinions, second thoughts, or political manoeuvring do not qualify.

Technique 7: Defeating Second-Guessing

Second-guessing is not rigorous reassessment; it is anxiety wearing a rational costume. Sydney Finkelstein's research identifies its cost: a founder who second-guesses a hire actively undermines that hire's probability of success, creating a self-fulfilling prophecy that validates the original doubt.

The antidotes:

  • Perspective calibration. Ask: what are the actual stakes of this decision? Many choices that consume disproportionate mental energy have surprisingly low consequence. Redirect attention to decisions that genuinely matter.
  • Gut journalling. Maintain a log of past decisions and their outcomes. Over time, this record builds calibrated self-trust and reveals whether intuition is a reliable signal or a noisy one.
  • Advisory polling. When doubt persists, consult two or three trusted advisers -- not for validation, but for perspective. The act of articulating the decision to another person often resolves the uncertainty before the adviser even responds.
  • Scheduled review. Set a specific date to formally revisit the decision. Between now and that date, execute with full commitment. This converts open-ended rumination into bounded, productive monitoring.
  • Process-outcome separation. Judge decisions by the quality of the process that produced them, not by the outcome that followed. A sound process that yields a bad outcome is not a bad decision -- it is a reminder that the world contains irreducible uncertainty. Confusing process quality with outcome quality is the hallmark of hindsight bias.

Prompts

Prompt 1 -- Paralysis Diagnostic:

I have been deliberating on [describe decision] for [time period]. List the information I already have versus the information I am still seeking. For each missing piece of information, estimate: (a) how long it will take to obtain, (b) how much it would change the decision if obtained, and (c) the cost of waiting. Then recommend whether to decide now or continue gathering data.

Prompt 2 -- Implementation Blueprint:

I have decided to [describe decision]. Draft an implementation plan that includes: a one-sentence decision statement, stakeholder notification list, milestone timeline, success criteria, escalation triggers, and the single accountable owner. Tailor it to a [stage] startup in [sector].

Prompt 3 -- Decision Communication Script:

I need to communicate [describe decision] to my team. Some members preferred a different option. Draft a communication that leads with the process used, explains the criteria and trade-offs, acknowledges the alternative viewpoints, and outlines next steps. Tone: direct, respectful, no hedging.

Prompt 4 -- Second-Guessing Audit:

I am second-guessing [describe past decision]. Walk me through: (1) the process I used to make it, (2) whether new facts have emerged that warrant revisiting, (3) whether my doubt is evidence-based or anxiety-driven, and (4) a recommended next action -- either recommit or reopen with specific new criteria.


Use Cases

The Feature Pivot That Stalled

A validation-stage SaaS founder has spent three months debating whether to pivot the core feature set based on user feedback. Metrics are mixed -- some cohorts respond well, others do not. The team has held four strategy sessions without resolution. Applying the 70% rule, the founder recognises that additional user interviews are unlikely to resolve the ambiguity. She buys an option instead: a 30-day A/B test running both feature sets simultaneously. The test provides real conversion data, and the team makes a definitive call within five weeks of the original deadlock. The cost of the test was trivial compared to the cost of three months of organisational drift.

The Hire Everyone Questioned

A growth-stage fintech founder hires a CTO from outside the industry, overriding the preference of several board members who favoured a candidate with sector-specific experience. Rather than letting the disagreement fester, he communicates the decision using the transparency protocol: he shares the evaluation criteria, the performance data from reference checks, and the strategic rationale for prioritising technical architecture skills over domain familiarity. He sets a 90-day review checkpoint. Two months in, early infrastructure improvements validate the choice, and the board members who initially objected acknowledge that the process was fair, even though their preferred outcome was not selected.

The Founder Who Could Not Stop Revisiting

An early-traction e-commerce founder finds herself re-examining every pricing decision within days of making it. She implements a gut journal: each decision is logged with the reasoning, the alternatives considered, and the expected outcome. After three months, she reviews the journal and discovers that 80% of her initial pricing calls were within 5% of what she later considered optimal. The journal transforms vague self-doubt into calibrated confidence, and her decision velocity doubles.


Anti-Patterns

The Consensus Trap. Waiting for unanimous agreement before acting is not thoroughness; it is abdication disguised as democracy. Consensus is a luxury of low-stakes decisions. For high-stakes choices, one person must own the call. Seeking input is wise; requiring permission from everyone is paralysing.

Transparency Theatre. Sharing the decision without sharing the reasoning. Announcing "we have decided to restructure the team" without explaining the criteria, alternatives, and trade-offs does not build trust -- it invites conspiracy theories. Transparency means process visibility, not just outcome notification.

The Perpetual Pilot. Using options and experiments as a permanent substitute for commitment. Buying an option is a tool for reducing uncertainty before a decision, not a strategy for avoiding decisions indefinitely. Every option must have an expiration date.

Outcome-Based Self-Flagellation. Judging a past decision harshly because the outcome was poor, without examining whether the process was sound. A founder who carefully evaluated three vendors, selected the best-qualified one, and still experienced a service failure did not make a bad decision. Punishing yourself for outcomes beyond your control trains you to avoid decisions, not to improve them.

The Silent Veto. Allowing a senior stakeholder to remain silent during deliberation and then reopen the decision after the fact. This pattern is organisational poison. It teaches the team that formal decision processes are performative and that real power operates through back channels.


By Stage

StageFocusKey Difference
IdeaSpeed over precision. Most decisions are reversible explorations.Nearly every choice is a two-way door. Apply the 70% rule aggressively. The cost of delay at this stage is existential -- runway is finite, and the venture has no momentum to sustain it through prolonged deliberation.
ValidationStructured experimentation. Convert decisions into testable hypotheses.Buy options wherever possible. Pilot before committing. The goal is learning velocity, not decision perfection. Implementation plans should be lightweight but explicit.
Early TractionEstablish decision norms for the growing team.As headcount grows, "you didn't ask me" challenges multiply. Introduce formal decision roles (RACI/RAPID) and the silence-denotes-agreement norm. Transparency protocols become essential as the founder can no longer communicate every decision personally.
GrowthDelegation architecture. The founder cannot and should not make every call.The critical skill shifts from making good decisions to designing systems that enable others to make good decisions. Implement escalation triggers, decision journals, and periodic review cadences across the leadership team.
ScaleInstitutional decision quality. Protect against bureaucratic slowdown.The risk inverts: at scale, organisations over-deliberate rather than under-deliberate. Reintroduce speed by enforcing decision deadlines, empowering frontline managers with clear decision rights, and reserving executive deliberation for genuinely irreversible choices.

Output Template

markdown
# Decision Record: [Decision Title]

**Date:** [YYYY-MM-DD]
**Decision Owner:** [Name and role]
**Stage:** [idea / validation / early-traction / growth / scale]

## Decision Statement
[One sentence: what was decided and the primary rationale.]

## Context and Alternatives Considered
| Alternative | Key Advantage | Key Risk | Reason Not Selected |
|-------------|---------------|----------|---------------------|
| [Option A] | | | |
| [Option B] | | | |
| [Option C -- selected] | | | [N/A -- this was selected because...] |

## Process Used
- **Who was consulted:** [Names and roles]
- **Data reviewed:** [Key data sources]
- **Decision method:** [Founder call / team vote / advisory input / other]
- **Reversibility assessment:** [One-way door / two-way door]

## Implementation Plan
| Milestone | Owner | Deadline | Status |
|-----------|-------|----------|--------|
| [Stakeholder communication] | | | |
| [First execution step] | | | |
| [Checkpoint review] | | | |

## Success Criteria
- [Metric 1: target and measurement method]
- [Metric 2: target and measurement method]

## Escalation Triggers
- [Condition under which this decision should be revisited]

## Review Date
[Scheduled date for formal reassessment]

Related Skills

  • Evaluating and Deciding -- The Clear Thinking framework's unified decision system covers criteria weighting, margin of safety, and the irreversibility test; this toolkit provides the complementary post-decision disciplines.
  • Tough Decision Situations -- When the problem is not paralysis but genuinely bad options, failed consensus, wrong calls, or time pressure, this companion skill provides targeted techniques.
  • Decision-Making Under Pressure -- Addresses the specific cognitive and emotional dynamics of high-stakes, time-compressed leadership decisions.
  • Learning from Failure -- Extends the "extract the lesson" principle into a full organisational learning practice.
  • Trust Equation -- The transparency techniques in this skill feed directly into the credibility and intimacy components of trust.
  • Stoic Pragmatism -- The Stoic emphasis on decisive action and practical execution aligns with the commitment discipline that prevents decision paralysis and second-guessing.

Frequently asked questions

What does the Choosing And Executing AI skill do?

Provides a toolkit for moving from deliberation to commitment and from commitment to results. Covers the cost of decision paralysis, the 70% rule for when to stop gathering information, implementation planning after the choice is made, transparency as a trust mechanism, handling challenges to decisions, and combating second-guessing through process review rather than outcome regret. Use when stuck in analysis paralysis, when a decision has been made but needs implementation momentum, when stakeholders challenge or resist a decision, when second-guessing erodes confidence, or when building a...

Why use Choosing And Executing on TypingMind?

Because you install it once and use it with any model. Choosing And Executing is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Choosing And Executing in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/fatihguner/foreman/tree/main/plugins/foreman/skills/choosing-and-executing. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Choosing And Executing?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Choosing And Executing?

As many as you like. As long as a model supports skills, you can use Choosing And Executing with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Choosing And Executing AI skill free?

Yes. It is published on GitHub by fatihguner under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇