Technical Debt RegisterCAUTION

1255 professional Agent Skills for Claude, ChatGPT, Gemini, Cursor & Codex — PRDs, postmortems, leases, medical bills, layoffs, go-bags, new countries. Plain markdown, MIT, in Anthropic's plugin directory. Plus a typed decision layer: which skill, is it safe, ship or slip. Free in-browser or npx pm-

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: technical-debt-register
description: "Document and prioritize a technical debt backlog with business impact, effort estimates, and resolution strategy. Use when asked to audit technical debt, create a debt register, prioritize tech debt for a quarter, document architectural shortcuts, or build a debt reduction roadmap. Produces a structured technical debt register covering debt inventory by category, business impact per item, effort and priority scores, top-item resolution plans, and a quarterly debt reduction roadmap."
---

# Technical Debt Register Skill

Produce a complete technical debt register for a team or service. A debt register is not a complaint list — it is a prioritized, business-impact-aware inventory that lets an engineering team make deliberate choices about which debt to pay down, in what order, and with what expected return.

Good debt management is not eliminating all debt. It is ensuring debt is visible, owned, and resolved when the interest cost exceeds the cost of fixing it.

## Required Inputs

Ask for these if not already provided:
- **Team or service name** — what team and/or service this register covers
- **Known debt items** — list of known technical debt, or ask Claude to elicit them by asking about: legacy code, missing tests, outdated dependencies, architectural shortcuts, manual processes, observability gaps, security backlogs
- **Tech stack** — language, frameworks, infrastructure (helps Claude categorise and score items correctly)
- **Team size and velocity** — number of engineers and approximate story points or days per sprint (needed for effort estimates)
- **Current quarter / planning period** — so the roadmap targets the right timeframe

## Output Format

---

# Technical Debt Register: [Team / Service Name]

**Team:** [Name] | **Service(s):** [Name(s)]
**Author:** [Name] | **Last updated:** [Date]
**Planning period:** [Q[X] [Year]] | **Review cadence:** [Monthly / Quarterly]

---

## Overview

[2–3 sentences describing the team's current debt situation, the main categories of debt, and the business context — e.g. are they in a growth phase where velocity matters, or approaching a compliance deadline where security debt is critical?]

**Total items in register:** [X]
**Unresolved items:** [X]
**Critical/High priority items:** [X]
**Estimated total resolution effort:** [X story points / X engineer-weeks]

---

## Debt Category Definitions

| Category | Description | Examples |
|---|---|---|
| **Code quality** | Code that works but is hard to change safely | Duplicated logic, deeply nested conditionals, inconsistent error handling, missing abstraction |
| **Architecture** | Structural decisions that limit scalability or increase coupling | Monolith that should be decomposed, sync calls that should be async, missing domain boundaries |
| **Testing** | Gaps in test coverage that increase regression risk | Missing unit tests, no integration tests, flaky test suite, no test data management |
| **Security** | Known vulnerabilities or missing security controls | Outdated dependencies with CVEs, missing rate limiting, hard-coded secrets, insufficient auth |
| **Dependencies** | Outdated or risky external dependencies | End-of-life libraries, major version lag, abandoned packages |
| **Infrastructure** | Infrastructure that limits reliability or developer productivity | Manual deployment steps, no IaC, single-AZ, missing autoscaling |
| **Observability** | Gaps in visibility that slow incident response | Missing metrics, no distributed tracing, poor log structure, no alerting on key SLIs |
| **Process** | Manual or error-prone operational processes | Manual DB migrations, no runbooks, tribal knowledge not documented |

---

## Debt Register

### Scoring Method

**Business impact (1–5):**
- 5 — Blocking growth, causing production incidents, or creating compliance risk
- 4 — Significantly slowing delivery or increasing incident likelihood
- 3 — Noticeable slowdown; manageable but accumulating
- 2 — Minor friction; low immediate risk
- 1 — Cosmetic or aspirational; no current business impact

**Effort to resolve (1–5, lower = easier):**
- 1 — <0.5 day; single engineer
- 2 — 0.5–2 days; single engineer
- 3 — 3–5 days; single engineer or small pair
- 4 — 1–2 weeks; team collaboration required
- 5 — >2 weeks; significant planning and coordination

**Priority score = Business impact × (6 − Effort)** *(rewards high-impact, low-effort items)*

---

| ID | Item | Category | Business impact (1–5) | Effort (1–5) | Priority score | Status | Owner |
|---|---|---|---|---|---|---|---|
| TD-001 | [e.g. No integration tests for payment flow] | Testing | 5 | 3 | 15 | Open | [Name] |
| TD-002 | [e.g. Authentication library 3 major versions behind] | Security | 5 | 2 | 20 | Open | [Name] |
| TD-003 | [e.g. Database queries not using connection pooling] | Architecture | 4 | 2 | 16 | Open | [Name] |
| TD-004 | [e.g. Manual deployment process for [service]] | Infrastructure | 4 | 3 | 12 | In progress | [Name] |
| TD-005 | [e.g. 200-line God function in order processing] | Code quality | 3 | 3 | 9 | Open | [Name] |
| TD-006 | [e.g. No structured logging — plain text only] | Observability | 3 | 2 | 12 | Open | [Name] |
| TD-007 | [e.g. ORM version has known N+1 query issue] | Dependencies | 3 | 3 | 9 | Open | [Name] |
| TD-008 | [e.g. No runbook for [critical operation]] | Process | 3 | 1 | 15 | Open | [Name] |
| TD-009 | [e.g. Test coverage at 34% — no meaningful safety net] | Testing | 4 | 4 | 8 | Open | [Name] |
| TD-010 | [e.g. Hard-coded config values in application code] | Code quality | 2 | 1 | 10 | Open | [Name] |
| TD-011 | [e.g. Service deployed single-AZ with no failover] | Infrastructure | 5 | 4 | 10 | Open | [Name] |
| TD-012 | [e.g. No alerting on P95 latency for [endpoint]] | Observability | 4 | 1 | 20 | Open | [Name] |

---

## Category Breakdown

```
Category distribution (by item count):
─────────────────────────────────────────────
Code quality     ████████░

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (5)

templates/pm-discovery-agent/skills/assumption-mapper/SKILL.md

templates/pm-discovery-agent/skills/discovery-interview-guide/SKILL.md

templates/pm-discovery-agent/skills/job-story-mapper/SKILL.md

templates/pm-discovery-agent/skills/user-interview-synthesis/SKILL.md

templates/pm-launch-agent/skills/content-calendar/SKILL.md

Gates applied: no_behavioural_pass.