---

name: franklin-prioritization description: Implement Franklin Planner Prioritization A∞ B∞ C∞ D∞ system in applications requiring prioritization. Use when starting a new application that needs priorities, migrating from high/medium/low scales, standardizing priorities across multiple applications, or questions like implement priorities, convert priority system, standardize priorities, building bug trackers, task lists, backlogs, or any prioritized queue systems.

Franklin Planner Prioritization (FPP)

Overview

Franklin Planner Prioritization using the A∞/B∞/C∞/D∞ system provides granular prioritization within categories. High/Medium/Low scales don't differentiate within categories (is medium-low more important than medium-high?). Franklin solves this with numeric precision within each category.

Core principle: Priority = Category (A/B/C/D) + Rank (1-1000) = Precise ordering.

When to Use This Skill

Setup scenarios:

• Building a new application with priority features (bug tracker, task list, backlog)
• Migrating from high/medium/low or P0/P1/P2 priority scales
• Standardizing prioritization across multiple applications

Migration scenarios:

• "My priority scale doesn't differentiate well"
• "I need better granularity within categories"
• "Users complain about priority ambiguity"

Standardization scenarios:

• Multiple apps need consistent priority system
• Company-wide standard for prioritization
• Integrating with Franklin Planner methodology

The Franklin System

Four Priority Categories

| Category | Meaning | Examples | Urgency Level | |----------|---------|----------|---------------| | A∞ | Must Do Now | Critical bugs, production outages, deadlines | Immediate (today) | | B∞ | Should Do Soon | Important features, improvements, backlog | Near-term (this week/month) | | C∞ | Could Do Eventually | Nice-to-haves, enhancements, optimizations | Long-term (quarter/planned) | | D∞ | Delegate or Defer | Low value, someone else can do, maybe never | Whenever possible |

Numbering System

Each category has 1-1000 for fine-grained ordering:

• A1-A1000: A1 = most critical Must Do, A1000 = least critical Must Do
• B1-B1000: B1 = most important Should Do, B1000 = least important Should Do
• C1-C1000: C1 = most worthwhile Could Do, C1000 = least worthwhile Could Do
• D1-D1000: D1 = highest priority Delegate, D1000 = lowest priority Delegate

Common practices:

• Reserve A1-A50 for crises, production issues
• Use B1-B100 for active development backlog
• Use C1-C50 for quarterly improvements
• Use D1-D50 for items that might never get done

Priority Ordering

Automatic sorting: All A's > All B's > All C's > All D's, then by number:

A1  >  A2  >  A3  >  ...  >  A1000
B1  >  B2  >  B3  >  ...  >  B1000
C1  >  C2  >  C3  >  ...  >  C1000
D1  >  D2  >  D3  >  ...  >  D1000

Implementation strategy: Store as separate fields or parse, sort by:

ORDER BY
  CASE franklin_category
    WHEN 'A' THEN 1
    WHEN 'B' THEN 2
    WHEN 'C' THEN 3
    WHEN 'D' THEN 4
  END,
  franklin_number

Implementation Workflow

Step 1: Choose Storage Schema

Option A: Single Composite Column

ALTER TABLE bugs ADD COLUMN franklin_priority TEXT NOT NULL DEFAULT 'B1';
CREATE INDEX idx_bugs_priority ON bugs(franklin_priority);

Option B: Separate Category and Number Columns (Recommended for sorting)

ALTER TABLE bugs ADD COLUMN franklin_category CHAR(1) NOT NULL DEFAULT 'B';
ALTER TABLE bugs ADD COLUMN franklin_number INTEGER NOT NULL DEFAULT 1;
CREATE INDEX idx_bugs_priority ON bugs(franklin_category, franklin_number);

Option C: Computed View (Option A + virtual column for sorting)

ALTER TABLE bugs ADD COLUMN franklin_priority TEXT NOT NULL DEFAULT 'B1';
ALTER TABLE bugs ADD COLUMN franklin_sort_order
  GENERATED ALWAYS AS (
    CASE substr(franklin_priority, 1, 1)
      WHEN 'A' THEN 1
      WHEN 'B' THEN 2
      WHEN 'C' THEN 3
      WHEN 'D' THEN 4
    END * 10000 + CAST(substr(franklin_priority, 2) AS INTEGER)
  ) STORED;
CREATE INDEX idx_bugs_sort ON bugs(franklin_sort_order);

Recommendation: Option B for clarity, Option C for automatic sorting.

Step 2: Add Validation

SQLite/PostgreSQL CHECK constraints:

ALTER TABLE bugs ADD CONSTRAINT ck_franklin_priority
  CHECK (franklin_priority REGEXP '^[ABCD][1-9][0-9]*$');

-- For Option B:
ALTER TABLE bugs ADD CONSTRAINT ck_franklin_category
  CHECK (franklin_category IN ('A', 'B', 'C', 'D'));
ALTER TABLE bugs ADD CONSTRAINT ck_franklin_number
  CHECK (franklin_number BETWEEN 1 AND 1000);

MySQL pattern matching:

ALTER TABLE bugs ADD CONSTRAINT ck_franklin_priority
  CHECK (franklin_priority RLIKE '^[ABCD][1-9][0-9]*$');

Triggers for automatic derivation (Option B):

