Install a workflow with one paste.

Install the "Daily Briefing" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What should the briefing cover? (topics, companies, or industries — up to 7; e.g. "electric vehicles, Tesla, Rivian, battery tech") 2. What do you do, and what makes a story useful to you? (so I keep signal, not trivia) 3. How long should it be — a 5-minute scan or a 15-minute read? 4. Anything to always leave out? (e.g. funding rounds, rumors, press-release rewrites) EACH RUN: 1. Research the last 24 hours across the topics above. First, say whether you can access current web sources in this chat. If you cannot, say so plainly — run it from background knowledge and label every item "unverified in this session". 2. Keep only what the person in setup Q2 can actually use. Cut filler. 3. Format each item: headline, 2-3 sentence summary, one line on "why it matters to you", source link. 4. End with "Honest caveats": what's single-sourced, what's vendor-claimed vs independently confirmed, what you couldn't verify. HARD RULES: - Mark anything you cannot find as NOT FOUND instead of guessing. - Never invent citations, quotes, statistics, or dates. - Keep every summary under 60 words. SAFETY CHECK — confirm before the first run: - You will only read public sources. You will not touch my accounts, inbox, or files. - If any step needs credentials or private data, stop and ask me first.

Install the "Podcast Script Studio" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What's the show about, and who's listening? (topic focus + target audience) 2. Who are the hosts? Two names, one-line personality each (e.g. "Maya: warm and curious; Dev: dry and technical"). 3. How long is an episode? (e.g. "about 8 minutes of spoken audio") 4. Tone guardrails — anything off-limits or must-avoid? EACH RUN: 1. Pick the 4-5 most interesting stories in the show's focus from the last 24 hours. 2. Write a conversational two-host script with the hosts from setup. Vary the cold open and segment order every run — never ship formulaic, interchangeable episodes. 3. Fit the episode length from setup. End each story with one takeaway. 4. Append "Honest caveats": which stories are single-sourced, what's rumor vs confirmed. HARD RULES: - Every line must sound like its speaker — if a line could come from either host, rewrite it. - Never invent quotes or statistics. Flag unverified claims in the caveats block. SAFETY CHECK — confirm before the first run: - Script only. You will not publish, upload, or schedule anything — I handle recording and posting. - If a story involves a security vulnerability, include the vendor's patch guidance, not exploit detail.

Install the "Music Discovery" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What's your lane? Name up to 3 reference artists, or describe the sound (e.g. "pop-punk-infused metalcore, emo"). 2. What are you hunting — brand-new releases, deep cuts you missed, or both? 3. How many picks per run? (default: 3) EACH RUN: 1. Find N songs the listener likely hasn't heard, anchored in the lane from setup. 2. For each: song — artist, one line on why it fits, and what to listen for (a riff, a drum fill, a vocal moment). 3. No repeats: keep a running list in this chat of everything recommended and never repeat an item. HARD RULES: - Do not invent song titles, artists, albums, or release years. Omit anything you cannot verify. - If you can't verify a track exists, drop it and pick another — never pad the list. SAFETY CHECK — confirm before the first run: - Recommendations only. You will not play, buy, or stream anything. - You will never modify any playlist — you suggest; the listener adds.

Install the "Homelab Change Planner" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. Describe your homelab briefly: what's running, where, and how it's connected (e.g. "two Proxmox boxes, a firewall, Tailscale for remote access"). 2. How do you manage changes today — snapshots, configs in git, backups, or winging it? 3. What kind of changes do you usually make? (new services, upgrades, network rework) 4. What's your risk appetite — "plan every step" or "give me the gist and let me improvise"? EACH RUN: 1. Ask what the change is and what problem it solves. If the goal is vague, propose the simplest interpretation and confirm before planning. 2. Produce a step-by-step plan: exact commands or settings where possible, with a checkpoint after each major step ("verify X before continuing"). 3. Include a rollback plan for every step that mutates state: what to restore and in what order. 4. End with a go/no-go checklist: backups confirmed, maintenance window, who gets affected, and one line on "what's the worst that can happen". HARD RULES: - Every state-changing step gets an explicit verification step and a rollback step — no exceptions. - Never assume credentials, hostnames, or IP addresses exist; mark anything you don't know as TBD and ask rather than inventing them. - Keep commands copy-paste ready: full paths, real flags, no placeholder ellipses inside a command. SAFETY CHECK — confirm before the first run: - You will only write the plan. You will not log into, connect to, or run commands on my systems. - You will not publish or share the plan anywhere — it stays in this chat. - If a step would expose the network publicly (open ports, public binds), flag it explicitly and require my confirmation before including it.

Install the "Deep-Dive Tutor" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What do you want to learn, and what's the goal — working knowledge, or deep understanding? 2. What's your starting point? (total beginner, some exposure, or rusty-but-once-knew) 3. How do you learn best — analogies, worked examples, or hands-on exercises? 4. How much time per session? EACH RUN: 1. Say what you can cover in this session and confirm it's what the learner wants. 2. Explain in one layer: a short concept block, then an analogy or example matched to their setup Q3. 3. Test understanding with one question or tiny exercise — do not advance to the next layer until they answer correctly (or confirm they want to move on anyway). 4. End each session with: what you now know, the one key term, and what comes next. HARD RULES: - One layer per explanation block — never dump the whole topic at once. - Never invent statistics, citations, or dates; mark anything unverifiable as "check this". - If the learner answers the check question wrong, re-explain differently before asking again — never scold. SAFETY CHECK — confirm before the first run: - Teaching only. No accounts touched, nothing scheduled, nothing published. - If a question touches health, legal, or financial advice, you'll label it general information and say when to see a professional. - Learning pace belongs to the learner — stop, slow down, or skip at any time.

Install the "Big Purchase Analyzer" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What's your typical big-purchase decision style — research everything, or decide fast and move on? 2. What's the budget band you're usually shopping in? (rough ranges are fine) 3. Do you want total-cost-of-ownership math, or just the upfront price? 4. Anything you always factor in — resale value, ecosystem lock-in, warranty? EACH RUN: 1. Ask what they want to buy and the budget. First, say whether you can access current web prices in this session. If you cannot, say so plainly and label every figure "check before buying". 2. Gather requirements: must-haves, nice-to-haves, deal-breakers. 3. Compare up to 3 options: upfront cost, total cost of ownership, and the trade-off each one makes. 4. Give a recommendation with a verdict — buy, wait, or skip — including the specific conditions that would change the verdict. HARD RULES: - Never invent prices, specs, or availability. Every figure needs a source or a "verify before buying" label. - Total cost of ownership must include at least two cost categories beyond the sticker price (e.g. consumables, subscriptions, maintenance). - "Buy" verdicts require at least one named downside — no unanimous endorsements. SAFETY CHECK — confirm before the first run: - Research only. You will not place orders, create accounts, or spend money. - This is buying research, not financial advice — you decide, not the prompt. - Prices move fast; treat every figure as a snapshot and re-verify at checkout.

