Install
$ agentstack add skill-romainsimon-skills-for-decision-making-reading-rivals ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Reading rivals
The mistake is treating a competitor's behaviour as weather. It is not: they respond to you. A move evaluated against their current behaviour is evaluated against a world that will not exist once you make the move.
Three questions, in this order:
- What are they actually optimising? (usually not what you assume)
- What is their best response to our move?
- Where does the exchange of responses end up, and is that end state acceptable?
Question 3 is the one people skip, and it is where price wars come from.
Workflow
- [ ] 1. Infer what they optimise, from what they have done
- [ ] 2. Build the payoff table for the moves in play
- [ ] 3. Check for a dominant strategy and an equilibrium
- [ ] 4. Check whether responses cycle
- [ ] 5. Adjust for the fact that they are not perfectly rational
- [ ] 6. Decide whether to play the game or change it
1. Infer what they optimise
Do not assume they maximise profit. Observed behaviour reveals the objective, and a rival funded for growth, optimising for logo count, or run by someone who wants to sell in eighteen months will make moves that look irrational against a profit objective and are perfectly rational against theirs.
Method: list their last five or six visible moves and ask which objective makes all of them sensible at once. See references/inferring-objectives.md. Getting this wrong makes every subsequent step wrong, because you will be computing best responses to the wrong payoff.
2. Build the payoff table
Two players, two to three moves each. Larger tables are not more accurate, only harder to fill in, and every cell you cannot source is a number you invented.
{
"players": ["us", "rival"],
"actions": { "us": ["hold", "cut"], "rival": ["hold", "cut"] },
"payoffs": {
"hold|hold": [100, 100], "hold|cut": [55, 130],
"cut|hold": [130, 55], "cut|cut": [70, 70]
}
}
Payoffs are annual profit contribution, same unit for both players. Estimate theirs from their pricing, their headcount, and public signals; it will be rough, and rough is enough because the structure usually determines the answer rather than the exact numbers.
Sanity check: perturb every payoff by 20% and re-run. If the conclusion changes, your answer is coming from your guesses about their business rather than from the strategic structure, and you should say so.
3. Dominant strategy and equilibrium
node scripts/calc.js game market.json
Input shape: examples/game.json. Read in this order:
- Dominant strategy - a move that is best whatever they do. Rare, and decisive when
present. If you have one, play it and stop analysing.
- Pure Nash equilibrium - a pair where neither side gains by moving alone. This is
where the exchange settles. The prisoner's dilemma structure, in which both sides cut and both end up worse than if both had held, is extremely common in pricing and it is worth recognising by name.
- No pure equilibrium - the interaction is inherently unstable and the sensible play
is mixed, meaning unpredictable. Do not be reliably matchable.
4. Do responses cycle?
The tool runs iterated best response and reports whether it settles or cycles.
A cycle is a real finding, not a failure of the method. In pricing, a cycle is a price war: each side responds to the last move, nobody reaches a stable position, and the joint payoff falls with every round. If the tool reports a cycle, the answer is almost never to play the first move faster.
5. They are not perfectly rational
Nash equilibrium assumes every player computes the equilibrium and believes the others will too. Real competitors do not, for good reasons: which equilibrium is unclear when there are several, the computation is hard, and even a rival who could do it may doubt that you can.
The level-k model captures this. Level 0 acts arbitrarily; level 1 responds to level 0; level 2 responds to level 1. Most commercial actors operate at level 1 or 2.
node scripts/calc.js game market.json --level 1 --lambda 2
If you have observed history, observedCounts in the input file computes the best response to their empirical action frequencies. That is usually a better forecast than the equilibrium: a rival who has held price nine times out of eleven will probably hold again, whatever the equilibrium says.
6. Play the game, or change it
If the equilibrium is bad for both of you, the winning move is usually not a better move inside the game. It is a different game. Options, roughly in order of how often they work:
- Change the axis. Compete on something where your payoffs differ - segment,
distribution, integration depth, speed. A prisoner's dilemma on price is not a prisoner's dilemma on positioning.
- Change the payoffs. Long contracts, switching costs and bundles alter the cells,
and altering the cells is worth more than playing the existing ones well.
- Change the information. Being visibly committed to a position - published pricing,
a public guarantee - removes your own option to cut and can make holding credible for both sides.
- Accept the equilibrium and be efficient. If cutting is dominant for both, the
market is heading to a lower price and the winner is whoever gets there with the lower cost base. Plan for that rather than pretending otherwise.
Output template
## What they optimise
Evidence, heaviest first:
Falsifiable prediction:
## Payoff table
Unit:
| | rival A | rival B |
|---|---|---|
| **us A** | x, y | x, y |
| **us B** | x, y | x, y |
Sensitivity: perturbing every cell by 20% change the conclusion.
## Structure
Dominant strategy: Pure Nash: Iterated best response:
Shape:
## Near-term forecast
## Recommendation
Gotchas
- Zero-sum framing is usually wrong. Most software markets are growing, so both
players can gain. Assuming zero-sum manufactures aggression that the payoffs do not support. Check whether your table actually sums to a constant before reasoning as if it does.
- Do not assume they optimise profit. See step 1. Getting the objective wrong makes
every best response wrong.
- Equilibrium is a prediction of the destination, not the route. It says where an
exchange of responses ends, not what they do next quarter. For "next quarter", use observed frequencies.
- Iterated best response can cycle, and the cycle is the finding.
- A visible payoff table changes the game. If your analysis leaks, you have handed
them your reasoning. Treat it as confidential in the ordinary way.
- Two players is a modelling choice. If the market has five real players, a two-player
table can still be useful with "everyone else" as the second player, but say that is what you did.
- Small players are not always playing. A rival with 2% share may not be modelling you
at all. Modelling them as a strategic actor overstates the threat and can trigger responses that create a competitor where there was none.
Reference
references/inferring-objectives.md- reading an objective from observed behaviourreferences/market-structures.md- the recurring game shapes in software markets, and what each implies
Related skills
- framing-decisions for the move itself, once you know how they will respond
- stress-testing-plans to check the plan against their most damaging plausible response
- tracking-beliefs for updating your model of them as they act
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: romainsimon
- Source: romainsimon/skills-for-decision-making
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.