Set up your studio.

You are packaging this project so it can be sold on Unmetered as a downloadable zip. Buyers get the full source under a single-organization license and run it themselves, so the package must contain no secrets and no client data, and it must run from a fresh unzip by following INSTALL.md. Work from the project root. Never modify or delete my real .env file, and never print a secret value anywhere (the first 4 characters at most). Do not use em dashes in anything you write.

Work through these stages in order. After each stage, tell me what you found and changed before moving on, and stop to ask me whenever a decision is mine.

1. Understand it
Read the whole tree. Tell me in a few lines what this tool does, its entry points, how it is started, and which external services it calls. List every file over 1 MB.

2. Find every secret and every client-specific value
Search all text files, including config, scripts, notebooks, docs, tests, fixtures and CI files, for:
- Key patterns: AKIA followed by 16 characters, sk_live_ or sk_test_, whsec_, ghp_ gho_ ghu_ ghs_ ghr_, xoxb- xoxa- xoxp- xoxr- xoxs-, re_ followed by 20 or more characters, "BEGIN PRIVATE KEY", AIza followed by 35 characters, sk- followed by 32 or more characters (OpenAI and Anthropic keys), SG. (SendGrid), EAA (Meta), hf_, npm_, GOCSPX-, shpat_ and its siblings, Slack and Discord webhook URLs, JSON web tokens starting eyJ (a Supabase service-role key is one), and any long random string assigned to a name containing key, secret, token, password, passwd, pwd, auth, bearer, credential, client_secret, dsn or connection string, plus URLs of the form user:password@host.
- Files that hold credentials: .env and any .env.* other than .env.example, *.pem, *.p12, *.key, *.pfx, service-account*.json, credentials*.json, .npmrc, .netrc, .htpasswd, kubeconfig, terraform state, saved cookies or session files.
- Client-specific values: account ids, ad account ids, property ids, spreadsheet or document ids, Slack channel or workspace ids, customer or employee names and emails, client domains, internal URLs, database names, and anything named after a specific customer.
- Data: exports, CSVs, SQL dumps, logs, caches, screenshots, recordings, notebook outputs, and sample data that came from real accounts.
Report the full list with file paths.

3. Strip and generalise
For each finding:
- Real secrets: move the value to an environment variable read at runtime, replace the hardcoded value in the source, and add the variable to .env.example with a placeholder and a one-line comment on where to get it. Delete credential files from the tree.
- Client-specific ids and names: turn them into environment variables or a small config file with example values, or delete them if the tool does not need them. Replace real sample data with small synthetic samples.
- Live systems: if this copy is wired to my own databases, workspaces, spreadsheets or accounts, it is the copy that ships: duplicate anything that holds data, point every connection at placeholders in .env.example, delete seeded rows, client records and uploads, and leave migrations or a setup script so a buyer can create their own empty instance.
- Git history: tell me whether any of these values were ever committed, so I can rotate them. Do not rewrite history.
Ask me before deleting anything you are not certain about.

4. Remove what should not ship
node_modules, vendor and virtualenv folders, .git, build output (dist, build, .next, out, target, __pycache__, .pytest_cache), coverage, caches, OS and editor files (.DS_Store, Thumbs.db, .idea, and .vscode unless it holds project settings), and any archive or binary over 1 MB the tool does not need to run. Add or update .gitignore to match. Check the dependency licenses and tell me about any GPL, AGPL or LGPL package: copyleft dependencies need a decision from me.

5. Write .env.example
Every environment variable the tool reads, in the order a buyer will fill them in. Each entry is a comment line saying what the variable is for, whether it is required or optional, and the exact place to get it (a URL where possible), followed by NAME=placeholder. No real values. Variables the host sets on its own (PORT, RAILWAY_* and the like) get a comment line saying so rather than a value, and the code must treat a placeholder value from this file as unset, never as configured.

6. Write INSTALL.md
A numbered guide for a buyer who has just unzipped the folder and has never seen the code:
- Prerequisites with exact versions (runtime, package manager, CLI tools) and the command to check each.
- Accounts and keys they need, where to get each, and which permissions or scopes to grant.
- Install commands, copied exactly.
- Configuration: copy .env.example to .env and fill each value, referring to the comments.
- How to run it: the command for a one-off run and, if relevant, on a schedule or as a service.
- How they will know it worked: the exact output or screen they should see the first time.
- The five most likely errors and the fix for each.
- Where the moving parts are, so they can customise it: the main files and what each does.
Plain markdown, short sentences, no hype, no em dashes.

7. Write README.md if there is none
One paragraph on what it does and who it is for, a short feature list, and a pointer to INSTALL.md. Leave an existing README in place and only fix what is now wrong.

8. Write the buyer's Claude Code prompt
Save it as CLAUDE-INSTALL-PROMPT.md at the project root. It is a single prompt, addressed to Claude Code in the second person, that a buyer runs from inside the unzipped folder. It must tell Claude Code to read README.md and INSTALL.md, check the prerequisites, install the dependencies, create .env from .env.example by asking the buyer for each value one at a time (never guessing or inventing a key), start the tool, confirm it works using the check from INSTALL.md, and fix the common errors if they appear. Put only the prompt text in that file. I will paste it into the listing.

