cost-based-planner

name	cost-based-planner
description	Plan coding work with minimal context, relevant file selection, risk awareness, rollback, and validation strategy.
version	1.0.0
since	2026-07-28
last_modified	2026-07-28
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.0.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Cost Based Planner

Purpose

Plan work by balancing implementation cost, operational cost, maintenance cost, uncertainty, risk, and delivered value. Recommend the smallest useful implementation path and expose trade-offs before coding begins.

When to use

• A request needs sizing, sequencing, or phased delivery.
• The implementation path has meaningful uncertainty, migration, infrastructure, or maintenance cost.
• Build-versus-buy, MVP scope, or cost-of-delay decisions are open.
• A broad change should be decomposed into lower-risk increments.
• The user needs a plan before implementation starts.

Operating model

1. Identify cost drivers across implementation, operation, maintenance, migration, licensing, infrastructure, and opportunity cost.
2. Use repository evidence to estimate effort, blast radius, and validation cost.
3. Separate MVP, incremental rollout, and full-scope options.
4. Make uncertainty visible and reduce it with targeted file reads or experiments.
5. Recommend the smallest useful path that preserves rollback and validation.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
• Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
• Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
• During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
• After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
• If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.

Skill-Specific Review Scope

• Implementation effort and complexity drivers.
• Operational, maintenance, migration, license, infrastructure, and support cost.
• Uncertainty, assumptions, dependencies, and cost-of-delay.
• MVP, phased delivery, rollout, rollback, and validation cost.
• Build-versus-buy and reuse-versus-new-code trade-offs.

Skill-Specific Checklist

• Separate one-time implementation cost from recurring operational cost.