Templates & Commands

# Bug Report Title

## Problem and Context
(description of the end users issue, significance, and background)

### Expected Behaviour

### Actual Behaviour

## How to Reproduce

### Preconditions (including roles tested, specific data point if any, or other)

## Checklist
(fixes required for this — restrict only to relevant steps)
- [ ] Item to fix 1
- [ ] Item to fix 2
- [ ] Item to fix 3

## Instances Tested
(If the input mentions instances, check them off here. If not, ignore this section.)
- [ ] Development
- [ ] Staging
- [ ] Demo
- [ ] Production

## Media (Including JAM.dev or video links if any)

## Feature Title
<a suitable, compact feature title that captures the essence of the change request>

## Summary
Clear explanation of why this is important to build and what value it brings.

## Problem & Context
<description of the users pain points and how this solution will help>

## User Story
As a [user], I want this [functionality] so that I can achieve this [benefit].

## In Scope Checklist
- [ ] Item 1
- [ ] Item 2

## Out of Scope
(placeholder)

## Acceptance Criteria (QA Team)
(placeholder)

## Technical Notes (Dev Team)
(placeholder)

## Source Request URL (e.g. ClickUp, Slack, Email)
(placeholder)

# AI Feature Title

## Summary
What the AI feature does and the value it delivers.

## Problem & Context
What the user is currently doing manually, and why AI is the right solution.

## User Story
As a [user], I want [AI capability] so that [benefit].

## Input Data
What data the model receives as context (fields, records, history).

## Prompt(s)
```
System: {system prompt}
User: {user prompt template}
```

## Models & Fallback
Primary: {model}  |  Fallback: {model}

## Acceptance Criteria
- AC-01: {Observable, testable AI output outcome}

# Business Requirements Document (BRD)

> **Status:** DRAFT | IN REVIEW | APPROVED
> **Artefact ID:** `{YYYY-MM-DD}-{feature-slug}-BRD`
> **Feature:** {Feature Title}
> **Author:** Claude (AI) — **Verified by:** {Name / Role}

---

## 1. Summary
{2–3 sentences: what it does, why it exists, value delivered.}

---

## 2. Problem & Objectives

| #      | Objective | Success Indicator |
|--------|-----------|-------------------|
| OBJ-01 |           |                   |

---

## 3. User Stories
- **US-01:** As a {role}, I want to {action} so that {benefit}.

---

## 4. Functional Requirements

### FR-01: {Title}
**Description:** {What the system must do.}
**Triggered by:** {User action or event}

**Acceptance Criteria:**
- AC-01-01: {Observable, testable outcome}

# Product Documentation (PD)

> **Status:** DRAFT | IN REVIEW | APPROVED
> **Artefact ID:** `{YYYY-MM-DD}-{product-slug}-PD`
> **Product:** {Product / Module Name}
> **Author:** Claude (AI) — **Verified by:** {Tech Lead / Product Owner}

---

## 1. Module Overview
{What this module does, who uses it, and where it fits in the product.}

---

## 2. User Roles & Permissions

| Role  | Can do                        | Cannot do          |
|-------|-------------------------------|--------------------|
| Admin | Full access                   | —                  |
| User  | {specific actions}            | {restricted areas} |

---

## 3. Feature Walkthrough
{Step-by-step description of the key flows, verified against the codebase.}

---

## 4. Business Rules
- BR-01: {Observable rule the system enforces}
- BR-02:

# Technical Implementation Plan (TIP)

> **Status:** DRAFT | IN REVIEW | APPROVED
> **Linked BRD:** [{BRD filename}](../requirements/{BRD-filename}.md)
> **Effort:** S (<1 day) / M (1–3 days) / L (3–7 days) / XL (>7 days)

---

## 1. Implementation Tasks

### Backend
| #     | Task | FR(s) | Effort |
|-------|------|-------|--------|
| BE-01 |      |       |        |

