A. Primer Prompts

Primer prompts

Use these first to turn working material into a tighter intermediate brief.

Primer Brief

Short brief-building prompt for a concise intermediate deck outline.

Show full prompt
Consolidate everything we've agreed in this conversation into a clean, final deck brief that can later be converted into a strict `deck_spec`.

Only include the final agreed direction. Ignore earlier ideas, alternatives, dead ends, and discarded content.

OBJECTIVE:
Create a clear intermediate brief that:
- resolves ambiguity
- removes duplication
- sharpens the storyline
- chooses the right slide types
- tightens titles and executive-summary wording
- keeps the overall pack short and efficient
- prepares the material for clean conversion into structured JSON

IMPORTANT:
- Do not output JSON
- Do not output markdown code fences
- Do not output alternative options unless explicitly asked
- Be decisive and synthesise to one coherent answer
- Prefer clean consulting language over brainstorming language
- Prefer contractions where natural and professional, such as `aren't`, `can't`, `doesn't`, `it's`, `that's`, and `won't`

YOUR JOB:
1. Identify the final deck objective.
2. Define the clearest top-down storyline.
3. Propose the best section structure.
4. Define the cover-slide content.
5. Draft the executive summary so it works as the first content slide after the cover.
6. Recommend the best slide type for each slide.
7. Tighten titles so they are presentation-ready and likely to fit the template.
8. Make sure the brief is clean enough for direct conversion into a `deck_spec`.
9. Keep the total number of slides tight enough for the standard template to feel full rather than sparse.
10. Use the notes field on each slide to capture concise explainer guidance, future iteration ideas, and open questions where helpful.

OUTPUT FORMAT:

Return the brief using exactly these section headers and structure:

DECK META
- deck_title:
- output_title:
- deck_purpose:
- audience:
- tone:
- document_status:

PACK TITLE
- line_1:
- line_2:

COVER SLIDE
- title:
- subtitle:
- prepared_for:

EXEC SUMMARY
- title:
- subtitle:
- point_1_main:
- point_1_detail_1:
- point_1_detail_2:
- point_2_main:
- point_2_detail_1:
- point_2_detail_2:
- point_3_main:
- point_3_detail_1:
- point_3_detail_2:
- point_4_main:
- point_4_detail_1:
- point_4_detail_2:

SECTION STRUCTURE
- section_1:
- section_2:
- section_3:
- optional_section_4:

SLIDES
For each slide, use exactly this pattern:

SLIDE N
- slide_type:
- section:
- title:
- subtitle_or_message:
- purpose:
- key_content:
- notes:

NOTES RULES
- Every slide must include a populated `notes` field.
- Use notes to add presenter guidance, important caveats, assumptions, useful future-build considerations, and any open questions that should be revisited later.
- Notes should complement the slide rather than repeat it verbatim.
- Prefer compact note sections using plain-text headers followed by short lines.
- Format notes with simple headings and line breaks, for example:
  `EXPLAINER`
  `Short speaker guidance or interpretive framing.`

  `CONSIDERATIONS`
  `- Useful enhancement or future build idea`
  `- Practical thing to test or validate`

  `OPEN QUESTIONS`
  `- Key unresolved issue if one exists`
- Keep notes readable in PowerPoint notes view: short paragraphs, short bullets, and visible spacing between sections.
- Do not force all sections onto every slide; include only the sections that materially help.

SLIDE TYPE RULES
- Always include exactly one `exec_summary` slide as the first content slide after the cover.
- Use `title_section_divider` only when the pack genuinely benefits from section breaks.
- Usually use 0-2 section divider slides maximum.
- Do not use section dividers in short packs unless they materially improve navigation.
- Use `title_full` for narrative explanation and synthesis.
- Use `title_2col`, `title_3col`, or `title_4col` only when the content is clearly parallel.
- Use `title_2x2` only when a matrix genuinely clarifies the argument.
- Use `title_subtitle_table` when the content is best communicated through a compact table.

PACK LENGTH RULES
- This brief version should stay concise at pack level.
- Prefer roughly 4-7 content slides after the cover slide.
- Do not stretch a short argument across too many slides just to create space.
- If the storyline is short, consolidate related points onto fewer slides rather than spreading them thinly.
- Optimise for fuller slides and faster executive consumption, not maximum page count.

