← All sessionsHomeSearch
Outskill GenAI Learning Portal·Glossary & Support·

Beginner Glossary (30 terms) + I'm Stuck Guides (23)

Outskill (portal authors) The learner-support layer: every glossary term ships definition/why-it-matters/example; every stuck-guide ships question/short answer/steps/success test/troubleshooting prompt

Session map

VOCABULARYWORKING DISCIPLINERECOVERY30 termsdefinition · why · exampleCost & contextsmallest complete packetRequirements & reusenumber, audit, promoteStart smallmanual before automatedSafety boundariessix-verb auditBuild recoveryroot cause, minimal patchn8n diagnosticsfirst broken assumption
VocabularyWorking disciplineRecovery
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — vocabulary flow into working discipline, then into recovery. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. Thirty glossary terms in a fixed teachable shape (definition, why it matters, concrete example, source day) spanning AI foundations, prompting, knowledge systems, Claude workspace, agents, integrations, automation, and software delivery.
  2. Twenty-three 'I'm Stuck' guides, each a complete recovery unit: the confusion in the learner's own words, a short honest answer, numbered steps, a success test, and a copyable troubleshooting prompt.
  3. The guides encode the portal's judgment layer: smallest complete context packet, numbered-requirements compliance audits, template-vs-instruction-vs-Project-vs-Skill taxonomy, data classification before upload, and draft-only support automation.
  4. The diagnostic prompts are the treasure: 'do not solve the task yet', 'do not redesign the workflow', 'do not make changes yet' — every one forces diagnosis before action, which is the single most transferable AI-collaboration habit in the corpus.
  5. This part is the portal's own version of what a KB is for: the answer you need at the moment you're stuck, structured for retrieval rather than reading order.

The concepts

01

The glossary: 30 terms, each with a why and an example

Every term answers three questions: what is it, why does it matter to you, and what does it look like in practice.

The thirty terms cover the course's whole vocabulary: foundations (LLM, model, token, embedding, self-attention), prompting and context (prompt, context window, context engineering, system instructions), quality (hallucination), knowledge systems (RAG), the Claude workspace (Project, Project instructions, knowledge file, artifact, Skill), assistants and agents (bot, custom assistant, AI agent, AI employee), integrations and security (API, API key, credential/OAuth), automation (workflow, n8n, node, trigger, JSON), and delivery (vibe coding, GitHub/version control).

The definitions are precision-tooled for beginners: 'the model is not the whole chat application'; 'anyone with the key may be able to use the associated service and spend its allowance'; 'a bot may retain instructions or knowledge but does not automatically become autonomous'; ''AI employee' is a business framing — the useful part is the operating design, not the label.'

Worked example · from the session

The API-key entry in full shape: definition (secret credential authorizing API calls), why (whoever holds it can spend your allowance; never in prompts, screenshots or repos), example (store the model key in n8n Credentials, not a workflow text field).

Why it matters

This is the KB's ready-made shared vocabulary across all seven courses — definitions quotable as-is when any session record needs a term anchored.

People get this wrong

A glossary is reference filler.

This one is the course's conceptual spine in retrievable form — each entry carries the why and an example, which makes it teaching, not lookup.

Go deeper

In one line: 30 terms × (category, definition, why-it-matters, example, source day) covering foundations, prompting/context, quality, knowledge systems, Claude workspace, agents/assistants, integrations/security, automation, and software delivery. All durable-class content — the most decay-resistant part of the portal.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Bot vs agent vs AI employee, per the glossary?

Bot: responds within configured behavior when invoked. Agent: selects steps, uses tools, observes, continues within limits. AI employee: business framing for a scoped agent system — the operating design matters, not the label.

What's the glossary's warning about the term 'model'?

The model is not the whole application — Claude/ChatGPT/Gemini are products that may swap models underneath, differing in speed, cost, context, and tool access.

02

Cost and context discipline: smallest complete packet, planned spend

Yes, tokens still matter on a paid plan — and the fix for a bloated chat is the smallest complete evidence set, not more context.

