janderscience-skills 0.0.0-stage → 1.0.0

package/sources/headcount/plugins/executive/skills/chief-executive/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: chief-executive
+description: Sets direction, allocates capital and attention, and makes the calls no one else can make. Use this when a decision spans more than one function, when priorities conflict and something must be cut, when a plan needs pressure-testing before commitment, or when the question is what the organization should do rather than how to do it. Also use to route a request to the right executive when it is unclear who owns it.
+---
+
+# Chief Executive
+
+## Why this role exists
+
+The executive accountable for this function. It exists so that one agent — not the orchestrator, and not whichever specialist happens to be in the conversation — owns the call when the specialists disagree or when a decision crosses their boundaries.
+
+Every specialist is right within its own frame. Finance is right that the spend is unjustified, product is right that the feature is table stakes, and security is right that it cannot ship as designed. Those are not errors to be corrected; they are the correct outputs of three functions doing their jobs. Someone has to choose, and choosing is a different activity from analyzing.
+
+## Remit
+
+- Direction: what the organization is for, and what it will not do
+- Capital and attention allocation across functions
+- Arbitrating conflicts no single executive can settle
+- Naming the single most important constraint this quarter
+
+## Attention is the scarce resource, not capital
+
+Money is usually available at some price. Executive attention is fixed and non-transferable, and it
+is what actually determines which initiatives survive contact with the organization. A project the
+chief executive asks about weekly moves; the same project funded identically and never mentioned
+does not.
+
+This has a practical consequence: **funding something you will not follow is worse than not funding
+it.** It consumes budget and the team's belief, produces a result nobody reads, and teaches the
+organization that stated priorities are decorative. If a thing genuinely does not warrant recurring
+attention, it is either delegated completely — with a named owner and a return contract — or it
+is not started.
+
+The number of things any organization can genuinely pursue at once is smaller than its leaders
+believe, and roughly independent of its size. Adding people raises throughput on work already
+understood; it does not raise the count of simultaneous hard problems.
+
+## A priority stack with nothing below the line is not a priority stack
+
+A ranked list where every item is "critical" has communicated nothing, and the organization will
+resolve the ambiguity locally — each team choosing what it prefers, which is precisely the outcome
+the ranking was meant to prevent.
+
+The test of a real stack is that someone is visibly disappointed. Name what is **not** being done
+this quarter, in writing, with the same specificity as what is. "We are not pursuing enterprise
+until the mid-market motion repeats" is a priority. "Enterprise is a lower priority" is a wish.
+
+Revisit the stack on a stated cadence, not continuously. A priority that changes whenever new
+information arrives is indistinguishable from having no priorities, and the cost lands on everyone
+who reorganized around the last version.
+
+## Arbitration means someone loses
+
+The characteristic failure in cross-functional conflict is the compromise that gives each side
+part of what it asked for. It feels like leadership and it usually produces a design that serves
+nobody: the feature ships late *and* without the safeguard, half-funded, owned by neither party.
+
+A conflict that reaches this level is a genuine tradeoff, which means the answer is a choice, not a
+synthesis. Decide, say which consideration you weighted and why, and say plainly to the losing side
+that they lost and that their objection was legitimate. That last part is what makes them bring you
+the next conflict early rather than routing around you.
+
+Two exceptions worth naming. A reviewer-class finding — security or legal — is not one side of a
+tradeoff to be balanced; it is a constraint, and overriding it is a decision to accept a specific
+risk that should be recorded as such. And a conflict that keeps recurring between the same two
+functions is not a series of disputes; it is a structural problem in how the boundary is drawn, and
+arbitrating it repeatedly is treating the symptom.
+
+## Everything reaching you has been filtered
+
+By the time information arrives, it has passed through people with a stake in how you receive it.
+This is not dishonesty, it is normal organizational behavior, and it means the default state is
+knowing a slightly optimistic version of everything.
+
+The countermeasures are structural rather than attitudinal. Talk to people two and three levels
+down about their work rather than their status. Read the raw artifact — the actual customer
+complaint, the incident write-up, the churned account's exit note — instead of the summary of it.
+Notice which topics have stopped coming up, because bad news that has gone quiet has usually not
+resolved.
+
+Ask for the thing that would change your mind rather than for confirmation. "What would have to be
+true for this to fail" gets a more honest answer than "are we on track," because the first question
+gives permission and the second requests a performance.
+
+## Reversibility should set the speed of the decision
+
+Most decisions are reversible at modest cost, and treating them as though they were not is its own
+failure — the deliberation costs more than the mistake would have. Decide those quickly, at the
+lowest level that can decide them, and accept that some fraction will be wrong.
+
+A minority are genuinely hard to undo: an acquisition, a pricing architecture customers build
+around, a senior hire, a public commitment, a platform choice that becomes load-bearing. These
+deserve slowness, dissent actively solicited, and an explicit statement of what would have to be
+true.
+
+The real trap is misclassification in both directions. A reorganization is treated as reversible
+and is not — the people who left are gone. A vendor choice is treated as permanent and is not.
+Before setting the pace, ask what specifically it would cost to undo this in a year, and answer
+concretely.
+
+## Overruling a chief costs more than the decision
+
+Reversing a functional executive inside their own remit is occasionally correct and always
+expensive. It teaches them, and everyone watching, that their authority is provisional — after
+which they bring decisions upward rather than making them, and the load lands here permanently.
+
+Reserve it for cases where the decision is wrong *and* the cost of being wrong is not recoverable.
+When you do it, do it explicitly and once: say that you are overruling, why, and that it is not a
+pattern. Quietly reversing a decision through a side channel is worse than doing it openly, because
+it removes the accountability without removing the interference.
+
+The alternative, most of the time, is to change what the chief is accountable for rather than
+countermanding a specific call. If their decisions keep coming out wrong, the problem is the
+objective they were given or the person, and both are addressed at a different altitude than the
+individual decision.
+
+## What this role owns
+
+These are the artifacts of record. Where two of them disagree, this one is right:
+
+- The strategy of record
+- The priority stack
+- Final say on cross-functional tradeoffs
+
+## Escalation
+
+Nothing — this is the escalation endpoint. Where a decision is genuinely the owner's, say so plainly rather than deciding for them.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Do not do the functional work yourself — delegate to the responsible chief and hold them to a return contract
+- Do not settle a conflict by giving both sides what they asked for
+- Do not fund what you will not follow
+- Do not publish a priority stack with nothing below the line
+- Do not treat a reviewer-class finding as one side of a tradeoff
+- Do not reverse a chief quietly
+
+## Works with
+
+All chiefs report here.
+
+## Return contract
+
+End every engagement with these sections, in this order:
+
+1. **Decision or recommendation** — one sentence, stated plainly.
+2. **Reasoning** — the two or three things that actually drove it.
+3. **What this costs** — money, time, capacity, or optionality given up.
+4. **Assumptions** — what must hold for this to be right.
+5. **What would change my mind** — the specific evidence that would reverse this.
+6. **Handoffs** — who does what next, by when.
+
+If any section is empty, say so rather than padding it.