TITLE RULES
- Titles must be argument-led, not topic-led.
- Titles should usually fit comfortably within two lines.
- Prefer roughly 8-14 words for titles.
- Keep titles tighter than the maximum available space.
- Use a short full sentence when helpful, but avoid long stacked clauses.

EXEC SUMMARY RULES
- The 4 main points should tell the story on their own if only they are read.
- Each main point can be a short full sentence.
- Each corresponding detail should be exactly 2 full bullet points.
- Keep the detail bullets concise enough to fit comfortably on the slide.
- The exec summary must reflect the key top-down messages supported by the rest of the pack.

SECTION DIVIDER RULES
- Only include a section divider when a new section genuinely changes the focus of the deck.
- Never place section divider slides back to back.
- Do not end the deck on a section divider.

CONTENT RULES
- Keep the pack coherent from top to bottom.
- Avoid repetition across slides.
- Make the logic cumulative, not circular.
- Ensure every slide earns its place in the pack.
- Do not artificially limit the number of points within a column if the slide type can support them cleanly.

Primer Longform

Longform brief-building prompt that preserves more argument and depth.

Show full prompt
Consolidate everything we've agreed in this conversation into a clean, final deck brief that can later be converted into a strict `deck_spec` for a denser, more report-style PowerPoint.

Only include the final agreed direction. Ignore earlier ideas, alternatives, dead ends, and discarded content.

OBJECTIVE:
Create a clear intermediate brief that:
- resolves ambiguity
- removes duplication
- sharpens the storyline
- chooses the right slide types
- tightens titles and executive-summary wording
- preserves more substance than the standard version
- avoids over-summarising material that needs explanatory depth
- allows the pack to expand where the argument benefits from more slides and fuller narrative
- prepares the material for clean conversion into structured JSON

IMPORTANT:
- Do not output JSON
- Do not output markdown code fences
- Do not output alternative options unless explicitly asked
- Be decisive and synthesise to one coherent answer
- Prefer clean consulting language over brainstorming language
- Prefer contractions where natural and professional, such as `aren't`, `can't`, `doesn't`, `it's`, `that's`, and `won't`
- This longform version should preserve more argument, evidence, and implication than the standard version

YOUR JOB:
1. Identify the final deck objective.
2. Define the clearest top-down storyline.
3. Propose the best section structure.
4. Define the cover-slide content.
5. Draft the executive summary so it works as the first content slide after the cover.
6. Recommend the best slide type for each slide.
7. Tighten titles so they are presentation-ready and likely to fit the template.
8. Preserve explanatory depth where the material genuinely needs it.
9. Make sure the brief is clean enough for direct conversion into a `deck_spec`.
10. Use additional slides where needed to avoid compressing distinct arguments too aggressively.
11. Use the notes field actively to capture richer explainer commentary, iteration ideas, and unresolved questions for future builds.

OUTPUT FORMAT:

Return the brief using exactly these section headers and structure:

DECK META
- deck_title:
- output_title:
- deck_purpose:
- audience:
- tone:
- document_status:

PACK TITLE
- line_1:
- line_2:

COVER SLIDE
- title:
- subtitle:
- prepared_for:

EXEC SUMMARY
- title:
- subtitle:
- point_1_main:
- point_1_detail_1:
- point_1_detail_2:
- point_2_main:
- point_2_detail_1:
- point_2_detail_2:
- point_3_main:
- point_3_detail_1:
- point_3_detail_2:
- point_4_main:
- point_4_detail_1:
- point_4_detail_2:

SECTION STRUCTURE
- section_1:
- section_2:
- section_3:
- optional_section_4:
- optional_section_5:

SLIDES
For each slide, use exactly this pattern:

SLIDE N
- slide_type:
- section:
- title:
- subtitle_or_message:
- purpose:
- key_content:
- notes:

NOTES RULES
- Every slide must include a populated `notes` field.
- Use notes to capture presenter guidance, deeper explanation, caveats, assumptions, future iteration ideas, and open questions that may shape later versions of the deck.
- Longform notes can be more substantive than the brief version, but they should still be readable in PowerPoint notes view.
- Prefer compact note sections using plain-text headers followed by short paragraphs or bullets.
- Format notes with simple headings and line breaks, for example:
  `EXPLAINER`
  `Short interpretive commentary that helps the presenter land the slide.`

  `CONSIDERATIONS`
  `- Useful future enhancement`
  `- Additional analysis worth testing`

  `OPEN QUESTIONS`
  `- Material unresolved issue`
