Assisted Mastery
Choose explain vs produce agent assistance per task, fade scaffolding over time, and keep load-bearing code in human hands on risky work.
Overview
Assisted Mastery is a journey-wide agent skill that sets explain-vs-produce collaboration modes and fades assistance over time—usable whenever a solo builder needs to decide how much an agent should implement before comm
Install
npx skills add https://github.com/athola/claude-night-market --skill assisted-masteryWhat is this skill?
- Two explicit modes: Explain (human writes load-bearing code) vs Produce (agent implements, human reviews)
- Mode selection tied to risk classification and whether the goal is shipping or skill retention
- High-risk domains (auth, migration, money, concurrency) default to Explain regardless of ship pressure
- Fade protocol: reduce assistance tier over time so scaffolding does not become permanent
- Requires stating the chosen mode aloud—silent produce defaults are treated as an anti-pattern
- 2 assistance modes (Explain and Produce) with explicit high-risk Explain override
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
You default to full agent implementation and lose skill on critical code paths, or you never get throughput because every task is treated as a lesson.
Who is it for?
Solo builders using Claude Code, Cursor, or Codex who want durable skill growth alongside agent speed on low-risk work.
Skip if: Fully automated pipelines with no human in the loop, or one-off copy edits where mode discipline adds no value.
When should I use this skill?
Starting agent-assisted work where you must choose explain vs produce, fade tiers, or prevent silent full automation on consequential code.
What do I get? / Deliverables
You run each task under an explicit assistance mode matched to risk and learning goals, then step down tiers so the agent stops doing the load-bearing work you need to own.
- Explicit mode declaration per task
- Fade plan for reducing agent responsibility over repetitions
- Human-authored load-bearing code paths on high-risk work
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Use Explain while spiking an unfamiliar SDK so you retain mental model before scaling the prototype.
Produce boilerplate handlers but Explain on concurrency and payment edge cases.
After agent confusion on a migration, drop one assistance tier and require human-written load-bearing steps.
Choose Produce for log-parser scripts and Explain when patching auth regressions in production.
Produce draft docs while Explain on architecture posts you need to defend publicly.
How it compares
Use for human–agent pedagogy and risk-aware modes—not for a feature generator or a code review rubric alone.
Common Questions / FAQ
Who is assisted-mastery for?
Indie builders and small teams who pair with coding agents daily and want explain/produce discipline plus fading scaffolding instead of permanent autopilot.
When should I use assisted-mastery?
Before build implementation on unfamiliar APIs; during ship review on auth or payments; when validating prototypes; and whenever an agent repeatedly misunderstands a domain and you need to drop an assistance tier.
Is assisted-mastery safe to install?
It is behavioral guidance only; review the Security Audits panel on this Prism page and pair it with your agent’s permission settings for produce mode on sensitive repos.
Workflow Chain
Requires first: leyline risk classification
SKILL.md
READMESKILL.md - Assisted Mastery
# Modes and Fading How to choose an assistance mode per task and reduce it over time. ## The Two Modes | | Explain mode | Produce mode | |---|---|---| | Agent role | Narrates reasoning, writes scaffolding only | Writes the implementation | | Human role | Writes the load-bearing code | Reviews the diff | | Optimizes for | Understanding and skill retention | Throughput | | Learning value | High (productive failure, retrieval) | Low (offloaded) | | Use when | Unfamiliar area, high stakes, skill-building | Boilerplate, known patterns, reversible work | Explain mode is not "produce mode with a paragraph attached." In explain mode the human writes the part that matters, and the agent withholds the finished answer so the struggle that builds judgment actually happens. The agent models the approach, points at the relevant interfaces, and reviews what the human writes. ## Choosing the Mode Tie the choice to risk and to whose skill is at stake: 1. Classify the task risk (see `leyline:risk-classification`). 2. Ask: is the goal to ship this, or to build the human's skill in this area? 3. Map: | Risk / goal | Mode | |-------------|------| | Low risk, ship goal | Produce | | Low risk, skill goal | Explain | | High risk (auth, migration, money, concurrency) | Explain, regardless of goal | | Agent showed repeated confusion or failure | Drop a tier (see below) | State the chosen mode explicitly. A silent default to produce mode is how scaffolding becomes permanent. ## The Fade Protocol Expertise reversal means constant help eventually hurts. On any area the human is deliberately building skill in, assistance should decrease across encounters: ``` produce -> explain -> manual with review -> manual (agent writes) (human writes, (human writes, (human writes, agent narrates) agent reviews) agent silent) ``` Move one step toward manual each time the human demonstrates they can do the previous step unaided. This is the apprenticeship fading model: support is withdrawn on purpose as competence grows, the opposite of permanent dependence. ## Dropping a Tier on Confusion Borrowed from aviation's "children of the magenta" lesson: when the automation is not doing what is needed, the operator must downgrade the level of automation rather than re-issue the same command at the same level. For coding agents: - After two consecutive failed attempts of the same shape (same file, same error class, same tool), do not try a third blind variation. Drop to a lower tier: switch to explain mode, run a read-only diagnostic, and have the human state what they believed and what the evidence now says. This is the two-challenge rule already encoded in the project's global guidance, applied as a deliberate automation downgrade. # Research Basis: Assisted Mastery and the Verification Spine The evidence base behind this skill and its sibling `imbue:graduated-implementation`. The SKILL.md Overview summarizes the load-bearing findings; this module preserves the full tables, cross-domain mechanism, and citations for auditing the claims. It also records the six workflow principles this research recommended, four of which this skill and its siblings now implement. ## Thesis The problem with AI-generated code is not the tool: it is blind trust of the tool's output. Experienced developers catch the flaws (bad architecture, hallucinated APIs, over-abstraction, outdated syntax); novices cannot, because you cannot verify what you do not understand. The historical fix for the analogous problem (novices copy-pasting from Stack Overflow) was not to ban the source: it was to force learners through implementation, trial-and-error, and explicit tradeoff reasoning until they understood the ramifications of design decisions. The design question for any coding-agent workflow is therefore: does it force understanding and verification, or does it enable blind acceptance? ## Thread A: the flaws are real and measured | Cl