pp-learn-loop-example

What this skill does

# Learn Loop Example — Printing Press CLI

## Prerequisites: Install the CLI

This skill drives the `learn-loop-example-pp-cli` binary. **You must verify the CLI is installed before invoking any command from this skill.** If it is missing, install it first:

1. Install via the Printing Press installer. It defaults binaries to `$HOME/.local/bin` on macOS/Linux and `%LOCALAPPDATA%\Programs\PrintingPress\bin` on Windows:
   ```bash
   npx -y @mvanhorn/printing-press-library install learn-loop-example --cli-only
   ```
2. Verify: `learn-loop-example-pp-cli --version`
3. Ensure the reported install directory is on `$PATH` for the agent/runtime that will invoke this skill.

If the `npx` install fails before this CLI has a public-library category, install Node or use the category-specific Go fallback after publish.

If `--version` reports "command not found" after install, the runtime cannot see the binary directory on `$PATH`. Do not proceed with skill commands until verification succeeds.

Golden fixture exercising the spec-declared self-learning loop. Demonstrates
the shape every printed CLI gets when its spec declares a `learn:` block:
the generator emits internal/learn/* subpackages, the teach/recall/learnings
commands, the v3 store schema additions, and the self-learning sections in
README.md / SKILL.md / AGENTS.md.

The underlying resource surface mirrors the sync-walker fixture (top-level
games + walker-fanned-out leagues) so the emitted shape covers the typical
multi-file CLI alongside the learn package. Identifiers in the learn block
are intentionally neutral (EXAMPLE-* ticker, ALPHA/BRAVO entities) so the
scripts/verify-learn-purity.sh gate cannot trip on this fixture.


## When Not to Use This CLI

Do not activate this CLI for requests that require creating, updating, deleting, publishing, commenting, upvoting, inviting, ordering, sending messages, booking, purchasing, or changing remote state. This printed CLI exposes read-only commands for inspection, export, sync, and analysis.

## Command Reference

**games** — Top-level games resource. The list endpoint populates the generic resources table; rows carry a `game_key` field that the walker's leagues endpoint extracts for child fan-out.

- `learn-loop-example-pp-cli games` — List games

**leagues** — Leagues, fetched per-game by walking games and extracting each game's game_key into the child path.

- `learn-loop-example-pp-cli leagues <game_key>` — List leagues for a game


### Finding the right command

When you know what you want to do but not which command does it, ask the CLI directly:

```bash
learn-loop-example-pp-cli which "<capability in your own words>"
```

`which` resolves a natural-language capability query to the best matching command from this CLI's curated feature index. Exit code `0` means at least one match; exit code `2` means no confident match — fall back to `--help` or use a narrower query.

## Auth Setup

Run `learn-loop-example-pp-cli auth setup` for the URL and steps to obtain a token (add `--launch` to open the URL). Then store it:

```bash
learn-loop-example-pp-cli auth set-token YOUR_TOKEN_HERE
```

Or set `LEARN_LOOP_TOKEN` as an environment variable.

Run `learn-loop-example-pp-cli doctor` to verify setup.

## Agent Mode

Add `--agent` to any command. Expands to: `--json --compact --no-input --no-color --yes`.

- **Pipeable** — JSON on stdout, errors on stderr
- **Filterable** — `--select` keeps a subset of fields. Dotted paths descend into nested structures; arrays traverse element-wise. Critical for keeping context small on verbose APIs:

  ```bash
  learn-loop-example-pp-cli games --agent --select id,name,status
  ```
- **Previewable** — `--dry-run` shows the request without sending
- **Offline-friendly** — sync/search commands can use the local SQLite store when available
- **Non-interactive** — never prompts, every input is a flag
- **Read-only** — do not use this CLI for create, update, delete, publish, comment, upvote, invite, order, send, or other mutating requests

### Response envelope

Commands that read from the local store or the API wrap output in a provenance envelope:

```json
{
  "meta": {"source": "live" | "local", "synced_at": "...", "reason": "..."},
  "results": <data>
}
```

Parse `.results` for data and `.meta.source` to know whether it's live or local. A human-readable `N results (live)` summary is printed to stderr only when stdout is a terminal AND no machine-format flag (`--json`, `--csv`, `--compact`, `--quiet`, `--plain`, `--select`) is set — piped/agent consumers and explicit-format runs get pure JSON on stdout.

## Automatic learning

This CLI ships a self-learning loop: agents `recall` before doing discovery walks, fire `teach` in the background after answering, and record playbooks when discovery is expensive. Repeat questions skip discovery; structurally similar questions get answered via entity substitution; a `playbook amend` call lets future-you fix observed CLI gotchas.

### Step 1: `recall` before any discovery

Before list/search/drill commands on a new user question, run:

```bash
learn-loop-example-pp-cli recall "<user's question>" --agent
```

The response envelope:

```json
{
  "query": "...",
  "normalized": "<normalized form>",
  "query_entities": ["..."],
  "found": true | false,
  "match_score": 0.0,
  "results": [
    { "resource_id": "...", "resource_type": "...", "venue": "...",
      "confidence": 2, "entity_match": "exact|partial|unknown",
      "source": "taught|preseed|pattern", "warnings": ["..."] }
  ],
  "mismatches": [ /* only when --debug-mismatches */ ],
  "warnings": [ /* top-level */ ],
  "playbook": {
    "query_family": "...",
    "playbook": {
      "steps": [ { "cmd": "<command with {slot} substitution>", "purpose": "..." } ],
      "entity_slots": ["$ENTITY"],
      "expected_tool_calls": 3
    },
    "slots_resolved": { "$ENTITY": { "token": "<live token>", "canonical": "<canonical>" } },
    "notes": "<workarounds + gotchas for this query family>"
  },
  "notes": "<duplicate surface for non-playbook callers>"
}
```

### Step 2: six-branch decision tree

Read `playbook`, `notes`, `results[0]`, and warnings in that order:

```
if Playbook present:
    -> READ Playbook.notes verbatim FIRST (workarounds + gotchas the CLI surface doesn't expose)
    -> replay Playbook.steps in order, substituting Playbook.slots_resolved entries
       for the entity slot tokens. If a step's slot is unresolved, fall back to
       discovery for that step only.
    -> the Playbook's expected_tool_calls is a budget; if you find yourself running
       materially more, record the divergence via `learn-loop-example-pp-cli playbook amend`
       at end-of-session.

elif Notes present (no Playbook):
    -> read Notes verbatim before any discovery step; they carry known gotchas
       for this query family even when no structured choreography exists yet.

elif Found AND Results[0].EntityMatch == "exact" AND Results[0].Confidence >= 2:
    -> skip discovery; fetch live data for Results[*].ResourceID in parallel

elif Found AND Results[0].EntityMatch == "partial":
    -> candidate hint, NOT a hit; read the resource title to validate before trusting

elif (any row in Mismatches[] when --debug-mismatches was passed):
    -> treat as cold start; the stored learning is for a different entity
       (different canonical resolved from query_entities)

else:  // Found == false, no playbook, no notes
    -> cold start; run discovery normally; teach the answer afterward AND record
       a playbook + notes via `teach --playbook-file --playbook-notes-file` so the
       next session of the same family is faster.
```

Playbook and Notes are orthogonal to the per-resource path. A recall response can carry both a Playbook AND a `Results[]` hit — use both: the Playbook tells you which choreography to run; the resource hits short-circuit specific steps. Default to skipping `mismatches`; pass `--debug-mismatches` only when investigating col