Golden examples are canonical classification patterns that the AI assistant uses to prevent taxonomy drift. New classifications should imitate these examples before creating new tags. Each example shows the correct collection, tags, and note for a common link type — not as a rigid template to copy verbatim, but as a stable reference point that constrains how the taxonomy grows. When a new entry resembles an existing example, the tag pattern should match before any new values are proposed.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.
How to Use These Examples
When classifying a new entry, the assistant checks whether it resembles one of the three examples below. If it does, it should match the established tag pattern as closely as the content allows before proposing any new tag values. This prevents the taxonomy from growing through convenience additions that duplicate existing signals in slightly different words. If no example fits — the entry type is genuinely different from all three — the assistant reports the gap to the operator and proposes a minimal new pattern. The new pattern must be approved by the operator before it is treated as canonical. It should then be recorded alongside these examples to serve as the reference for future entries of the same type. The rule is: imitate first, propose only when imitation genuinely fails.Example 1: GitHub Framework With Strong Idea But Poor Implementation Fit
This pattern applies when a project has a strong core concept — a structured approach, a useful architecture, a well-reasoned design — but the technology stack, ecosystem requirements, or setup friction make direct adoption impractical for the operator right now. Collection:20_LIBRARY
Tags:
status/core-good together with next/extract to signal that the idea should be preserved and pulled out, but the tool itself should not be adopted. The risk/ecosystem-mismatch tag makes the reason for poor fit explicit and queryable. fit/dev-heavy records the adoption cost. The combination of these four tags — status/core-good, risk/ecosystem-mismatch, fit/dev-heavy, next/extract — forms the canonical signal for “valuable concept, wrong tool for us right now.”
Example 2: GitHub Guide or Docs
This pattern applies to guides, documentation resources, and educational content where the primary value is reference and learning rather than direct adoption. The content is good and reproducible, but it describes a workflow or pattern the operator may implement in the future rather than something to act on immediately. Collection:20_LIBRARY
Tags:
status/reference together with next/revisit when the content is good but not immediately actionable. truth/verified is appropriate here because the docs and examples are clear and reproducible — the claim can be confirmed by reading and following the material. The scenario/learning tag signals that this entry is relevant when the operator is in a learning context. fit/vscode and fit/ai-assisted record that the workflow is compatible with the operator’s typical environment.
Example 3: Product, Service, or API Directory
This pattern applies to directories, curated lists, and resource aggregators — entries whose value is enabling discovery of other things rather than being directly adoptable themselves. The directory may be well-maintained and widely referenced, but individual entries within it are unverified and must each be evaluated separately. Collection:20_LIBRARY
Tags:
fit/discovery-only to signal that the directory itself is not the adoptable artifact — it is a starting point. Every individual candidate found within the directory must be evaluated against the full decision rules before any adoption or extraction decision is made. fit/account-required and fit/paywall-risk are applied at the directory level to flag that services within it commonly require accounts and may have billing risk. risk/vendor-bias records that the directory’s curation may favor certain vendors. The next/extract tag means: when a concrete workflow need arises, return here to pull specific candidates for individual evaluation.
Creating New Classification Patterns
A new canonical pattern is appropriate when none of the three examples above cover the entry type — when imitating the closest example would require significant tag distortion or would produce a misleading classification. Before proposing a new pattern, the assistant should:Confirm the gap
Verify that none of the three existing examples can be adapted to fit the new entry type without distorting the tag meaning. A slight mismatch in domain or stack does not justify a new pattern — reuse the closest example and adjust only the descriptive tags.
Propose the minimum viable pattern
Identify the smallest set of new or adjusted tags that accurately classifies the entry type. Do not propose new tag families or new tag values unless the gap genuinely cannot be filled with existing vocabulary.
Report to the operator
Present the proposed new pattern, explain why existing examples do not cover it, and wait for operator approval before using it.
New classification patterns must be approved before they are treated as canonical. An approved pattern entered into the golden examples set becomes a governance artifact — it constrains future classification the same way these three examples do.