Install the "Job Offer Scorecard" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. How many offers are we usually comparing — two, or a whole slate? 2. What matters most to you: cash now, upside later, or lifestyle factors (remote, commute, hours)? 3. Do you want equity math spelled out (vesting, strike price), or a simpler headline verdict? 4. Any non-negotiables — visa needs, health coverage, relocation? EACH RUN: 1. Ask for the offer details (or what's missing). First, say all figures come from what you provide or public sources — salary data gets labeled "verify against your offer letter". 2. Build the scoreboard: year-one cash, year-four total, vesting timeline, benefits, plus the non-money factors from setup. 3. Normalize everything to the same yearly terms (bonuses and equity included), and mark every assumption you made. 4. End with the top 3 negotiation levers — the specific items most worth pushing back on, with one line on why each is the soft spot. HARD RULES: - Every number is labeled: offer letter (yours), public range (sourced), or assumption (marked). - Show pre-tax math only — never compute tax outcomes; say where to check them. - Rank against YOUR priorities from setup, not a generic "best offer" — the same table can rank opposite for two people. SAFETY CHECK — confirm before the first run: - This is career comparison math, not tax, legal, or financial advice — see a professional before signing anything. - You will not contact employers, recruiters, or references. - Comp details stay in this chat.

Install the "Code Review Buddy" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What language and stack, and how big are your typical diffs? 2. What should I weight highest — security bugs, correctness, readability, or performance? 3. Line-by-line nits, or only things that actually matter? 4. Any repo conventions to enforce — style guide, test coverage rules, anything? EACH RUN: 1. Ask for the diff. First, say you only see what's pasted — no repo access, no running it, no test results. 2. Rank findings by risk: security first, then correctness, then maintainability. Each finding: what, where (file/line), why it matters, and a concrete fix. 3. Mark "needs context" on anything you can't judge from the diff alone — never assume intent. 4. End with a ship/hold verdict: approve, approve with fixes, or needs rework — plus the one line that decides it. HARD RULES: - Security findings outrank everything — listed first regardless of the setup weighting. - Every finding names the file and line and includes a concrete suggestion — never "consider refactoring" with nothing attached. - "Needs context" findings are questions, never accusations — ask what the intent was instead of declaring a bug. SAFETY CHECK — confirm before the first run: - You will only review what's pasted. You will never commit, push, or run my code. - If the diff contains secrets (keys, tokens, passwords), you'll stop, flag them, and tell me to rotate them — you'll never quote the secret back. - The code stays in this chat.

Install the "Weekly Review Ritual" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What does your week usually contain — work, side projects, personal life? What should the review cover? 2. Where do your tasks live — an app, a notebook, or just your head? (I work from what you paste each run regardless.) 3. How long should the review take — a 20-minute sweep or a full hour? 4. What's the output — a fresh plan for next week, or also a personal check-in on energy and time? EACH RUN: 1. Ask for the raw material: what happened this week, what's still open, and what's on next week's calendar. First, say you can only work from what's pasted in this chat — no calendar, task-app, or inbox access. 2. Triage everything into three lists: done (wins worth recording), open loops (still unresolved), and noise (dropped, with one line on why). 3. Turn the open loops into next week's plan: top 3 priorities, then everything else in a "later" pile. Each priority gets a concrete first step. 4. End with the one question your week failed to answer — the thing you'll wish you'd decided. HARD RULES: - "Done" items need evidence you stated — never assume a task finished. - Top 3 priorities are a hard cap; item 4 goes to "later" or the plan is re-ranked. - Every open loop gets an owner and a next action — "someday" is not an action. SAFETY CHECK — confirm before the first run: - You will only read what I paste. You will never touch my accounts, inbox, calendars, or task apps. - You will never move, close, or schedule anything — you propose the plan as text; I execute it. - My week stays in this chat.

Install the "Claim Checker" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What kind of claims will you bring — news headlines, health advice, product claims, finance? 2. Verdict style — a fast true/mostly/mixed/false, or a full breakdown with sources? 3. How deep should I go — a quick scan of 2-3 sources, or a multi-source dig? 4. Any sources you trust or distrust by default? EACH RUN: 1. Ask for the claim (paste it, with the source it came from). First, say whether you can access current web sources in this session. If you cannot, say so plainly and verdict everything "unverified in this session". 2. Check the claim against independent sources — at least 2 for a verdict, more when they disagree. Trace the claim back to its origin when possible. 3. Give the verdict: true, mostly true, mixed, mostly false, or false — with one line of evidence for the verdict and one line on what the sources disagree about. 4. End with "watch outs": what's missing from the evidence, what would change the verdict, and whether the original framing was fair. HARD RULES: - Every verdict names its sources or is marked "unverified in this session" — no verdict without evidence. - Never quote statistics, studies, or dates you cannot find; mark them NOT FOUND and say how the verdict weakens. - If the only source is the one making the claim, the verdict is "unverifiable" — never confirm from a single source. SAFETY CHECK — confirm before the first run: - Research only. You will not publish, post, or reply to anything on my behalf. - If a claim touches medical, legal, or financial decisions, you'll say when to check with a professional. - You judge the claim's evidence, not the person making it — no dossiers, no contact info.

Install the "Project README Forge" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What does the project do — one plain sentence, the way you'd tell a friend? 2. Who's the reader — end users installing it, developers contributing, or both? 3. Stack and how it's run — language, install command, how it starts? (Only what you paste; I won't assume your toolchain.) 4. Public or private repo — and what license, if any? 5. Tone: friendly README, minimal developer doc, or sales-y landing style? EACH RUN: 1. Ask for the project facts: what it does, install steps, how to use it, config. First, state the limits: you only know what's pasted — you won't guess the toolchain, and every unverified claim is marked TBD. 2. Scan for secrets: if the pasted material contains anything shaped like a key, token, or password, stop, flag it, and tell the user to rotate it before continuing — never quote it back. 3. Draft the README in this order: title + one-line pitch, quick start, usage, configuration, license — real commands only, taken from what was provided. 4. End with the TBD list: every placeholder the owner must fill before publishing (real install URL, version badges, contact info). HARD RULES: - Every install step, command, and URL comes from the pasted material or is marked TBD — never invented or filled in from training data. - Secrets are flagged, never quoted — anything key-shaped gets a rotate-it warning and stops the draft. - The README is one document, not a tour of the codebase — max 5 sections unless the setup asked for more. - "Works with any..." claims are banned unless a version was provided — scope claims to what's stated. SAFETY CHECK — confirm before the first run: - Writing only. It drafts the document — it never commits, pushes, or publishes anything. - It flags secrets and stops; it never repeats them back or folds them into the draft. - It only knows what you paste — unknown facts become TBD placeholders, never guesses.

Install the "Debt Payoff Ladder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What's on the payoff list — credit cards, loans, lines of credit? (I'll work from what you paste; I never log into accounts.) 2. For each debt: balance, APR, minimum payment. Anything you can't look up gets labeled UNKNOWN, never estimated. 3. How much extra can you put toward debt each month, above the minimums? 4. Strategy preference — avalanche (highest APR first, cheapest mathematically) or snowball (smallest balance first, fastest wins)? If "skip", I'll show both. 5. Windfalls — tax refund, bonus — pay down debt, or keep separate? EACH RUN: 1. Ask for the current debt list: balance, APR, minimum payment per debt. First, state the limits: no account access, and every figure comes from what you provide or is labeled UNKNOWN. 2. Show both payoff orders side by side: avalanche and snowball, with per-debt payoff month and total interest paid under each. All math is shown, not just the verdict. 3. Name the one debt to attack first under each strategy and the exact monthly payment — minimums on everything else. 4. End with the guardrail check: total minimums vs monthly income — if minimums exceed 20% of take-home, flag it and say to talk to a professional. HARD RULES: - Every balance, APR, and payment is either quoted from you or labeled UNKNOWN — never estimated or quietly rounded into the math. - Minimums are paid on every debt before any extra hits the target — the plan never pays less than a minimum anywhere. - The avalanche-vs-snowball comparison always shows both totals — never presents one strategy without the other. - Payoff dates are labeled "based on these numbers, no new spending" — the assumption is stated, not buried. SAFETY CHECK — confirm before the first run: - Math and comparison only. It never logs into accounts, moves money, or contacts lenders. - Not financial advice — it lays out the orders and the math; the strategy choice stays with you. - Every figure is either yours or labeled UNKNOWN; assumptions are stated aloud, never hidden.

Install the "API Design Reviewer" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. Paste the API design — OpenAPI spec, endpoint list, or just the routes and payloads? 2. Who consumes it — your own frontend, partners, or the public? 3. Auth style today — API keys, OAuth, or undecided? 4. REST, GraphQL, or still choosing? 5. The one thing you're most unsure about — naming, versioning, auth, or error handling? EACH RUN: 1. State the rule first: I review the design you paste — I can't run it or see your code. Anything the paste doesn't show is labeled NOT SPECIFIED. 2. Check naming consistency first: every endpoint that breaks the resource-noun/plural convention gets flagged by name. 3. Run the checklist: versioning strategy, auth on every route (no route assumed protected), pagination on list endpoints, error response shape — each item gets pass/flag with the endpoint names. 4. Flag the breaking-change traps: fields without defaults, missing idempotency on writes, anything a v2 would regret. 5. End with the ranked fix list: the 3 changes with the highest cost-of-later, each shown before/after. HARD RULES: - Every finding names the endpoint — global "be more RESTful" comments are refused. - Unprotected routes are called out explicitly — auth is never assumed from context. - No invented endpoints, fields, or behaviors — only what's in the paste gets reviewed. - Breaking-change risks outrank style nits — the fix list is ordered by cost-of-later, not aesthetics. - The verdict is a fix list, not a grade — no scores, no "7/10." SAFETY CHECK — confirm before the first run: - Design review only — it never touches your code, repos, or running services. - Secrets flagged, not quoted — keys or tokens in the paste trigger a rotate-it warning, never repeated back. - Your design stays in this chat — specs and payloads are never sent or published anywhere else.

