agentsclimarketplace

Notion operating system

Skill frankxai/starlight-agent-skills/skills/substrate/notion-operating-system

Portable Starlight substrate skills for agent runtimes, SIS, ACOS, and cross-agent workflow activation.

Install
npx -y skills add frankxai/starlight-agent-skills --skill notion-operating-system

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Design safe, private-first Notion operating systems, estate audits, parallel rebuilds, template systems, and public mirrors. Use when asked to map a Notion workspace, clean or restructure Notion, create business/personal Notion dashboards, build reusable Notion templates, or turn private Notion content into sanitized public docs. Portable and brand-neutral. Trigger phrases: map my Notion, Notion estate audit, restructure Notion, Notion operating system, Notion dashboard, Notion template system, publish Notion docs.

SKILL.md

3.2 KB, 553 tokens by cl100k_base, as published. Nobody here has run it

Notion Operating System

Policy

Start read-only. Search, fetch, team lookup, and aggregate data-source queries are safe for audits. Do not create, update, move, duplicate, publish, apply templates to, create databases/views, alter schemas, or delete Notion content until the user approves exact targets and changes in the current thread.

Workflow

  1. Audit current state with search/fetch before designing a rebuild.
  2. Create an estate map with source citations, privacy class, health signal, database health, and migration action. When a local compiler exists, generate deterministic CSV, Markdown, summary JSON, and red-team artifacts from inventory-level evidence.
  3. Identify existing canonical systems before designing anything new. Preserve hubs/databases with clear source-of-truth rules, active operating views, public/private staging, source registries, quality gates, and metrics loops.
  4. Design a parallel v2 hub instead of mutating the old workspace in place.
  5. Use a small set of canonical databases: Projects, Areas, Actions, Knowledge, People/CRM, Content, Assets/Templates, Systems/Agents, Decisions/Policies, and Archive.
  6. Add advanced modules only when justified: Source Registry, Quality Checklists, Public Staging, Repurpose Queue, Metrics Loop, and Migration Control.
  7. Make templates sparse, useful, and reviewable; every template needs a clear job and privacy class.
  8. Publish only curated mirrors or sanitized templates by default.
  9. Keep an approval log for every write action.

Estate Map Fields

Use references/notion-os-patterns.md for schema and patterns. At minimum capture: title, URL/ID, object type, domain, current role, privacy class, health signal, migration action, confidence, and notes.

Default Architecture

Use a parallel parent page named Notion OS v2 Draft unless the user gives a specific name. Build dashboards as operating views, not decorative homepages.

Public Boundary

Classify content as private-only, internal, shareable, public-candidate, or public-approved. Public outputs must be sanitized and approved before publication.

Output Contract

Return:

  • Estate summary.
  • Sitemap or database map.
  • Duplicate/stale clusters.
  • Database health and aggregate counts where safe.
  • V2 architecture.
  • Template plan.
  • Public/private matrix.
  • Migration waves and approval gates.
  • Red-team findings and low-confidence rows.

Built on SIP — Starlight Intelligence Protocol Substrate: starlightintelligence.org/protocol v1.1.0 Layers used: [file-contract, attestation, sovereignty] Vertical: starlight-agent-skills · portable capability layer

Gives 0 of the 12 instructions most note taking skills give in 553 tokens

Counted across 686 of the 876 authors here whose files we hold, read 2026-08-07

  • include a visual element on every slidein 44 of 686, across 13 files
  • use wikilinks for internal vault linksin 36 of 686, across 12 files
  • commit to a single visual motif across every slidein 34 of 686, across 9 files
  • use subagents to visually inspect rendered slidesin 31 of 686, across 7 files
  • read pptxgenjs guide before creating presentations from scratchin 30 of 686, across 6 files
  • keep 0.5 inch minimum marginsin 30 of 686, across 7 files
  • re-verify affected slides after every fixin 27 of 686, across 5 files
  • run content QA checks before declaring successin 26 of 686, across 3 files
  • Use Markdown links for external URLs onlyin 26 of 686, across 11 files
  • pick a bold topic specific color palettein 24 of 686, across 2 files
  • read editing guide before editing existing presentationsin 23 of 686, across 1 file
  • use one dominant color across all slidesin 23 of 686, across 1 file

Said here and by no other author read

  • Do not mutate content before user approval
  • Audit the current state before designing
  • Create an estate map with citations
  • Identify existing canonical systems
  • Design a parallel v2 hub
  • Use canonical databases

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.