Tinfoil Kimi K3 E2EE TEE coming this week!

fips-tollgate MVP turns any FIPS mesh gateway into a pay-per-minute service: customers drop a Cashu ecash token (Bitcoin sats) to buy time-metered access, and the system grants, tracks, and automatically revokes that access when the paid time runs out — no accounts, no signups, no company in the middle.

gitworkshop - Decentralized Git

Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.

Date: 2026-07-23 Status: exploratory vision — not a commitment, not a roadmap promise. Context: written after reviewing the fips-tollgate MVP and the nostr-vpn (mmalmi) README. nostr-vpn is a Tailscale-style mesh VPN built on the same FIPS data plane fips-tollgate uses, with signed join-request admission, exit-node selection, WireGuard upstream egress, and shipped native apps (including iOS/Android). This document preserves a design conversation about what the integration of these two pieces could mean and what could be built on top of it. --- ## The core insight: accounts disappear from the entire stack Every VPN that has ever existed works the same way: identity first (email, account, payment card), access second. Even Mullvad's numbered accounts are still *accounts*. This integration inverts it completely: - Who are you? A keypair you generated yourself. - What did you pay? A bearer ecash token — cash, not a card. - How do you get in? A cryptographic signature on a roster. - How do you get kicked out? A janitor with a timer (the reconcile sweep). There is no user database anywhere in this system. Nothing to leak, nothing to subpoena, nothing to breach. That's not a feature — it's a *category change*. The product stops being "a VPN subscription" and becomes **access itself, sold as a commodity**, like electricity from a socket. The tollgate control plane is four machines, and none of them care what is being sold: 1. **A ticket seller** — verifies a Cashu token at the mint, converts sats into minutes. 2. **A wristband printer** — records "npub X is allowed until 10:30". 3. **A turnstile** — the FIPS ACL / nvpn roster that physically enforces admission. 4. **A janitor** — the reconcile sweep that removes expired grants even when no process is running. ## What could be built, near to far 1. **The vending-machine VPN.** Open the app, insert 10 sats, get one hour online. No signup, no email, no subscription dark patterns. The nvpn mobile apps already exist — this is a payment flow, not a product build. 2. **Operator-in-a-box.** nvpn already packages for StartOS and Umbrel — the home-server crowd. A one-click "Paid Exit Node" service: set your price, plug in your WireGuard upstream, and an always-on home server earns sats while its owner sleeps. That's the supply side of the market, and the packaging channel already exists. 3. **The giftable internet voucher.** A Cashu token can travel over *any* channel — DM, QR code, printed paper. VPN access becomes a transferable bearer instrument: a friend in a free country buys hour-tokens and sends them to a friend somewhere censored, where credit cards don't work and VPN merchant accounts are blocked anyway. You cannot DM someone a VPN subscription; you *can* DM them ecash redeemable at any participating exit. 4. **The exit market.** Operators advertise exits on Nostr relays (the TollGate kind-10021 offer event, grown up): city, price per hour, mint. Clients browse, compare, pick. Price discovers jurisdiction, quality, and trust. This is the economic cure to Tor's exit scarcity — a tragedy of the commons where volunteers absorb legal risk for free. A price signal fixes it: don't beg people to run exits; pay them. 5. **Wholesale recursion.** A gateway operator with customers but no appetite for exit risk buys exit capacity from another operator — settlement in ecash, per session, enforced by the same tollgate on the exit side. A wholesale bandwidth market with no contracts, no invoices, no minimums. 6. **The services bazaar.** The same control plane can sell anything reachable on a mesh: a Nostr relay, a storage box, a game server, a media library, a build cache. Every home server becomes a stall in a bazaar, and every stall has the same coin slot. ## What it means, zoomed all the way out Nostr, Cashu, and FIPS are three protocols swimming toward the same reef: **who you are, how you pay, how you connect** — identity, money, and networking, each open, with no company in the middle. This integration is one of the first places they click together into a single economic organism: discovery flows through Nostr, payment flows through Cashu, traffic flows through FIPS, and the tollgate is the connective tissue that turns the whole thing into a market instead of a hobby. Bandwidth today is a stranded asset — every home connection sits mostly idle, worthless because there's no safe way to sell sips of it to strangers. This stack makes bandwidth *liquid*. The headline: **the internet's last mile becomes a peer-to-peer marketplace, and access becomes money.** ## Honest tether - Two-sided markets are brutally hard to bootstrap; the vending-machine VPN and operator-in-a-box come first, the bazaar comes after liquidity. - Regulators will have opinions about paid telecom-ish services. - The abuse problem doesn't vanish because the payment rail is anonymous — it gets *priced*, which is different and defensible, but it still has to be designed for (rate limits, upstream terms, jurisdiction choice). - Mobile VPN UX has sharp edges; nvpn's own README notes platform hardening in progress. - nvpn caveats to verify before building: headless roster approval/revocation, revocation liveness, one-active-network-per-device, and keeping two control planes (tollgate ACL vs nvpn roster) from fighting over the same network. ## The concrete first step A small spike, not a build: stand up an nvpn test network, confirm headless roster approve/revoke from the CLI, then prototype the **bridge daemon** — join requests + Cashu tokens in, roster signatures in, expiry sweeps out — reusing the existing Merchant, session store, and reconcile logic. The reconcile invariant transfers unchanged: *the roster must equal the set of active paid sessions.* --- *Preserved from a design conversation on 2026-07-23 so the idea doesn't evaporate. Visions expire; documents don't.*

