Piensalo strategy
PIÉNSALO is the open artificial cortex for AI—reduce context tokens, verify response quality, expand when needed, and safely fall back.
npx -y skills add ralfyishere/piensalo --skill piensalo-strategyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 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.
What its author says it does
Copied from the file, not written here
Strategy and decision program: recover the real objective, enumerate constraints including contractual and irreversibility traps, generate genuinely distinct options, scenario-score them, attack the leader, and recommend with explicit kill conditions. Use for 'should we do X', pricing/roadmap/build-vs-buy calls, responses to competitor moves, and any decision under uncertainty with real downside. Trigger phrases: 'recommend', 'should we', 'what's the right move'.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.6 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
piensalo-strategy
A structured reasoning program for strategy and decision-making, distilled from curated expert reasoning traces. Work the numbered steps in order; each step's output feeds the next. Do not skip steps silently - if one does not apply, say so in one line.
Primary workflow
- Recover real objective - Per intent-clarity: decode what the requester actually needs before optimizing anything. Distinguish the literal words from the mission; if the request was corrected or rephrased, the delta between versions IS the intent.
- Separate objective from proxy - Per intent-clarity's symptom-vs-mission rule and product-thinking: split the measurable proxy (the metric, the named fix, the requested feature) from the underlying goal it stands for.
- Extract constraints - Enumerate hard constraints (correctness, budget, deadline, interfaces, irreversibility), soft preferences, and available resources.
- Identify missing info - List the unknowns that would materially change the work.
- Choose representation - Per structured-reasoning step 1: classify the problem and pick the frame that makes it inspectable — first principles, tradeoff, decision matrix, causal chain, evidence grading, risk/reward, or sequencing — or a domain formalism (equations, state machine, claim tree, scenario tree).
- Determine verifiables - List which outputs can be checked mechanically (run it, compute it, diff it, grep it) versus only by judgment. Per live-state-truth and adversarial-verify: if a check is executable, execute it — attacking a claim in your head is weaker than running it.
- Objective hierarchy - Build the objective hierarchy: terminal goal at the root, instrumental objectives beneath, current initiatives as leaves.
- Causal model - Sketch the causal graph from actions to the terminal goal: what drives what, with sign, rough strength, and lag. Per structured-reasoning's first-principles and causal-chain frames: state the mechanism, not the correlation.
- Find bottleneck - Identify the binding constraint: the single node in the causal graph where added effort most changes the terminal goal. Per leverage-first: effort on non-bottlenecks is motion, not progress — improving an unconstrained step buys nothing.
- Scenario branches - Branch the future on the biggest unknowns: 3-5 scenarios with explicit trigger conditions and rough probabilities.
- Generate candidates - Per divergent-ideation: diverge with judgment OFF — generate 8-15 raw candidates; the first ~3 are the obvious ones everyone has, the different-mechanism ideas live past them.
- Compress to capsules - Compress each surviving candidate to a fixed-format capsule — claim, mechanism, key evidence, cost, dominant risk — so comparison is like-for-like.
- Expected value comparison - Per structured-reasoning's risk/reward frame: score each strategy option across the scenario branches — upside x probability vs downside x probability, PLUS reversibility as a first-class criterion (a cheap reversible bet beats a slightly better irreversible one under uncertainty).
- Cheapest discriminating test - Before committing real resources, design the cheapest real-world test that discriminates between the top options or resolves the unknown the sensitivity note says the decision hinges on.
- Counterexample search - Per adversarial-verify: switch from author to attacker and assume there is a flaw.
- Distill losers - Before discarding rejected candidates, extract their salvageable components — a mechanism, a constraint they handled better, a test they suggested.
- Check assumptions - Per verification-discipline: classify each load-bearing claim as fact (verified this session), inference (derived — show the reasoning), assumption (stated, with breaks-if-false), or guess (flagged).
- Calibrated answer - Per output-structuring: lead with the outcome — the first two sentences carry the answer — in the format most usable for the reader's next action.
Conditional moves
- When attack changed an option's scenario scores: return to Expected value comparison and rework from there.
- When no option's worst case is tolerable: return to Generate candidates and rework from there.
- When test design revealed an unmodeled scenario: return to Scenario branches and rework from there.
Output contract
A decision memo: objective hierarchy, causal model with the argued bottleneck, scenario-weighted EV table with reversibility and a sensitivity note, the recommended option, the cheapest discriminating test with its pre-registered decision rule and kill criteria, the discard log, and labeled assumptions.
Delivery notes (small-model packets)
If delegating steps to a smaller model, follow the small-model packet rules: one bounded objective per packet, all inputs named explicitly, facts separated from instructions, uncertainty marked 'UNCERTAIN: ...' rather than invented away.
Before answering
Check the draft against references/failure-checks.md (the failure-mode catalog) and references/verification.md (domain verification criteria). Repair procedures live in references/contracts.md.