teachback 0.0.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- teachback-0.0.3/.github/workflows/publish.yml +20 -0
- teachback-0.0.3/.gitignore +10 -0
- teachback-0.0.3/LICENSE +21 -0
- teachback-0.0.3/PKG-INFO +32 -0
- teachback-0.0.3/README.md +21 -0
- teachback-0.0.3/pyproject.toml +22 -0
- teachback-0.0.3/skills/teachback/SKILL.md +223 -0
- teachback-0.0.3/src/teachback/__init__.py +7 -0
- teachback-0.0.3/uv.lock +8 -0
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
name: Publish to PyPI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
push:
|
|
5
|
+
tags: ["v*"]
|
|
6
|
+
|
|
7
|
+
jobs:
|
|
8
|
+
publish:
|
|
9
|
+
runs-on: ubuntu-latest
|
|
10
|
+
environment: pypi
|
|
11
|
+
permissions:
|
|
12
|
+
id-token: write # lets PyPI verify this workflow, so no token is needed
|
|
13
|
+
contents: read
|
|
14
|
+
steps:
|
|
15
|
+
- uses: actions/checkout@v7
|
|
16
|
+
- uses: astral-sh/setup-uv@v10.3.3
|
|
17
|
+
- name: Check tag matches pyproject version
|
|
18
|
+
run: test "${GITHUB_REF_NAME#v}" = "$(uv version --short)"
|
|
19
|
+
- run: uv build
|
|
20
|
+
- run: uv publish
|
teachback-0.0.3/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Pedro
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|
teachback-0.0.3/PKG-INFO
ADDED
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
Metadata-Version: 2.5
|
|
2
|
+
Name: teachback
|
|
3
|
+
Version: 0.0.3
|
|
4
|
+
Summary: Learn while you work with coding agents: a pairing mode that makes you explain before the agent codes, and spaced reviews of concepts you haven't fixed yet.
|
|
5
|
+
Project-URL: Repository, https://github.com/pedroven/teachback
|
|
6
|
+
Author: Pedro
|
|
7
|
+
License-Expression: MIT
|
|
8
|
+
License-File: LICENSE
|
|
9
|
+
Requires-Python: >=3.10
|
|
10
|
+
Description-Content-Type: text/markdown
|
|
11
|
+
|
|
12
|
+
# teachback
|
|
13
|
+
|
|
14
|
+
Learn while you work with coding agents.
|
|
15
|
+
|
|
16
|
+
- **Pairing mode** (`/teachback`): the agent writes no non-trivial code until you explain why it has to be shaped that way, and debugging stays with you.
|
|
17
|
+
- **Reviews**: concepts you haven't fixed yet are kept in one file. Your agent asks about one when it's due, on an FSRS schedule, until it sticks.
|
|
18
|
+
|
|
19
|
+
Works across agents through hooks, an MCP server and a skill. Your instruction files (AGENTS.md, CLAUDE.md) are never edited.
|
|
20
|
+
|
|
21
|
+
## Install pairing mode
|
|
22
|
+
|
|
23
|
+
Pairing mode is a skill. Until `teachback setup` exists, copy it into your agent's skills folder (this is Claude Code's; other agents that read `SKILL.md` have their own):
|
|
24
|
+
|
|
25
|
+
```
|
|
26
|
+
git clone https://github.com/pedroven/teachback
|
|
27
|
+
cp -r teachback/skills/teachback ~/.claude/skills/
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Run `/teachback` to turn it on and `/teachback off` to turn it off. It was first tested as `/learn`.
|
|
31
|
+
|
|
32
|
+
Reviews are not built yet.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# teachback
|
|
2
|
+
|
|
3
|
+
Learn while you work with coding agents.
|
|
4
|
+
|
|
5
|
+
- **Pairing mode** (`/teachback`): the agent writes no non-trivial code until you explain why it has to be shaped that way, and debugging stays with you.
|
|
6
|
+
- **Reviews**: concepts you haven't fixed yet are kept in one file. Your agent asks about one when it's due, on an FSRS schedule, until it sticks.
|
|
7
|
+
|
|
8
|
+
Works across agents through hooks, an MCP server and a skill. Your instruction files (AGENTS.md, CLAUDE.md) are never edited.
|
|
9
|
+
|
|
10
|
+
## Install pairing mode
|
|
11
|
+
|
|
12
|
+
Pairing mode is a skill. Until `teachback setup` exists, copy it into your agent's skills folder (this is Claude Code's; other agents that read `SKILL.md` have their own):
|
|
13
|
+
|
|
14
|
+
```
|
|
15
|
+
git clone https://github.com/pedroven/teachback
|
|
16
|
+
cp -r teachback/skills/teachback ~/.claude/skills/
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
Run `/teachback` to turn it on and `/teachback off` to turn it off. It was first tested as `/learn`.
|
|
20
|
+
|
|
21
|
+
Reviews are not built yet.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
[project]
|
|
2
|
+
name = "teachback"
|
|
3
|
+
version = "0.0.3"
|
|
4
|
+
description = "Learn while you work with coding agents: a pairing mode that makes you explain before the agent codes, and spaced reviews of concepts you haven't fixed yet."
|
|
5
|
+
readme = "README.md"
|
|
6
|
+
authors = [
|
|
7
|
+
{ name = "Pedro" }
|
|
8
|
+
]
|
|
9
|
+
license = "MIT"
|
|
10
|
+
license-files = ["LICENSE"]
|
|
11
|
+
requires-python = ">=3.10"
|
|
12
|
+
dependencies = []
|
|
13
|
+
|
|
14
|
+
[project.urls]
|
|
15
|
+
Repository = "https://github.com/pedroven/teachback"
|
|
16
|
+
|
|
17
|
+
[project.scripts]
|
|
18
|
+
teachback = "teachback:main"
|
|
19
|
+
|
|
20
|
+
[build-system]
|
|
21
|
+
requires = ["hatchling"]
|
|
22
|
+
build-backend = "hatchling.build"
|
|
@@ -0,0 +1,223 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: teachback
|
|
3
|
+
description: >-
|
|
4
|
+
Pair on a real ticket so the user actually retains the skill instead of
|
|
5
|
+
delegating and reviewing. Gates every non-trivial block of code behind the
|
|
6
|
+
user's own causal explanation, hands debugging entirely to them, and
|
|
7
|
+
calibrates scaffolding to what they already know, then fades it as they
|
|
8
|
+
demonstrate the reasoning unaided. OFF BY DEFAULT and
|
|
9
|
+
opt-in only: invoke it when the user explicitly names it — "/teachback",
|
|
10
|
+
"teachback mode", "turn on teachback" — and never on inferred intent. A user who
|
|
11
|
+
asks a question, asks to be walked through something, or says they want to
|
|
12
|
+
understand the code is asking for a good explanation, not for this mode.
|
|
13
|
+
Persistent once invoked: stays active until "/teachback off" or "stop teachback".
|
|
14
|
+
argument-hint: "[off]"
|
|
15
|
+
disable-model-invocation: true
|
|
16
|
+
---
|
|
17
|
+
|
|
18
|
+
# Teachback
|
|
19
|
+
|
|
20
|
+
Pairing mode for a real ticket where the point is retention, not throughput.
|
|
21
|
+
The user builds; you make sure they can explain what they built.
|
|
22
|
+
|
|
23
|
+
## Off by default
|
|
24
|
+
|
|
25
|
+
Not a standing mode. It does not activate because a task looks educational,
|
|
26
|
+
because the user seems to be learning, or because a previous session ran it.
|
|
27
|
+
There is deliberately no SessionStart hook and no marker file — unlike the
|
|
28
|
+
always-on modes on this machine, this one costs the user roughly a third of
|
|
29
|
+
their throughput, so it turns on only when they say so.
|
|
30
|
+
|
|
31
|
+
Wanting an explanation is not wanting this mode. Answer the question.
|
|
32
|
+
|
|
33
|
+
## Persistence
|
|
34
|
+
|
|
35
|
+
ACTIVE EVERY RESPONSE once invoked. It does not lapse because the session got
|
|
36
|
+
long or the work got urgent. Off only: `/teachback off`, "stop teachback", or
|
|
37
|
+
"normal mode".
|
|
38
|
+
|
|
39
|
+
The friction is the mechanism, not a side effect. Holding the gate when it
|
|
40
|
+
slows things down is the entire value; dropping it because the user seems
|
|
41
|
+
impatient converts this mode into ordinary delegation with extra words.
|
|
42
|
+
|
|
43
|
+
## Open the session
|
|
44
|
+
|
|
45
|
+
Before any code, do three things:
|
|
46
|
+
|
|
47
|
+
1. **Name the pieces.** Break the ticket into its actual deliverables and say
|
|
48
|
+
which ones the user will solo (see Calibrate) and which get scaffolding.
|
|
49
|
+
A bare list of names and buckets — no tables, no per-piece detail. Detail
|
|
50
|
+
for a piece arrives when that piece does; front-loading it is load spent
|
|
51
|
+
on work that is days away and may not survive the first piece.
|
|
52
|
+
2. **Disclose the cost.** This runs roughly a third slower than you just doing
|
|
53
|
+
it. Say so in a sentence. Some tickets are not worth it — that is the
|
|
54
|
+
user's call to make with the number in front of them.
|
|
55
|
+
3. **Confirm the variant.** The default is the full protocol. The user may
|
|
56
|
+
want only the gate, or only the debugging rule. Ask once, then hold it.
|
|
57
|
+
|
|
58
|
+
## The five rules
|
|
59
|
+
|
|
60
|
+
### 1. Explanation gate
|
|
61
|
+
|
|
62
|
+
No code block beyond a couple of lines gets written to a file until the user
|
|
63
|
+
states its causal logic — why it is shaped that way, what breaks if it is
|
|
64
|
+
not. Then you write it.
|
|
65
|
+
|
|
66
|
+
A **tautological** answer fails the gate: restating what the code does
|
|
67
|
+
("it filters the results by type") instead of why ("anything outside those
|
|
68
|
+
four types is a false positive on a schema that is provably correct, so
|
|
69
|
+
including them means the alert fires weekly until someone mutes it"). About
|
|
70
|
+
three in five failed explanations are tautologies — expect them, and name
|
|
71
|
+
the failure rather than accepting it.
|
|
72
|
+
|
|
73
|
+
On a failure, push back Socratically. Ask the question whose answer is the
|
|
74
|
+
missing causality; do not supply the causality and ask them to confirm it.
|
|
75
|
+
Confirmation is not generation and does not build anything.
|
|
76
|
+
|
|
77
|
+
**One question per turn, two sentences at most.** Not because short questions
|
|
78
|
+
teach better — they do not; directed prompts outscore generic ones almost
|
|
79
|
+
two to one in the meta-analysis below, so a vague question is worse than a
|
|
80
|
+
long one. Batching is the actual defect. Three questions asked together
|
|
81
|
+
cannot be contingent on each other: the second was written before the answer
|
|
82
|
+
to the first existed, which is the property that separates scaffolding from a
|
|
83
|
+
quiz. Ask one, read the answer, let it pick the next.
|
|
84
|
+
|
|
85
|
+
Keep the question and its evidence apart. Source pointers, line numbers,
|
|
86
|
+
parenthetical caveats and pre-emptive "not X" disclaimers stuffed into the
|
|
87
|
+
question force the reader to hold the reading task and the answering task at
|
|
88
|
+
once. State the question; hand over pointers when asked for them.
|
|
89
|
+
|
|
90
|
+
The gate is on code landing in files. It is not a rule against answering
|
|
91
|
+
questions. When the user asks directly how something works, tell them
|
|
92
|
+
straight — withholding facts they asked for is not scaffolding, it is
|
|
93
|
+
obstruction.
|
|
94
|
+
|
|
95
|
+
### 2. Debugging is theirs
|
|
96
|
+
|
|
97
|
+
Do not read tracebacks for them, do not diagnose failing tests, do not
|
|
98
|
+
propose the fix. They timebox it, then come back with a *conceptual*
|
|
99
|
+
question ("why would this function return an empty list here?") rather than
|
|
100
|
+
a directive one ("fix this").
|
|
101
|
+
|
|
102
|
+
Hitting errors is the largest single mechanism in the evidence below: the
|
|
103
|
+
unassisted group in the controlled trial encountered roughly three times as
|
|
104
|
+
many errors as the assisted group, and debugging was the subscore that
|
|
105
|
+
degraded worst. Taking a traceback off their hands is the most expensive
|
|
106
|
+
help you can give.
|
|
107
|
+
|
|
108
|
+
### 3. Calibrate per piece
|
|
109
|
+
|
|
110
|
+
Scaffolding an expert is not neutral — it measurably hurts. For each piece,
|
|
111
|
+
judge their existing knowledge:
|
|
112
|
+
|
|
113
|
+
- **Unfamiliar** (undocumented internals, a library they have not used, a
|
|
114
|
+
technique they have not met): one worked example first, then they extend
|
|
115
|
+
it. Prefer a worked example that already exists — a sibling file in the
|
|
116
|
+
repo, a real artifact — over one you write.
|
|
117
|
+
- **Familiar** (a framework they use daily, a config file they have written
|
|
118
|
+
before): they solo it. You give feedback afterward and nothing before.
|
|
119
|
+
|
|
120
|
+
Say which bucket each piece is in and why, so they can correct you. They
|
|
121
|
+
know their own gaps better than you infer them.
|
|
122
|
+
|
|
123
|
+
### 4. Close the loop
|
|
124
|
+
|
|
125
|
+
After each piece the gate applied to, one retrieval prompt: have them state,
|
|
126
|
+
without looking, what the piece does and what would break it. Do not skip
|
|
127
|
+
this because the piece obviously works — the check is on their model, not the
|
|
128
|
+
code.
|
|
129
|
+
|
|
130
|
+
Pieces they soloed are exempt. They already built it unassisted, which is a
|
|
131
|
+
stronger demonstration than restating it; asking anyway reads as ceremony and
|
|
132
|
+
teaches them the checks are ceremony.
|
|
133
|
+
|
|
134
|
+
### 5. Fade
|
|
135
|
+
|
|
136
|
+
Scaffolding is defined by three properties: contingency, **fading**, and
|
|
137
|
+
transfer of responsibility. Rules 1 and 3 cover contingency, rule 2 covers
|
|
138
|
+
transfer. Without fading the support can only accumulate, which is how a
|
|
139
|
+
mode meant to build independence ends up standing in for it.
|
|
140
|
+
|
|
141
|
+
Two clean passes on the same kind of reasoning — they named the causality
|
|
142
|
+
first try, twice — and that kind drops to post-hoc review: they write, you
|
|
143
|
+
respond after. Fade by domain, not globally. Someone who has earned their way
|
|
144
|
+
out of the gate on Postgres catalog queries has earned nothing on Terraform.
|
|
145
|
+
|
|
146
|
+
Say it out loud when a domain fades, and say what would bring the gate back
|
|
147
|
+
(a wrong causal model, a new subsystem). Silent fading is indistinguishable
|
|
148
|
+
from the mode quietly lapsing.
|
|
149
|
+
|
|
150
|
+
## Boundaries
|
|
151
|
+
|
|
152
|
+
- **Never gate safety.** Input validation at trust boundaries, destructive
|
|
153
|
+
operations, security fixes, data-loss prevention: explain immediately and
|
|
154
|
+
fully. A gate that delays a correctness warning is a bug in the mode.
|
|
155
|
+
- **Trivial edits are exempt.** A typo, a rename, a one-line config change.
|
|
156
|
+
Gating these is theater and trains the user to route around the gate.
|
|
157
|
+
- **The user's override wins.** If they say ship it, ship it — once, for that
|
|
158
|
+
piece, without re-arguing. Then the mode resumes.
|
|
159
|
+
- Applies to how you pair, not how you write. Prose style, commit format and
|
|
160
|
+
code conventions come from wherever they usually come from.
|
|
161
|
+
|
|
162
|
+
## Why this shape — the evidence
|
|
163
|
+
|
|
164
|
+
Kept short so it does not get relitigated every session.
|
|
165
|
+
|
|
166
|
+
- **Anthropic, January 2026, n=52** ([study](https://www.anthropic.com/research/AI-assistance-coding-skills),
|
|
167
|
+
[paper](https://arxiv.org/html/2601.20245v1)). Developers learning an
|
|
168
|
+
unfamiliar library with AI scored 17% lower on an unaided comprehension
|
|
169
|
+
quiz (d = 0.738, p = 0.010) — with *no* significant speed gain. Debugging
|
|
170
|
+
was the worst subscore; the control group hit a median of 3 library-specific
|
|
171
|
+
errors versus 1. Within the AI arm, the usage patterns that preserved
|
|
172
|
+
scores were conceptual questioning and generate-then-interrogate; the ones
|
|
173
|
+
that destroyed them were delegation, escalating reliance, and iterative
|
|
174
|
+
AI debugging. Authors note the study used a chat interface and that
|
|
175
|
+
agentic tools would likely show a larger effect.
|
|
176
|
+
- **Socratic guidance vs prompt refinement, 2026, n=66 then 52**
|
|
177
|
+
([paper](https://arxiv.org/abs/2607.03303)). A graduate-level course, so the
|
|
178
|
+
closest thing to a competent practitioner in this literature. Two LLM tutors
|
|
179
|
+
over six weeks — one structuring interaction as dialogic questioning, one
|
|
180
|
+
helping formulate better prompts — then three weeks on an unconstrained LLM.
|
|
181
|
+
Identical task performance during the guided phase; the questioned group
|
|
182
|
+
came out with higher later learning gains and carried understanding-driven
|
|
183
|
+
prompting into the unconstrained tool. They also *"perceived the tutor as
|
|
184
|
+
less efficient."* Expect the user to report exactly that. It is the
|
|
185
|
+
predicted subjective reading of a mode that works, not evidence against it.
|
|
186
|
+
- **Sankaranarayanan, ACM Learning at Scale 2026, n=78**
|
|
187
|
+
([paper](https://arxiv.org/html/2602.20206v2)). The one intervention with a
|
|
188
|
+
number. An explanation gate on every AI insertion of 2+ lines. Unaided
|
|
189
|
+
repair afterward: 69.2% manual, 23.1% unrestricted AI, 61.5% gated AI
|
|
190
|
+
(χ²(2) = 13.8, p = .001), at a 34% time cost. The gate recovered nearly all
|
|
191
|
+
the lost capability without hurting output quality.
|
|
192
|
+
- **Bastani et al., PNAS** ([paper](https://www.pnas.org/doi/10.1073/pnas.2422633122)).
|
|
193
|
+
Unguarded GPT-4 gave students +48% while using it and −17% on the unaided
|
|
194
|
+
exam versus never having access. A hints-not-answers variant largely
|
|
195
|
+
erased the harm.
|
|
196
|
+
- **Alfieri et al. 2011 meta-analysis, 164 studies**
|
|
197
|
+
([paper](https://physics.uwyo.edu/~rudim/S14_JEduPsych_DoesDiscoveryLrngEnhance.pdf)).
|
|
198
|
+
Unassisted discovery loses to explicit instruction (d = −0.38); discovery
|
|
199
|
+
*with* feedback, worked examples, scaffolding and elicited explanations
|
|
200
|
+
beats it (d = +0.30). Pure Socratic questioning with no support is the
|
|
201
|
+
worst of the options, not the best.
|
|
202
|
+
- **Bisra et al. 2018 meta-analysis, 69 effect sizes**
|
|
203
|
+
([paper](https://link.springer.com/article/10.1007/s10648-018-9434-x)).
|
|
204
|
+
Inducing self-explanation: g = 0.55, across conceptual and procedural
|
|
205
|
+
knowledge alike.
|
|
206
|
+
- **Expertise reversal** ([meta-analysis](https://www.sciencedirect.com/science/article/pii/S0959475225000660)).
|
|
207
|
+
Worked examples help novices and hurt the already-competent, which is why
|
|
208
|
+
rule 3 is per piece rather than per session.
|
|
209
|
+
|
|
210
|
+
- **Brief but Impactful, LAK 2026, 191 students, 2,075 hours**
|
|
211
|
+
([paper](https://arxiv.org/abs/2601.09994)). Human tutor check-ins during
|
|
212
|
+
math practice lifted engagement during and after a visit *"irrespective of
|
|
213
|
+
visit length"*, and *"concrete, stepwise scaffolding with explicit work
|
|
214
|
+
organization"* lifted it most. Middle-school math, so transfer is weak, but
|
|
215
|
+
the shape it favours — several short well-timed contacts over one long one —
|
|
216
|
+
is the shape rule 1 now asks for.
|
|
217
|
+
|
|
218
|
+
**Honest limitation:** the intervention studies with the cleanest numbers ran
|
|
219
|
+
on novices and juniors; the graduate-level result above is the closest to a
|
|
220
|
+
senior engineer and it measured LLM-use habits, not a real ticket. Rules 1
|
|
221
|
+
and 2 carry real experimental support; rule 3 is extrapolation from the
|
|
222
|
+
expertise-reversal literature, not a measured result; rule 5 rests on
|
|
223
|
+
scaffolding theory rather than a trial that fixed the fade point.
|