Part 5: The Minimum Prompt Standard Starter Kit: Deploy Your Team's Prompt Estate (2026)

← Previous Chapter: Part 4 — Prompt Versioning and CI/CD Evals | Series Hub: Prompt Standard | Next Chapter: Part 6 — Context Engineering & Dynamic Ingestion →

🔗 Related Deep-Dives

• High-Throughput Go Microservices Architecture
• Generative UI with Model Context Protocol (MCP)
• Engineering Reading Map & System Design Guides

Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

Answer-first: The enterprise prompt starter kit standardizes five core directories (roles, rules, workflows, skills, evals) alongside a central conventions charter for immediate team adoption. This modular layout defines explicit code ownership, strict promotion gates from sandbox to production, and shared evaluation harnesses, converting scattered personal prompts into permanent institutional engineering capital assets.

The Goal Is Not Perfection, It Is Usable on Monday

Answer-first: Teams delay standardization believing they must first build a large system — the actual requirement is a five-directory kit. The tree is the Part 3 layer model collapsed into directories, plus evals/ because Part 4 proved measurement is half the system.

Many teams postpone prompt standardization because they imagine a large platform effort first.

The actual minimum is five directories:

• roles/ — L1 identity
• rules/ — L2 invariants
• workflows/ — L3 procedures
• skills/ — L4 domain depth
• evals/ — the measurement half

The five directories are not arbitrary: they are the four-layer model of Part 3 plus the measurement discipline of Part 4 — the whole series folded into a file tree.

The structure has production precedent: the agent-skills pack operates 108 skills, 34 roles, 24 workflows in precisely this shape — centralized rules propagate to every role without per-file edits, and the pack passes 16/16 validation gates at that scale. Your starter tree will not need restructuring when it grows.

The Directory Tree

.agent/
  roles/
    developer.md
    reviewer.md
    writer.md
  rules/
    safety.md
    coding-standards.md
  workflows/
    debug-issue.md
    code-review.md
    quick-docs.md
  skills/
    add-api-endpoint/
      SKILL.md
    write-tests/
      SKILL.md
  evals/
    review-agent-cases.md
    docs-agent-cases.md
CONVENTIONS.md

Minimum Content Per Directory

Roles

Each role file carries:

• identity (one to three sentences — “Even a single sentence makes a difference” per Anthropic)
• responsibilities
• decision boundaries
• communication style

Acceptance test per role file: Anthropic’s golden rule — show it to a colleague with minimal context; if they’d be confused, the model will be too.

Rules

Each rules file contains:

• clear prohibitions
• safety principles
• internal invariants

Keep every file under ~10 lines — long rule files get skimmed; short ones get enforced. The starter safety.md is four prohibitions: no hand-editing generated files, no destructive commands, no fabricated test results, no secret exposure.

Workflows

Each workflow answers:

• when to use (trigger)
• the numbered execution steps (numbering where order matters — Anthropic guidance)
• the expected output

Every step ends on a checkable completion criterion; the final step is a self-check (“Before you finish, verify your answer against [test criteria]”).

Skills

Each skill states:

• which tasks it serves
• which tasks it does not
• execution checklist
• common pitfalls

Trigger words front-load the file; the body loads only on trigger match — the 108 coexisting pack skills never cross-fire precisely because of this granularity discipline.

Evals

Each eval case set carries:

• sample inputs
• pass/fail criteria
• the mandatory-detection list (critical errors the agent must catch)

The starter case set follows the five-probe pattern: happy path, performance case, format-only change, missing-context case, security case — five failure classes, five cases.

The kit extends by directory addition — never by restructuring:

.agent/
  skills/
    reconcile-report/
      SKILL.md
  evals/
    reconciliation-cases.md

reconcile-report (finance add-on) specifies: permitted data sources, the “insufficient data” flag rule, the mandatory diff-table format, and the no-guessing-on-missing-amounts principle.

CONVENTIONS.md — The Kit’s Constitution

Answer-first: Four lines: naming, owner field, review routing, changelog format — the conventions page converts a directory tree into governed infrastructure. Naming is the onboarding UX: new members find the right template without asking. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

Keep the page to one screen — anything longer belongs on the docs site, not at the kit’s front door. Reviewers cite the page in review comments (“naming violation”, “missing owner”) — it converts taste disputes into checklist items.

Two Starter Templates

The Engineering Template

# Identity
You are an engineering agent working in a Go microservices repo.

# Mission
Prioritize correctness, safety, and maintainability.

# Scope
May read code, edit code, and run local validation.
No breaking-compatibility changes without explicit confirmation.