What you actually built (the ticket booth) Strip away the FIPS and Cashu specifics and your MVP is four machines bolted together: 1. A ticket seller — takes a Cashu token, checks it's real and unspent at the mint, converts sats into minutes. 2. A wristband printer — writes down "npub X is allowed until 10:30" (the session store + the ACL entry with its expiry marker). 3. A turnstile — the FIPS ACL and firewall that physically enforce "is this npub allowed through, yes or no." 4. A janitor — the reconcile sweep that walks around removing expired wristbands, even if everyone went home. Notice something: none of these four machines know or care what's behind the turnstile. They handle payment, identity, time, and enforcement. The thing being sold is just... whatever the operator decided to put back there. The small pond vs. the big ocean Right now, what's behind the turnstile is services on your private mesh — an SSH box, a file share, a web service. Who pays for that? Mostly hobbyists and your friends. It's a small pond, and it's stocked with fish you put there yourself. The original TollGate idea aims at a much bigger ocean: selling internet access itself. Someone with no connectivity — a traveler, someone whose data plan ran out, someone on censored or broken infrastructure — pays a few sats and gets online through your connection. That's a proven, universal demand; people already pay for hotspot Wi-Fi, mobile data, and VPNs every day. The commodity is valuable everywhere on Earth, unlike "access to my mesh." Why you're not locked in Here's the key point: switching from the pond to the ocean is a venue change, not a rebuild. Your turnstile today says "this npub may peer with my mesh and reach port 22." The internet version says "this npub's traffic may exit to the internet through me." Same ticket seller, same wristbands, same turnstile mechanism, same janitor — only the rule written on the gate changes. That collection of machinery is called the control plane, and you built it once, correctly, in a way that doesn't depend on the product being sold. That's what I meant by "it transfers." Mesh-only was a safety cage, not a wall — you deliberately scoped down (test funds, no abuse exposure) while proving the machinery. Smart. But nothing in the code welded the cage shut. The identity head-start This part is easy to underrate. Traditional paid Wi-Fi gateways have a miserable identity problem: they recognize customers by MAC address (easily spoofed, and modern phones randomize it constantly) or by captive-portal accounts (emails, passwords, a database to hack). You skipped all of that. Your customer identity is a nostr keypair from day one — unforgeable, portable, no accounts, no personal data, and the mesh handles addressing so there's no IP-management bookkeeping either. Anyone rebuilding TollGate on plain Wi-Fi has to duct-tape exactly the layer you got for free. That's the genuinely novel contribution hiding inside your MVP. What does not transfer for free Honesty time — the ocean has sharks the pond doesn't: - Byte metering. On your mesh, an hour of access costs you nothing per packet. On an internet exit, a customer who paid for an hour can burn gigabytes — your money. You'd need per-peer traffic accounting, which your own docs already list as future work. - Abuse and legal exposure. Whatever customers do comes from your IP address. This is exactly why mesh-only was the right MVP scope, and crossing this line needs a real review, not just a config change. - Customer experience. Discovery (how does a stranger find your offer?) needs the Nostr advertisement/discovery transport — the advertise command on the roadmap is the first small step. In one sentence: you set out to sell fish from a small private pond, but along the way you built a tollbooth that works on any road — and the pond was just the safest place to test the tollbooth. 🐡

