| name | intake |
| description | Onboarding interview for the personal development harness. Scans background/ for pre-loaded materials (code, resumes, writing, transcripts), runs a conversational interview to discover background, goals, current skills, and learning preferences, then generates a personalized CLAUDE.md and initial current-state.md. Use when setting up a new learner, onboarding, or bootstrapping the harness. |
Intake
Onboard a new learner. Five phases, in order. Do not skip or reorder.
Path Resolution
This skill reads and writes files in the weft harness directory, which
may not be the current working directory.
To find the harness root: Read ~/.config/weft/root. If the file
exists, use its contents as the absolute path. If it doesn't exist, fall
back to the current working directory (local-install compatibility).
All file paths in this skill resolve from the harness root:
learning/* → <harness-root>/learning/*background/* → <harness-root>/background/*.claude/skills/* → <harness-root>/.claude/skills/*.claude/references/* → <harness-root>/.claude/references/*.claude/consent.json → <harness-root>/.claude/consent.json
Phase 4 (Write) targets ~/.claude/CLAUDE.md — the global file, not
a project-local CLAUDE.md. Intake replaces the content between the
<!-- weft:start --> and <!-- weft:end --> markers with a
personalized version. See Phase 4 for details.
Skip .gitignore steps. The global install doesn't need gitignore
entries — learning state lives in the harness directory, not in user
projects.
Phase 0: Resume Check
Before starting intake, check if learning/.intake-notes.md exists.
If found: Read the file. The YAML frontmatter fields phase and
last_completed tell you where intake was interrupted. Present a
summary of what's already captured and offer:
- Resume from the interruption point
- Start fresh (delete the notes file and any partial drafts first)
If resuming into Phase 2, re-read the notes to restore context. If
the notes contain a ## Background Analysis section, use its signal-strength
ratings to calibrate remaining interview domains the same way a fresh
run would (strong = confirmation only, thin = full question set). Also
read .claude/references/developmental-model.md if you haven't yet.
Pick up at the next step not listed in domains_completed — this
includes the five interview domains plus reflection and projects.
If resuming into Phase 3, proceed directly to synthesis sub-agent
dispatch.
If not found: Proceed to Phase 1.
Phase 1: Discover
Scan for materials before asking questions. Read
.claude/references/developmental-model.md first — use it to
calibrate interview questions and identify bridge opportunities.
1a. Scan background materials
Look for a background/ directory in the project root. List its contents
(file names, sizes, types) but do not read file contents yourself.
Produce a file manifest — this is what you'll pass to the analysis
sub-agent.
1b. Dispatch background analysis
If background has files, tell the user you're analyzing their
materials and it will take a moment. Then dispatch a background analysis
sub-agent using the Task tool. Read
.claude/skills/intake/subagents.md § Background Analyzer for the full
dispatch prompt, extraction table, and output schema. Pass the sub-agent
the background path and your file manifest. It reads the files, reads the
developmental model independently, and returns a structured Background
Analysis Report with signal-strength ratings per interview domain.
If the sub-agent fails or returns unusable output, retry once. If it
fails again, tell the user the automated analysis didn't work and
proceed to the interview without background findings — background is an
accelerant, not a gate.
If the background folder is empty or absent, skip the sub-agent.
Explain the convention: background/ is where they can drop materials
(code, resumes, writing, conversation logs, course materials) for a
sharper starting profile. None of it is required — the interview can
build the profile from scratch.
1c. Present findings and offer paths
If a background report was returned, present what it found — be specific
about signals, not just file names. Use the signal-strength ratings to
tell the user what's well-covered vs. thin, and suggest materials that
could fill gaps. Frame it as opportunity, not requirement.
Either way, offer three paths:
- Add materials to background (wait for them, then re-dispatch)
- Point to another directory to read from
- Skip straight to the interview
1d. Initialize intake notes
Create learning/.intake-notes.md with YAML frontmatter:
---
phase: discover
last_completed: discover
domains_completed: []
started: YYYY-MM-DD
---
If a background report was generated, append it as the ## Background Analysis
section. This file is your running record for the rest of intake.
1e. Proceed
Whatever the user chose, move to Phase 2. Background is an accelerant,
not a gate.
Phase 2: Interview
Adaptive conversational interview. The background findings (if any)
inform which questions to ask and which to skip. Target: 10-15 minutes.
If the background was rich, this may be shorter.
Interview protocol
- Conversational, not interrogative. One domain at a time.
- Acknowledge what background revealed before asking related questions.
- Offer to wrap up if the interview exceeds 15 minutes.
Question domains
Work through these domains in order. Background signal-strength
ratings guide depth: strong = confirmation only, moderate =
targeted follow-ups, thin/missing = full exploration. One
follow-up per short answer, max.
1. Background and context — experience level, how they got here,
prior domains. Note prior-domain skills as bridge material.
(→ feeds "How {name} learns" transfer mappings, "Strengths")
2. Goals and aspirations — who they want to become, not what they
want to learn. States of being, not skill checklists. Timeframes if
driving.
3. Current state — concrete skill levels for initial calibration.
What's solid, what's shaky, hardest problem solved recently.
(→ feeds current-state.md)
4. Learning style — how they learn best, how they get unstuck,
what helps vs. annoys. Error patterns.
(→ feeds "How {name} learns", "How {name} gets unblocked")
5. Work and communication preferences — quality standards,
structure vs. flexibility, feedback directness.
Record domain notes
After completing each interview domain, append structured notes to
learning/.intake-notes.md. Format:
## [Domain Name]
[Key findings — specific quotes, concrete details, not summaries]
**Signal strength:** strong | moderate | thin
**Key signals:**
- [most important things learned, bulleted]
Then update the YAML frontmatter: add the domain name to
domains_completed, set phase: interview, set last_completed to
the domain name.
Write as if you will not remember anything that isn't in this file.
This is your compression-resistant record — if context is lost, these
notes are what survives.
Reflect and check
Reflect back a brief portrait: what they're confident about, where
they're stuck, predicted workflow patterns, and bridge material from
prior domains. This is a mirror, not a grade — ask: "Does this sound
right? Anything I'm missing?"
Append a ## Reflection section to intake notes with the summary and
corrections. Update frontmatter: add reflection to
domains_completed, set last_completed: reflection.
Projects
Explore current projects — what they're building, where they are in
it, what they need to learn to finish, and what it means to them. The
why matters as much as the what. Build on anything that surfaced
earlier.
If no current projects, note it for post-intake follow-up.
Append a ## Projects section to intake notes. Update frontmatter:
add projects to domains_completed, set last_completed: projects.
Phase 3: Synthesize
Read learning/.intake-notes.md and verify completeness — all interview
domains, reflection, and projects should be present. If any are missing,
ask the user for that information directly before proceeding to
synthesis. A missing reflection is especially important — the learner
needs to have validated the portrait before it becomes the basis for
their profile.
Tell the user you're generating their personalized learning profile and
it will take a minute (four documents are being drafted in parallel).
Dispatch up to 4 synthesis sub-agents in parallel using the Task tool.
Read .claude/skills/intake/subagents.md § Synthesis Agents for the
dispatch prompt pattern. Each sub-agent receives the full contents of
.intake-notes.md plus its specific template and guidelines (from
sections 3a-3d below — include the relevant section text in the
dispatch prompt).
If a synthesis sub-agent fails or returns unusable output, retry once.
If it fails again, dispatch a fresh sub-agent for that document. Do not
draft the document yourself — keep the main agent's context clean.
The arcs and current-state sub-agents also read
.claude/references/developmental-model.md independently.
Collect all drafts. Review for cross-document consistency: do arcs
reference the same goals? Do current-state concepts align with arcs?
Does the CLAUDE.md calibration match current-state evidence? Fix
discrepancies before presenting to the user.
Update the intake notes: set phase: synthesize,
last_completed: synthesize.
Present all drafts to the user for review before writing anything.
3a. Draft CLAUDE.md
The synthesis sub-agent reads .claude/references/claude-md-template.md
directly. It follows the synthesis annotations (HTML comments) in the
template to populate each section from the intake notes.
The sub-agent emits User through Teaching Mode. It stops there — the
main agent appends the four system invariant sections (Security,
Recovery, Complex operations, Unexpected behavior) verbatim from the
template after collecting the synthesis output.
Phase 3 consistency check: verify the CLAUDE.md draft contains no
HTML comments (catches annotation leak from the template).
The three predictive sections — "How {name} learns", "How {name}
gets unblocked", and "Strengths" — are the highest-value content.
They turn the CLAUDE.md from a preference sheet into a model that
changes how the agent intervenes.
Minimum bar: at least 1 entry each in "How learns" and "How gets
unblocked." Strengths can be sparse if background evidence is thin.
Sparse is fine; empty is not.
Quality bar: each entry should be predictive (changes agent
behavior), not merely descriptive (restates a preference). The
template annotations include examples of the difference — the
sub-agent reads them directly.
3b. Draft learning/goals.md
Goals are the highest level of abstraction — states of being, not skill
checklists. Derived from the interview's goals & aspirations domain.
# Goals
States of being the learner is working toward. Each goal describes who
they want to become, not what they want to learn. Capabilities and
skills emerge from pursuing goals through projects.
## [Goal name]
[1-2 sentences: the aspiration as a state of being.]
**Capabilities required:**
- *(populated as arcs develop)*
Guidelines:
- States of being, not skills. "A developer who ships products
people use" — not "Learn React."
- 2-4 goals, learner's language, timeframes if mentioned.
3c. Draft learning/arcs.md
Arcs are developmental lines that serve goals — the decomposed
capability clusters and skill sequences needed to get there. Lower
abstraction than goals, higher than individual concepts.
Use the developmental model (.claude/references/developmental-model.md)
to structure arcs. Each arc tracks a capability cluster with its
complexity/chunking state and dependencies.
# Arcs
Developmental lines serving goals. Each arc tracks a capability cluster
— a group of related skills that develop together and compound.
## [Arc name]
**Serves:** [which goal]
**Current state:** [brief assessment — note evidence basis: artifact, self-report, or inferred]
**Key skills:** [the specific skills this arc develops]
**Dependencies:** [hard prerequisites, bridge opportunities, altitude gates]
**Next move:** [reps or abstraction, based on complexity-chunking gap]
Guidelines:
- Derive from goals + current state. What capability clusters need
to develop to close the gap between where the learner is and where
they're headed?
- Note bridge opportunities. Any background experience that could
accelerate this arc (from the developmental model).
- Be concrete about next move. The complexity-chunking diagnostic
from the developmental model tells you: reps or abstraction?
- Start sparse. Intake seeds arcs from interview evidence. They
fill in as the learner works on projects and completes sessions.
3d. Draft learning/current-state.md
Seed initial concept entries from the interview. Use the scoring rubric
in .claude/references/scoring-rubric.md for scores, gap types, and
evidence source tags.
Template:
concepts:
- name: concept-name
score: 3
gap: procedural
source: intake:artifact
last-updated: YYYY-MM-DD
Populate entries from concrete evidence in the interview. Guidelines:
- Bias conservative. See rubric — a too-generous 4 hides a concept
from spaced repetition.
- Use specific concepts, not entire domains. "Array methods" not
"JavaScript." "Experimental design" not "statistics." Match the
granularity to the learner's domain.
- Tag the evidence source. Use the intake source tags from the
scoring rubric (
intake:artifact, intake:self-report,
intake:inferred). Session-review will calibrate with quiz-verified
scores later.
- Only include concepts that came up. Don't speculatively populate
a curriculum. Session-review adds concepts from real sessions.
- Gap type from evidence. If they described a wrong mental model,
that's conceptual. If they know the concept but struggle to execute,
that's procedural. If they've done it before but can't recall how,
that's recall. Use
-- if score >= 4 or no gap evidence.
3e. Present and confirm
Present learner-facing drafts: goals, arcs (in plain language — no
developmental model jargon), and current state. Don't lead with
CLAUDE.md — offer to show it after the learner-facing drafts are
reviewed. Present arcs as a conversation, not a spec.
Wait for explicit approval of all drafts before proceeding to Phase 4.
Accept edits — incorporate and re-present if needed.
Phase 4: Write
All file writes are human-gated. Present what you will write and where
before writing.
4a. Check for conflicts
Before writing, check whether target files already exist:
CLAUDE.md — intake writes to ~/.claude/CLAUDE.md (the global
file), replacing the content between <!-- weft:start --> and
<!-- weft:end --> markers. The markers were placed by bootstrap.sh.
- If the markers exist: replace everything between them (inclusive) with
the personalized section (see 4b.1 for the template).
- If no markers found but the file exists: append the personalized
section with markers.
- If no file exists: create it with the personalized section.
If learning/ directory has existing files (current-state.md,
goals.md, arcs.md):
- Warn the user. For each file, offer to merge or skip.
4b. Write approved files
-
Write the personalized weft section to ~/.claude/CLAUDE.md
between the markers. The personalized section has three blocks:
Block 1 — Synthesis output (from § 3a sub-agent):
User, Calibration, How {name} learns, How {name} gets unblocked,
Strengths, Preferences, Conventions, Communication, Teaching Mode.
Block 2 — System invariants (appended by main agent, verbatim
from .claude/references/claude-md-template.md):
Security — Context Files, Recovery after interruption, Complex
operations are decision points, Unexpected behavior — pause and
report. All at ## level.
Block 3 — Weft Harness (path resolution, retained verbatim
from bootstrap):
The full section template between markers:
<!-- weft:start -->
<!-- weft:section-version:2 -->
[Block 1: Synthesis output — User through Teaching Mode]
[Block 2: System invariants — 4 sections at ## level, verbatim]
## Weft Harness
**Harness root:** <harness-root>
### Path resolution
When skills reference harness files, resolve paths from the harness
root above — not from the current working directory:
- `learning/*` → `<harness-root>/learning/*`
- `background/*` → `<harness-root>/background/*`
- `.claude/references/*` → `<harness-root>/.claude/references/*`
- `.claude/consent.json` → `<harness-root>/.claude/consent.json`
When a skill says "read learning/current-state.md", read
`<harness-root>/learning/current-state.md`.
### Architecture
Skills: `<harness-root>/.claude/skills/` (registered globally)
References: `<harness-root>/.claude/references/`
Learning state: `<harness-root>/learning/`
Background materials: `<harness-root>/background/`
<!-- weft:end -->
Note: section-version bumps to 2 (personalized replaces generic).
-
Create learning/ and learning/session-logs/ directories if they
don't exist (resolve from harness root).
-
Write learning/goals.md.
-
Write learning/arcs.md.
-
Write learning/current-state.md.
4c. Wrap up
List every file written/modified with paths. Remind the user everything
is editable. Recommend the getting-started guide as the next step:
/lesson-scaffold guides/getting-started.md
4d. Harness settings
One more thing — Weft keeps your learning profile current by
periodically checking your recent Claude sessions for new evidence.
Every few sessions, it'll suggest updates to your profile. You
always review and approve before anything changes.
The default is to check every 3 days. You can change the interval
or turn it off anytime — just ask Claude to adjust your Weft
settings.
Then ask:
Does every 3 days sound right, or would you prefer a different
interval?
Accept natural language ("that's fine", "make it weekly", "turn it
off"). Map to config values:
| Response | digestInterval | digestMode |
|---|
| Default / "fine" / "sure" | 3 | "suggest" |
| "weekly" / "once a week" | 7 | "suggest" |
| Specific number | N | "suggest" |
| "off" / "don't want that" | — | "off" |
Write the preference to ~/.config/weft/config.json. Read the
existing file first (it may have an updates key from bootstrap).
Merge — don't overwrite.
Example resulting config:
{ "updates": "notify", "digestInterval": 3, "digestMode": "suggest" }
If the user declines or says "off", still write digestMode: "off"
so the hook knows to skip.
Seed the digest timestamp. After writing config, also create
learning/.last-digest-timestamp with today's date (YYYY-MM-DD).
This prevents the very next session from nudging a digest when there's
nothing to digest yet — the window starts from post-intake.
Keep it brief. This is a 30-second interaction, not a settings
walkthrough. One explanation, one question, one write.
4e. Data sharing (optional)
One more thing — this harness can share your learning data to
GitHub. Two things happen if you opt in:
-
At the end of each session review, a short signal gets posted to
the developer's repo — your feedback on how the tool worked, plus
the agent's own observations. You see every signal before it
sends, and you approve or skip each one.
-
A public repo is created on your GitHub account where progress
summaries get posted when you run /progress-review. Teachers,
mentors, or peers can watch that repo and comment with guidance.
What's shared: concept scores, gap types, progress patterns,
goals, and growth edges — the learning data the harness tracks.
What's never shared: conversation content, code, file paths,
background materials, or raw quiz answers.
You can turn this off anytime by deleting .claude/consent.json.
Want to opt in?
If they decline, skip. Don't push.
If they agree:
-
Write .claude/consent.json (creates the consent gate):
{
"repo": "hartphoenix/weft-signals"
}
-
Create the learner's signal repo. Run:
gh repo create learning-signals --public --description "My learning progress — shared with teachers and mentors"
If it already exists, skip creation.
-
Set up labels. Run:
gh label create progress-review --repo USERNAME/learning-signals --description "Cross-session progress summary" --color 0E8A16
gh label create goal-update --repo USERNAME/learning-signals --description "Goal or arc change" --color 1D76DB
gh label create needs-teacher --repo USERNAME/learning-signals --description "Student requesting teacher input" --color D93F0B
gh label create responded --repo USERNAME/learning-signals --description "Teacher has responded" --color BFD4F2
gh label create acknowledged --repo USERNAME/learning-signals --description "Student has seen teacher response" --color C2E0C6
-
Write learning/relationships.md:
signal_repo: USERNAME/learning-signals
teachers: []
students: []
-
Confirm and explain the share link:
You're set up. Your progress repo is at:
https://github.com/USERNAME/learning-signals
If you have a teacher or mentor who'd like to follow your
progress, send them that link — they just Watch the repo on
GitHub. You can add their GitHub handle to
learning/relationships.md anytime, and /progress-review
will assign issues to them automatically.
4f. Clean up
After all approved files are written, delete learning/.intake-notes.md
— it has served its purpose. The learning files are the permanent record.
