call-to-scope
- Trigger
- After a discovery call, before a proposal or quote
- Output
- Outcome, deliverables, exclusions, assumptions, acceptance checks and open questions
- Guardrail
- No price or timeline is produced unless the user supplied one.
Skill pack
Client room
Four skills that keep a client engagement legible: call-to-scope, weekly updates, decision logs and handoff packs.
weekly-update
- Trigger
- When the weekly client update is due
- Output
- Status, outcomes shipped, next commitments with dates, blockers and decisions needed
- Guardrail
- A scope change is labelled before it is absorbed into the plan.
decision-log
- Trigger
- When a client makes, changes or reverses a decision
- Output
- A dated entry with the decision, the owner, the options considered and what it changes
- Guardrail
- The log records what was decided, not what the agent thinks should have been decided.
handoff-pack
- Trigger
- At the end of a phase, or when someone else takes over
- Output
- Current state, open work, access, risks, decisions and the first three things to read
- Guardrail
- Secrets and credentials are referenced by owner, never copied into the pack.
Install
Put the pack in the project
Create `skills/call-to-scope/`, `weekly-update/`, `decision-log/` and `handoff-pack/` in the client project.
Give each skill its own `SKILL.md` with a description written as the moment it should fire: 'after a discovery call', 'when the weekly update is due'.
Keep the client's scope, milestone list and decision log in `references/`, not inside the instructions.
Run the tests below with a real (redacted) call note. If the scope has no exclusions, the skill is not doing its job.
skills/my-pack/
|-- SKILL.md
|-- references/
|-- scripts/
`-- assets/
Test
Prove the pack does something
Turn these discovery notes into a scope I can send before quoting.
Pass condition: The output has an out-of-scope section, at least three assumptions and open questions above the deliverables.
Write this week's update. The client asked for one extra report on Tuesday.
Pass condition: The extra report appears in the scope watch as 'change' or 'unknown', not silently in the plan.
The client changed the launch date. Log it and tell me what moves.
Pass condition: A dated decision entry is created, with the affected milestones and the owner of the change.
Why this pack
Client work fails at the seams: a request that was never scoped, a decision that was never written down, a handoff that lives in someone's head. The work itself is usually fine. The record is not.
This pack makes the record a byproduct of the work. The scope skill runs after the call; the update skill runs weekly; the decision log runs when something changes; the handoff pack runs at the boundary. None of them needs a new tool.
The rule behind the pack
If it changes the plan, it goes in writing before it changes the plan. That is the whole discipline. A scope that absorbs a new request silently is not a scope; it is a hope.
Adapting it
- For retainers, add a capacity table to the weekly update: units used, units left, what triggers a new scope.
- For agencies, keep an internal version of the update with the risk line you do not send.
- For fixed-price work, make the change label mandatory in every update, even when the answer is “no change”.
Failure modes
- The update becomes a diary. Cut activity that did not change an outcome.
- The decision log becomes a blame log. Record the decision and its owner, not the argument.
- The handoff pack contains credentials. Reference the owner and the vault entry; never paste the secret.
Related
Skills are instructions, not a security boundary.
Read a skill before you install it, keep secrets out of the folder, and treat scripts as code you are about to run. The full pack is in the Markdown mirror at
/skills/client-room.md.
Found a gap in the library?
Send the scenario, the prompt that failed, or the harness change that broke your setup. The help desk takes questions and corrections from humans and agents, and every accepted fix updates the page date.