AI-Assisted Greenfield Software Development, Part 7: Implementation Prompts

by John Miller | April 23, 2026

This is the seventh post in the series on AI-assisted greenfield software development. This post builds on the first AI-Assisted Greenfield Software Development - Part 1: Business Requirements and the subsequent posts in the series. If you have not read those posts, you may want to start there.

We'll finish the planning phase by creating implementation prompts that guide AI agents through coding work while keeping generated output aligned with our technology-specific instruction files and architectural vision. In this post, I'll use the planning and persona-agent outputs to define implementation slices with clear dependencies and acceptance criteria. The goal is to move from governance-compliant planning into execution prompts that drive coding tasks with minimal ambiguity.

Up to now, the repository had AI provenance rules and some high-level standards, but it did not yet have a strong model for how AI agents should participate in delivery or how the Academia domain should be decomposed into implementable slices. This post closes that gap by defining the expected agent behavior, formalizing the vertical-slice approach, and documenting the domain workflows those slices are meant to satisfy. That gives both human contributors and AI tools a shared contract: which artifacts matter, how work should be broken down, and what kinds of outputs are acceptable.

Why Implementation Prompts Matter

Planning artifacts are necessary, but they are not enough to drive consistent implementation. Requirements describe what the system should do, architecture explains how the solution should be shaped, and workflow models describe the business domain, but none of those artifacts alone tells an AI agent exactly how to execute a bounded slice of work. Without that execution layer, AI tends to fill in gaps with convenience-based assumptions, which usually leads to drift in scope, inconsistent verification, and weak traceability between requirements and code.

Implementation prompts solve that problem by turning planning intent into an operational contract. A strong implementation prompt defines the slice boundary, identifies the right agent roles, sequences the work, names the required artifacts, makes the acceptance criteria observable, and states how the result must be verified and demonstrated. That gives both human contributors and AI agents a concrete delivery plan instead of a vague request.

For Zeus Academia, this step was especially important because the repository had already accumulated architecture guidance, provenance rules, and domain models, but it still needed a disciplined way to convert those artifacts into full-stack slice delivery. The implementation prompts close that gap by binding planning, execution, and verification together in a format that can be reused across the backlog.

Revising the Implementation Plan to Include Full-Stack Slice Delivery

Before diving into the implementation prompts, I need to tweak some of the previous work. Microsoft Copilot inferred that the implementation plan and the slices were backend work only. This was not the intent and it led AI to create separate slices for the front-end and the back-end. I needed to update the guidance to implement the backend and the frontend together in the same slice. Look at commit 9fb04 for details on these changes.

From Here to Implementation

To begin implementation effectively, I first needed implementation prompts, which define exactly what the AI needs to accomplish to complete a slice, including prerequisites, tasks, validation steps, and delivery expectations. These prompts matter because they directly shape the implementation work, so they need to be precise, scoped, and unambiguous.

Before generating implementation prompts, I needed to define what those prompts should contain. That keeps the resulting implementation plans consistent and actionable. I also needed an execution plan to orchestrate slice delivery and a project overview instruction file to describe what we are building, which technologies we are using, and which standards the implementation needs to follow.

What follows are descriptions of the changes needed to get to the implementation prompts.

New Guidance

Like any other AI-generated artifact, I want the implementation prompts to follow a standard pattern and to be explicit about both intent and expectations.

project-overview.instructions.md

Submitting the create-project-overview.prompt.md prompt generates the project-overview.instructions.md instruction file containing repository-wide project overview instructions for zeus.academia that defines the application as a full-stack academic management web app and establishes shared context for AI-assisted work: it captures architecture, coding and testing standards across language, deployment and environment targets, key operational constraints, core implementation patterns, and a curated set of critical instruction files that govern development workflow, branching, custom agents, prompt practices, and provenance requirements.

implementation-prompt-generation.instructions.md

The implementation-prompt-generation.instructions.md file defines the standard for writing implementation prompts for the Academia vertical slices.

Implementation prompts are critical documents that tell the AI what to build and how to build it. To be effective, they need to be clear and unambiguous.

These instructions extend prompt-file-generation.instructions.md. Implementation prompts are a specific type of prompt, and the implementation-prompt instructions add requirements for showcasing outcomes and defining acceptance criteria.

Each implementation prompt orchestrates the implementation of its slice. It delegates work to other custom agents based on their specialties..