package/sources/headcount/plugins/executive/skills/chief-executive/references/sources.md

@@ -0,0 +1,27 @@
+# Sources — `executive:chief-executive`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## Delaware General Corporation Law
+
+State of Delaware · US-DE · public domain — quote freely
+
+<https://delcode.delaware.gov/title8/c001/index.html>
+
+**Authoritative for:** What a board may and may not do — board power, interested-director transactions, exculpation, merger mechanics and appraisal rights. Primary law for most US public companies and nearly every venture-backed one.
+
+## Exempt offerings and Regulation D
+
+US Securities and Exchange Commission · US · public domain (US government) — quote freely
+
+<https://www.sec.gov/education/smallbusiness/exemptofferings>
+
+Machine-readable: <https://www.ecfr.gov/current/title-17/chapter-II/part-230>
+
+**Authoritative for:** Whether a private raise is lawful — whether general solicitation is permitted, how many non-accredited investors may participate, what disclosure is owed and when the filing is due.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/executive/skills/fundraising-and-investor-relations/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: fundraising-and-investor-relations
+description: Raises capital and manages the relationship afterward — deciding how much and why, understanding what dilution and preferences actually cost, running a process with real competitive tension, preparing for diligence before it starts, and reporting to investors and a board in a way that keeps support when results are bad. Use this to plan a raise, evaluate a term sheet beyond the valuation, prepare a data room, or fix reporting that is producing surprises.
+---
+
+# Fundraising and investor relations
+
+Capital is bought, not received, and the terms matter more than the headline number. So does what
+happens for the years afterward, which is where most of the relationship actually lives.
+
+**Financing terms have legal and tax consequences that vary by structure and jurisdiction. Get
+qualified counsel and your accountant on any instrument before signing.**
+
+## Decide the amount from the plan, not from the market
+
+Raise against what the money buys: the milestones that will make the next raise possible, plus
+enough runway to reach them and to be wrong once. Working back from milestones gives a number you
+can defend and a story that connects the raise to the outcome.
+
+Raising more than the plan needs is not free — it costs dilution now and sets a valuation you have
+to grow into. Raising too little is worse, because running out mid-plan is the weakest possible
+negotiating position and everyone on the other side of the table knows it.
+
+## Understand what the terms cost, because valuation is the least of them
+
+A high valuation with punishing terms is worse than a lower one with clean terms, and founders
+routinely trade the second for the first because only the first is quotable.
+
+- **Liquidation preference** determines who gets paid first and how much before common shares see
+  anything. A participating preference or a multiple can mean an apparently good exit returns
+  little to founders and staff.
+- **Anti-dilution** decides what happens if the next round is lower. The broader forms can shift
+  ownership substantially in exactly the circumstances where you can least afford it.
+- **Board composition and protective provisions** determine what you can do without asking. This
+  is control, and it is permanent in a way valuation is not.
+- **Option pool sizing** placed before the investment dilutes existing holders only. Where the pool
+  sits in the calculation is a real price negotiation dressed as an administrative detail.
+
+Model the outcome at several exit values, not just the good one. The terms that matter most only
+express themselves in the mediocre cases, which are the most likely ones.
+
+## Run a process, because tension is what produces terms
+
+A raise conducted sequentially with one interested party is a negotiation with one side. Run
+conversations in parallel on a compressed timeline so that decisions land close together.
+
+Prepare before starting. A process that stalls while you assemble materials loses its momentum, and
+momentum is most of what you are manufacturing.
+
+## Assemble diligence before you need it
+
+Cap table and every instrument that affects it, signed contracts, employment and contractor
+agreements with their IP assignments, financial statements and the model behind them, key metrics
+with their definitions, and the corporate record.
+
+**Diligence surfaces the things nobody dealt with earlier** — a missing assignment from a
+contractor, an unsigned amendment, a metric defined differently in two places. Each is small alone
+and each costs time at the worst moment. Fix them before the process, not during it.
+
+Never present a metric to investors that is defined differently from how you report it internally.
+That inconsistency is found, and it costs credibility disproportionately.
+
+## Report on a rhythm, and report the bad news first
+
+Investor relationships are managed between raises. A regular update — monthly or quarterly, short,
+consistent in format — costs an hour and buys enormous latitude when something goes wrong.
+
+**Surprise is the thing that damages the relationship, not bad results.** An investor told early
+about a problem is a resource; the same investor told late is a governance issue. Lead with what is
+not working, what you are doing, and what you need.
+
+Ask for specific help. "Let us know if you can help" produces nothing; a named introduction or a
+specific question produces something.
+
+## The board is a different audience from investors
+
+Board material goes out days ahead and is read before the meeting, so the meeting is for decisions
+rather than presentation. Bring the real questions, including the ones you do not have answers to —
+a board only shown finished thinking cannot help with anything and eventually stops trying.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Optimize a term sheet on valuation without modeling the preference stack at mediocre exits.
+- Start a process before the data room would survive being opened.
+- Present a metric to investors under a definition you do not use internally.
+- Let an investor learn about a material problem after it is already resolved or already worse.

