soft-skills 2.1.0

package/plugins/soft-skills/skills/ai-to-delegated/configurations/pair-programming.md

@@ -0,0 +1,72 @@
+---
+name: pair-programming-team
+shape: Team
+description: Pairs peers who agree on a plan, then implement and review once.
+---
+
+# Pair-Programming Team Pattern
+
+Before dispatching, read [delegate coordination](../coordination/delegates.md). When briefing participants without shared context, read [fresh-context briefing](../briefing/fresh-context.md).
+Participants: read [peer coordination](../coordination/peers.md) before working together.
+
+This team structure is somewhat different in that the teammates' slots shape are vertical, not horizontal. The pair is best for taking a feature through the whole dev cycle from start to finish. This means they wear different hats as they progress through planning, implementing, reviewing and shipping. Neither is "an implementer" or "a reviewer". They're both planners engaging in dialectic discussion at first; they then fan out writing code; review each other's work; and wrap up.
+
+Use this when a task is small-to-medium, well-scoped, and would benefit from a second mind on the *plan* more than on the code. Two peers agree on an approach before anyone writes a line, then one implements and the other reviews once. It is a single pass, not a ping-pong loop.
+
+## Shape
+
+Create a two-teammate team of equals. Neither is designated implementer up front — they decide between themselves during planning.
+
+1. **Plan together, freely.** Before any implementation, the two discuss the approach in free flow. They are explicitly told to surface low confidence: when either is unsure about a direction, they say so — including about a point they themselves proposed. Uncertainty is information, not weakness.
+2. **Agree explicitly.** The planning phase ends with a stated agreement, not a drift into coding. One teammate then starts implementing; the other waits.
+3. **Review once.** When the implementer says it is done, the other reads what was written and reviews it.
+4. **One judgement call, then stop.** The implementer takes the review, decides what to act on, does that turn, and the team is finished. No second review round.
+
+## Shared compass
+
+Give the team one explicit tiebreaker: **simplicity, and no accidental sub-adventures.** Scope creep is the named failure mode. When two directions are otherwise comparable, the simpler one wins by default.
+
+## Review scope
+
+The review is deliberately light. Aim for one to three low-hanging fruits, and say so in the prompt — otherwise reviewers escalate into exhaustive audits.
+
+In scope: bugs that are fairly obviously true positives; clean, declarative code and architecture; simplicity used as the means to elegance and to collapsing complexity.
+
+Out of scope: heavyweight, NASA-grade review.
+
+## Reviewer tone
+
+The reviewer advises; it does not adjudicate. It should not state hypotheses or extrapolations as facts. Have it load a tone-softening skill if the environment has one, and load [peer-review](../../peer-review/SKILL.md) regardless. Both teammates load `peer-review` at the start — the roles are not fixed until they agree, and the reviewing frame improves the planning discussion too.
+
+## Context floor
+
+Tell them what they need and nothing more:
+
+1. The goal, in the user's framing.
+2. Any variant or approach already ruled out — state it, so they don't rediscover it.
+3. What to leave out. Upstream conversation that is irrelevant to their task is noise; strip it rather than dumping the transcript.
+
+## Tone of the prompt
+
+Write to them the way you would talk to a colleague, not as a spec. A strict, clause-numbered brief makes them literal and brittle; conversational framing preserves the judgement you spawned two peers to get.
+
+## Team prompt template
+
+When sending this template, resolve its relative file paths from this file's directory.
+
+```text
+Load the project context skill with the same arguments I used, then load `ai-to-leader`, the peer conduct in `../coordination/peers.md`, and `peer-review`. Reviewer: also load the tone-softening skill if there is one.
+
+You two are a pair-programming team. The goal is: <goal in the user's framing>.
+Avoid <ruled-out approach>, we already decided against it.
+
+Talk the plan through first, in free flow. When either of you is less confident about a direction, say so — whether it's a point you made yourself or one your teammate made. Your compass as a team is simplicity, and not wandering into new sub-adventures along the way.
+
+Once you explicitly agree on a plan, one of you implements while the other waits. When the implementer is done, the other reads the work and reviews it: obvious bugs, clean and declarative code and architecture, simplicity as a way to collapse complexity. Just 1-3 low-hanging fruits — not a NASA-grade review. Reviewer, keep it advisory; don't state hypotheses or extrapolations as facts.
+
+Implementer, make a judgement call on the review, do that turn, and you're done. No more ping-pong.
+```
+
+## When not to use
+
+If there is a measurable target and a real search space, you want the [hillclimber–watcher pattern](hillclimber-watcher/protocol.md) instead. If the work is trivial or purely exploratory, one agent is enough. This pattern earns its keep when a wrong plan is expensive and a wrong line of code is cheap.

package/plugins/soft-skills/skills/ai-to-delegated/configurations/research-fanout.md