# Context
The repo uses Clean Architecture, DDD, Kratos, PostgreSQL, Redis, and Dapr.

# Workflow
Understand the current state, choose the smallest change, implement, verify, report.

# Output Contract
State the changes made, files touched, verification results, and remaining risks.

# Uncertainty
If data is missing for a major decision, stop and ask concisely.

The Accounting (Reconciliation) Template

# Identity
You are a financial data reconciliation assistant.

# Mission
Prioritize accuracy, no guessing, and clear separation of well-founded vs missing data.

# Scope
May compare figures, detect mismatches, and summarize anomalies.
Must not fill in missing figures or conclude without sufficient documentation.

# Context
Data includes the sales report, the payment statement, and the internal lead sheet.

# Output Contract
Return results in three sections: matched, mismatched, insufficient data.

# Uncertainty
If the basis is insufficient, state "insufficient data to conclude".

Both templates demonstrate deliberate block omission: engineering runs 7 blocks (no Tool Policy — the agent has no tools yet); accounting runs 6 blocks (no Workflow — single-pass comparison). Omission is a documented decision, never an oversight.

The remaining three starters (PM brief, tester test-cases, CS response) follow the same anatomy — porting between teams touches only the Context block; the anatomy travels, the context stays local.

The Three-Step Rollout

Answer-first: Step 1: pick the 1–2 most repeated use cases (by repetition count, not impressiveness). Step 2: write the first standard prompts from the templates. Step 3: watch output for 1–2 weeks and fix on repeated failures — do not standardize everything on day one. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

Step 1

Pick one or two most-repeated use cases — code review, quick docs. Repetition amortizes the template cost and generates eval data fastest.

Step 2

Write the first standard prompts for them — 20 minutes from template, not a design project.

Step 3

Watch output for one to two weeks, then fix based on repeated failures — each repeated failure maps to a block; fix the block, note the changelog. At volume, repeated failures graduate into case files in evals/.

Week one produces three numbers with zero infrastructure: how many runs used the template vs ad-hoc (reuse), which format breaks appeared (pre-eval signal), how many questions new members asked (onboarding friction).

Full bootstrap in seven steps — an afternoon with checkpoints:

graph LR
    A["1. mkdir<br/>five dirs"] --> B["2. Write<br/>CONVENTIONS.md"]
    B --> C["3. Write 2<br/>role files"]
    C --> D["4. Write<br/>safety.md"]
    D --> E["5. Write 2<br/>workflows"]
    E --> F["6. Write 2<br/>skills"]
    F --> G["7. Write 2<br/>eval case sets"]
    G --> T[/"Takeover test:<br/>a new member runs the task<br/>from the tree alone"/]
    T -->|"Pass"| DONE["KIT COMPLETE"]
    T -->|"Fail — more questions"| A

    style DONE fill:#e8f8e8,stroke:#2a7da0

Do not standardize everything on day one. The kit is done when the takeover test passes: a new member takes over your task from the tree alone — no questions to you — and two colleagues independently produce compatible prompts from the same template.

Promotion and Archival Rules Between Directories

Answer-first: The kit lives on pain-triggered promotion: an ad-hoc procedure typed 3x/week → workflows/; domain guidance outgrowing a workflow → skills/; an invariant discovered in an incident → rules/; a repeated failure pattern → evals/. Workflows nobody follows get archived, not defended. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

graph TD
    AD["Ad-hoc procedure<br/>(typed in chat)"] -->|"3x/week"| WF["workflows/"]
    WF -->|"domain guidance outgrows it"| SK["skills/"]
    INC["Production incident<br/>(invariant discovered)"] --> RL["rules/"]
    FAIL["Repeated failure<br/>pattern in output"] --> EV["evals/"]
    AD -.->|"zero repeated failures"| KEEP["No standardization needed<br/>(documented decision)"]

    style WF fill:#e8f4f8,stroke:#2a7da0
    style EV fill:#e8f8e8,stroke:#2a7da0

Usage is the only legitimacy test: dead files mislead new members more than missing files. Monthly, borrow the period-end close rhythm: conventions still one page? rules still true? workflows still match practice? skills still triggering? evals still passing? — five questions, twenty minutes.

Production Failure: The Perfect Kit That Sits on the Shelf

Answer-first: The kit’s most common failure is not breaking — it is not being used: templates no task matches (template fiction), case files never run (eval theater), files without owners (owner sprawl). All three are diagnosable by the takeover test. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

The scenario: a team copies a beautiful kit template from a blog, spends two evenings customizing it, merges it… and three weeks later, the chat logs show everyone still typing prompts by hand because “the template doesn’t match my actual task.” The root cause is always one of three:

