Templates

Templates define the structure of artifacts and issues. They ensure consistency across your team's output and teach Lisa your standards.

How Lisa uses templates

When you ask Lisa to create a document — a PRD, architecture doc, spec, or any artifact — she uses your organization's templates as the blueprint. Instead of generating arbitrary structure, Lisa fills in your template sections with context from the conversation, your codebase, and the project.

The workflow:

1. You create a template (or use a built-in one)
2. You ask Lisa to create a document: "Write a PRD for our search feature"
3. Lisa generates the document using your template's structure, filling each section with relevant content
4. The result is consistent, complete, and matches your team's expectations every time

Built-in templates

Lisa ships with default templates for each artifact type. These are ready to use out of the box:

Custom templates

Create your own templates to match your team's standards:

1. Navigate to Templates in your organization
2. Click Create Template
3. Write your template in Markdown
4. Select the template type (issue, project, milestone, prd, architecture, spec, design, notes)

Writing effective templates

Templates use Markdown with section headers that Lisa fills contextually. Leave sections empty or add brief guidance comments — Lisa interprets the structure and populates each section based on your conversation.

## Overview

<!-- Brief summary of what this feature does and why it matters -->

## Goals

<!-- What success looks like, measurable outcomes -->

## Non-Goals

<!-- Explicitly out of scope for this iteration -->

## User Stories

<!-- As a [user], I want [action] so that [outcome] -->

## Acceptance Criteria

<!-- Specific, verifiable conditions for "done" -->

## Technical Considerations

<!-- Architecture decisions, dependencies, risks -->

## Open Questions

<!-- Things that need resolution before implementation -->

Example: filled template

When you ask Lisa "Write a PRD for adding real-time notifications," she produces something like:

## Overview

Real-time notification system for the web application.
Users receive instant notifications for issue updates,
new comments, and task assignments via WebSocket.

## Goals

- Users receive notifications within 5 seconds of an event
- Support in-app and email notification channels
- Users can configure notification preferences per-type

## Non-Goals

- Mobile push notifications (future iteration)
- SMS notifications
- Notification digest/summary emails

## User Stories

- As a developer, I want to be notified when assigned
  to an issue so I can start work immediately
- As a PM, I want to see when issues change status
  so I can track progress without checking manually

## Acceptance Criteria

- WebSocket connection established on page load
- Notification badge updates without page refresh
- Email notifications sent within 60 seconds
- Users can toggle notifications per-type in settings

## Technical Considerations

- Use pg_notify + WebSocket (matches existing PostgreSQL setup)
- Leverage existing event bus in src/services/events.ts
- Notification preferences stored in user_settings table

Per-organization customization

Templates are scoped to your organization. Each org can have its own standards without affecting others. When Lisa creates artifacts, she uses your org's custom templates if available, falling back to the built-in defaults.

This means different teams can have different PRD formats, different spec structures, and different levels of detail — all within the same platform.

Best practices

• Be specific about sections — The more clearly you define sections, the more structured Lisa's output will be. Headers like "User Stories" and "Acceptance Criteria" produce better results than "Details."
• Add guidance comments — Brief HTML comments (<!-- ... -->) within sections help Lisa understand what level of detail you expect.
• Keep it lean — Templates with 5-8 sections work best. Too many sections leads to thin content spread across too many headers.
• Iterate — Start with the built-in templates, see what Lisa produces, then customize based on what your team actually needs.
• One template per type — Having a single, well-crafted PRD template is better than multiple overlapping ones. Lisa picks the best match automatically.