Prioritize Dev Tasks

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:

# 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:

# 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.