---
name: learning-session
description: Use when the user asks to start, control, finish, report, or export a private learning session with native Pi tools.
---

# Learning Session

Use this Skill when the user asks to learn with automatic organization, control an active learning session, or finish and generate a report.

## Native Pi lifecycle

Native tools bind to the stable current Pi session identity. A token is never supplied to or returned by native Pi tools, and calls have no host or session-id argument. Capture is not implicit: explicitly call `learning_session_start` at the beginning, optionally with an initial topic and learning goal. Use `learning_session_status` to inspect state, `learning_session_pause` before a private interval, and `learning_session_resume` to continue.

Switching away from an identity stops runtime capture and binding only; it does not change or mutate that identity's persisted learning-session state. Returning to the original active identity restores capture. If the original identity was explicitly paused, it remains paused with no automatic resume.

A new or forked identity is independent, inactive, and unbound until `learning_session_start` is called there. A fork never inherits the source identity's binding or token. Commands such as “do not record this,” “skip this message,” pause, resume, finish, and delete exclude their whole turn rather than only the command text.

Only visible user messages and final assistant messages are captured. Thinking, tool calls, tool results, and compaction summaries are never learning content.

Call `learning_session_delete` only after explicit confirmation that deletion is irreversible. Deletion removes the session content while retaining a content-free barrier that prevents delayed events from recreating it.

## Ordered report protocol

A finish/report request starts this foreground sequence; do not fabricate a giant report command or background polling loop:

1. Call `learning_report_audit_begin` to freeze the run.
2. Paginate with `learning_report_audit_page`, then checkpoint every page with `learning_report_audit_submit`. Continue until no page remains. On interruption, resume from the last accepted checkpoint; retrying an accepted checkpoint is duplicate-safe. Use `learning_report_audit_abort` only when abandoning the run.
3. Paginate `learning_report_organization_material`, organize all audited questions into topics, relations, and one or more trees, then send the complete organization with `learning_report_organization_submit`. Weakly related topics may be separate roots.
4. Paginate `learning_report_section_material`, write the report sections grounded in that material, and send sections plus coverage through `learning_report_section_submit`. If coverage validation fails, repair missing or invalid question coverage and resubmit sections.
5. Call `learning_report_publish` and report completion only after publication succeeds. A report is not complete until section submission and publication succeed.
6. Call `learning_report_export` only when the user requests an explicit destination directory. Export is separate from publication; never invent a destination.

Preserve the returned report-run identifier across all report calls. Publication artifacts are deterministic, so retry publication after a transient failure rather than restarting successful stages.

## Compatibility and privacy

The native Pi workflow above needs no bearer. Claude Code, Codex, MCP, and CLI remain supported legacy integrations: the MCP protocol uses the host session identifier and bearer token returned by its start/resume lifecycle calls. Treat that MCP bearer as secret, supply it only to the MCP server, and never echo it to the user or place it in report content.