Self-Improvement Intake
SkillDev toolsCapture reasoning traces from user feedback, approvals, rejections, reroutes, expert learnings, and strategic decisions so Parker improves over time.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Self-Improvement Intake skill
What this skill tells your AI
The instructions your AI receives, as published by real-simple-labs/parker-brain in .claude/skills/self-improvement-intake/SKILL.md and read by ahel’s review.
Goal
Turn important feedback from normal conversation into durable Parker learning. The saved unit is the reasoning trace: what happened, the decision context behind it, why it mattered, what rule Parker should infer, where it applies, and what should change.
The canonical method lives at self-improvement/self-improvement-system.md. Read it before creating or updating traces.
When this skill runs
Run this skill when Jimmy corrects Parker, approves a direction for a specific reason, rejects a direction, reroutes where content belongs, says something should become a rule, explains a taste boundary, or asks Parker to improve from a conversation.
This skill can also run after expert-signal intake when the expert source changes Parker's product architecture or operating method.
How this skill runs
-
Identify the learning moment. Decide whether the user's message contains a durable lesson or only local feedback.
-
Capture the decision context, with the full moment verbatim. Preserve why the user made the correction or decision and the historical context that shaped it: prior related decisions, rejected paths, examples, constraints, and tradeoffs. Do not save only the changed output. And keep the real scene word for word — their exact words, the Parker output they were reacting to, and enough of the surrounding exchange to understand why the rule exists. A correction is meaningless without the thing it corrected. This verbatim-full-moment capture is a hard rule from
self-improvement-system.md; when more history is needed, keep more. If the decision context is not explicit, invite the user to context dump or confirm Parker's inferred read before promotion. -
Classify scope. Use the narrowest accurate scope: local output, user, brand, team, skill, prompt family, system, or product architecture. A learning about the person — who they are, their process, their craft, how they like Parker to work, or a standing rule they set for themselves — is
user-scoped. -
Route to the living surface. User-specific lessons go to
users/[user-id]/user-profile.md(their rules, process, craft, preferences) and roll up tooperations-and-team.md, the team profile, and the user-by-user part ofbrand-notes-from-org.mdwhere they touch how work gets done. Brand-specific lessons go to brand memory or brand rules. Expert method signals go through expert insights. Prompt or skill lessons become candidates. System-level lessons go to self-improvement traces and, when approved, canonical docs. -
Create or update a trace. Save new traces under
self-improvement/reasoning-traces/[YYYY-MM]/. If an existing trace or pattern already covers the lesson, update it rather than creating a duplicate. -
Keep Jimmy in the loop. Parker may create a candidate trace from an inferred lesson, but Jimmy must confirm the why and the relevant historical context before the trace becomes a promoted rule.
-
Promote carefully. Do not update prompts, skills, or system docs from one trace unless Jimmy explicitly approves the promotion or the trace is repeated and already aligned with canonical direction.
-
Report back. Tell the user what Parker learned, where it landed, what is still only a candidate, and where Parker needs the user's why.
Trace categories
- User learning: who the person is, their process, their craft, how they like Parker to work, or a standing rule they set — routes to their user profile.
- Strategic decision: why a strategy split, recommendation, or direction changed.
- Hypothesis edit: why Parker's explanation of what worked was corrected.
- Context rule: what Parker should load, avoid loading, or treat as canonical.
- Prompt rule: how a prompt family should behave.
- Skill rule: how a runtime skill should reason or execute.
- Taste boundary: what quality bar, style, or creative judgment Parker should preserve.
- Product rule: how Parker v2 itself should be structured.
Hard rules
- Do not save every chat turn.
- Do not over-promote one-off feedback.
- Do not silently infer the why or the missing history. Ask when the decision context is unclear.
- Do not blur brand-specific rules with global Parker rules.
- Do not create new docs when an existing trace, pattern, or living surface can absorb the learning.
- Do not rewrite prompts or skills from one trace without approval.
- Always preserve source, scope, status, and promotion condition.
- Keep the full moment verbatim — their words, the Parker output, the surrounding exchange — never a paraphrase. This is the hard rule the Anthropic team stressed, and it is what keeps a rule from drifting.
- When the user says "make this a rule," treat it as strong evidence and update the right canonical surface if the scope is clear.
Output structure
Learning Captured
Name the trace or existing surface updated.
Scope
State whether the lesson is local, brand, team, skill, prompt-family, system, or product architecture.
Routing
List what changed and what remains in review.
Next Watch
Name what Parker should watch for in future conversations to confirm, reject, or sharpen the rule.
Signals
- GitHub stars
- 87
- Forks
- 25
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
self-improvement-intake- Source
- github.com/real-simple-labs/parker-brain