### API
| #      | Task                     | FR(s) | Effort |
|--------|--------------------------|-------|--------|
| API-01 | {Endpoint to add/modify} |       |        |

### Frontend
| #     | Task                           | FR(s) | Effort |
|-------|--------------------------------|-------|--------|
| FE-01 | {Component/page to add/modify} |       |        |

---

## 2. API Contracts

### `{METHOD} /api/{endpoint}`
**Auth:** JWT — min role: {Role}

```json
{ "field_name": "string" }
```

---

## 3. Data Model Changes

| Column    | Type    | Nullable | Default |
|-----------|---------|----------|---------|
| id        | UUID    | No       | gen_random_uuid() |
| {field}   | VARCHAR | No       | —       |

# Test Case: {MODULE}_TC{NN}_{Short_Name}

> **Status:** DRAFT | READY | PASS | FAIL | BLOCKED
> **Priority:** High / Medium / Low
> **Type:** Happy Path / Negative / Role-Based / Edge Case
> **Linked BRD:** [{BRD filename}](../../requirements/{BRD-filename}.md)
> **FR/AC:** FR-{xx}, AC-{xx}-{xx}

---

## Preconditions
- Tester is logged in as **{Role}** on **{environment}**
- {Any required data or system state}

---

## Test Steps

| Step | Action                              | Input Data    | Expected Result      |
|------|-------------------------------------|---------------|----------------------|
| 1    | {Click / Navigate / Enter / Select} | {Exact value} | {Observable outcome} |
| 2    |                                     |               |                      |

---

## Postconditions
- {What must be true in the system after the test passes}

---

## Execution

| Field       | Value                       |
|-------------|-----------------------------|
| Executed by |                             |
| Environment | Staging / Demo / Production |
| Result      | PASS / FAIL / BLOCKED       |

# Diagram: {Title}

> **Status:** DRAFT | APPROVED
> **Type:** Sequence / Flowchart / ER / State
> **Linked Artefact:** [{CR or BRD filename}](../requirements/{filename}.md)

---

## Purpose & Scope
{What this diagram shows and why it exists.}

---

## Diagram

```mermaid
sequenceDiagram
  actor User
  participant API
  participant DB

  User->>API: POST /api/{endpoint}
  API->>DB: INSERT INTO {table}
  DB-->>API: {id}
  API-->>User: 201 Created
```

---

## Key Notes
- {Anything a developer or BA should know about this flow}

# ERD: {Title}

> **Status:** DRAFT | IN REVIEW | APPROVED
> **Linked artefact:** [{BRD, CR, or TIP filename}](../../path/to/artefact.md)

---

## Purpose
{Which tables are shown, why this diagram was created, and who the audience is.}

---

## Diagram

```mermaid
erDiagram
    TABLE_NAME {
        int id PK
        varchar name
        int foreign_id FK
        date created_at
    }
    OTHER_TABLE {
        int id PK
        varchar description
    }
    TABLE_NAME ||--o{ OTHER_TABLE : "has many"
```

---

## Relationship Key

| Notation   | Meaning                      |
|------------|------------------------------|
| ||--||     | One to one                   |
| ||--o{     | One to zero or many          |
| ||--|{     | One to one or many           |
| }o--o{    | Zero or many to zero or many |

---

## Notes & Assumptions
- {Any tables or columns omitted for clarity}

# Client Clarification Request (CLQ)

> **Status:** DRAFT | SENT | RESOLVED
> **Related Artefact:** [{artefact filename}](../{path}/{filename}.md)
> **Date:** {YYYY-MM-DD}

---

**Subject: {Feature or Module Name} — Clarification Required Before We Proceed**

{Opening: reviewed the request, conducted a full review, N points to raise before work can begin.}

---

## 1. {Blocker title — plain language}

{Context: what the request assumes, what the system currently does, why they conflict.}

**Question:** {One precise, answerable question.}

---

## Next Steps

Once you have reviewed these points, please reply with your answers or preferred approach.
We will not begin scoping or development until these are resolved.