The paid-plan guide is honest about subscriptions: long inputs, long outputs, large files, retries and parallel agents all consume capacity regardless of plan wrapper. The disciplines: decide whether the task needs the full source or selected sections, ask for a plan before a long run, limit output length and alternatives, test one item before scaling, and reuse a concise approved summary instead of re-supplying the same large material.

The context guide completes it: use the smallest complete evidence set for the CURRENT task; separate facts, examples, constraints and open questions; keep a short approved project brief and decision log; start a fresh chat when the conversation holds unrelated work. The troubleshooting prompt makes the model sort supplied context into required / optional / unrelated / missing — 'do not solve the task yet.'

Worked example · from the session

The pre-flight prompt: 'identify the parts likely to consume the most context or output; propose a smaller test run… do not begin the full task until I approve the plan' — spend approval as a conversational gate.

Why it matters

This is the portal's version of the KB's own budget discipline — and 'smallest complete context packet' is the best five-word statement of context engineering anywhere in the corpus.

People get this wrong

More context always helps the model.

'Simply adding more information does not guarantee a better answer' — organized, relevant, minimal context beats volume.

Go deeper

In one line: Cost: capacity is consumed by inputs, outputs, files, retries, parallel agents on any plan — plan runs, cap outputs, test small, reuse summaries. Context: smallest complete evidence set, labeled and separated; fresh chats for unrelated work; a decision log instead of conversation archaeology.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

A long-running chat starts giving worse answers. The guide's diagnosis?

Context bloat — unrelated history competing with the current task. Fix: fresh chat seeded with the approved summary, not more explanation piled on.

What replaces re-pasting the same big document every session?

A concise approved summary, reused — the compression is done once and becomes the working context.

03

Compliance audits and the template / instruction / Project / Skill taxonomy

When the model drifts from your requirements, number them and demand a mismatch audit; when a prompt works, know which of four containers it belongs in.

The drift fix: state the goal in one sentence, separate background from requirements, NUMBER every non-negotiable, specify the output structure, state what must not be added, and require a final compliance check. The audit prompt closes the loop: 'list every mismatch first, then return a corrected answer that introduces no additional scope.'

The reuse taxonomy settles a real beginner confusion: a template is a fill-in-the-blanks shape; an instruction is a behavior rule; a Project is a workspace grouping one job's chats, files and rules; a Skill is a reusable method that should work across jobs. The promotion path: start as instructions inside one Project, package as a Skill only after it proves reusable — and test any template on three different inputs before trusting it.

Worked example · from the session

'I asked for a three-day plan and received seven days' — the guide's cure is not a better adjective but numbered requirements plus a required pre-return compliance check.

Why it matters

The numbered-requirements + audit pattern is the cheapest reliability upgrade available for any prompt, and the four-container taxonomy is the org chart for a personal prompt library.

People get this wrong

Prompt drift means the model is bad at following instructions.

Unnumbered requirements are suggestions. Numbering plus a required audit turns them into a checkable contract.

Go deeper

In one line: Drift control: one-sentence goal, numbered non-negotiables, output structure, exclusions, required compliance check, mismatch-first audit on failure. Reuse containers: template (shape) / instruction (rule) / Project (workspace) / Skill (cross-job method); promote only after proven reuse; test on three inputs.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

The output added scope you never asked for. What was missing from the prompt?

The exclusions ('what must not be added') and the required final compliance check against numbered requirements.

When does a working prompt earn Skill status?

When the same method proves useful across several jobs — before that it lives as Project instructions. Premature packaging is the named anti-pattern.

04

Safety boundaries: no-invention gates, data classification, draft-only support

Approval is not automatic unless the workflow is designed that way — so design it: evidence rules in, drafts out, a person at every external action.

Three guides form one safety doctrine. Hallucination control: identify which claims require evidence, supply approved sources, require flagging of missing facts instead of gap-filling, save output as a draft, and verify before anything publishes. Private data: classify before upload, redact or use fictional data while learning, check retention/training/sharing/deletion controls, smallest permissions, human approval on high-impact actions, and the responsible privacy owner involved in regulated settings.

