Backend Feature Build Plan
Builds one backend feature through gates: confirmed requirements, one-screen design, small tested slices, and a deploy/rollback handoff.
Before & after
Same prompt, same agent — the only difference is the skill.
That's a complex domain. Let me ask some clarifying questions first. Are you handling recurring billing monthly or supporting custom intervals? Do you need to track refunds and disputes separately? What's your payment processor—Stripe, another provider? How many subscriptions do you expect per day? I'd normally suggest normalizing user, subscription, and payment tables, but your specific requirements might call for a different approach. What's your scale and retention pattern like?
DATABASE SCHEMA: SUBSCRIPTION BILLING CORE TABLES Users → id, email, created_at, stripe_customer_id Subscriptions → id, user_id, plan_id, status (active/canceled/suspended), started_at, ends_at, current_period_start, current_period_end Invoices → id, subscription_id, amount, currency, due_date, paid_at, status (draft/sent/paid/void) Payments → id, invoice_id, provider_id (stripe charge ID), amount, method, succeeded_at, failed_at Refunds → id, payment_id, reason, amount, initiated_at, completed_at RELATIONSHIPS & INDEXES subscriptions.user_id → users (cascade delete) subscriptions.status + current_period_end → index for renewal jobs invoices.subscription_id, paid_at → index for reporting payments.provider_id → unique constraint (prevent duplicate webhook processing) EDGE CASES ADDRESSED Proration → Calculate daily rate if plan changes mid-cycle Dispute flow → Payment marked disputed, subscription held (not canceled) Cancellation → Soft-delete pattern, keeps invoicing history Retry logic → Failed payment marked, not auto-retried (webhook handles) MIGRATION STRATEGY Step 1: Create new tables (no downtime) Step 2: Backfill from old system (parallel read) Step 3: Dual-write new tables for 1 week Step 4: Read from new tables, monitor for anomalies Step 5: Archive old table after 30-day validation
About this skill
Stop jumping straight into code. This skill takes one ticket through requirements, design, sliced implementation, and handoff, so the feature ships safely and matches what was asked.
What it does
- Reads the ticket and code, then confirms requirements in 3-6 bullets
- Writes a one-screen design: API contract, schema and migration plan, failure modes, idempotency, authorization
- Implements in 3-6 independently mergeable slices, each with its tests and the command to run them
- Verifies retries, unauthorized access, and dependency failures in tests
- Hands off with deploy order and rollback steps
What you get
A feature record: confirmed requirements, the design, a slice table with test status, verification results, deploy and rollback plan, and follow-ups.
Best for
Engineers and teams using an AI agent to implement backend tickets who want design discipline and working tests, not a large unreviewed diff.
SKILL.md preview
---
name: backend-feature-build-plan
description: Take one backend feature from requirements to merged code through gated stages - clarify requirements, write a short technical design (API contract, schema changes, failure modes), implement in small verified slices, and hand off with tests and a rollout plan. Use when the user says "build this endpoint/feature", "implement X in the backend", or hands over a ticket and wants it done properly rather than coded straight away. Also triggers on "add an endpoint for X", "how should I implement this?", or "just write the handler for this ticket".
---
# Backend Feature Build Plan
… (sign up to view the full skill)More development skills
View all Development skills →Production Go: Concurrency, Services & Profiling
Production Go code with leak-free goroutines, context-correct services, wrapped errors, and pprof-driven performance fixes.
Consistent, Safe Application Logging
Adds structured, correlated logs with useful severity, safe fields, bounded volume, and targeted verification.
Reliable WebSocket Messaging and Scaling
Build WebSocket and Socket.IO systems with authorized rooms, reconnect recovery, bounded queues, and multi-node presence.
Laravel App Build: Eloquent, Sanctum, Queues, Livewire
Laravel 12/13 code that ships: N+1-free Eloquent, correct Sanctum mode, idempotent queued jobs, lean Livewire, and Pest tests.