The Goal Is Not Perfection — It Is Getting Started

Many teams delay because they think they need a massive prompt system.

In reality, to get started you only need five directories:

  • roles/
  • rules/
  • workflows/
  • skills/
  • evals/

Suggested Directory Structure

.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

Minimum Content for Each Layer

Role

Each role should contain:

  • identity
  • responsibilities
  • decision boundaries
  • communication style

Rules

Each rule file should contain:

  • clear prohibitions
  • safety principles
  • internal invariants

Workflow

Each workflow should answer:

  • when to use it
  • what steps to follow
  • what output is expected

Skill

Each skill should specify:

  • which tasks it applies to
  • which tasks it does not apply to
  • implementation checklist
  • common pitfalls

Evals

Each eval set should have:

  • sample inputs
  • pass/fail criteria
  • mandatory issues that must be detected

A Short Prompt Template for Teams

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

# Mission
Prioritize correctness, safety, and maintainability.

# Scope
Allowed to read code, modify code, and run local validation.
Not allowed to make breaking changes without 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
Clearly state changes made, related files, verification results, and remaining risks.

# Uncertainty
If you lack data for a major decision, stop and ask a concise question.

This template is not final, but it is enough for a team to start working consistently.

A 3-Step Adoption Roadmap

Step 1

Choose the 1 or 2 use cases your team repeats most often.

Examples:

  • code review
  • writing docs

Step 2

Create the first standard prompt for those use cases.

Step 3

Monitor output for 1–2 weeks, then iterate based on recurring errors.

Do not try to standardize everything on day one.

Final Takeaway

A good Prompt Standard is one that the entire team can use, understand, and maintain.

If only one person understands the prompt system, it is not truly standardized.

A good standard should be:

  • clear
  • just enough
  • easy to maintain
  • tied to real work

If you have mastered the foundations, continue to the advanced sections: Read Part 6 — From Prompting to Context Engineering.

🤝 Let's Connect

Are you facing similar challenges with system architecture, scaling, or migration? I'd love to hear about it. Connect with me on LinkedIn, check out my GitHub, or drop me an email.