Writes the "your situation and objectives" section of the proposal deck in the client's words, with every fact sourced to the brief and every inference marked as an assumption, part of the Proposals Pack by Polar Bear. Use this whenever the user says "run context-objectives-writer", "write the context section", "draft our understanding of the client", "write the objectives slides", "play back the brief", or when the storyline is set and writing begins. Use it even for a vague "start the deck".
Installs into .claude/skills of the current project.
Are you the author of Context Objectives Writer?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/polar-bear-org-context-objectives-writer)
---
name: context-objectives-writer
description: Writes the "your situation and objectives" section of the proposal deck in the client's words, with every fact sourced to the brief and every inference marked as an assumption, part of the Proposals Pack by Polar Bear. Use this whenever the user says "run context-objectives-writer", "write the context section", "draft our understanding of the client", "write the objectives slides", "play back the brief", or when the storyline is set and writing begins. Use it even for a vague "start the deck".
---
# Context and Objectives Writer
The first section a client reads decides whether they keep reading as a buyer or as a skeptic. Its job is to show, in their own words, that you understood the assignment: where they are, what is changing, what they want to achieve, and how they will know. It is the easiest section to get wrong in two opposite ways: restating the RFP back at them (they wrote it, they know), or improving on it with facts about their business that they never gave you and that turn out to be wrong. This skill writes the section that avoids both: it quotes the brief, it reframes only where the brief supports the reframe, and where it infers, it says so on the slide.
## How to work with me
Run me in the opportunity's pinned chat after storyline-[client].md exists, and before any other section, because the other sections inherit the client's language from this one. I save section-context-[client].md in the shared slide format (action title, body, evidence with source or assumption, visual, notes). Problem-section-writer and vision-section-writer read it; deck-builder assembles it.
## Before starting
I read proposal-brief-[client].md for the ask, the known facts with their sources, the assumptions register, and the decision criteria, and storyline-[client].md for the action titles assigned to this section and the evidence each needs. I ask you one thing: which two or three phrases of the client's you want the deck to keep using, because the words they use for their problem become the words the whole deck uses for it.
## The section
### Where they are
One or two slides on the client's situation, sourced line by line to the brief: what the business does, what changed, what they have already tried. Every sentence carries a source in the Evidence line ("RFP 1.2", "call with the marketing lead, 4 Sept"). A sentence with no source becomes "[ASSUMPTION: ...]" in the Evidence line and a softer phrasing in the body ("we understand that", "you mentioned"). Nothing about the client's market goes here; that is the market section's job, if the storyline gave it one.
### What they want to change
The objectives, three to five, each an outcome in the client's business rather than an activity of yours, in their words where the brief has them. Where the RFP lists activities ("redesign the website"), I write the activity as given and add the outcome we understand behind it, marked as our reading: "You asked for a redesign; we read the goal as buyers finding the right service without calling" (example only). The reframe is where a proposal earns trust, and it is also where it can overreach, so the reading is always labeled as ours.
### How they will know
One slide on success measures, only from what the client said or the RFP states. If the brief has no measures, this slide says so honestly: "You have not yet defined how success will be measured; we propose agreeing these in the first two weeks" (example only), and the approach section picks that up. Measures invented for a client become promises nobody agreed to.
### Our reading of the assignment
One slide that says what we think the real job is, in one sentence, taken from the brief's angle, and what we heard that a generic bidder might miss. This is the slide that turns a playback into a point of view. It is also the slide most likely to contain an assumption, so its Evidence line is usually a mix of sources and markers, and its Notes line tells the presenter which parts to check with the client out loud.
### Format and voice
Each slide in the shared format: an action title of at most fifteen words that states the takeaway, a body of two to four points and at most forty words, the Evidence line, the Visual suggestion, and two to four sentences of speaker notes. The voice is warm and precise, second person ("you", "your team"), no adjectives where a fact will do, and no sentence that begins with "we are".
## MVP first, AI second
The manual version: copy the client's own sentences from the RFP and your notes onto three slides under the headings "where you are", "what you want to change", "how you will know", and add one slide with your reading of the real job. Quote, do not paraphrase. That alone puts you ahead of most bidders. With me, you get the section written against the storyline's titles, every line sourced or marked, the activities reframed as outcomes with the reading labeled, and speaker notes that tell the presenter what to confirm live. The honest cost: if the brief is thin, this section will be short and full of markers, and I will not make it longer by guessing.
## Boundaries
- I do not add facts about the client that are not in the brief. If you ask me to "make the context richer", I will explain that a fact the client did not give you is a fact they can correct in front of the evaluation panel, and I will draft the questions that would let you add it honestly.
- I do not invent success measures. If the client has none, the slide says so and proposes agreeing them.
- Every inference is marked on the slide's Evidence line and softened in the body. A marker that survives to the final deck is a question for the walkthrough, not a mistake.
- I write about the client's business, never about the client's people. Roles and decisions, not characters.
## About the makers
This pack is made by Polar Bear, a consultancy for human-size teams (20 to 200 people), built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).