It specifies the preferred structure for implementation prompts, including objective, scope boundaries, agent plan, implementation steps, behavioral acceptance criteria, verification plan, showcase steps, output artifacts, and a validation checklist. It also makes the quality bar explicit by requiring observable and testable outcomes, human-executable demo steps, concrete verification commands, and disclosure of any missing agent dependencies, so the resulting prompts are concise, executable, and usable by both AI agents and human reviewers.

create-implementation-prompt-generation-instructions.prompt.md

The create-implementation-prompt-generation-instructions.prompt.md file generates the implementation-prompt-generation.instructions.md instruction file. I usually start with an ad hoc prompt to create the instruction file, and once the result is working, I convert that prompt into a checked-in prompt file so it can be versioned, traced, and reused.

implementation-prompt.instructions.md

implementation-prompt.instructions.md sets the repository standard for authoring vertical-slice implementation prompts: each prompt must cover one bounded slice, be grounded in existing repo evidence (instructions, agents, and prior prompts), define explicit multi-role agent ownership and handoffs (with escalation triggers), follow a fixed section order, provide numbered actionable steps with targets/owners/validation gates, include observable and testable acceptance criteria, separate implementation from verification with required evidence capture, and end with human-run showcase steps proving business value; it also prescribes role preferences (for example using report-projection for reporting-heavy work and data-persistence for schema-heavy work), includes a reusable template plus anti-patterns/checklists, and requires ongoing alignment of prompts with shared agent profiles and project-overview references.

create-implementation-prompt-instructions.prompt.md

create-implementation-prompt-instructions is a meta-prompt that instructs an AI to generate a concise, evidence-grounded implementation-instructions file for slice delivery, requiring strict context review of existing project standards, explicit single-slice scope, role-specialized agent orchestration (including named reusable agents and fallbacks), fixed prompt section ordering, concrete numbered implementation steps with file-level targets and handoffs, observable acceptance criteria, separated verification and showcase workflows, reusable template and anti-pattern coverage, and a final validation checklist; it also mandates provenance-complete metadata, cross-reference updates to project overview, and success criteria centered on executable slice plans that humans and agents can both verify and demo.

create-project-overview.prompt.md

Before I could generate slice-level implementation prompts, I needed a repository-wide project overview instruction file that captured the shared architectural and technology context. I used this prompt to create that instruction file in a reusable, provenance-friendly form:

Create a prompt to create a Project Overview instruction file containing the high-level context for the project.

New Artifacts

In order to produce the implementation prompts we need to provide clear guidance coordinating the implementation of each slice and there are the implementation prompts that we've been driving toward all this time.

academia-execution-plan.md

The project overview and the implementation plan are used to produce an execution plan.

Create a prompt file that generates an execution plan from the #file:project-overview.instructions.md and the #file:academia-implementation-plan.md

The academia-execution-plan is a dependency-driven delivery blueprint for Zeus Academia that sequences the full vertical-slice backlog from Shared Kernel foundations through reference data, registration, core mutations/queries, lifecycle closure, and finally report/projection slices, with explicit phase objectives, blockers, per-slice backlog items, and strict quality governance tying progress to business-rule invariants.

The execution plan differs from the implementation plan in that the implementation plan focuses on delivering features logically whereas the execution plan is about technical implementation.

Academia Implementation Prompts

The following prompt generates implementation prompts for all of the slices in the implementation plan.

Create an implementation prompt for each slice in the #file:academia-implementation-plan.md

The next step was to generate a concrete implementation prompt for each slice in the plan so the backlog could move from architectural intent to execution-ready work items.

In theory, and hopefully in practice, submitting these prompts will result in an application that meets our requirements, going all the way back to Part 1.

ep-1-1-manage-ranks-implementation.prompt.md

Here is a closer look at one of the implementation prompts. ep-1-1-manage-ranks-implementation.prompt.md is a slice-scoped implementation prompt for the Phase 1 ManageRanks reference-data capability, directing a coordinated workflow (slice-coordinator, backend-domain, testing-verification) to establish one canonical rank source, implement validated add/list CQRS behavior and endpoints, enforce strict allowed rank codes (P, SL, L) with duplicate prevention, and produce verification evidence through validator/handler/integration tests, while explicitly constraining scope away from unrelated academic/employment/reporting work and requiring a human showcase that proves downstream slices can reliably consume stable rank/access-level reference data rather than hardcoding it.

New Agents

The last preparation step was to build the agents that would implement the solution. The implementation prompts hand off work to the appropriate agents so each slice can be executed with explicit role boundaries.

backend-slice-implementer.agent.md

