Prompts

Give me a quick, read-only overview of my Yard account: who I'm signed in as, which team the CLI acts for, what that team's plan allows, and which projects it has.

1. Run yard me --json and yard team --json. Tell me my username, the active team (name, @username and my role) and any other teams I could switch to with yard team use. If I have no team, tell me to create one at https://yard.sh/team and stop.
2. Go through .team_permissions in yard me --json and tell me in plain language which team features are granted and which aren't (for example selling, pricing tiers, license keys, free trials, coupons, custom landing pages, hosted services, Yard Auth, realtime rooms and sandboxes). For limits, include the number.
3. Run yard projects --json and list each project with its title, slug and public URL (https://<team username>.yard.sh/<slug>/).
4. Suggest two or three next steps that fit what my plan allows.

Don't create, change or publish anything.

Connect this GitHub repository to my Yard project so every GitHub release I publish becomes a Yard release automatically.

1. Make sure this is a clone of a GitHub repo (git remote -v shows a github.com origin) and that the directory is linked to a Yard project. If it isn't, ask me which project and link it with yard init --project <slug> --json.
2. Run yard github link --channel Production --json. If it fails because the Yard GitHub App isn't installed or can't see this repo, give me the install link it printed, wait for me to finish on GitHub, then run it again. If the repo is linked to another project, ask me before you rerun it with --move.
3. Confirm with yard github list --json and show me the repo, project and sync channel.
4. Explain what happens next: publishing a GitHub release copies its tag, notes and assets to Yard and ships to users. Editing it re-syncs, and deleting it archives the Yard release. If .yard/settings.json is committed at the tag, its pricing, download buttons, landing page and services sync too.

Don't create a GitHub release yourself. I'll do that when I'm ready.

Create a Yard project for the software in this repository so I can start selling it.

1. Read the README and skim the code to understand what this is and who it's for. Run yard me --json to see what my team's plan allows, and yard projects --json to check a project for it doesn't already exist. If one does, link it with yard init --project <slug> --json and skip to step 4.
2. Propose a title, a pricing model (one-time or subscription), one or two tiers with prices and a few features each, and whether to turn on license keys. Only suggest features my plan includes. Wait for my OK or changes.
3. Create the project with yard init --spec - --json using the agreed spec.
4. Show me the project slug, its buy URL and the .yard/settings.json that was written. Explain that the project starts in draft, so only my team can see it until I move its launch stage forward in the Yard dashboard.

Don't publish a release or change the launch stage.

Give me a sales report for my Yard team covering this calendar month so far.

1. Run yard transactions list --start <first day of this month> --limit 100 --json, paging with --page until you have every row. Add up team_earnings_cents and total_cents per project_name (use the cents fields, not the formatted text), and count sales by type: purchase, subscription, trial upgrade and gift. Leave refunded sales out of the totals and list them separately.
2. Run yard users list --sort totalSpent --direction desc --limit 10 --json for my top-spending users of all time.
3. Run yard transactions list --trials --json and list the trials that are still running, with their expiry dates. Flag any that end in the next 7 days.
4. Run yard coupons list --sort currentUses --direction desc --json and show the codes that were used most, with their uses.

Present it as one short report with a few headline numbers at the top and small tables after. Don't change anything. This is read-only.

Post a message to my Discord channel every time someone buys my Yard project, using a Yard webhook and a small service hosted on Yard.

1. Check yard me --json for .team_permissions.service and webhooks. If either is missing, stop and give me https://yard.sh/pricing. In the Yard project linked to this directory, create notify/_service.js and add {"dir": "notify", "name": "notify", "url": "/notify", "access": "public"} to services in .yard/settings.json.
2. Handle POST /sale. Read the raw body as text and verify the X-Yard-Signature header, which looks like t=<unix seconds>,v1=<hex>. Split it on commas into key=value pairs, require a digits-only t and a v1, and reject a t more than 300 seconds from now. v1 is the hex HMAC-SHA256 of t exactly as received, then ".", then the raw body, keyed with the env.YARD_WEBHOOK_SECRET string as-is (don't hex-decode it). Use Web Crypto and a constant-time compare, and answer 401 if any check fails. On a "sale.completed" event, post project_slug, tier_name, quantity and amount_cents (formatted as money) to env.DISCORD_WEBHOOK_URL. Skip any event that carries a sandbox field: it is a test sale from one of my sandboxes, so post nothing. Answer 200 quickly for every verified event, including webhook.ping.
3. Put test values for both secrets in .yard/dev/secrets.env, run yard dev in the background, and send a sample sale.completed body signed the way Yard signs it: T=$(date +%s); SIG=$(printf '%s.%s' "$T" "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | sed 's/^.* //'); curl -H "Content-Type: application/json" -H "X-Yard-Signature: t=$T,v1=$SIG" --data-binary "$BODY" <local URL>/notify/sale. Send the same sample with "sandbox": "beta" added and confirm it gets 200 without posting to Discord. Confirm a bad signature and a t from 10 minutes ago both get 401. Then run yard service check and yard push.
4. Give me the hosted URL https://<team username>.yard.sh/<slug>/notify/sale and have me create the webhook in the Yard dashboard (Configure, then Webhooks), copy its signing secret (Yard creates it with the URL) and paste it to you along with my Discord webhook URL. Set both with yard service secrets set.

Ask me before you run yard releases publish. Note that Yard can only reach the service once the project is out of draft.

My latest Yard release is broken. Put the previous good version back in front of users right now.

1. Work in the Yard project linked to this directory. Run yard sandbox list --json and tell me which release the project itself is serving and why (channel, pinned or rolled back).
2. Ask me which earlier version to go back to. If this repo tags its releases, suggest the tag before the broken one.
3. After I confirm, run yard sandbox rollback <tag> --json. If it's refused because the project is pinned, ask me before moving the pin with yard sandbox pin <tag> instead.
4. Run yard sandbox list --json again and confirm the project now serves the older release.

Then explain my options. The rollback lasts until I publish the next release, which takes over automatically once the fix is out. yard sandbox pin makes it permanent, and yard releases archive <bad tag> removes the broken release from its channel for good. Don't do either unless I ask.

Add live chat to my Yard project: people signed in through Yard join a room by name and talk in real time.

1. Check yard me --json for .team_permissions.service_rooms and yard_auth. If either is missing, stop and give me https://yard.sh/pricing. In the Yard project linked to this directory, run yard service init chat --realtime.
2. Keep the scaffold's shape: the fetch handler only routes /ws?room=<name> to that room, and the Room class owns the connections. Read X-Yard-Email (or X-Yard-User-Id if it's empty) from the upgrade request, keep it in the connection's attachment, and show it next to every message.
3. Store messages in the room's own SQL storage (create the table if it doesn't exist) and send the last 50 to each person who joins. Show who's online, let the user pick a room name in the page, and reconnect after every close.
4. Run yard dev in the background and run yard service check. Give me the local URL and tell me to open it in a normal window and a private window, picking a different persona in each from the sign-in picker, so I can watch messages arrive in both. Then run yard push.

Don't publish. Tell me when it's ready.

Build my app and publish it as a new Yard release with a download button for each platform.

1. Work in the Yard project linked to this directory. If there isn't one, ask me which project and link it with yard init --project <slug> --json. Build the app with the repo's own build scripts and collect the artifacts for each platform.
2. Write release notes from git log since the last tag, grouped into New, Improved and Fixed, in plain language a user would understand. Suggest the next version tag.
3. In .yard/settings.json, make downloads.buttons hold one button per artifact, for example {"condition": "ends_with", "value": ".dmg", "label": "Download for Mac"}. Conditions are contains, starts_with, ends_with or has_extension, with up to 10 buttons. Then run yard push.
4. Show me the tag, the notes and the file list, and wait for my OK. Then run yard releases publish <tag> --notes-file - --file <artifact> (repeat --file for each artifact) --json, piping the notes on stdin.

Publishing goes live to users in the Production channel. If any file fails to upload, show me which one and stop, without retrying under the same tag.

Stage my latest changes in a private preview copy of my Yard project so I can check them before users get them.

1. Work in the Yard project linked to this directory. Run yard push to stage local changes in the draft release, then yard sandbox list --json. If there's no sandbox named preview, create one with yard sandbox create preview. If that fails with sandbox_limit_reached, stop and tell me.
2. Run yard sandbox pin (no release) so the live project keeps serving what it serves now. Then suggest a version tag, and once I agree, run yard releases publish <tag>.
3. Run yard sandbox pin <tag> --sandbox preview, then yard service open --sandbox preview if the project has services. Give me the preview URL (https://<team>.yard.sh/<slug>/@preview/). Only my team can open it, and purchases in it are simulated, with no money moving.
4. Ask whether I want to share it with someone outside my team. If I do, run yard sandbox visibility public --sandbox preview.

When I say it looks good, run yard sandbox unpin to ship it to users. If I say it's broken, leave the pin in place and help me fix it.

Add a Team tier to my Yard project that charges per seat and gets cheaper as teams buy more seats.

1. Work in the Yard project linked to this directory. If there isn't one, ask me which project and link it with yard init --project <slug> --json. Check yard me --json for .team_permissions.seat_based_pricing and room under max_pricing_tiers. If either is missing, stop and give me https://yard.sh/pricing.
2. Run yard pull so .yard/settings.json holds the release's current pricing block, and keep every existing tier and its name unchanged. Ask me for the per-seat price and the minimum number of seats.
3. Add a tier named Team with "seat_type": "per_seat", "min_seats" and "volume_brackets" for 10% off from 10 seats and 20% off from 50 seats. Brackets must be contiguous with no gaps, discounts run from 1 to 99, and only the last bracket can leave max_quantity out. Match the pricing_model of my other tiers unless I say otherwise.
4. Run yard push, then show me what a team of 5, 25 and 100 seats would pay before tax, and give me the review URL.

Ask me for a version tag before you run yard releases publish, because publishing makes the tier live.

Put my Yard-hosted web app behind a paywall so only buyers, subscribers and people on a trial can use it, and unlock extra features per tier.

1. Check yard me --json for .team_permissions.yard_auth. If it isn't granted, stop and give me https://yard.sh/pricing. Read .yard/settings.json and yard projects show <slug> --json so you know my services and tier names.
2. Set "access": "users" on the app's service entry in .yard/settings.json. Yard then sends anyone who hasn't bought to the sales page, with no code needed. Show the tier name from the X-Yard-Tier header in the app's header, and add a sign-out link to the relative URL __yard/auth/logout.
3. Ask me which features belong to which tier. Gate them on X-Yard-Tier on the server side, and treat X-Yard-Entitlement "owner" (my own team) as having everything.
4. Run yard dev --json in the background and check each persona with curl and the yard_dev_identity cookie: anonymous and signed-in should be turned away, user:<tier> should get its tier's features, and member should get everything. Then run yard service check and yard push.

Don't publish. Tell me what each persona saw and give me the review URL.

Get this repository ready to be a Yard template, so anyone can create their own copy of my project with one click.

1. Check .yard/settings.json: it must be version 8 (run yard migrate if it's older) and at most 16 KiB. Every service listed in services needs its directory and a _service.js, a custom landing page needs its files, and migrations need .sql files. Add a pricing block if there isn't one, after asking me what the template's default pricing should be (a free tier is a good default).
2. Make sure nothing secret is committed: no keys in the code, and .yard/dev/ is ignored. Anything the app needs from secrets should be listed in the README, with the yard service secrets set command to run.
3. Write a short README: what it is, the Create in Yard button, the URLs the project serves, the folder layout, and the local loop (yard dev, then yard push and yard releases publish). The button is <a href="https://dash.yard.sh/projects?action=create&repo=<URL-encoded https://github.com/owner/repo>"><img src="https://yard.sh/create-in-yard.png" width="200" alt="Create in Yard" /></a>, built from this repo's GitHub origin.
4. Tell me the repo must be public on GitHub. Have me test it by pasting the repo URL into "Create from GitHub URL" in the Yard dashboard's Create Project dialog before I share the button.

Don't commit or push anything to git. Show me the changes and let me do that.

Add a live "N people here now" counter to my Yard project's landing page.

1. Check yard me --json for .team_permissions.service_rooms and custom_project_pages. If either is missing, stop and give me https://yard.sh/pricing. In the Yard project linked to this directory, run yard service init live --realtime, then set "access": "public" on its entry in .yard/settings.json so visitors don't have to sign in.
2. Trim the scaffold's Room down to presence: ignore incoming messages, and on every join, close or error, broadcast {"count": n} to everyone, where n comes from ctx.getWebSockets(). Remove the scaffold's chat page from the live directory.
3. On the landing page (scaffold one with yard init --page if there isn't one), connect to new URL("live/ws?room=landing", location.href) with http swapped for ws, show the count, and reconnect a second after every close. Keep the counter hidden until the first count arrives.
4. Run yard dev in the background and give me the landing page URL to open in two windows, so I can watch the count go to 2. Then run yard service check and yard push.

Don't publish. Tell me when it's ready.

Make my app ask for a Yard license key and only unlock once Yard says the key is valid for this device.

1. Check yard me --json for .team_permissions.license_keys, device_activations and api_keys. If any are missing, stop and give me https://yard.sh/pricing. Turn keys on for the project in this directory with yard projects edit <slug> --spec - --json, using {"license_key_enabled": true, "activations_enabled": true, "max_activations": 3} (ask me if I want a different device limit).
2. Create an API key with yard keys create --spec - --json using {"name": "app-license-check", "scopes": ["licenses:validate", "licenses:activate"]}. Both scopes are needed, because sending a device_id activates the device. These integration scopes are safe to ship inside the app. Inject the key at build time from an environment variable rather than committing it, and tell me where to store it.
3. Add a license screen: the user pastes a key, the app sends POST https://api.yard.sh/v1/licenses/validate with Authorization: Bearer <api key> and a JSON body of license_key, device_id and device_name. Generate device_id once with a random UUID and store it in the app's config directory. Save the key only when the response says valid, and show the response's error text when it doesn't.
4. In release builds, reject any response whose sandbox field is set, because those keys come from simulated test purchases. Re-check the stored key on launch without blocking startup.

Ask me where the license screen should live in the UI before you build it. When you're done, tell me how to test it: create a sandbox, buy the project inside it (simulated, no card), and paste that key into a development build.

Set up discount codes for my launch: one public code anyone can use, plus a batch of single-use codes I can hand out to creators.

1. Check yard me --json for .team_permissions.coupons. If it isn't granted, stop and give me https://yard.sh/pricing. Find my project's slug in .yard/settings.json, or ask me which project from yard projects --json.
2. Create the public code with yard coupons create LAUNCH25 --percent 25 --max-uses 100 --expires <the date 30 days from today> --projects <slug> --json.
3. Generate the creator codes with yard coupons generate --count 20 --prefix CREATOR --percent 15 --max-uses 1 --projects <slug> --json. The codes are only shown once, so write them to creator-codes.txt (one per line) straight away, and don't commit that file.
4. Run yard coupons list --json and show me a short table of the new codes, with their discount, uses left and expiry.

If LAUNCH25 already exists, don't touch it. Tell me and suggest another name.

Add a "Check for updates" action to my app that finds the newest release on Yard and downloads it with the user's license key.

1. Find where the app stores the user's Yard license key and where its current version number lives. If the app doesn't store a license key yet, stop and tell me, because the update server authenticates with that key.
2. Call GET https://api.yard.sh/v1/updates/latest?license_key=<key>. No API key is needed. The response matches GitHub's Releases API: compare its tag_name with the running version (ignore a leading "v").
3. If it's newer, show the release name and notes (body), pick the asset that matches this OS and CPU, and download it from its browser_download_url. That URL redirects to a short-lived link, so follow redirects and start the download right away.
4. Turn errors into friendly messages: 404 "No releases found" means nothing is published yet, 403 means the purchase was refunded or the trial has expired (offer a link to buy again), and network failures should never block the app.

Don't auto-install anything. Download it and tell the user where it is, unless the app already has an installer flow I point you to.

Check my Yard-hosted services for errors from the last day, fix what's causing them, and stage the fixes.

1. In the Yard project linked to this directory, run yard service logs --since 24h --limit 500 --json, once per service with --service <name> if there are several. Group the exceptions and failed requests by cause and show me a short summary with counts.
2. For each cause, find the responsible code and reproduce it with yard dev --json running in the background. If it depends on who's signed in, pick a persona with the yard_dev_identity cookie. The local errors show up at /__yard/dev/api/logs.
3. Fix each one with the smallest change that addresses the cause, and confirm the same request now succeeds locally. If it's a data problem, inspect it read-only with yard db query, and never write to the hosted database without asking me.
4. Run yard service check and yard push, and give me the review URL.

If nothing in the logs is an error, say so and stop. Ask me before you publish the fix.

A customer asked for more time on their free trial. Find their trial and extend it.

1. Ask me for the customer's email and how many extra days to give.
2. Run yard transactions list --trials --search <email> --json and find their trial. If the search finds nothing, list every trial and match user_email yourself. If there are several, show me each one's project, tier and expiry and ask which. If there's none, tell me and stop.
3. Show me the order id, the current expiry and what the new expiry will be. The days are added to the current expiry, not to today. Wait for my OK, because Yard emails the customer about the change.
4. Run yard transactions trial <order-id> --add-days <days> --json and confirm the new expiry. If it says the trial was reactivated, mention that the customer has access again.

Never extend a trial without my confirmation.

Turn on gift purchases for my Yard project so people can buy it for someone else.

1. Work in the Yard project linked to this directory. If there isn't one, ask me which project and link it with yard init --project <slug> --json.
2. Run yard pull so .yard/settings.json holds the release's current pricing block. Set "gift_enabled": true on every paid one-time tier, and leave subscription tiers alone because they can't be gifted. Don't change anything else.
3. Run yard push and show me which tiers now allow gifting, plus the review URL.
4. Read my team username from yard team --json and give me the gift checkout link https://pay.yard.sh/<team username>/<slug>?gift=true. Explain how a gift works: the recipient gets an email to activate it, and an unclaimed gift is refunded after 90 days.

Ask me for a version tag before you run yard releases publish, because the gift button only appears once the release is live.

Replace my Yard project's default page with a custom landing page that sells the product, using the README for copy.

1. Check yard me --json for .team_permissions.custom_project_pages. If it isn't granted, stop and give me https://yard.sh/pricing. In the Yard project linked to this directory, run yard init --page --json to scaffold .yard/landing-page/.
2. Write index.html and styles.css with a hero, three to five feature sections and an FAQ, using copy from the README. Use relative URLs only (href="styles.css", never "/styles.css"). Bind the title and tagline with data-yard="title" and data-yard="tagline", and show prices from window.yard.project.tiers.
3. Add a Buy button with data-action="checkout" and data-yard-when="not_owned", and an "Open in your library" link to https://yard.sh/library with data-yard-when="owned". Show a data-action="trial" button only when some tier has free_trial.enabled, and set its data-tier-id to that tier's id.
4. Run yard dev in the background and give me http://localhost:9875/<slug>/ to look at. Fix anything I point out, then run yard push.

Keep it to plain HTML, CSS and a little JavaScript, with no build step. Don't publish the release. Tell me when it's ready and I'll decide.

Add an endpoint to my Yard-hosted service that calls a third-party API (for example OpenAI, Resend or a weather API), keeping the API key in Yard secrets instead of the code.

1. Ask me which API, what the endpoint should do, and which service in .yard/settings.json it belongs to. Pick an UPPER_SNAKE secret name such as OPENAI_API_KEY (DB and ASSETS are reserved).
2. In that service's _service.js, read the key as env.<NAME> and call the API with plain fetch. If the secret is missing, answer a clear 500. Never log the key or send it back in a response.
3. For local testing, the key goes in .yard/dev/secrets.env as NAME=value (that folder is never pushed or committed). Ask me to paste the key, or let me add the line myself. Run yard dev in the background and exercise the endpoint with curl.
4. Ask me before setting the hosted value with yard service secrets set NAME=..., or let me run it myself. Confirm with yard service secrets list, then run yard service check and yard push.

Secrets apply on the next deploy, so remind me the endpoint only works hosted once the next release is published. Before you finish, double-check that no key is in git.

Build a small web app and host it on Yard, with a database and sign-in handled by Yard.

1. Ask me what the app should do, in a sentence or two, and propose the screens and data it needs. Check yard me --json for .team_permissions.service and yard_auth. If either is missing, stop and give me https://yard.sh/pricing.
2. In the Yard project linked to this directory, run yard service init app. Replace the notes example with my app, keeping the same shape: one _service.js that exports a fetch handler (no ports, no listen(), no Express), static files next to it, relative URLs everywhere, and tables in numbered .sql files in .yard/migrations. Store times as integer milliseconds.
3. Leave "access": "authenticated" on the service and use the X-Yard-User-Id header to scope each user's data. Never build login, sessions or password storage.
4. Run yard dev --json in the background and test the API with curl as two different personas (Cookie: yard_dev_identity=signed-in, then yard_dev_identity=member) to prove one user can't see another's data. Then run yard service check and yard push.

Don't publish. Show me the local URL and the review URL, and offer to put the release in a preview sandbox so I can try it hosted.

Add a monthly subscription tier called Pro to my Yard project, alongside the pricing I already have.

1. Work in the Yard project linked to this directory. If there isn't one, ask me which project and link it with yard init --project <slug> --json. Check yard me --json: if .team_permissions.max_pricing_tiers leaves no room for another tier, stop and give me https://yard.sh/pricing.
2. Run yard pull so .yard/settings.json holds the release's current pricing block. Pricing is saved per release, so change it there, not with yard projects tiers. Keep every existing tier and its name exactly as they are, so past purchases stay attached.
3. Ask me for the monthly price and the yearly discount I want, and propose three to five short features for Pro based on what the app does. Once I agree, add the tier to pricing.tiers with "pricing_model": "subscription", "price_cents", "yearly_discount_percent", "features" and "is_default": false.
4. Run yard push. It validates the pricing and stages it in a draft release. Show me the new tier and the review URL.

Ask me for a version tag before you run yard releases publish, because publishing makes the new price live.

Let people try my Yard project free for 14 days before they pay.

1. Work in the Yard project linked to this directory. If there isn't one, ask me which project and link it with yard init --project <slug> --json. Check yard me --json for .team_permissions.free_trials. If it isn't granted, stop and give me https://yard.sh/pricing.
2. Run yard pull so .yard/settings.json holds the release's current pricing block. Trials are set per tier in that block, not with yard projects tiers. Ask me which tier gets the trial (suggest the default one).
3. On that tier, set "free_trial": {"enabled": true, "days": 14}. If it's a subscription tier, ask me whether the trial should collect a card up front and set "requires_card" to match. Leave every other tier and field unchanged.
4. Run yard push and show me the updated tier and the review URL.

Ask me for a version tag before you run yard releases publish, because publishing makes the trial live on my buy page.