agentleFS
skyf0xxskyf0xx/gambit/skills/negotiate/SKILL.md

negotiate

Skill29 starsChanged 33 days agoMITView on GitHub

Use before a conversation where you need someone's agreement — a council, a landlord, a sponsor, a platform, a collaborator, a rival organiser. Preps interests on both sides, your walk-away alternative (BATNA), the zone where a deal exists, concessions ranked by cost, and the traps. Two-way, unlike comms, which prepares outward broadcast. Writes each conversation's prep to the goal's prep key, then its outcome once it has happened.

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the goal — the goal statement, the plan key, the people key, the stakeholders array if non-empty.

    line 46
  2. Distinctive:

    If "must have" has more than two items, it's probably a wish list.

    line 62
  3. Distinctive:

    Never disclose a weak BATNA.

    line 80
  4. Distinctive:

    If there's no overlap, say so before the conversation.

    line 111
  5. Distinctive:

    Every concession past the first should be conditional: "I can do X if you can do Y." Unilateral concessions teach the other side to wait.

    line 132
  6. Very specific:

    Call write_section on prep with one entry per counterpart, at most 5.

    line 183
  7. Distinctive:

    If the write returns { ok: false, errors }, fix the reported fields and retry before ending the turn.

    line 206
  8. Very specific:

    Use after the talk, or when the state block flags a prep entry whose on date has passed with no outcome.

    line 218
  9. Very specific:

    Call write_section on prep, setting that entry to done: true and outcome (120 characters or less: what was agreed and who owes what by …

    line 225
  10. Very specific:

    Call append_log with source: "negotiate" and at most 3 notes: the outcome and any commitment made.

    line 228

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: negotiate

Trigger: A conversation is coming where the other side has to agree to something. Permission, money, access, a venue, a partnership, a division of work, a de-escalation with someone who's been blocking.

Also use after stakeholders identifies a high-power actor who needs moving — this is how the conversation gets prepped.

Purpose: Walk in prepared. comms shapes what you broadcast; this prepares a two-way exchange where the other side has leverage and their own goals.

Most people prepare by rehearsing their argument. That is the least useful preparation available. What actually determines the outcome is knowing what they want, knowing what you'll do if there's no deal, and knowing in advance what you'll trade — decided while calm, not in the room.


Voice & Tone

Practical and unsentimental, without being adversarial. Most negotiations that matter here are with people the user will deal with again — a council officer, a venue manager, a fellow organiser. Winning a single exchange at the cost of the relationship is usually a bad trade, and should be named when it's on the table.

Firm on substance. Do not coach the user into conceding early to be agreeable — that's the most common failure, and it's expensive.


Execution Sequence

1. Load Context

Read the goal — the goal statement, the plan key, the people key, the stakeholders array if non-empty. If the counterparty appears in the stakeholders array, pull their recorded interest rather than re-deriving it. If this talk is a message the plan escalates from, the escalation that follows it is part of the user's BATNA: name it, and use it as leverage only if the user is ready to climb.

2. Define What You Actually Need

Separate, precisely:

MUST HAVE: [without this, no deal is worth doing]
WANT: [valuable, tradeable]
NICE: [give away deliberately, to buy something]

If "must have" has more than two items, it's probably a wish list. Test each: would you genuinely walk away without it? If not, it's a want.

3. Your BATNA

The single most important input, and the most commonly skipped:

BATNA — Best Alternative To a Negotiated Agreement
  If this conversation produces nothing, I will: [the specific fallback]
  How good is that, honestly: strong | workable | poor
  Can it be improved before the conversation? [what would strengthen it]

Your BATNA sets your real floor. A weak BATNA doesn't mean concede — it means know you're exposed, and improve it beforehand if there's time. An hour spent strengthening the alternative usually beats an hour spent rehearsing arguments.

Never disclose a weak BATNA. Never bluff a strong one you don't have — it gets tested, and being caught costs more than the deal.

4. Their Side

Work it as carefully as your own. Guessing here is where negotiations are lost:

THEIR INTERESTS: [what they actually want — not their stated position]
THEIR CONSTRAINTS: [what they can't do, regardless of willingness — policy, budget, a boss,
                    precedent, optics]
THEIR BATNA: [what happens for them if there's no deal — are they under pressure or not?]
WHO ACTUALLY DECIDES: [is this person the decision-maker, or carrying it to someone?]

That last line changes the whole approach. If they're a messenger, the goal is to make it easy for them to advocate internally — which means giving them something to say, not winning an argument with them.

Where an interest or constraint is a guess, mark it and offer a web search, where the tool is present, to firm it up.

5. Find the Zone

ZOPA — Zone Of Possible Agreement
  Your floor: [worst acceptable]
  Their likely floor: [estimated]
  Overlap: exists | doesn't appear to | unknown

If there's no overlap, say so before the conversation. The options then are: change what's being negotiated (add an issue, extend the timeframe, split the deal), improve your BATNA, or don't have the meeting. Discovering it in the room wastes the meeting and hardens positions.

6. Rank Concessions by Cost

Decide this in advance, in writing:

CONCESSION LADDER — give in this order
  1. [item] — costs me: [low] — worth to them: [high]   ← trade these first
  2. [item] — costs me: [medium] — worth to them: [medium]
  3. [item] — costs me: [high] — only for: [what you require in return]

NEVER: [what you will not trade, at any price]

The best trades are cheap to you and valuable to them — they exist because the two sides value things differently, and they're invisible unless you've mapped both interest sets.

Every concession past the first should be conditional: "I can do X if you can do Y." Unilateral concessions teach the other side to wait.

7. Openings, Anchors, and Traps

OPEN WITH: [your opening position — ambitious but justifiable]
JUSTIFICATION: [the standard or precedent it rests on — anchors need a reason to stick]
IF THEY ANCHOR FIRST: [how to reset without rejecting outright]

TRAPS TO EXPECT
  [tactic] — [what it looks like] — [response]

Common ones worth prepping for: artificial deadline pressure, "that's just our policy", escalating demands after apparent agreement, splitting the difference from an extreme anchor, and the deal that changes when it's written down.

8. Elicit

Before you go in:

  - What are you most afraid they'll say?
  - What would you accept right now if they offered it — honestly?

The second question exposes a real floor that's often well above the stated one. If the user would accept something today that sits below their stated "must have", the must-have list is wrong, and better to find that out now than mid-conversation.

The first question usually surfaces the argument they feel weakest against — which is the one worth preparing.

9. Set the Walk-Away Rule

Written in advance, while calm:

I WALK IF: [specific, observable condition]
I ALSO WALK IF: [the relationship or process condition — bad faith, moving terms]

Deciding to walk is nearly impossible in the room, under social pressure, with sunk time behind you. Deciding it beforehand is the only reliable way it happens.

10. Confirm, Then Write the Prep

Show the prep as one confirm reply (the ask, the walk-away, the first concession) and write after the user answers, never in the turn this skill was loaded.

Call write_section on prep with one entry per counterpart, at most 5. with is the person's name exactly as it appears in people or stakeholders; on is the meeting date. Keep other conversations' entries as they are.

{
  "prep": [
    {
      "with": "Council officer",
      "on": "2026-10-14",
      "ask": "Three-month permit extension",
      "batna": "Hold it in the park across the road",
      "walkAway": "Walk if they add a fee over £200",
      "concessions": ["Share the route early", "Add a marshal"],
      "done": false
    }
  ]
}

ask, batna and walkAway are 120 characters or less; each concession is 40 or less, ranked cheapest first.

If the write returns { ok: false, errors }, fix the reported fields and retry before ending the turn.

Next: [strengthen the BATNA | confirm a guessed interest → web search |
       draft the opening → comms | after the conversation → debrief here]

Debrief Mode

Use after the talk, or when the state block flags a prep entry whose on date has passed with no outcome.

  1. Find the matching prep entry by with. Ask what happened in one question: what was agreed, what was refused, what was promised on each side.
  2. Confirm the outcome in one line. This is a record of what the user just said, so it needs no full checkpoint.
  3. Call write_section on prep, setting that entry to done: true and outcome (120 characters or less: what was agreed and who owes what by when). Leave the other entries as they are.
  4. Call append_log with source: "negotiate" and at most 3 notes: the outcome and any commitment made. A commitment nobody recorded is one nobody can hold either side to.
  5. Route what was promised into the next step. Commitments to sequence go to plan; a stance that moved goes to stakeholders; a lesson worth extracting goes to review.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.