PIL: Personal Instagram Library

What it does

What this one touches

Not a pure one-paste skill. The source below is the instruction file only. Setup also clones the author's GitHub repo, installs a Python package and the "mcp<2" dependency, and can run the repo's bootstrap script. That code is not in this entry and we have not reviewed it. Reads your own saved Instagram posts through instagram-cli. You link the account in your browser. The source says Muse never handles your password or token. Writes a SQLite database and JSON, HTML and app exports on your computer. The deep-read step calls instagram-cli media-understanding, so post content is processed by that tool, not only on your machine. The optional phone step publishes the app bundle to a static host you choose and needs your hosting token, which is kept in a local config file. Treat it as uploading your library. The submitter's claim that no data leaves the machine does not cover this step. The local MCP server is read-only. Muse asks you before it downloads or runs anything.

Install

Copy this block and paste it into your Muse chat. Muse does the install and confirms when it's done.

Full source

This is the exact text Muse installs. Read it. That's the whole trust model.

---
name: "pil"
description: "Build and query a Personal Instagram Library: ingest your saved Instagram posts into a local SQLite database, run vision-AI deep extraction over them, and query the library live through a read-only local MCP server. Use when the user wants to index, search, or ask questions over their Instagram saved posts."
---

# PIL: Personal Instagram Library

## Purpose
Turn a user's Instagram saved posts into a private, queryable knowledge base that
lives entirely on their own machine: ingest → deep-extract → tag → export, plus a
read-only MCP server so Cursor, Claude Code, or Claude Desktop can query it live.

## Tooling
Helpers live in `bin/` and share config through `bin/pil_common.py`. Config resolves
from `PIL_CONFIG` env var, `./pil.config.json`, then `~/.config/pil/pil.config.json`
(copy `pil.config.example.json` to start). The DB is `<data_dir>/pil.sqlite`;
`schema.sql` is applied automatically on first run.

- `bin/ingest_saved.py [collection_id]`, step 1: saved collections → `folders`,
  saved posts → `posts`/`post_folders`. Resume-safe via cursor files.
- `bin/extract_content.py`, step 2: vision-AI deep read (`instagram-cli
  media-understanding`) → `knowledge` rows (summary, key points, how-to, links)
  plus tags. Resume-safe; batches of 25.
- `bin/tag_all.py`, step 3: programmatic tags (caption keywords + folder names)
  for posts with fewer than 3 tags.
- `bin/export_web.py [output_path]`, step 4: static JSON export for manual use
  with any AI tool. Captions are truncated to snippets, never verbatim.
- `bin/export_html.py [output_path]`, step 5: self-contained HTML dashboard
  (`pil_library.html`): answer-first search with inline citations, source
  cards, thin-result fallbacks and follow-up prompts, plus rooms, tags,
  sorting, read-notes. Works offline from disk; the user can keep it on
  their Desktop as a web app.
- `bin/export_pwa.py [output_dir]`, step 6: installable PWA bundle
  (`index.html` + `manifest.json` + offline service worker + icons) for the
  real browser *Install* prompt, plus one-click launchers: a Mac
  `Start PIL.app` builder (no terminal window), hidden-console Windows
  `Start/Stop PIL.vbs`, and a universal `Start PIL.command`. Serve over
  localhost; Chrome/Edge prompt automatically, Safari/Firefox add manually
  (see README).
- `bin/publish_pwa.py <pwa_dir> [--provider netlify|manual]`, step 7:
  publish the PWA bundle to the user's own private static host for phone
  install; writes `phone.json` + `phone-qr.png` so the desktop PWA shows a
  "Take PIL on your phone" panel with a QR code. Tokens live in the local
  config's `publish` section, never committed. See `MOBILE.md`.
- `bin/mcp_server.py`, read-only MCP server over stdio. Tools: `search_posts`,
  `get_post`, `list_folders`, `list_tags`, `library_stats`.

Requires: `python3`, `instagram-cli` (see the Instagram skill), `pip install "mcp<2"`.

## First-run: setting up the user
When the user asks you to set up PIL (e.g. pastes the prompt from the README):
1. Clone the repo (or pull latest) and work from it. You can run `bootstrap.sh`
   / `bootstrap.ps1` yourself for Python/git/deps, or do the Install steps manually.
2. Link Instagram: `instagram-cli accounts` must list their account. If not, get
   the connect URL (`instagram-cli connect-url`) and have the user link it in
   their browser, then re-check. Never handle passwords or tokens yourself.