@@ -0,0 +1,38 @@
+---
+name: fanned-out-research
+shape: Parallel subagents
+description: Example of how independent user requirements map to parallel read-only research subagents.
+---
+
+# Simple Fanned-out Research Delegation Example
+
+Before dispatching, read [delegate coordination](../coordination/delegates.md). For recipients without shared context, read [fresh-context briefing](../briefing/fresh-context.md).
+
+The following is an "easy" case, because the subagents' graph maps cleanly to the user message's structure. User basically hands you the graph shape while specifying their requirements.
+
+In terms of systems/domains, the user describes two worlds: the project where the session lives, and Pi.
+
+<example-user-message>
+$PWD is a fork of a Pi extension called `btw`. a slash command for ephemeral side question. Pi is ~/.pi/AGENTS.md. agent harness. i have taken a screenshots of what the current experience is (behavior). it's pretty bare-bones. 
+1. at the minimum, i want a better waiting experience. 
+  1.a. at the minimum of the minimum, a braille animation. but open to other ideas. 
+  1.b. (better) something that solves the problem outright is finding whether it's possible to stream the btw response, and not wait until it's 100% finalized. 
+2. i'm not sure the response renders markdown. Pi has a built in markdown renderer out of the box.
+3. the btw response hides real chat events. the longer the response is, the more real chat is hidden (from the end). the btw response should be concatenated BELOW the real chat, not displayed over it.
+4. Simple UI concern: currently it's not obvious at a glance where the "real" last agent response ends and where the btw response starts. one needs to be able to tell them apart reflexively.
+
+[Image #1]
+[Image #2]
+[Image #3]
+</example-user-message>
+
+Among the two world (project and Pi), the user has broken down the project world into ~4-5 sub-domains, asked to map them to the Pi world, and find better solutions Pi may provide.
+
+Therefore:
+<trivial-research-fanout>
+// read-only, doesn't involve thinking or forming opinions, orthogonal -> fan-out parallel small models.
+1. dispatch 4 read-only fast & cheap models in parallel with the simple question - where's the code responsible for each of 1–4 (respectively), and what it touches downstream/upstream.
+
+// two tasks disguised as one: research first, then figure out a better, feasible solution. the second half implies product thinking and making judgment calls -> big model.
+2. after they return, dispatch a big model (same model and thinking level as you are) to follow ~/.pi/AGENTS.md and study the Pi docs to ground the current implementation in the appropriate doc space, AND bring back referenced information about potential elegant solutions to the issues. other components. other approaches. or similar approaches just better implemented. everything goes.
+</trivial-research-fanout>

package/plugins/soft-skills/skills/ai-to-delegated/coordination/delegates.md

@@ -0,0 +1,41 @@
+---
+name: delegates
+description: Supervise delegates without taking over their scope, and handle approvals, escalations, and context limits.
+---
+
+# Coordinate Delegates
+
+Read this before dispatching and while supervising delegates.
+For your own reports and requests for approval, read [ai-to-leader](../../ai-to-leader/SKILL.md).
+If your delegates lead their own agents, also read [leading-leaders.md](leading-leaders.md).
+If you need to brief a delegate without shared context, read [fresh-context.md](../briefing/fresh-context.md).
+
+## Leader conduct: a delegate’s scope is not yours
+
+Your fingers are delegation buttons. Do not row, raise sails, or scout ahead yourself unless your own leader instructs you to do so. Delegate the operational work to your delegates.
+
+Avoid the helicopter parenting failure mode: Whatever you delegated is not yours until it returns. While a delegate works, do not do its work, do not re-read the files it is writing “just to make sure everything is okay,” and do not run its code and tests yourself to “make sure they really work.” Do not continuously poll its status either. Trust your delegate, exactly as your leader trusts you. Answer escalations, steer on exception, then step back out. This applies per delegated scope, however small the delegation.
+
+## The escalation bar
+
+The chain processes at every rung: each agent surfaces to its leader only what needs the leader’s judgment. Reversible implementation tuning is yours to decide. What legitimately goes up: product-visible behavior, money, direction and scope changes, non-trivial cross-scope decisions, and blockers.
+
+**Batch approvals.** When you expect several approvals to arrive close together, hold them and bring one grouped request. One decision session beats three interruptions. A lone question does not wait for company.
+
+**Suggest, then get approval.** If you intend to dispatch delegates of your own, you may propose a delegation shape, but your leader must approve it before you dispatch anyone.
+
+## Understand an Escalation Before Passing It Up
+
+**If you cannot explain the escalation, the question goes back down, not up.** You are a translator between decks, not a relay. When a delegate’s escalation is saturated with internal jargon you cannot ground in product terms, ask the delegate for the missing context first. Forwarding it upward verbatim is a chain-of-command failure even though the message flowed through the right rungs.
+
+### Heavy delegation
+
+When doing heavy delegation (multiple serial runs of heavy concurrent shapes for a complex, large task scope), avoid micromanaging pitfalls such as re-reading files your sub-agents wrote or edited "just to make sure everything is okay," running the code and tests yourself to "make sure they really work," and reading files before prompting a sub-agent when your sub-agents should read them to finish their tasks, "just to have the right context yourself.". Verify with the user whether they consider what you’re doing as "heavy delegation."
+
+### Keep your ship afloat
+
+These are the warning signs to watch for while supervising delegates. For your own context limits, read [ai-to-leader](../../ai-to-leader/SKILL.md).
+
+Besides checking your own context window, check your delegates’ window opportunistically. Don’t manage their windows; just keep an eye out. Your delegates already know how to take care of their own context windows. Your role in this subject is narrow — a safety net in case one of your delegates races across 85–90% obliviously (never mentioning its context window status, not intending to write a handoff doc.) In that case, nudge it to write a handoff doc. If your delegate hasn’t written one and has used >95% of its window, interrupt it and ask for a handoff doc.
+
+When a delegate needs to write a handoff, direct it to the [handoff skill](../../handoff/SKILL.md).

package/plugins/soft-skills/skills/ai-to-delegated/coordination/leading-leaders.md

@@ -0,0 +1,55 @@
+---
+name: leading-leaders
+description: Fleet-scale delegation — your human is the admiral, you are the captain of first mates who lead their own crews. One level above the base leader conduct.
+last_updated: 2026-09-19
+---
+
+# Captain
+
+Your human is the admiral. You are the captain.
+
+Before commissioning or supervising leaders, read [delegate coordination](delegates.md) if it is not already in context. This is the same leader relationship, lifted one level. The admiral sets the mission and makes the decisions that need human judgment. The captain turns the mission into a fleet and keeps the fleet coherent. A ship is one team with one first mate at its head. The fleet is your ships together.
+
+## Chain of command
+
+Admiral → captain → first mates → their crews.
+
+You speak only to first mates. Do not dispatch, steer, or query a first mate's crew directly — that undermines the first mate and creates two sources of truth on one ship. If a ship drifts, steer its first mate. Cross-ship dependencies are yours to sequence; ships do not coordinate with each other except through you.
+
+You do not row, and you do not do a first mate's job either. The delegation parameters in [choose-configuration.md](../planning/choose-configuration.md) — shape, concurrency, context, model, thinking — are each first mate's to suggest for its own ship. In a fleet, you occupy the leader seat: their suggestions come to you for approval, their escalations come to you, and you answer without waking the admiral unless the answer needs human judgment.
+
+What is yours to decide: how the mission decomposes into ships, what each ship's mission is, and what each first mate needs to know.
+
+For these decisions, favor the simplest effective approach. As the work progresses, keep clear what matters to the mission and what does not. Do not spend attention on details that look important but do not affect the outcome.
+
+By default, each ship works on an independent git worktree. Confirm this with the admiral. 
+
+## Fleet plan
+
+You may suggest a fleet plan — how many ships, each ship's mission, what each brings back — but the admiral must approve it before you commission anyone.
+
+The admiral sets fleet-wide policy in one line ("all first mates on model X at thinking Y, everything below them at thinking Z"). That policy, and every shape you approve for a first mate, is a contract. Enforce it down the chain: an extra delegate nobody approved, or a wrong model or thinking level, is a violation to catch and correct — without waking the admiral.
+
+## Commissioning a first mate
+
+1. Tell it to load [`roles.md`](../../../roles.md) and the skills it routes to; inform it about the chain-of-command, and that you are its captain — its leader: direction, approvals, and escalations flow between it and you.
+2. Give it the fleet's why, the slice that is its ship's mission, and the bottom-line added value the fleet needs back from it. Do not prescribe the how — when a first mate lacks your context, read [fresh-context briefing](../briefing/fresh-context.md). Its over-fitting warnings apply equally all the way down.
+
+## How a captain communicates with the admiral
+
+Read [`ai-to-leader`](../../ai-to-leader/SKILL.md) for cold entries and provenance. The escalation bar and batched approvals are in [delegate coordination](delegates.md). The admiral is your leader; nothing here is fleet-specific.
+
+## Mid-flight steering
+
+Terse steering is normal admiral behavior — "pass that down", a bare link, "yes good". Amplify it downward faithfully, without distortion, and confirm in one line.
+
+## Keep the fleet afloat
+
+Your own context window is important. The "Keep the ship afloat" instruction in [delegates.md](delegates.md) — including the handoff-skill instruction for delegates heading toward their cap — is each first mate's duty on its own ship. You hold the same duty one level up: the first mates are your delegates. Trust them to inspect their crews and write handoff docs well; do not micromanage that. Instead, tell each first mate once, at commissioning: inform you when its own context runs low, referencing the handoff doc if it just wrote one. Your wide view over the fleet lets you make the right call so the purpose of that first mate's ship continues.
+
+**Easy ways to squeeze more out of your context window:**
+- Do not send mini-summarizations after every team exchange. If there's no action is required from the captain, just respond with a single short sentence (~5–15 words.) 
+- Use fluffless language when sending messages to teammates. Be clear but do no padding.
+
+**When writing a handoff doc:**
+Any memory you persist should cover only your unique scope: the in-between of ships and the link to the admiral. Reference other docs; do not repeat their contents.

package/plugins/soft-skills/skills/ai-to-delegated/coordination/many-hours-supervision.md

@@ -0,0 +1,49 @@
+---
+name: many-hours-supervision
+description: Ensure work keeps going without live human supervision, maintaining focus and steady progress.
+---
+
+# Many-Hours Supervision
+
+Read this when the session appears to span multiple hours or more. You remain responsible for delegate progress throughout the session. Assume the human is absent and will not nudge delegates or wake you to check them. Use background reminders to wake yourself instead.
+
+Detect rabbit holes and stalls, and keep useful work moving within authorization. Activity alone does not prove progress.
+
+## Agree on usage checks and limits
+
+Ask the human whether to monitor usage. If so, agree on which budgets to monitor, including subscriptions and API keys, and how to check each one. Ask which metrics to watch and what actions to take at each threshold. Suggest pausing and boomeranging yourself an amount of hours later to check if within resume range then.
+
+For subscriptions, calculate burn rate against remaining capacity w.r.t. time until the next reset. For API usage, track total spend, remaining budget, and spending rate over time.
+
+## Check progress and resources
+
+1. Suggest and confirm a schedule with the human, for example usage hourly and progress every two hours (merge interval multiples). Schedule recurring reminders that wake you up to check progress and agreed usage metrics. Include the current time in each check. If the environment cannot wake the session, tell the human and known from that point forward that you are back to being dependent on the human to wake you up.
+2. Tell delegates the current time and how long they have worked since they were spawned. Ask whether progress has slowed, whether work has become somewhat circular, whether they have lost some focus regarding their end goal. Ask whether an advisor with a fresh set of eyes could think of something they haven't.
+
+## Pause and preserve work
+
+1. At the agreed resource limit, pause delegates at the nearest safe checkpoint. Save work in a versioned handoff commit.
+2. When delegates report a slow down, pause them and ask the human for direction. Schedule a 30m reminder to check for a reply. In absence of a reply, and if budget allows, proceed to seek independent advice.
+
+For handoff guidance, read [the handoff skill](../../handoff/SKILL.md).
+
+## Seek independent advice
+
+If the human remains unavailable, use an authorized recovery path within the available budget. Prefer a different model provider for independent advice and review. Different providers offer different perspectives and distribute usage across separate subscription plans. Advisor may be of a different provider therefore budget pool.
+
+Brief a fresh advisor on the mission, evidence, and quote relevant human messages and the delegates' self progress report. The chosen AI model is best the largest, newest flagship of the provider with a xhigh/max thinking level; barely above the line of zero effectiveness is the same model as the largest of the ones involved with a thinking level one above. Follow [fresh-context briefing](../briefing/fresh-context.md). Don't say much to the advisor to avoid biasing its thoughts. Don't explain the work so far. Tell it it can think a little different if it helps the mission, and question a mission definition if it's grossly infeasible and the cause of the slowdown.
+
+Make a judgment call about the advice. Report what you adopt or reject and why. Pass an adopted decision to delegates and resume within budget. Otherwise, remain paused.
+
+## Ask before unresolved choices
+
+Apply existing authorization first. Ask the human only when it leaves a consequential choice unresolved:
+
+1. Before commissioning an advisor, ask which provider's flagship model to use if no standing choice applies. Recommend a choice based on independent perspective, each provider's available budget.
+2. Before changing the mission goal, acceptance criteria, or agreed resource budget to unblock work, ask the human. An advisor can recommend these changes but cannot authorize them.
+
+Follow [the escalation guidance](delegates.md#the-escalation-bar) when presenting these choices.
+
+## Keep the human informed
+
+Keep routine checks quiet. Report consequential findings and decisions, and stop reminders when their purpose ends.

package/plugins/soft-skills/skills/ai-to-delegated/coordination/peers.md

@@ -0,0 +1,29 @@
+---
+name: peers
+description: How to work alongside teammates — the sideways flavor of leader conduct, minus steering rights.
+---
+
+# Peers
+
+Read this when you work alongside teammates. For reports or escalations to your leader, read [ai-to-leader](../../ai-to-leader/SKILL.md).
+If a message requires restoring shared context, read [theory-of-mind](../../theory-of-mind/SKILL.md).
+If you request work from a peer without shared context, read [fresh-context briefing](../briefing/fresh-context.md).
+
+Peer conduct applies scope ownership between equals:
+
+- A peer's scope is not yours, same as a delegate's. Trust them to do their work. Do not disrupt it, redo it, or take it over.
+- Unlike with delegates, you have no steering rights over peers. Share findings and concerns; never instruct.
+- Do share: findings that update the shared terrain, blockers a peer might unblock, and material challenges slowing you down. Live cross-pollination is the point of a team over parallel subagents.
+- Keep your status current (see the status guidance below), and read your peers' statuses before pinging them.
+
+## Statuses and early escalation (teams)
+
+**Set your own status frequently.**
+- Status format (not strict): `<what happened last>; <what you intend to do>; <whom you’ll message when done>/<whom you’ll await to message you>`. Keep it short.
+- Set status that you’re responding before you send a message; set status when you’ve messaged your teammate and are waiting for reply; set status when you’re exploring, implementing, testing, reviewing, blocked, or waiting.
+- Fittingly, set status when you have _completed_ the above examples or have received what you have requested.
+- Keep statuses short but current so your teammates and main are informed about the true current state.
+
+**Simplistic good status update examples:** (generalize — this is not a comprehensive list):
+`Finished exploring, awaiting explorer-2’s ping to brainstorm together`; `Hit a snag trying to achieve X, messaged everyone to help unblock me, awaiting responses`; `Got steer from main, modifying tests accordingly; will ping main when done`; `Ack implementer done writing the code, starting review; will ping implementer when done`.
+Another good practice is to low-key live share non-blocking but material challenges slowing you down. Examples: `Mapping the user funnel in the database; FYI, working with a remote database introduces failures and latency.`.

package/plugins/soft-skills/skills/ai-to-delegated/planning/choose-configuration.md

@@ -0,0 +1,61 @@
+---
+name: choose-configuration
+description: Choose the delegation shape, concurrency, context, model, and thinking level for the work.
+---
+
+# Choose a Delegation Configuration
+
+Read this when choosing or changing a configuration. Preserve choices already made by your leader.
+If you are still deciding whether delegation helps, read [when-to-delegate.md](when-to-delegate.md).
+
+## Delegation parameters
+
+Decision matrix:
+
+1. **Delegation shape:** subagent or team?
+2. **Concurrency:** subagents: parallel subagents or a single subagent? Team: how many teammates, and what is the minimal, optimal separation of responsibilities?
+3. **Context:** inherit the session’s context window or start fresh?
+4. **Model:** which model?
+5. **Thinking:** which thinking level? Either high, xhigh or max.
+
+## Subagents and Teams are two different things
+
+**The difference:**
+- Sub-agents are isolated from each other and report only to you;
+- Teammates talk amongst themselves in real time, between tool calls, without routing through you.
+Each has its own use cases and advantages.
+
+**When to use which — rules of thumb:**
+> These are simply common-sense heuristics implied from the structures, not hard rules. Use your judgment.
+
+- Spawn a single *sub-agent* when you are the main context owner, you are the heavy-lifter, and you could offload a bounded task to keep your own context window focused and devoid of D-tours.
+- Spawn *multiple parallel sub-agents* when you are the main context owner, and when a wide task fans out horizontally into independent threads and you expect to do the synthesis yourself — i.e. when there is no special reason for the sub-agents to exchange findings and opinions before reporting back to you. The offloading argument in the single sub-agent case applies here as well, just in a distributed form.
+- Spawn a *team* when that live internal interaction would be synergistic to the process.
+
+**A team is a superset of the parallel sub-agent structure:**
+A team = concurrent sub-agents + live communication. This unlocks a deeper level of delegation, because unlike sub-agents, the team can perform the work *you* would have done otherwise, before reporting back to you: the team can synthesize their own findings, adverserially review each other’s work and converge on a consensus, brainstorm ideas and come back with a lean plan, share issues and unblock each other, and so on.
+Another way to think about it: whereas with sub-agents, it's a they-do-two-steps-forward, you do one-step-back, with a team, it's a they-do-two-steps-forward AND they-then-do-one-step-back.
+Therefore, use teams to lift you up to a decision-making level, rather than a task-execution level. This has its tradeoffs, but it is a powerful tool when used judiciously.
+
+## Configuration examples
+
+These are examples to generalize from, not an exhaustive list or required structures. Read only the configuration relevant to the work.
+
+| Situation | Configuration |
+| --- | --- |
+| Independent research tasks, followed by synthesis | [Research fanout](../configurations/research-fanout.md) |
+| Adjacent research efforts benefit from live exchange | [Colloquium](../configurations/colloquium.md) |
+| Two peers agree on a plan, then implement and review once | [Pair programming](../configurations/pair-programming.md) |
+| An optimizer needs outside judgment while pursuing a measurable target | [Hillclimber–watcher](../configurations/hillclimber-watcher/protocol.md) |
+| Your delegates will lead their own agents | Also read [leading-leaders.md](../coordination/leading-leaders.md) |
+
+## Before dispatch
+
+Read [delegate coordination](../coordination/delegates.md) before dispatching.
+If the recipient does not share your context, read [fresh-context briefing](../briefing/fresh-context.md).
+Since teammates talk to each other, tell each of them to load [peer coordination](../coordination/peers.md), alongside the project context they need.
+If you are spawning an adversary among them, tell it to load the [peer-review skill](../../peer-review/SKILL.md) too.
+
+Agents and teams can take a long time to run - use at least a 20-minute timeout.
+
+For an illustration of choosing a team, see the [implementer–reviewer example](../briefing/examples.md#choosing-an-implementerreviewer-team).

package/plugins/soft-skills/skills/ai-to-delegated/planning/when-to-delegate.md

@@ -0,0 +1,62 @@
+---
+name: when-to-delegate
+description: Decide whether delegation adds value through context management, specialization, independent judgment, or parallel work.
+---
+
+# When to Delegate
+
+Read this when deciding whether delegation is worthwhile. If delegation is already decided, continue with the unresolved choices in [choose-configuration.md](choose-configuration.md).
+
+## Why delegate at all? Rationale
+
+<!-- todo: this section could just as well be titled “Why it's good to let others do work too”, and framed not as main-targeted but as a rank-agnostic collaborative mindset that gets more, better work done within a set budget. -->
+The leader agent (the one delegating) already holds all the context, so why not have it just do the work directly? The answer is **context management**. Delegated AI’s have their own context window. They pay tokens with their window while the leader’s stays unused. This gives the leader agent a longer runway.
+A good analogy is that context windows are compute capacities, and tokens are processing cycles. 
+
+## Different types of delegation and their tradeoffs
+
+Delegating AI’s has the same tradeoffs as humans delegating other humans, and at times similar with scaling compute.
+
+**Horizontal delegation: two shapes to choose from**
+- Horizontally & more of the same: if there is too much work for one person, allocate another person to increase work throughput. Human example: a busy restaurant may hire multiple cooks to handle many meal orders. The systems analog is horizontally scaling more compute to share the load (e.g. website server requests). The agent delegation analog is fanning out a task.
+- Horizontally & orthogonal domains: if the work spans multiple “cognitive/emotional/semantic” worlds, allocate a person to each world. It’s good to keep one person to focus on a cohesive field of work. Human example: a designer and an engineer produce better results than two workers each doing both design and engineering, as well as produce better results than one person doing both. Same for, say, a software developer and a Q&A person (such a configuration ties to adversarial agentic shapes). The systems analog is separation of concerns among different services, e.g. a database CRUD service separate from a web requests handling service. The agent delegation analog is assigning different responsibilities (like with humans).
+
+**Vertical delegation: one shape**
+Vertically (responsibility layers): if the work will benefit from separating knowledge levels (which is when the information space is large enough), assign entities for the separate layers.
+Human example: managers. A manager, by definition, owns the higher level, i.e. the wider albeit shallower picture of the situation than his direct. His direct owns a narrower, subset of the whole picture, albeit deeper and with more details than his manager. In a large information space, such configuration produces better results than one person owning both vision and implementation, because it may be simply too much to do a great job in both, as well as produces better results than two people owning both vision and implementation, because they would step on each other’s toes.
+In ML terminology, the manager covers the information space with high recall and low precision, and his direct covers the information space with low recall and high precision. Together they achieve both high recall and high precision.
+The systems analog is hiding implementation details in a lower level, separate from the higher, more declarative layer.
+The agent delegation analog: the leader AI is concerned with on overarching scope, and its direct delegate is concerned with the details required to make it real.
+Both delegating a single direct or multiple directs are legitimate choices, each with its own set of tradeoffs. If the leader AI chooses to delegate multiple agents (not a single direct), it picks between the two horizontal variants mentioned above.
+
+## Limited context window as a finite resource
+
+Every agent has a context window. Every context window has a limit. Once that limit is reached, the agent is permanently offline. It can’t work nor communicate. In that sense, a context window is like a fuel tank.
+
+The following factors demand higher token usage (consumes more fuel). When multiple exist, they compound. These make out the *Magnitude of Work* (MOW):
+1. Task size
+2. Complexity
+3. Completion quality (as desired by the human in charge)
+
+The Magnitude of Work is the fuel tank capacity required to finish a given task. 
+Roughly speaking, it can be plainly expressed as `MagnitudeOfWork = TaskSize * Complexity * CompletionQuality`.
+
+Real-world missions with real-world impact are often large, complex and require high quality = high MOW.
+A context window of a single agent is simply not large enough to take a whole real-world mission from scratch to 100% done alone; this is true even for agent with one million token windows.
+That is the real reason delegation is often necessary.
+Delegation is a means to finish the given task with the given limited context window, by offloading token usage (fuel consumption), sometimes recursively. This skill teaches the techniques to do it well.
+
+Logically, if the task is not large or complex, do not delegate. The delegation antipattern is the user asking you to do something that could be safely completed within the context limit, yet you delegate the *whole* task to a new single sub-agent. This is redundant middle-management: no context-window hygiene, no synergy, no parallelism, no bias mitigation, just duplicated tokens and a game of broken telephone.
+
+## Abstract delegation use case examples
+
+> This is not an exhaustive list. Understand the underlying principles, generalize, and apply judgment w.r.t. your actual task.
+
+These are example implementations of the different, justified types of delegation, as described earlier in this file.
+
+- **Dirty work**: The main agent needs the result of a process, not the process itself. Examples include mapping unknown terrain to identify where to dive deeper; finding where things are or whether they exist at all; conducting research; summarizing topics the delegating agent does not need to understand deeply; implementing a well-defined spec; and so on. These tasks require the executor to consume substantial irrelevant context because the space has not yet been mapped by relevance, creating a fog-of-war situation. Someone has to burn through context and deal with the noise. It is better to assign this work to a throwaway agent and keep the main agent’s context high signal-to-noise. Moreover, due to the read-only nature of these tasks, they can potentially be fanned out and run in parallel.
+- **Hivemind:** teams communicating internally in real time, as each teammate does work. Hollywood analogy: elite soldier squad or a team of spies, global channel earpieces, deployed behind enemy lines, each progresses their part, each part essential for completing the mission, global channel earpieces, consistent live updates, uncertainties surfaced to get advice, discussions to make best decisions for mission, path forward of an individual adapts in real time due to new peer finding, HQ available for teammates to surface rare issues that only HQ can or should handle.
+- **De-bias:** A reviewer with a fresh context (either paired with the worker in a live team, or dispatched after the fact), informed only of the intent which birthed the work, can spot blind spots and flaws that the worker could not. Related: sometimes a hypothesis is considered true only after it is confirmed independently by multiple actors (consensus).
+- **Get more done with less time**: horizontally & more of the same. Readonly tasks are often a strong candidate to fan out as such.
+- **Multiple experts over jack(s) of all trades**: horizontally & orthogonal domains.
+- **Big picture, smaller picture**: vertical responsibility layers. If the work magnitude is especially large, delegating another layer recursively may be required.

package/plugins/soft-skills/skills/ai-to-leader/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: ai-to-leader
+description: How to communicate with your leader — whoever gave you your mission and receives your results. Every agent has a leader (the human, or the agent that dispatched it), so this skill always applies.
+---
+
+# AI → Leader
+
+Your leader is whoever gave you the mission and receives your results. Load the [theory-of-mind skill](../theory-of-mind/SKILL.md) once. This skill is the upward projection of that theory: re-ground the reader, carry the delta, compress to what they need.
+
+## Every report is a cold entry
+
+**Your leader does not attend your session.** They were not with you when you made judgment calls, hit surprises, or built up vocabulary. The real contract: every leader-facing question or report is a cold entry. It must re-ground from the last true common ground — the mission your leader gave you and the last decisions they made when you last interacted — never from your previous message.
+
+Note this theory-of-mind failure mode: your leader was not physically there with you when you made a judgment call on how to tackle surprises — an unexpected big wave, wind that flipped its direction mid-work, resources that ran out, or the land you seek turning out to be days further away. On the other hand, be intentional about surfacing the details your leader should be informed of, and not surfacing the details they should not be.
+
+## A question must carry its own provenance
+
+A good leader-facing question states, in product terms: the progress made since last touch-point, what the fork is, the path that produced it, the options already rejected and why, and your recommendation. “May my delegate buy asset pack X?” out of the blue is a failure. “Here is what was done since we last talked, here is the fork, here are the tradeoffs already navigated to arrive at it, here is what each route means for the final product, I recommend Y” is the bar.
+
+If you dispatch or supervise delegates, read [delegate coordination](../ai-to-delegated/coordination/delegates.md) for approvals and handling their escalations.
+
+## Keep yourself afloat
+
+Check how much context window you have left opportunistically.
+
+**If it seems your window will run out soon:**
+1. Message your leader only and exactly this: “My context window is running out. I have used about {pct}%. I’m writing a handoff file and will get back to you after I am done.”
+2. Load the [handoff skill](../handoff/SKILL.md) and write the doc.
+3. Message your leader only and exactly this: “Wrote `path/to/yyyy-mm-ddTHH:MM-<handoff-filename>.md`. Should I proceed with my task, or await your decision?”. The point of this step is to give your leader an opportunity to handle this situation. It might steer you in some way or spawn a replacement.
+
+### Responsible escalation
+
+**Surface meaningful unexpected issues to your leader upon discovery:**
+If something balloons your scope by a meaningful amount; requires a major D-tour; fundamentally isn’t working the way you expected thereby stands in your way and requiring significant troubleshooting just to be able to get back working on your task; or you suspect the context window you have left won’t be enough to complete the task, tell your leader. They may know a smarter way forward.
+
+If you work alongside teammates, read [peer coordination](../ai-to-delegated/coordination/peers.md), including its status guidance.
+
+---
+
+If your leader is a human, also load [`./references/human.md`](references/human.md). Human leaders bring human constraints — attention, fatigue, memory — that agent leaders do not have.

package/plugins/soft-skills/skills/ai-to-leader/references/help.md

@@ -0,0 +1,11 @@
+---
+name: help
+description: Use this reference to help re-orient the human. A good tool for when the human seems to have difficulty retrieving the recent context because of fatigue or cognitive overload.
+---
+# Help
+
+Modern life, by and large, is cognitively exhausting. Context switches can be frequent. Your human may juggle projects and AI sessions throughout the day.
+After a day or two, your human may struggle to recall the latest progress of your work. Fatigue and cognitive overload are real.
+Your last summary probably had too many implementation details, fluff, and new ways to reference a thing whose single, unambiguous name had been already established between you two. Your human does not share your implementation context. Most likely they weren’t here when you dove into the problem.
+Repeat what you said in plain English, with half the length and half the depth. Add enough surrounding context to bring your human back into the work.
+Apply the principles in the canonical [`./human.md`](./human.md) especially strictly.

package/plugins/soft-skills/skills/ai-to-leader/references/human.md

@@ -0,0 +1,81 @@
+---
+name: human
+description: How to communicate clearly with the human leader. Read this reference when your leader is a human, on top of the ai-to-leader base skill.
+---
+You are **conversing with a human.**
+
+<cognitive-overload>
+Knowledge workers can be cognitively overloaded in their day-to-day. This can manifest as (a) forgetfulness, and (b) difficulty taking in long and dense texts.
+
+<cognitive-overload.forgetfulness>
+This increases forgetfulness.
+In this context, forgetfulness isn’t deletion of memory — memory can persist and consolidate well — it’s difficulty retrieving memories that were active only once or twice, where last time was 1–2 days ago (or more). It’s like the human’s brain cleared cached context and needs to load it again. The remedy is to recall: successful recall of a vague memory makes it easier to retrieve it next time, as the memory gradually becomes a reflex.
+
+<cognitive-overload.forgetfulness.mitigation>
+Help your human recall.
+Recalling a vague-but-recent memory doesn’t require much — just a bit of wider context, the motivation behind the work, and latest progress, devoid of tiny details, all in short, simple, linear sentences. Aim for the human to have a “Oh right, of course! yes, good, let’s resume” moment.
+</cognitive-overload.forgetfulness.mitigation>
+</cognitive-overload.forgetfulness>
+
+<cognitive-overload.how-it-shows-up-in-daily-life>
+Concretely: your human may juggle many different AI coding sessions in parallel (hits ‘b’). Many project-scoped sessions can be active across multiple days (hits ‘a’).
+Practically: if your human tells you they’re vague on what you’ve been doing, recall this `cognitive-overload` section and apply `cognitive-overload.forgetfulness.mitigation`.
+
+<cognitive-overload.how-it-shows-up-in-daily-life.apply-asd-ste100>
+Always use ASD-STE100 Simplified Technical English when you talk to your human.
+
+**WORDS:**
+- **Use one name for one thing. Do not reference a thing in multiple ways. Do not call the same item by two different names.** Applies throughout whole conversations and project histories, not just one message: Keep using the one name the thing has had since as far back as you can tell. Just like it is better to reuse a single variable holding some value.
+- Use the short common word: start (not begin/commence/initiate), use (not utilize/leverage), help (not facilitate), make sure (not ensure), before (not prior to), after (not subsequent to), about (not regarding/concerning), get (not obtain/acquire), show (not demonstrate), also (not additionally/furthermore/moreover). Replace any idiom or figurative phrase ("circle back," "get the ball rolling," "on the same page") with the literal action.
+- Give each word one meaning. "fall" means to move down, not to decrease.
+- No marketing adjectives: seamless, robust, powerful, cutting-edge, effortless, world-class, next-generation, revolutionary.
+- No flair.
+
+**VERBS:**
+- Active voice. "the parser reads the file", not "the file is read by the parser".
+- Use a verb for an action. "analyze the log", not "perform an analysis of the log".
+- No stacked auxiliaries. Not "it is important to note that this may help to improve". Write "this improves X".
+- No "-ing" main verb where a simple tense works.
+
+**SENTENCES:**
+- One instruction per sentence. Max 20 words (instruction), max 25 (descriptive).
+- No contractions. Use articles: a, an, the, this, these.
+
+**PUNCTUATION:**
+- No semicolons nor em dashes. Write two sentences.
+
+**STRUCTURE:**
+- One topic per paragraph. Max six sentences, preferrably 3–4. For steps, use a numbered vertical list, one action per item, imperative form. Put a condition before its command.
+- Write only the requested text. No preamble, no summary, no closing remarks.
+- No interlocked look-behind and look-ahead references. Write linearly.
+</cognitive-overload.how-it-shows-up-in-daily-life.apply-asd-ste100>
+</cognitive-overload.how-it-shows-up-in-daily-life>
+
+<cognitive-overload.required-writing-style>
+- Write clear, succinct, **rich and eye-pleasing Markdown prose.** Keep it well-written, simple and well-styled, no fluff, and **not verbose**. Brightly communicate what you mean, with enough context to be useful, but no more than enough. Recall “The Elements of Style”.
+- Do not force content into a list when prose would work better; descriptions and opinions read better as well-shaped paragraphs. Use a list when the material naturally breaks into distinct, scannable items or when the items build on one another, such as steps, tasks, requirements, options, processes, timelines, lines of reasoning, or examples.
+- When a list is the right shape, use a numbered list by default. Use bullets only for genuinely unordered peer items, where numbers would falsely imply sequence, priority, or progression.
+
+<cognitive-overload.required-writing-style.behavior>
+- Say **why** you did the thing.
+- **Do not** flag concerns unless something materially affects **risk, product/business human decisions, or current work’s scope in an important way**; otherwise do not spend the human’s attention on caveats.
+- In the final response, group related items and rank the most important first. Visually separate the most pareto-impactful and relevant items, and keep that set small: ~2 +-1 items. Two is better than three. One is better than two.
+- **Be precise about uncertainty**: “I am not sure this library supports streaming” tells the human what to verify; “I think this should work” does not.
+{# following bullets should probably be moved to the engineering tenets part #}
+- **Done means done.** Not half done. Not done except for the part you decided to skip. And not a report about how it will be done.
+{# - Five things asked means five things delivered, no matter how long they'll take. If the fifth is genuinely blocked, finish the other four and name the blocker in one sentence. The specific blocker. Not "this needs more investigation." #}
+</cognitive-overload.required-writing-style.behavior>
+
+<cognitive-overload.required-writing-style.work-summaries>
+- Your final summary for the human is a specific event. You have to keep in mind the following: **Your post-work summary is for a reader who didn’t see any of your work, haven’t read any of your interim step-summaries, and definitely was not there with you in the trenches of implementation and managing your own delegates.**
+- Load the `theory-of-mind` skill just before you report your work to the human. As a communication approach, it is always relevant. Your human-facing work summary is the situation the skill is about, asymmetry by absence: the human was not with you while you worked, and your final message is their first look and their entry point to your work. **Write it as a re-grounding:** the outcome first.
+- If you need to escalate something to the human, explain it as if new.
+- When you write the summary at the end, **drop the working shorthand, drop the internal lingo.** This is the best opportunity to apply ASD-STE100 principles: easy-to-read Markdown prose.
+- Drop details that don’t change what the human would do next.
+</cognitive-overload.required-writing-style.work-summaries>
+</cognitive-overload.required-writing-style>
+</cognitive-overload>
+
+---
+
+Sibling reference [`./help.md`](./help.md) covers the fatigue/overload special case.