This post continues the idea of Full-Loop Agentic Development (FLAD).

The previous article introduced FLAD as a development model where the agent owns the entire loop: planning, implementation, testing, validation, and only then handing control back to the human.

This time, we’ll keep it short and practical.

Below are two copy‑pasteable prompts, that you can use directly with a coding agent.

  • The first prompt generates a production‑grade AGENTS.md for an existing project.
  • The second prompt kicks off a new project in a FLAD‑native way, using existing ecosystem bootstrapping tools.

Both prompts explicitly require the model to research current‑year best practices, tools, and libraries before producing output.

Prompt 1: Generate AGENTS.md for an Existing Project

Copy everything below and use it as‑is with your coding agent.

You are a senior staff+ software engineer and systems architect.

Your task is to generate a **production‑grade `AGENTS.md` file** for an existing repository.

You MUST:
- Inspect the repository structure, tooling, dependencies, and configuration.
- Search the internet for **current‑year best practices** relevant to the detected language(s), frameworks, and libraries.
- Prefer modern, stable, widely‑adopted tools unless the project clearly dictates otherwise.

This file is **not documentation for humans**.
It is an operational rulebook for coding agents.

---

### Core Expectations

- Treat the project as **production‑level at all times**.
- No hacks, no temporary solutions, no TODOs left behind.
- Code must be future‑proof, maintainable, and idiomatic for the ecosystem.

---

### Engineering Principles (Enforced)

Apply and enforce, where appropriate:
- DRY
- KISS
- YAGNI
- Separation of Concerns (SoC)
- Composition over inheritance
- Functional patterns, immutability, pure functions where practical
- SOLID (especially for larger or long‑lived systems)
- Test‑Driven mindset where feasible

---

### Codebase Structure Awareness

`AGENTS.md` MUST describe the repository so the agent knows **where to make changes without searching**.

Rules:
- Document features and modules at the **directory and file level**.
- Document **shared / common code at the method or function level**.
- Do NOT document trivial private helpers.
- Do NOT mirror the entire codebase — only what is necessary for correct decisions.

---

### Testing Requirements

- **End‑to‑End (E2E) tests**:
  - 100% coverage is mandatory.
  - New functionality requires new E2E tests.
  - Coverage must never drop.

- **Unit tests**:
  - Mandatory for shared / common modules.
  - 100% coverage required only for shared / common code.

- Integration tests where appropriate.

---

### Code Quality & Security Tooling

- Select tools appropriate to the detected stack.
- Research and use **current best‑in‑class tools** (examples only):
  - SonarQube, Snyk, Codacy, Semgrep, Knip, ts‑prune.

Rules:
- Tools must run as part of validation.
- **Warnings are failures**.
- Zero warnings, zero errors.

---

### Definition of Done (Agent‑Enforced)

A task is complete ONLY when:
- Code compiles / builds successfully.
- Linters pass with **zero warnings**.
- Static / code analysis tools pass with **zero warnings and zero errors**.
- Full E2E test suite passes with **100% coverage**, including new tests.

---

### Governance Rules

- The agent MUST always consider whether `AGENTS.md` needs updating.
- `AGENTS.md` MUST NOT include:
  - Change history
  - Changelogs
  - Release notes
  - Commentary that grows over time

- Keep the file **under 300 lines**.
- Be dense, directive, and explicit.

---

### Maintenance Instructions (Required)

`AGENTS.md` MUST include rules that:
- Require the agent to read the entire file before acting.
- Require coherent updates (no isolated inserts).
- Require updating all impacted sections in one change.

---

### Commits

- Follow best‑practice commit conventions (prefer **CBEAMS**).
- Inspect existing commits to infer style if present.
- If no clear style exists, define one explicitly.

---

### Uncertain Inputs

If any required information cannot be reliably inferred (tooling preferences, CI style, testing framework choices):
- Ask the user targeted questions BEFORE finalizing `AGENTS.md`.

---

### Output Rules

- Output **only** the contents of `AGENTS.md`.
- No explanations.
- No commentary.
- No markdown styling beyond headings and lists.

Prompt 2: Kick Off a New FLAD‑Native Project

This prompt is for starting a new project from scratch, using existing ecosystem bootstrapping tools.

Copy everything below and use it as‑is.

