notion-doc

Solid

Notion design skill that MUST be used whenever creating documents. When the user asks for a document, report, summary, meeting notes, or review write-up in HTML/Markdown, load this skill first. The content decides the document's structure and outline; this skill only governs the Notion blocks (callouts, toggles, tables, checklists, code, columns, etc.) and visual style.

Data & Documents 83 stars 13 forks Updated 1 weeks ago MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
64
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Creating documents with Notion's design **This skill governs only how the document *looks*.** The outline, sections, and flow are decided by the content and the request — no particular document format (proposal, etc.) is imposed. Instead, every document is rendered with the blocks and design language Notion provides. ## 1. Header area (required) 1. **Page icon**: one emoji matching the document's topic, large, above the title (Notion page icon) 2. **Title**: a short noun phrase 3. **Meta line**: date · author · 1–2 tag pills 4. A thin divider below the meta line ## 2. Notion block dictionary — pick the block that fits the content | Content | Block | |---|---| | Key takeaway, the one line to emphasize | Callout (blue 💡) | | Reference, supplementary info | Callout (gray) | | Done, success, what went well | Callout (green ✅) | | Caution, constraints | Callout (yellow ⚠️) | | Warning, incident, risk | Callout (red 🚨) | | Opening of a long document (4+ h2s) | Table of contents (`toc`) | | Parent document, location context | breadcrumb | | Comparable, listable facts | simple table | | Two chunks that belong side by side | 2-column layout | | Long details or logs that break the flow | `<details>` toggle | | Tasks, progress | checkbox list (done items get strikethrough) | | Code | code block + `class="language-<lang>"` syntax highlighting (required) | | One striking sentence | quote (bold left bar) | | Introducing an external link | bookmark card | | A single call-to-action ...

Details

Author
heyman333
Repository
heyman333/agent-notion-template-docs
Created
1 weeks ago
Last Updated
1 weeks ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

dark-terminal-doc

Use when a single-file HTML technical document should carry a dark developer / terminal aesthetic — monospace type, terminal-green accents, near-black background. Trigger on: "dark terminal doc", "terminal-style HTML", "developer-terminal aesthetic", "make it look like a terminal", "dark developer-facing HTML page", or when the user wants a reference sheet, comparison table, changelog or API cheatsheet rendered in that specific look, or one matching a document already produced in this style. For a document with no stated aesthetic, use the harness design skills instead.

2 Updated today
Tamircohen28
Data & Documents Listed

writing-documents

Write structured technical documents — design-doc, adr, spec, api-contract, architecture, handoff, design-handoff, discovery, test-report, postmortem, proposal, runbook, onboarding, tutorial, how-to, reference, explanation, mulesoft — as Markdown in the repo by default. Use when asked to write or restructure one of those types, including RFCs, ADRs, developer handoffs, API writeups, test summaries, discovery briefs, or MuleSoft project docs. Produce designed HTML or PDF only when asked. Do not use for casual edits to existing markdown, metric-led reports (analytical-document-design), slides (presentation-design), standalone charts or diagrams, restyling a file into HTML unprompted, or Mule markdown refresh when mule-docs is installed.

2 Updated 2 weeks ago
Avinava
Data & Documents Listed

better-documents

Apply communication best practices when generating or reviewing any document, presentation, report, memo, slide deck, proposal, or email. Use this skill when asked to write, create, draft, or generate a document or presentation — apply the principles at generation time, not as an afterthought. Also use when asked to "review my doc," "look at this deck," "does this make sense," "is this clear," "improve this proposal," "check this before I send it," "make this more effective," or any request to evaluate whether a document will land with its audience. Use this skill even when the request seems minor — a "quick look" or a "short memo" is exactly when these principles matter most.

1 Updated yesterday
jackson2w