| name | learning-synthesis |
| description | Analyzes a day of Slack-thread user sessions to discover opportunities for new skills, personas, tools, workflows, and system-level improvements. Use alongside gap-analysis for the nightly self-improvement workflow. |
Learning Synthesis
Look across the day's sessions not for what went wrong, but for what the system could learn.
Scope
Use this skill when the input is the same batch of reconstructed user tasks given to gap-analysis, and the goal is to find opportunities rather than failures.
Gap analysis asks: "what broke and how do we fix it?"
Learning synthesis asks: "what should we build, know, or become next?"
What To Look For
Scan the evidence packs for these opportunity classes, in roughly this priority:
1. Missing Skills
A user repeatedly asks for a workflow or procedure the bot handles ad-hoc every time. If the same multi-step pattern shows up in 2+ threads, it should probably become a reusable skill with its own SKILL.md, references, and trigger phrases.
Look for:
- Multi-step procedures the bot assembled from scratch each time
- Tasks where the bot had to be walked through a process by the user
- Requests where a skill file would have saved significant back-and-forth
2. Missing Personas
A user needs a consistent stance, voice, or decision-making framework that doesn't match any existing persona. If the bot keeps being asked to "think like X" or "approach this from Y's perspective," that's a persona opportunity.
Look for:
- Repeated "think like a..." or "approach this as..." framing
- Tasks where the user had to repeatedly steer the bot's judgment or tone
- Domains where the existing personas (eng, legal, invest, events) don't cover the user's actual need
3. Domain Knowledge Gaps
The bot had to be taught something by the user that it should already know. If a user corrects the bot about internal processes, team structure, product names, or domain conventions, that knowledge should be baked into a skill, persona, or the system prompt.
Look for:
- User corrections that teach the bot internal facts
- "Actually, the way we do this is..." patterns
- Domain-specific vocabulary or conventions the bot didn't know
4. Tool Opportunities
Users are asking for capabilities that don't exist as tools. If users repeatedly ask the bot to do something it can only hack together with shell commands or workarounds, that's a tool opportunity.
Look for:
- Shell command workarounds for tasks that should be a proper tool
- "Can you access X?" where X isn't an integrated service
- Multi-step tool-call sequences that could be a single higher-level tool method
5. Workflow Automation
Users are doing manual multi-session workflows that could be automated. If you see a pattern like "every Monday the user asks the bot to do X, then Y, then Z," that's a scheduled workflow opportunity.
Look for:
- Recurring temporal patterns (daily, weekly, ad-hoc but regular)
- Multi-turn sessions that follow a predictable structure
- Tasks that a user shouldn't have to ask for because they're predictable
6. System Prompt Improvements
Sessions reveal that the base system prompt or a persona overlay is missing guidance that would prevent recurring confusion.
Look for:
- Cases where the bot misunderstood its role or capabilities
- Tasks where the bot didn't know about available tools or workflows
- Patterns where adding one line to the system prompt would prevent a class of mistakes
Evidence Rules
Use the same evidence packs as gap-analysis. Do not request additional data.
Follow-up messages are provided as raw text. Interpret them semantically to understand what users actually needed, not just whether the task "passed" or "failed."
Focus on patterns across sessions, not individual task quality. A single instance is an anecdote; 2+ instances of the same demand pattern are a signal.
A separate reconciliation step will deduplicate your selected builds against gap-analysis fixes after this pass. Focus on finding the best opportunities; the workflow handles cross-pass merging.
Output Contract
Return JSON only. Use EXACTLY these top-level keys:
{
"sessions_analyzed": 0,
"opportunities_found": 0,
"opportunities": [
{
"title": "Short descriptive title",
"opportunity_type": "new_skill",
"evidence_summary": "What sessions showed this pattern",
"evidence_threads": ["C123:1700.100"],
"what_exists_today": "How the bot handles this now",
"what_should_exist": "What the improvement would look like",
"target_surface": "tools/personas/eng/PROMPT.md",
"implementation_sketch": "Concrete first step — not vague",
"confidence": "high",
"user_value": "Why this matters to users"
opportunity_type values
new_skill — a reusable skill file for a recurring procedurenew_persona — a new persona overlay for a recurring stance/voiceskill_improvement — add references, examples, or steps to an existing skillpersona_improvement — add guidance to an existing persona overlaynew_tool_idea — a tool that should exist but doesn'tnew_workflow_idea — a scheduled or triggered workflow that should existsystem_prompt_improvement — a change to the base system promptdomain_knowledge — factual knowledge that should be baked in somewhere
selected_builds array
From the opportunities list, select up to the workflow-provided maximum for autonomous implementation. Each entry uses the same schema as opportunities but represents a commitment to build, not just an observation.
Only select builds where:
- The pattern appears in 2+ sessions (not a one-off)
- You can name a specific
target_surface (file path)
- The implementation is small enough for one focused PR
- The user value is clear
Each selected build MUST additionally include a slack_narrative field — a 2–4 sentence plain-English note that names the specific users who surfaced the pattern, describes what they were trying to do, and explains why this opportunity is worth building now. Use the source_user_name field on each evidence pack to ground the narrative in real people. This field is posted to the internal ai-v2 Slack channel and is stripped before the implementing agent sees the fix packet, so user names and concrete task details are encouraged here. Do NOT invent situations — stay grounded in provided evidence.
If no opportunity meets that bar, return an empty selected_builds array. Observations still go in opportunities for the scorecard.
What Not To Do
- Do not duplicate gap-analysis findings. If something is a quality bug, it belongs in gap-analysis, not here.
- Do not propose vague "we should be smarter about X" recommendations. Every opportunity must have a concrete
target_surface and implementation_sketch.
- Do not over-index on a single session. One user asking for something once is not a system-level opportunity.
