timothyfraser

Build a single self-contained HTML mini-tutorial that teaches ONE concept through a GENUINELY interactive centerpiece — something the reader manipulates that responds live — then verify it actually works before handing it back. The *form* of the interactive is chosen to fit the concept (a network process, a parameter model with sliders, an agent-based grid, a step-through algorithm, a data explorer, a what-if calculator, …) — contagion-on-a-network is just one example, not the default. Every build opens with a big-picture question, puts a hands-on interactive at the center with live-updating readouts, uses a fixed color scheme and uniform headings, and ends with tap-to-reveal learning checks (phone-friendly). Use when a faculty member wants an interactive explainer, a lesson dashboard, a concept simulator, or a "mini tutorial" they can open in a browser or share on a phone.

A monthly routine for scholars: search the web for recent mentions, press, talks, and citations of a named researcher and their work, then append the genuinely-new ones to a CSV (date logged, date published, title, source, URL, one-line description) — deduped against what's already there. Use when a researcher wants to track who is talking about them and their work over time, with links they can skim later.

Have the agent propose a concrete, numbered plan and get approval BEFORE executing — then work the plan step by step, re-planning out loud when reality diverges. Part of the "keep the agent on track" suite. Use for any task big enough that a wrong first move is costly, or when an agent tends to charge ahead.

Maintain a persistent house-rules file (CLAUDE.md or AGENTS.md) the agent reads every session — what the project is, how to run/test it, conventions, architecture pointers, and gotchas/"don'ts" — so it stops relearning the project and repeating mistakes. Part of the "keep the agent on track" suite. Use for any repo an agent will touch more than once.

Break a complex build into thin, end-to-end slices — each independently runnable and verifiable — instead of horizontal layers, so you always have something working and learn early. Part of the "keep the agent on track" suite. Use when a task is big enough that "build it all, then test" risks weeks of invisible drift.

Keep an append-only log of decisions (Architecture Decision Records) — each with context, the decision, and its rationale and consequences — so the agent doesn't re-litigate or silently contradict past choices. Part of the "keep the agent on track" suite. Use when a project accumulates choices you'll need to remember the "why" for.

Pin down checkable success criteria (and ideally tests) BEFORE building, so "done" is objective, not vibes — acceptance criteria, test cases, edge cases, and a done checklist the agent must satisfy and report against. Part of the "keep the agent on track" suite. Use to keep an agent honest about whether a task is actually complete.

Write a short design doc (RFC) before building — problem, goals & non-goals, proposed approach, alternatives considered, risks, and a validation plan — and get sign-off before the agent writes code. Part of the "keep the agent on track" suite. Use to stop an agent from charging ahead on the wrong solution.

Scaffolds short-lived R or Python scripts that call Ollama Cloud /api/chat with tool definitions, batch rows or records per request, optionally parallelize chunk calls (e.g. furrr), and apply tool results on the main process with JSONL audits—using a folder-local .env. Use when the user wants an agent loop for data cleaning, enrichment, geospatial routing, dataset compilation, batched tool calls, parallel Ollama chunks, or teaching patterns aligned with 10_data_management/fixer (not full Plumber/FastAPI agents unless requested).

Adds clear console progress and status output for R and Python scripts using section dividers, Unicode emoji icons, dimensions (nrow/length), paths, and previews so runs are debuggable from logs pasted into AI chats. Use when polishing scripts, improving observability, or when the user asks for progress messages, status lines, or emoji console UX.

Write elegant modern tidyverse R for this course repo—always = for assignment (never <-), dplyr 1.1+ (join_by, .by), native pipe, explicit library() per file, vectorized mutate/case_when, httr2 and purrr possibly/safely, rlang data-mask patterns. Use when editing 03_query_ai, 10_data_management, fixer, or refactoring API/data pipelines.

Use this skill when a user wants to convert a workflow.R script into an interactive HTML/JS mockup dashboard with a design sidepanel. Triggers when users mention building a Shiny dashboard from an R script, want to prototype a dashboard UI before writing Shiny server code, want to visualize their R workflow as a dashboard, or say things like "turn my workflow into a dashboard", "mockup my shiny app", "design a dashboard from my R script", or "stage 1 of the shiny pipeline". Always use this skill before generating any HTML dashboard mockup for a Shiny app project.

Use this skill when a user wants to convert an approved HTML mockup dashboard into a real R Shiny app. Triggers when users mention "convert my mockup to Shiny", "stage 2 of the shiny pipeline", "turn the HTML into a Shiny app", "build the Shiny server", or paste a design_metadata.json. Always use this skill before writing any Shiny app code from an HTML mockup. This skill produces a raw HTML/JS Shiny UI (no bslib/shinydashboard) paired with a reactive R server.

Use this skill when a user wants to replace fake/synthetic data stubs in their Shiny app with real data from their workflow.R script. Triggers when users mention "stage 3 of the shiny pipeline", "replace fake data", "wire up real data", "swap stubs for real data", "integrate my workflow into shiny", or present a FAKEDATA_INDEX with items marked as still fake. Always use this skill before touching any fake_data.R or placeholder_fns.R stubs. Never silently replace fake data — every swap must be logged.

How to use the per-user Smartsheet connector (smartsheet_whoami, smartsheet_list_sheets, smartsheet_get_sheet, smartsheet_search, smartsheet_list_workspaces). Use whenever a user asks about THEIR Smartsheet sheets, rows, workspaces, or wants to look something up in Smartsheet. Every action is scoped to the user's own Smartsheet account via their personal access token.

How to use the SysEng Canvas Faculty Assistant (the ask_canvas tool) to answer questions about the user's OWN Cornell Canvas courses and students — listing courses, rosters, student search, cross-course overlap, grade trajectory, and assignment analytics. Use whenever a Cornell Systems Engineering faculty member asks about their Canvas courses, their students, grades, submissions, or course analytics. FERPA-sensitive — prefer aggregates.

How to use the Cornell Systems Engineering Program Assistant (the ask_program tool) — when to call it, how to phrase questions, and how to invoke named /skills. Use whenever a user asks about Cornell Systems Engineering courses, faculty, degree requirements, forms, deadlines, pathways, contacts, or "who do I talk to about X".