Warranty Claim Helper

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

skillProductivityCoverage 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

To 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.

View source

Ready to copy.

Details

Type: skill
Category: Productivity
Version: 1.0.0
Added: 9 Nov 2026
Author: Muse Skills editorsWritten for this directory
Includes: Coverage 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
Source: github.com/…/warranty-claim-helper.md

To 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.

Before you install

A shared skill carries somebody else's instructions. Read the source before you install it.
Never paste an API key, password, or token into anything a skill asks for. Legitimate skills use Muse's own secure flows.
Installing copies the setup into your own environment. It gives the author nothing.

What it does

What it includes

A broken appliance or gadget leaves you with a warranty document, a receipt somewhere, and a claim form that wants exact facts. This skill takes the product details, the purchase record, and the warranty terms you paste in, then checks what is covered and what is excluded and gives a plain verdict: covered, likely excluded, or expired, with the deciding term quoted in plain words. It builds an evidence checklist for the receipt, photos of the fault, the serial number, and any prior repair notes, marking each one as have it, need it, or not applicable. Then it drafts the claim message with the product facts, the fault, the covering term, and the remedy you want, ready to send to the maker or retailer. It also sets up the follow-up, with the claim number, the date sent, and the date to chase it if no reply comes. It never files the claim for you, and it never invents a purchase date, serial number, or receipt. If coverage has expired or the damage looks excluded, it says so instead of drafting a claim that cannot succeed.

Example

Your two year old blender stops spinning, and the maker offers a three year limited warranty that covers the motor but not the jar. You paste in the warranty terms and the order record. The skill confirms the motor is covered, lists the receipt, a photo of the serial plate, and a short video of the fault as the evidence to attach, and drafts a message asking for a motor replacement under the three year term. It notes the date to send it and the date to chase it if the maker has not replied in a week.

What this one touches

Never files the claim for you; you always send it yourself. Never invents a purchase date, serial number, or receipt. Says plainly when coverage has expired or the damage looks excluded, instead of drafting a claim that cannot succeed.

Install

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

Install prompt

To 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.

To 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.

Full source

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

SKILL.md

---
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.

---
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.

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
ViewTo 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.
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
ViewTo 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
ViewInstall 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.
PIL: Personal Instagram Library
Turns your Instagram saved posts into a private, searchable library on your own computer.
skillinstructionspython packagelocal databasemcp server
shared by pjpoulose
ViewInstall the "PIL: Personal Instagram Library" skill. Its full source is below. Create it at ~/workspace/skills/pil/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 needs code from https://github.com/pjpoulose/PIL: a Python package and scripts that the source below does not contain. Before you clone, download, install, or run anything, tell me exactly what you will fetch and run, and wait for my yes. Do not ask me for a password or token in chat. --- SOURCE --- --- 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`.