- Do not repeat the slide text mechanically; use notes for what sits behind the slide.
- Do not force all sections onto every slide; include the sections that add value for that specific slide.

SLIDE TYPE RULES
- Always include exactly one `exec_summary` slide as the first content slide after the cover.
- Use `title_section_divider` only when the pack genuinely benefits from section breaks.
- Usually use 0-2 section divider slides maximum.
- Do not use section dividers in short packs unless they materially improve navigation.
- Use `title_full` for narrative explanation, synthesis, implications, and denser report-style argument.
- Use `title_2col`, `title_3col`, or `title_4col` only when the content is clearly parallel.
- Use `title_2x2` only when a matrix genuinely clarifies the argument.
- Use `title_subtitle_table` when the content is best communicated through a compact table.

PACK LENGTH RULES
- This longform version may use a longer pack when the material benefits from it.
- Prefer adding slides when that creates clearer argument development, cleaner structure, or better use of narrative space.
- It is acceptable for the longform version to run materially longer than the brief version.
- Use longer body text where needed to preserve evidence, implication, and nuance.
- Avoid splitting content into extra slides unless each slide adds a distinct analytical step.

TITLE RULES
- Titles must be argument-led, not topic-led.
- Titles should usually fit comfortably within two lines.
- Prefer roughly 8-14 words for titles.
- Keep titles tighter than the maximum available space.
- Use a short full sentence when helpful, but avoid long stacked clauses.

EXEC SUMMARY RULES
- The 4 main points should tell the story on their own if only they are read.
- Each main point can be a short full sentence.
- Each corresponding detail should be exactly 2 full bullet points.
- Keep the detail bullets concise enough to fit comfortably on the slide.
- The exec summary must reflect the key top-down messages supported by the rest of the pack.

SECTION DIVIDER RULES
- Only include a section divider when a new section genuinely changes the focus of the deck.
- Never place section divider slides back to back.
- Do not end the deck on a section divider.

B. Output Prompts

Output prompts

Use these second to convert the intermediate brief into strict `deck_spec` JSON.

Output Brief

JSON conversion prompt for the standard deck spec output.

Show full prompt
Convert the structured intermediate brief below into a strict `deck_spec` JSON object for the BFY PowerPoint renderer.

Only use the information contained in the intermediate brief. Do not re-open the thinking, add new ideas, or introduce alternative structures unless the brief clearly requires them.

OBJECTIVE:
Translate the brief cleanly into valid JSON that matches the rendering schema and template assumptions.

OUTPUT FORMAT:
- Output valid JSON only
- Do not include any text before or after the JSON
- Do not include markdown
- Do not explain anything
- Use standard JSON punctuation only
- Use straight ASCII double quotes `"` for all JSON keys and string values
- Use only straight ASCII apostrophes `'` inside string values
- Do not use smart quotes, curly apostrophes, or typographic punctuation that would make the JSON invalid
- Before responding, check that every quote character in the output is straight ASCII
- If a contraction is used, it must use a straight ASCII apostrophe

SCHEMA:

{
  "schema_version": "1.0",
  "deck_title": "",
  "output_title": "",
  "pack_title": {
    "line_1": "",
    "line_2": ""
  },
  "pack_title_slide": {
    "title": "",
    "subtitle": "",
    "prepared_for": ""
  },
  "deck_purpose": "",
  "audience": "",
  "tone": "executive",
  "document_status": "draft",
  "slides": [
    {
      "slide_number": 1,
      "slide_type": "exec_summary",
      "title": "",
      "message": "",
      "body": [],
      "columns": [],
      "matrix": null,
      "table": null,
      "exec_summary": {
        "items": [
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          }
        ]
      },
      "notes": ""
    }
  ]
}

SLIDE TYPES:

1. "exec_summary"
- Must always be slide_number 1 in `slides`
- Must have empty `body`
- Must have empty `columns`
- Must include a populated `exec_summary` object with exactly 4 items
- Use `title` for the exec summary title
- Use `message` for the exec summary subtitle

