Use a ready-made stack
Choose this path when you want a recommended setup for a common goal without assembling the run manually.
Prompt library
Copy/paste prompt assets for controlled AI work.
Choose how to start
Start with a recommended stack for a common goal, or build your own run by choosing the evidence mode, workflow, and optional gates yourself.
Build your own run
Choose this path when you want to select the evidence mode, task workflow, and optional review layers yourself.
On this page
Ready-made stacks
Choose a stack when you want a recommended setup for a common goal and do not want to assemble the run manually.
Daily work — files only
Use for day-to-day work when the answer must stay inside the files you provide, with no external lookup.
Daily work — web-verified
Use for day-to-day work when the task depends on current or public facts that must be checked and cited.
Developer architecture boundary review stack
Use when the task is to classify the architecture, inspect layering and dependency direction, and propose minimal structural remediation.
Prompt files (7) Hide prompt files
Standards-backed implementation review stack
Use when code or configuration changes must be checked against official framework, library, runtime, or platform guidance.
Prompt files (8) Hide prompt files
-
System
facts-only-authoritative-sources-required.system.txt -
System
web-verification-and-citations.system.txt -
System
standards-backed-implementation-review.system.txt -
User
standards-backed-implementation-review.user.txt -
Component
deep-search.user.txt -
Component
deep-scan.user.txt -
System
chain-of-verification.system.txt -
System
confidence-score.system.txt
Evidence-gated technical writing stack
Use when drafting technical content that must control claims, terminology, and evidence quality before publication.
Scholarly review & synthesis stack
Use when the task is a literature-based scholarly review or cross-source evidence synthesis.
Prompt files (3) Hide prompt files
Scholarly comparison & gap-mapping stack
Use when the task is to compare sources, identify disagreement, and map evidence gaps.
Prompt files (3) Hide prompt files
Scholarly bibliography & evidence-table stack
Use when the task is to produce source-by-source annotations or a structured evidence table.
Prompt files (3) Hide prompt files
Build your own run
Use this path when you want to assemble the run yourself. Start by choosing an evidence mode, then add either a task workflow or a scholarly workflow, and only then add optional review gates, output modes, or defaults & output modifiers.
Evidence modes
Facts-only: Artifacts-only (no external sources)
Use when the run must stay strictly inside user-provided artifacts with no external lookup.
Facts-only: Authoritative sources required (citations required)
Use when claims must be supported by citation-grade external sources rather than unsupported recall.
Web Verification & Citations Policy
Add live browsing, retrieval, and citation output requirements for current or public facts.
Task workflows
Architecture Boundary Review
Use for architecture classification, layering and boundary analysis, and minimal structural remediation.
Standards-Backed Implementation Review
Use for source-backed review of code or configuration changes against official framework, library, runtime, or platform guidance.
Evidence-Gated Technical Writing
Use for publishable technical writing where non-trivial claims must be checked before output.
Scholarly workflows
Literature review
Use when you need a focused scholarly review grounded in inspected sources.
Evidence synthesis
Use when you need themes, patterns, or positions synthesized across inspected sources.
Source comparison
Use when you need agreements, disagreements, and meaningful differences compared across inspected sources.
Gap mapping
Use when you need to identify where the current evidence is thin, missing, inconsistent, or underexplored.
Annotated bibliography
Use when you need one annotated entry per inspected source.
Evidence table
Use when you need a structured evidence row for each inspected source or unit of analysis.
Review / enforcement gates
Chain-of-Verification
Add a structured self-check loop before final output.
Semantic Accuracy Gate (Claims + Terminology)
Add a claim and terminology check to suppress overstatement and wording drift.
Scholarly Evidence Gate
Add a scholarly evidence boundary when claims must stay inside inspected scholarly sources and make disagreement, limitations, and source quality visible.
Output modes
Evidence-Gated Academic Mode (EGAM)
Use when the output must be written in a formal academic register with authoritative citations and fail-closed behavior.
Defaults & output modifiers
Objective Technical Baseline Rules (No Simulation)
Default operating rules for objective, non-simulative technical responses.
Read policy
Prompt files (2) Hide prompt files
Minimal non-speculation baseline
Lightweight default that suppresses speculation without a full gate stack.
Prompt files (1) Hide prompt files
Confidence score (0–100)
Append a numeric confidence line to standardize uncertainty reporting.
Optional components
Use components only after you already chose a stack or built a run.
They are small add-ons for one extra execution behavior, not a replacement for the main workflow.
Browse the components catalog
Open the full catalog of drop-in components you can attach to a runner.
When to use components
Add a component only when the base stack or workflow is already correct and you need one extra constraint such as deep read, deep scan, or anti-auto-agreement.
- Use 1–2 components max per run to reduce instruction collisions.
- Use tool-dependent components only in runtimes that support the required tools.
Usage rules
Usage rules (show) Usage rules (hide)
- Pick one primary path: either start with a ready-made stack or build the run yourself.
- Choose one evidence mode first before adding workflows, gates, or defaults.
- System templates (`.system.txt`) define higher-authority rules such as evidence boundaries, output constraints, and fallback behavior.
- User templates (`.user.txt`) are runnable task or workflow templates.
- Components are optional add-ons for one extra behavior and should be used sparingly.
- Keep mappings explicit across policies, prompt assets, and procedures to prevent drift.