3. Run the pipeline in order; every step is resume-safe: `ingest_saved.py` →
   `extract_content.py` → `tag_all.py`. Extraction is slow on large libraries;
   run it in the background and report when done.
4. Build the app with `export_pwa.py`, then **deliver it**: zip the PWA folder,
   put the zip in the user's file area, and attach it to your reply along with
   the 3 install steps (unzip → double-click Start PIL → click Install).
   Also run `export_web.py` and attach `web_data.json`: that's the file they
   hand to any other AI tool.
5. Offer the phone step: `publish_pwa.py` needs their hosting token; collect it
   via the secure credential flow, never in chat. After publishing, make sure the
   QR/URL reaches them (re-serve the folder or send the code directly).
Keep the user posted at each stage; ask only for what only they can do.

## Auth
The user links their own Instagram account themselves. `instagram-cli accounts`
must list it; the `user_fbid` from that output goes into `pil.config.json` as
`account_id`. Never ask for, handle, or store passwords, tokens, or session data.
The pipeline only reads the user's own saved posts.

## Operating Rules
1. **Code is shared, data stays home.** Never copy, upload, or commit a user's
   `pil.sqlite`, exports, captions, or account ID. The package holds code,
   schema, config examples, and docs only.
2. The MCP server is read-only by construction (SQLite `mode=ro`, SELECT-only
   tools). Never add a write tool.
3. Run the pipeline in order: ingest → extract → tag. Export any time after ingest.
4. Deep-extraction headings are normalized in `extract_content.py`
   (`_normalize_labels`): sections read Context / Moment / Significance / Origin.
   Do not reintroduce the word "Cultural".
5. Keep this file lean. Install/usage docs live in `README.md`; per-client MCP
   wiring lives in `references/mcp_clients.md`.

More in Productivity

• Interval Tracker

  Logs recurring events like haircuts and predicts the next due date from your intervals.

  skillLog of every recurring event you report, with the date it happenedAverage, shortest, and longest interval per trackPredicted next due date once a track has a few entriesReminder before the next due date so nothing slipsOne line per track showing the last date and the days since

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Interval Tracker skill, save the skill source below as ~/workspace/skills/interval-tracker/SKILL.md, then tell Muse to use it whenever you report a recurring event, such as a haircut, and want the date logged with a prediction for the next one. --- SOURCE --- --- name: interval-tracker description: Log recurring events such as haircuts and predict the next due date from your own intervals. Use when the user reports a recurring event happened today and wants the date logged, interval stats, or a reminder before it is due again. --- ## Purpose Keep a simple log of the recurring things in your life: haircuts, nail trims, oil changes, filter swaps, and anything else that repeats on a rough rhythm. You report the event in plain words, such as haircut today, and the skill logs the date, keeps the average, shortest, and longest interval per track, and predicts the next due date once a track has enough entries to judge. ## Workflow 1. Take the report: the event name and the date, which defaults to today when you say today. 2. Log it under its track, creating the track on the first report. 3. Compute the intervals between the logged dates for that track: average, shortest, and longest, in days. 4. Predict the next due date from the average interval once the track has at least three entries, and say how confident the prediction is from how steady the intervals are. 5. Offer a reminder a few days before the predicted date, and note when the prediction is based on too little data to trust. 6. Show a one line summary per track: last date, days since, average interval, and next due date. ## Output Contract - A confirmation naming the event and the date logged. - Per track: last date, days since, average interval, shortest interval, and longest interval. - A predicted next due date once three or more entries exist, with a note on how steady the pattern is. - A reminder offer before the next due date. ## Operating Rules - Never invent a date. Log only what the user reports. - Do not predict from fewer than three entries; say the track needs more data. - Report the average, shortest, and longest interval, not just the average, so a lopsided pattern stays visible. - Keep each track separate; a haircut interval never mixes with a nail trim interval. - Reminders are suggestions only. Never book, order, or schedule anything on the user's behalf.

