The first agent-ready slice spec I used had five fields: the target UI state, the entity changes, the route, the security scope, and a done line. The project already had a custom /symfony skill carrying the framework conventions, so I did not want to repeat repository rules, CSRF rules, migration naming, routing habits, form patterns, and security-aware query behaviour in every task. The slice spec only had to say what the framework skill could not infer: what the feature looked like, what data existed, which URL owned it, who could use it, and how I would know it was done.
The Original Method Was Deliberately Small
I was trying to turn a large rebuild into thin pieces that an AI agent could work on without me manually restating the whole project every time. A feature needed a visible target, a data shape, a URL, a permission boundary, and a pass/fail line. Everything else should come from the project conventions.
In this case the skill carried how repositories are built, how query security is preserved, how forms handle CSRF, how migrations are named, how routes are shaped, and which shortcuts are forbidden.
The five-field spec avoided a giant planning document that looked complete while still leaving the actual screen, route, data, permission, or done line ambiguous. For small bounded changes it gave a fresh agent enough to start and gave me something concrete to review, but it never forced the import, review-environment, or security-hardening questions onto the page.
The First Slice Made The Gap Measurable
The documented feature estimate was 66 hours. After implementation reality was counted, the same slice modelled closer to 226 hours of traditional effort.
The original method had captured the feature layer: screens, entities, routes, permissions, states, forms, and acceptance criteria. It had not captured the full delivery layer: import work, framework and toolchain integration, security hardening, review infrastructure, seed data, and remediation.
Some misses were design and review churn after the slice became visible. Some were predictable engineering work that should have had a named place in the plan from the beginning. A flat contingency percentage could have covered the 160-hour gap without naming import work, seed data, review infrastructure, or remediation as categories.
This is where the phrase "feature spec" stopped being precise enough for me: import work, seed data, review infrastructure, and remediation are delivery-spec questions, not feature-spec questions.
Review Infrastructure Became Part Of Done
Once several branches can move at the same time, one shared staging site becomes a coordination bottleneck. A branch might be ready for review while another is waiting for client feedback. A third might need stakeholder review. A fourth might be technically complete but blocked on seeded data, and all four share one staging URL.
That turned review environments into delivery scope. A review/* branch or worktree should be able to create a stable URL, seed the data, show the branch and build being reviewed, and disappear when the branch is merged, abandoned, or replaced. That is cheap for a small slice and its own task once legacy data, permissions, workflow changes, or stakeholder feedback are involved.
The original five fields did not have a natural place for that. The method needed more structure, because a reviewer opening a review/* URL needs evidence of what was seeded, built, and checked.
Seven Stages, Seven Artifacts
The current lifecycle is Plan, Design, Specify, Scaffold, Plan implementation, Implement, Verify. Each step leaves an artifact the next step can inspect.
Plan: slice state
Plan creates the slice boundary and a place for state. It names the work before the project starts absorbing every related concern into one oversized branch. It also creates timing information, so later review can tell which stages actually ran and when.
Design: visible truth
Design captures the visible UI truth before backend structure gets invented from memory. That matters because screens carry quiet requirements: fields, states, labels, grouping, ordering, empty states, permissions, and implied workflow. If those details stay in a screenshot or conversation only, they are easy to lose when implementation starts.
Specify: routes and data
Specify turns the visible work into project artifacts: UI elements, entities, routes, security, requirements, and done criteria. Scaffold then runs before implementation and records what structure could be generated. Even when it generates nothing, the SCAFFOLD.md manifest proves the step was considered. It says this slice did not need new entities, controllers, forms, or tests from the scaffolding pass, rather than leaving that question implicit.
Plan implementation: frozen how
The implementation plan then freezes the work in PLAN.md. That file is the how: task order, tests, files, and implementation moves. It is deliberately different from claude-progress.md, which is the live where: what has been done, what is blocked, what still needs review, and where execution has drifted from the plan.
Implement: live ledger
Implementation keeps the live ledger tied to the code. claude-progress.md matters because the plan is incomplete once the work starts; it records what actually changed, where the slice expanded, and which assumptions had to be corrected.
Verify: audit
The audit compares planned scope against actual code and asks which artifacts were missing, incomplete, or misleading. In this case, the 66-hour slice that became 226 hours is what put import work, review infrastructure, seed data, and remediation into the categories for the next slice.
Convention Layer And Artifact Layer
This also clarified the difference between the Symfony skill and the SDLC lifecycle. The /symfony skill is the convention layer. It tells the agent how this project builds Symfony: repository patterns, CSRF, routing, migrations, forms, naming, dependency choices, and security rules.
The SDLC lifecycle is the artifact layer around that: import work, seeded review data, route security, and rollback checks now have named places in specify and scaffold, before any implementation task is written.
I still want the execution machinery that made parallel agent work useful: fresh subagents, worktree isolation, and review. The missing questions have to sit in the stage where they can still change the work cheaply: a review-environment question before review becomes blocked, an import question before a feature assumes clean data, a security question before generated routes and forms are treated as complete, and a scaffolding manifest before implementation starts writing against entities, controllers, and forms that were never generated.