Support automation gets its own boundary map: automate intake, classification, routing, summarization and drafting FIRST; substantive replies stay behind human review until policy, quality, escalation and monitoring are proven; auto-send only a narrow approved low-risk acknowledgement, if authorized at all. The audit prompt hunts every point that 'can send, promise, refund, delete, disclose data, or hide an urgent case.'

Worked example · from the session

The pre-publish review prompt returns three buckets — verified claims with sources, unsupported claims to remove or confirm, questions for the human reviewer — 'do not publish, send, or rewrite until I approve.'

Why it matters

This is the portal's ethics engine stated as procedure, and the six-verb audit (send/promise/refund/delete/disclose/hide) is a reusable risk checklist for any automation.

People get this wrong

The AI will ask permission before doing something consequential.

'Approval is not automatic unless the workflow is designed that way' — the checkpoint exists only where you built it.

Approval is not automatic unless the workflow is designed that way.
Go deeper

In one line: No-invention gate: evidence-required claims, approved sources, flag-don't-fill, draft state, human verification. Data: classify → minimize → check controls → least permission → approval on impact. Support: automate intake/classify/route/summarize/draft; human review for substance; six-verb risk audit (send, promise, refund, delete, disclose, hide-urgent).

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What are the six verbs the support-automation audit hunts for?

Send, promise, refund, delete, disclose data, and hide an urgent case — every point capable of one gets converted to a draft or approval step.

What's the first move before uploading any business document?

Classify it (public/internal/confidential/regulated/prohibited) and strip what the task doesn't need — safety is decided before the upload, not after.

05

Build recovery: design audits, maintenance discipline, architecture maps, bug reports

'Fix it' makes things worse — the guides replace it with: reproduce, evidence, root cause, smallest patch, verify, rollback.

Five guides cover the life of an AI-built app after the demo. Generic design: give a design system (palette, type scale, spacing, max width) and fix ONE visual dimension at a time — the audit prompt asks a 'senior product designer' for the five highest-impact reasons it looks generic, with one small testable change each. Maintenance: version history, tests, docs, backups, rollback — reproduce a failure before requesting a fix, demand root-cause analysis and a minimal patch, verify in preview, roll back regressions.

Architecture literacy: map frontend/backend/database/files/auth/APIs/secrets/repo/hosting/domain, with provider, owner account, backup path and unresolved risk per layer — 'each one still needs an owner and recovery plan.' Portability: GitHub stores code, but portability also depends on env vars, proprietary services and a clean-environment build test. And the bug-report guide is the master pattern: expected, observed, steps, exact error, last working state, last change — 'do not make changes yet.'

Worked example · from the session

The maintenance prompt's shape: 'Act as a maintenance engineer. Do not rewrite the application… identify the likely root cause, smallest safe patch, tests to run, and rollback plan. Label every assumption.'

Why it matters

These prompts are the difference between owning software and being hostage to it — the exact discipline the trainer's live debugging demonstrated in sessions 16–17, packaged for self-serve.

People get this wrong

AI-built apps are maintained by asking AI to fix them.

They're maintained like all software — history, tests, rollback — with AI as the diagnostician under a smallest-safe-patch rule.

Go deeper

In one line: Design: specific system + one dimension at a time + five-reasons audit. Maintenance: reproduce → evidence → root cause → minimal patch → preview verify → rollback. Architecture: ten-layer map with owner/backup/risk per layer. Portability: clean-environment build test beyond GitHub. Bugs: expected/observed/steps/error/last-working/last-change, no changes until diagnosed.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why is 'make it look better' as bad as 'fix it'?

Both name no target. The guides demand one dimension (or one reproduced symptom) at a time, with an audit or root cause before any change.

What proves an app is actually portable?

A clean build and deployment outside the original builder, from documented instructions plus separately supplied secrets — not merely code sitting in GitHub.

