Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/decision-rain-library-project/llms.txt

Use this file to discover all available pages before exploring further.

Decision Rain Library Project is designed for everyday use. The flow is intentionally short — find a signal, let the assistant research it, then decide what to do with it. The loop repeats every time you encounter something worth saving. You do not need to know why a signal matters when you capture it; the library is built to preserve the trace first and turn it into a decision later.

The Six-Step Daily Loop

1

Find a signal

A GitHub repo, tool, article, service, guide, idea, or research spark catches your attention. You do not need to have an opinion about it yet — noticing it is enough.
2

Save to 00_INBOX

Give the link to your AI assistant. It saves the original URL to 00_INBOX first, with status/pending-review and one next/* tag, to preserve the trace before any analysis begins.
3

Assistant researches

The assistant reads the page, repo, docs, or available sources and gathers both official and community evidence. It does not skip this step, and it does not classify from memory or title alone.
4

Assistant proposes

The assistant proposes classification, tags, Verdict, Next, and uncertainty. This is a proposal only — not a decision. The entry remains in 00_INBOX with status/pending-review until you act.
5

You validate

You read the proposal, correct anything wrong, and decide whether to approve, reject, or request more analysis. Approval is an explicit action — silence is not approval, and a clean-looking proposal is not approval.
6

Entry moves

Only after your validation does the assistant update tags and move the entry to 10_REVIEW, 20_LIBRARY, or 90_ARCHIVE. The assistant never promotes or archives without this instruction.

What Counts as a Signal

A signal is anything that may be worth later attention. The library does not require you to know why it matters at capture time — the point is to preserve the trace, then turn it into a decision later. Signals include:
  • GitHub repositories — libraries, tools, reference implementations, research projects, or idea sparks hosted on GitHub
  • Documentation pages — official docs, guides, API references, or specification pages
  • Products or APIs — services you might integrate, automate against, or evaluate for adoption
  • Guides and patterns — workflows, architecture patterns, implementation techniques, or best-practice write-ups
  • Research projects — academic or community research that may inform future decisions
  • Workflow ideas — concepts, integrations, or automations that are not yet fully formed
  • Directories of tools — curated lists, awesome-lists, or catalogs that are useful for discovery
  • Small sparks — fragments, quotes, or links that do not fit neatly into any category but may become useful later
No category is too small. If it caught your attention, the library can hold it until you are ready to decide.

Separating Signal, Analysis, and Decision

The library works because it keeps three levels distinct. Collapsing them together — treating a saved link as a decision, or an AI analysis as validation — undermines the entire system.
  • Signal: the item caught attention. Something about it was worth preserving.
  • Analysis: the assistant explains what it is, what evidence exists, and what is missing. It may recommend a course of action. That recommendation is a proposal.
  • Decision: you validate what to do with it. Only operator action converts a proposal into a canonical library entry.
Saving a link is not a decision. Analysis is not validation. A clean-looking proposal is not validation. Until you explicitly approve the proposal, the entry remains pending.

Evidence the Assistant Uses

Before proposing classification or a verdict, the assistant gathers evidence from two distinct sources. Both matter; neither replaces the other. Official evidence includes docs, README, maintainer notes, release notes, pricing pages, source code, examples, and tests. This describes how the project is intended to work. Community evidence includes issues, discussions, user reports, forums, Hacker News and Reddit signals when relevant, adoption signals, breakage reports, and pricing and setup complaints. This reveals how the project behaves in practice.
Official evidence describes intended behavior; community evidence reveals operational friction. A useful decision note keeps them separate — noting where official claims and community experience diverge is often the most decision-relevant part of the entry.

Build docs developers (and LLMs) love