023-assumption-analysis
From the author
Use when a framed and root-caused problem needs its assumptions made explicit before design or planning begins — explicit Assumptions, Unknowns, and a Validation plan. This should trigger when an issue's Assumption Analysis point of view needs evaluation, or when a maintainer directly asks to surface hidden assumptions and unknowns before committing to an approach. Part of Plinth Toolkit
Install
npx skills add jabrena/plinth --skill 023-assumption-analysis -a claude-code
Installs to .claude/skills/023-assumption-analysis/ · Each command fetches the skill straight from GitHub with the open skills CLI.
Byte-identical to the scanned commit, with the repository’s licence and a SOURCE.txt.
Want your agent to suggest skills while you type? See how to use skills from your IDE.
Safety checks on SKILL.md
No warnings.
Why 86
aiqbench computes the trust score from public signals. It is not a security audit, so read a skill before you install it.
Similar skills
Closest to this one by what they do and when they are used.
- 021-problem-framingjabrena/plinthUse when a problem or issue needs explicit framing before deeper analysis begins — establishing the Problem statement, Current state, Desired state, Stakeholders, and Success criteria. This should trigger when an issue's Problem Framing point of view needs evaluation, or when a maintainer directly asks to frame a problem before root-cause analysis, design, or planning begins. Part of Plinth ToolkitDesign★ 455
- 024-context-mappingjabrena/plinthUse when a problem under exploration needs its surrounding system context identified before design begins — Existing systems, Integrations, Ownership, and External dependencies. This should trigger when an issue's Context Mapping point of view needs evaluation, or when a maintainer directly asks to map the systems, integrations, owners, and external dependencies relevant to a problem. Part of Plinth ToolkitProductivity★ 455
- 022-root-cause-analysisjabrena/plinthUse when a framed problem needs root-cause investigation rather than a symptom-level fix, applying Five Whys, Fishbone (Ishikawa), Current Reality Tree, and constraint identification. This should trigger when an issue's Root Cause Analysis point of view needs evaluation, or when a maintainer directly asks to find the root cause of a problem before proposing a fix. Part of Plinth ToolkitFinance★ 455
- solution-explorationcbrock84/headcountExplores the problem and the range of possible approaches before any code is written — clarifying what is actually being asked, surfacing options with their tradeoffs, and converging on one. Use this at the start of any feature, component, or behavior change, when a request is ambiguous, when the first idea is the only idea on the table, or when a design decision needs pressure-testing before commitment.Testing★ 2.1K
- scenario-planningcbrock84/headcountPlans under genuine uncertainty — building scenarios, identifying which assumptions are load-bearing, setting early-warning indicators, and stress-testing a plan against futures rather than forecasting one. Use this when a decision depends on something unknowable, when a plan assumes conditions that may not hold, before a large irreversible commitment, or when a market, regulatory, or technology shift could invalidate the strategy.Planning★ 2.1K
- 025-quality-attribute-discoveryjabrena/plinthUse when a problem under exploration needs its quality attributes (non-functional requirements) identified and prioritized before architecture and design begin. This should trigger when an issue's Quality Attribute Discovery point of view needs evaluation, or when a maintainer directly asks to discover and prioritize candidate quality attributes for a problem, before any ADR or design work starts. Part of Plinth ToolkitDesign★ 455
Ratings & reviews
—
no reviews
Tried this skill? Rate it to help others. Sign in
Discussion
Join the discussion. Sign in