I "engineered" these AI prompts for my own benefit, but I hope other people find theem useful. I invite constructive criticism and suggestions for improvement.
You will need to customization these prompts to make them relevant to your situations. For exaple: For summarymtg.md, replace my name with yours, list your meeting's attendees, and specify the relevant terms.
The Context Window and Context Rot
Here's a little background for an important context.
Context Window
How much the model can hold in short term memory during a conversation. The context window is the amount of text an AI model can “remember” at one time.
Context Rot
The degradation of an AI's performance that occurs when its context window gets overloaded with too much conversation history, failed attempts, or irrelevant data. As new content comes in and the limit is reached, older content gets pushed out. As noise accumulates, the model struggles to prioritize core instructions, leading to forgetfulness, contradictions, and decreased accuracy. As context rot increases, the model ignores rules, formatting requests, or parameters it was following earlier. Their responses become more generic and less helpful.
Context Distillation
When the model summarizes the conversation, replacing old, verbose context with concise bullet points and uses the summary in a new conversation.
An infographic created with AI in early 2026.
Some Strategies for Avoiding Context Rot:
Periodically make the model apply context distillation.
Break large projects into multiple conversations: Compose a prompt in one chat. Run the prompt in another chat. For example, I used the Claude model to write a prompt for building an accessible and responsive web site in one conversation and I executed the resulting prompt in a conversation with the DeepSeek. One conversation was not enough to complete a draft.
Save your prompts for reuse and update them with the improvements you discover over time.
Upload data in a .csv file instead of a .xlmx file. The .csv file format strip away heavy, hidden formatting and metadata. This results in lower token usage, predictable text parsing, and eliminates errors caused by hidden rows, merged cells, or complex formulas that confuse AI models. It's useful to consider the LLM models as people with disabilities. Apply Accessibility best practices in the Excel or Google Docs workbooks before exporting them to. csv format. (E.G., avoid blank data cells, start in cell A1, do not merge or split cells, apply row and column headers).
Use the best format for your models or tools (e.g., markdown, JSON, XML).
Use retrieval tools or persistent project files (e.g., custom instructions, architectural guidelines) instead of pasting entire files into a chat.
HTML stands for "Hypertext Markup Language." It's the foundational language for web pages.
Markdown is a subset of HTML created to make writing for the web easier.
They serve different purposes in a complementary relationship. Markdown is a lightweight writing format, while HTML is the standard publishing format for the web.
Benefits of Markdown
Adds clear structure with headings and lists, so the model can follow instructions step by step.
Separates context, rules, and examples, which reduces confusion and mistakes.
Matches common training data formats, so the model handles it more reliably.
Encourages better formatted output by mirroring headings, lists, and code blocks.
Makes constraints easier to follow when written as simple bullet points.
Improves readability for humans, which helps with editing and reuse.
Markdown can be overused, which adds noise and hurts clarity. It is best for long or complex prompts. It provides little benefit for very short or simple prompts.
But is it not good for storing complex data structures or strict schemas, where JSON or XML are better. JSON is often used for generating images and videos, but that's outside the scope of this page.
Note: Recently some prompt engineers are using HTML (instead of markdown) to isolate variables, segment complex instructions, or strictly control the formatting of a model's response. If you're unsure whether to use HTML, just used markdown.
Headings: Use # for H1, ## for H2, etc. Emphasis: Use **bold** or *italics*. Lists: Use * or - for unordered, and 1. for ordered lists. Images: Use  for images. Links: Use [Text](URL) for links Code (single line): Enclose text inside single backticks (`text`). Code Blocks: Group multiple lines of code by wrapping them with three backticks (```) on the lines immediately before and after the block.
Pre-Processing Directives are specialized instructions, structured at the beginning of a prompt, that dictate how the input data should be cleaned, transformed, formatted, or constrained before the main model reasoning takes place. Properly preprocessed data ensure the models are not misled by noise, reduce the number of tokens, and produce better, more consistent outputs.
For many of my prompts, I use Interactive Prompting as my Pre-Processing Directive because it allows the model to build a precise, high-context plan, significantly reducing hallucinations and wasted computation on off-target outputs. By initiating the interaction at the start, you shift the LLM from a passive generator to an active, goal-oriented partner that "listens" for crucial details as it reviews the rest of the prompt.
I always specify WCAG guidelines instead of a vague directive like "make the site accessible." I don't trust any models to know what accessibility means. I am more confident that they can observe the WCAG version and levels if I specify them.
In the prompts involving HTML or CSS, I specify conforming to WCAG 2.1 because that is currently the standard for lawsuits and laws. But to future proof your web page, you might want to use WCAG 2.2 instead. (See the The 9 Additional Success Criteria in WCAG 2.2 section on the WCAG page.)
It's redundant to specify both level A and AA WCAG success criteria. LLMs should know to include level A when level AA is specified, but I think it's prudent to explicitly specify both level. It might increase the token count slighly, but it improved the likelyhood that models don't overlook the level A criteria.
In the prompts involving HTML, I specify using HTML5 because HTML5 provides significant accessibility benefits (such and landmarks) over earlier versions of HTML and XHTML.
I specify that the HTML must be valid and strict so that the resulting web pages are robust, predictable, and fully interpretable by assistive technologies. Othewise, the model might produce malformed code that can cause security breaches, rendering errors, and poor accessibility. LLMs often prioritize generating some form of output based on probability, which may not adhere to strict syntactic standards. LLM models immitate the majority of existing (average) web pages which typically do not follow best practices and the highest standard.
Following Google mobile-friendly guidelines alongside WCAG creates a powerful, combined approach that ensures digital content is not just accessible to assistive technology, but actually usable and intuitive for users with disabilities on mobile devices.
In my experience, I have received better results by asking LLMs to avoid including any unnecessary tag attributes, in-line styles, or ARIA. It's less likely to contribute to code bloat, redundancy, and conflict. Otherwise, if I add the AI generated content to an existing web page or site, the new content might break the existing design.
I'm fixated on properly indenting HTML, CSS, and code. It's essential to me for understanding a block of code or markup.
After running any web developmemnt prompts, always validate the model's resulting output.
# Accessible and Responsive Web Page
## Pre-Processing Directive
- Before starting this task, ask **brief clarifying questions** to reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Goal
- Create a web page consisting of an .HTML file, a .CSS file, and (optionally) a .js file.
- Apply **separation of concerns**, where HTML handles the content and structure, and CSS manages the presentation and visual styling.
- Avoid unnecessary use of JavaScript except for **Progressive enhancement** and **Unobtrusive JavaScript**.
## HTML
- Create .HTML in **valid**, **strict** HTML5.
- Apply **responsive design** best practices.
- Comply with WCAG 2.2 level AA.
- Follow Google mobile-friendly guidelines.
- Don't include any unnecessary tag attributes, in-line styles, or ARIA.
- Observe the **first rule of ARIA**.
- Properly indent the HTML and the CSS for readability.
- Set the content area maximum width to 1024 pixels (not counting padding) for when the screen is larger than the content area.
- Set the left and right margins for the content area to auto.
- Link to the .css file in the head of the HTML file.
- Include a typical hamburger menu using the dialog tag, CSS, and as little JavaScript as necessary for functionality.
- Include a standard close button in the hamburger menu.
## CSS
- In the CSS file, include comments specifying the WCAG success criteria and level (e.g., A, AA) and the Google guidelines.
- Prefer REM units rather than EM units.
- Use HSL color codes.
- Properly indent the HTML and the CSS for readability.
Notes:
Separation of Concerns is a fundamental computer science design principle of breaking a system into distinct, independent modules, where each module addresses a single, specific function or set of closely related information. It boosts maintainability, scalability, and reusability, allowing teams to develop, test, and update different parts of a site, such as structure, style, and logic, without breaking others. The key areas of separation (in web development):
Content (HTML): Structure and meaning of the data (e.g., titles, headings, lists)
Presentation (CSS): Visual appearance and layout (e.g., colors, fonts).
Behavior (JavaScript): Interaction and functionality (e.g., button clicks, API calls).
Business Logic (Backend): Data processing, security, and database interactions.
The benefits of Separation of Concerns are:
Improved Maintainability: Changes to one area (e.g., switching from CSS to SASS) do not require changes to others.
Better Collaboration: Teams can work on separate concerns simultaneously, such as separating frontend design from API development.
Scalability & Testing: Smaller, specialized modules are easier to maintain, understand, and test compared to one large, "monolithic block of code."
Progressive Enhancement is a design strategy that starts with a basic, functional version of a webpage using only HTML, then adds layers of style (CSS) and interactivity (JavaScript) as the user's browser allows.
Progressive enhancement improves accessibility by ensuring a baseline, functional experience for all users-regardless of device, browser, or assistive technology-before adding advanced features. It prioritizes semantic HTML, guaranteeing core content is accessible to screen readers, search engines, and low-bandwidth users.
Unobtrusive JavaScript is a principle of progressive enhancement which states that JavaScript should enhance the experience rather than be a hard requirement for the page to function.
The first rule of ARIA is: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state, or property to make it accessible, then do so. In short: Don't use ARIA, use semantic HTML first.
Using REM (Root EM) units over EM units offers greater predictability, consistency, and accessibility in web design. Because rem units are relative only to the root font size-rather than the parent element like em-they prevent complex compounding issues in nested elements, making layout maintenance easier.
HSL (Hue, Saturation, Lightness) color codes are primarily advantageous for being human-readable and intuitive, allowing designers to easily understand and manipulate colors (e.g., creating lighter/darker variants) without relying on tools. They simplify creating harmonious palettes, managing color systems, and improving accessibility by allowing precise, independent control over color intensity and brightness.
I'm fixated on properly indenting HTML, CSS, and code. It's essential to me for understanding a block of code or markup.
# Improve this HTML file
## Pre-Processing Directive
- Before producing the summary, ask **brief clarifying questions** to reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Goals
- Make sure the markup is strict and valid HTML5.
- Preserve ARIA regions and HTML5 landmarks.
- Comply with WCAG 2.2 level AA.
- Follow Google mobile-friendly guidelines.
- Strip all unnecessary tag attributes, JavaScript, and ARIA from attached file.
- Follow Google mobile-friendly guidelines.
- Properly indent the HTML for readability or scanability.
- Transfer any existing styles in the head to an external .css file and link to the .css file in the head.
# Create an Accessible HTML Table
## Pre-Processing Directive
- Before producing the summary, ask the following six questions:
1. Ask for the column names.
2. Ask how many data rows belong in the table.
3. Ask if this table will be added to an existing web site.
- Ask any additional **brief clarifying questions** that will reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- After every five questions, ask whether it's okay to continue asking questions or proceed with the task.
- Do not proceed until questions are answered.
## Context
- You are a web developer adding content in HTML table format to an existing web page.
- There are already styles extant for the table elements.
## Goals
- Write an HTML5 table using strict and valid html.
- Don't include any unnecessary tag attributes or styles.
- Make it WCAG 2.2 level AA compliant.
- Do not use any more ARIA or JavaScript than necessary.
- Keep the table simple.
- Indent the markup for readability.
- Do not include attributes for visual styling or inline styles in the tags.
- Include a header row with column names.
- Do not merge any table cells
Notes:
I wanted to make this prompt as helpful as possible which is why the LLM asks the users for the column names and the number of rows.
I let Deepseek know the subject of the table and it suggested the column names and populated the table cells. Because the topic is well documented online, the table content turned out to be accurate.
For more obscure or proprietary data, I would be more careful. I'd upload or link to specific documentation.
The example I provide below is short: Only 4 rows. In real life I wouldn't waste valuable tokens on such a small task. It would be a better use of my resources to markup the data on my own.
Because I apply the Separation of Concerns, the stripped down HTML conforms to the site design by default. If I had allowed Deepseek the freedom include inline styles or attributes, the resulting table would very likely clash with the rest of the site's aesthetic choices.
Here's an example table I generated in Deepseek. (Notice how this table conforms closely to the overall site design.)
Before starting on my task, ask me any clarifying questions you may have one at a time. I prefer questions in yes/no or multiple-choice format.
Kindly remove all attributes (e.g., class, id, style, width) from the HTML elements/tags from the following html table while keeping the structure and text content intact. Keep the semantic tags. Indent the markup for readability. Apply strict and valid HTML5 and comply with WCAG 2.2 level A and AA success criteria.
Notes:
This prompt is so short, there wasn't a benefit in writting it a a markdown format.
Here is a prompt for creating seamless web background in various diffusion models (i.e., Image Generators). It's not optimoized for any specific diffusion model.
A seamless, tileable background texture of polished honed soft stone. Light cool gray palette: dove to silver tones, approximate hex #e8ebee base. Very subtle mineral veining, fine grain, and gentle diffuse clouding. Evenly distributed composition with no focal points, no directional bias, no visible seams. Flat, diffused lighting. Extremely low contrast, muted and desaturated. Medium-to-large scale texture with moderate density. Refined, crisp, corporate aesthetic. Clean, professional, understated. No text, no logos, no people, no objects. 4K resolution, PNG format, perfectly tileable seamless pattern.
This prompt is optimized specifcally for Midjourney (which is considered by some as the best diffusion model for tileable textures).
/seamless soft stone texture light cool gray dove silver polished honed mineral veining subtle grain diffuse lighting low contrast refined corporate aesthetic 4k --tile --ar 1:1 --v 6.0
This prompt is optimized specifcally for DALLE-3.
Generate a seamless, tileable background texture of polished soft stone in light cool gray tones. Very subtle mineral veining and fine grain. Evenly distributed, no focal points, flat diffused lighting. Extremely low contrast. Refined, crisp, corporate aesthetic. Square format, 4K resolution.
This one is for Stable Diffusion. Use the prompt with "seamless texture" and "tileable" — check the "Seamless" checkbox if available.
Polished honed soft stone texture, cool gray dove silver tones, subtle veining, fine mineral grain, flat lighting, low contrast, refined corporate aesthetic, 4k, texture, seamless
The following prompt was engineered for LLMs (including ChatGPT, Claude, and Deepseek).
# Meeting Summary
## Pre-Processing Directive
- Before producing the summary, ask **brief clarifying questions** to reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Context
- You are a Business Systems Analyst summarizing a meeting transcript for a technical audience.
- The transcript will be provided as an attachment.
## Goals
- Produce a **maximum-detail summary** covering:
- Key decisions, conclusions, dependencies.
- User stories (format: “As a [user], I want [action] so that [benefit]”).
- Acceptance criteria for each user story (explicit or inferred).
- Action items grouped by assignee (use “No Specific Assignee” if missing).
- Questions and follow-ups as action items.
- Aggressively infer missing details where context suggests them. Mark inferred items as “(Inferred).”
- Ignore small talk and vague abstractions. Use active voice, 8th-grade reading level.
## Output Rules
- Format for professional documents:
- Title = `Work_Meeting_Summary` (example filename).
- Begin with boilerplate:
```
This summary was generated with support from Microsoft 365 Copilot Chat from a transcript generated by Microsoft Teams. The content was reviewed by Bouton Jones.. AI and transcription may contain errors; refer to the recording for confirmation.
```
- Use semantic formatting (headers, bullet points).
- Font: Aptos (Body), size 12.
- Timestamps:
- Include for every major point in (mm:ss) or (h:mm:ss).
- End timestamps with “)” followed only by space or punctuation.
- No extra characters, links, or formatting after timestamps.
- Use “>” instead of the right pointing arrow symbol (“→”).
- Do NOT include decorative elements, numbered links, or references to transcript timestamps.
- Provide the output in publication mode: clean text, no internal tracking or citations.
## Validation
Before output:
- Confirm all timestamps comply with rules.
- Confirm formatting and boilerplate are present.
- State at end: “Validation complete: no characters follow timestamps.”
## Possible Attendees
Bob Smith, Sue Jones
## Technical Terms
Accessibility (A11y), World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG), Azure DevOps, FTP, Minimum Viable Product (MVP), Service Level Agreement (SLA), sFTP, Standard Operating Procedures (SOP), VPN, WSDL.
## Compliance Checklist
- [ ] All timestamps follow (mm:ss) or (h:mm:ss) format and end cleanly.
- [ ] Boilerplate text included.
- [ ] Font: Aptos (Body), size 12 confirmed.
- [ ] Assumptions section included.
- [ ] No prohibited symbols or formatting.
- [ ] Compliance statement added at end.
Notes: Validate the results.
Review the summary for accuracy. Compare the summary to the transcript.
If the summary includes footnotes that detract fromt the formatting, ask the AI to "Please regenerate with all citation artifacts removed."
# Training Summary Generation
## Clarifying Questions Directive
- Before producing the summary, ask **brief clarifying questions** to reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Context
- You are a Business Systems Analyst Senior creating documentation from a recorded Teams training session.
- The transcript is attached.
## Goals
- Summarize the transcript for **internal, non-technical employees**.
- Include:
- Business needs
- Steps to take (numbered)
- User stories & acceptance criteria (infer if missing; list assumptions)
- Best practices & tips
- Ignore small talk and irrelevant content.
- Emphasize company-specific details.
- Use **active voice**, **8th-grade reading level**, and **humanized tone**.
## Output Rules
- **Format for Microsoft Office** (Word/Outlook):
- Font: Aptos (Body), size 12
- Semantic styles: Title, Heading 1, Heading 2
- Use bullet points and numbering
- Bold/italic sparingly
- **Title**: Derived from filename (minus extension)
- **Boilerplate (mandatory)**:
```
This summary was generated with support from Microsoft 365 Copilot Chat from a transcript generated by Microsoft Teams. The content was reviewed by Bouton Jones.
```
- **Timestamps**:
- Include for every major point in [mm:ss] or [h:mm:ss] format
- End cleanly with `]` followed by space or punctuation
- No extra characters, links, or formatting after timestamps
- Infer approximate timestamps if missing
- **Symbols**: Use the greater than sign (">") instead of the symbol of a right pointing arrow ("→").
- **No**: em dashes, decorative icons, links, or transcript references
## Validation
Before output:
1. Confirm all timestamps comply with rules.
2. Confirm font, size, and formatting compliance.
3. Confirm boilerplate text is included.
4. Confirm assumptions are clearly listed.
**State compliance explicitly at the end of output with this line:**
```
Compliance confirmed: All rules validated.
```
## Possible Attendees
Bob Smith, Sue Jones
## Technical Terms
Accessibility (A11y), World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG), Azure DevOps, FTP, Minimum Viable Product (MVP), Service Level Agreement (SLA), sFTP, Standard Operating Procedures (SOP), VPN, WSDL.
## Compliance Checklist
- [ ] All timestamps follow [mm:ss] or [h:mm:ss] format and end cleanly.
- [ ] Boilerplate text included.
- [ ] Font: Aptos (Body), size 12 confirmed.
- [ ] Assumptions section included.
- [ ] No prohibited symbols or formatting.
- [ ] Compliance statement added at end.
# YouTube Video Summary
## Context
- You are a Business Systems Analyst Senior.
- You write for a technical audience.
## Clarifying Questions Directive
- Before producing the summary, ask **brief clarifying questions** to reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Summary
* Summarize the attached transcript of a YouTube video.
* Focus on facts, findings, history, motivations, user stories, terminology, statistics, and specific examples.
* Write in an active voice using an 8th-grade reading level with no redundant words or phrases.
## Formatting Guidelines
* Format for Microsoft Office (e.g., Word, Outlook).
* Use semantic formatting such as bullet points and styles (including title, header 1, header 2).
* Derive the title from the filename (minus the file extension).
* Begin the summary with this boilerplate text: "This summary of a YouTube video was generated from a transcript generated by YouTube. The content was reviewed by Bouton Jones. AI and automated transcription can produce errors. For confirmation, refer to the video or transcript."
* Include timestamps in brackets (e.g., (10:54)) at the end of each bullet point. Omit the hour if the time stamp is less than an hour. Use time frames where appropriate.
* Do not include any links, numbers, or characters after the closing bracket of the timestamp.
* Validate before output: confirm that every timestamp ends with ) and is followed only by whitespace or punctuation.
* Include timestamps for every major point.
* When inserting timestamps in brackets (e.g., "(41:36)"), ensure that no characters, formatting tags, footnotes, or superscripts follow the closing bracket. The timestamp must end cleanly with the closing bracket and be followed only by a space or punctuation.
* Do not append any characters (e.g., numbers, footnote markers, formatting tags) after timestamps. Timestamps must appear exactly as (mm:ss) or (h:mm:ss) and must not be followed by any unintended characters.
* Do NOT include any numbered links after the timestamps.
* Do NOT include any "refences to transcript timestamps".
* Do not include em dashes, en dashes, horizontal dividers, icons, or decorative images.
* Use Aptos (Body) font face.
* Use font size 12 for the base font (excluding title and headers).
* Use the greater than sign (">") instead of the symbol of a right pointing arrow ("→").
Explain a Complex Document to Someone with Neudiversity or a Leaning Disability
In the Acessibility community, cognitive and learning disabilities have historically received less attention than physical disabilities. Cognitive disabilities are often invisible. But that is changing. Cognitive disability is rapidly becoming one of the most reported disabilities. WCAG 2.1 added eleven success criteria generally cited as improving cognitive accessibility. WCAG 2.2 added four success criteria categorized under Cognitive Disabilities.
LLMs can be an effective way to make online content more accessible to people with cognitive and learning disabilities. Here's my attempt at creating a useful prompt for that.
# Prompt: Improve the attached document to make it easier to read without losing understanding.
## Pre-Processing Directive
- Before producing the summary, ask the following six questions:
1. Ask what reading level to adopt (e.g., 5th grade reading level, 8th grade reading level).
2. Ask whether to show both the original and revised versions side by side or just the revised version.
3. Ask whether to **emojis** or **icons**.
4. Ask whether to use text formatting (e.g., bold, italics, colors) or if text formatting would distract or confuse.
5. Explain the **Oxford Comma** and ask whether to use it.
6. Ask for the preferred typeface and font size.
- Ask any additional **brief clarifying questions** that will reduce ambiguity (e.g., scope, priorities, formatting) and improve accuracy. Ask the questions one at a time. Based on my answers, you might ask follow-up questions.
- Use **yes/no**, **multiple-choice**, or **short answer**. Prefer short answers only when more efficient than yes/no or multiple-choice.
- Do not proceed until questions are answered.
## Context
Act as a tutor helping a neurodiverse person or a person with a learning disability (e.g. dyslexia, dyscalculia) to understand a challenging document (e.g., email, web page, pdf, Word, or Google document).
## Goals
- Explain the attached document, website, or pasted text.
- Apply WCAG success criteria 3.1.3 (i.e., Unusual Words), 3.1.4 (i.e., Abbreviations), and 3.1.5 (i.e., Reading Level).
- Write in an **active voice** when the actor is known.
- Eliminate redundant words or phrases.
- Eliminate meaningless and vague abstractions.
- Limit use of acronyms.
- Follow the best practice in style guides of **defining the abbreviation** or **spelling out acronyms on first use**. For example:
- First use: "The Environmental Protection Agency (EPA) was founded in 1970."
- Subsequent use: "The EPA is responsible for enforcing environmental regulations."
- Use contractions.
- Apply vertical, **bulleted lists** for lists with three or more items.
- For longer lists (more than 8 items), break them into sub-categories.
- Always introduce the bulleted list with a complete sentence followed by a colon.
- Ensure all items in the bulleted lists start with the same part of speech (e.g., all verbs or all nouns).
- Capitalize the first letter of each item in the bulleted list. If an item is a complete sentence, end it with a period; if it is a phrase, punctuation is not required.
- Use a mixture of short and medium length sentences.
- Break long paragraphs into smaller paragraphs.
- If the content is more than two pages, include **headings** to improve reader navigation.
- Keep the formatting simple and straight forward.
- Use Aptos or another familar typeface.
- Make sure the heading font size is larger than the text body's text size and properly reflects the semantic heading level.
- Add a line break between paragraphs for better readability.
- Use transitional phrases between paragraphs when needed
- If the document is longer than 10 pages, include a table of contents (for the headings) at the beginning.
## Output Rules
- Apply **WCAG 2.2 level A and AA** success criteria to the output
- Follow the principles of **UDL** to the output.
- **Title**: Derived either from filename (minus extension) where a file was uploaded or the content that was included in the prompt.
- **Boilerplate (mandatory)**:
```
This summary was generated with support from AI
```
## Compliance Checklist
- [ ] Boilerplate text included.
Notes:
Rather than deciding for the user what reading level they want, I'm making the LLM ask them directly. By its nature, neurodiversity means that there is no one reading level appropriate for everyone. I know of a graduate student who prompts an LLM to convert her professors' emails to a fifth-grade reading level.
Some users will benefit from a side-by-side comparison of the original and revised versions. Others won't.
Some people will find text formatting (including colors) helpful, but others will be over stimulated.
The Oxford comma (also known as the serial comma) is a comma placed immediately before the coordinating conjunction (usually "and" or "or") in a list of three or more items. It is used to separate the final item from the second-to-last item. I personally don't understand why anyone would not use the Oxford comma. But if you feel differently, I have no way to stop you from removing that list item from this prompt.
I directed the LLM to ask for the preferred typeface and font size. Based on my reading and conference attendance, I believe that "Dyslexia Friendly Fonts" are less effective than using commonly used fonts (like Aptos). But I could be wrong. That's why I'm leaving it to the user to specify the typeface.
Using bulleted lists (to break up dense paragraphs, emphasize key takeaways, and help readers quickly scan essential information) help in understanding. They can break up long, difficult-to-read sentences or paragraphs. They are ideal for unordered information where sequence and priority do not matter. But they are less helpful for lists of three or fewer items.
Why did I include "UDL?" By simply asking "to apply UDL principles," you don't need to specify or explain: Gamification &qmp; Active Recall, Multimodal Content Creation, or Voice-to-Text & Text-to-Speech. Admittedly, this criterion might be unnecessarily broad. I'll look at narrowing it down in future drafts of explain.md.
