Files
ai-workflow-course/AGENTS.md
T
claude fbec36cb67 feat(course): build out all 27 modules, capstone, scaffold, and conventions
Scaffold the course repo and author the full curriculum in dependency-chain
order, following the settled build decisions in handoff.md.

- Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5),
  _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config.
- Modules 1-2: reference exemplars (locked for tone/depth/lab style).
- Modules 3-27: full lessons + runnable labs, each following the template,
  respecting the chain, vendor/model-agnostic, with "feel the pain" labs.
- Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22),
  not written from memory; expansion-zone modules carry Verify-before-publish.
- Capstone: the full loop end to end on the running tasks-app example.

Lab code syntax-checked (Python/shell/YAML); every module has the 7 core
template sections.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
2026-06-22 12:18:30 -04:00

3.5 KiB
Raw Blame History

AGENTS.md — instructions for AI agents working in this repo

This is the committed AI instructions file for The Workflow course. It exists for two reasons: it actually configures the agents that help author the course, and it is a live worked example of Module 5 — Commit the AI's Config, Not Just the Code. The filename is deliberately vendor-neutral: most agentic coding tools read a repo-level instructions file, and the principle outlives any one vendor's filename. If your tool looks for a different name, point it here.

What this repo is

A course that teaches IT professionals the engineering toolchain around AI coding — version control, collaboration, CI/CD, and the tools that extend AI into real systems. The repo is both the course content and a dogfooded example of the practices it teaches.

  • Source of truth for structure: the-workflow-syllabus.md. Don't re-derive decisions it settles; read it first.
  • Build-context for authoring: handoff.md. The "how" of building, plus the owner's settled decisions.
  • Every module follows _TEMPLATE.md. Don't invent a new shape per module.

Core promises (do not violate)

  • Model- and vendor-agnostic. Never pin a lesson to one LLM vendor. Never hardcode a specific tool's config filename — say "your agentic tool's committed instructions file." Examples must survive a model swap.
  • GitHub is the default, not the requirement. Keep hosting content provider-neutral; name the alternatives and the self-host track. Do not reintroduce a single specific forge as the answer.
  • The dependency chain is load-bearing. A module may assume only what precedes it. Never reference a tool before its introducing module. If you think something should move, flag it — don't silently reorder.
  • Honesty about limits. Where a tool or analogy breaks, say so. Don't sand off the caveats.
  • Don't pad. This audience reads fast and trusts concrete over comprehensive. Lead with the pain, show the command and the failure mode.

Voice

Direct, concrete, rigorous. Reframe ops instincts the reader already has toward AI-assisted work. No motivational filler. When in doubt, show the command and what goes wrong without it.

Conventions for labs

  • Labs run on the learner's own machine, any OS. Don't assume a sandbox, cloud account, or specific shell beyond what's stated.
  • Lean on Python or shell, chosen per lab, kept minimal. State the language once per lab.
  • Every module ends at a keyboard (a lab), not a quiz, and has a concrete "you're done when…" check.

Working in this repo (dogfooding the course)

This repo is hosted on git.jpaul.io. Follow the same flow the course teaches:

  • Never commit directly to main. Branch per module/change, open a PR, squash-merge. The PR is the review gate (Module 10) even for solo work — it exists for traceability.
  • Build in dependency-chain order. Modules 12 are the locked exemplars; match their tone, depth, and lab style.
  • Verify before publishing volatile claims. Anything about pricing, versions, or tool behavior (especially the Module 8 hosting comparison) must be checked at build time, not written from memory. Mark such claims with a "Verify-before-publish" note.

Don't

  • Duplicate or fork the-workflow-syllabus.md — edit it in place if structure changes.
  • Reorder modules or break the dependency chain without flagging it.
  • Pin to a specific LLM vendor or a specific tool's config filename.
  • Write pricing/version claims from memory.
  • Pad.