Kimi K3 opinion on my fips-tollgate MVP: "Honestly? It's one of the better MVPs I've read, and having now changed code in it rather than just reviewed it, I can say that with more confidence — the codebase fought back in all the right places. What genuinely stands out The dependency discipline is the headline. A stdlib-only core with the entire Cashu/Nostr dependency graph quarantined in one isolated module means the money-and-access logic is auditable in an afternoon, builds offline, and tests without network. Most projects get this backwards — they let the payment library leak into everything and then can't test anything without a mint. You (or whoever drove those early phases) made the expensive-correct call before it was expensive. The safety engineering has real blast-radius thinking: --apply never implied, the /etc/fips fixture guard, managed blocks that preserve operator content, atomic writes with fsync and directory sync, strict mode treating unmanaged allow entries as hostile. That's the mindset of someone who has been bitten by a config-management tool clobbering hand edits before. And the docs culture — phase reports with an explicit "honest limitations" section admitting the Phase 7 customer was your own upstream — is rarer than any technical feature here. Projects that lie to themselves in their docs lie to themselves in their code eventually. The one systemic blindspot The expiry bug is instructive precisely because the testing was otherwise good. Every layer was verified: timers tested in-process, the live pilot tested the adapters, replay tested against a real mint. But nobody ran the composed system in the shape it's actually deployed — purchase via one-shot CLI, process exits, timer service ticks later. Each fish was healthy; the tank had a leak. That's the classic MVP trap, and the fix (reconcile over per-process timers) is the right one because it matches operational reality instead of aspiring to be a daemon it isn't yet. I'd rather maintain a correct cron loop than a half-built daemon. What I'd watch as it grows 1. The CLI-per-action model is at its ceiling. Purchase races, 30-second expiry granularity, no event log — these all quietly point at a long-running process eventually. Not now; the reconcile model bought you time. But the day you want sub-minute expiry or an audit trail, that's the daemon forcing function. 2. The money path is test-funds honest but real-funds fragile: payment-taken-gate-failed strands customer sats, and remainders vanish. Fine today; both must close before any real-value pilot, along with the audit log — the first "I paid and got nothing" dispute with no event log ends the experiment. 3. The product question underneath it all: paid access to mesh-local services is a niche. The real TollGate gravity is internet-access resale. What this MVP actually proves — that FIPS's npub identity + ACL maps cleanly onto TollGate's pay-per-allotment model, with cryptographic customer identity from day one (no MAC addresses, no IPAM) — is the genuinely novel part, and it transfers. You're not locked into mesh-only; you've built the control plane either way. Verdict Compact (~3,200 lines, much of it tests), honest, correctly scoped, and now — with expiry reconciled — internally consistent in the shape it deploys. It's not production-ready and says so, which is exactly what "good MVP" means: every claim in the README survived me checking it except one, and that one is fixed. The distance from here to "a stranger could run this with test funds" is short and mostly paved: the P0 money-path items, the audit log, and a two-node pilot. If you keep the same discipline — small phases, honest results files, verify in deployment shape — this has a real shot at being the reference FIPS-TollGate bridge. Solid little fish. 🐡"

Had Kimi K3 take a look at my fips-tollgate MVP Spent 3,000 sats on a fresh commit to #ngit Signed with Amber on my GrapheneOS Hey @Sovereign Engineering thinking of you ⛵

gitworkshop - Decentralized Git

Decentralized GitHub alternative over Nostr for browsing repositories, managing issues, and collaborating on pull requests.

All the models -- No subscriptions -- No permission @routstr D

Prompt caching coming to Tinfoil TEE models

@redshift I can see private provider tinfoil models when i run routstrd models --model tinfoil-glm-5-2 but i don't see them when i run opencode and try to select that model under routstr I do see a tinfoil-deepseek available FYI tinfoil recently dropped Deepseek so that must be yours because it wasn't available to me yesterday

# How to access frontier opensource AI in the most private way # Combine opensource Tinfoil TEE models + Opencode via @routstr Use routstrd, a TUI to monitor and control all your AI token uses in a terminal window bun i -g routstrd routstrd onboard # choose opencode routstrd receive 6900 # pay with lightning routstrd top # see usage stats / dashboard This single tool allows you to never leave the terminal for AI inference. Never log into an AI account again. No more subscriptions, emails or credit cards. Pay per request using permissionless #cashu #bitcoin Open new terminal window Make new project directory cd into project directory run opencode ctrl+p to select models scroll down to routstr provider select tinfoil-glm-5-2 Your client verifies a remote attestation proof, encrypts your prompts locally, is decrypted by the TEE, encrypted responses sent back to your key and decrypted locally. By using E2EE TEE models with routstr you combine private anonymous payments, blind yourself to the node and blind yourself to the AI provider all without permission. Build your freedom tech privately, without permission or limits.

