Skip to content
AIOS

Templates

Templates give every project the same documentation shape. They make agent output easier to review because PRDs, ADRs, tasks, reviews, migrations, and releases always follow a familiar structure.

Included Templates

Section titled “Included Templates”
TemplateOutput
vision.template.mdProduct vision captured from product discovery before PRD generation.
prd.template.mdProduct requirements, scope, non-goals, users, and acceptance criteria.
design.template.mdUI/UX design for user flows, screens, interface states, and accessibility.
architecture.template.mdArchitecture overview, constraints, components, and risks.
adr.template.mdOne architecture decision with alternatives and consequences.
task.template.mdA small implementation task with context, acceptance criteria, and validation.
implementation-plan.template.mdStep-by-step implementation planning before editing code.
review-report.template.mdFindings, evidence, risks, and approval state.
test-plan.template.mdTest strategy and verification checklist.
openapi.template.yamlAPI contract stub for endpoint design.
migration-plan.template.mdDatabase migration plan, rollback, and safety notes.
security-review-report.template.mdSecurity review findings and mitigations.
release-note.template.mdRelease summary, validation, rollout, and rollback notes.
changelog.template.mdChangelog draft for release history.

Create Documents From Templates

Section titled “Create Documents From Templates”

Use aios create commands to generate named document stubs:

Terminal window
aios create feature "Habit reminders"
aios create adr "Use server date for completion"
aios create task "Implement habit API"
aios create review "Habit API"
aios create openapi "Habit API"
aios create migration "Create habits table"
aios create security "Habit API"
aios create release "0.3.1"

Generated files are written under the configured docs root, usually docs/.

Why Templates Matter

Section titled “Why Templates Matter”

Templates prevent vague AI output. They ask for the same details every time:

  • scope and non-goals,
  • source-of-truth documents,
  • acceptance criteria,
  • validation steps,
  • risk and rollback notes,
  • evidence before done.

This matters most when a project has both frontend and backend work. The same PRD, ADR, task, and API contract should guide both sides.

How To Use Templates With Agents

Section titled “How To Use Templates With Agents”

When asking an agent to fill a template, point to the exact template and source context:

Read docs/product/vision.md and .aios/templates/prd.template.md.
Create docs/product/prd.md.
Keep acceptance criteria specific and testable.
Do not add implementation details that are not implied by the product context.

For implementation tasks:

Read docs/product/prd.md, docs/architecture/architecture.md, and .aios/templates/task.template.md.
Create one small task for the login API.
Include acceptance criteria, validation commands, and files likely to change.

Keep Templates Stable

Section titled “Keep Templates Stable”

Project teams can adapt templates, but avoid frequent churn. Templates are part of the workflow contract. If a template changes, update related skills, docs, and examples so agents keep producing compatible output.

Section titled “Related Pages”