CREATE TRIGGER derive_franklin_parts
AFTER UPDATE ON bugs
FOR EACH ROW
WHEN NEW.franklin_priority IS DISTINCT FROM OLD.franklin_priority
BEGIN
  UPDATE bugs
  SET franklin_category = substr(NEW.franklin_priority, 1, 1),
      franklin_number = CAST(substr(NEW.franklin_priority, 2) AS INTEGER)
  WHERE id = NEW.id;
END;

Step 3: Migrate Existing Data

From high/medium/low:

UPDATE bugs
SET franklin_priority = CASE
  WHEN priority IN ('high', 'critical', 'urgent', 'p0') THEN 'A1'
  WHEN priority IN ('medium', 'normal', 'standard', 'p1') THEN 'B1'
  WHEN priority IN ('low', 'minor', 'p2') THEN 'C1'
  ELSE 'B1'
END;

From P0/P1/P2/P3:

UPDATE bugs
SET franklin_priority = CASE
  WHEN priority LIKE 'P0' THEN 'A1'
  WHEN priority LIKE 'P1' THEN 'B1'
  WHEN priority LIKE 'P2' THEN 'C1'
  WHEN priority LIKE 'P3' THEN 'D1'
  ELSE 'B1'
END;

From numeric scales (1-10):

UPDATE bugs
SET franklin_priority = CASE
  WHEN priority_number <= 3 THEN 'A' || (11 - priority_number)  -- 1→A10, 3→A8
  WHEN priority_number BETWEEN 4 AND 7 THEN 'B' || (8 - priority_number)  -- 4→B4, 7→B1
  WHEN priority_number >= 8 THEN 'C' || (11 - priority_number)  -- 8→C3, 10→C1
END;

Step 4: Update Application Code

Service layer (example: BugQueueService.js):

// Before
DEFAULT_PRIORITY = 'medium';

// After
DEFAULT_PRIORITY = 'B1';

validatePriority(priority) {
  const franklinPattern = /^[ABCD][1-9][0-9]*$/;
  if (!franklinPattern.test(priority)) {
    throw new Error(`Invalid Franklin priority: ${priority}`);
  }
}

// Add bug with Franklin priority
addBug(title, description, priority = 'B1') {
  this.validatePriority(priority);
  // ... rest of implementation
}

API validation:

// routes.js
app.post('/api/bugs', (req, res) => {
  const { priority } = req.body;
  if (!/^[ABCD][1-9][0-9]*$/.test(priority)) {
    return res.status(400).json({
      error: 'Invalid Franklin priority. Format: [ABCD][1-9][0-9]* (e.g., A1, B5, C10)'
    });
  }
  // ... create bug
});

Sorting queries:

// With Option B schema
SELECT * FROM bugs
ORDER BY franklin_category, franklin_number;

// Or computed column (Option C)
SELECT * FROM bugs
ORDER BY franklin_sort_order;

Step 5: Update Documentation

PRD/Specs:

• Explain Franklin prioritization in product requirements
• Provide examples of when to use each category
• Document priority escalation guidelines

API docs:

POST /api/bugs
priority:
  type: string
  pattern: '^[ABCD][1-9][0-9]*$'
  description: Franklin priority (A∞/B∞/C∞/D∞). Examples: A1 (urgent), B5 (mid-priority), C3 (nice-to-have)
  default: "B1"

User-facing docs:

• Explain what priorities mean to end users
• Provide decision tree for choosing priorities
• Show examples of appropriate priority assignments

Common Issues and Solutions

❌ Invalid priority in database

Problem: Existing data doesn't match Franklin pattern

Solution:

-- Find invalid priorities
SELECT DISTINCT priority FROM bugs
WHERE priority NOT REGEXP '^[ABCD][1-9][0-9]*$';

-- Update to valid defaults
UPDATE bugs
SET franklin_priority = 'B1'
WHERE franklin_priority IS NULL
   OR franklin_priority NOT REGEXP '^[ABCD][1-9][0-9]*$';

❌ CHECK constraint fails on insert

Problem: Application sending invalid priorities

Solution: Add client-side validation AND server-side validation:

// Client-side (frontend)
function validatePriority(priority) {
  return /^[ABCD][1-9][0-9]*$/.test(priority);
}

// Server-side (API)
if (!validatePriority(req.body.priority)) {
  return res.status(400).json({ error: 'Invalid Franklin priority' });
}

❌ Sorting not working as expected

Problem: "A10" sorts before "A2" in string comparison

Solution: Use separate columns or computed sort order (see Option B or C above).

❌ Users confused by "B5" vs "C3"

Problem: Users don't understand numeric differences within categories

Solution: Add priority selector UI with labels:

A∞ Must Do Now [Critical]
B∞ Should Do Soon [Important]
C∞ Could Do Eventually [Nice-to-have]
D∞ Delegate/Defer [Low priority]

And explain that within categories, lower numbers = higher priority.

Migration Checklist

• [ ] Choose storage schema (Option A/B/C)
• [ ] Add franklin_priority column to database
• [ ] Add CHECK constraints for validation
• [ ] Migrate existing data (high/medium/low → B1)
• [ ] Update application code for Franklin validation
• [ ] Update API routes with validation
• [ ] Update database queries for proper sorting
• [ ] Update documentation (PRD, API docs, user docs)
• [ ] Test all priority operations (create, update, list, sort)
• [ ] Verify CHECK constraints reject invalid priorities
• [ ] Commit and push all changes

---

Remember: Franklin prioritization provides clarity through categories and precision through numbers. The key is consistent validation and clear documentation for users.