Celebrating 1 year of serving private AI inference 🪄 Private Provider has been here from the start of @routstr operating the longest running node outside of the dev team! #nostr + #cashu #bitcoin + #AI + #Freedomtech Cypherpunks route around!

Private Provider is proud to offer Tinfoil TEE models including GLM 5.2 and Kimi K2.6 fully end to end encrypted 🔥🔥🔥 View article →

On a retail Passport Prime running KeyOS v1.2.1, can a user sideload an app signed with a self-generated cosign2 developer key over USB, or does the device only run Foundation-signed apps / require a developer unit or developer mode? @QnA

It is just a calculator...

Hello @Foundation !

## Project Intake Form A short, plain-English worksheet to get your app idea out of your head before you start building with Fugu. This form only asks about things that YOU know: what you want and why. The technical decisions (tools, commands, safety rules) are figured out later with Fugu and captured in the project AGENTS.md after the project is scaffolded — so you do not need to answer any technical questions here. How to use this form • Fill this out first, in plain language. Short answers are fine. • Focus on the first useful version, not the whole dream app. • When you are done, send the kickoff prompt at the bottom to Fugu, then follow the walkthrough (Starting From Only an App Idea) for the rest. • If you are unsure about anything, just write what you are thinking — Fugu can help refine it. 1. One-sentence description Formula: This is a [kind of app] for [who] that helps them [main outcome]. Example: This is a habit tracker for me that helps me check off daily habits. Answer: 2. Who is it for? Who will use it? If it is just for you at first, say that. Answer: 3. What problem does it solve? What is annoying or hard today, and what should feel better once the app works? Answer: 4. The first version Describe the smallest version that would still be useful. Keep it small — you can always add more later. Answer: 5. The main thing a user does Describe the most important flow in simple steps, from what they do first to what they see at the end. Example: Add a habit, check it off today, see today’s habits, see the current streak. Answer: 6. What "done" looks like How will you know the first version works? Describe it in plain terms. Example: I can add habits, check them off, my data is still there after I refresh, and I can start the app with one command. Answer: 7. What to leave out for now List anything you do NOT want in the first version. This keeps the project small and focused. Examples: accounts and logins, payments, a mobile app, sharing with others, fancy settings. Answer: 8. Anything else Fugu should know Likes, dislikes, inspirations, must-haves, or things to avoid. Anything that helps Fugu understand your taste. Answer: Kickoff: hand this to Fugu When the form is filled in, start your session and send this. Replace the bracket with your answers above. Kickoff prompt to send Fugu: " I'm brand new and have no coding experience. I have an idea for an app. Please guide me step by step, explain things in plain English, and don't build anything until I approve a plan. Here is my filled intake: [paste your answers to the questions above]. Based on this, help me confirm a small first version, then recommend a simple stack and a plan — and wait for my approval before building. " After that, follow the walkthrough document (Starting From Only an App Idea) for choosing tools, scaffolding, saving, and building one small slice at a time.

## Starting From Only an App Idea - What to Say to Fugu A friendly, conversational walkthrough for someone with no coding experience who has an app idea only in their head. Each phase includes a copy-paste prompt you can send to Fugu. Go one phase at a time, and let Fugu explain anything you don't understand. Before you begin - the mindset • You do not need to know how to code. Your job is to describe what you want and review what comes back. • Go slowly. Build in small steps. Save often so you can always undo. • If anything is unclear, ask Fugu to explain it in plain English. Phase 1 - Introduce yourself and your idea Start the session by setting the tone. Fill the brackets with your own idea, then send this: Prompt to send: I'm brand new and have no coding experience. I have an idea for an app. Please guide me step by step, explain things in plain English, and don't build anything until I approve a plan. Here's my idea: [describe your idea in a few sentences: what it is, who it's for, and the main thing it should let someone do]. Phase 2 - Let Fugu sharpen the idea Let Fugu ask you questions to fill the gaps. Then ask it to define a small first version: Prompt to send: Based on my idea, help me define the simplest first version that is still useful. Tell me what the first version should include, and just as importantly, what to leave out for now so I don't overbuild. Phase 3 - Choose the tools You don't need to know the tools. Ask Fugu to recommend a sensible default and explain it: Prompt to send: Recommend a simple, boring, well-supported way to build this. Explain in plain English why you chose it and what I'll be able to do with it. Then wait for my approval before doing anything. Phase 4 - Scaffold the running skeleton Once you approve the tools, have Fugu create and run the starting point: Prompt to send: Please scaffold the project using the standard setup for that stack, then run it so I can see a basic version working. Show me the real commands to run, test, and build it. Phase 5 - Save your first checkpoint Before adding features, lock in a safe save point: Prompt to send: Set up version tracking (git) if it isn't already, and save this working baseline with a clear message. Explain what you did in plain English. Phase 6 - Create the project instructions file Give future sessions a short operating manual based on the real project: Prompt to send: Now create a short AGENTS.md for this project using the real commands and folder structure. Keep it to one page: what it is, the current goal and what 'done' looks like, the commands, and any safety boundaries. Then save it. Phase 7 - Build one small slice at a time This is the main loop. Repeat it for each small feature. Start each slice like this: Prompt to send: Let's add just one small thing: [describe one visible feature, for example: let me add an item to the list]. Propose a short plan first and wait for my approval before building. After Fugu builds each slice, always send these two review prompts: Prompt to send: In plain English, what exactly changed? Prompt to send: Did you run and test it? What was the actual result? Then decide: • If it works: say - Save this working state with a clear message. • If it's broken: say - Please fix it, or roll back to the last working save. • Then move on to the next small slice. Phase 8 - Finish the first version When the core feature works, wrap up cleanly: Prompt to send: Compare what we've built to the 'done' definition from earlier. Then write a short README so I can run this again later, and do a final save. Handy prompts to keep nearby • Explain that to me like I have no coding experience. • What are my options here, and which do you recommend and why? • Is this a risky change? If so, save first, then explain what could go wrong. • Show me what changed and how you verified it works. • Save this working state with a clear message. • Roll back to the last working save. How to get engineer-quality results You can get close to what a professional would build, especially for simple, personal apps. The trick is HOW you ask. Follow these habits. • Delegate the decision, but demand the reasoning. Don't say 'you decide' and walk away, and don't dictate technical choices you don't understand yet. Ask Fugu to recommend, explain, and warn you - then you approve. • Avoid the two traps: blind delegation (you can't tell if the result fits your needs) and confident dictating (forcing a choice based on a guess is worse than letting Fugu choose). • Verify, don't assume. Fugu will always sound confident, even when it's wrong. Make it run it, test it, and show you it actually works - every time. • Slow down when the stakes are real. Real users, personal data, money/payments, passwords, or code you'll rely on long-term deserve extra care - ask Fugu to point out risks, and consider a human review for those parts. • Learn as you go. Each time Fugu explains a tradeoff, you get a little better at asking the right question next time. That's how a beginner grows into getting expert results. Copy-paste prompt that captures all of this: Prompt to send: For this decision, recommend the best option for my situation, explain the tradeoffs in plain English, tell me what could go wrong, and wait for my approval. After you build it, run and test it and show me it actually works. Prompt to send: Are there any risks here I should worry about - security, privacy, data loss, or things that get harder later? Explain simply. The three habits that carry a beginner • Small steps - one slice at a time, never 'build it all.' • Always review - ask what changed and whether it was actually tested. • Save constantly - after anything that works, and before anything risky. One-line reminder: Get the idea out of your head, let Fugu sharpen it, approve simple tools, scaffold and save, then build one small reviewed slice at a time - saving after each one that works.

## How to Build a Project using Fugu + Codex A plain-language, step-by-step checklist for building software with an AI coding agent, written for someone with no prior software experience. Work top to bottom. Do one step at a time. Key idea Build in small, saved steps. First create a running skeleton (scaffold), save it, then add one small feature at a time and save after each one that works. Saves are called commits, and you can always roll back to a previous commit if something breaks. Step 0 - Before you start • You do not need to know the tools. You describe what you want; Fugu recommends and runs the technical steps. • Ask Fugu to explain anything in plain English and to show you what changed after each step. • Golden rule: if something works, save it (commit). Before trying something risky, save first. Step 1 - Conceive: fill the intake form • Open the Project Intake Form and fill it in. • Be clear on: what the app is, who it is for, the single most important thing it must do, and what a first working version (done) looks like. • Keep the first version small. You can add more later. Step 2 - Set up the project folder • Create or choose an empty folder for the project. • Copy your filled intake form into that folder so Fugu can read your intentions. Step 3 - Choose the tools (stack) • Ask Fugu: Given my intake form, recommend a simple, boring, well-supported stack and the standard way to scaffold it. • Ask why it chose those tools. Approve the choice before continuing. Step 4 - Scaffold: create the running skeleton • Ask Fugu to scaffold the project using the standard generator for the chosen stack. • This creates the folder layout, config files, the real commands (install, run, test, build), and a working hello-world starting point. • Ask Fugu to run it so you can confirm the baseline actually works. Step 5 - First save point (first commit) • Ask Fugu to set up version tracking (git) if it is not already, and commit this clean, working baseline. • Ask for a clear commit message, for example: initial scaffold, running baseline. • This is your first safe point you can always return to. Step 6 - Write the project AGENTS.md • Now fill the lean AGENTS.md template using the real commands and folder structure from the scaffold. • Include: what it is, current milestone and definition of done, real commands, safety boundaries, and stack plus key decisions. • Do not repeat your global rules (tone, security, workflow) - those live in your global AGENTS.md. • Commit the new AGENTS.md. Step 7 - Build in slices (the main loop) Repeat this loop for each small feature until the first version is done: • Pick one small slice - a single visible thing, for example: let the user add an item. Not the whole app. • Ask Fugu to propose a short plan for that slice, and approve it. • Let Fugu build it. • Review: ask What changed, in plain English? and Did you run and test it, and what was the actual result? • Run it yourself if you can, and confirm it does what you expected. • If it works: commit with a clear message. If it does not: ask Fugu to fix it, or roll back to the last good commit. • Move to the next slice. Step 8 - Finish the first version • Check your work against the definition of done from your intake form. • Make sure setup and usage are written down (a short README) so you can run it again later. • Do a final commit for the completed first version. Commit cheat sheet (your undo button) • Commit = a labeled snapshot of the whole project at a moment in time. • Commit every time something works, and before anything risky. • You can ask Fugu: commit this working state with a clear message. • If a change breaks things, ask Fugu to roll back to the last working commit - nothing before it is lost. Good habits that keep you in control • Keep slices small - easy to review, easy to undo. • Always ask what changed and whether it was actually tested. • Never store passwords or secret keys in the project files; use the placeholders and environment variables Fugu sets up. • Update your AGENTS.md when commands or decisions change; keep it short and accurate. One-line mental model Intake (what I want) -> choose tools -> scaffold (running skeleton) -> first commit -> write AGENTS.md -> loop: plan, build, review, run, commit.

## Reading tips won't make you good — reps with reflection will. Here's the practice loop: 1. Do it a lot, on real tasks. Volume matters. Every task is a rep. 2. Notice the failure, then diagnose the prompt, not just the output. When you get a bad result, ask: "What did I leave ambiguous? What context did I assume it had?" The bug is usually in the prompt, not the model. 3. Keep a "prompt journal." Save prompts that worked well (you're literally already doing this — tasty fugu, your shine prompt). Reuse and refine them into templates. 4. Compare variations. Ask the same thing two ways and see what changes. You learn what levers actually move the output. 5. Steal structure from good prompts. Your shine prompt (Goal / Guardrails / Workflow) is a reusable skeleton. Collect skeletons like that. 6. Make the model teach you. Ask: "How could I have prompted this better?" or "What was ambiguous in what I asked?" — turn it into a feedback partner. 7. Learn the domain a little. The more you understand what you're asking for, the better you can specify it. Prompting well and knowing your subject reinforce each other. ## Common beginner mistakes (and the fix) Too vague → add goal + constraints + done-when Assuming it knows → give context / point it at files One giant prompt → break into steps, iterate Over-explaining "how" → state intent, let it find the route Trusting first output → verify, then refine No examples → show one example of what you want ## The honest truth about the field - It's a real skill, but not a mystical one. It's mostly clear thinking + clear communication + iteration. - It's getting easier, not harder. Newer models need less hand-holding, so heavy "trick" prompting matters less over time. The durable skills — clarity, context, constraints, verification — are exactly the ones you've been building. - The best prompt engineers aren't collecting magic phrases. They're good at decomposing problems and communicating precisely. ## The tasty-fugu takeaway 🐡 Prompt engineering = designing clear input to get the output you want. Get good by: do reps → diagnose the prompt when it fails → save what works → reuse structures → verify → ask the model how to prompt better. And the reassuring part: your AGENTS.md, your shine prompt, your "verify, don't assume" reflex — that is applied prompt engineering. You're not starting from zero; you're already practicing the real thing. Now it's just reps.