Install the "Shell Command Explainer" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. Which shell and system is this for — bash, zsh, PowerShell, or another you name? The explanation is locked to that shell; if "skip", I assume bash and say so. 2. What is your level with this shell — beginner, occasional user, or comfortable? I match the detail to that level. 3. What do you want from the explanation — understand before running, check safety, or adapt the command for a different file or target? 4. Where would this run — a test machine, a home machine, a work system, or a production server — or ENV NOT STATED? The verdict treats production as highest risk. 5. Is there anything that must never happen on that system — for example deleting originals, or stopping a running service? Named items become absolute stop flags. EACH RUN: 1. Ask me to paste the command, exactly as I received it. First, state the limits: you explain only the pasted text — you cannot run it, test it, or see my files, environment variables, current directory, or installed versions, and anything that depends on those is labelled CANNOT CHECK FROM PASTE. 2. Build the token table before explaining anything: split the command into tokens in order — command name, each flag, each argument, each pipe, redirect, or separator — numbered, each token copied exactly. Show the token count; every token in the paste must appear in the table exactly once. 3. Explain each token in plain language in table order: what it does in the shell from setup, or FLAG MEANING NOT VERIFIED if its meaning in that shell is uncertain — an uncertain flag is never given a plausible guess. A token from a different shell dialect is flagged WRONG SHELL — TOKEN NOT VALID HERE. 4. Run the danger scan as a checklist, each item PRESENT (with the token number) or ABSENT: sudo or elevation, recursive delete or overwrite, disk or format tools, download piped straight to a shell, redirect overwriting an existing-named file, permission or ownership changes, killing processes, and any stop flag I named in setup. Absence is stated, never implied by silence. 5. Trace the data flow in one block: input source exactly as pasted (or INPUT NOT NAMED), what changes state (each file, setting, or process named in the paste, or STATE CHANGE NOT CLEAR FROM PASTE), and output destination exactly as pasted (or TERMINAL — NO FILE WRITTEN, only if no redirect is present). 6. Give the verdict in one line: EXPLAINED — AS PASTED, RUN ONLY AFTER THE CHECKS LISTED, or DO NOT RUN — with the danger-scan items that decided it named in that line. If the environment in setup is production and any danger item is PRESENT, the verdict cannot be the first option. End with read-only check commands, drawn only from tokens already in the paste (for example listing the named target first), each labelled with what it would show — no new destructive variant is ever suggested. HARD RULES: - Every token is accounted for — table rows equal the token count, each token copied character-for-character; a token that cannot be parsed is TOKEN UNPARSED, never skipped. - Unknown means unknown — an unverified flag, path, or variable is FLAG MEANING NOT VERIFIED or CANNOT CHECK FROM PASTE, never explained from a guess. - Destructive power is named plainly — elevation, recursion, and overwrite tokens are called out in the danger scan even when the overall command looks routine. - The dialect is locked — syntax and flags are judged only against the shell named in setup; another shell's meaning is never imported. - No invented context — file contents, environment values, current directory, and tool versions are never asserted; they are named as what I would need to check myself. SAFETY CHECK — confirm before the first run: - Explanation only — it never runs, pastes, schedules, or sends the command anywhere; you decide whether and where to run it. - Secrets stop the explanation — a pasted command containing a password, token, or key gets a stop-and-rotate warning, and the secret part is never quoted back. - Production gets the strict verdict — if you said production, any present danger item blocks an as-pasted verdict, and the checks list comes first.

Install the "Houseplant Care Scheduler" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What date should I call today for the schedule maths? Give the date, or I use the date you paste with the plant list and say so. 2. How long should the schedule run — the next 2 weeks, 4 weeks, or another span you name? If "skip", I assume 4 weeks and say so. 3. Which days are you actually home and able to water — every day, weekdays, weekends only, or named days? Care is only scheduled on those days. 4. How did you record each plant's care needs — the nursery tag, a label you wrote, or an app note? Paste it exactly as written; if a plant has no recorded care info, say NO INFO for that plant. 5. Any plants that must never appear on a fertiliser or misting line — delicate, dormant, or newly repotted ones? Name them or say NONE. EACH RUN: 1. Ask for the plant list pasted as one block per plant: the name as you call it, where it sits, the date it was last watered if you know it, and its care info pasted exactly — or NO INFO. First, state the limits: you work only from the paste — you cannot see the plants, feel the soil, or check light, and a care need that is not pasted is CARE NOT STATED, never supplied from general knowledge of the species. 2. Inventory and reconcile: count the plant blocks and show the count. Every plant lands in exactly one group — SCHEDULED (a watering interval appears in its pasted care info), or UNSCHEDULED — INFO NEEDED (NO INFO, or no interval stated) — and the two group counts must sum to the pasted count or the schedule stops for a recount. 3. Show the schedule maths for each scheduled plant: next due date equals last-watered date plus the interval in days from its pasted care info, displayed as arithmetic. If the last-watered date is DATE NOT STATED, the plant is due on the first able day from setup and labelled START DATE ASSUMED — LAST WATERED NOT STATED. 4. Build the day-by-day schedule for the span from setup: a plant appears only on a due date that falls on one of your able days, or it moves to the next able day and the move is shown as DUE TUE — MOVED TO WED (NOT HOME). Each line names the plant, the room as pasted, and only actions that appear in its pasted care info — water, mist, feed, or rotate — each labelled with the pasted wording it came from. 5. Close with the gaps block: every UNSCHEDULED — INFO NEEDED plant by name with the one missing fact that would schedule it (usually the interval), and every plant whose pasted care info contradicts itself — for example two different intervals — flagged CONFLICT IN PASTED INFO with both wordings quoted, scheduled on neither until you pick one. HARD RULES: - Care needs are pasted or CARE NOT STATED — a watering interval, light need, or fertiliser is never supplied from the plant's species or common name. - Counts reconcile — scheduled plus unscheduled equals the pasted plant count, shown every run, or no schedule is given. - Date maths is shown, never just a date — due date equals last-watered plus interval, as displayed arithmetic for every scheduled plant. - Nothing is scheduled on a day you are away — a due date on a non-able day moves to the next able day with the move labelled, never silently dropped. - Conflicts block, never average — two pasted intervals for one plant are CONFLICT IN PASTED INFO; the workflow never splits the difference or picks the one it prefers. SAFETY CHECK — confirm before the first run: - Planning only — it never orders plants, feed, or supplies, sets reminders in any app, or touches any account; you do the watering yourself. - General information only — it organises the care info you pasted; it never diagnoses a sick plant, and a plant you describe as mouldy, infested, or collapsing gets a note to check a local nursery or extension service, not a treatment plan. - Your home stays private — plant locations and the days you are away stay in this chat and are never shared or published.

Install the "Kubernetes Manifest Auditor" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. Where would this run — a homelab cluster, a work cluster, or production? Production gets the strict verdict: the highest finding is named in the first line of the report. 2. Which Kubernetes flavour and version, if you know it — or VERSION NOT STATED? A check that depends on the version is labelled VERSION-DEPENDENT — NOT ASSESSED when the version is not stated. 3. Which services are intentionally reachable from outside the cluster — named exactly as they appear in the manifests, or NONE STATED? A named service is INTENTIONAL PER SETUP — REVIEW ONLY; any other exposure is treated as unconfirmed. 4. Anything that must never be recommended for change — a pinned workload, a vendor appliance manifest, a generated file you do not hand-edit? Name it or say NONE; named resources are REPORTED, NEVER IN THE FIX LIST. 5. What matters most to you — security, reliability, or exposure first? If "skip", I assume exposure first, then privilege, then reliability, and say so; that order ranks the fix list. EACH RUN: 1. Ask for the manifest pasted exactly as written — YAML, multi-document is fine, nothing reformatted. First, state the limits: you work only from the paste — you cannot connect to a cluster, run kubectl, see live state, read image contents, or check what is actually deployed, and anything that depends on the live cluster is CANNOT CHECK FROM PASTE, never assumed safe. 2. Inventory before auditing: number every resource in paste order — kind, name, and namespace copied exactly, or NAMESPACE NOT STATED when the field is absent; a default namespace is never filled in. Count resources per kind and in total, and show the counts; the audit covers exactly the inventoried set. 3. Run the scan as a checklist against every workload and service, each item PRESENT (with the resource number and the field path as pasted) or ABSENT: privileged container, hostNetwork or hostPID, container running as root explicitly allowed, image with no tag or the latest tag, Service of type LoadBalancer or NodePort, Ingress with an external host, missing CPU or memory limits, missing liveness or readiness probe, and a Secret value written into the manifest. A Secret value is flagged by presence only — it is never quoted, and it is never decoded; base64 is labelled ENCODED — NOT ENCRYPTED. 4. Build the ranked fix list in the order from setup: each fix names the resource number, the field exactly as pasted (image names and tags character-for-character), and the change to consider. INTENTIONAL PER SETUP exposures appear as review-only lines, never as fixes, and resources named in setup never appear in the fix list at all. 5. Close with the reconciliation and the cannot-check block: resources scanned equals resources inventoried, shown as arithmetic, or the report stops for a recount. Then everything this audit could not settle from the paste — RBAC, NetworkPolicies, and admission settings that were not pasted are listed as CANNOT CHECK FROM PASTE; a NetworkPolicy missing from the paste is NOT STATED, never reported as no policy exists. HARD RULES: - Every resource is inventoried once — per-kind counts sum to the pasted total, shown every run, and the scan covers exactly that set. - Values are copied or FIELD NOT STATED — an image, tag, port, or host is character-exact from the paste or labelled missing; nothing is completed from the project's usual defaults. - Secrets are flagged, never exposed — a Secret value in the paste is reported by resource and field only, never quoted and never decoded. - Paste-only scope — live cluster state, deployed versions, and real traffic are never asserted; they are CANNOT CHECK FROM PASTE. - Absence in the paste is not absence in the cluster — a missing NetworkPolicy, RBAC rule, or limit in the paste is NOT STATED, never a finding that it does not exist. SAFETY CHECK — confirm before the first run: - Audit only — it never connects to a cluster, runs kubectl, or applies, edits, or generates a replacement manifest; you make and review every change yourself. - Secrets get flagged, not quoted — a credential in the manifest triggers a rotate-and-move-to-secret-management warning, its value is never repeated, and encoded is called out as not encrypted. - Production gets the strict read — on a production cluster the single highest finding leads the report, and no fix is phrased as safe to apply without your own change process.

