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.

Every evaluated entry in Decision Rain Library Project uses a compact note format. The format is designed for Raindrop’s excerpt display, which may truncate long notes — so the most critical fields (Verdict and Next) always appear near the top. The note is not a free-form comment or a general description of the link. It is a structured decision record that captures the reasoning behind the classification so it can be retrieved, audited, and acted on later.

​
The Anti-Truncation Rule

Raindrop may truncate long excerpts in its card and list views. If critical information appears at the bottom of a long note, it will be hidden. Verdict and Next must therefore always appear within the first three lines of the note — before Claim, Evidence, Authority, Truth, or StackFit. This is a hard constraint, not a style preference. A note where the Verdict is buried after a paragraph of evidence is a broken note — it defeats the purpose of having a decision library.

​
The Compact Template

Use this template for every evaluated entry: 
Cataloged: YYYY-MM-DD
Verdict: practical judgment in one or two sentences.
Next: next action, such as use now, test, extract pattern, watch, reference only, archive.
Claim: what the link appears to provide or prove.
Evidence: what supports the claim, such as README, source code, docs, issues, tests, release activity, community use, pricing, setup reports, or hands-on test.
Authority: what kind of authority supports it; keep official and community evidence separate when both matter.
Truth: verified, plausible, claimed, conflicting, outdated, or unknown.
StackFit: practical judgment of how realistically the operator can get value from the item. Consider value type, operator capability, adoption cost, friction threshold, and decision path. Mention whether the item is for direct use, test, assisted implementation, workflow integration, idea extraction, reference, discovery, watch, or archive.

​
Field Definitions

The date the entry was created in YYYY-MM-DD format. This field provides an audit trail and helps identify when the evaluation was done relative to the state of the project at that time.
The practical judgment after considering authority, truth, risk, and StackFit. One or two sentences maximum. The Verdict answers the question: given everything known, what should the operator do with this? It must appear on line two of the note, immediately after Cataloged.
The most specific concrete action to take. Maps directly to a next/* tag. The Next field must appear on line three of the note. It must never be omitted from an evaluated entry.
What was actually examined to assess the claim. Evidence sources include: README, source code, docs, issues, tests, release activity, community use, pricing pages, setup reports, or hands-on tests. Keep official and community evidence separate when both apply — they answer different questions and carry different weight.
The kind of authority behind the evidence. Maps directly to one or more authority/* tags. When evidence comes from multiple source types, list them all. This field makes the evidentiary basis of the Verdict explicit and auditable.
The confidence level of the key claim. Maps directly to a truth/* tag. Choose the most accurate value — not the most favorable one. The options are: verified, plausible, claimed, conflicting, outdated, unknown.
A practical judgment of how realistically the operator can get value from the item. Consider: value type, operator capability, adoption cost, friction threshold, and decision path. Mention whether the item is suited for direct use, test, assisted implementation, workflow integration, idea extraction, reference, discovery, watch, or archive. StackFit is not a list of tools — it is a judgment about the realistic path from this item to operator value.
Claim ≠ Evidence ≠ Verdict. The Claim states what the item appears to provide. Evidence states what supports or weakens the Claim. Verdict states the practical judgment after weighing everything. Conflating these three fields produces unreliable decisions and makes the library hard to audit or correct later.

​
Style Rules

Notes must be concise and decision-oriented. Write for later retrieval and decision recall — not for general explanation or documentation of the subject. Avoid essays, background context, and extended descriptions unless a deep dive is explicitly requested by the operator. Every sentence in the note should answer a decision question, not add ambient information. Optimize for the reader who returns to this entry three months later and needs to understand the decision in thirty seconds.

​
Gate Rule

The completed note is a proposal until the operator explicitly validates it. Do not treat a completed note as a canonical library entry. status/pending-review must remain on the entry until the operator confirms the classification, collection placement, and decision. Silence is not confirmation.

​
Example Completed Note

The following is a realistic completed note for a curated API and services directory: 
Cataloged: YYYY-MM-DD
Verdict: useful for capability discovery, not direct adoption.
Next: extract candidates only when a concrete workflow needs them.
Claim: a curated directory lists APIs and services for automation workflows.
Evidence: README and repository metadata show a large maintained catalog, but individual services are not verified.
Authority: vendor-claim plus community signal.
Truth: plausible as a directory, unknown for individual services.
StackFit: discovery-only; each candidate must be evaluated for free tier, setup friction, billing risk, and actual operator use case.
This example demonstrates the anti-truncation rule in action: Verdict and Next appear on lines two and three, making the decision immediately visible even if the note is truncated after the first few lines. It also demonstrates the Claim/Evidence/Verdict separation — the Claim records what the directory purports to be; the Evidence records what was actually examined; the Verdict records the practical conclusion.

Build docs developers (and LLMs) love

Get started for freeTalk to us