canvas-info
|
canvas-quiz
|
try-first-tell-later
Structure educational content using try-first-tell-later pedagogy where students predict, attempt, or reflect before receiving explanations. Creates active learning through cognitive engagement and variation theory's contrast patterns. Use when writing educational materials, designing exercises, creating lecture notes, structuring tutorials, writing teaching examples with LaTeX/Beamer or Mentipy, developing problem sets, or when user mentions try-first, predict-first, productive failure, Socratic method, question-before-answer, exercise-driven learning, inquiry-based teaching, polls, or interactive slide questions.
update-project-docs
|
writing-crypto
|
latex-writing
|
skill-management
IMPORTANT: Activate this skill BEFORE modifying any skill in ~/.claude/skills/. Guide for creating, updating, and maintaining Claude Code skills following best practices. Use proactively when: (1) creating a new skill, (2) modifying an existing skill in ~/.claude/skills/, (3) user requests to create, improve, update, review, or refactor a skill, (4) discussing skill quality or effectiveness. Always commit skill changes to the skills git repository after making modifications.
backing-claims
|
didactic-notes
|
document-issues
IMPORTANT: load this skill the moment you notice an out-of-scope follow-up while working, and BEFORE filing any GitHub issue or importing to nytid todo. Captures unrelated follow-up issues discovered during repository work and records them for later. Use proactively when: (1) working inside a git repository and you spot a bug, cleanup, missing test/doc, or tech-debt item that is NOT part of the current task (even one you only mention in a comment, memory, or summary — capture it here instead); (2) the user mentions filing an issue, follow-up, backlog item, or nytid import. Prefer gh issue; ask before creating anything unless autonomous issue capture is enabled; optionally import created GitHub issues into nytid todo.
inbox-info
|
literate-programming
CRITICAL: ALWAYS activate this skill BEFORE making ANY changes to .nw files. Use proactively when: (1) creating, editing, reviewing, or improving any .nw file, (2) planning to add/modify functionality in files with .nw extension, (3) user asks about literate quality, (4) user mentions noweb, literate programming, tangling, or weaving, (5) working in directories containing .nw files, (6) creating new modules/files that will be .nw format. Trigger phrases: 'create module', 'add feature', 'update', 'modify', 'fix' + any .nw file. Never edit .nw files directly without first activating this skill to ensure literate programming principles are applied. (project, gitignored)
nytid-todo
|
remarkable
IMPORTANT: load this skill BEFORE calling ANY remarkable-mcp tool — even a one-line upload — because the tools have silent-failure gotchas (address docs by path/name, NOT the UUID that upload returns; annotations only appear after the tablet syncs; render_merged needs the patched build). Work with a reMarkable tablet via the remarkable-mcp MCP server: upload PDFs/EPUBs, browse/search the cloud, render pages (optionally compositing annotations onto the PDF), read page text/OCR, extract highlighted text, and list which pages carry notes/highlights. Use when: (1) sending/uploading a document, paper, or PDF to the reMarkable ('put this on my reMarkable', 'upload to remarkable'); (2) reading/rendering/checking an annotation, note, or highlight, or extracting only the annotated pages; (3) the user mentions reMarkable, remarkable-mcp, rmapi, or their tablet; (4) setting up or troubleshooting the server. Covers auth, the tool inventory, annotation extraction, and more gotchas (1-based pages, mid-session MCP loading).
review
Review recent changes — a branch, a diff, or staged/unstaged working-tree work — for correctness, regressions, and relevant domain-specific quality criteria. Use proactively when: (1) the user asks to "review the work on this branch", "review my changes", "review my diff", "review recent changes", or "check this code before I commit", (2) the user requests a review of uncommitted or just-written local work, (3) reviewing local changes against the base branch before a commit or PR. For reviewing an existing GitHub pull request, prefer the PR-focused review/code-review skills instead.
scientific-writing
Structure and workflow conventions for research papers. Use proactively when (1) writing or revising a paper draft, its introduction, method, results or conclusions, (2) adding research questions, hypotheses, contributions, questionnaires or analyses to a paper, (3) processing a review round on a draft, or (4) starting a new paper repository. Covers question-hypothesis-contribution traceability, substantive vs methodological research questions, literate-program appendices for instruments and analyses, method-section chronology, and the review-round loop.
variation-theory
Apply variation theory of learning to structure content using contrast, generalization, and fusion patterns. Variation must target the critical aspects of the learning objective. Use proactively when (1) writing educational materials, explanations, tutorials, or lecture slides, (2) designing or reviewing examples in documentation, READMEs, or literate programs (.nw files), especially when multiple examples illustrate alternative approaches to the same task, (3) structuring code examples, CLI usage examples, or API examples where the reader should notice what differs between alternatives, (4) user mentions variation theory, learning theory, pedagogy, contrast, invariance, or critical aspects. Also activate when asked to elaborate, make concrete, or add examples to existing content. Works alongside literate-programming and didactic-notes skills; in educational LaTeX or .nw materials, keep variation-analysis labels in \ltnote{} rather than student-facing prose, unless the document itself is about that design.