• Warranty Claim Helper

  Turns a broken product and its warranty terms into a ready-to-send claim draft.

  skillCoverage check against the warranty terms you paste inEvidence checklist: receipt, photos, serial number, and datesClaim draft ready to send to the maker or retailerPlain verdict when coverage has expired or the damage is excludedFollow-up tracker with claim number and dates

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Warranty Claim Helper skill, save the skill source below as ~/workspace/skills/warranty-claim-helper/SKILL.md, then tell Muse to use it whenever a product breaks and you need to file a warranty claim. --- SOURCE --- --- name: warranty-claim-helper description: Help file a warranty claim for a broken product. Use when a product breaks under warranty, when the user wants to check what a warranty covers, or when they need a claim draft with the proof to attach. --- ## Purpose Turn a broken product and a warranty document into a claim that is ready to send. The skill reads the warranty terms, checks what is covered and what is excluded, lists the proof the maker will ask for, and drafts the claim message with the facts filled in. It is the filing step, not a tracker: it starts when something breaks and ends with a draft you can send. ## Workflow 1. Collect the facts: product name and model, serial number if there is one, purchase date and place, and what went wrong and when. 2. Read the warranty terms the user pastes in: coverage length, what is covered, what is excluded, and how claims are filed. 3. Give a coverage verdict: covered, likely excluded, or expired, with the exact term that decides it quoted in plain words. 4. Build the evidence checklist: receipt or order record, photos of the fault, serial number photo, and any prior repair notes. 5. Draft the claim: a short message to the maker or retailer with the product facts, the fault, the warranty term that covers it, and the remedy asked for. 6. Set up the follow-up: claim number, date sent, and the next date to chase it if no reply comes. ## Output Contract - A coverage verdict with the deciding warranty term in plain words. - An evidence checklist with each item marked as have it, need it, or not applicable. - A claim draft ready to send, with product facts, fault, covering term, and remedy asked for. - A follow-up note: where to send the claim, the claim number once filed, and the date to chase it. ## Operating Rules - Never file the claim for the user; the user always sends it. - Never invent a purchase date, serial number, or receipt. If a fact is missing, ask for it or mark it as missing. - Say plainly when coverage has expired or the damage looks excluded, and do not draft a claim that cannot succeed. - Quote the deciding warranty term in plain words so the user can check it. - Keep the draft short and factual, with no extra blame or apology.

• Contractor Quote Requester

  Turns a job description into a clear quote request you can send to three contractors.

  skillJob brief with scope, materials, and timelineQuote request message ready to send to each contractorApples-to-apples quote comparison tableQuestions that surface hidden costs and exclusionsRed-flag checklist for vague or one-line quotes

  by Muse Skills editors · Written for this directory

  ViewCopy install promptTo install the Contractor Quote Requester skill, save the skill source below as ~/workspace/skills/contractor-quote-requester/SKILL.md, then tell Muse to use it whenever you need quotes for a job and want the replies to be easy to compare. --- SOURCE --- --- name: contractor-quote-requester description: Turn a job description into a clear quote request for contractors. Use when the user says "get quotes", "contractor quote", "quote request", "compare contractor quotes", "hire a contractor", or describes a job and asks what to send to contractors to get comparable prices. --- ## Purpose Turn a job description into a quote request that gets complete, comparable answers. A vague ask gets vague quotes: one contractor includes cleanup, another does not, and the prices cannot be compared. This skill writes one clear brief for you to send to every contractor, then lines the replies up in a table so the differences are easy to see. ## Workflow 1. Collect the job: what needs doing, where, measurements, materials, and the timeline. Ask for photos when they help a contractor price the work. 2. Draft the request: scope, specs, materials, site access, timeline, and exactly what the quote must include, in one message ready to send. 3. Show the exact message for each contractor. The user approves each message and sends it themselves, to three contractors when possible, so every reply answers the same questions. Never send a message for the user. 4. Build the comparison table: price, materials, labor, timeline, warranty, payment schedule, and exclusions, one column per contractor. 5. List the follow-up questions: permits, cleanup, disposal, change orders, and anything a quote left out. 6. Flag the red flags: one-line quotes, no materials listed, no timeline, or a price far below the rest with no explanation. ## Output Contract - A job brief: scope, specs, materials, access, and timeline. - A quote request message ready to send to each contractor. - A comparison table: price, materials, labor, timeline, warranty, and exclusions per contractor. - A follow-up questions list for anything a quote left out. - A red-flag checklist for vague or one-line quotes. ## Operating Rules - Never invent a price, a timeline, or a material. If a number is missing, ask for it or mark the brief as partial. - Never recommend a contractor or vouch for one; the user checks licenses, insurance, and references. - Never send a message to a contractor. The user approves the exact message for each contractor and sends it themselves. - Use the same brief for every contractor so the quotes stay comparable. - Flag any quote that skips permits, materials, cleanup, or disposal, and say what to ask before signing. - Keep the comparison table honest: mark what a quote left out instead of guessing it.

