Skip to content This library is free, offered as dana. If it helps your work, donate here →
penguin tree ai
← back to libraryDonate here

This is one of 3,622 free prompts in the penguin tree ai library. Sign up once and the whole library opens, with new prompts by email.

open the library →

Engineering initiative breakdown generator

Decomposes a complex engineering initiative into a phased milestone plan with owners, dependencies, success criteria, effort estimates, risk register, and a rollout/validation strategy. Use when breaking down a large…

download .md

Purpose

Turn a vague, oversized engineering initiative into a phased execution plan — with sequenced milestones, named owners, explicit dependencies, effort estimates, and measurable success criteria — so a team can start work with clear scope and a way to know when each phase is actually done. Eliminates the "big scary project with no starting point" problem.

When to Use

Invoke this skill when the user asks to:

  • Break down a large engineering project, migration, or platform build into phases
  • Turn a technical initiative into milestones with owners and success criteria
  • Plan a cross-team engineering effort or multi-quarter roadmap item
  • Estimate scope and sequencing for a complex technical undertaking
  • Create an execution plan for a re-architecture, infrastructure change, or new system
  • Structure an ambiguous initiative into something a team can actually start on

Inputs Required

Before starting, collect:

  • Initiative description: 2–4 sentences on what's being built or changed and why
  • Business/technical driver: The outcome this initiative must produce (revenue, reliability, unblock, compliance, scale)
  • Team composition: Roles and headcount available (e.g., 3 backend, 1 frontend, 1 SRE) — names if known
  • Timeline constraint: Target completion date or hard deadline, if any
  • Known dependencies: External teams, systems, vendors, or approvals required
  • Technical constraints: Existing stack, legacy systems, migration requirements, must-not-break systems
  • Definition of done: What "success" looks like at the initiative level

If team composition or timeline is missing, assume a 4–6 engineer team over one quarter and flag the assumption.

Instructions

Step 1: Clarify Scope and Non-Goals

Before decomposing, establish boundaries:

  • In scope: 3–5 bullets stating exactly what this initiative will deliver
  • Explicitly out of scope (non-goals): 3–5 bullets stating what this initiative will NOT do — this prevents scope creep and is the most-skipped step
  • Success at the initiative level: 2–3 measurable outcomes (e.g., "p99 latency under 200ms," "100% of traffic migrated," "zero downtime cutover")

Step 2: Decompose into Phases

Break the initiative into 3–6 sequential phases. Standard engineering initiative arc:

  • Phase 0 — Foundation/Spike: De-risking work, proof of concept, tooling, design doc, environment setup
  • Phase 1 — Core Build: The primary technical work that delivers the central capability
  • Phase 2 — Integration/Migration: Connecting to existing systems, data migration, backward compatibility
  • Phase 3 — Rollout/Validation: Progressive rollout, monitoring, load testing, cutover
  • Phase 4 — Hardening/Cleanup: Remove legacy paths, documentation, runbooks, on-call handoff

Adjust phase count to the initiative. Each phase must produce something demonstrable or verifiable — no phase should end in an unmeasurable state.

Step 3: Define Milestones Within Each Phase

For each phase, define 2–4 milestones. Each milestone includes:

  • Milestone name: Concrete deliverable (e.g., "Read path served by new service," not "work on backend")
  • Owner: Assigned role or named person (single accountable owner per milestone — no shared accountability)
  • Effort estimate: T-shirt size (S/M/L/XL) with rough engineer-week range
  • Dependencies: Which milestones or external inputs must land first
  • Success criteria: A verifiable exit condition — a test that passes, a metric that's hit, a demo that works, a review that's signed off

Step 4: Map Dependencies and Critical Path

  • List cross-milestone dependencies and identify the critical path — the longest chain of dependent work that determines minimum timeline
  • Flag any milestones blocked on external teams or approvals — these are the highest-risk items and need early kickoff
  • Identify parallelizable work — milestones that can run concurrently given the team size

Step 5: Build the Risk Register

Identify 4–6 top risks. For each:

  • Risk: What could go wrong (technical, dependency, resourcing, unknown-unknown)
  • Likelihood / Impact: Low / Medium / High for each
  • Mitigation: A concrete action to reduce or de-risk it
  • Prioritize risks that threaten the critical path or the initiative-level success criteria

Step 6: Sequencing Recommendation

Provide an opinionated ordering:

  • What to start in Week 1 (usually the highest-uncertainty spike + any external dependency kickoff)
  • What to explicitly defer
  • The single most important thing to get right early

Output Format

  • Structure: Scope/non-goals block → phase-by-phase breakdown with milestone tables → dependency & critical path section → risk register table → sequencing recommendation
  • Length: 900–1,400 words
  • Format: Structured document with milestone tables (Milestone | Owner | Effort | Dependencies | Success Criteria) and a risk register table
  • Sections: Scope & Non-Goals → Phases & Milestones → Dependencies & Critical Path → Risk Register → Sequencing Recommendation
  • Tone: Engineering manager — pragmatic, direct, ownership-focused; assumes the reader will execute this plan

Quality Checklist

Before delivering output, verify:

  • [ ] Every milestone has exactly one accountable owner — no shared or blank owners
  • [ ] Every milestone has a verifiable success criterion (a test, metric, demo, or sign-off) — not "done when it works"
  • [ ] Non-goals section is present with at least 3 explicit exclusions
  • [ ] The critical path is named and external-team dependencies are flagged as high-risk
  • [ ] Risk register has 4–6 risks, each with likelihood, impact, and a concrete mitigation
  • [ ] Effort estimates are present on every milestone (T-shirt size + engineer-week range)

Notes

  • The single highest-value output is usually the non-goals list and the success criteria — teams overrun because scope was never bounded and "done" was never defined
  • Front-load uncertainty: put spikes and external-dependency kickoffs in Phase 0, not Phase 3
  • If the initiative can't be described in one sentence, it's probably two initiatives — flag this and suggest splitting
  • Prefer single accountable owners over "the team owns it"; shared accountability reliably becomes no accountability

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

  • ~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
  • <your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

  1. Drag this file into a new chat, or copy and paste its contents
  2. Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills