Course Execution Guide

• Status: Ready
• Purpose: Help a human operator use Claude, Copilot, Codex, or another strong LLM effectively on the course work.

Working Style

Use the repository as the source of truth.

Prefer this evidence order:

1. implementation and tests
2. requirements and requirements breakdown pages
3. ADRs
4. specs and implementation reviews
5. lessons

The AI should not invent machine behavior that the repo does not support.

Recommended AI Roles

Use different model classes for different tasks.

Budget

Use for:

• sidebar and nav edits
• filename cleanup
• repetitive page scaffolding
• simple cross-linking and formatting passes

Examples:

• GPT-5 mini class
• Claude Haiku class
• Copilot Auto for low-risk docs work

Balanced

Use for most course work.

Use for:

• scenario writing
• newcomer walkthroughs
• repo-grounded design explanations
• lesson linking and practical summaries

Examples:

• Claude Sonnet class
• GPT-5.2 or GPT-5.4 mini class
• GPT-5.2-Codex class

Frontier

Use when the AI must synthesize architecture, runtime behavior, and teaching structure at the same time.

Use for:

• architecture packs
• runtime deep dives
• state and sequence reasoning
• major editorial reshaping

Examples:

• Claude Opus class
• GPT-5.4 class
• GPT-5.3-Codex class

Reasoning Effort

Low

Use for:

• scaffolding
• navigation
• renames
• formatting
• straightforward cross-link updates

Medium

Default for:

• most scenario pages
• most course modules
• repo-grounded summaries

High

Use for:

• architecture explanation
• diagram planning
• workflow state reasoning
• async and failure-mode teaching material

Global Prompt Header

Copy this block at the start of every course task prompt:

You are working in C:\Lcn.Workspaces\lcn-wafer-inspection-desktop.

Audience: a newcomer software engineer or automation engineer learning this project.
Goal: turn this repo into a high-quality engineering training course, not just reference docs.
Style: practical, detailed, blog-quality English; clear headings; concrete examples; no fluff.
Ground all claims in the repo docs and code. Do not invent behavior that the current project does not support.
Prefer reusing and linking existing content under docs/lessons, docs/specs, docs/tasks, docs/adrs, docs/implementation, and the source code when helpful.
When a concept is hard to explain in prose, include a small ASCII diagram directly in the Markdown page first.
For diagrams, do not generate binary assets. Instead, produce a Draw.io-friendly diagram brief: title, purpose, nodes, edges, grouping, caption, and destination file path.
If you edit docs, keep VitePress navigation coherent and make sure npm run docs:build passes.

Prompting Rules

When assigning a task to an AI tool:

• tell it exactly which files to read first
• name the files it is allowed to touch
• name the files it must not rewrite broadly
• ask for concrete deliverables, not “improve docs”
• ask it to verify links and VitePress build

Review Checklist

After any AI-generated course content, check:

• does it stay grounded in the actual app?
• does it explain trade-offs instead of only praising the design?
• does it cite the right lessons rather than re-teaching everything?
• does it use a small ASCII diagram when the structure or flow is easier to see than read?
• does the diagram brief feel buildable in Draw.io?
• does the page help a newcomer know what to do next?

Common Failure Modes

Watch for these problems:

• generic textbook prose
• architecture claims not supported by the code
• too many theory digressions
• pages that describe everything but teach nothing
• pages that obviously need a visual but provide only dense prose
• diagram briefs that are too vague to draw
• prompts that are too broad and cause wandering output