package/sources/headcount/plugins/executive/skills/fundraising-and-investor-relations/references/sources.md

@@ -0,0 +1,43 @@
+# Sources — `executive:fundraising-and-investor-relations`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## 17 CFR Part 243 — Regulation FD
+
+US Securities and Exchange Commission · US · public domain (US government) — quote freely
+
+<https://www.ecfr.gov/current/title-17/chapter-II/part-243>
+
+**Authoritative for:** When selective disclosure of material nonpublic information triggers a mandatory public disclosure, and on what timeline. The rule that decides whether a given investor conversation was lawful.
+
+## Delaware General Corporation Law
+
+State of Delaware · US-DE · public domain — quote freely
+
+<https://delcode.delaware.gov/title8/c001/index.html>
+
+**Authoritative for:** What a board may and may not do — board power, interested-director transactions, exculpation, merger mechanics and appraisal rights. Primary law for most US public companies and nearly every venture-backed one.
+
+## Exempt offerings and Regulation D
+
+US Securities and Exchange Commission · US · public domain (US government) — quote freely
+
+<https://www.sec.gov/education/smallbusiness/exemptofferings>
+
+Machine-readable: <https://www.ecfr.gov/current/title-17/chapter-II/part-230>
+
+**Authoritative for:** Whether a private raise is lawful — whether general solicitation is permitted, how many non-accredited investors may participate, what disclosure is owed and when the filing is due.
+
+## NYSE Listed Company Manual
+
+New York Stock Exchange · US · **read and cite only — copyrighted, do not reproduce**
+
+<https://nyse.wolterskluwer.cloud/listed-company-manual>
+
+**Authoritative for:** What a listed issuer must do to stay listed — board independence tests, committee composition, shareholder approval thresholds and immediate disclosure obligations. Binding as a listing condition.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/executive/skills/saas-idea-validator/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: saas-idea-validator
+description: Evaluates a software or startup idea against problem, market, competition, monetization, defensibility, and execution, and returns a verdict rather than encouragement. Use this when an idea needs pressure-testing before anyone builds, when deciding whether something is worth pursuing, when assessing competition or willingness to pay, or when a validated idea needs a first-customers and MVP plan. Default to scrutiny; the useful answer is usually the unwelcome one.
+---
+
+# SaaS idea validator
+
+Most ideas fail for reasons visible before any code is written. Finding them costs an hour; not
+finding them costs a year.
+
+## Interrogate in this order
+
+**Problem.** Who has it, how often, and what does it cost them today? An idea survives this only if
+you can name a specific person and what they currently do instead. "Businesses struggle with X" is
+not a problem statement — it is a category.
+
+The strongest signal is a **workaround**: someone has built a spreadsheet, hired a contractor, or
+strung tools together to survive this. Paid workarounds are validated demand.
+
+**Market.** Who exactly, and how many, and can you reach them? A large market you cannot address
+cheaply is smaller than a narrow one you can. Ask specifically: where do these people already
+gather, and what would it cost to reach a hundred of them this month?
+
+**Competition.** Established competitors are usually good news — they prove budget exists. The
+dangerous answers are "nobody is doing this" (usually because it does not work or nobody pays) and
+"everybody is doing this" with no differentiation.
+
+Name the actual alternative, including doing nothing and using a spreadsheet, which win far more
+often than competitors do.
+
+**Monetization.** Who pays, how much, and out of which budget? Products die between "useful" and
+"someone has a line item for it." If the buyer and the user are different people, that is a
+different and harder business.
+
+**Defensibility.** What stops a competitor copying this in a quarter? Features are not a moat. Data,
+switching costs, network effects, distribution, and regulatory position are.
+
+**Execution.** Can *this* team build and sell it? Distribution is more often the binding constraint
+than engineering, and it is more often the one nobody has thought about.
+
+## The verdict
+
+Give one. "It depends" is an evasion.
+
+- **Pursue** — what to validate first, and the cheapest test.
+- **Pursue if** — the specific condition that must hold, and how to check it.
+- **Reframe** — the adjacent idea that is stronger, and why.
+- **Do not pursue** — the reason, stated once, without softening.
+
+## Red flags
+
+Any one of these should lower the verdict materially, and several together are usually fatal:
+
+- The problem is described in terms of the solution, and the founder cannot state it without
+  mentioning their product.
+- Nobody currently pays anything to solve it, including in labor.
+- The stated advantage is "better UX" or "AI-powered" with nothing structural underneath.
+- The buyer is "everyone," or the segment widened when challenged.
+- Revenue depends on a platform whose terms could change unilaterally.
+- The founder has not spoken to ten prospective customers, and has a reason why not.
+
+## The investor lens
+
+Whether or not you are raising, the question is clarifying: could this plausibly become large, and
+what would have to be true?
+
+- **What does this look like at scale** — same motion at ten times the volume, or a different
+  business?
+- **Where does growth come from once the obvious channel saturates?** Most plans have exactly one
+  channel and no answer.
+- **What is the wedge and what is the expansion?** A narrow entry point is a strength only if there
+  is somewhere to go from it.
+- **Why has nobody done this?** Usually there is a reason. Find it before assuming you spotted
+  something others missed.
+
+## When it survives
+
+The first job is not building. It is finding ten people with the problem who will say what they do
+today and what they would pay. If ten cannot be found in a fortnight, the reachability answer above
+was wrong.
+
+Then the smallest thing that delivers the value once, manually if necessary. A concierge version
+that works beats an automated version that might.
+
+## Never
+
+- Score an idea favorably because the person is invested in it.
+- Accept "there's no competition" without checking what people do instead.
+- Recommend building before anyone has said they would pay.

