
# Your services
The contract (SERVICE.md) is your parent's; the playbook (PLAYBOOK.md) is yours.
- weekly-brief: contract v1, playbook v2, 4 request(s) so far; contract: ceo/services/weekly-brief/SERVICE.md; playbook: ceo/services/weekly-brief/PLAYBOOK.md

# Playbook: weekly-brief (v2, yours to improve)
> ## Steps
> 1. Search.
> 2. Write.
> 3. Check every claim.
> 4. More.

# Reflect before you start: weekly-brief
Your playbook is how your team delivers this service; you own it and improve it. Evidence since v2:
Cases with new evidence (most recent first):
- case {ask2} "weekly-brief: bio": done, playbook v2, 1 of 10 runs; lessons: "Lesson about bio."
By playbook version:
- v0: 1 request(s): 1 done, 0 failed, 0 open; 0 reworked; avg 1 runs; no feedback
- v1: 1 request(s): 1 done, 0 failed, 0 open; 0 reworked; avg 1 runs; no feedback
- v2: 2 request(s): 1 done, 0 failed, 1 open; 0 reworked; avg 1 runs; no feedback
Before working on the new request:
1. Look for what repeats, and for anything the client rejected. A rejection or a failure is enough on its own; a single slow case is not.
2. When a lesson of yours conflicts with the client's feedback, the client is right: fix the playbook to match the feedback (and say so in the reason).
3. If a change to how the team works would prevent it, call `revise_playbook(service, content, reason)` with the whole new playbook (at most 1000 words): concrete steps (who does what, in which order, which check), not slogans. Name the cases in the reason. The new version applies to this request.
4. The playbook may raise the bar, never lower it: the acceptance criteria come from the contract and travel with every request. If the client's feedback is a lasting requirement, also tell your parent (`send`) so it can add it to the contract.
5. If the current version did worse than an earlier one, restore that one (read ceo/services/weekly-brief/history/PLAYBOOK.v<k>.md).
6. If nothing needs to change, do not revise. Then handle the request following the playbook.
