dcode:jtbd-prd-frame — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited dcode:jtbd-prd-frame (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Reframe feature definitions around the user's job, not the feature itself.
For designers who think: "We're building a referrals page... but what is the agency actually trying to do?"
Every feature exists to help a user complete a job. If the PRD describes the feature without naming the job, the team will build what was specced instead of what's needed. Frame the job first, then define the feature as the means to get it done.
Ask: "When the user comes here, what are they trying to get done?"
Not what the feature does. What the user is hiring it for.
| Feature-framed | Job-framed |
|---|---|
| Referrals page | "Earn money by connecting clients to products" |
| Plugin management | "Keep my client sites healthy and up to date" |
| Reports dashboard | "Prove my value to clients with data" |
| Team settings | "Control who on my team can do what" |
Format: [When I'm...] [I want to...] [so I can...]
Examples:
Replace feature-centric language with job-centric language:
| PRD Section | Feature-centric | Job-centric |
|---|---|---|
| Title | "Referral Checkout Form" | "Client Onboarding & Commission Earning" |
| Problem | "The form needs better UX" | "Agencies lose track of the job mid-flow" |
| Success metric | "Form completion rate" | "Agencies who earn their first commission" |
| Scope | "Fields, validation, CTA" | "Everything between 'I found a product' and 'my client is set up'" |
When deciding where a feature lives in the product:
Ask: "What job does this do for the user?" Not: "Which team owns it?"
This is how governance works. If two teams want top-level nav space, the answer isn't politics. It's: "What job? Does that job already have a home?"
| Placement question | Wrong frame | Right frame |
|---|---|---|
| "Where does WooPayments go?" | "WooCommerce team owns it" | "It helps agencies earn revenue" → Earn section |
| "Where do dev tools go?" | "Engineering built them" | "They help manage client sites" → Clients section |
| "New reporting feature?" | "Analytics team request" | "Helps prove value to clients" → Already in Earn |
Flag any section that describes the feature without naming the job. Suggest a reframe.
| Mistake | Fix |
|---|---|
| Job is too abstract ("be productive") | Make it specific and completable ("send my client a setup link") |
| Job is actually a feature ("use the dashboard") | Ask "why?" until you hit the real job |
| Multiple jobs crammed into one feature | Split the PRD or acknowledge the primary vs secondary job |
| Success metric measures the feature, not the job | "Form submissions" → "Agencies who earned first commission within 7 days" |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.