Comprehensive guidelines for formatting research artifacts, technical surveys, rundowns, book summaries, and documentation with proper markdown formatting for Joplin notes.
When to Use: Automatically activate this skill whenever:
Response: When returning formatted artifacts:
>[toc] tag at start of document if the document is more that 5 pages long###### [GitHub: Repository](url))>[toc]
# Main Document Title
First paragraph content starts immediately after heading. Note that h2 already has a border-bottom in CSS, so NO horizontal rule is added.
## Major Section Header
### Major Sub-Section
---
Content starts immediately after the separator line. This is the ONLY heading level that may sometimes get the horizontal rule separator. The presence or absence of "---" should be consistent throughout the document.
<figure class="img-center">
<img src=":/af5fcef1a0234a36b27c35b519d52e7c" alt="Description">
<figcaption>Figure 1. This is a comment for an example of how an image should be formatted.</figcaption>
</figure>
#### Subsection
Content starts immediately after heading (one blank line before heading). No horizontal rule for h4.
##### Detail Section
More detailed content here. No horizontal rule for h5.
###### Lower-level Details or Paragraph Header
More content.
### Next Major Sub-Section
Content starts immediately after the separator line. This is the ONLY heading level that may sometimes get the horizontal rule separator.
## Next Major Section
There may be an introductory paragraph here. Then content continues with another section.
Format: Always use blockquote syntax with >[toc] at the start of documents
>[toc]
# Main Title of Document
## First Major Section
When to Use:
>[toc] before first h2 heading| Request Phrase | Use Case | Typical Output Length |
|---|---|---|
| "Technical Survey of..." | Compare 5-10 similar tools | 2-4 pages |
| "Technical Rundown of..." | Deep dive on one tool | 3-6 pages |
| "What's New with..." | Recent updates/changes | 1/2 page - 1 page |
| "Book Summary of..." | Summary of a book | 2-4 pages |
| "Article Summary of..." | Summary of an article | 2-4 pages |
| "Whitepaper Summary of..." | Summary of a whitepaper | 2-4 pages |
Trigger: User specifically requests "Give me a technical rundown of..." Use Case: Software engineering tools, libraries, frameworks, platforms Goal: Condensed material for accelerated learning and technical proficiency
Structure:
>[toc]
## [Tool/Framework Name]
### Overview
---
**General Information**: Provide context about the entity. How is it different from competitors? Who created it and when? How have adoption rates changed? What is its basic function and purpose? How does it work at a high level (1-paragraph explanation)? What are its key features and capabilities?
**Key Resources**:
- [Official Site](https://...)
- [Documentation](https://...)
- [GitHub Repository](https://...)
- [Community Forum](https://...)
**Advantages & Disadvantages**:
\+ Major advantage over competitors
\+ Another key strength
\+ Unique feature or capability
\- Notable limitation or weakness
\- Area where competitors may excel
\- Potential drawback or concern
### Common Commands
---
- `command syntax`: *Brief description of what it does*
- `another command`: *Its purpose and usage*
- `third command`: *When and why to use it*
### [Additional Detail Section - e.g., Language Support, Pricing, Roadmap, etc]
---
Content about language support.
#### Specific Language Details
Subsection content here.
### [Another Section - e.g., Pricing]
---
Pricing information.
### [Another Section - e.g., Market Position]
---
Market share, GitHub stars, adoption rates.
Required Additional Sections (when relevant):
Trigger: User specifically requests "Give me a technical survey of..." Use Case: Compare 6-12 similar tools in a specific space Goal: Comparison overview of multiple technologies
Structure:
>[toc]
## [Technology Category Survey]
### Overview
---
Brief introduction to the technology category and why these tools are being compared.
**Comparison Table** (optional):
| Tool | Key Feature | Pricing | Best For |
|------|-------------|---------|----------|
| Tool 1 | Feature | $X | Use case |
| Tool 2 | Feature | $Y | Use case |
### [Tool Name 1]
---
**Background**: When was it created? Who maintains it? How have adoption rates changed recently? Provide context about the entity. How is it different from competitors? What is its basic function and purpose? How does it work at a high level (1-paragraph explanation)? What are its key features and capabilities?
**Key Resources**:
- [Official Site](https://...)
- [Documentation](https://...)
- [GitHub Repository](https://...)
**Advantages & Disadvantages**:
\+ Key advantage
\+ Another strength
\- Notable limitation
\- Area where competitors excel
### [Tool Name 2]
---
[Same structure as Tool 1]
### [Tool Name 3]
---
[Same structure]
Format:
### [Book Title]
**Author**: [Name]
**Context**: Brief background about the author and why they wrote this book.
**Main Objectives**: Core goals and themes of the book.
### Chapter 1: [Title]
[2-5 sentence summary of key points, arguments, and takeaways]
### Chapter 2: [Title]
[2-5 sentence summary]
[Continue for all chapters]
Format:
## [Article Title]
**Author**: [Name]
**Source**: [Publication/Website]
**Date**: [Publication date]
### Summary
[Conventional summary providing balanced mix of:]
- Main arguments and thesis
- Key counterarguments or alternative perspectives
- Significant data points or evidence
- Important conclusions or implications
### Key Takeaways
- [Bullet point 1]
- [Bullet point 2]
- [Bullet point 3]
Format:
>[toc]
## [Topic/Research Subject]
### Context & Background
[Overview of the topic, why it matters, current state]
### Key Findings
[Main discoveries or insights organized logically]
#### Finding Category 1
[Details]
#### Finding Category 2
[Details]
### Methodology
[If relevant: how information was gathered or analyzed]
### Implications
[What this means, how it can be applied]
### References
- [Citation 1]
- [Citation 2]
Format: Always as markdown links with descriptive text
- [Official Documentation](https://docs.example.com)
- [GitHub Repository](https://github.com/org/project)
- [Tutorial Series](https://learn.example.com)
For sub-labels within content:
###### [GitHub: Repository](https://github.com/org/project): *Description of what you'll find*
Format: Use + and - with proper escaping
\+ This is an advantage or positive aspect
\+ Another benefit or strength
\- This is a disadvantage or limitation
\- Another concern or weakness
Why escaping: The backslash prevents markdown from interpreting + and - as list markers
Format: Backticks for command, italics for description
- `npm install package`: *Installs the specified package*
- `git commit -m "message"`: *Creates a commit with a message*
- `docker build -t name .`: *Builds a Docker image with specified tag*
Format: Standard markdown fenced code blocks with language specification
```python
def example_function():
"""This is a docstring"""
return "formatted code"
**Supported languages**: javascript, python, css, html, bash, typescript, go, rust, java, sql, json, yaml, etc.
### Inline Code
**Format**: Backticks for inline code mentions
```markdown
Use the `useState` hook to manage component state.
Available types: idea, todo, warning
Format:
<div class="idea">
<div class="idea-title">Idea</div>
Your idea content goes here. Can include multiple paragraphs, code, lists, etc.
</div>
<div class="todo">
<div class="todo-title">Todo</div>
Your todo content goes here with circular checkmark icon.
</div>
<div class="warning">
<div class="warning-title">Warning</div>
Your warning content goes here with exclamation icon.
</div>
When to use:
Primary Use: Table of contents at document start
>[toc]
Secondary Use: General quotes or tips
> **Pro tip**: Always validate user input on both client and server side to prevent injection attacks.
Format: HTML image syntax with optional caption that provides css for padding, width, and alignment When editing existing notes or adding images, images that are formatted as below:
... should be converted to html:
<figure class="img-center">
<img src="/path/to/image.jpg" alt="Description">
<figcaption>Figure 1. This is a comment for an example of how an image should be formatted.</figcaption>
</figure>
Format: Standard markdown tables, compact spacing
| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Data 1 | Data 2 | Data 3 |
| More 1 | More 2 | More 3 |
Best Practices:
Unordered Lists:
- First item
- Second item
- Nested item (2 spaces indent)
- Another nested item
- Third item
Ordered Lists:
1. First step
2. Second step
3. Third step
Task Lists:
- [ ] Unchecked item
- [x] Checked item (renders italic with reduced opacity)
- [ ] Another unchecked item
Before finalizing any Joplin markdown artifact, verify:
>[toc] tag present at document start (for h2-headed documents)- [Text](URL) or ###### [Source: Title](URL): *description*\+ and \- (escaped)`command`: *description*Understanding why certain formatting choices are made:
border-bottom styling in CSS>[toc] from multi-section documentsUser: "Give me a technical rundown of FastAPI" Action:
>[toc]User: "Summarize this article about neural networks for my Joplin notes" Action:
User: "Create chapter summaries for 'Clean Code' in Joplin format" Action:
User: "Give me a technical survey of Python web frameworks" Action:
>[toc]