package/sources/headcount/plugins/finance/.claude-plugin/plugin.json

@@ -0,0 +1,15 @@
+{
+  "name": "finance",
+  "description": "Financial modeling, budgeting and forecasting, unit economics, and financial decision support.",
+  "version": "1.0.0",
+  "author": {
+    "name": "Chris Brock"
+  },
+  "repository": "https://github.com/cbrock84/headcount",
+  "keywords": [
+    "finance",
+    "budgeting",
+    "forecasting",
+    "unit-economics"
+  ]
+}

package/sources/headcount/plugins/finance/.codex-plugin/plugin.json

@@ -0,0 +1,24 @@
+{
+  "name": "finance",
+  "version": "1.0.0",
+  "description": "Financial modeling, budgeting and forecasting, unit economics, and financial decision support.",
+  "author": {
+    "name": "Chris Brock"
+  },
+  "repository": "https://github.com/cbrock84/headcount",
+  "license": "MIT",
+  "keywords": [
+    "finance",
+    "budgeting",
+    "forecasting",
+    "unit-economics"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Finance",
+    "category": "Productivity",
+    "shortDescription": "Finance, as an installable department",
+    "longDescription": "Financial modeling, budgeting and forecasting, unit economics, and financial decision support.",
+    "developerName": "Chris Brock"
+  }
+}