06

n8n diagnostics: one node at a time, credentials first, costs as line items

Test the account connection before the AI logic — most 'broken automations' are the wrong Google account, a missing scope, or an expired credential.

The vocabulary guide de-mystifies: workflow = the whole automation, node = one step, trigger = the starting event — 'software-workflow concepts, not neural-network layers' (a real learner confusion). Credentials doctrine: keys live in the credential manager, attach to compatible nodes, one provider's key is not valid for another's node, and diagnosis runs provider → billing → permissions → expiry → documentation, in that order.

The Gmail/Sheets guide isolates integration failures: confirm the owning account, reconnect, approve only needed scopes, test the trigger ALONE, the draft ALONE, the append ALONE, match exact document/tab/header names, and inspect the first empty or red node — 'find the first broken assumption. Do not redesign the workflow.' Cost estimation separates line items: hosting, executions, model calls, input/output volume, connected services, safety margin — with self-hosting allowed only if you can own updates, backups, secrets and uptime.

Worked example · from the session

The diagnosis prompt refuses the secret and the redesign both: node, operation, expected input, observed input, error — compatibility, permissions, billing, expiry, endpoint, in order.

Why it matters

These four guides are the operations manual the workbook builds assume — and the first-broken-assumption method generalizes to every pipeline, including this KB's.

People get this wrong

An n8n node is like a neuron and the workflow is like a neural network.

They're plumbing, not neurons — one step, one job, one testable input/output. The AI, when present, lives inside individual nodes.

Find the first broken assumption. Do not redesign the workflow.
Go deeper

In one line: Vocabulary: workflow/node/trigger as software concepts. Credentials: manager-stored, node-compatible, diagnosed provider→billing→permissions→expiry→docs. Integration isolation: per-node testing, exact-name matching, first empty/red node. Cost: separate line items with a dated estimate and safety margin; self-host only with full ops ownership.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

A workflow that ran yesterday fails today. First suspect?

Credentials — expired or revoked connections and provider billing, before any prompt or logic change.

What does 'test one node at a time' actually buy?

Localization: the first node with empty or red output names the broken assumption; whole-workflow reruns just re-mix the symptoms.

07

Start with one small build

One recurring task, one tool, one input, one reviewable output — 'do not begin with a multi-agent system.'

The beginner-plan guide is the portal's own priority ordering: pick a task you already understand, define input and output, write a five-line requirements brief, build the MANUAL AI-assisted version first, test on three examples, save the working prompt, and automate only after the manual version is reliable.

The reduction prompt does the scoping for you: 'one user, one input, one output, one tool, three acceptance checks, and what must remain manual — do not add automation or agents yet.' It's the antidote to tool-list paralysis, and it's the same smallest-working-version doctrine the Practice Lab, the roadmap's deterministic-first sequence, and the workbooks all repeat.

Worked example · from the session

Success is defined humbly and completely: 'you complete one repeatable workflow that saves time and can explain every step.'

Why it matters

If one concept from the support layer reaches every beginner, it should be this one — every other guide assumes its discipline.

People get this wrong

Starting small wastes time you could spend building the real system.

The small build IS the real system's first proven component — and the fastest route to knowing what the real system needs.

Choose one recurring task, one tool, one input, and one reviewable output. Do not begin with a multi-agent system.
Go deeper

In one line: Sequence: understood task → input/output defined → five-line brief → manual AI-assisted version → three-example test → saved prompt → automation only after reliability. Scoping prompt: one user/input/output/tool + three acceptance checks + explicit manual remainder.

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What comes before automation, always?

A reliable manual AI-assisted version, tested on three examples, with the working prompt saved. Automation is a promotion, not a starting point.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01The glossary: 30 terms, each with a why and an example30 terms × (category, definition, why-it-matters, example, source day) covering foundations, prompting/cont…

