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:

DimensionQuestion to answerBusiness impactDoes it affect a core flow, core users, delivery goals, or a primary revenue path?UrgencyIs there a concrete deadline, current development/testing impact, an imminent release, or an expanding problem?BlockingDoes it block integration, testing, acceptance, deployment, release, or another contributor?RiskDoes it involve security, data, production stability, severe performance, or a difficult rollback?Cost and valueCan a small effort remove major blockage, or is this high effort with limited present benefit?Dependency orderMust it be completed before another task can proceed?

Quadrant Classification#

QuadrantMeaningTypical actionImportant and urgentAffects a core goal and needs prompt actionHandle immediately; reduce to a minimum deliverable fix if neededImportant but not urgentAffects stability or long-term efficiency without blocking the current objectiveSchedule in the current week or next sprintUrgent but not importantHas time pressure but limited impact or a workable alternativeTime-box, delegate, or simplifyNeither important nor urgentHas weak connection to the current objective or limited benefitDefer, 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.