Para method
Organize notes, files, or an Obsidian vault with the PARA method (Projects, Areas, Resources, Archives). Use when the user asks to structure or restructure a knowledge base, vault, folder tree, or cloud drive; decide where a note or document belongs; separate active work from reference material; or clean up an overgrown collection by actionability.From its SKILL.md
npx -y skills add Jylhis/skills --skill para-methodAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 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.
SKILL.md
3.9 KB, 775 tokens by cl100k_base, as published. Nobody here has run it
PARA method
Organize information into four top-level buckets sorted by actionability, not by subject. Method by Tiago Forte (Forte Labs); this skill is an original summary for applying it with an agent.
The four categories
- Projects: short-term efforts with a defined outcome and an end state. "Ship the Q3 report", "renovate the bathroom". A project can be finished.
- Areas: ongoing responsibilities with a standard to maintain and no end date. "Health", "finances", "team hiring". An area is never done.
- Resources: topics of ongoing interest collected for future use. "Coffee", "typography", "Rust". No responsibility attached.
- Archives: inactive items from the other three. Completed or abandoned projects, areas no longer maintained, interests gone cold.
The same four buckets work in any tool: folder trees, Obsidian vaults, note apps, email, cloud drives. Mirror the structure across tools rather than inventing a different scheme per tool.
Filing procedure
For each item, ask in order:
- Does it advance a specific active project? File under that project.
- Does it belong to an ongoing responsibility? File under that area.
- Is it interesting enough to want again later? File under a resource topic.
- Otherwise archive it. Archiving is cheap and reversible; deleting and elaborate taxonomies are not.
Two consequences worth stating to the user:
- Subject folders ("Psychology", "Business") are an anti-pattern here. The question is never "what is this about" but "what can I act on".
- The projects list doubles as the workload inventory. If a goal has no project, it is not being worked on; if an area keeps generating tasks, break a project out of it so completions stay visible.
Lifecycle
Items flow toward Archives:
- Project completed or dropped: move the whole project folder to Archives.
- Area handed off or lapsed: archive it.
- Resource topic gone stale: archive it.
- The reverse flow is normal too: pull an archived project back when it reactivates, or promote a resource to a project when interest becomes a commitment.
Suggest a light periodic review (weekly or monthly): scan the projects list for anything finished or stalled, and file the inbox backlog using the procedure above. PARA tolerates mess between reviews; it only needs the four boundaries kept honest.
Restructuring an existing collection
When asked to convert an overgrown vault or folder tree:
- Inventory the current top level and list active projects with the user. The projects list comes from the user, not from the folders.
- Create the four top-level folders (prefix them
1 Projects,2 Areas,3 Resources,4 Archiveswhen sort order matters). - Move obvious matches in bulk; file stragglers with the four questions. When in doubt, archive rather than agonize.
- Do not rename or reorganize inside moved folders in the same pass. One structural change at a time keeps the move reviewable.
In Obsidian, folders are the simplest mapping; the obsidian-markdown skill covers using properties or tags instead when the user prefers flat structure. A PARA vault pairs well with the llm-wiki skill: the wiki typically lives inside a Resource or Area folder.
Verification
After a restructure: every top-level item sits in one of the four buckets, each project folder names an outcome that can finish, and nothing was deleted (archives hold the doubtful cases).
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most note taking skills give in 775 tokens
Counted across 632 of the 857 authors here whose files we hold, read 2026-09-06
- Use standard Markdown links for external URLsin 16 of 632, across 8 files
- Use wikilinks for internal vault connectionsin 15 of 632, across 7 files
- Embed content using the exclamation mark prefixin 14 of 632, across 6 files
- Ask for clarification if the user request is ambiguousin 13 of 632
- Add frontmatter properties at the top of the filein 12 of 632, across 4 files
- Verify note renders correctly in reading viewin 12 of 632, across 4 files
- Include a visual element on every slidein 11 of 632, across 5 files
- Left-align body text and listsin 11 of 632, across 5 files
- Maintain 0.5 inch minimum marginsin 11 of 632, across 5 files
- Wrap formulas containing double quotes in single quotesin 11 of 632, across 5 files
- Repeat one distinctive visual motif across all slidesin 10 of 632, across 4 files
- Use 36pt or larger for slide titlesin 10 of 632, across 4 files
Said here and by no other author read
- Sort items by actionability not by subject
- Create four top-level folders for Projects Areas Resources and Archives
- File items based on the four-step filing procedure
- Inventory current top level and active projects with user
- Move obvious matches in bulk
- Archive items when in doubt
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.