Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add assimovt/productskills --skill problem-validationgit clone --depth 1 https://github.com/assimovt/productskillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/assimovt/productskills/problem-validation)<a href="https://agentmods.dev/skills/assimovt/productskills/problem-validation"><img src="https://agentmods.dev/badge/skills/assimovt/productskills/problem-validation.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.00948 |
| Opus 5 | $0.00030 | $0.00474 |
| Sonnet 5 | $0.00012 | $0.00190 |
| Haiku 4.5 | $0.00006 | $0.00095 |
Grade A, and why
problem-validation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 95 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Validate problems with evidence, not opinions. A problem worth solving is one that people encounter frequently, feel intensely, and have already tried to solve. If nobody has attempted a workaround, the problem isn't painful enough to build for.
Scoring Framework
Rate each dimension 1-5 based on evidence:
Frequency (How often does this happen?)
- 5: Daily or multiple times per day
- 4: Weekly
- 3: Monthly
- 2: Quarterly
- 1: Rarely or once
Intensity (How painful is it when it happens?)
- 5: Blocks critical work, causes real losses (money, time, reputation)
- 4: Major friction, significant workarounds needed
- 3: Annoying but manageable
- 2: Minor inconvenience
- 1: Barely noticeable
Existing Workarounds (Are people already trying to solve it?)
- 5: Paying for imperfect solutions or built custom tools
- 4: Cobbled together multi-tool workflows (spreadsheets + email + manual steps)
- 3: Have a basic process but it's tedious
- 2: Occasionally Google for solutions
- 1: Haven't tried to solve it
Willingness to Pay (Would they pay to make this go away?)
- 5: Already spending money on partial solutions
- 4: Have explicitly said they'd pay (and named a number)
- 3: Would "probably" pay (hypothetical — discount this)
- 2: Want it free
- 1: Haven't considered paying
Validation Score = Frequency x Intensity x Workarounds x WTP
- 250+: Strong signal. Build.
- 100-249: Promising. Needs more evidence on weak dimensions.
- Under 100: Weak. Either pivot the problem framing or walk away.
Example: "PDF Export" — Frequency: 3 (monthly board reports), Intensity: 2 (screenshot workaround exists), Workarounds: 4 (3 users built browser-print-to-PDF workflows), WTP: 1 (nobody has paid for an export tool). Score = 3 x 2 x 4 x 1 = 24. Verdict: Kill — not painful enough.
Evidence Requirements
Every score MUST cite evidence. Acceptable evidence types, strongest first:
- Observed behavior: You watched someone struggle with this
- Spending: They pay for alternatives or workarounds
- Time invested: They built custom solutions (scripts, spreadsheets, processes)
- Quotes from interviews: Direct quotes about past behavior (Mom Test compliant)
- Support tickets / forum posts: Public complaints with specifics
- Survey responses: Weakest — people say one thing and do another
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 95 lines · 59 tokens per session scan A 5f455cb8d0a0
problem-validation is a skill published in the GitHub repository assimovt/productskills (66 stars, last pushed 6mo ago), licensed MIT. It adds 59 tokens to every session and 948 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
handoff
Phase 3 of the prd-taskmaster pipeline: smart mode selection and user handoff. Detects installed capabilities (superpowers, ralph-loop, task-master-ai, playwright, research providers), recommends ONE execution mode (A/B/C) with reasoned justification, appends the task-execution workflow to CLAUDE.md, surfaces a…
prd-taskmaster
Zero-config goal-to-tasks engine (the Atlas engine). Takes any goal (software, pentest, business, learning), runs adaptive discovery via brainstorming, generates a validated spec, parses into TaskMaster tasks, and hands off to execution. Use when user says "PRD", "product requirements", "I want to build", invokes…
generate
Phase 2 of the prd-taskmaster pipeline: spec generation and task parsing. Loads a template (comprehensive|minimal), fills it with DISCOVER-phase constraints and answers, validates the spec (placeholdersfound, grade thresholds), parses the PRD into tasks via task-master, runs TaskMaster's native complexity analysis…
customise-workflow
Customise the prd-taskmaster plugin workflow via curated brainstorm questions. The AI asks, the user answers in plain English, and the skill writes their preferences to .atlas-ai/config/atlas.json. Future runs of prd-taskmaster read that file and apply user preferences to phase gates, validation strictness, default…
discover
Phase 1 of the prd-taskmaster pipeline: brainstorm-driven discovery. Delegates to superpowers:brainstorming in Interactive Mode (one adaptive question at a time), or self-brainstorms in Autonomous Mode when no user is present. Intercepts before the brainstorming chain hands off to writing-plans — this skill owns the…
execute-fleet
Phase execution skill for licensed Atlas Fleet runs. Use when HANDOFF has selected Atlas Fleet and the project should be executed across isolated launcher worktrees with inbox-based result collection, verified CDD cards, sequential integration merges, and one final PR.