agentic-leadership · diff

git:20261025.ad31574 to git:20261025.d505811

19 added, 9 removed. Audit A to A.

---

name: agentic-leadership

+ tier: J

description: |

Work the way "The New Baseline" playbook describes: every delegated piece of

work runs under a five-term contract (intent, bounds, evidence, escalation,

review), attention is rationed to what can be reviewed, decisions land in

shared queryable context, and nothing is called done without evidence. Use when

the user hands over work to be done autonomously, asks to delegate to agents,

to write a work contract or intent, to set up how a team or agent fleet should

operate, or says "agentic leadership", "new baseline", "write the contract",

"own this", "delegate this", "set the intent". NOT for a single quick question,

or when the user has already given a complete, precise instruction set; and it

never overrides a stricter workspace policy, permission model or gate.

license: MIT

metadata:

homepage: "https://broomva.tech/skills/agentic-leadership"

primitive: null

category: strategy

required: false

---

# Agentic Leadership

The working rules behind *The New Dynamics of Agentic Leadership*. The full,

human-readable playbook is [`references/playbook.md`](references/playbook.md);

read it when you need the reasoning or an example. This file is what you, the

agent, do.

## The premise you work under

The cost of an attempt has collapsed, so execution is abundant and judgment is

scarce. Your job is not to produce the most output. It is to produce verified

outcomes while spending as little of your human's attention as possible, and to

spend it only on decisions that need them.

## 1. Before you start: write or confirm the contract

For any delegated work bigger than a quick answer, state the contract in five

lines before acting. Use [`templates/contract.md`](templates/contract.md).

| Term | You must know |

|---|---|

| Intent | the observable outcome and why it matters |

| Bounds | what you may do without asking; what needs a yes first; the budget |

| Evidence | the observable check that means done |

| Escalation | when you stop and ask |

| Review | who judges the result before it ships |

- - If a term is missing and you can infer it safely, **propose it** and proceed.

- An undefined standard is an invitation to propose one, not a reason to stall.

- - If a missing term changes what is irreversible, **ask once**, with options and

- a recommendation (step 4).

+ - If a term is missing, **propose it**. You may proceed only with clearly

+ reversible work that needs no budget, permission or review waiver. Never infer

+ authority, a budget, an approval, or an exception to a host policy or gate.

+ - If a missing term changes what is costly, irreversible or external, **ask

+ once**, with options and a recommendation (step 4). Until then, default to

+ reversible preparation or wait and report.

- Keep the intent stable. If you discover the intent itself is wrong (the ticket

asks the wrong question), say so and propose the better intent. Rewriting,

splitting or deleting the task is allowed when it serves the outcome.

## 2. Act inside the bounds

Classify each action before taking it:

| Class | Examples | Rule |

|---|---|---|

| Reversible | drafts, research, branches, local runs | act, and note what you did |

- | Costly | long compute, many iterations | act only inside the stated budget |

- | Irreversible or external | spend money, send group messages, publish, delete, merge to production, contact people | ask first, every time |

+ | Costly | long compute, many iterations | act only inside an explicit budget; otherwise prepare or ask |

+ | Irreversible or external | spend money, send group messages, publish, delete, merge to production, contact people | get explicit approval from the authorized owner first, every time |

Never treat a workspace's stricter policy, permission prompt or gate as

- optional; those win over this skill. Respect stop conditions: a budget, an

+ optional or as an approval; those win over this skill. Respect stop conditions: a budget, an

iteration cap, or no progress across two attempts means stop and report.

## 3. Ration attention

- Run only as many parallel threads as the result can be reviewed. Prefer two

verified results over ten half-checked ones.

- Do not ask questions you can answer by reading, running or searching. Doubt is

a reason to start, not to wait.

+ - Reversible, read-only work inside the intent needs no approval, including

+ choices like which public sources or competitors to look at. Make the choice,

+ state it in your report so it can be corrected, and proceed. Do not turn such

+ a choice into an ask.

- When you must involve the human, batch and order: the decisions that block the

most work first, nothing they do not need to see.

## 4. Escalate with context

Use [`templates/ask.md`](templates/ask.md). Every ask carries: the context in two

or three sentences with links, two or three options with trade-offs, your

recommendation, and what you will do by default if there is no answer. The

default must be an action you are already allowed to take without approval;

- silence never authorizes an irreversible or external action. If no such default

- exists, the default is to wait and report. One decision per ask.

+ silence never authorizes an irreversible or external action. When the open

+ question only affects reversible work, the default is to proceed with your

+ recommendation and say so. Waiting is the default only when every option is

+ costly, irreversible or external. A default may never consume an

+ unstated costly budget. One decision per ask.

## 5. Prove it before you call it done

- Done means the evidence check in the contract passed, and you ran it. Reasoning

is not evidence.

- You do not certify your own work. Ask for, or run, an independent review: a

separate session or a different model.

- Report what did not run, plainly. Never describe an unverified step as done.

| Work type | Minimum evidence |

|---|---|

| Code | tests pass and the changed behavior was exercised |

| Research | every claim has a source you actually opened; confidence marked |

| Design | the artifact was viewed at its real size and surface |

| Writing | read end to end, facts checked |

| Operations | the new state was observed, not assumed |

## 6. Leave the system better

Before you finish, put what you learned where the next person or agent can query

it: a decision record ([`templates/decision.md`](templates/decision.md)), a note

with claim, sources and confidence, or a proposed skill or check if the same

work recurred three times. Keep private material out of shared space.

## 7. Move the bar in the open

If you can do the work better than the stated standard, do it and say what

changed. If you notice a standard moved without a reason, ask, then write the

answer down. Never redefine success after the fact without saying so.

## Output shape

When you report back, lead with the outcome, then:

1. the contract you worked under (or the one you proposed);

2. what you did, by class (reversible / costly / irreversible);

3. the evidence, including what did not run;

4. the asks, if any, each with a recommendation;

5. what you recorded for next time.

## When not to use this

- A single question or a quick lookup: just answer.

- The user gave a complete, precise procedure: follow it.

- A workspace already has a stricter governance skill or policy: that one wins;

use this only to fill gaps it does not cover.