explaingit

refactoringhq/portent

20CSSAudience · writerComplexity · 1/5ActiveSetup · easy

TLDR

A written specification for organizing a personal knowledge base with eight item types, two relationship kinds, and a capture to archive lifecycle so notes stay readable by both humans and agents.

Mindmap

mindmap
  root((portent))
    Inputs
      Raw notes
      Existing vaults
      Frontmatter or wikilinks
    Outputs
      Typed knowledge items
      Lifecycle states
      Linked graph
    Use Cases
      Standardize a personal vault
      Make notes agent readable
      Adopt a shared note taxonomy
    Tech Stack
      Markdown
      VitePress
      Tolaria

Things people build with this

USE CASE 1

Adopt the eight Portent types in an Obsidian or similar Markdown vault

USE CASE 2

Tag notes with belongs_to and related_to links to build an agent readable graph

USE CASE 3

Run the captured to organized to archived lifecycle for personal task notes

USE CASE 4

Read the VitePress site to bootstrap a shared note taxonomy for a team

Tech stack

MarkdownVitePressTolaria

Getting it running

Difficulty · easy Time to first run · 30min

It is a specification not software, applying it needs a compatible note tool such as Tolaria.

In plain English

Portent is not a software product so much as a written specification. It proposes a small, opinionated set of rules for how a personal or work knowledge base should be organized, so that both people and AI agents can read it in a consistent way. The idea is that everyone who keeps notes ends up inventing their own folder structure and tag system, and Portent offers a shared starting point instead of that one-off design work. The spec is built on three ideas. The first is types. Every item in a Portent knowledge base belongs to one of eight default types, split into two groups. PORT types cover things you can act on: Projects, Operations, Responsibilities, and Tasks. ENTP types cover things you record but do not act on directly: Events, Notes, Topics, and People. The second idea is relationships, and the spec keeps these to two defaults: belongs_to for ownership and composition, and related_to for looser links. The third idea is a lifecycle: an item is first captured quickly so it is not lost, then organized by giving it a type and relationships, then archived when it is no longer useful. For a system to count as Portent-compatible, it needs three things: a way to mark each item with one Portent type, a way to record its lifecycle state, and a way to link items together, for example through Markdown wikilinks or frontmatter fields. The spec is intended to be portable across file-based note systems, note-taking apps, documentation tools, and agent-readable vaults, with a tool called Tolaria being the easiest place to apply it. The repository also contains a documentation website built with VitePress that lives in the site folder. The project has 20 stars and the language listed by GitHub is CSS, reflecting the docs site rather than any application code.

Copy-paste prompts

Prompt 1
Convert my existing Obsidian vault frontmatter to the Portent type and lifecycle scheme
Prompt 2
Generate a VitePress page that lists all eight Portent types with examples drawn from my notes
Prompt 3
Write a script that scans Markdown files and reports which ones are missing a Portent type
Prompt 4
Map my current Notion database properties onto the PORT and ENTP type groups
Prompt 5
Add a daily review query that surfaces items still in the captured state for more than seven days
Open on GitHub → Explain another repo

Generated 2026-05-22 · Model: sonnet-4-6 · Verify against the repo before relying on details.