joplin-research

What this skill does

**When to Use**: Automatically activate this skill whenever:
- User mentions "Joplin" in their request
- User requests markdown artifacts for note-taking
- User requests technical rundowns, summaries, or research documents
- User explicitly requests content following their markdown preferences

**Response**: When returning formatted artifacts:
- Refer to the generated content
- Do not describe formatting rules and other details followed, unless more substantial changes to content have been made

## Core Formatting Principles

### Spacing and Line Break Rules
1. **Heading Spacing**:
   - Two carriage returns (blank lines) BEFORE h2 headings
   - One carriage return (blank line) BEFORE all other headings (h3, h4, h5, h6)
   - CRITICAL: NO extra blank lines after headings
2. **Horizontal Rules**:
   - Remove any extra horizontal rules ("---") under headings other than H3. These are handled by CSS.
   - **NEVER use "---" after h1 or h2 headings** (they already have border-bottom in CSS)
   - **NO other heading levels** (h4, h5, h6) should have horizontal rules.
3. **Content Spacing**:
   - NO extra blank lines within sections unless separating fundamentally different concepts
   - CLI commands follow the same compact formatting as other content
4. **General Rule**: If in doubt, use less spacing rather than more

### Heading Hierarchy & Typography
1. **h1 Headings** - Bitter Serif, 2rem, border-bottom
   - Rarely used. Reserve for document title only in special cases
   - Already has border-bottom in CSS, so NEVER add "---" after it
   - Usually preceded by `>[toc]` tag at start of document if the document is more that 5 pages long
2. **h2 Headings** - Bitter Serif, 1.8rem, border-bottom
   - Main document sections
   - Already has border-bottom in CSS, so NEVER add "---" after it
3. **h3 Headings** - Bitter Serif, 1.5rem
   - Primary section dividers
   - ONLY heading level that gets "---" separator underneath
   - This is where major content sections begin
4. **h4 Headings** - Bitter Serif, 1.25rem
   - Sub-sections within h3 sections
   - Regular markdown, no special formatting
   - Use for subsections within a larger section
5. **h5 Headings** - Bitter Serif, 1.25em
   - Detail-level sections
   - Regular markdown, no special formatting
   - Use for even smaller section headings
6. **h6 Headings** - Sans-serif, 0.9rem, weight 600
   - Rarely used
   - For emphasis or 1-paragraph comments
   - Often used for sub-labels within lists (e.g., `###### [GitHub: Repository](url)`)

### Example Structure:
```markdown
>[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.
```


## Table of Contents

**Format**: Always use blockquote syntax with `>[toc]` at the start of documents
```markdown
>[toc]
# Main Title of Document
## First Major Section
```

**When to Use**:
- Always include for documents longer than 4-5 pages long
- Place at the very beginning of the document
- Single blank line after `>[toc]` before first h2 heading


## Artifact Type Templates
##### 🔥 Research Format Quick Reference
| 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             |


### Technical Rundowns
---
**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**:

```markdown
>[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):
- Language support
- Pricing/Licensing
- Security & Deployment (cloud, on-premise, package manager)
- Market share / GitHub stars / rate of adoption
- API flexibility / availability
- Computational requirements
- Integration capabilities


### Technical Surveys
---
**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**:

```markdown
>[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]
```

### Book Summaries
---
**Format**:
```markdown
### [Book Title]

**Author**: [Name]