teambrilliant/working-backwards
skills/working-backwards/SKILL.md
Write a PR-FAQ to pressure-test a product idea customer-first — before committing engineering. Use when someone says "write a PR-FAQ", "press release", "working backwards", "PRFAQ", "start from the customer", "what's the press release for this", "before we build this", "is this idea clear enough to build", "draft the launch announcement", or has a fuzzy product idea and wants to force clarity on what to build and why. Amazon's Working Backwards method: define the desired customer experience as a mock press release + FAQ, iterate on the document until the thinking is clear, and kill weak ideas cheaply on paper. Sits between product-thinker (should we?) and shaping-work (what exactly?), alongside product-discovery (will it work?) — this skill answers "what is the customer-facing end-state, stated so plainly that the holes show?" NOT for validating risky assumptions with experiments (use product-discovery), NOT for breaking shaped work into a build plan (use shaping-work / implementation-planning).
$ install --global
skillsauthnpx skillsauth add teambrilliant/dev-skills working-backwardsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 10, 2026, 5:31 AM90.9s4 files scanned
SKILL.md
- name:
- working-backwards
- description:
- >-
- on what to build and why. Amazon's Working Backwards method:
- define the desired customer experience
Working Backwards
Start from the customer and the desired end-state, write it down, and iterate on the document until the thinking is clear — long before any engineering. The artifact is a PR-FAQ: a one-page mock press release + an FAQ of the hard questions. Most PR-FAQs are never built — killing a weak idea cheaply on paper is the point, not a failure.
Why writing: prose forces clarity that slides and good intentions can't. If you can't write a compelling, honest press release for it, you don't understand it yet — and neither will the customer.
References:
references/pr-faq-template.md— the press-release + FAQ structure, section by section.references/six-page-narrative.md— the prose-memo / silent-read discipline (for proposals & reviews beyond a launch).references/input-metrics.md— input-vs-output metrics, DMAIC, the WBR (how you'd measure it once live).
When to use this vs. its neighbors
- product-thinker decided should we? → use Working Backwards to force the customer end-state into focus.
- Idea is fuzzy / stakeholders disagree on what it even is → write the PR-FAQ; the draft surfaces the disagreement.
- The risk is "will this technically/behaviorally work?" → that's product-discovery (experiments), not this.
- The PR-FAQ is approved and clear → hand to shaping-work to define the work.
The method
- Write the press release first (customer-benefit-first, < 1 page). Use the template. Write it as if it already launched. The customer's problem and the benefit lead — not the technology.
- Write the FAQ (≤ 5 pages). Put the hard questions in, the ones that could kill it: market size, per-unit economics, dependencies & third-party risk, feasibility, what has to be true. The FAQ is a pre-mortem on your own idea — if you skip the uncomfortable questions, the document is dishonest.
- Iterate as a document. Circulate; open the meeting with a silent read; take general feedback first, then line-by-line; seniors speak last (no anchoring). Expect 10+ drafts. Revise from the criticism, not around it.
- Decide: build / kill / keep iterating. A PR-FAQ that can't be made compelling and honest is a cheap save — kill it here, not after a quarter of engineering.
Output
A PR-FAQ (press release + FAQ, from the template) and a clear verdict. Close with the signature block:
`★ Working Backwards View ────────────────────────`
- Customer + benefit: [who, and the one-line win]
- Verdict: [build / kill / iterate] — [why in one line]
- Biggest hole: [the FAQ question most likely to kill it]
`─────────────────────────────────────────────────`
Handoffs
- Verdict = build, but a key assumption is unproven →
product-discovery(test it cheaply first). - Verdict = build, and it's clear →
shaping-work(define the work), thenimplementation-planning. - Need to re-litigate whether to build at all →
product-thinker.
Related Skills
teambrilliant/strategic-thinker
development
VerifiedTrustedCommunity
Use for cross-domain strategic reasoning, approach selection, and systems-level analysis. Trigger when the user wants to: think through how to approach a problem, evaluate tradeoffs between architectural or technical approaches, sanity-check a plan or direction, understand second-order effects of a decision, get a holistic view across code/org/time dimensions, or pressure-test assumptions. The core signal is the user asking "what's the right approach?", "think about this", "what am I not seeing?", "sanity check", "tradeoffs", "how should we tackle this?", or any request for multi-level reasoning that spans product, architecture, and organization. Also use when the user needs help deciding which workflow skill to invoke next. NOT for: product/user/business decisions (→ product-thinker), work definition (→ shaping-work), file-level technical planning (→ implementation-planning), writing code, test authoring, or PR review.
5SKILL.mdUpdated Apr 18, 2026
teambrilliant/qa-test
tools
VerifiedTrustedCommunity
Browser-based QA verification after any implementation. Use when someone says "QA this", "test this in browser", "verify the feature", "qa test", "browser test", or after completing an /implement-change to verify acceptance criteria in a real browser. Opens Chrome via MCP, exercises each acceptance criterion, verifies via DOM snapshots, and reports pass/fail. The "closer" for every implementation — proof it works, not just that tests pass.
5SKILL.mdUpdated Apr 15, 2026
teambrilliant/implementation-planning
development
VerifiedTrustedCommunity
Create technical implementation plans and architecture designs. Use when someone needs a detailed technical approach before coding begins — "create a plan", "plan this ticket", "how should we implement this", "technical design", "architect this", "design the approach", "plan the migration", "refactor plan", "how should we structure this", or when shaped work or a groomed ticket needs a concrete implementation strategy with phases, file changes, and verification steps.
5SKILL.mdUpdated Apr 15, 2026
teambrilliant/implement-change
development
VerifiedTrustedCommunity
Execute code changes from an implementation plan. Use when someone says "implement this", "build this", "code this", "start building", "let's implement", "execute the plan", "make the changes", "do the work", or has an approved implementation plan ready for coding. Takes implementation plans and produces working code, phase by phase with verification.
5SKILL.mdUpdated Apr 15, 2026