• Instagram Saved Reels Sort

  Files your Instagram saved reels into your own topic collections, two pages at a time.

  skillinstructionspython scriptssetupreview files

  shared by chinami-michaels

  ViewCopy install promptInstall the "Instagram Saved Reels Sort" skill. Its full source is below. Create it at ~/workspace/skills/instagram-saved-reels-sort/SKILL.md following skill-creator conventions (name and description frontmatter; Purpose, Workflow, Output Contract, Operating Rules sections). Then confirm it is installed and tell me the trigger phrases. This skill also runs scripts from https://github.com/chinami-michaels/instagram-saved-reels-sort that the source below does not contain. Before you clone anything, tell me what you will download, and wait for my yes. Clone the repository into ~/workspace/skills/instagram-saved-reels-sort, compare its SKILL.md with the source below, and tell me if they differ. Read each script in bin/ and tell me what it does before you run it. Do not run setup until I say go. --- SOURCE --- --- name: "instagram_saved_reels_sort" description: "Sort Instagram saved reels into the user's topic collections, in small reviewable batches. Use when the user asks to sort saved reels, run a recurring sort, or work through a saved-reels backlog. Requires a connected Instagram account (instagram-cli)." --- # Instagram Saved Reels Sort ## Purpose Move saved Instagram reels out of the unsorted Saved bucket into the user's own topic collections, two pages at a time, with a human review step before anything moves. Built for backlogs of hundreds or thousands of saved reels, and for a light recurring run that keeps new saves filed. ## Requirements - An agent environment with the `instagram-cli` tool available and the user's Instagram account connected (`instagram-cli accounts` must return an account). This skill was built for Muse; on other platforms, substitute the equivalent commands for listing saved posts, describing media, managing saved collections, and moving posts between collections. - Python 3 (standard library only). ## Setup (one time) 1. Run `python3 bin/setup.py`. It verifies the Instagram connection, lists the user's existing saved collections, and walks through defining topics. 2. The user picks a short theme key per topic (e.g. `ai`, `recipes`, `travel`). Collections that don't exist yet are created on Instagram. 3. Setup writes `~/.instagram-saved-reels-sort/config.json` (account id and the key → collection-id map) and a starter `~/.instagram-saved-reels-sort/my-collections.md`. 4. The user writes their routing rules (which reels go where, plus the edge cases) into `my-collections.md`. See `references/collections-template.md` for a worked example. This file is the source of truth for every batch; keep it current as tastes change. ## Tooling Helpers live in `bin/`; all state (config, cursor, batch files) lives in `~/.instagram-saved-reels-sort/`, never in `/tmp`, which can be wiped without warning and would lose your place mid-sort. - Fetch a batch: `python3 bin/fetch_batch.py fetch 2 <label>`: pulls 2 pages of saved posts (50/page), keeps reels, runs media-understanding, writes `<label>_reels.json` and `<label>_review.txt`, advances `cursor.txt`. - Re-sync a lost cursor: `python3 bin/fetch_batch.py advance <pages>`: walks forward N pages without processing. - Sort a batch: `python3 bin/sort_batch.py --batch <label> --map <map.json>`: moves reels into collections per a `{media_id: theme_key}` map. Collection map and routing rules: the user's `my-collections.md` (template: `references/collections-template.md`). Step-by-step with examples and troubleshooting: `references/batch-procedure.md`. Dining dossiers (opt-in per-restaurant health-inspection + review-trend reports for food-spot reels): `references/dining-dossier.md`. ## Workflow 1. Fetch one batch (`fetch 2 <label>`), then read `<label>_review.txt`. 2. Assign every reel a theme key per the user's `my-collections.md`, or leave it unassigned (stays in Saved). 3. Write the map to `<label>_map.json` (`{"<media_id>": "<theme_key>"}`), run the sorter. 4. Report per-collection move counts plus the unsorted leftovers with reasons. Repeat these steps for each batch. ## Output Contract After each batch: counts moved into each collection + list of reels left unsorted (with reason, e.g. no description). ## Operating Rules 1. Two pages per batch: keeps reviews human-sized. Continue to the next batch only when asked, or during a full scheduled run. 2. Never move a reel with no usable description and no inferable content; unsortable reels stay in Saved. 3. Write actions only move posts between collections: nothing is deleted, unpublished, or unsaved globally. Say that plainly to the user before the first sort. 4. The cursor file is the source of truth for progress; if it looks stale, re-sync with `advance` rather than guessing pages. 5. Confirm the first batch's moves with the user before running unattended. After that, a recurring run (e.g. weekly) can process everything saved since the last batch until caught up. 6. Dining dossiers are opt-in: after a batch, offer one for any reel filed into a food/dining collection that's about a specific restaurant, or run one on demand. Never auto-run them for every food reel.