structural-planning

Converts fuzzy requirements and migrations into executable engineering plans with defined acceptance criteria.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-planning-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: structural-planning
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/structural-planning
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-planning-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Fuzzy requirements, vague tickets, and cross-team migrations often turn into plans that only make sense to their author, leaving implementers to reconstruct context, rediscover unknowns, and improvise rollback paths mid-incident. This Skill structures planning so the plan itself carries the context a cold reader needs. ## Core Features & Use Cases - Done Contract Template: Produces a structured plan with acceptance criteria, non-goals, assumptions, owners, sequencing, rollback, and failure modes. - Planning Checks: Enforces rules like bounding unknowns before estimating, anchoring facts to a single source of truth, and sequencing for reversibility (expand, backfill, dual-write, switch, contract). - Red Flag Detection: Flags one-shot cutovers, unverifiable acceptance criteria, unrehearsed fallbacks, and artifacts with no owner or expiry. - Use Case: When scoping a database migration with cross-team dependencies, use this Skill to produce a plan that names the spike questions, defines reversible steps, and assigns every flag and scaffold an owner and expiry date. ## Quick Start Use the structural-planning skill to turn this migration ticket into an executable plan with acceptance criteria, sequencing, and rollback steps.

Frequently Asked Questions about structural-planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an engineering plan for a vague ticket?

Start by bounding unknowns: spike only questions whose answer changes the date, approach, or blast radius. Then write acceptance criteria a stranger could verify, cap scope with explicit non-goals, and sequence work so reversible steps come before irreversible ones.

How to plan a database migration with rollback safely?

Sequence the migration as expand, backfill, dual-write, switch, then contract so each step is reversible. Name failure modes and fallback tiers in the plan itself, and avoid one-shot cutovers that have no losing move.

What should acceptance criteria include in a technical plan?

Acceptance criteria should be observable and checkable by someone who did not write the plan. Avoid terms like "works" or "handled" without a concrete verification step, and define non-goals and split points to cap scope.

When should I spike before estimating engineering work?

Spike only when the answer would change the estimate, the chosen approach, or the blast radius of the work. Time-box the spike and anchor its findings to a source of truth such as a ticket, doc, API contract, or named owner.

What are common red flags in software project plans?

Red flags include "we'll figure it out" on cross-team contracts, acceptance criteria without observable checks, one-shot cutovers with no rollback, fallbacks that are named but never built, and artifacts like flags or migrations with no owner or expiry.