Skip to main content سوق المهارات اكتشف واستكشف مهارات الذكاء الاصطناعي التي بناها المجتمع.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
عرض تفاصيل Prompt يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ForceInjection/domain-driven-design-skills --skill roadmap-builderيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
تحميل Zip جاري التحميل... Conduct deep academic research for philosophy, neuroscience, cognitive science, and theoretical computer science (computability, complexity, AI theory, logic). Use when user asks to: research academic topics, find scholarly papers, conduct literature reviews, analyze citations, synthesize research findings, explore philosophical arguments, investigate consciousness/cognition, study computability/decidability/Turing machines, or analyze academic debates. Triggers on: 'research papers', 'literature review', 'academic sources', 'scholarly articles', 'philosophy of mind', 'computability theory', 'neuroscience studies', 'find papers on', 'what does the research say'.
المهن ذات الصلة SOC
استنادا إلى تصنيف SOC المهني
name roadmap-builder description Decide what to build next with brutal prioritization using impact/effort analysis. Use when planning sprints, evaluating features, or auditing an overgrown roadmap.
Roadmap Builder
Decide what to build next with brutal prioritization. Cut the noise, focus on what moves the needle.
Usage
/roadmap-builder [command] [feature or context]
Commands:
next - Advise what to build next based on current stageevaluate [feature] - Challenge a specific feature ideaaudit - Review current roadmap and cut the fatprioritize [list of features] - Rank features using the framework
Before Prioritizing
First, understand the current context. If not provided, ask:
What stage is the product in? (Pre-launch / Post-launch / Growth)What's the core value proposition? (One sentence)What features already exist? (Brief list)What user feedback has been collected? (Complaints, requests, praise)
Skip this step if context is already clear from the conversation.
Core Prioritization Framework
Impact vs Effort Matrix
Always evaluate features on two axes:
HIGH IMPACT
│
┌──────────────┼──────────────┐
│ SCHEDULE │ DO FIRST │
│ (Later) │ (Priority) │
│ │ │
HIGH ────┼──────────────┼──────────────┼──── LOW
EFFORT │ │ │ EFFORT
│ AVOID │ FILL-INS │
│ (Cut it) │ (Maybe) │
│ │ │
└──────────────┼──────────────┘
│
LOW IMPACT
High Impact + Low Effort → Do immediatelyHigh Impact + High Effort → Schedule for later, break into smaller piecesLow Impact + Low Effort → Fill-ins when you have spare timeLow Impact + High Effort → Cut. Don't even put it on the roadmap.
Category Prioritization Features fall into four categories. Prioritize in this exact order:
Priority Category Why 1 Retention Keeping existing users is cheaper than acquiring new ones 2 Core Features The fundamental value prop that makes the product useful 3 Monetization Revenue enables everything else, but only after retention 4 Growth Meaningless without retention; last priority
Rule: Never work on a lower-priority category if higher-priority categories have gaps.
Stage-Based Rules
Pre-Launch Stage ONLY build core loop features. Nothing else.
What's the ONE thing users come to do?
Does this feature directly enable that action?
If no → Cut it. Revisit after launch.
Analytics dashboards
User profiles (unless core)
Settings pages
Social features
Email notifications
Multiple user tiers
Admin tools
Post-Launch Stage ONLY build features users explicitly request.
Did multiple users ask for this?
Are users churning because this is missing?
Is this a "nice to have" or a "can't use without"?
Rule: If zero users requested it, don't build it. Your assumptions are wrong until proven otherwise.
Growth Phase ONLY build features that:
Reduce churn (why are users leaving?)
Increase sharing (why would users tell others?)
Remove friction from conversion (why aren't free users paying?)
Everything else is distraction.
Feature Evaluation Questions Ask these about EVERY feature idea:
1. Does this serve the core use case?
What's the core action users take?
Does this feature directly enable or improve that action?
Or is it tangential?
2. Will users actually use this or just say they want it?
Is there evidence of usage (behavior) not just interest (words)?
Are users hacking together solutions without this?
Would users pay for this specific feature?
3. Can we fake it first to validate demand?
Can we use a manual process instead of automation?
Can we use a third-party tool instead of building?
Can we test with a landing page before building?
If you can fake it, fake it first. Build only after validation.
Red Flags (Automatic NO) These patterns signal a feature should be cut:
Red Flag What It Looks Like Feature creep "While we're at it, we could also add..." Cool factor "It would be cool if we had..." Premature optimization "We need this to scale to..." Imaginary users "I think users would want..." (no evidence) Competitor copying "X has this feature, so we need it too" Sunk cost "We already started, might as well finish" Resume-driven "I want to learn/use this technology" Edge cases "But what if someone wants to..."
When you spot these: STOP. Challenge the assumption.
Output Format: Feature Evaluation When evaluating a feature, use this format:
Feature: [Name] Verdict: [BUILD NOW | SCHEDULE | MAYBE LATER | CUT IT]
Quick Assessment Criteria Rating Notes Impact [High/Medium/Low] [why] Effort [High/Medium/Low] [why] Category [Retention/Core/Monetization/Growth] Stage-appropriate? [Yes/No] [current stage] User-requested? [Yes/No/Unknown] [evidence]
Core Use Case Test
Red Flags Found
[List any red flags spotted]
Recommendation [2-3 sentences on what to do and why]
If Building: Simplest Version [What's the MVP of this feature? Cut scope by 50%.]
Output Format: Roadmap Audit When auditing a roadmap, use this format:
Roadmap Audit Current Stage: [Pre-launch / Post-launch / Growth]
Features to CUT (Remove from roadmap) Feature Reason [Name] [Why it should be cut]
Features to DELAY (Move to later) Feature Reason When to Revisit [Name] [Why delay] [Trigger condition]
Features to BUILD NOW Feature Category Impact Effort [Name] [Category] [H/M/L] [H/M/L]
Recommended Next 2 Weeks
[Most important thing]
[Second priority]
[Third priority, if time]
Warning Signs
[Any red flags in current roadmap]
Output Format: What to Build Next When advising on what to build next:
What to Build Next Current Stage: [Stage]
Core Use Case: [One sentence]
Priority Stack (in order)
[Feature Name] - [one sentence why this is #1]
Category: [Category]
Impact: [H/M/L] | Effort: [H/M/L]
Evidence: [why this matters now]
[Feature Name] - [one sentence]
Category: [Category]
Impact: [H/M/L] | Effort: [H/M/L]
Evidence: [why]
[Feature Name] - [one sentence]
Category: [Category]
Impact: [H/M/L] | Effort: [H/M/L]
Evidence: [why]
What NOT to Build (Tempting Traps)
[Feature] - [why it's a trap right now]
Questions to Answer First
[Any unknowns that should be resolved before building]
Prioritization Mantras Repeat these when tempted to add features:
"If users haven't asked for it, they don't need it."
"Retention beats growth. Always."
"The best feature is the one you don't have to build."
"Can we fake it first?"
"Cool is not a business requirement."
"What's the simplest thing that could possibly work?"
When to Use This Skill
Decide what to build in the next sprint
Challenge a feature idea before committing
Audit and prune an overgrown roadmap
Settle debates about priority
Stay focused when shiny objects appear
❌ Don't use this skill for:
Bug fixes (just fix them)
Technical debt (use engineering judgment)
User-reported critical issues (handle immediately)
Final Rule When in doubt, don't build it.
The cost of building the wrong thing is always higher than the cost of waiting. Ship less. Learn faster. Build only what's proven to matter.
Related Skills
New idea? → Use /idea-validator first to validate it's worth buildingReady to plan? → Use /launch-planner prd [idea] to create a lean PRDScope creep? → Use /launch-planner scope [feature] to evaluate if it belongs in MVP 