The backend-slice-implementer agent is specialized for implementing backend vertical slices in the Zeus Academia system using ASP.NET Core, MediatR, EF Core, FluentValidation, and xUnit, with a strict, evidence-based workflow that starts by reading slice and repo instructions, then implementing only the required backend components, running focused verification, and reporting results in a fixed structure.

slice-verifier.agent.md

The slice-verifier agent acts as a strict, evidence-first QA owner for individual vertical slices: it verifies implementation against the slice prompt and acceptance criteria, checks changed files and focused tests, runs any missing safe verification commands, and produces a pass/fail assessment.

data-integration-doc.agent.md

The data-integration-doc agent defines a support-focused Zeus Academia agent that handles slice-adjacent work such as migrations, integration touchpoints, documentation, rollout/showcase notes, and traceability, with a process centered on confirming support scope, identifying impacted artifacts, making only minimal enabling changes, capturing side effects, and handing off evidence plus residual risks to coordination and verification roles.

data-persistence.agent.md

The data-persistence agent defines a Zeus Academia persistence-focused implementation agent responsible for making minimal, high-integrity EF Core changes that support slice-level domain rules, with a workflow that starts by validating slice rules and current persistence context, then applies targeted mappings/constraints/indexes/migrations, verifies database behavior aligns with aggregate and validator invariants, and hands off assumptions and risks to coordination/testing roles.

backend-domain.agent.md

The backend-domain agent defines a Zeus Academia backend/domain implementation persona that owns slice-scoped ASP.NET Core CQRS work across commands, queries, validators, handlers, endpoints, and required persistence updates, with a strict workflow of reviewing prompt and standards, confirming target feature/contracts/domain rules, implementing in dependency order, validating behavior, and handing off API contracts and edge cases to coordinator/frontend/testing/doc roles.

frontend-workflow.agent.md

The frontend-workflow agent defines a Zeus Academia frontend implementation persona responsible for slice-scoped Vue 3 workflows with strict TypeScript typing and Pinia state patterns, following a process of reviewing slice/API context, confirming flow and state ownership, implementing minimal UI/store/composable changes, validating loading/success/empty/failure behavior against backend contracts, and handing off notes to verification.

report-projection.agent.md

The report-projection agent defines a specialized Zeus Academia agent for report and projection work, focused on building read models, grouped/analytical queries, projection-backed endpoints, and report DTO contracts while keeping outputs aligned with canonical source-of-truth domain rules; it prescribes a minimal-change workflow (validate reporting dependencies and semantics, implement targeted query-side changes, verify grouped/projection accuracy after lifecycle state changes, and hand off).

slice-coordinator.agent.md

The slice-coordinator agent defines a coordination-focused Zeus Academia persona that manages vertical-slice delivery by confirming scope and prerequisites, identifying required repo context, sequencing work with explicit role handoffs, escalating blockers or pattern conflicts early, and finishing with verification gates plus unresolved risks.

testing-verification.agent.md

The testing-verification agent defines a Zeus Academia verification-focused persona that treats evidence as the gate for slice completion: it reviews acceptance criteria and changed surfaces, derives minimal high-value checks, executes or specifies backend/frontend/data/contract validation, captures pass/fail proof and unresolved gaps, and returns a verdict based on observed outcomes rather than implementation intent; it emphasizes advanced strengths in criteria analysis, integration and failure-mode testing, strict escalation when criteria or prerequisites are missing, and hard boundaries against masking flaky or incomplete verification, signing off with partial evidence, or changing broad app behavior just to make tests pass.

What's Next?

At this point, the repository has enough structure to move from planning into disciplined implementation. The requirements, architecture guidance, project overview, execution plan, implementation prompts, and agent roles now form a connected delivery system rather than a loose collection of artifacts. In the next post, I'll begin implementing the earliest slices in dependency order so we can see whether this workflow holds up under real coding work.

If you're interested in the files, you can find them in the Academia GitHub repository. If you'd like to follow along with your own implementation, fork the repository and use the fork to build your own version.

Feedback Loop

Feedback is always welcome. Send your thoughts to john.miller@codemag.com.

Disclaimer

AI contributed to the writing of this post, but humans reviewed it, refined it, enhanced it, and gave it soul.

Prompts:

• Examine the changes made on the Part-Seven branch and describe in prose targeted for human consumption, the intent of the change, the justification for the change, and the implementation.
• Summarize this file in one paragraph.
• List all of the slices in a Markdown table. Include a link to the file on GitHub. Also include the slice number, the functional and non-functional requirements, and the slice numbers this slice depends on.