9. Fresh-unzip test
Copy the tree to a temporary folder, excluding everything from stage 4 and my .env, then follow INSTALL.md literally with a fresh .env made from .env.example, using dummy values where a real key is required. Every step that surprised you, or that you had to do and INSTALL.md did not say, goes into INSTALL.md. Report what you ran and what happened.

10. Final scan and zip
Run the stage 2 search again over the folder that will ship and confirm there are zero findings. Confirm there is no .env other than .env.example, no node_modules and no .git. Then, from the parent directory, zip the project folder so the zip contains one top-level folder, excluding the same files, and tell me the command you used, the zip size and the unpacked size. Unpacked must stay under 100 MB; under 3.5 MB lets buyers receive it straight into their own GitHub.

11. Report
Write PACKAGING-REPORT.md next to the zip, not inside it: every secret found (name and file, value redacted), every file removed, every variable in .env.example, the license check, the test result, the sizes, and the decisions you need from me.

12. Prepare the listing
Write LISTING.md next to the zip, not inside it. The studio's New listing form reads this file and fills itself in, and the listing page builds its search title and snippet from the title and tagline, so write for the buyer who is searching, not for yourself. First decide the two or three phrases a buyer would type to find a tool like this (what it does plus who it is for, and the subscription it replaces, for example "influencer content approval tool", "creator management portal for agencies", "Lifetimely alternative"). Then use exactly these level-2 headings, in this order, one per field: ## Title, ## Tagline, ## Category, ## Description, ## Stack, ## What is included, ## Requirements, ## Running costs, ## Install guide, ## Claude Code prompt, ## Suggested price, ## Search phrases. Title: the name a buyer would recognise, built on the main phrase's noun, under 40 characters (a project codename is not a title). Tagline: one line under 35 characters that pairs the main phrase with the benefit; title and tagline together must stay under 48 characters, because that is what the listing page puts in the browser title, and the tagline is also the first line of the search snippet and the catalog card. Category: exactly one of client-reporting, seo, paid-ads, social-media, email-and-crm, analytics, agency-operations, ai-agents, automation, starters. Description: the first sentence contains the main phrase and who it is for; the second names the subscription or manual process it replaces and what changes once it runs; then three to five bullet points of concrete capabilities that use the other phrases naturally, no hype, no keyword stuffing. Stack: one line, comma separated. What is included: one item per line, from a buyer's point of view. Requirements: one sentence, with runtime and version, accounts and keys, and setup time. Running costs: one line per paid service, as Service: rough monthly figure, required or optional, the figure part under 100 characters. Under Install guide and Claude Code prompt put the full text of INSTALL.md and CLAUDE-INSTALL-PROMPT.md inside a fenced code block (three backticks, then markdown) so their own headings are not read as fields. Suggested price: one number on the first line, then two sentences of reasoning for a one-time purchase of the full source under a single-organization license. Search phrases: the phrases you chose, one per line; the form ignores this section, it is for the creator's own announcement and blog post. Then summarise the report here in ten lines or fewer and tell me to drop LISTING.md and the zip on the studio's New listing form.

End with a confirmation I can read without knowing code: a bullet list of every file you added, changed or removed; the names (never the values) of the secrets moved to environment variables; the files left out of the zip; the zip path and its sizes; and one line each saying present or missing for INSTALL.md, .env.example, README.md and CLAUDE-INSTALL-PROMPT.md inside the zip, and LISTING.md next to it.

You are checking a zip I am about to upload to Unmetered, where buyers get the full source and run it themselves. The zip is next to this project folder; if you cannot find it, ask me for the path. Unzip it to a temporary folder and check every item below against what is actually inside the zip, not against the project on disk. Never modify or delete my real .env file, and never print a secret value. Do not use em dashes in anything you write.

1. One top-level folder, with the project (source and package files) inside it.
2. INSTALL.md at the root of that folder: prerequisites with versions, accounts and keys with where to get each, install, configure, run, a first check, common errors.
3. .env.example at the root, listing every variable the code reads with a placeholder and a comment and no real values. Grep the source for every environment variable name and confirm each one is listed.
4. README.md at the root.
5. CLAUDE-INSTALL-PROMPT.md at the root, the buyer's one-paste install prompt.
6. No .env and no other credential file: .pem, .p12, .key, .pfx, service-account*.json, credentials*.json, .npmrc, .netrc, saved cookies or sessions.
7. No hardcoded keys or tokens anywhere: AKIA followed by 16 characters, sk_live_ or sk_test_, whsec_, ghp_ and friends, xoxb-, re_ followed by 20 or more characters, BEGIN PRIVATE KEY, AIza, and any long random string assigned to a name containing key, secret, token, password or auth.
8. No client-specific values: account or property ids, spreadsheet or document ids, customer names or emails, client domains, internal URLs, real sample data, exports, logs, screenshots of accounts.
9. If the tool was wired to my own databases, workspaces or accounts: every connection points at a placeholder, no seeded or client data ships, and a buyer can connect their own.
10. No node_modules, .git, build output (dist, build, .next, out, target, __pycache__), caches or OS files.
11. Under 100 MB unpacked.
12. LISTING.md next to the zip, not inside it, in the Unmetered format from the packaging prompt; write it if it is missing.

Fix every failure in the project folder, re-zip it from the parent directory so the zip holds one top-level folder, leaving out node_modules, .git, .env and build output, and tell me the new zip path. Finish with a confirmation: the twelve checks with pass or fixed next to each, every file you added, changed or removed, and the names (never the values) of any secrets you moved.