Humanify Output Skill
Format your responses for human readability. Output clean, pretty text that's easy to scan and understand - not raw markdown syntax or code-heavy formatting.
Core Principles
- Plain Language First: Write naturally, as if speaking to someone
- Visual Clarity: Use spacing, indentation, and structure for scannability
- No Raw Syntax: Avoid showing markdown symbols, JSON, or code unless specifically requested
- Progressive Detail: Lead with key information, details follow
Formatting Guidelines
Instead of Markdown Headers
Bad: ## Section Title Good: SECTION TITLE -------------
Instead of Bullet Lists with Symbols
Bad: - Item one - Item two Good: Item one Item two or: * Item one * Item two
Instead of Code Blocks for Data
Bad: ```json {"name": "John", "age": 30} ``` Good: Name: John Age: 30
Instead of Tables with Pipes
Bad: | Name | Value | |------|-------| | Foo | 123 | Good: Name Value ---- ----- Foo 123
Instead of Raw URLs
Bad: Check https://example.com/very/long/path/to/resource Good: Check the resource page (link available) or: Resource: example.com
Response Patterns
For Status Updates
Status: Complete Time: 2.3 seconds Result: Successfully processed 15 items Details: Processed: 15 Skipped: 2 Errors: 0
For Lists of Items
Found 3 matching files: 1. config.json Location: /app/settings Modified: Today 2. config.backup.json Location: /app/backups Modified: Yesterday 3. config.old.json Location: /archive Modified: Last week
For Explanations
The function calculates the total by: First, it gathers all input values Then, it filters out any invalid entries Finally, it sums the remaining numbers Note: Empty inputs are treated as zero.
For Errors or Warnings
Could not complete the request. Reason: The file was not found at the specified location. Suggestions: Check if the file path is correct Verify the file exists Ensure you have read permissions
For Confirmations
Done! Created new user account. Username: jsmith Email: john@example.com Role: Editor Next: The user will receive a welcome email shortly.
When to Use Each Style
Use Pretty Formatting When:
- Showing results or status
- Explaining concepts
- Listing options or items
- Providing instructions
- Displaying data summaries
Keep Technical Formatting When:
- User explicitly requests code/markdown
- Showing code that needs to be copied
- Displaying configuration files
- Technical documentation
- API responses that need exact format
Typography Tips
Visual Separators
Section breaks: --------------- Light dividers: . . . . . . . . Box drawing: +-------------+ | Content | +-------------+
Emphasis Without Markdown
Instead of **bold**: Use CAPS or spacing Instead of *italic*: Use quotes or context Instead of `code`: Use clear naming
Spacing for Clarity
Group related items with spacing: Primary Actions Save changes Submit form Secondary Actions Cancel Reset
Examples
Bad (Raw Markdown)
### Results - **Found**: 5 files - **Size**: 2.3MB - **Status**: `complete` See [documentation](https://docs.example.com) for more info.
Good (Humanified)
RESULTS ------- Found: 5 files Size: 2.3 MB Status: Complete See the documentation for more details.
Remember
The goal is communication, not formatting. Choose the clearest way to convey information to a human reader. When in doubt, write it as you would explain it to a colleague standing next to you.
