All authors
Claude Skills by designedbythanh
github.com/designedbythanh16 skills0 installs3 views
- Acceptance CriteriaTurn a user story into Given/When/Then acceptance criteria covering the happy path, errors, and edge cases. Use to define \"done\" before engineering starts building.Votes: 0GitHub stars: 2
- Assumption ReversalFlip your current design assumptions 180° and generate concrete ideas from the reversed perspective. Use when stuck on ideas or wanting to pressure-test the current design direction.Votes: 0GitHub stars: 2
- Cross Industry StealFind 3 solutions from unrelated industries that solve a structurally similar problem, and translate the strongest one into a concrete idea. Use when stuck on ideas or need fresh inspiration outside the category.Votes: 0GitHub stars: 2
- Data InterpretationInterpret metrics or experiment results by separating fact from explanation and ruling out alternative causes before recommending action. Use when reviewing results and need to draw a real conclusion, not just eyeball a chart.Votes: 0GitHub stars: 2
- Decision RationaleDocument a design decision between 2 options with explicit criteria, scenario testing, and a confidence-rated recommendation. Use when torn between two directions and need a defensible, written rationale - not just a gut call.Votes: 0GitHub stars: 2
- Design Critique FacilitatorFacilitate a structured design critique across 5 lenses (clarity, hierarchy, consistency, interaction & feedback, edge cases), starting from the designer's intent, concerns and what's already decided, and tagging each fix by severity and owner. Asks before critiquing and measures before praising. Use when presenting work for feedback, to get specific critique anchored to the designer's intent instead of vague opinions.Votes: 0GitHub stars: 2
- Design Scope NegotiatorSort a design scope into Ship / Fast-follow / Cut using effort vs. impact-if-removed, with the reason for each. Use when pushing back on scope creep or negotiating what gets cut before a deadline.Votes: 0GitHub stars: 2
- Edge Case FinderStress-test a feature across 5 failure dimensions (input, permissions, concurrency, dependencies, user behavior) before it ships. Use before handing a spec to engineering, to catch what breaks.Votes: 0GitHub stars: 2
- Experiment DesignPlan a product experiment - hypothesis, control and variant, duration, decision rule - and flag when traffic is too low for a reliable result. Use when planning an A/B test or any product experiment.Votes: 0GitHub stars: 2
- Explain To 4 AudiencesTranslate one design decision into 4 audience-specific explanations (10-year-old, engineering, executive, end user) to pressure-test whether it's actually clear. Use after designing, before presenting, writing docs, or shipping.Votes: 0GitHub stars: 2
- Five Whys Root CauseDig past a stakeholder's feature request to the real underlying need, using 5 consecutive Why questions, then surface alternative solutions. Use when a stakeholder or client requests a specific feature and you want to check it's solving the real problem.Votes: 0GitHub stars: 2
- Persona PretestSimulate how a specific user persona would react to a design or flow, surfacing likely confusion, objections, and drop-off points before real user testing. Use when you want a fast sanity check on a design before investing in a usability study.Votes: 0GitHub stars: 2
- Prd First DraftWrite a PRD first draft that's clear enough for engineers to build from and concise enough for executives to read in 5 minutes. Use when starting to spec a feature or product.Votes: 0GitHub stars: 2
- Success Metrics DefinitionDesign a metrics framework (primary metric, leading/lagging indicators, counter-metrics) that proves a feature solved the real problem, not just that it was used. Use when defining what success looks like before building.Votes: 0GitHub stars: 2
- User Interview SynthesisTurn messy interview notes from multiple users into ranked insights, frustrations, and unspoken needs. Use after collecting raw notes from user interviews.Votes: 0GitHub stars: 2
- Product ContextWrite down the context the other skills keep asking for: a PRODUCT.md for the product (users, roles, references, vocabulary, where known issues live) and a brief per feature (goal, stage, what's decided and open, worries, and a log other skills add to). Use at the start of a project or a new feature, or when skills keep asking for the same context.Votes: 0GitHub stars: 2