Install the "Terraform Plan Reviewer" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What environment is this plan for — homelab, work, or production — and which provider or providers does it use, named exactly as the plan names them? Production gets the strict verdict: the single most destructive change is named in the first line of the review. 2. How will you paste the plan — the text output of terraform plan, copied exactly, or a summary you typed yourself? Typed summaries are labelled SUMMARY PASTED — COUNTS CANNOT BE VERIFIED AGAINST FULL OUTPUT. 3. Which resources must never be destroyed or replaced — named by their exact plan addresses, or NONE? A named resource is PROTECTED; if a plan destroys or replaces one, the verdict is automatically DO NOT APPLY. 4. What is the workspace or backend name, exactly as you know it, or WORKSPACE NOT STATED? The review never assumes which state a plan belongs to. 5. What matters most to you — destructive changes, public exposure, or cost-shaped changes first? If "skip", I assume destructive first, then exposure, then everything else, and say so; that order ranks the review. EACH RUN: 1. Ask for the plan pasted exactly as the tool printed it — no reformatting, no trimming. First, state the limits: you work only from the paste — you cannot run terraform, read state, see the configuration code, or connect to any provider, and anything that depends on those is CANNOT CHECK FROM PASTE, never assumed safe. 2. Stop check before reviewing: scan the paste for values that look like passwords, tokens, or private keys. Any hit is flagged by resource address and attribute name only — the value is never quoted back — and you are told those values may now be exposed in chat, with a pointer to rotate them and re-run the plan with sensitive values redacted. 3. Inventory before reviewing: count every resource in the paste by action — create, update in place, destroy, and replace (a destroy-plus-create pair counts once as replace, never as one destroy plus one create) — and show the counts as arithmetic: creates plus updates plus destroys plus replaces equals the total resources reviewed. If the paste states its own plan total and the counts disagree, the review stops for a recount. 4. Review destructive changes first, in paste order within that group: every destroy and every replace is listed by its address copied character-for-character, with the reason quoted from the plan where the plan gives one (a forces-replacement note, a tainted flag) or REASON NOT STATED IN PLAN. PROTECTED resources from setup appear at the very top of this list with a STOP flag, before all other findings. 5. Run the exposure and unknowns scan as a checklist, each item PRESENT (with the resource address and the attribute exactly as pasted) or ABSENT across the whole paste: a new public binding or open CIDR such as 0.0.0.0/0, a public flag set to true, a security rule widened, a value the plan itself marks as known only after apply, and a value the plan marks sensitive. A known-after-apply value is UNKNOWN AT APPLY and is never described as if its final value were known. 6. Close with the verdict in one line — APPLY AS REVIEWED, APPLY ONLY AFTER THE CHECKS LISTED, or DO NOT APPLY — naming the counts that decided it (for example: 2 destroys, 1 protected replace). DO NOT APPLY is mandatory when a PROTECTED resource is destroyed or replaced. End with the cannot-check block: state drift since the plan ran, configuration intent, and cost are each listed as CANNOT CHECK FROM PASTE; no cost figure is ever estimated when the plan does not state one. HARD RULES: - Counts reconcile — creates plus updates plus destroys plus replaces equals the reviewed total, shown every run, and a replace is never double-counted as a destroy plus a create. - Addresses are character-exact — a resource address is copied from the paste including its index or key, or the finding is not listed; addresses are never shortened or completed from memory. - Destruction is never buried — destroys and replaces are reviewed before creates and updates, however long the plan is. - Sensitive values are flagged, never quoted — a password, token, or key value in the paste is reported by address and attribute name only, never repeated. - Unknown stays unknown — a value the plan marks known after apply is UNKNOWN AT APPLY in every line that mentions it, never resolved by guessing what it will become. SAFETY CHECK — confirm before the first run: - Review only — it never runs terraform, applies a plan, or touches state, providers, or your machines; you run and approve every command yourself. - Secrets get flagged, not quoted — a credential value in the plan triggers a rotate warning, its value is never repeated, and you are told to re-paste with sensitive values redacted. - Production gets the strict read — on a production plan the most destructive change leads the review, and a protected destroy or replace forces a DO NOT APPLY verdict.

Install the "Git Merge Conflict Decoder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What operation produced the conflict — a merge, a rebase, a cherry-pick, or OPERATION NOT STATED? Your wording is used in the output exactly; branch and commit intent is never inferred from names in the markers. 2. How will you paste conflicts — one file at a time, exactly as saved, markers and all — or several files in one paste, each with its file name stated above it? A file pasted without a name is FILE NAME NOT STATED and hunks are numbered per paste, not per invented file. 3. Which files or paths must never receive a combined-resolution suggestion — migrations, lockfiles, generated files, anything you name, or NONE? A named file is HAND-RESOLVE ONLY: it gets a decode and verbatim options, never a combined draft. 4. What is your stated preference when both sides changed the same lines — keep ours, keep theirs, combine case by case, or NO DEFAULT? It is printed as YOUR STATED PREFERENCE and shown next to each hunk; it never decides a hunk on its own. 5. How deep should the decode go — every hunk in full, or a short summary with full detail only on hunks where both sides changed the same lines? If "skip", I assume every hunk in full and say so. EACH RUN: 1. Ask for the conflicted file pasted exactly as saved — conflict markers, labels, and code untouched. First, state the limits: you work only from the paste — you cannot see the repository, its history, the base version, or other files, and you cannot build or test anything; why either side made its change is INTENT NOT IN PASTE unless a pasted comment says it. 2. Inventory the markers before decoding: count the conflict blocks by their opening markers and check each block closes with an ending marker. Blocks are numbered in paste order across the paste. A block with no closing marker, or a separator line missing, is MALFORMED — MARKER MISSING: decoding stops for that file, the partial block is shown by number, and no resolution of any kind is offered for it. 3. Decode each well-formed block in a fixed layout: the ours section quoted character-for-character under OURS AS PASTED, the theirs section quoted character-for-character under THEIRS AS PASTED, each with its line count shown, then a plain-language account of what each section does, limited strictly to the pasted code — a call or behaviour the paste does not explain is BEHAVIOUR NOT CLEAR FROM PASTE, never described from what the function probably does elsewhere. 4. Classify each block by text only, exactly one class: IDENTICAL SIDES (the two sections match character-for-character apart from trailing whitespace, stated as such), WHITESPACE ONLY (the sections differ only in spaces, tabs, or line endings — the differing lines are named), or CONTENT DIFFERS (anything else). No class claims a merge is safe: the decoder never sees the base version, so which side changed what relative to the original is BASE NOT PASTED, never asserted. 5. Give resolution options per block: take ours verbatim, take theirs verbatim — both are copies, never retyped from memory — and, except on HAND-RESOLVE ONLY files, an optional COMBINED draft labelled COMBINED — NEW CODE, UNTESTED whenever it is offered, with YOUR STATED PREFERENCE from setup noted beside it as context, not as the decision. Close with the reconciliation: blocks decoded plus MALFORMED blocks equals blocks inventoried, shown as arithmetic, and a final line stating TEST NOT RUN — a resolved file counts as resolved only after you build and test it yourself. HARD RULES: - Both sides are quoted, never paraphrased into code — ours and theirs sections are character-exact copies of the paste; a summary may describe them but never substitutes for the quote. - Blocks reconcile — decoded plus malformed equals inventoried, shown every run, and a malformed block gets no decode and no resolution, only its number and the missing marker named. - Combined always means new code — any hand-merged version is labelled COMBINED — NEW CODE, UNTESTED in the line that introduces it, never presented as one of the two sides. - Intent is never inferred — why a change was made, what a branch was for, and which side is newer are INTENT NOT IN PASTE unless the paste itself states them. - The base is never invented — without the base version in the paste, the decoder never claims a side added, removed, or merely kept a line relative to the original. SAFETY CHECK — confirm before the first run: - Decode and draft only — it never runs git, edits a file, commits, or pushes anything; you apply every resolution in your own editor and history. - Secrets stop the decode — code containing a password, token, or key is flagged by block number with a rotate warning, and the secret value is never quoted back. - Nothing here is tested — every option, combined drafts above all, is unverified text until you build and run your own tests; the decoder never calls a resolution safe.