You are a principal engineer designing a new production system using
**Full-Loop Agentic Development (FLAD)**.

You MUST:
- Search the internet for **current-year best practices**, tools, languages, and frameworks.
- Prefer modern, stable, widely adopted technology.
- Treat the project as **production-grade from day one**.
- Apply the same rigor as an existing long-lived production system.

This is not a prototype.

---

### Step 1: Interview the User (Required)

Ask concise but thorough questions to determine:

- Problem domain and business goals
- Expected scale, traffic, and longevity
- Runtime environment (web, mobile, backend, cloud, edge)
- Preferred or excluded languages and ecosystems
- Team size, seniority, and development velocity expectations
- Performance, security, compliance, and regulatory constraints
- Deployment model (cloud provider, on-prem, hybrid)

Do NOT proceed until answers are sufficient.

---

### Step 2: Engineering Principles (Enforced)

Apply and encode in **all outputs**:

- DRY
- KISS
- YAGNI
- Separation of Concerns (SoC)
- Composition over inheritance
- Functional patterns, immutability, pure functions where practical
- SOLID (especially for non-trivial systems)
- Test-driven mindset where feasible

---

### Step 3: Technical Decisions

Based on user input and current best practices:

- Select language(s), frameworks, and libraries
- Select testing strategy (unit / integration / E2E)
- Select linting, formatting, static analysis, and security tooling
- Select code quality platforms (e.g. SonarQube, Snyk, Codacy)

Rules:
- Prefer boring, proven technology unless strong reasons exist
- Optimize for long-term maintainability over novelty
- Document all decisions explicitly

---

### Step 4: Project Bootstrap (Mandatory)

DO NOT invent custom init scripts.

Use **existing ecosystem-standard bootstrapping tools**, for example:

- `create-react-app`, `vite`, `next`, `nuxt`
- `create-expo-app`
- `rails new`, `django-admin startproject`
- `cargo new`, `go mod init`

Rules:
- Choose the most appropriate official or de-facto standard tool
- Configure it to **production-grade defaults immediately**

---

### Step 5: Testing & Quality Requirements

- **End-to-End (E2E) tests**
  - 100% coverage is mandatory
  - All user journeys must be covered
  - New functionality requires new E2E tests

- **Unit tests**
  - Mandatory for shared / common code
  - 100% coverage required for shared / common modules

- Integration tests where appropriate

- Code quality & security tooling:
  - Must run as part of validation
  - **Zero warnings allowed**

---

### Step 6: Definition of Done (Agent-Enforced)

A task is complete ONLY when:

- Code compiles / builds successfully
- Linters pass with **zero warnings**
- Static / code analysis tools pass with **zero warnings and zero errors**
- Full E2E test suite passes with **100% coverage**

This definition of done MUST be encoded into `AGENTS.md`.

---

### Step 7: Generate `AGENTS.md`

Generate a complete **production-grade `AGENTS.md`** that:

- Is an operational rulebook for agents (not human documentation)
- Encodes all architectural and tooling decisions
- Describes repository structure so agents know where to make changes **without searching**
  - Features/modules at file & directory level
  - Shared/common code at method/function level
- Enforces production-quality engineering standards
- Requires the agent to consider updating `AGENTS.md` when code changes
- Explicitly forbids change history or growing commentary
- Defines commit message conventions
  - Prefer **CBEAMS**
  - Infer existing style if detectable
- Includes maintenance and governance rules
- Is **under 300 lines**, compact, dense, and directive

---

### Step 8: Output

Output, in order:

1. The bootstrap command(s) used to initialize the project
2. The initial repository structure
3. The complete `AGENTS.md`

Do NOT include explanations unless explicitly asked.
Prioritize correctness, maintainability, and long-term clarity over speed.

Closing

FLAD is not about better prompts.

It’s about moving responsibility — from humans and CI pipelines into the agent itself.

Once your agent has a real definition of done, enforced through AGENTS.md, you stop babysitting changes and start reviewing validated outcomes.

That’s when agentic development stops being a novelty and starts being infrastructure.

We’re only at the beginning of treating agents as full participants in the development loop.

If you’re exploring similar ideas — tighter definitions of done, agent-enforced quality gates, or collapsing CI into the development process itself — let’s compare approaches. This is a space where shared practice will matter more than theory.