---
name: zingage-learn
description: Extract and store learnings from the current work/coding session into your work knowledge base. Run at the end of a session or whenever the user invokes /zingage-learn. Captures technical patterns, architecture decisions, domain knowledge, engineering practices, and problem-solving stories.
---

# Zingage Learn — Session Learning Extraction

Capture the most valuable learnings from the **current conversation** into persistent storage at `~/.claude/zingage-kb/knowledge/<company>/`. This knowledge base is queried later via `/zingage-query` for interviews, resumes, and performance reviews.

> **Vault conventions — read first.** This is an Obsidian knowledge base; every note carries frontmatter and wikilinks per `~/.claude/zingage-kb/CONVENTIONS.md`. The entry template and steps below already encode the relevant rules.

## Storage Layout

One **module** per employer/company. The slug is a lowercase, kebab-case company name (e.g. `acme`, `initech`).

```
~/.claude/zingage-kb/knowledge/<company>/
├── LEARNINGS.md        ← index: one line per dated entry
├── entries/
│   └── YYYY-MM-DD.md   ← one file per day (append if it already exists)
└── topics/
    ├── technical.md     ← languages, frameworks, libraries, tools, patterns actually used
    ├── domain.md        ← your product/industry concepts, business context, jargon
    ├── architecture.md  ← module boundaries, data flow, schema design, system-design decisions
    └── engineering.md   ← code review norms, CI/CD, testing philosophy, debugging approaches
```

## Steps

### 1. Resolve the module (company)

Look at existing `~/.claude/zingage-kb/knowledge/*/` directories:

- **Exactly one module exists** → use it.
- **None exist** → ask the user: **"Which company/employer are these learnings for?"** and use a kebab-case slug of their answer as `<company>`.
- **Multiple exist** → ask which one this session belongs to (or infer from the repo/context and confirm).

Use the chosen slug as `<company>` everywhere below and as the `module` frontmatter value.

### 2. Mine the current conversation

Scan the full session history visible in context for learnings in these 5 categories. Be selective — capture insights that would be **worth retelling in an interview or putting on a resume**, not routine activity logs.

- **Technical** — language/framework patterns actually used or learned: type-system techniques, API/schema design, database queries, async/workflow patterns, frontend patterns, notable tools/libraries/MCP servers.
- **Architecture** — module boundary decisions, data-flow tracing (producer → canonical layer → consumer), integration patterns, "fix the root cause, not the symptom" style decisions.
- **Domain** — concepts specific to your company's product and industry, business context, the vocabulary insiders use, how the core systems actually work.
- **Engineering practices** — code review norms, CI/monorepo workflows, testing philosophy, debugging techniques, observability/monitoring.
- **Problem-solving** — tricky bugs solved, non-obvious decisions, mistakes made and lessons learned. These become STAR interview stories — capture the situation, what made it hard, what you did, and the outcome.

A category with nothing notable today can be omitted from the entry. Quality over completeness.

### 3. Ask for extras

Ask the user: **"Anything else from today you want to capture? (a key decision, insight, mistake, or context I might have missed?)"** Incorporate their answer into the appropriate categories.

### 4. Ensure storage exists

```bash
mkdir -p ~/.claude/zingage-kb/knowledge/<company>/entries ~/.claude/zingage-kb/knowledge/<company>/topics
```

### 5. Write the dated entry

Write (or append to, if a session already ran today) `~/.claude/zingage-kb/knowledge/<company>/entries/YYYY-MM-DD.md`:

```markdown
---
type: entry
module: <company>
date: YYYY-MM-DD
tags: []   # theme tags from CONVENTIONS §3
---

# YYYY-MM-DD

## Technical
- ...

## Architecture
- ...

## Domain
- ...

## Engineering Practices
- ...

## Problem-Solving
- ...

## Extra Notes
- (user-provided additions, if any)

## Related
- Index: [[LEARNINGS]] · Topics fed: [[technical]] / [[architecture]] / [[engineering]] / [[domain]] (only those you appended to)
```

Each bullet should be self-contained — readable months later without the session context. Include concrete names (file paths, system names, pattern names) so future queries can ground answers in specifics. The `## Related` wikilinks keep the entry connected — never skip them.

### 6. Append durable insights to topic files

For each insight that is **reusable knowledge** (not just "what happened today"), append it to the matching file under `topics/`. Use a `## YYYY-MM-DD` subheader per session; create the file with frontmatter (`type: topic`, `module: <company>`) + a `# <Topic>` title if it doesn't exist yet, and wikilink that day's entry (`[[YYYY-MM-DD]]`). **Always append — never overwrite existing topic content.** Skip insights already captured in a topic file from a previous session.

### 7. Update the index

Append one line to `~/.claude/zingage-kb/knowledge/<company>/LEARNINGS.md` (create with a `# <Company> Learnings` header if missing):

```markdown
- [[YYYY-MM-DD]]: <one-sentence summary of the session's main learning>
```

### 8. Confirm

Tell the user what was captured (category counts + the one-line summary) and remind them they can query it anytime with `/zingage-query`.

## Scheduling note

There is no automated trigger; run this manually at the end of each workday. To automate a reminder, use the `/update-config` skill to add a Stop hook or notification.