Update to Negotiation Adviser

{
  "description": "Use when a negotiation needs Topics, Targets and Trade-offs, an opening or counter-offer package, concession design, or alternatives within an agreement rather than a BATNA analysis.",
  "included_files": [],
  "name": "ttt-offer-design",
  "skill_md_contents": "---\nname: ttt-offer-design\ndescription: Use when a negotiation needs Topics, Targets and Trade-offs, an opening or counter-offer package, concession design, or alternatives within an agreement rather than a BATNA analysis.\n---\n\n# TTT Offer Design\n\n## Overview\n\nTurn state into **Topics, Targets and Trade-offs (TTT)** and offer packages. Freeman's TTT uses ambitious but realistic targets, least acceptable boundaries and two trade types; it is a play card, not a script. [F03]\n\n**Authority:** `00_FREEMAN_RESEARCH_BASE.md` → `01_NEGOTIATION_AGENT_ARCHITECTURE.md` → `02_NEGOTIATION_BEHAVIOUR_CONTRACT.md`.\n\n**Interface:** accept `schemas/SKILL_REQUEST.md`; return `schemas/SKILL_RESPONSE.md`. Never persist state directly.\n\n## When to use\n\nUse to define or refresh topics, targets, trades, opening/counter packages, least acceptable packages or conditional movement.\n\nDo not own detailed BATNA/leverage analysis (F03), final drafting (F07), independent acceptance (F08), or role-play (F06).\n\n## Core model\n\n| Element | Rule |\n|---|---|\n| **Topics** | Identify negotiable issues; price/fee is not automatically the whole negotiation. |\n| **Best target** | Ambitious but realistic, with rationale/evidence. A user wish is not automatically a researched target. |\n| **Least acceptable boundary** | Preserve the established boundary; never move it silently. |\n| **Cross-topic trade** | Exchange movement on one topic for value on another. |\n| **Within-topic trade** | Find another way to satisfy the interest within the same topic. |\n\n## Method\n\n1. **Validate state.** Use the supplied version, interests, positions, evidence, priorities, BATNA summary and concession history. Flag material contradictions.\n2. **Map topics/priorities.** Preserve `agreed` topics unless deliberately reopened. Add topics only when state supports them; do not invent counterpart priorities.\n3. **Set/test targets.** Require a basis for best targets and least acceptable boundaries. If BATNA is needed but unknown, identify the limitation and route detailed analysis to F03.\n4. **Search for trades.** Look for cross-topic and within-topic trades before unilateral movement. Never store an agreement trade as BATNA.\n5. **Design supported packages:**\n   - **opening package** near supported best targets, with no arbitrary numerical cushion;\n   - **least acceptable package** respecting critical boundaries;\n   - **creative package** using supported tradeable topics where useful.\n6. **Check concessions.** State why movement helps, what should return, whether a boundary is crossed, and whether conditional movement is preferable. Unilateral movement is allowed when the state supports a strategic reason.\n7. **Return proposals.** Explain give/receive logic and risks. Flag proposed target/floor changes through `material_change_candidate`.\n\n## Safeguards\n\n- Never invent prices, percentages, market anchors, target rationales or counterpart valuations.\n- Preserve evidence labels for material assumptions about counterpart value.\n- Do not sacrifice a critical topic for a lower-priority gain without surfacing a deliberate boundary change.\n- Do not use arbitrary utility scores or pseudo-precision.\n- Do not silently re-trade an `agreed` topic.\n- Prefer supported trades to giveaways; do not manufacture reciprocity.\n\n## Output\n\nReturn canonical `skill_response`: conclusion/confidence, findings, recommendations, permitted state patches, questions, warnings/conflicts and `material_change_candidate` where required.\n\nFor every finding, keep the two enums separate: `research_provenance` is only `FREEMAN | EXTERNAL | SYNTHESIS | DESIGN`; `evidence_status` is only `KNOWN | SUPPORTED_INFERENCE | HYPOTHESIS | UNKNOWN | null`. Never place an evidence-status value in `research_provenance` or a methodology value in `evidence_status`.\n\nF02 proposes; the orchestrator reconciles/persists. F07 drafts wording. F08 decides material deal acceptance.\n\n## Stop condition\n\nStop when a supportable TTT map and enough package choices exist for the next move. Do not generate variants merely to appear creative.\n"
}