Context is Queen is a Claude Code skill for complex work, where an agent left alone will decide what “done” means and never mention it. This one asks instead. It interviews you, researches whatever it can answer itself, and proposes a goal for you to correct before anything gets built. Then it holds itself to that goal, and lists every decision it made on its own whenever you ask. You stay the decision-maker on your own project.
Install
Open Claude Code, or your favourite coding agent, and paste this into the chat:
› Install the Context is Queen skill globally from github.com/hgambas/think-like-a-pm
“Globally” means it works in every project, not just the one you're in.
There is a second way to install it, as a Claude Code plugin. Same skill, except it also offers itself at the start of a session instead of waiting to be asked:
› /plugin marketplace add hgambas/think-like-a-pm
Your first briefing, in three steps
- 1.Ask for something complex, in your own words
“Rework our onboarding so people finish setup.” No special syntax needed. The briefing starts on its own for multi-step work, and simple asks skip it.
- 2.Answer the questions, one at a time
Three to eight of them, covering only what your agent can't research for itself.
- 3.Correct the proposed goal
Fix anything wrong in the goal it proposes, before any work starts.
Choose a command
You never need commands — plain requests work, and the skill routes them. The commands exist for when you want to steer directly:
| You're thinking… | Run |
|---|---|
| “I'm starting something big” | brief |
| “Just ask me the right questions” | interview |
| “We already covered the context” | set-goal |
| “Wait, when did we decide that?” | drift-check |
| “Turn the goal into a work list” | backlog |
Useful pairs: brief → backlog (strategy, then the work it implies) · drift-check → set-goal (found drift? refresh the target).
The idea in one paragraph
When you don't read code, the biggest risk isn't that the AI misunderstands one instruction. It's that it keeps moving and quietly makes decisions you never approved. So this skill makes the agent gather enough context first: its own research, plus an interview with you, one question at a time. Only then does it propose a goal, and you correct it before anything is built. That's the whole trick: an agent aimed at a corrected goal produces dramatically better work than one that guessed.
brief
The full briefing: interview, research, then goal. Runs by default when you use /context-is-queen with no command.
When to use it
At the start of complex work: multi-step projects, handoffs, anything with many decisions. If you'd feel nervous handing it to a contractor with one sentence of instructions, it deserves a briefing.
How it works
- 1.It says what it needs from you
It separates what only you know from what it can research itself.
- 2.It does its own research
Everything it can look up, it looks up — so your time goes only to questions you alone can answer.
- 3.It interviews you
One question at a time, covering only what's still unsettled after the research.
- 4.It proposes the goal
What “done” looks like, how it's judged, which decisions stay yours. You correct it once, up front.
- 5.It runs the loop
It opens with a plan of attack — the passes it intends to run, with your open decisions marked where they block — then works the passes, checking each success measure pass, fail, or uncertain at every checkpoint, with evidence. While a decision sits with you, it keeps working the lanes that decision doesn't touch. It can only call the work done when every measure passes, or you've said one doesn't matter.
Try it
A normal ask — the briefing starts on its own for complex work. Force it any time with /context-is-queen.
A healthy briefing: three to eight questions, a short research pass, one goal proposal, one round of corrections. A few minutes that prevent days of rework.
Pitfalls
- Skipping it because it feels slow. Complex work without a briefing turns into rework later.
- Letting it set the goal first. A goal proposed before the interview is your own words parroted back — nothing to correct.
- Running it on trivial asks. It's for complex work. On small asks it's noise you'll learn to tune out.
interview
Get asked the right questions, one at a time, and only the ones you alone can answer.
When to use it
When you want your thinking drawn out before any work happens — shaping an idea, briefing a feature, or handing work to someone else and wanting your requirements made explicit first.
How it works
One question at a time, never a batch. A batch of five questions gets skimmed; one question gets a real answer. Each answer shapes the next question.
It focuses on what's still unclear:
- gaps in your instructions
- where effort should go, and where it shouldn't
- the outcome you expect, and how you'll test it
- which decisions stay yours
- whether this is planning, building, or both
- whether the work needs separate perspectives, like product, design, or engineering
Try it
Or: /context-is-queen interview
AgentHow will you judge whether the revamp worked?
YouMore visitors starting a trial.
AgentGot it. Which decisions do you want brought back to you — copy and layout, or only pricing structure?
Expect three to eight questions. Say “standard” and it will ask what standard means for this project.
Pitfalls
- Answering vaguely. Specificity is the whole point — the follow-up exists because “normal” carries no information.
- Expecting a form. It's a conversation, not a questionnaire; you answer naturally.
set-goal
Turn context already gathered into a specific goal you can correct.
When to use it
Use it when the interview and research are done but no goal has been proposed yet. Also to refresh a goal after plans change.
How it works
The agent writes the goal in plain language: what “done” looks like, how it will be judged, which decisions come back to you, what's deliberately out of scope, and the checkpoints where it returns to you. Then it asks you to correct the proposal before work starts. Once agreed, the goal stays open on the agent's desk: it re-reads it as it works, and tests the finished work against it before reporting done.
Agent · proposed goalNew users complete setup on their own — judged by completion rate and fewer setup-related support emails. Structural decisions come to you; I own copy and styling. Out of scope: pricing and the mobile app. Checkpoints: after the flow is mapped and after the first working pass. Correct anything before I start.
Try it
Or: /context-is-queen set-goal
A goal is a compass, not a spec: under ten lines, always correctable. A goal that comes back untouched deserves suspicion: check that it added real judgment instead of restating your words.
Pitfalls
- Accepting a restatement. If the goal only contains your own words, there's nothing at stake and nothing to correct.
- Letting it balloon into a plan. Ten lines. The plan comes after the goal is agreed.
drift-check
A mid-project check: which decisions were made since the goal was set, and did the agent have permission to make them?
When to use it
After a long stretch of work, a handoff, or when resuming a session. Any time you get the “wait, when did we decide that?” feeling.
How it works
The agent walks back through everything since the goal was agreed and lists every real decision — things that could have gone another way. Each one is classified: yours (you made it), the agent's, allowed by the goal, or drifted: a decision you said should come back to you, made without you. Drifted decisions come first in the report, each with a recommendation: keep, revisit, or undo. You choose; it never silently reverts work.
Try it
Or: /context-is-queen drift-check
A healthy check: a handful of decisions, zero to three drifted. Many drifted decisions means the goal was unclear about which decisions belonged to you. Refresh it with set-goal.
Pitfalls
- Reopening decisions you already made. If you made the call, it's closed. This is a check, not an appeal.
- Letting it become a new briefing. List, classify, recommend — short and factual.
backlog
Turn the approved goal into work items: generate a backlog from it, or review an existing one against it.
When to use it
Generate: the goal is agreed and no work list exists yet; you need the work it implies, written down. Review: a list already exists and the goal just changed; you need to know which items still support it.
How it works
Each item describes the problem to solve or the outcome to reach — never how to build it. The moment an item names a file, it has stolen a decision from the person who'll build it. Each item carries what's happening in plain English, why it serves the goal, and how you'll know it worked.
When reviewing an existing list, each item lands in one of four groups: keep, rewrite (right idea, stale wording), doesn't fit (proposed for removal; you decide), and missing (work the goal demands that no item covers, drafted for you).
Try it
Or point it at an existing list. Explicitly: /context-is-queen backlog
It proposes, you decide: priority order is a suggestion, removals are proposals, and showing what's missing beats guessing.
Pitfalls
- Running it without an agreed goal. A backlog without a goal is a to-do list of guesses. It will ask to run brief first.
- Letting items turn into specs. Problems and outcomes only — the how belongs to whoever builds it.