product-framing
Skill1 starsChanged 3 months agoMITView on GitHub
Frame the problem before any design work — audience, one user problem, target behavior, constraints, explicit scope. Use when starting a feature or product, when a request jumps straight to solutions, when scope keeps growing mid-work, or when nobody can say who the change is for.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- shreyas-makes/agent-skillstheir own version, first seen Jul 15, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- shreyas-makes/agent-skills★ 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 repository14 other files it gives its agents.
- accessibilitySkill
- colorSkill
- content-designSkill
- design-reviewSkill
- design-systemSkill
- implementation-reviewSkill
- interaction-designSkill
- layoutSkill
- measurementSkill
- motionSkill
- product-evidenceSkill
- typographySkill
- validationSkill
- visual-directionSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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 14
Write these, in this order, before anything else:
- Distinctive: line 27
If any line takes more than a sentence, the frame isn't ready.
- Very specific: line 31
Every claim about users cites something checkable: analytics, support tickets, issue history, a real conversation, the live product.
- Distinctive: line 32
Never invent personas, quotes, KPIs, or research findings.
≈ “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
Product Framing
Design work without a frame optimizes a random target. The frame is ten lines written before any wireframe, token, or component. It costs five minutes and prevents the expensive failure: building the wrong thing beautifully.
A frame compresses evidence; it does not generate strategy from a brief. Run the product-evidence skill first when the claims about users are unverified: the frame's Evidence and Unknowns lines are lifted from that ledger, not written from imagination.
The frame
Write these, in this order, before anything else:
- Audience: who exactly. "Developers on the free tier who hit the rate limit", not "users".
- One problem: a single observed struggle, in one sentence. Two problems means two frames.
- Evidence: the strongest signal the problem is real: analytics, tickets, a real conversation, the live product. Nothing checkable? Write
assumptionhere and treat the frame as a bet, not a fact. - Target behavior: what the person does after the change that they couldn't or wouldn't before.
- Success metric: the number that moves when the behavior happens, and where it's measured today. No baseline, no metric line.
- Feeling: the one word the interface should produce. Confidence, calm, momentum. This drives visual direction later.
- Constraints: platform, existing design system, deadline, tech debt that stays.
- In scope: the screens and paths that change.
- Non-goals: the adjacent things you're deliberately not touching. Written down, or scope creep is guaranteed.
- Unknowns: the open questions that could invalidate the frame, each with who or what answers it.
If any line takes more than a sentence, the frame isn't ready. A frame is allowed to be uncertain; it is not allowed to hide it. Three honest assumptions and two named unknowns beat ten confident lines nobody checked.
Evidence rules
- Every claim about users cites something checkable: analytics, support tickets, issue history, a real conversation, the live product. "Users want X" with no source is your assumption; label it
assumptionand move on. - Never invent personas, quotes, KPIs, or research findings.
- Inspect the existing product and repository before asking anyone anything. Most framing questions are answered by what's already shipped.
Small changes keep the existing frame
A bounded edit to an existing screen doesn't reopen product strategy. Note "framing unchanged", confirm the edit serves the existing frame, and move to structure. Reopening the why on every button change is how process kills teams; skipping the why on a new journey is how teams ship the wrong product. The line: new journey or new audience reopens the frame, everything smaller inherits it.
The frame is the referee
Downstream disagreements (which layout, which copy, which color) get settled by pointing at the frame, not by taste or hierarchy. When a decision can't be traced to a line in the frame, it's decoration. When the frame itself turns out wrong mid-work, change the frame first, in writing, then the work.
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.