write-brief
Skill15 starsChanged 5 months agoMITView on GitHub
Use when the user wants the human-facing decision document for a problem or bet that has been investigated, to align people on it or to force a choice. Covers three shapes: a narrative or report (problem, why now, impact, and the ask), a hard-questions FAQ, or a decision or options memo that weighs several options (including do-nothing), recommends one, and states the ask. Trigger on phrasing like 'write the brief', 'draft the brief', 'opportunity brief', 'the narrative', 'the FAQ', 'decision memo', 'options memo', 'recommendation memo', 'weigh options and recommend one', or after a decision passes the readiness gate. This is the leadership decision artifact, rendered from existing evidence and scores, NOT an engineering PRD, spec, acceptance criteria, status update, competitive battlecard, or metrics review. Refuses to invent metrics.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- giorgosn/diavgeia-watchdogtheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- giorgosn/diavgeia-watchdog★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- calibrateSkill
- critiqueSkill
- decision-readinessSkill
- design-testSkill
- discover-sourcesSkill
- drift-checkSkill
- gather-evidenceSkill
- pressure-testSkill
- prioritize-backlogSkill
- scorecardSkill
- startSkill
- synthesizeSkill
- to-build-briefSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 34
Put evidence in appendices, not in marketing claims.
- Very specific: line 35
Run critique (panel mode) on the FAQ and tag each answer resolved / open / contested before calling it done.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Write Brief
Produce the human decision artifact for a decided problem or bet, in the requested style. Narrative and FAQ styles persuade and align humans around the problem, why now, impact, and ask; memo style forces a yes/no or option choice with a recommendation and explicit ask. It is not an implementation spec. Each style renders from the same .product-eval/<scope>/ content (problem, evidence, themes, scores, decision). Never invent metrics, owners, or dates, write "Not provided in input" instead.
Preconditions
The brief is gated on decision-readiness. Check the item's latest verdict in .product-eval/<scope>/decisions-log.md: if there is no passing (Decide-now) verdict, or the latest outcome is "Run a research sprint", do not produce a confident brief. Say so, and offer a "decision-readiness brief" that states the gaps and points to design-test for the cheapest validating test instead.
Also run the conformance preflight in DATA-CONTRACT.md (Validation) on the scope files you render from; if scores.md, themes.md, or decisions-log.md fails a check, report the violation rather than rendering a brief from inconsistent data.
Styles, --style narrative | faq | memo | both
narrative / report
A flowing readout: problem → why now → proposed solution → customer & business impact → success metrics → the ask. Prose, not bullets; one quantified claim early; explicit before/after; no unsupported roadmap commitments. Optional press-release voice (write it as if already shipped). Structure and starters in references/opportunity-brief.md.
faq
The hard-questions version, the completeness gate. Answer the question bank in references/opportunity-brief.md (problem, customer, timing, alternatives, limitations, out-of-scope, failure modes, success metrics, one-way doors, …). This version is also the scaffold the critique lens-panel attacks before the doc is "done".
memo
A decision-oriented memo that forces a yes/no or option choice by a deadline, for driving a decision, not persuading. Headings in order: purpose & decision requested (one sentence + deadline) · executive summary (customer + business impact) · current state & evidence (each claim with source + strength) · root cause · options considered (≥3 incl. do-nothing; table Option | Summary | Benefits | Tradeoffs | Key risk | Why not selected) · recommended strategy (falsifiable success/failure criteria) · metrics scorecard (Metric | Baseline | Target | Owner | Date) · economics if relevant · risks/dependencies/mitigations (owner + close date) · the ask (concrete, owner- and time-bound). Run critique on the recommendation's falsifiability and whether do-nothing is honestly weighed.
both
Narrative as the readout, FAQ as the backing appendix.
Workflow
- Load the decided problem, its evidence, scores, and verdict from the scope.
- Render the requested style(s) from
references/opportunity-brief.md. - Put evidence in appendices, not in marketing claims; cite source + strength.
- Run
critique(panel mode) on the FAQ and tag each answer resolved / open / contested before calling it done. - Export to docx/pdf if asked (read the docx/pdf skills). Write to
.product-eval/<scope>/docs/.
Output
The brief in the requested style plus the critique summary (resolved / open / contested counts). Lead with the one-paragraph essence. End with Next move: and recommend resolving open FAQ items, pressure-testing the plan if commitment risk remains, or turning the approved decision into a build brief.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

