Nous self-improving context system overview. Use when the user asks about "nous", "learnings", "knowledge extraction", "context injection", "how does memory work", "how are learnings captured", or wants to understand the self-improvement pipeline.
Explains the self-improving context system that captures and injects learnings across Claude Code sessions.
npx claudepluginhub aeyeops/aeo-skill-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Nous operates through two Claude Code hooks and a statusline trigger:
.claude/nous/ storage and prepends relevant entries so Claude benefits from prior session insights.hooks/nous-logger.sh): A minimal script that reads status JSON from stdin, enriches it with timestamp and hostname, and silently appends to ~/.claude/statusline-activity.jsonl. Produces no stdout output -- it is designed to run in the background without interfering with any visual statusline.Nous does not own or replace the user's statusline. Instead, /nous:setup appends a small trigger block to the bottom of the user's ~/.claude/statusline.sh:
~/.claude/statusline.sh (user-owned)
├── rendering logic (model, git, context bar, etc.)
└── plugin trigger (appended at bottom)
└── pipes $input to hooks/nous-logger.sh in background (&)
This means:
nous-logger.sh) never writes to stdout. The statusline rendering never writes to the activity log. The trigger is the only piece that connects them.~/.claude/statusline.sh (user-owned, set as statusLine.command)
→ reads stdin (status JSON from Claude Code) into $input
→ rendering logic outputs to stdout (visual statusline)
→ trigger block (appended at bottom):
→ pipes $input to hooks/nous-logger.sh in background
→ enriches with meta_ts, meta_host
→ appends to ~/.claude/statusline-activity.jsonl
→ Stop hook reads statusline-activity.jsonl
→ if context >10%, spawns `claude --print` extraction workers
→ workers read the session transcript
→ extract JSONL entries to inbox fragments (.claude/nous/{learnings,knowledge}/inbox.jsonl.*)
→ flush_inbox() consolidates fragments into engram.jsonl / cortex.jsonl
→ next SessionStart hook injects recent entries from engram.jsonl / cortex.jsonl
Extraction uses two perspectives (lenses), each with its own prompt and output format:
learnings/engram.jsonl.knowledge/cortex.jsonl.Each lens runs as a separate claude --print worker process, reading the same transcript but extracting different types of information.
Each project maintains its own nous state in .claude/nous/:
.claude/nous/
├── extraction_cursor.json # Tracks last extracted timestamp to avoid re-processing
├── learnings/
│ ├── inbox.jsonl.* # Raw extraction fragments (temporary, per-worker)
│ └── engram.jsonl # Consolidated learnings (injected at session start)
└── knowledge/
├── inbox.jsonl.* # Raw extraction fragments (temporary, per-worker)
└── cortex.jsonl # Consolidated knowledge (injected at session start)
The extraction_cursor.json file prevents duplicate extraction across sessions. Inbox fragments are named with unique suffixes per worker invocation and consolidated during the flush step.
The Stop hook reads the current context window percentage and applies these rules:
| Context % | Action |
|---|---|
| <10% | Skip entirely -- session too short to contain useful extractable content |
| 10-70% | Flush inbox fragments to engram/cortex + fire extraction workers for new content |
| 70-85% | Flush inbox only -- context too full for safe extraction worker spawning |
| >=85% | Flush inbox + block with /clear recommendation -- context nearly exhausted |
The activity logger is required for nous to function. It provides the context window percentage that drives all threshold decisions. Without it, the Stop hook cannot determine whether extraction should run.
The logger must be triggered from the statusline because that is how Claude Code exposes periodic status data. Run /nous:setup to append the trigger automatically. The setup never replaces your statusline — it only adds silent background logging alongside your rendering.
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.