155 lines
4.3 KiB
Markdown
155 lines
4.3 KiB
Markdown
|
ResearchPrompt
|
|||
|
|
|
|||
|
|
*Research a topic...*
|
|||
|
|
|
|||
|
|
# InfoTechPrimer – ResearchPrompt
|
|||
|
|
|
|||
|
|
Below is a **single, reusable, high-precision research prompt** you can use to *systematically get a grip on any InfoTech topic* before writing an **InfoTechPrimer**.
|
|||
|
|
|
|||
|
|
> **Purpose:**
|
|||
|
|
> Produce a *factually grounded, scope-aware, source-anchored research brief* suitable as the direct input for authoring an InfoTechPrimer.
|
|||
|
|
|
|||
|
|
It is designed to work well with:
|
|||
|
|
|
|||
|
|
* General-purpose LLMs
|
|||
|
|
* Research-oriented agents
|
|||
|
|
* Human-in-the-loop review
|
|||
|
|
|
|||
|
|
The prompt is **topic-agnostic**, but forces rigor, boundaries, and source grounding.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## ResearchPrompt
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
You are conducting foundational research for an InfoTechPrimer.
|
|||
|
|
|
|||
|
|
Topic: <$topic>
|
|||
|
|
|
|||
|
|
The goal is NOT to teach or promote, but to establish a precise, shared understanding
|
|||
|
|
of the topic for experienced IT professionals and AI systems.
|
|||
|
|
|
|||
|
|
Produce a structured research brief that answers the following sections.
|
|||
|
|
Be concise, factual, and source-driven.
|
|||
|
|
Avoid tutorials, opinions, and vendor marketing language.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
1. Canonical Definition
|
|||
|
|
- Provide the most widely accepted definition(s) of the topic.
|
|||
|
|
- If multiple definitions exist, explain why and in which contexts they differ.
|
|||
|
|
- Prefer definitions from standards bodies, original designers, or official specifications.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
2. Domain Context and Classification
|
|||
|
|
- Which technical domain(s) does this topic belong to?
|
|||
|
|
(e.g. systems programming, distributed systems, security, AI, quantum computing)
|
|||
|
|
- What *type* of thing is it?
|
|||
|
|
(e.g. protocol, framework, architectural style, API standard, SDK, language, library)
|
|||
|
|
- At which abstraction level does it primarily operate?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
3. Historical Origin and Motivation
|
|||
|
|
- Who introduced it and when?
|
|||
|
|
- What concrete problem(s) was it created to solve?
|
|||
|
|
- What existing approaches did it replace, extend, or formalize?
|
|||
|
|
|
|||
|
|
(Only include history that explains intent or constraints.)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
4. Core Concepts and Invariants
|
|||
|
|
- List the essential concepts without which the topic would not make sense.
|
|||
|
|
- For each concept, explain its role in one or two sentences.
|
|||
|
|
- Identify any invariants, guarantees, or formal assumptions.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
5. Scope Boundaries
|
|||
|
|
- Clearly state what the topic explicitly covers.
|
|||
|
|
- Clearly state what it explicitly does NOT cover.
|
|||
|
|
- Identify common misconceptions or misuses.
|
|||
|
|
|
|||
|
|
This section should prevent overextension by AI systems.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
6. Practical Implications (Non-Tutorial)
|
|||
|
|
- What design or architectural consequences follow from using this?
|
|||
|
|
- What tradeoffs are inherent?
|
|||
|
|
- What kinds of systems typically depend on it?
|
|||
|
|
|
|||
|
|
Do NOT include step-by-step usage.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
7. Relationship to Adjacent Concepts
|
|||
|
|
- List closely related standards, technologies, or terms.
|
|||
|
|
- For each, explain the relationship (complementary, layered on top, alternative, predecessor).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
8. Authoritative Sources
|
|||
|
|
- List primary, authoritative references:
|
|||
|
|
- Standards (RFCs, ISO, W3C, IEEE, etc.)
|
|||
|
|
- Official specifications or documentation
|
|||
|
|
- Foundational papers
|
|||
|
|
- Include direct links.
|
|||
|
|
- Clearly distinguish primary sources from secondary explanations.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
9. Stability and Maturity Assessment
|
|||
|
|
- Is this topic considered stable, evolving, or experimental?
|
|||
|
|
- Are there competing standards or dominant implementations?
|
|||
|
|
- Is backward compatibility a concern?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
10. Notes for Primer Authoring
|
|||
|
|
- Highlight points that MUST be stated clearly in a primer.
|
|||
|
|
- Highlight areas where ambiguity must be avoided.
|
|||
|
|
- Identify terminology that must be used consistently.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Constraints:
|
|||
|
|
- Use precise, declarative language.
|
|||
|
|
- No metaphors or analogies.
|
|||
|
|
- No marketing or opinionated statements.
|
|||
|
|
- Assume a technically literate audience.
|
|||
|
|
- Prefer explicit statements over implied assumptions.
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Why This Prompt Works Well
|
|||
|
|
|
|||
|
|
This prompt is intentionally shaped to:
|
|||
|
|
|
|||
|
|
* **Force scope clarity** (critical for AI agents)
|
|||
|
|
* **Surface invariants and constraints**
|
|||
|
|
* **Separate definition from implementation**
|
|||
|
|
* **Anchor everything in primary sources**
|
|||
|
|
* **Produce output that maps 1:1 to your Primer Authoring Rules**
|
|||
|
|
|
|||
|
|
You can think of it as:
|
|||
|
|
|
|||
|
|
> *A pre-primer that de-risks the primer.*
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## How You’ll Likely Use It in Practice
|
|||
|
|
|
|||
|
|
Typical flow:
|
|||
|
|
|
|||
|
|
1. Run this prompt on a topic (e.g. CUDA, OAuth 2.0, OpenQASM)
|
|||
|
|
2. Review and correct factual issues
|
|||
|
|
3. Collapse the research brief into the Primer schema
|
|||
|
|
4. Apply brand tone + structural rules
|
|||
|
|
5. Publish as an InfoTechPrimer
|
|||
|
|
|
|||
|
|
xxx
|