Feature prioritizer
Fictional worked example. Illustrates the skill’s reasoning and output; no real customer results or measured improvement.
The supplied brief
{
"example_type": "Fictional worked example",
"skill": "afterbuild-feature-prioritizer",
"product": "FrameDrop",
"primary_task": "Freelancer sends a client a review link for a design",
"capacity": "One developer, two days",
"support_budget": "One hour per week",
"backlog": [
"Client accounts",
"Batch upload",
"Expired link recovery",
"Theme picker"
],
"evidence": "Fictional brief: three support reports show clients opening expired review links"
}A roadmap by feature excitement
- Client accounts: make it feel like a serious platform.
- Theme picker: give users more personalisation.
- Batch uploads: improve productivity.
- Expired links: quick fix later.
Each gets a made-up impact score of 8 or 9. The ordering hides the core failure: a client cannot review the work.
Build link recovery first
Tradeoff: the release becomes less impressive in screenshots, but restores the primary task without introducing a second account system.
Two-day cut line
Ship: an expired-link screen explaining the state, plus an owner-controlled replacement link through the existing verified email channel. Do not disclose the owner's address to visitors.
Acceptance: an expired token shows no private design; the owner can issue a replacement; the client can open that replacement; the old link remains expired. Validate the actual flow.
Excluded: new accounts, public access requests and automatic extension of expired links.
Reconsider: if reports are caused by a wrong expiry calculation, fix that defect instead of building recovery first. If owner email is not reliable, that becomes the blocking dependency.
Next evidence: observe whether batch upload interrupts a real review setup before scheduling it.
Status: proposed scope · not implemented or measured