Building with AI, from Nepal

You commented PLAN. Here is the file, the way the system reads it, and a template with three real entries from my own November. The idea I plan once a month and decide once a day. The plan is one JSON file. Every post is one entry. The studio reads the file, draws it as a calendar, renders whatever has a script, and creates one scheduled job per post. My job each day is a tick. ...

You commented CLIP. This is the system, with the code that matters. It is not a product. It cuts Shorts out of my own films in my own format, and that narrow scope is exactly why it works. What goes in, what comes out In: one film already cut from phone clips (the Dashain film, nine minutes, sixty-five iPhone clips shot in HLG), plus the catalogue of those clips. Out: five vertical Shorts with a title stamp, natural sound, an optional music track, loudness-normalised, uploaded to YouTube as scheduled videos in one command. ...

You commented STUDIO. Here is the whole thing, with the parts named, what each one does, and what it cost. Nothing here is a product you can install; it is my own setup, built with Claude Code over a few weeks, and I describe it so you can build your own version of the parts you need. What it is in one paragraph A local web app on my Mac in Panauti. It reads a month plan, writes each reel’s script into a JSON file, voices it with a clone of my voice, renders a vertical video, uploads it to YouTube as a scheduled Short, posts it to Facebook and Instagram at the right minute, pulls the comments back every half hour, drafts replies in my voice, and sends my phone a notification whenever something needs me. Nothing goes out without my tick. ...

You commented PROMPT. Here it is as text, then the reasons, then how I keep it in the repository so I never have to paste it again. The prompt ROLE You are a senior engineer on this repository. You have worked on it for a year. You care about the next person who reads the code. CONTEXT Stack: <language and versions, framework, database, infra>. Layout: <where the code lives, the main modules, where tests are>. Conventions: <formatter, naming, how errors are handled, how config is loaded, what must never be logged>. Today's task: <one or two sentences>. RULES 1. Ask before assuming. If anything about the task, the data or the constraints is unclear, ask one clear question and stop. 2. Plan before code. Give me the plan as a short numbered list: files you will touch, what changes in each, what could break. Wait for my OK. 3. Smallest diff that solves the task. No drive-by refactors, no renames, no new dependencies unless you say why. 4. Do not touch files outside the plan. If you must, say so first. 5. Keep behaviour: existing tests must still pass. Add a test for what you change. 6. Never invent an API, a flag or a library function. If you are not sure it exists, check or ask. 7. Secrets, tokens and personal data stay out of the code, the logs and this conversation. OUTPUT First the plan. After my OK, a diff I can review, file by file, with a one-line reason per file. Not a rewrite of the file. Fill the angle brackets once. For one of my Django and React projects the context block reads, roughly: Python 3.12, Django 5, DRF, PostgreSQL, React 18 with TypeScript, Docker Compose for local, GitHub Actions for CI; apps under backend/apps/, the SPA under frontend/src/, tests next to the code; black and isort, errors as typed exceptions, config from environment variables only, nothing from the request body is ever logged. ...