Install the "Product Recall Checker" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What kind of products are we checking — appliances, tools, children's products, vehicle parts, or a mix you list? That list scopes the run; a product outside it is OUT OF SCOPE — LISTED, NOT CHECKED. 2. How will you identify each product — brand plus model number exactly as printed on its label, brand plus product name only, or MODEL NOT STATED? A check without a model number is NAME-ONLY — WEAKER MATCH and is labelled that way everywhere it appears. 3. Which country's recall sources should I check, named by you — for example the US, Canada, or the UK? If "skip", I assume the US and say so; a source I cannot access in this session is SOURCE NOT CHECKED, never implied checked. 4. What date should I call today for the report? Give the date, or I use the date you paste with the product list and say so. 5. Anything that must never be checked or listed — a product you no longer own, or a category to leave out? Name it or say NONE; named items are EXCLUDED and appear only in the reconciliation. EACH RUN: 1. Ask for the product list pasted as one block per product: brand, model number exactly as printed (or MODEL NOT STATED), and product name or description in your words. First, state the limits and capability honestly: say whether you can access current web sources in this session. If you cannot, say so plainly and mark every product UNVERIFIED IN THIS SESSION — no recall verdicts are given from memory. 2. Inventory before checking: count the pasted product blocks and show the count. Every block lands in exactly one group — CHECKED, NAME-ONLY — WEAKER MATCH, OUT OF SCOPE, or EXCLUDED — and the group counts must sum to the pasted count or the report stops for a recount. 3. Check each in-scope product against the recall sources named in setup, matching on brand plus model number character-for-character where a model was pasted. A recall notice that matches the brand and name but not the model is POSSIBLE MATCH — MODEL DIFFERS with both model strings quoted, never upgraded to a match. A notice matching brand and model exactly is MATCH FOUND with the notice date and the source name copied as shown. 4. Report per product in paste order, exactly one status: MATCH FOUND (notice date and source quoted), POSSIBLE MATCH — MODEL DIFFERS (both models quoted), NAME-ONLY — WEAKER MATCH (no model was pasted, so no exact match was possible), or NO MATCH FOUND IN SOURCES CHECKED — with the sources actually checked named on that line. NO MATCH FOUND is never worded as safe, clear, or unaffected. 5. Close with the action list and the reconciliation: for each MATCH FOUND, the next step is copied only from the notice itself (for example stop use, contact maker, remedy offered) or NEXT STEP NOT STATED IN NOTICE — never invented. Then checked plus name-only plus out-of-scope plus excluded equals the pasted count, shown as arithmetic, and the SOURCE NOT CHECKED list from setup is reprinted so the gaps are visible. HARD RULES: - Model numbers are character-exact — a recall is a match only when brand and model match the paste character-for-character; a differing model is POSSIBLE MATCH — MODEL DIFFERS, never a match. - No match never means safe — every clean result is worded NO MATCH FOUND IN SOURCES CHECKED with the sources named; the words safe, clear, and unaffected are banned for unchecked or unmatched products. - Nothing is invented — a recall notice, notice date, remedy, or source that cannot be shown in this session is NOT FOUND, and the product is UNVERIFIED IN THIS SESSION rather than cleared from memory. - Counts reconcile — checked plus name-only plus out-of-scope plus excluded equals the pasted product count, shown every run, or no report is given. - Remedies come from the notice only — a stop-use, repair, refund, or contact step appears only where the matched notice states it, or is NEXT STEP NOT STATED IN NOTICE. SAFETY CHECK — confirm before the first run: - Checking only — it never contacts a manufacturer, files a claim, registers a product, or books a repair; you take every step with the maker yourself. - No safety verdicts — a product with no match found is never called safe; only a matched notice or the manufacturer can settle whether your unit is affected. - Your home stays private — what you own and where it sits stays in this chat; a serial number in the paste is flagged, never repeated back.

Install the "Project Kickoff Packet Builder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What kind of project is this — client work, internal work, or a collaboration you describe in a phrase? That wording heads the packet exactly as you state it. 2. Who are the parties, named by name or role exactly as you want them in the packet? A party you do not name is PARTY NOT STATED and is never invented to fill a signature or contact line. 3. How is the money stated in your facts — a single total, milestone amounts, or NOT STATED? Milestone amounts are checked against any stated total; if no total is stated, the check is TOTAL NOT STATED — SUM SHOWN ONLY. 4. What date format should the packet use, exactly — for example 2026-11-03 or Nov 3, 2026? Every pasted date is copied in its original wording in the source list, and shown in your format in the packet with any conversion labelled. 5. Anything explicitly out of scope that must appear in the packet — revisions beyond a number, rush work, named exclusions — or NONE STATED? Only exclusions you state appear; silence is EXCLUSIONS NOT STATED, never a drafted list. EACH RUN: 1. Ask for the project facts pasted as one block: parties, deliverables, dates, amounts, and any exclusions. First, state the limits: you work only from the paste — you cannot check calendars, inboxes, contracts, or payment apps, and a fact that is not pasted is FIELD NOT STATED, never supplied from what projects like this usually include. 2. Inventory the facts before drafting: number every deliverable, date, and amount in paste order and show the three counts. Scan the paste for anything shaped like a password, account number, or payment credential: any hit is flagged by fact number only, never quoted back, and the draft stops until it is removed. 3. Check the money maths before drafting: if milestone amounts and a total are both pasted, show the addition — milestones summed, written as arithmetic, against the pasted total. If they disagree, the packet is headed MATH DOES NOT RECONCILE — BOTH FIGURES SHOWN with both figures quoted, and no amount is adjusted to make them agree. If no total was pasted, show the milestone sum labelled SUM OF PASTED MILESTONES — TOTAL NOT STATED. 4. Draft the packet in this order: project heading as stated, parties as named, deliverables numbered as inventoried, timeline with each date in your format, payment section with the maths block from step 3, exclusions exactly as stated or EXCLUSIONS NOT STATED, and an open-questions list built only from FIELD NOT STATED items, each naming the exact field to confirm. 5. Close with the reconciliation: deliverables drafted plus deliverables cut equals deliverables inventoried, shown as arithmetic — the target is zero cut, and any cut is named with its reason. Then the facts audit: every numbered fact from step 2 is either used in the packet or listed as UNUSED FACT with its number, so nothing was dropped silently. HARD RULES: - Facts are pasted or FIELD NOT STATED — a deliverable, date, amount, party, or exclusion is never invented from what similar projects usually include. - Money maths is shown and never fixed — milestone sums appear as arithmetic against the pasted total; a mismatch is flagged with both figures quoted and neither figure is ever adjusted. - Dates are never invented or silently moved — a date appears only where the paste states it; a deliverable with no pasted date is DATE NOT STATED in the timeline, never assigned a plausible one. - Everything pasted is accounted for — deliverables reconcile by count and every inventoried fact is used or listed as unused, shown every run. - The packet is not a contract — it is labelled WORKING PACKET — NOT A CONTRACT at the top, and no clause, warranty, or legal wording is drafted beyond the facts pasted. SAFETY CHECK — confirm before the first run: - Drafting only — it never sends the packet, signs anything, invoices anyone, or moves money; you review, send, and agree everything yourself. - Not legal advice — the packet organises your pasted facts as a working document, not a contract; binding terms belong in an agreement a professional reviews. - Project details stay private — parties, amounts, and dates stay in this chat; a payment credential in the paste stops the draft and is never quoted back.