2. "title_section_divider"
- Must have empty `message`
- Must have empty `body`
- Must have empty `columns`
- Must not include `matrix`, `table`, or `exec_summary`

3. "title_full"
- Must use `body`
- Must have empty `columns`
- `title_full.body` can contain at most 6 bullets

4. "title_2col"
- Must have exactly 2 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

5. "title_3col"
- Must have exactly 3 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

6. "title_4col"
- Must have exactly 4 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- May intentionally use only the first two or the last two columns to leave space for a later visual
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

7. "title_2x2"
- Must use `body`
- Must have empty `columns`
- Must include a populated `matrix` object
- Use `message` as the first narrative line for the left-hand text box
- The `matrix` object must use exactly these fields:
  `header`, `x_axis_title`, `y_axis_title`, `x_axis_lower`, `x_axis_upper`, `y_axis_lower`, `y_axis_upper`, `top_left`, `top_right`, `bottom_left`, `bottom_right`
- `top_left`, `top_right`, `bottom_left`, and `bottom_right` must each be arrays of strings
- Do not use `x_axis`, `y_axis`, or `quadrants`

8. "title_subtitle_table"
- Must have empty `body`
- Must have empty `columns`
- Must include a populated `table` object
- Use `message` as the subtitle text
- The `table` object must use exactly:
  `{"columns": ["", "..."], "rows": [["", "..."]]}`
- Do not use `headers`; use `columns`

CRITICAL FIELD RULES
- `output_title` must be 60 characters or fewer
- Prefer a short, filename-friendly `output_title` that is materially shorter than the full deck title
- If the deck title is long, keep `deck_title` descriptive but shorten `output_title`
- For `title_full`, never output more than 6 body bullets
- For table slides, always use `table.columns`, never `table.headers`
- For column slides, never output column objects with `title` or `items`; use `header` and `body`
- For 2x2 slides, never output a nested quadrant object list; use the four explicit quadrant arrays
- If you output a slide type whose required structure is missing, fix the structure rather than changing the slide type
- Every slide must include a populated `notes` string
- The `notes` field should be meaningfully useful, not a placeholder
- Use notes to capture brief explainer guidance, presentational cues, future iteration considerations, and open questions where relevant
- Format notes as plain text with visible line breaks so they read cleanly in PowerPoint notes
- Use simple uppercase section headers where useful, such as `EXPLAINER`, `CONSIDERATIONS`, and `OPEN QUESTIONS`
- Keep notes concise in the brief version, but do include enough to make the slide more reusable in future iterations

Output Longform

JSON conversion prompt for denser, report-style longform output.

Show full prompt
Convert the structured intermediate brief below into a strict `deck_spec` JSON object for the BFY PowerPoint renderer, using a denser, more report-style longform approach.

Only use the information contained in the intermediate brief. Do not re-open the thinking, add new ideas, or introduce alternative structures unless the brief clearly requires them.

OBJECTIVE:
Translate the brief cleanly into valid JSON that matches the rendering schema and template assumptions, while preserving more substance and avoiding over-summarisation.

OUTPUT FORMAT:
- Output valid JSON only
- Do not include any text before or after the JSON
- Do not include markdown
- Do not explain anything
- Use standard JSON punctuation only
- Use straight ASCII double quotes `"` for all JSON keys and string values
- Use only straight ASCII apostrophes `'` inside string values
- Do not use smart quotes, curly apostrophes, or typographic punctuation that would make the JSON invalid
- Before responding, check that every quote character in the output is straight ASCII
- If a contraction is used, it must use a straight ASCII apostrophe

SCHEMA:

{
  "schema_version": "1.0",
  "deck_title": "",
  "output_title": "",
  "pack_title": {
    "line_1": "",
    "line_2": ""
  },
  "pack_title_slide": {
    "title": "",
    "subtitle": "",
    "prepared_for": ""
  },
  "deck_purpose": "",
  "audience": "",
  "tone": "executive",
  "document_status": "draft",
  "slides": [
    {
      "slide_number": 1,
      "slide_type": "exec_summary",
      "title": "",
      "message": "",
      "body": [],
      "columns": [],
      "matrix": null,
      "table": null,
      "exec_summary": {
        "items": [
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          },
          {
            "main_point": "",
            "detail": ["", ""]
          }
        ]
      },
      "notes": ""
    }
  ]
}