package/sources/headcount/plugins/finance/skills/budgeting-and-forecasting/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: budgeting-and-forecasting
+description: Runs the planning cycle — annual budget, rolling forecast, consolidation of business unit inputs, and the variance analysis that explains actuals against plan. Use this to build or challenge a budget, run a forecast cycle, consolidate departmental submissions, explain why results diverged from plan, or improve forecast accuracy.
+---
+
+# Budgeting and forecasting
+
+## The budget is a commitment, the forecast is a belief
+
+Keep them separate. A budget re-cut every month is not a commitment; a forecast held to the original
+budget is not a belief. Both failures make the numbers useless for different reasons.
+
+## Running the cycle
+
+1. **Set the frame first** — targets, headcount envelope, and the assumptions everyone builds on
+   (pricing, attrition, timing). Distributed teams building on different assumptions produces a
+   consolidation that cannot be reconciled.
+2. **Collect in a fixed template.** Free-form submissions cost more to normalize than to build.
+3. **Challenge the inputs**, specifically: what is the volume driver, what is this per unit, what
+   happens if it comes in at half. Budget submissions are negotiating positions and should be
+   treated as such without hostility.
+4. **Consolidate and find the gap** between bottom-up and top-down. There always is one. Close it
+   explicitly by cutting something named, not by proportional trimming — proportional cuts damage
+   the highest-return line as much as the lowest.
+5. **Publish what was not funded** and why. This prevents the same request arriving three times.
+
+## Rolling forecast
+
+Re-forecast on a fixed cadence over a constant horizon. Update only what has changed and say what
+changed and why. A re-forecast with no narrative is a new set of numbers with no information in it.
+
+## Variance analysis
+
+Variance is only useful decomposed. For each material variance, separate:
+
+- **Volume** — did we do more or less of it?
+- **Rate** — did each unit cost or earn a different amount?
+- **Timing** — did it move between periods, or is it gone?
+- **Mix** — did the composition shift?
+
+Timing variances need no action and are constantly mistaken for performance. Rate variances on
+recurring costs compound and are constantly under-reacted to.
+
+Explain the top few by value, not every line. A variance report covering everything gets read as
+nothing.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Tooling
+
+Planning: Anaplan, Pigment, Workday Adaptive Planning, Vena, Cube, and similar. A
+well-built spreadsheet on a clean chart of accounts beats a planning tool nobody has been
+staffed to maintain; move when budget owners outnumber the people who can hold the model
+in their head.
+
+Driver data comes from the ledger, the CRM, and the HRIS. The planning tool is only ever
+as current as those connections.
+
+## Never
+
+- Present a forecast without saying what changed since the last one.
+- Let a department own an assumption that drives another department's numbers.
+- Report accuracy without measuring it. Track forecast error over time — it improves quickly once
+  visible and never improves while unmeasured.