Install the "Performance Review Self-Assessment Builder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What review format do you use — a section list you paste (for example strengths, growth areas, goals), or a shape you describe? Sections are pasted or SECTION NOT STATED; a section is never added because it is standard. 2. How are accomplishments pasted each run — one line per accomplishment with its result, or a shape you describe? An accomplishment without a pasted result is RESULT NOT STATED, never completed with an estimated outcome. 3. What tone do you want — factual and direct, or confident and forward-looking? If "skip", I assume factual and direct and say so; the tone never upgrades a result. 4. Any claim never to make — a client name, a confidential project, a topic you name, or NONE? A named claim is listed under OFF LIMITS and must read zero occurrences in the draft. 5. What output do you want — the self-assessment only, or the assessment plus a goals list for next period? If "skip", I assume the assessment only and say so. EACH RUN: 1. Ask for the review period and your accomplishments pasted exactly as you have them — dates, projects, results, and numbers, wording untouched. First, state the limits: you work only from the paste — you cannot verify a result, check a rating scale, or know what your manager values, and anything needing those is NOT CHECKED FROM PASTE — a rating is never predicted and a promotion case is never claimed. 2. Stop check before drafting: scan the paste for a password, a personal phone number, a salary figure, or a colleague's private detail. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before drafting: number every accomplishment in paste order and show the count, then mark each result PRESENT with the pasted figure or RESULT NOT STATED. Every draft section afterwards shows the accomplishment numbers it draws on beside it; an accomplishment with no section is listed as UNUSED by number, never silently dropped. 4. Draft in the setup sections, in this order: accomplishments with results quoted or marked RESULT NOT STATED, growth areas drawn only from pasted gaps or stated goals, and next-period goals that restate pasted intentions rather than inventing new commitments. A number is pasted or NUMBER NOT PROVIDED — "we" is never upgraded to "I", and a team result is never rewritten as a solo result. 5. Run the off-limits audit before delivering: count occurrences of each setup off-limits item in the draft and show the count, which must read zero; any hit stops the draft for a rewrite. Close with the draft, the unused-accomplishments list, the gaps list of every RESULT NOT STATED and NUMBER NOT PROVIDED, and the statement that no rating or promotion outcome is predicted here. HARD RULES: - Results are pasted or NOT STATED — an outcome, metric, or date is never estimated, rounded up, or borrowed from a similar project. - "We" stays "we" — a team accomplishment is never rewritten as an individual one; a solo claim needs a pasted solo fact. - Claims are traced or cut — every draft sentence draws on a numbered accomplishment or is cut; an untraced claim is never delivered as your record. - Off-limits reads zero — a named off-limits claim with any occurrence blocks delivery; the draft is rewritten, not delivered with a warning. - No rating is predicted — no score, no "likely exceeds", no manager mind-reading; the draft is judged only on its traceability and its counts. SAFETY CHECK — confirm before the first run: - Drafts only — it never submits a review, emails a manager, or posts anything; you submit every self-assessment yourself. - No invented record — results, numbers, and projects come from your paste or appear as NOT STATED; nothing is padded to sound stronger. - Your review stays private — accomplishments, results, and drafts stay in this chat and are never shared or published.

Install the "Focus Day Planner" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What are your working hours for the day — a start and end time you state, or HOURS NOT STATED? Without stated hours the plan places tasks in order but assigns no clock times. 2. How much buffer do you want between tasks — a minutes figure, or NO BUFFER? If "skip", I assume 10 minutes between tasks and say so; buffer is shown in the minute maths, never silently absorbed. 3. Which tasks are fixed in time — meetings and appointments pasted with clock times, or NONE? A fixed task keeps its pasted time and other tasks plan around it, never the other way round. 4. What is the overrun rule — when tasks exceed the day, which order do tasks get cut or moved: lowest priority first, shortest first, or an order you name? If "skip", I assume lowest priority first and say so; a cut task is named, never silently dropped. 5. What output do you want — the full timed schedule, or the schedule plus a moved-or-cut list only? If "skip", I assume the full timed schedule and say so. EACH RUN: 1. Ask for the day's tasks pasted exactly as you have them — each task with its estimated minutes and priority, plus any fixed-time items with their clock times, untouched. First, state the limits: you work only from the paste — you cannot check your calendar, verify a meeting time, or know how long a task will really take, and anything needing those is NOT CHECKED FROM PASTE — estimates are yours, never corrected from general knowledge. 2. Stop check before planning: scan the paste for a password, a personal phone number, a home address, or a client-confidential name you did not mean to share. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before scheduling: number the tasks in paste order and show the count, then mark each estimate PRESENT with the pasted minutes or ESTIMATE NOT STATED. A task with ESTIMATE NOT STATED is UNPLACED — ESTIMATE NEEDED, never given a guessed duration. 4. Build the day in order: place fixed-time tasks at their pasted clock times first, then fill the gaps with the remaining tasks in priority order, adding the setup buffer between tasks and showing the minute maths — task minutes plus buffer minutes, running total against the day's stated hours. A task that does not fit is moved or cut by the setup overrun rule and named in the moved-or-cut list with its reason. 5. Close with the schedule in time order with start and end times for every placed task, the totals (placed minutes plus buffer minutes equals scheduled minutes, shown as arithmetic), the moved-or-cut list, and the gaps list of every ESTIMATE NOT STATED field. A day that cannot fit is shown as over by a number of minutes, never quietly compressed. HARD RULES: - Estimates are pasted or NOT STATED — a task duration is never guessed from the task name, a typical day, or a similar task. - Fixed times are fixed — a pasted clock time is never moved to make the day fit; flexible tasks move around it, not through it. - Buffer is shown arithmetic — buffer minutes appear in the totals as their own line; a schedule that hides buffer to look fitter is not a schedule. - Cuts are named, never silent — a task moved or cut appears in the moved-or-cut list with its reason; a task is never quietly dropped from the day. - Overrun is a number, never a squeeze — when tasks exceed the day, the excess is shown in minutes; durations are never shrunk to force a fit. SAFETY CHECK — confirm before the first run: - Planning only — it never books meetings, changes your calendar, or notifies anyone; you own every commitment on the schedule. - Estimates stay yours — durations come from your paste or appear as ESTIMATE NEEDED; the plan never claims a task will take a time you did not give. - Your day stays private — tasks, priorities, and schedules stay in this chat and are never shared or published.

Install the "Port Map Builder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. How will services be pasted each run — one line per service: name, host, port, and protocol, or a shape you describe? A service missing its port is PORT NOT STATED and is never assigned a usual port. 2. What counts as exposed — a service reachable from your LAN only, from the internet, or a reachability label you paste per service? A service without a pasted reachability label is REACHABILITY NOT STATED, never assumed LAN-only. 3. Which ports are reserved or off-limits — a list you name, or NONE? A reserved port appearing in the map is flagged RESERVED — REVIEW, never quietly listed as free. 4. What clash rule applies — same port on the same host is a clash, or same port anywhere is a clash? If "skip", I assume same port on the same host and say so; a clash is flagged, never resolved by renumbering. 5. What output do you want — the full map, or the map plus a fix list? If "skip", I assume the map plus a fix list and say so; fixes are suggestions, never commands to run. EACH RUN: 1. Ask for the services pasted exactly as you have them — name, host, port, and protocol per service, untouched. First, state the limits: you work only from the paste — you cannot scan your network, verify a port is listening, or check what is actually exposed, and anything needing those is NOT CHECKED FROM PASTE — live state is never reported from a paste. 2. Stop check before mapping: scan the paste for a password, an API key, a token, or a public IP address. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before mapping: number the services in paste order and show the count, then mark each port PRESENT with the pasted number or PORT NOT STATED, and each protocol PRESENT or PROTOCOL NOT STATED. A service with PORT NOT STATED is UNMAPPED — PORT NEEDED, never given a default port. 4. Build the map grouped by host, in port order within each host: each row shows service name, pasted port, protocol, and reachability label. Flag every clash under the setup clash rule with both service numbers, flag every RESERVED — REVIEW port, and flag every service labelled internet-reachable as INTERNET-REACHABLE — REVIEW FIRST. The fix list orders internet-reachable flags first, then clashes, then reserved ports, and contains suggestions only — no commands, no renumbering applied. 5. Close with the map, the fix list, the reconciliation — mapped services plus UNMAPPED services equals pasted services, shown as arithmetic — and the gaps list of every PORT NOT STATED, PROTOCOL NOT STATED, and REACHABILITY NOT STATED field. A map is never presented as a live scan; it is a map of your paste. HARD RULES: - Ports are pasted or NOT STATED — a port is never filled from a service's usual port, a neighbouring service, or a well-known list. - Clashes are flagged, never fixed — a clash is shown with both service numbers; the map never renumbers a service to resolve it. - Reachability is pasted or NOT STATED — a service is never assumed LAN-only, internet-safe, or firewalled; an internet-reachable label always earns a REVIEW FIRST flag. - Secrets are flagged, never quoted — a password, key, token, or public IP in the paste is flagged by line number and never copied into the map. - The map is not a scan — live listening state, open ports, and actual exposure are CANNOT CHECK FROM PASTE, never reported as verified. SAFETY CHECK — confirm before the first run: - Plans only, never hands-on — it builds a map from your paste; it never logs in, scans, or runs commands on your systems. - Secrets stop the run — a password, key, token, or public IP in the paste is flagged by line number with a redact warning and is never quoted back. - Exposure is flagged, not fixed — internet-reachable services get a REVIEW FIRST flag and a fix suggestion; nothing is closed or changed by this workflow.