30 terms × (category, definition, why-it-matters, example, source day) covering foundations, prompting/context, quality, knowledge systems, Claude workspace, agents/assistants, integrations/security, automation, and software delivery. All durable-class content — the most decay-resistant part of the portal.

02Cost and context discipline: smallest complete packet, planned spendCost: capacity is consumed by inputs, outputs, files, retries, parallel agents on any plan — plan runs, cap…

Cost: capacity is consumed by inputs, outputs, files, retries, parallel agents on any plan — plan runs, cap outputs, test small, reuse summaries. Context: smallest complete evidence set, labeled and separated; fresh chats for unrelated work; a decision log instead of conversation archaeology.

03Compliance audits and the template / instruction / Project / Skill taxonomyDrift control: one-sentence goal, numbered non-negotiables, output structure, exclusions, required complian…

Drift control: one-sentence goal, numbered non-negotiables, output structure, exclusions, required compliance check, mismatch-first audit on failure. Reuse containers: template (shape) / instruction (rule) / Project (workspace) / Skill (cross-job method); promote only after proven reuse; test on three inputs.

04Safety boundaries: no-invention gates, data classification, draft-only supportNo-invention gate: evidence-required claims, approved sources, flag-don't-fill, draft state, human verifica…

No-invention gate: evidence-required claims, approved sources, flag-don't-fill, draft state, human verification. Data: classify → minimize → check controls → least permission → approval on impact. Support: automate intake/classify/route/summarize/draft; human review for substance; six-verb risk audit (send, promise, refund, delete, disclose, hide-urgent).

05Build recovery: design audits, maintenance discipline, architecture maps, bug reportsDesign: specific system + one dimension at a time + five-reasons audit.

Design: specific system + one dimension at a time + five-reasons audit. Maintenance: reproduce → evidence → root cause → minimal patch → preview verify → rollback. Architecture: ten-layer map with owner/backup/risk per layer. Portability: clean-environment build test beyond GitHub. Bugs: expected/observed/steps/error/last-working/last-change, no changes until diagnosed.

06n8n diagnostics: one node at a time, credentials first, costs as line itemsVocabulary: workflow/node/trigger as software concepts.

Vocabulary: workflow/node/trigger as software concepts. Credentials: manager-stored, node-compatible, diagnosed provider→billing→permissions→expiry→docs. Integration isolation: per-node testing, exact-name matching, first empty/red node. Cost: separate line items with a dated estimate and safety margin; self-host only with full ops ownership.

07Start with one small buildSequence: understood task → input/output defined → five-line brief → manual AI-assisted version → three-exa…

Sequence: understood task → input/output defined → five-line brief → manual AI-assisted version → three-example test → saved prompt → automation only after reliability. Scoping prompt: one user/input/output/tool + three acceptance checks + explicit manual remainder.

Tools referenced

ToolCoverageMomentContext
ClaudeexplainedWorkspace terms defined (Project, instructions, knowledge file, artifact, Skill); chat-vs-memory-vs-Project and Skills-vs-instructions guides
n8nexplainedFive glossary terms plus four dedicated diagnostic guides (vocabulary, credentials, Gmail/Sheets isolation, cost estimation)
GitHubexplainedGlossary entry plus the portability guide (clean-environment build test as the real proof)
Google Workspace (Gmail + Sheets)explainedThe integration-failure guide: owning account, scopes, per-node isolation, exact name matching
ChatGPTmentionedNamed in the paid-plan token guide and tool-selection guide
LovablementionedThe Lovable/Bolt-vs-Claude-Code guide: continue with the tool that fits; export a working version before major changes
Claude CodementionedSame guide's coding-agent side: deeper control, more responsibility

Action items

Resources mentioned

Resources
  • docPre-publish no-invention review prompt
  • docRequirements compliance audit prompt
  • docContext-packet sorting prompt
  • docReproducible bug-report prompt
  • docSupport-automation risk audit prompt (the six verbs)
  • docSmallest-useful-build reduction prompt
  • docAll 23 troubleshooting prompts + 30 glossary entries

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

True on recording day — verify before relying