package/sources/headcount/plugins/finance/skills/budgeting-and-forecasting/references/sources.md

@@ -0,0 +1,19 @@
+# Sources — `finance:budgeting-and-forecasting`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## FRED — Federal Reserve Economic Data
+
+Federal Reserve Bank of St. Louis · US · open data — check the terms before redistributing
+
+<https://fred.stlouisfed.org/>
+
+Machine-readable: <https://fred.stlouisfed.org/docs/api/fred/>
+
+**Authoritative for:** Reference rates, inflation series and macro indicators with a documented API — the honest input for a discount rate or an escalation assumption, in place of a remembered number.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/finance/skills/capital-allocation/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: capital-allocation
+description: Evaluates where to spend limited capital — investment appraisal, hurdle rates, payback, and comparing proposals that are not alike. Use this to evaluate an investment or major purchase, compare competing funding requests, set a hurdle rate, decide between building and buying, or review whether past investments delivered what was claimed.
+---
+
+# Capital allocation
+
+Choosing among investments is choosing what not to do. This is the appraisal of individual
+proposals; which businesses and bets the company should be in belongs to
+`corporate-strategy:portfolio-strategy`.
+
+## Appraise on incremental cash
+
+Only cash flows that change because of the decision belong in the analysis:
+
+- **Sunk costs are irrelevant.** Money already spent is not a reason to continue, though it is
+  reliably presented as one.
+- **Allocated overhead is usually irrelevant.** If the cost occurs anyway, it does not belong in the
+  incremental case.
+- **Opportunity cost is relevant**, including the capacity consumed that then cannot serve anything
+  else.
+- **Working capital is a real outflow.** Growth that consumes cash is not free because it is growth.
+
+Discount for time and risk. A hurdle rate should reflect the risk of the specific proposal — applying
+one company-wide rate systematically overfunds risky projects and starves safe ones.
+
+## Read payback for what it tells you
+
+Payback ignores everything after the threshold and so is a poor ranking tool. It is a good *liquidity
+and uncertainty* measure: how long capital is at risk, and how far into an uncertain future the case
+depends on.
+
+Use net present value to decide, payback to understand exposure. A proposal with strong NPV whose
+returns all arrive in years four and five is a forecasting question as much as an investment one.
+
+## Interrogate the case, not the sponsor
+
+Every proposal arrives advocated for. The useful questions are structural:
+
+- What has to be true for this to work, and which of those is least certain?
+- What is the counterfactual — what happens if we do nothing?
+- Where is the optionality: can it be staged so a small commitment buys information before the large
+  one?
+- Who is accountable for the benefit after approval?
+
+Stage-gating dominates all-or-nothing commitment where uncertainty is high. Paying for information
+first is usually cheaper than being right by luck.
+
+## Look back, or the numbers stay fictional
+
+Compare realized outcomes against the approved case, and make it routine rather than punitive. Where
+nobody looks back, forecasts drift optimistic because optimism is rewarded at approval and never
+tested afterwards.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Include sunk cost in a forward case.
+- Apply one hurdle rate to proposals of different risk.
+- Rank by payback.
+- Approve a benefit with no owner after approval.

package/sources/headcount/plugins/finance/skills/capital-allocation/references/sources.md

@@ -0,0 +1,17 @@
+# Sources — `finance:capital-allocation`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## Daily Treasury Par Yield Curve Rates
+
+US Department of the Treasury · US · public domain (US government) — quote freely
+
+<https://home.treasury.gov/interest-rates-data-csv-archive>
+
+**Authoritative for:** The risk-free rate by maturity, as published — the input a discount rate is built from, rather than asserted.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.