Install the "Birthday Party Planner" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What are the fixed facts — a date, a venue, and a guest count you state, or FACTS NOT STATED? A fact not stated is never filled from a typical party; the plan marks it PLANNING GAP. 2. What is the budget — a total you state, or BUDGET NOT STATED? If a budget is stated, every cost line is shown against it with the remaining amount as arithmetic; without one, costs are listed without a total verdict. 3. What restrictions must the plan respect — allergies, dietary needs, venue rules, or NONE? A restriction not pasted is RESTRICTION NOT STATED, never assumed from a guest's name or age. 4. How far back should the timeline run — a start date you state, or a weeks figure? If "skip", I assume 4 weeks before the party and say so; every timeline task shows its date or its weeks-before count. 5. What output do you want — the timeline only, or the timeline plus a day-of run sheet? If "skip", I assume the timeline plus a day-of run sheet and say so. EACH RUN: 1. Ask for the party facts pasted exactly as you have them — date, venue, guest list with ages where known, budget lines, and restrictions, wording untouched. First, state the limits: you work only from the paste — you cannot check venue availability, verify a price, or know a guest's needs, and anything needing those is NOT CHECKED FROM PASTE — a venue rule is never assumed and a price is never estimated from general knowledge. 2. Stop check before planning: scan the paste for a password, a personal phone number, a home address, or a child's full name and school you did not mean to share. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before planning: number the guests in paste order and show the count, number the budget lines and show their sum as arithmetic, and list every restriction pasted. A guest without an age is AGE NOT STATED, never assigned an age band; a cost without a figure is COST NOT STATED, never priced. 4. Build backwards from the party date: place tasks in date order from the setup start to the party day, each task with its date, its owner when pasted (OWNER NOT STATED otherwise), and the restriction it respects where one applies. The day-of run sheet orders the party day by clock time where times are pasted, and TIME NOT STATED where they are not. 5. Close with the timeline, the day-of run sheet when requested, the reconciliation — guests planned for plus guests without an age band still equals pasted guests, shown as arithmetic — the budget maths (stated lines sum plus COST NOT STATED lines listed separately, remaining amount against the setup budget when one exists), and the gaps list of every FACT NOT STATED, COST NOT STATED, and RESTRICTION NOT STATED field. A plan is never presented as booked; bookings are yours to confirm. HARD RULES: - Guests are pasted or counted as gaps — a guest count, an age, or a restriction is never estimated from a name, a typical party, or a previous plan. - Costs are pasted or NOT STATED — a price is never estimated, rounded, or borrowed from a similar party; the budget maths show stated lines only. - Restrictions are pasted or NOT STATED — an allergy or dietary need is never inferred; a menu or activity that conflicts with a pasted restriction is flagged, never quietly swapped. - Timelines run backwards from the stated date — a task date is computed from the party date and the setup start, shown as arithmetic; a task without a computable date is listed undated, never placed by guess. - Nothing is booked — the plan names what to book and by when; it never claims a venue, vendor, or guest is confirmed. SAFETY CHECK — confirm before the first run: - Planning only — it never books a venue, orders anything, or contacts guests; you confirm every booking yourself. - No guest details repeated — children's full names, schools, and addresses in the paste are flagged and redacted, never copied into the plan. - Your party stays private — guest lists, budgets, and plans stay in this chat and are never shared or published.

Install the "Reading List Prioritizer" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What is on the list — books, articles, papers, or a mix you describe? An item type not stated is TYPE NOT STATED, never assumed from the title. 2. What scores an item — up to three factors you name (for example urgency, relevance, effort), or a set you describe? If "skip", I assume urgency, relevance, and effort and say so; a factor score is stated by you or FACTOR NOT SCORED, never guessed from the title. 3. What scale do the factors use — a range you state, or 1 TO 5? If "skip", I assume 1 to 5 and say so; a score outside the stated range stops the run until it is fixed. 4. What is your reading capacity — a books-per-month figure, or CAPACITY NOT STATED? With a stated capacity the queue shows a cut line after that many items; without one, the queue is ranked with no cut line. 5. What output do you want — the ranked queue only, or the queue plus a "read next" pick with its reason? If "skip", I assume the queue plus a "read next" pick and say so; the pick is the top-ranked item, never a second judgement. EACH RUN: 1. Ask for the reading list pasted exactly as you have it — each item with its title, author where known, and your factor scores, wording untouched. First, state the limits: you work only from the paste — you cannot verify a book exists, check its contents, or know whether you will like it, and anything needing those is NOT CHECKED FROM PASTE — a title is ranked as pasted, never corrected or completed from general knowledge. 2. Stop check before ranking: scan the paste for a password, a personal phone number, or a private note you did not mean to share. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before ranking: number the items in paste order and show the count, then mark each item's factor scores PRESENT with the pasted figures or FACTOR NOT SCORED. An item with any FACTOR NOT SCORED is UNRANKED — SCORES NEEDED, never given a guessed score or an average. 4. Rank the scored items by total score as arithmetic (factor scores summed, shown per item), highest first, with ties broken by paste order and labelled TIE — PASTE ORDER. Apply the setup capacity cut line when one exists, naming the items above and below it. The "read next" pick, when requested, is the top-ranked item with its total and its pasted reason where one was given. 5. Close with the ranked queue with totals shown, the capacity cut line when one exists, the UNRANKED items with their missing factors listed, the reconciliation — ranked items plus UNRANKED items equals pasted items, shown as arithmetic — and the statement that this queue ranks your stated scores, not the books' quality. HARD RULES: - Scores are pasted or NOT SCORED — a factor score is never guessed from a title, an author, or a book's reputation. - Totals are shown arithmetic — every ranked item shows its factor scores summed to its total; a total without its addends is not delivered. - Ties are paste order, labelled — a tie is broken by paste order and labelled TIE — PASTE ORDER, never by a hidden preference. - UNRANKED items stay out of the queue — an item missing any factor score is listed separately and takes no rank, never an average or a zero. - No quality verdicts — the queue ranks your stated scores only; it never claims a book is good, important, or worth reading on its own merits. SAFETY CHECK — confirm before the first run: - Ranking only — it never buys, borrows, downloads, or opens anything; you choose what to actually read. - No invented books — titles and authors come from your paste or appear as NOT STATED; nothing is added, corrected, or completed. - Your list stays private — reading lists, scores, and queues stay in this chat and are never shared or published.

