How I ship software
Every project I take on runs the same loop: a real problem becomes a reviewed issue, an agreed spec, an implementation held to standards, a build verified on staging, and only then a deliberate release. Here is that loop, step by step.
Step 1 — Problem
A real problem, in the business’s words
It starts as a complaint, not a ticket: the last-mile work that never gets budget yet quietly costs a team hours every week. The job is to hear it precisely enough to scope it.
What the agent runs here
superpowers:brainstormingExplores intent, constraints and success criteria before any code exists — the design gets agreed, not assumed.
How to read this
Command — a slash command I run myself
Plugin skill — domain skills installed from a plugin
Superpower — a process the agent is made to follow
MCP server — real tools the agent drives, not guesses
Automation — runs on its own — an Action or a script
Steering — always-on instruction files
Issue status, driven by the staging automation
Promotion to production changes no status — “Done” means integrated and verified on staging.
The steering underneath every step
None of this relies on remembering to ask nicely. Four instruction files are installed for Kiro and Claude Code alike, so both agents work to the same standards before a single prompt is typed.
AGENTS.mdThe engineering standards: the default stack, how testing is done, and what “done” means for UI work.
project-workflow.mdHow a problem becomes issues, issues become specs, and the project board stays in sync automatically.
git-workflow.mdBranch and release discipline: staging integrates, main is production, and promotion is always deliberate.
amplify-deploy.mdThe deploy rules learned the hard way — the npm ci gate, the SSR compute cap, and the known-good build config.
Written once, versioned in a repo, and propagated to every project — so a lesson learned on one build applies to the next.