SLIDE TYPES:

1. "exec_summary"
- Must always be slide_number 1 in `slides`
- Must have empty `body`
- Must have empty `columns`
- Must include a populated `exec_summary` object with exactly 4 items
- Use `title` for the exec summary title
- Use `message` for the exec summary subtitle

2. "title_section_divider"
- Must have empty `message`
- Must have empty `body`
- Must have empty `columns`
- Must not include `matrix`, `table`, or `exec_summary`

3. "title_full"
- Must use `body`
- Must have empty `columns`
- `title_full.body` can contain at most 6 bullets

4. "title_2col"
- Must have exactly 2 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

5. "title_3col"
- Must have exactly 3 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

6. "title_4col"
- Must have exactly 4 columns
- Must have empty `body`
- `message` should be a short one-line summary suitable for the bottom summary box
- May intentionally use only the first two or the last two columns to leave space for a later visual
- Each column object must use exactly:
  `{"header": "", "body": ["", "..."]}`
- Do not use `title` or `items` inside column objects

7. "title_2x2"
- Must use `body`
- Must have empty `columns`
- Must include a populated `matrix` object
- Use `message` as the first narrative line for the left-hand text box
- The `matrix` object must use exactly these fields:
  `header`, `x_axis_title`, `y_axis_title`, `x_axis_lower`, `x_axis_upper`, `y_axis_lower`, `y_axis_upper`, `top_left`, `top_right`, `bottom_left`, `bottom_right`
- `top_left`, `top_right`, `bottom_left`, and `bottom_right` must each be arrays of strings
- Do not use `x_axis`, `y_axis`, or `quadrants`

8. "title_subtitle_table"
- Must have empty `body`
- Must have empty `columns`
- Must include a populated `table` object
- Use `message` as the subtitle text
- The `table` object must use exactly:
  `{"columns": ["", "..."], "rows": [["", "..."]]}`
- Do not use `headers`; use `columns`

CRITICAL FIELD RULES
- `output_title` must be 60 characters or fewer
- Prefer a short, filename-friendly `output_title` that is materially shorter than the full deck title
- If the deck title is long, keep `deck_title` descriptive but shorten `output_title`
- For `title_full`, never output more than 6 body bullets
- For table slides, always use `table.columns`, never `table.headers`
- For column slides, never output column objects with `title` or `items`; use `header` and `body`
- For 2x2 slides, never output a nested quadrant object list; use the four explicit quadrant arrays
- If you output a slide type whose required structure is missing, fix the structure rather than changing the slide type
- Every slide must include a populated `notes` string
- The `notes` field should be materially useful, not a placeholder
- Use notes to capture deeper explainer commentary, assumptions, caveats, future iteration considerations, and open questions where relevant
- Format notes as plain text with visible line breaks so they read cleanly in PowerPoint notes
- Use simple uppercase section headers where useful, such as `EXPLAINER`, `CONSIDERATIONS`, and `OPEN QUESTIONS`
- The longform version may use more substantive notes than the brief version, but they should still remain readable and well structured

C. JSON Input And Render

Validate and build deck

Validation runs through your existing schema logic. Rendering runs through your existing PowerPoint generator.

D. Recent Files

Latest generated decks

Newest first. Use this when a deck was generated on mobile and needs to be downloaded later on desktop.

Created Deck title Filename Download
2026-04-08 22:54:16 Monetisation Strategy for Housing Association Solar Assets 2026-04-08_225416_solar-monetisation-strategy.pptx Download
Show rerender overrides
2026-04-08 21:18:56 The MHHS Rumsfeld Matrix 2026-04-08_211856_the-mhhs-rumsfeld-matrix.pptx Download
Show rerender overrides
2026-04-08 21:03:04 MHHS Rumsfeld Framework 2 2026-04-08_210304_mhhs-rumsfeld-framework-2.pptx Download
Show rerender overrides
2026-04-08 20:50:27 MHHS Rumsfeld Framework 2026-04-08_205027_mhhs-rumsfeld-framework.pptx Download No saved JSON