Header Banner Image
Your
Trusted
Get Fully AWS Funded
Cloud Migration

Prompt Formatting Guide

This guide defines how we format prompts for CloudBrowser (system, style, errors, tools, context). Consistency ensures prompts are easy to read, easy to maintain, and predictable for both humans and LLMs.


1. Headings
  • Use H2 (##) for each prompt fragment:

    • ## Role, ## Style, ## Errors, ## Tools, ## Context

  • Use H3 (###) inside a fragment if you need subsections:

    • Example: ### Static Entities, ### Dynamic Entities

  • Do not use H1 (#) inside prompts (reserve for Confluence docs).

Example:

## Role
You are CloudBrowser Support Copilot...

## Concepts
### Static Entities
- Client
- Project

2. Lists
Bulleted lists (- or *)
  • Use for unordered items (rules, options, facts).

  • Keep items short (1–2 sentences max).

Example:

- **Clarity**: ≤6 bullets max.
- **Scope**: Current client only.
- **Source of truth**: CloudBrowser data.
Numbered lists (1. 2. 3.)
  • Use when order matters (procedures, workflows).

Example:

1. Identify failing component.
2. Check related events.
3. Suggest remediation.

3. Inline Code vs Code Blocks
Inline code (`example`)
  • Use for commands, identifiers, field names.

Example:

Check pod status with `kubectl describe pod`.
Code fences (```lang … ```)
  • Use for logs, configs, structured output (JSON/YAML).

  • Always label with language when possible (e.g., json, yaml, bash).

Example:

```json
{
  "summary": "Pod was OOMKilled",
  "root_cause": "Memory limit exceeded",
  "suggested_actions": ["Increase memory limit", "Check memory leaks"]
}
```

4. Text Emphasis
Bold (**AAA**)
  • Use for critical rules, entity names, key concepts.

  • Think of bold as must not miss.

Example:

**Source of truth**: Use CloudBrowser data only.
Italics (*AAA*)
  • Use for nuance, optional hints, or tone guidance.

  • Think of italics as soft emphasis.

Example:

Ask for *clarification* if identifiers are missing.
Combined (***AAA***)
  • Rarely used, but can combine bold + italics for critical nuance.

Example:

***Never expose credentials*** in responses.

5. Blockquotes (>)
  • Use for fallback responses or boilerplate outputs.

Example:

> If context is missing, reply: "Not enough data to answer."

6. Separators (---)
  • Use sparingly to break long sections when headings are too heavy.

Example:

## Ground Rules
...

---

## Instructions
...

7. JSON Output
  • Require JSON only when needed for automation.

  • For general answers, prefer bullets.

Example:

Return output in JSON only:
```json
{
  "summary": "Pod OOMKilled",
  "root_cause": "Container exceeded memory limit",
  "suggested_actions": ["Increase memory limit", "Check app for memory leaks"]
}
```

8. Example Full Prompt Structure
## Role
You are CloudBrowser Support Copilot...

## Style
- Be concise and technical.
- Prefer bullet points.
- Output JSON when requested.

## Errors
> If context is missing, reply: "Not enough data."

## Tools
- `search_incidents(query)` → search known incidents.
- `get_metrics(component)` → fetch metrics.

## Context
Logs:
```
OOMKilled: container killed due to memory limit
```
Events:
```
Pod evicted due to node pressure
```

9. Quick Rules Cheat Sheet
  • Use H2 for top sections, H3 for subsections.

  • Bullets for unordered, numbers for steps.

  • Inline code for identifiers, code fences for logs/JSON.

  • Bold = must-follow rules.

  • Italics = nuance or optional hints.

  • Bold + Italics = critical nuance.

  • Blockquotes for fallback answers.

  • JSON only when automation requires structured output.