Skill: kokidebuff/prioritize-dev-tasks (version 1.0.0)

--- name: prioritize-dev-tasks description: Prioritize software project backlogs, bugs, technical debt, sprint tasks, release checks, and requirement pools using business impact, dependency blocking, delivery risk, security and data risk, and implementation cost. Use when a user asks to classify unfinished development work, determine execution order, identify release blockers, schedule deferred work, or remove low-value tasks. --- # Prioritize Development Tasks ## Goal Help the user decide which unfinished software project items to address immediately, schedule deliberately, handle quickly, defer, merge, or remove. Use an Eisenhower-style four-quadrant view to present classification. Determine the actual execution order primarily by: 1. Security and data risk 2. Production incidents or core-flow availability 3. Release, acceptance, and multi-person dependency blockers 4. The current version goal 5. Cost-to-value ratio 6. General user-experience polish and long-term improvement Answer in the language used by the user. Keep project terminology, task names, and code identifiers as provided unless translating them is necessary for clarity. ## Input Handling Accept any of the following: - A development to-do list or short task list - A bug list - Release-readiness checks - Technical debt - A sprint backlog - A requirement pool or scheduling problem When the user provides incomplete information: - Give a preliminary judgment using the available evidence instead of requiring every field first. - Explicitly mark conclusions that are based on incomplete information. - Do not invent deadlines, user impact, cost, or dependency relationships. - For potential security, data, production, or release-blocking concerns, rank conservatively higher and identify only the missing facts that could change the decision. ## Mandatory Escalation Rules Treat the following as highest-priority candidates unless the user clearly states that the risk is isolated, effectively mitigated, or outside the current version scope: - Data loss, data corruption, money errors, or incorrect critical business data - Authorization bypass, privilege escalation, sensitive-data exposure, or a known security vulnerability - Production crashes, unavailable core flows, or persistently failing critical APIs - A completely blocked build, deployment, release, or acceptance process - Work blocking multiple developers, integration, or critical testing - Changes or failures that cannot be rolled back, or are costly to roll back Do not lower the priority of these items merely because they take longer to resolve. ## Assessment Dimensions Assess each task against these dimensions: | Dimension | Question to answer | |---|---| | Business impact | Does it affect a core flow, core users, delivery goals, or a primary revenue path? | | Urgency | Is there a concrete deadline, current development/testing impact, an imminent release, or an expanding problem? | | Blocking | Does it block integration, testing, acceptance, deployment, release, or another contributor? | | Risk | Does it involve security, data, production stability, severe performance, or a difficult rollback? | | Cost and value | Can a small effort remove major blockage, or is this high effort with limited present benefit? | | Dependency order | Must it be completed before another task can proceed? | ## Quadrant Classification | Quadrant | Meaning | Typical action | |---|---|---| | Important and urgent | Affects a core goal and needs prompt action | Handle immediately; reduce to a minimum deliverable fix if needed | | Important but not urgent | Affects stability or long-term efficiency without blocking the current objective | Schedule in the current week or next sprint | | Urgent but not important | Has time pressure but limited impact or a workable alternative | Time-box, delegate, or simplify | | Neither important nor urgent | Has weak connection to the current objective or limited benefit | Defer, merge, return to the pool, or remove | Use quadrants for communication, not as the sole ranking algorithm. Risk, blocking relationships, and dependency order determine the execution order. ## Analysis Process 1. Identify the project phase: early development, integration, testing, pre-release, production maintenance, or refactoring. 2. Extract the current version objective, such as MVP delivery, a demo, scheduled release, or production recovery. 3. Check for mandatory escalation items. 4. Assess each task by impact, urgency, blocking, risk, cost-to-value ratio, and dependencies. 5. Classify tasks into quadrants and state the key evidence. 6. Recommend execution order: first address severe risk and blockers, then secure core flows, schedule important planned work, and handle low-value items last. 7. Explicitly identify tasks to defer, merge, or remove. 8. Ask only for missing information that could materially change the ranking. ## Output Rules - Do not sort only by deadline. - Do not label every task as high priority. - List no more than three top-priority items; do not fill the list artificially. - Always identify blockers. If none are evident, state that no clear blocker is identifiable from the current information. - Always identify defer, merge, or remove candidates; if evidence is insufficient, state why. - Do not rank cosmetic UI polish, speculative enhancements, or work without a clear requirement source as top priority unless delivery depends on it. - When dependencies are clear, place execution order ahead of quadrant labels. ## Output Formats ### Compact Output Use this format when there are fewer than five tasks and there is no apparent security, data, production-incident, or release-blocking risk: ```markdown # Development Task Priority Analysis ## Overall Judgment - Current phase: - Current objective: - Basis: Preliminary judgment based on available information / sufficiently detailed information ## Ranked Tasks | Order | Task | Quadrant | Key Reason | Recommended Action | |---|---|---|---|---| ## Blockers And Deferrals - Blockers: - Defer / merge / remove candidates: ## Information To Confirm - List only questions that could change the ranking. ``` ### Full Output Use this format when there are at least five tasks, or any security, data, production, release, acceptance, or multi-person blocking concern is present: ```markdown # Development Task Priority Analysis ## 1. Overall Judgment - Current project phase: - Current version objective: - High-risk note: ## 2. Four-Quadrant Classification | Quadrant | Task | Reasoning | Recommended Action | |---|---|---|---| ## 3. Highest-Priority Items List no more than three items. For each item state: - Why it is prioritized - Recommended treatment - The risk or blockage removed when completed ## 4. Blocking Relationships | Blocking Task | Blocked Work | Resolution Approach | |---|---|---| ## 5. Defer, Merge, Or Remove Candidates | Task | Recommendation | Reason | |---|---|---| ## 6. Recommended Execution Order 1. ... 2. ... 3. ... ## 7. Information To Confirm Ask only questions that could materially change the priority ranking. ```


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)