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.
What this skill does
# Try-First-Tell-Later Pedagogy
This skill applies the pedagogical principle of engaging learners' thinking **before** presenting information, creating active learning through anticipation, prediction, and problem-solving attempts.
## Core Principle
**Ask students to think, predict, or attempt solutions BEFORE providing the answer or explanation.**
This creates powerful learning through:
- **Double contrast**: Students contrast known approaches with new problems, then contrast their thinking with expert knowledge
- **Active engagement**: Learning happens through attempting, not just receiving
- **Metacognitive awareness**: Predicting and comparing reveals gaps in understanding
- **Productive failure**: Research shows attempting before instruction produces better learning than passive study
## The Teacher's Paradox and Assessment
### The Teacher's Paradox
Marton identifies a fundamental tension in teaching:
> "[T]he more the teacher does to enable the students to answer the questions asked, to solve the problems given, the fewer opportunities may be left for the students to learn to understand that which they are expected to learn to understand. The reason is that the more clearly the teacher tells the students what is to be done, the less chance the students get to make the necessary distinctions (for instance, between what is critical and what is not)." (NCOL, p. 13)
**Implication**: Try-first prompts should NOT reveal which aspects are critical. Students must discern this themselves.
### Try-First as Diagnostic Pre-Test
Try-first prompts serve a dual purpose:
1. **Learning function**: Engages prediction, activates prior knowledge, creates contrast
2. **Diagnostic function**: Reveals which critical aspects students can already discern
**Key insight** (Marton, NCOL p. 89):
> "If we want to find out to what extent they have learned to do so, we should not point out those aspects for them but let the students discern them by themselves."
**Use try-first prompts to diagnose**:
- Which critical aspects students already discern
- Which aspects need teaching (require variation patterns)
- Common misconceptions to address
### Designing Questions That Don't Reveal Critical Aspects
**BAD example** (Swedish national physics exam):
> "A ball falls and is affected by air braking force F = kv where k = 0.32 N·s/m. The ball's mass is 0.20 kg. What is the final velocity?"
**Problem**: All critical aspects are given. Students just calculate—no discernment needed.
**GOOD example** (Johansson, Marton, Svensson 1985):
> "A car is driven at a high constant speed on a motorway. What forces act on the car?"
**Why better**: Students must discern:
- That "constant speed" implies balanced forces
- Which forces are relevant
- That "engine pushes forward" alone is wrong
### Prompt Design Checklist
- [ ] Does my question require discerning critical aspects, or point them out?
- [ ] Could this serve as a pre-test to reveal student understanding?
- [ ] Am I avoiding giving away "what matters" in the question?
- [ ] Will responses reveal which critical aspects students see/miss?
### Connection to Variation Theory
Try-first prompts and variation theory work together:
1. **Try-first reveals** which critical aspects students cannot yet discern
2. **Variation patterns** then target those specific aspects
3. **Post-test try-first** confirms students now discern the aspects
See the variation-theory skill for designing appropriate patterns once diagnostic results are known.
## Quick Example
**Traditional "Tell-First" approach:**
```
Python uses the def keyword to define functions. Here's the syntax:
def function_name(parameters):
# function body
return result
```
**Try-First-Tell-Later approach:**
```
\begin{exercise}
How would you create a reusable piece of code in Python that
takes inputs and returns a result? What keyword might make sense?
Think about it before continuing.
\end{exercise}
Python uses the def keyword to define functions...
[Then show syntax and compare with their thinking]
```
The second approach activates prior knowledge, creates cognitive engagement, and sets up contrast between their prediction and the actual syntax.
## Seven Implementation Patterns
Use different prompt types to engage students before providing explanations:
1. **Prediction Prompts**: "What do you think will happen if...?"
2. **Design/Solution Prompts**: "How would you...?" or "How could you implement...?"
3. **Conceptual Definition Prompts**: "What is...? Try to formulate your own definition before..."
4. **Reasoning Prompts**: "Why do you think...?" or "Varför tror du...?"
5. **Comparison Prompts**: "Jämför..." or "Which differences do you see...?"
6. **Reflection Prompts**: "Reflektera över..." or "What advantages/disadvantages do you see...?"
7. **Experimentation Prompts**: "Prova!" or "Write a program that..."
**For detailed implementation guidance, examples, and LaTeX/Beamer templates, see `references/patterns.md`.**
## Mentipy as a Delivery Mechanism
Mentipy fits naturally when try-first prompts should be answered live in
slides or handouts. Use `mc` for constrained predictions, `scale` for quick
self-assessment or confidence checks, `open_text` for short reflections, and
`word_cloud` for brainstorming prior knowledge. This works well for brief
diagnostic questions before explanation, especially when the goal is to make
student thinking visible without revealing the critical aspect too early.
## Typical Flow
```
Context → Prompt to Try/Predict → [Student thinking] →
Explanation → Explicit contrast → Highlight critical aspects
```
## The Example-Question-Contrast Pattern
A powerful specific structure for organizing instructional sequences:
**Structure**:
1. **Show concrete example** illustrating a problem or scenario
2. **Pose try-first question** for students to predict/discover
3. **Show modified code/approach** demonstrating the solution
4. **Discuss the contrast** between approaches
**Example from file handling:**
```latex
% Step 1: Show problem example
\begin{frame}[fragile]
\begin{example}[Manual file handling]
\begin{minted}{python}
file = open("data.txt", "r")
content = file.read()
file.close()
\end{minted}
\end{example}
\end{frame}
% Step 2: Try-first question
\begin{frame}[fragile]
\begin{exercise}
What happens if an exception occurs between \mintinline{python}{open()}
and \mintinline{python}{close()}? How can we guarantee the file is closed?
\end{exercise}
\end{frame}
% Step 3: Show solution
\begin{frame}[fragile]
\begin{example}[with statement]
\begin{minted}{python}
with open("data.txt", "r") as file:
content = file.read()
# file automatically closed here
\end{minted}
\end{example}
\end{frame}
% Step 4: Discuss contrast
\begin{frame}
\begin{remark}
The \mintinline{python}{with} statement guarantees resource cleanup
even if exceptions occur. This implements the context manager protocol,
ensuring \mintinline{python}{close()} is always called.
\end{remark}
\end{frame}
```
**Why this works**:
- Students see the problem before being told there's a problem
- The question activates thinking about edge cases
- The solution is motivated by the discovered problem
- The contrast makes the value of `with` statement discernible
**Variation pattern**: The approach varies (manual vs with statement), the problem remains invariant, making resource management guarantees discernible.
## Guidelines for Effective Use
### When to Use Try-First Prompts
**Ideal situations**:
- Concepts students can partially reason about from prior knowledge
- Situations with intuitive but incorrect predictions
- Design decisions with multiple reasonable approaches
- Conventions or patterns with underlying rationale
- Comparisons where differences aren't immediately obvious
**Less suitable situations**:
- Completely novel concepts with no prior knowledge base
- Arbitrary facts with no logical deriRelated in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.