Building Workflows, Not Tool Stacks

Resources

• Executable Markdown with GitHub Agentic Workflows — GitHub’s project defines agentic repository workflows through Markdown and configuration that compile into GitHub Actions workflows. Use it to examine triggers, permissions, and constrained outputs: prose becomes a workflow only when a runtime gives it explicit execution semantics. https://github.github.io/gh-aw/

• Workflow graphs versus agents — LangGraph’s documentation contrasts predetermined paths with agents that choose their own process and tools, illustrating chaining, routing, parallelization, and evaluator loops. It helps teachers decide which steps should be deterministic and where model-directed decisions actually add value. https://docs.langchain.com/oss/python/langgraph/workflows-agents

• Reactive notebooks as dynamic working apps — marimo combines Python execution, dependency-aware reactivity, interactive controls, and application delivery. Use it as a concrete example of turning analysis into a reusable interactive tool instead of repeatedly asking a model to regenerate a static report. https://docs.marimo.io/

• Synthetic scenarios with deterministic assertions — Playwright’s best practices emphasize user-visible behavior, isolation, resilient locators, and web-first assertions. They ground the quality loop in executable scenarios and completion evidence; synthetic coverage should supplement, not impersonate, observations of real users. https://playwright.dev/docs/best-practices

• Visual evidence from a recorded test run — Playwright’s Trace Viewer exposes action timelines, DOM snapshots, logs, and network activity. It provides inspectable material for visual notes and agent review, making “the flow works” a claim that can be checked against a specific run. https://playwright.dev/docs/trace-viewer

• Stories as reusable visual scenarios — Storybook’s story documentation describes explicit component states and arguments. Use stories to connect visual prototyping, design-system constraints, and repeatable review cases instead of approving a single attractive screenshot with no edge states. https://storybook.js.org/docs/writing-stories

• Design tokens as a shared contract — The Design Tokens Community Group’s format specification defines a portable representation for design decisions. It supports constraining generated interfaces through named values and aliases, while making clear that tokens alone do not guarantee usability or accessibility. https://www.designtokens.org/tr/2025.10/format/

• Performance markers that reflect experience — Google’s Web Vitals guidance introduces user-centered performance measures and distinguishes field from laboratory measurement. Use it to establish explicit workflow quality gates rather than treating perceived speed in a prototype as sufficient evidence. https://web.dev/articles/vitals

• A security checklist with verifiable requirements — OWASP ASVS supplies structured application-security verification requirements. It is a foundation for risk-based review loops and release safeguards, not a claim that an AI reviewer can certify security by reading a checklist. https://owasp.org/www-project-application-security-verification-standard/

• Dependency changes deserve their own review — GitHub’s dependency-review documentation explains inspecting dependency changes and associated vulnerability information in pull requests. Use it to build a separate supply-chain checkpoint around AI-generated changes instead of hiding dependency risk inside a general code review. https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review

• Real behavior through session replay — PostHog’s session-replay documentation provides a concrete source of recordings for investigating friction and unexpected user paths. Pair replay observations with analytics and privacy controls; neither a synthetic persona nor one recording establishes how the whole user population behaves. https://posthog.com/docs/session-replay

• Reports backed by executable queries — Evidence combines Markdown, SQL, and interactive data components into reports and data applications. It shows how product analysis can become a reproducible reporting workflow, with explicit source queries rather than untraceable model-written summaries. https://docs.evidence.dev/

• Bound the product bet before building — Basecamp’s Shape Up chapter on setting boundaries introduces appetite and fixed-time, variable-scope work. Use it to translate research and dashboard insights into bounded roadmap inputs rather than letting cheap generation expand every idea into a larger tool stack. https://basecamp.com/shapeup/1.2-chapter-03