• Template fiction — templates written for imagined tasks, not the repeated real ones. Selecting use cases by repetition count prevents this disease entirely.
• Eval theater — case files written beautifully and never run. Attach them to Step 3 of the rollout; they run at the same cadence as the fix loop.
• Owner sprawl — orphan files nobody reviews or maintains. The owner: frontmatter field is the vaccine.

All three share one diagnostic: a failed takeover test — the new member cannot run the task from the tree. When it fails, don’t add longer documentation; ask the member what was missing, and write exactly that piece.

What Template Posts Skip (and This Kit Ships)

Answer-first: The information gain over typical team-prompt-template posts is the governance half: the evals/ directory, the conventions page with review routing, ownership fields, promotion rules between directories, and the honest anti-doctrine — none of which ship in template-list posts. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

The comparison, dimension by dimension:

The last row is the one most posts cannot afford: the kit’s honest failure mode is working-but-not-growing — team standardizes two use cases and stops. Acceptable if those two were the pain; a stall if the pain was bigger. The kit gives you the signal (repeated failures outside standardized use cases); the verdict stays human.

What to Remember

Answer-first: A good Prompt Standard is one the whole team can use, understand, and modify — if only one person understands the prompt system, it is not standardized yet. Prerequisite: Understanding of repository layout standards, code review workflows, and team contribution guidelines.

A good standard should be:

• clear (a one-page conventions file)
• sufficient (five directories, no more)
• maintainable (one owner, one version per file)
• tied to real work (evals use real inputs)

Four numbers say the kit works, countable from week one: reuse rate up, format-break incidents down, onboarding time down, pass rate stable or up.

The kit is deliberately the floor, not the ceiling: when it strains — more than five active prompts, more than three task types, a security review need — the deep-dive chapters take over: layered stacks with cache economics, MCP tool contracts, DSPy compilation, and CI-gated PromptOps.

The graduation signals, as a checklist you can audit quarterly:

None of these unlock prematurely — the kit’s five directories remain the base layer under every later upgrade; nothing you build this afternoon gets thrown away.

Return to the series index for the full roadmap, or use this series as internal onboarding material for your team.

❓ Frequently Asked Questions

📚 Research Anchors

Full 100-round research dossier: reports/research-prompt-standard-part-5-team-template-100-rounds.{md,json} (mirrored in both repositories). Grounding note: 20/100 rounds carry external source URLs; 77/100 trace series/pack-internal evidence (this kit codifies the structure the series itself runs on — series-internal is the primary source class by design); 3 rounds carry [INFERENCE] labels. Scale figures (108 skills / 34 roles / 24 workflows / 16 gates) are verifiable by running python3 core/scripts/validate-all.py from the agent-skills repository.

Series Table of Contents | You have reached the final part. Revisit the series index for the full roadmap.

Automated Pre-Commit Linting Hooks for Prompt Repositories

Answer-first: Installing automated pre-commit hooks in team repositories guarantees that 100% of committed prompt markdown files adhere strictly to the 8-block schema, pass secret scanning, and include valid YAML frontmatter before pushing to remote branches.

To prevent unformatted or insecure prompt files from entering team repositories, the starter kit provides an out-of-the-box .pre-commit-config.yaml specification:

# .pre-commit-config.yaml — Automated Prompt Standard Linter
repos:
  - repo: local
    hooks:
      - id: lint-prompt-blocks
        name: Enforce 8 Core Prompt Blocks
        entry: python3 scripts/lint_prompt_structure.py
        language: python
        files: ^(roles|skills|workflows)/.*\.md$
        pass_filenames: true
      - id: detect-api-credentials
        name: Block Hardcoded Credentials & API Keys
        entry: detect-secrets-hook
        language: python
        files: ^.*\.md$
      - id: validate-pydantic-schemas
        name: Validate Prompt Pydantic Schema Contracts
        entry: python3 scripts/verify_schemas.py
        language: python
        stages: [pre-push]

The 5-Minute Production Readiness Gatekeeper Checklist

1. Are Layer 1 (Role) and Layer 2 (Rules) completely static and isolated from user input?
2. Are all runtime variables enclosed in unambiguous XML tags (<user_input>, <data_context>)?
3. Does the golden test suite contain at least 10 ground-truth fixtures (including 2 adversarial probes)?
4. Did the candidate pass the automated CI gate with >= 95% pass rate across pinned models?
5. Is the prompt contract committed with an explicit SemVer tag and entry in CHANGELOG.md?