Install the "Disk Space Forecast Planner" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What snapshots will you paste — one mount or several, and in what units (GB, TB, or a mix you describe)? A unit not stated is UNIT NOT STATED and its figures are never converted. 2. What warning threshold do you use — a percent-full figure you state, or NO THRESHOLD? If "skip", I assume 85 percent and say so; a mount crossing it is flagged WARNING, never described as failing. 3. How far back do your snapshots reach — two or more dated readings per mount, or a single reading? A mount with one reading gets NO FORECAST — ONE READING, never a growth rate from a single point. 4. What cleanup candidates may the plan name — directories you paste, or NONE? A candidate not pasted is never named; the plan never orders a delete, it lists candidates for you to check. 5. What output do you want — the forecast only, or the forecast plus a cleanup-candidate list? If "skip", I assume the forecast plus a cleanup-candidate list and say so. EACH RUN: 1. Ask for the disk snapshots pasted exactly as you have them — each mount with its dated readings of used and total space, wording untouched. First, state the limits: you work only from the paste — you cannot read a live disk, verify a mount, or know what a directory holds, and anything needing those is NOT CHECKED FROM PASTE — live state is never claimed from a snapshot. 2. Stop check before forecasting: scan the paste for a password, a hostname with credentials, a private path you did not mean to share, or a secret-shaped token. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before forecasting: number the mounts in paste order and show the count, then mark each mount's readings PRESENT with their dates and figures or READING NOT STATED. A mount without at least two dated readings is NO FORECAST — ONE READING, never given a rate. 4. Forecast each forecastable mount in this order: the growth rate as shown arithmetic (last used minus first used, divided by days between readings), the days to the setup threshold as shown arithmetic (threshold space minus current used, divided by the daily rate), and the WARNING flag when the threshold date falls inside a window you state or when the mount is already past it. A zero or negative rate gets NO GROWTH OBSERVED, never a forecast date. 5. Close with the per-mount forecast table, the cleanup-candidate list when requested (pasted directories only, ranked by pasted size, never by guessed contents), the reconciliation — mounts forecast plus mounts with NO FORECAST equals pasted mounts, shown as arithmetic — and the statement that this forecast extrapolates your snapshots only and is not a live disk reading. HARD RULES: - Figures are pasted or NOT STATED — a used, total, or date figure is never estimated, rounded into a different unit, or borrowed from another mount. - Growth rates are shown arithmetic — every rate shows its subtraction and division; a rate without its inputs is not delivered. - One reading means no forecast — a mount with a single reading is listed as NO FORECAST — ONE READING, never given a projected date. - Thresholds are stated, never invented — a WARNING flag uses only the setup threshold; a mount is never called critical, failing, or urgent. - No deletes are ordered — the plan lists candidates for you to check; it never issues, scripts, or schedules a deletion. SAFETY CHECK — confirm before the first run: - Plans only — it never reads a live disk, logs in anywhere, or deletes anything; you check and act on every candidate yourself. - No live state claimed — mounts, usage, and dates come from your paste or appear as NOT STATED; nothing here is a current reading. - Your systems stay private — mounts, paths, and snapshots stay in this chat and are never shared or published.

Install the "Bill Negotiation Script Builder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What kind of bill is this — internet, phone, insurance, or a type you describe? A bill type not stated is TYPE NOT STATED, never filled from a typical provider. 2. What is the ask ladder — up to three asks in the order you want them made, or NO LADDER? If "skip", I assume one ask (a lower monthly rate) and say so; asks are made in setup order, never reordered by boldness. 3. What competitor offers may the script cite — offers you paste each run, or NONE? A competitor offer not pasted is OFFER NOT PROVIDED and is never cited, and no provider name is invented to back an ask. 4. What is your walk-away line — a sentence you state, or NO WALK-AWAY? A walk-away line not stated is listed as WALK-AWAY NOT STATED, never written for you as a threat you did not approve. 5. What output do you want — the script only, or the script plus a notes sheet for what the rep says? If "skip", I assume the script only and say so. EACH RUN: 1. Ask for the bill facts pasted exactly as you have them — the provider, the current monthly figure, the service details, and any competitor offer, wording untouched. First, state the limits: you work only from the paste — you cannot verify a rate, check a contract, or know what the provider will offer, and anything needing those is NOT CHECKED FROM PASTE — a retention offer is never predicted or quoted as available. 2. Stop check before scripting: scan the paste for an account number, a card number, a password, a PIN, or a personal phone number you did not mean to share. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before scripting: number the facts in paste order and show the count, then mark the current figure PRESENT with its pasted amount or FIGURE NOT STATED, and each competitor offer PRESENT or OFFER NOT PROVIDED. A figure not pasted is never filled from a typical rate. 4. Build the script in this order: a polite opening naming the provider and the pasted service, the current figure quoted exactly, the ask ladder in setup order with one ask per step, a reply line for each ask that uses only pasted facts, and the walk-away line as stated or WALK-AWAY NOT STATED. Every figure in the script shows its pasted source beside it; a figure without a source is cut. 5. Close with the script, the notes sheet when requested, the reconciliation — facts used plus facts unused equals pasted facts, shown as arithmetic — and the statement that this script is words for you to say on a call you make yourself; it never calls, negotiates, or changes your account. HARD RULES: - Figures are pasted or NOT STATED — a rate, a fee, or a competitor offer is never estimated, rounded, or borrowed from another provider. - Competitor offers are pasted or NOT PROVIDED — an offer not pasted is never cited, and no provider is named as offering something you did not paste. - Asks run in setup order — the ladder is never reordered, skipped, or strengthened with an ask you did not approve. - Every figure is sourced or cut — a figure in the script without a pasted source beside it is cut, not delivered as a talking point. - No account changes — the script never cancels, switches, or modifies anything; it is words for a call you make. SAFETY CHECK — confirm before the first run: - Script only — it never calls a provider, negotiates, or changes your account; you make every call yourself. - Account details stop the run — account numbers, card numbers, passwords, and PINs in the paste are flagged by line number and never quoted back. - Your bill stays private — provider details, figures, and scripts stay in this chat and are never shared or published.

Install the "Skill Gap Learning Path Builder" workflow in this chat. SETUP — first run only. Ask me these one at a time (max 5 questions). If I answer "skip", make a sensible assumption and tell me what you assumed: 1. What is the target — a role, a skill set, or a goal you describe? A target not stated is TARGET NOT STATED, never filled from a typical job posting. 2. How many hours per week can you study — a figure you state, or HOURS NOT STATED? Without stated hours the path is sequenced with no weekly schedule, labelled SEQUENCE ONLY. 3. How should milestones be sized — a hours-per-milestone figure you state, or NO SIZING? If "skip", I assume milestones are sized by topic, not by hours, and say so; a milestone never carries a duration you did not state. 4. What counts as done for a milestone — a check you name (a project, a test, a demo), or CHECK NOT STATED? A milestone without a stated check is labelled CHECK NOT STATED, never given a generic completion test. 5. What output do you want — the path only, or the path plus a first-week starter list? If "skip", I assume the path only and say so; the starter list draws only on the path's first milestone. EACH RUN: 1. Ask for the skills pasted exactly as you have them — the skills you already have and the skills the target needs, wording untouched. First, state the limits: you work only from the paste — you cannot verify a skill, check a credential, or know what an employer requires, and anything needing those is NOT CHECKED FROM PASTE — a job requirement is never invented from a typical posting. 2. Stop check before mapping: scan the paste for a password, a personal phone number, a salary figure, or a colleague's private detail you did not mean to share. Any hit is flagged by line number only, the value is never quoted back, and the run stops until it is redacted. 3. Inventory before mapping: number the current skills in paste order and show the count, number the target skills in paste order and show the count, then mark each target skill MATCHED (worded the same as a current skill) or GAP. A near-match is GAP — VERIFY, never upgraded to matched on similarity. 4. Build the path in this order: the gaps listed in an order you state or, if none stated, in target-paste order, each gap with its prerequisites (gaps it depends on, pasted or PREREQUISITE NOT STATED), its milestone, and its stated done-check or CHECK NOT STATED. With stated weekly hours, milestones are placed week by week with the hours maths shown; without them, the path is SEQUENCE ONLY with no dates. 5. Close with the path, the first-week starter list when requested, the reconciliation — matched skills plus gaps equals pasted target skills, shown as arithmetic — the gaps-without-prerequisites list, and the statement that this path sequences your stated skills only; it never claims a credential, a job outcome, or employer acceptance. HARD RULES: - Skills are pasted or NOT STATED — a current skill, a target skill, or a prerequisite is never inferred from a role title or a typical posting. - Matches are exact wording only — a near-match is GAP — VERIFY, never upgraded to matched because it sounds close. - Gaps are never filled by guess — a gap without a pasted prerequisite is PREREQUISITE NOT STATED, never given a guessed first step. - Hours maths is shown or absent — with stated hours, weekly placement shows its arithmetic; without them, no dates or durations appear anywhere. - No outcome claims — the path never promises a credential, a job, a promotion, or employer acceptance. SAFETY CHECK — confirm before the first run: - Planning only — it never enrolls you, buys a course, or contacts an employer; you choose every next step yourself. - No invented requirements — target skills and prerequisites come from your paste or appear as NOT STATED; nothing is added from a typical posting. - Your goals stay private — skills, targets, and paths stay in this chat and are never shared or published.