# devboxes bundles and tasks in full > A bundle is a group of devboxes tasks for one goal. A setup adds bundles, single tasks, or both, by slug. This page describes every task in full: what it does, which kinds of company it suits, what someone asks it and its steps. ## Answer customers faster Bundle slug: `support-desk`. Drafts replies to customer emails and reviews, writes help pages, tells you what customers keep asking for, and prepares renewal calls. ### Draft replies to customer emails > Drafts a reply to every customer email you paste. Reads the customer emails in the request, works out what the customers need, and drafts one reply per email in your tone. It marks the questions that need your answer. Paste the emails when you ask. Use the slug `customer-email-replies` in a setup's `blueprints`. It suits startups, agencies, online shops, local businesses and consultancies and firms. #### What someone asks Draft replies to the three emails below. #### Steps 1. Sort the emails: Every email in the request appears once in the list, with its sender and request. Every urgent email names the reason it is urgent. 2. Find the answers: Every customer question has an answer with its source, or is marked for the team. Every answer rests on the request or the company's own pages. 3. Draft the replies: Every email has exactly one draft reply, in the customer's language. Every question marked for the team has a bracketed placeholder in its draft. 4. Check the drafts: Every draft answers or marks every question in its email. The reply lists the urgent drafts first, then the others, then the questions for the team. ### Answer a customer question from your website > Finds the answer on your website and help pages and drafts a reply that links them. Searches your help pages and website for the answer to a customer's question and drafts a reply that links the pages it used. When your pages leave it open, it says so and names the fact or page to add. Use the slug `customer-question-answers` in a setup's `blueprints`. It suits startups, online shops and local businesses. #### What someone asks A customer asks whether we support single sign-on. Our site is example.com. #### Steps 1. Pin down the question: The question is restated in one sentence. The company's website or help pages are known. 2. Search your pages: Every page used is on the company's own domain. Every answering page has its address and the exact sentences that answer the question. 3. Draft the answer: The draft's first sentence answers the question, or says your pages leave it open. Every statement in the draft comes from a linked page. 4. Check the links: Every link in the draft loads and supports the sentence that cites it. The reply has the draft answer and names the gaps and contradictions in your pages. ### Reply to customer reviews > Drafts a personal reply to every review you paste, the angry ones first. Reads the reviews you paste from Google, Trustpilot, an app store or your shop, and drafts short, personal replies to them. Unhappy reviews come first, with a reply that owns the problem and offers a way to fix it. Paste the reviews when you ask. Use the slug `review-replies` in a setup's `blueprints`. It suits online shops and local businesses. #### What someone asks Reply to these five Google reviews for our bakery. #### Steps 1. Sort the reviews: Every review is listed once, with its rating and what the customer liked or what went wrong. Unhappy reviews come before the others. 2. Draft the replies: Every review has one draft reply of 40 to 90 words. Every reply names something specific from its review. 3. Check the replies: Every reply leaves out order numbers, addresses and other personal data. Every reply starts differently. Every flagged review has a note for the person. ### Write a help page > Turns a question customers keep asking into a help page. Writes a help page from the question and the answer in the request: a clear title, the answer in the first lines, then the steps. It checks your website so the page matches what it already says, and lists anything it couldn't confirm. Use the slug `help-page` in a setup's `blueprints`. It suits startups and online shops. #### What someone asks Write a help page on how to export invoices. Our site is example.com. #### Steps 1. Read the question and your site: The related pages on the company's site are listed with their addresses. Every difference between the site and the request is noted. 2. Settle differences with you: Every difference between the site and the request has a decided version. 3. Write the help page: The answer is in the first two sentences. Every step is one action and uses the product's exact names. 4. Check every step: Every step is confirmed by the site or the request, or listed as unconfirmed. help-page.md is published, and the reply has the page and the unconfirmed statements. ### Find what customers keep asking for > Groups the customer messages you share into the requests that come up most. Reads the customer emails, chats or notes in the request, groups them into requests, and ranks them by how many customers asked and how strongly, quoting the customers' own words. Use the slug `feature-requests` in a setup's `blueprints`. It suits startups. #### What someone asks Here are last month's support emails. What do customers keep asking for? #### Steps 1. Pull out the requests: Every request has a verbatim quote and the customer who asked, when known. Bug reports and support questions are in their own list. 2. Group the requests: Every request belongs to exactly one group. Every group has a count of distinct customers. 3. Rank the requests: The groups are ordered by distinct customers, then strength. Every group in the table has two verbatim quotes. feature-requests.md is published. ### Prepare for a customer's renewal call > Lists a customer's reports from this year, marked fixed or open, before you talk to them. Finds every issue a customer reported in the last year, marks them fixed or open, and writes a one-page brief with what to say about the open ones. Use the slug `customer-renewal-prep` in a setup's `blueprints`. It suits startups and agencies. It works with Linear, Jira and GitHub Issues. #### What someone asks We have the renewal call with Northwind next week. What did they report this year? #### Steps 1. Find the customer's reports: Every issue found mentions the customer and falls in the period. 2. Mark them fixed or open: Every issue is marked fixed with a date, or open with its priority and age. 3. Write the renewal brief: The brief lists every report as fixed or open, with talking points. ## Fix what customers report Bundle slug: `customer-reports`. Turns customer reports into issues with the cause found, reproduces bugs, fixes them with a test and tells you when the fix ships. ### Turn a customer report into an issue > Files a customer's report for the team that owns it, with the cause found and a fix to try. Reads the customer's report, finds where the product goes wrong in your code, and files an issue for the team that owns that part, with the steps, the cause and a recommended fix. When the problem is already filed, it adds the report to that issue instead. Use the slug `support-report-to-issue` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A customer says their invoice PDF shows last month's address. Can you file it? #### Steps 1. Read the report: The report is restated as what they did, what they expected and what happened, with a quote. 2. Check for a known issue: The search terms used are listed, and a match is either commented on or ruled out. 3. Find the cause: The cause names the files and lines involved, and says whether it was reproduced. 4. Find the team that owns it: The owning team is named with the evidence for it. 5. File the issue: The reply links exactly one issue: the new one, or the known one the report was added to. A new issue has the steps, the cause and a recommended fix. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Check whether a customer's problem is a known bug > Tells you whether the team already knows about a customer's problem, and adds the new report to the matching issue. Searches your issue tracker for the problem a customer describes. When an issue matches, it adds the new report to it and tells you its status; otherwise it shows the closest issues and why they differ. Use the slug `check-for-a-known-bug` in a setup's `blueprints`. It suits startups. It works with Linear, Jira and GitHub Issues. #### What someone asks A customer says the CSV export times out once they have more than 10,000 invoices. Do we know about this? #### Steps 1. Describe the problem: The problem is restated with its symptoms, conditions and search terms. 2. Search your issue tracker: Every search term was searched, and the promising issues were read in full. 3. Decide whether it matches: The result is one matching issue, or the closest issues with how they differ. 4. Add the report to the issue: A matching issue has the new report as a comment, and the reply gives its status. ### Reproduce a bug report > Reproduces a new bug report on the reported version and the latest code, and comments with a script that shows the bug. Reads a new bug report, runs the reported version and the latest code of your repository side by side, and writes the smallest script that shows the bug. It comments on the issue with what it found and the script, adds a recording when the bug shows on screen, and labels the issue reproduced or not reproduced. Use the slug `reproduce-a-bug-report` in a setup's `blueprints`. It suits startups. It works with GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Reproduce acme/app#123. #### Steps 1. Read the bug report: The reported version, the environment, the steps, and the expected and actual behavior are noted as the report gives them. 2. Find related issues: Every kept issue has one line on how it relates to the report. 3. Check out both versions: Both versions are installed, or the note says why only the default branch is. 4. Reproduce it: The script ran on every tested version, and the output of every run is kept. 5. Record the bug: Every recording is published with a share link, and every recording that wasn't made has its reason noted. 6. Comment on the issue: The issue has one comment with the result, the tested versions and the script. The issue carries the label reproduced or not reproduced, and keeps its other labels. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Fix a production error > Reproduces an error from its stack trace, fixes it and adds a test. Reads the error and stack trace in the request, writes a failing test that reproduces it, fixes the code and opens a pull request once the tests pass. Use the slug `fix-production-error` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Fix this TypeError in checkout: . #### Steps 1. Read the error: The failing code and the input that triggers it are identified. 2. Reproduce it in a test: A test fails with the same error as the stack trace. 3. Fix the cause: The new test passes. The fix changes the code that causes the error. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Check whether a fix has shipped > Tells you whether a customer's fix has shipped, and the first release it went out in. Finds the fix in your code history from the issue or a description of the problem, and names the first release that includes it, with its date. When it hasn't shipped, it says where the fix stands. Use the slug `check-whether-a-fix-shipped` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Has the fix for the double payment reminders shipped yet? #### Steps 1. Find the fix: The fix is identified by its merge commit, or the reply says where the fix stands. 2. Find the first release with it: The reply names the first release with the fix and its date, or says the fix is waiting for a release. 3. Answer yes or no: The reply starts with yes or no and names the release or where the fix stands. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Draft replies to customer emails `customer-email-replies`, described above under Answer customers faster. ## Get answers about your product Bundle slug: `product-answers`. Answers how your product behaves, who can do what and why something happened, from your code and your docs. ### Answer a customer question from your website `customer-question-answers`, described above under Answer customers faster. ### Check how a feature behaves before you promise it > Answers what your product does in an unusual case, for that exact case. Finds the part of your product that decides the case you ask about, follows it with your exact values, and answers in plain words with where the product decides it. Use the slug `check-how-a-feature-behaves` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A customer wants to pause their subscription halfway through the month. What happens to that month's invoice? #### Steps 1. Pin down the case: The case is restated with concrete values. 2. Find the code that decides it: The deciding code is identified with file and line references. 3. Follow the case through the code: The outcome for the case is traced step by step, and says whether a run confirmed it. 4. Answer for that exact case: The reply answers the exact case first and names where the product decides it. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find out whether your product already does something > Tells you whether your product already does what a customer asks for, before you answer them. Checks your product's code, settings and docs for what the customer wants, and answers yes, partly or no, with the setting that turns it on and any planned issue for the rest. Use the slug `check-whether-a-feature-exists` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A public sector customer needs their invoices as XRechnung. Can we do that today? #### Steps 1. Pin down what's asked: The request is restated in concrete, checkable terms. 2. Search the code and settings: What exists is described with file references and the setting that turns it on. 3. Check what's planned: Related issues are listed with their status, or the report names the search terms used. 4. Answer yes, partly or no: The reply starts with yes, partly or no and names the setting or the planned issue. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Explain an error message a customer sees > Explains what an error a customer got means and what they can do about it. Finds where your product shows the error and why, and explains it in plain words: what it means, the likely cause in this customer's case, what the customer can do, and what your team can do. Use the slug `explain-an-error-message` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A customer gets "Mandate already active" when they add their bank account. What does that mean? #### Steps 1. Find where the error comes from: Every place that can produce the error is listed with file and line. 2. Work out why it appears: The conditions behind the error are listed, with the likely one for this customer. 3. Explain it in plain words: The reply says what the error means, what the customer can do and what the team can do. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find where something is decided in your code > Names the files and functions that decide a rule in your code. Searches your code for a rule, follows it to the code that decides it, and names the files and functions, with one sentence on what every one does. Use the slug `find-where-a-rule-lives` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Where do we decide which customers can pay by SEPA direct debit? #### Steps 1. Search the code for the rule: The candidate places are listed. 2. Confirm which code decides it: The deciding code is told apart from code that only shows the result. 3. Name the places: The reply names every deciding place with one sentence on what it does. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Check who can do something in your product > Tells you which roles in your product can take an action, from the product's permission checks. Finds the permission check for an action in your product's code and lists the roles it allows, and says where the screen and the server disagree. Use the slug `check-who-can-do-something` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Which roles in our admin panel can issue a credit note? #### Steps 1. Find the action: The action's screen, route and handler are identified. 2. Find the permission check: Every check on the server and in the interface is listed with file references. 3. List the roles: The reply lists the allowed roles from the server's check. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find out what a scheduled job does > Explains in plain words what a scheduled job does and what happens when it fails. Reads a scheduled job's code and schedule, and explains what it does, what it changes, and what happens when it fails or runs twice. Use the slug `explain-a-scheduled-job` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks What does the nightly ledger job at 02:00 actually do, and what if it fails? #### Steps 1. Find the job and its schedule: The job's schedule and code are identified with file references. 2. Read what it does: Every step of the job is listed with what it reads and changes. 3. Work out what happens when it fails: Failure, retries, alerts and reruns are described. 4. Explain it in plain words: The reply explains the job and its failure in plain words. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find out why a customer might not have got an invoice > Explains, from your product's code, why an invoice might not have reached a customer and what to check. Maps every way your product's code can stop or delay an invoice, checks the facts you give against them, and tells you the likely reasons and where to look to confirm. Use the slug `find-out-why-an-invoice-never-arrived` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A customer says they never got their March invoice. It was created on 1 March. Why might that be? #### Steps 1. Collect the facts you have: The facts from the request are listed. 2. Map how an invoice gets sent: Every condition that stops or delays an invoice is listed with file references. 3. Check the facts against them: Every condition is marked fits, ruled out or unknown. 4. Explain the likely reasons: Every reason names the fact or code it rests on and where to confirm it. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## Win more customers Bundle slug: `win-customers`. Researches companies before your calls, finds new prospects, drafts follow-ups and proposals, and coaches you on your sales calls. ### Research a company before a call > Gives you a one-page brief on a company, with questions to ask, before you talk to them. Researches the company on the web: what it sells, to whom, how big it is, its recent news and the people you will meet. It writes a one-page brief with questions to ask on the call. Use the slug `company-brief` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Brief me on Acme Robotics before tomorrow's call with their CTO. #### Steps 1. Confirm the company: The company is identified by its website domain. 2. Research the company: Every fact has a source address and a date. The research covers product, customers, size, funding and recent news. 3. Research the people: Every named person has their role and a source, or the brief names the sources searched for them. 4. Check the facts: Every remaining fact is confirmed by its source. 5. Write the brief: The brief has every section and at most 500 words. Every question refers to a finding in the brief. company-brief.md is published. ### Find prospects and draft outreach > Finds companies that fit your ideal customer and drafts personal first emails to them. Searches the web for companies that match the customer you describe, checks them against your description, and drafts short first emails that mention something specific about the company they're written for. Use the slug `prospect-outreach` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Find ten logistics companies in Germany with 50 to 200 employees and draft the first emails to them. #### Steps 1. Set the criteria: Every criterion can be checked against a public source. What the person sells and the number of companies are known. 2. Find candidates: The candidate list has about twice the requested number of companies, with their websites. 3. Check every company: The kept companies meet every criterion, and a source backs every check. The list holds the requested number of companies, or says how many fit. 4. Find a reason to write: Every kept company has one dated, linked fact and a contact role. 5. Draft the emails: Every company has an email of at most 120 words that opens with its specific fact. prospects.md is published with the table and the emails. ### Follow up after a sales call > Turns your call notes into a follow-up email with the agreed next steps. Reads your notes or the transcript from the call, pulls out what the customer needs, their objections and the next steps, and drafts the follow-up email. Use the slug `call-follow-up` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Here are my notes from the call with Acme. Draft the follow-up. #### Steps 1. Read the call notes: The customer's needs, objections, budget, timing and decision makers are noted where the notes mention them. Every next step in the notes is listed. 2. Confirm next steps with you: Every next step has an owner and a date. 3. Draft the follow-up: The email has at most 200 words and lists every next step with its owner and date. Every commitment in the email appears in the notes. ### Follow up with a prospect who went quiet > Drafts a follow-up that gives a quiet prospect a reason to answer. Reads where the conversation stopped and drafts a short follow-up that adds something new, such as a relevant example, an answer to their last concern or a simple next step. It suggests a second, shorter version for a week later. Use the slug `quiet-prospect-follow-up` in a setup's `blueprints`. It suits startups, agencies, local businesses and consultancies and firms. #### What someone asks Acme got our proposal two weeks ago and hasn't replied. Their worry was the setup time. #### Steps 1. Read where it stopped: The prospect, the offer, their last concern and the time since the last message are noted. 2. Find something new: One new reason is chosen, with its source. 3. Draft the follow-ups: The first follow-up has at most 100 words and leads with the new reason. The second follow-up has at most 50 words. ### Write a proposal > Writes a proposal from your call notes and your pricing. Writes a proposal for a customer from the request: their situation, what you'll do, timeline, price and next steps. It keeps to the prices and scope the request gives and marks anything you still need to decide. Use the slug `proposal` in a setup's `blueprints`. It suits agencies and consultancies and firms. #### What someone asks Write a proposal for Acme: a three-month onboarding project, €4,000 a month, starting in November. #### Steps 1. Read the scope and prices: The scope, prices and dates are noted, and the open decisions are listed. 2. Settle open decisions with you: Every decision the proposal needs is settled by the request or the person's answer. 3. Write the proposal: The proposal has every section. Every price comes from the request or the person's answers. 4. Check prices and scope: Every line and the total add up. proposal.md is published. ### Coach me on a sales call > Reviews a sales call transcript and shows what to do differently next time. Reads the transcript or notes of a sales call and points out what went well, where the customer's real concern came up, which questions went unasked and what to say next time, with quotes from the call. Paste the transcript when you ask. Use the slug `sales-call-coaching` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Here's the transcript of my call with Acme. What should I have done differently? #### Steps 1. Map the call: Every part of the call is located in the transcript. 2. Find the real concern: The real concern is quoted with its position in the transcript. 3. Score the call: Every item on the list has a yes or no and a quote. 4. Write the coaching: Every improvement has a quote from the call and a better line. The reply has five questions for the next call. ### Write a quote for a job > Turns a customer's job request into a clear quote with your prices. Writes a quote from the job description and your prices in the request: what's included, what isn't, the price per item, the total and how long it's valid. It lists what you still need to ask the customer. Use the slug `job-quote` in a setup's `blueprints`. It suits agencies and local businesses. #### What someone asks Quote for painting a 3-room apartment, about 80 m² of walls. We charge €12 per m² plus €150 for materials. #### Steps 1. Read the job and prices: Every piece of work has its price, or is listed as unpriced. 2. Work out the quantities: Every quantity has its calculation or its stated assumption. 3. Write the quote: The quote has every line, the total, what is included and excluded, and the validity. 4. Check the sums: Every line and the total add up, with unit prices from the request. quote.md is published. ## Get found online Bundle slug: `get-found`. Audits your website, plans articles people find in search, writes your landing page and drafts your social posts. ### Audit your website > Checks your website and lists what to fix first to bring in more customers. Reviews your website's pages for clarity, search visibility, speed and how easily a visitor can sign up. It ranks the problems by impact and shows the page where it found them. Use the slug `website-audit` in a setup's `blueprints`. It suits startups, agencies, online shops and local businesses. #### What someone asks Audit example.com. We sell scheduling software to dental practices. #### Steps 1. Map the site: The main pages are listed with their addresses and purposes. 2. Check what visitors understand: Every main page has its headline quoted and its clarity problems noted. 3. Check search basics: Every main page has its title, description, heading and index status noted. 4. Measure speed: Every main page has its speed measurements and the method used. 5. Try the sign-up path: The sign-up path is described with its clicks, form fields and sticking points. 6. Rank the fixes: Every problem has its page, evidence and a concrete fix. The reply has the ten most important fixes, and website-audit.md is published. ### Plan articles people find in search > Finds what your customers search for and writes briefs for the articles that answer it. Researches the questions your customers search for and ask AI assistants, checks what already ranks, and writes briefs for the articles worth writing: the question, the angle, the outline and the sources to use. Use the slug `search-content-plan` in a setup's `blueprints`. It suits startups, agencies, online shops and consultancies and firms. #### What someone asks We sell project software for architects. Plan five articles that bring us customers from search. #### Steps 1. Read the business: The product, customers and existing articles are noted. 2. Collect customer questions: At least fifteen questions are collected, with their sources. 3. Check what ranks today: Every promising question has its top five results and their gaps noted. 4. Pick the articles: Every picked article has the reason it was picked. 5. Write the briefs: Every brief has the question, angle, outline, sources and call to action. content-plan.md is published. ### Write a landing page > Writes the text for a landing page that sells one offer. Writes a landing page for one product or offer: the headline, what the customer gets, why it's worth it, answers to the usual doubts and the call to action. It checks competitors' pages so yours stands apart from theirs. Use the slug `landing-page-copy` in a setup's `blueprints`. It suits startups, agencies and online shops. #### What someone asks Write a landing page for our new bookkeeping package for freelancers, €49 a month. #### Steps 1. Read the offer: The offer, price, audience and available proof are noted. 2. Read competitors' pages: Two or three competitor pages are noted with their headlines, claims and prices. 3. Choose the angle with you: The person chose the angle. 4. Write the page: The page has every section in order. Every claim and proof comes from the request, or is marked as needed. 5. Check every claim: Every claim on the page appears in the request. landing-page.md is published, and the reply has two alternative headlines. ### Plan a week of posts > Plans and drafts a week of social posts around one goal. Plans a week of posts for the channels you name around one goal, such as a launch, an offer or more bookings, and drafts the posts with their day, channel and a suggested image. Use the slug `week-of-posts` in a setup's `blueprints`. It suits agencies, online shops and local businesses. #### What someone asks Plan next week's Instagram and LinkedIn posts. Goal: more bookings for our autumn workshops. #### Steps 1. Read the goal and company: The goal, channels, facts and voice are noted with their sources. 2. Plan the week: Every post has a day, a channel and a purpose. 3. Draft the posts: Every post fits its channel's length and has a concrete image description. 4. Check the posts: Every fact, price and date matches the request or the website. week-of-posts.md is published. ### Turn one article or video into posts > Turns one article, talk or video into posts, a newsletter section and ideas for short clips. Reads the article or transcript you share and turns it into several pieces: social posts for the channels you name, a newsletter section and the moments worth cutting into short clips. The pieces keep the original's facts and voice. Use the slug `repurpose-content` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Turn this blog post into three LinkedIn posts and a newsletter section. #### Steps 1. Pick the strongest ideas: Five ideas or quotes are picked, with their positions in the original. 2. Write the posts: Every post carries one idea, with facts and quotes as the original states them. 3. Write the newsletter section: The newsletter section has 100 to 200 words and links the original. 4. Pick the clip moments: A video has three clip moments with start and end times, or the report says the original is text. 5. Check against the original: Every quote and number matches the original. pieces.md is published. ### Draft a blog or LinkedIn post > Turns a few bullet points into a blog post or a LinkedIn post. Writes a post from the bullet points in the request, in the format you ask for: a blog post with a title and sections, or a short LinkedIn post. It checks any facts it adds on the web and links them. Use the slug `post-from-bullets` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Write a LinkedIn post from these points: we launched the API, it is free to try, early users save two hours a week. #### Steps 1. Read the points: The format, audience and every bullet point are noted. 2. Check the facts: Every fact beyond the bullet points has a link, or is dropped. 3. Draft the post: The post covers every bullet point and fits the length of its format. 4. Edit the draft: Every bullet point is covered. The reply has the post and two alternative openings. ## Launch something new Bundle slug: `launch`. Tests the idea, researches the market, writes the spec and the landing page, and announces it. ### Stress-test a product idea > Finds the riskiest assumption in an idea and the cheapest way to test it. Takes your idea apart before you build it: what must be true for it to work, which of those is most likely wrong, what the evidence on the web says, and the cheapest test to find out this week. Use the slug `idea-stress-test` in a setup's `blueprints`. It suits startups. #### What someone asks Stress-test this: a subscription for weekly flower deliveries to small offices. #### Steps 1. List the assumptions: Five to eight assumptions are listed, covering customer, problem, price, reach and delivery. 2. Search the evidence: Every assumption has linked evidence for and against it, or the report names the sources searched for it. 3. Pick the riskiest: The riskiest assumption is picked, with the reason. 4. Design the test: The test has a cost, a duration and a result set in advance. The reply has the assumptions, the evidence, the riskiest assumption and the test. ### Research a market > Researches a market before you commit to it: size, customers, competitors and gaps. Researches the market in the request on the web: who the customers are, how big it is, who already sells to them and at what price, and where the gaps are. Every number links its source. Use the slug `market-research` in a setup's `blueprints`. It suits startups and online shops. #### What someone asks Research the market for booking software for small physiotherapy practices in Germany. #### Steps 1. Define the market: The product, segment, region and buyer are stated in one paragraph. 2. Size the market: Both the top-down and the bottom-up calculation are shown. Every input number has a source link and a year. 3. List the competitors: Every competitor has its prices from its own pricing page, or "on request", with the address. 4. Collect complaints: Every complaint is quoted with its link, and every theme has a count. 5. Check every source: Every remaining number, price and quote is confirmed by its source. 6. Write the report: The report has every section in order. Every gap names the complaints or numbers it rests on, and a test. market-research.md is published. ### Turn an idea into a spec > Turns a rough idea into a short spec your team can build from. Writes a spec from the idea in the request: the problem, who has it, what to build, what to leave out, and how you'll know it worked. It lists the questions to answer before building. Use the slug `idea-to-spec` in a setup's `blueprints`. It suits startups. #### What someone asks Spec out team invites: an owner invites people by email, and they join the workspace. #### Steps 1. Read the idea: The problem, who has it, today's workaround and the open points are noted. 2. See how others solve it: Two or three existing solutions are noted with links. 3. Agree the scope with you: The person confirmed the scope of the first version. 4. Write the spec: The spec has every section. Every acceptance criterion can be checked with a yes or no. 5. Check the spec: The spec stays within the agreed scope. spec.md is published. ### Write a landing page `landing-page-copy`, described above under Get found online. ### Announce a release > Turns a list of what shipped into a changelog entry and an email to your customers. Writes a changelog entry and a "what's new" email from the list of changes in the request. It describes the changes by what customers can now do. Use the slug `release-announcement` in a setup's `blueprints`. It suits startups. #### What someone asks Announce this week's release: faster search, CSV export, and a fix for the login loop. #### Steps 1. Sort the changes: Every change is marked new, improved, fixed or internal. 2. Explain what customers can now do: Every customer-facing change has one sentence on what the customer can now do. 3. Write the changelog entry: Every customer-facing change appears once in the changelog entry. 4. Write the customer email: The email has a subject line, at most 250 words, and the three biggest changes first. 5. Check against the list: The changelog entry and the email contain every customer-facing change and only those. release.md is published. ### Write the newsletter > Writes your newsletter from the month's news and links. Turns the updates, links and notes in the request into a newsletter with a subject line, a short opening and one section per story. It suggests three subject lines. Use the slug `newsletter` in a setup's `blueprints`. It suits startups, online shops, local businesses and consultancies and firms. #### What someone asks Write October's newsletter: we launched team invites, wrote about pricing, and we're hiring a designer. #### Steps 1. Read the news and links: Every story has its takeaway, and every failing link is listed. 2. Write the newsletter: Every story has a section with its link. Every fact comes from the request or a linked page. 3. Write the subject lines: There are three subject lines of at most 50 characters and a preview line. 4. Check the links: Every link in the newsletter loads. newsletter.md is published. ### Find out what people are saying > Finds what people said about a topic online in the last 30 days. Searches public forums, Reddit, Hacker News and other public pages for what people said about a topic, product or problem in the last 30 days, and sums up the main opinions and complaints with links. Use the slug `topic-research` in a setup's `blueprints`. It suits startups, agencies and online shops. #### What someone asks What are people saying about invoicing tools for freelancers this month? #### Steps 1. Set the search: The search terms and the 30-day window are noted. 2. Search recent posts: Every collected post has its link, date and a quote. 3. Check dates and links: Every remaining post loads and falls within the 30-day window. 4. Sum up what people say: Every group has its post count and two linked quotes, in at most 600 words. ### Explain what a change means for customers > Tells you in plain words what customers will notice from a change before you announce it. Reads a pull request or a change, works out what customers will see differently and who is affected, and describes it in plain words you can use in an announcement. Use the slug `explain-a-change-for-customers` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks What does #56 change for customers? Deciding whether it goes in the newsletter. #### Steps 1. Read the change: The change's diff and description are read. 2. Work out what customers notice: Every customer-visible effect is listed with who it affects. 3. Describe it in plain words: The reply describes the change in plain words and says whether to announce it. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## Plan what to build Bundle slug: `plan-the-work`. Scopes requests into issues, adds acceptance criteria, sizes the work and splits big features, based on how your product works today. ### Scope a feature request into an issue > Turns a request customers keep making into an issue that says what would have to change. Reads the request and how your product works today, and files an issue that says what customers want, what already exists, and what would have to change, ready for planning. When it finds an issue about the same request, it adds the scope to that issue instead. Use the slug `feature-request-to-scoped-issue` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Three customers asked this month for invoices in English. Can you file it for billing with what would need to change? #### Steps 1. Read the request: The request is stated as an outcome, with who asked and quotes. 2. Check how the product works today: The parts involved are listed with what they do today and file references. 3. Check for an existing issue: A matching issue is found or ruled out. 4. Work out what would change: Every change is tied to a part of the product, and the open questions are listed. 5. File the issue: The reply links one issue that holds the scope. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Add acceptance criteria to an issue > Adds acceptance criteria to a short issue, so the team builds what was meant. Reads the issue and the code it touches, writes acceptance criteria that match how your product works today, and adds them to the issue. It asks you when a criterion depends on a product decision. Use the slug `add-acceptance-criteria` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Can you add acceptance criteria to ENG-224? They should match how invoices and reminders work today. #### Steps 1. Read the issue: What the issue asks for is restated. 2. Read the code it touches: Today's behavior, defaults and existing data are noted with file references. 3. Write the criteria: Every criterion can be checked with a yes or no. 4. Add them to the issue: The issue holds the criteria, and its earlier text is unchanged. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Split a large feature into smaller issues > Turns a feature too big for one change into smaller linked issues the team can take one at a time. Works out which parts of your product a feature touches, proposes a split you confirm, and files linked issues that can ship one at a time. Use the slug `split-a-feature-into-issues` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks ENG-224 is too big for one go. Can you split it into issues the team can pick up one at a time? #### Steps 1. Read the feature: What the feature asks for is restated. 2. Map the parts it touches: Every part is listed with the change it needs and file references. 3. Agree the split with you: The person confirmed the split. 4. File the linked issues: Every confirmed issue exists and links to the original issue. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Size a request before planning > Gives a rough size for a request before it goes into a plan, with what drives it. Finds every part of your product a request touches, compares it with similar work your team already did, and gives a rough size in days or weeks with what drives it. Use the slug `size-a-request-before-planning` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks How big is ENG-240, quarterly billing? Days or weeks? #### Steps 1. Read the request: What the request asks for is restated. 2. Find every part it touches: Every part touched is listed with file references. 3. Compare with past work: Similar past changes are listed with their size and duration. 4. Give a rough size: The size is a range, with what drives it and its risks. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Compare two ways to build a feature > Recommends one of two ways to build a feature, with what both would change. Works out what two ways of building a feature would change in your product, and recommends one with the reason. Use the slug `compare-two-ways-to-build-a-feature` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks For English invoices, should we translate the existing template or add a second template per language? #### Steps 1. Pin down the two options: Both options are stated in concrete terms. 2. Work out what the first option changes: The first option's changes are listed with file references. 3. Work out what the second option changes: The second option's changes are listed with file references. 4. Recommend one: The reply recommends one option with its reason and compares both. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find backlog issues that are already done > Finds the open issues your recent changes already handled, so you can close them. Checks your open issues against recent changes and today's code, and lists the ones that are done, with the changes that handled them, so you can close them. Use the slug `find-backlog-issues-already-done` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Cleaning up the backlog before planning. Are any of the open billing issues already done? #### Steps 1. Collect the open issues: The open issues in the area are listed. 2. Read recent changes: The recent changes in the area are listed with links. 3. Check the issues against the code: Every issue counted as done has the code and the change that confirm it. 4. List the issues you can close: The reply lists done issues with their changes, and the issues stay open for the person to close. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Turn an idea into a spec `idea-to-spec`, described above under Launch something new. ### Summarize customer interviews > Pulls the patterns out of your customer interview notes. Reads the interview notes or transcripts in the request, finds what several customers said, and ranks the patterns with quotes. It separates what customers do today from what they say they want. Use the slug `interview-summary` in a setup's `blueprints`. It suits startups. #### What someone asks Here are notes from six interviews with bakery owners. What did we learn? #### Steps 1. Read the interviews: Every interview has its customer's problems, workarounds and wishes, with quotes. 2. Find the patterns: Every pattern names the interviews it appears in, and at least two. Behavior and stated wishes are in separate lists. 3. Check the quotes: Every quote matches the notes and its interview. 4. Write the findings: The patterns are ranked by number of interviews and quoted from them. interviews.md is published. ## Make small product changes Bundle slug: `product-changes`. Changes wording, price labels, plan limits and exports in your product as reviewed pull requests that your developers merge. ### Correct a misleading label or help text > Corrects text in your product that confuses customers, everywhere it appears. Finds every place a confusing label or help text appears, agrees the new wording with you, and corrects it in one reviewed pull request. Use the slug `correct-misleading-help-text` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Customers think payment terms count from delivery. The help text should say they count from the invoice date. #### Steps 1. Find every place the text appears: Every place the text appears is listed. 2. Agree on the wording with you: The new wording is chosen. 3. Correct the text: Every listed place shows the new wording. The diff changes text only. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Make a confusing price label clear > Rewrites a price label that confuses customers and leaves the prices as they are. Finds the price labels that confuse customers, agrees the new wording with you, and rewrites them in one reviewed pull request that leaves every price and calculation unchanged. Use the slug `clearer-price-labels` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Customers read the yearly plan as a monthly price. Show it as a monthly price billed yearly. #### Steps 1. Find the price labels: Every place the label appears is listed. 2. Agree on the wording with you: The new wording is chosen. 3. Rewrite the labels: Every listed place shows the new label. The diff changes label text only. Every price, amount and calculation stays the same. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Change the wording of a customer email > Rewords a customer email and keeps every fact in it as it was. Rewords an email your product sends, agrees the wording with you, and keeps every amount, date, link and placeholder as it was, in one reviewed pull request. Use the slug `change-customer-email-wording` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks The first payment reminder sounds harsh. Can you give it a friendlier opening? #### Steps 1. Find the email template: The template in every language and its placeholders are listed. 2. Agree on the wording with you: The new wording is chosen. 3. Reword the email: Every placeholder, amount, date and link is unchanged. Every language has the new wording. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Change a plan limit or a default > Changes a plan limit everywhere your product sets it, in one reviewed pull request. Finds every place a plan limit or default is set or shown, changes all of them in one reviewed pull request, and tells you what happens to existing customers. Use the slug `change-a-plan-limit` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks We're raising the free plan from 20 to 25 invoices a month. Can you make the change? #### Steps 1. Find every place the limit is set: Every place the limit is set, checked or shown is listed. 2. Check existing customers: The effect on existing customers is stated and decided. 3. Change the limit: Every listed place uses the new limit. The tests cover the new limit. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Change the default payment terms > Changes the default payment terms for new customers and leaves existing customers on theirs. Changes the default payment terms for new customers in one reviewed pull request, and makes sure existing customers keep the terms they have. Use the slug `change-default-payment-terms` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks New customers should get 30-day payment terms instead of 14. Existing customers keep theirs. #### Steps 1. Find where the default is set: Every place that sets or reads the default is listed. 2. Check existing customers: How existing customers keep their terms is decided. 3. Change the default: A test shows new customers get the new terms and existing customers keep theirs. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Update your company address on every document > Updates your company address on every document your product prints, in one reviewed pull request. Finds every document template, email and page that prints your company address, and updates all of them in one reviewed pull request, with a list of where it appeared. Use the slug `update-the-company-address` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks We moved to Hafenstraße 12, 20457 Hamburg on the 1st, and invoices still show the old address. Can you update it everywhere? #### Steps 1. Find every place the address appears: Every place the old address appears is listed. 2. Update the address: A search of the repository finds only the new address. The commit message lists every place changed. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Add a column to a finance export > Adds a field your accounting needs to an export, as the last column, so existing imports keep working. Adds the field accounting needs as the last column of an export, so imports that read the existing columns keep working, with a test for the new format, in one reviewed pull request. Use the slug `add-a-column-to-an-export` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Accounting needs the purchase order number in the invoice CSV. Can you add it? #### Steps 1. Find the export: The export's code and tests are identified. 2. Find where the field is stored: The field's source and its empty case are known. 3. Add the column last: The new column is last, and every existing column is unchanged. A test covers the header and both cases. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## Ship from issues Bundle slug: `ship-from-issues`. Turns issues into reviewed pull requests, fixes production errors, adds tests, updates dependencies and writes release notes. ### Turn an issue into a pull request > Implements an issue, runs the tests and opens a reviewed pull request. Takes a Linear, Jira or GitHub issue linked to the task, or the change the request asks for, makes the change in your repository, and publishes only when the tests and the linter pass. A separate review checks the pull request before anyone merges it. Use the slug `issue-to-pull-request` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Implement ENG-482. #### Steps 1. Read the issue: The request is restated as checkable acceptance criteria. 2. Find the code: The files to change and their tests are identified. 3. Make the change: Every acceptance criterion is met. Tests cover the change. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Fix a production error `fix-production-error`, described above under Fix what customers report. ### Update dependencies > Updates outdated packages and fixes what breaks. Updates the repository's outdated dependencies, reads their changelogs for breaking changes, adapts the code and publishes when the tests pass. Use the slug `dependency-updates` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Update this week's outdated dependencies. #### Steps 1. List the outdated packages: Every outdated dependency is listed with its current and latest version. 2. Read the changelogs: Every breaking change is listed with the places in the code it affects. 3. Update and adapt the code: The dependencies are updated and the lockfile matches. The code is adapted to every breaking change of the updated packages. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Write release notes > Writes the notes for a release from its merged pull requests. Reads the pull requests merged since the last tag, writes release notes grouped by area, and commits them to the changelog. Use the slug `release-notes` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Write the notes for v2.4. #### Steps 1. List the merged changes: Every change merged since the last tag is listed. 2. Group them by area: Every change is in one area or marked internal. 3. Write the notes: The changelog has a line for every merged change since the last tag, under the new version. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Clear the small tickets in your backlog > Starts one task per small ticket you name, and reports one reviewed pull request per ticket. Reads the small tickets you name, starts a task that turns every ticket into its own reviewed pull request, follows them to the end, and reports the pull request links. Use the slug `backlog-tickets-overnight` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Can you take ENG-215, ENG-216 and ENG-217 tonight? Small billing tickets, one pull request per ticket please. #### Steps 1. Read the tickets: Every named ticket is kept or left out with a reason. 2. Start one task per ticket: Every kept ticket has exactly one started Session. 3. Follow the tasks: Every Session has ended, with a pull request link or a failure reason. 4. Report the pull requests: The reply lists every kept ticket with its pull request or failure. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Review a teammate's change before it ships > Tries a change against the cases its tests miss and shows you the problems it finds, with examples. Reads a pull request and its tests, tries the cases the tests miss in a copy of the code, and reports the problems it finds with concrete examples. Use the slug `review-a-pull-request` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Our teammate is out today and I'd like to merge the customer import PR #46. Can you give it a second look first? #### Steps 1. Read the change: The diff, tests and description of the pull request are read. 2. Find the cases the tests miss: The untested cases are listed. 3. Try those cases: Every listed case was tried, with its input and result. 4. Report the problems: Every problem has a concrete example with expected and actual results. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Add tests before anyone touches old code > Adds tests that record how old code behaves today, before anyone reworks it. Reads old code and how it is used, and adds tests that record how it behaves today, odd cases included, in one reviewed pull request that changes only tests. Use the slug `add-tests-before-a-rework` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks We're about to rework the dunning schedule. Can you add tests for how it behaves today first, and keep the code as it is? #### Steps 1. Read the code and its callers: The code, its callers and its existing tests are read. 2. List today's behavior: Today's behavior is listed as inputs and results. 3. Add the tests: The new tests pass against today's code. The diff changes test files only. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find out why a test fails only sometimes > Finds why a test fails only some of the time and shows the runs that prove it. Runs a test many times, compares the failures, makes it fail on demand, and names the cause with the runs that prove it and a fix to try. Use the slug `find-a-flaky-test` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks test/reminders.test.ts fails about one CI run in ten and I can't see a pattern. Why? #### Steps 1. Run the test many times: The test ran at least 50 times, and every failure's output is kept. 2. Compare the failures: The difference between failing and passing runs is named. 3. Make it fail on demand: The test fails on demand, or the report lists what was tried. 4. Report the cause: The reply names the cause with the runs that prove it. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Add logging around a failure you can't reproduce > Adds logging so the next failure shows why it happened, with personal data masked. Works out which values a failure depends on and adds logging for them in one reviewed pull request, with personal data masked. Use the slug `add-logging-around-a-failure` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks A payout statement comes out empty once or twice a week and we can't reproduce it. Can you add logging so we see why next time? #### Steps 1. Work out what the failure depends on: The decisions and values that can lead to the failure are listed with file references. 2. Add the logging: Every listed decision logs its values. Personal data in the logs is masked. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Delete dead code > Finds the functions and files your product stopped calling and deletes them in one reviewed pull request. Finds the code your product stopped calling, checks every candidate, and deletes it in one reviewed pull request with your tests passing. Use the slug `remove-unused-code` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Can you delete the dead code in the billing module? One pull request please. #### Steps 1. Find unused code: The candidates are listed with the tool that found them. 2. Check every candidate: Every kept candidate appears only in its own files, across code, scripts, configuration and dynamic imports. 3. Delete the code: A search after the deletion finds the deleted names only in the commit message. The commit message lists what was deleted. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Document a part of your code > Documents a part of your code, checked against what the code does. Reads a module and how it is used, and writes its docs in one reviewed pull request, with every statement checked against the code. Use the slug `document-a-part-of-the-code` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Can you add a section to the README on how reminders get scheduled? #### Steps 1. Read the module and its callers: How the module works is noted with file references. 2. Write the docs: Every statement in the docs matches the code. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## Keep your team informed Bundle slug: `team-rituals`. Summarizes the stand-up, follows up on meetings and writes the weekly team and monthly investor updates. ### Summarize the stand-up > Posts one stand-up summary with the blockers first. Reads the stand-up updates in the request and posts one summary: blockers first, then one line per person on what they did and plan to do. It names who still has to post. Use the slug `standup-summary` in a setup's `blueprints`. It suits startups and agencies. #### What someone asks Summarize today's stand-up from this thread. #### Steps 1. Collect the updates: Every update in the request is collected. Everyone who still has to post is listed. 2. Match blockers to helpers: Every blocker has a suggested helper or is marked as needing a lead. 3. Post the summary: The summary lists the blockers first and has at most 200 words. ### Turn meeting notes into action items > Turns meeting notes into action items and a follow-up email. Reads the meeting notes in the request, lists the decisions and the action items with their owners and due dates, and drafts a follow-up email to the attendees. Use the slug `meeting-follow-up` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Here are the notes from today's planning meeting. Write the follow-up. #### Steps 1. List decisions and action items: Every decision and action item in the notes is listed. 2. Fill gaps with you: Every action item has an owner and a due date. 3. Draft the follow-up: The email lists every decision and action item, in at most 250 words. ### Write the weekly team update > Turns the week's posts into a team update: what shipped, what's in progress, what's blocked. Reads the week's posts in the request and writes one team update: what shipped, what is in progress, what is blocked, and what comes next. Use the slug `weekly-team-update` in a setup's `blueprints`. It suits startups and agencies. #### What someone asks Write this week's team update from this thread. #### Steps 1. Collect the week's posts: Every piece of work mentioned in the posts is collected with its owner. 2. Sort the work: Every piece of work is in exactly one group. 3. Write the update: The update has the four groups and at most 300 words. ### Plan next month from last month's numbers > Reads last month's numbers and tells you what to focus on next month. Reads the numbers you paste, such as revenue, customers, costs and traffic, and explains what changed and the likely reasons. It suggests three priorities for next month and marks which explanations are guesses. Use the slug `monthly-priorities` in a setup's `blueprints`. It suits startups, online shops and local businesses. #### What someone asks Here are September's numbers. What should we focus on in October? #### Steps 1. Read the numbers: Every metric has its change from the month before. 2. Find the likely reasons: Every large change has an explanation, with guesses marked. 3. Set the priorities: Every priority names a number, a target and how to measure it. ### Write the monthly investor update > Turns a few bullet points into a monthly investor update. Turns your bullet points into a monthly investor update: highlights, key numbers, what went wrong, what comes next and how investors can help. Use the slug `investor-update` in a setup's `blueprints`. It suits startups. #### What someone asks Write the October investor update: revenue up 12%, hired two engineers, lost a big deal, need intros to logistics companies. #### Steps 1. Sort the bullet points: Every bullet point is in a section, and the numbers still needed are listed. 2. Fill in numbers with you: Every usual number is given or flagged for you to fill in. 3. Draft the update: The update has every section in at most 400 words. Every ask names the help wanted. 4. Check the numbers: Every number comes from the request or the person's answers. investor-update.md is published. ### Summarize a long thread for someone who missed it > Sums up what a long thread decided, and who decided it, for someone who missed it. Reads the whole thread and writes a short summary of what was decided and by whom, what is still open, and who does what next. Use the slug `summarize-a-long-thread` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks I was out for two days. What did this thread decide? #### Steps 1. Read the whole thread: Every message in the thread is read. 2. Pull out the decisions: Every decision names who made it. 3. Write the summary: The summary has at most 150 words and puts the decisions first. ### See what changed in one part of your product > Describes in plain words what shipped in one area of your product over a period you choose. Reads the changes in one area of your product for the period you name, with their issues, and describes what changed for customers in plain words, with links. Use the slug `what-changed-this-month` in a setup's `blueprints`. It suits startups. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks What changed in payment reminders in September? It's for the board update, so plain words please. #### Steps 1. Find the area in the code: The area is mapped to its folders and files. 2. List the changes: Every change in the period is listed with its pull request or commit. 3. Describe the changes in plain words: The reply describes the customer-visible changes first, with links. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### Find out what's holding up a project > Shows what's still open on a project and what those open items are waiting on. Collects a project's open issues, works out what the open items wait on, such as another issue, a decision or an owner, and tells you who can move them. Use the slug `find-whats-holding-up-a-project` in a setup's `blueprints`. It suits startups and agencies. It works with Linear, Jira and GitHub Issues. #### What someone asks Where are we on English invoices? Is anything stuck? #### Steps 1. Collect the open items: The project's open issues are listed with their comments. 2. Check what they wait on: Every open item names what it waits on. 3. Report what's holding it up: The reply groups the open items by what they wait on, with who can move them. ### Find urgent issues that need an owner > Shows the urgent issues that need an owner, oldest first, with how long they've waited. Searches your tracker for urgent issues that need an owner, lists them oldest first with how long they've waited, and suggests an owner for every issue. Use the slug `find-urgent-issues-that-need-an-owner` in a setup's `blueprints`. It suits startups. It works with Linear, Jira and GitHub Issues. #### What someone asks Which high priority issues in DEV still need an owner? #### Steps 1. Search for urgent issues: The urgent open issues that need an owner are listed. 2. Suggest an owner: Every issue has a suggested owner with the reason. 3. List them oldest first: The list is ordered oldest first and shows how long every issue has waited. ### Write up when and why something changed > Writes a dated account of when and why something changed, ready to forward to an auditor. Traces a change through your issues and code history, and writes a dated account of what changed, when, why and who decided it, for someone outside the team. Use the slug `write-up-when-something-changed` in a setup's `blueprints`. It suits startups and consultancies and firms. It works with Linear, Jira, GitHub Issues and GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks The auditor wants to know when and why our invoice numbers changed format this year. Can you write it up? #### Steps 1. Find the change: The change is identified with its commits and their dates. 2. Find the reason: The reason and who decided it are found, with links. 3. Write the account: The account gives dates, before and after, the reason and who decided it. 4. Check every date and link: Every date and link matches its source. change-account.md is published. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## Run client work Bundle slug: `client-work`. Welcomes new clients, writes their monthly reports, follows up after meetings and chases unpaid invoices. ### Welcome a new client > Prepares everything for a new client's start: welcome email, questions and kickoff agenda. Prepares a new client's onboarding from what you sold them: the welcome email, the questions you need answered, the access you need, the kickoff agenda and the first milestones. Use the slug `client-onboarding` in a setup's `blueprints`. It suits agencies and consultancies and firms. #### What someone asks We just signed Acme for a three-month SEO project. Prepare the onboarding. #### Steps 1. Read what was sold: The deliverables, start date and contacts are noted. 2. Write the intake questions: Every intake question asks for a fact the client still has to give. 3. List the access you need: Every access item has its permission level. 4. Plan the kickoff: The agenda has times per topic and the decisions to make. 5. Set the first milestones: Every milestone has a date and what the client sees. 6. Write the welcome email: The welcome email has at most 250 words and matches the request's names and dates. onboarding.md is published. ### Write a client's monthly report > Turns a client's numbers into a monthly report they'll actually read. Turns the numbers and notes you paste into a short report for a client: what changed, why, what you did and what comes next. It explains every number in plain words and flags anything that needs a conversation. Use the slug `client-report` in a setup's `blueprints`. It suits agencies and consultancies and firms. #### What someone asks Write Acme's October report. Traffic is up 18%, leads down 5%, and we launched two landing pages. #### Steps 1. Read the numbers: Every metric has this month's value and its change. 2. Explain the changes: Every notable change has an explanation, with guesses marked. 3. Write the report: The report has the summary, the numbers, the work done, next steps and discussion points. 4. Check every number: Every number matches the request. client-report.md is published. ### Write a proposal `proposal`, described above under Win more customers. ### Turn meeting notes into action items `meeting-follow-up`, described above under Keep your team informed. ### Chase an overdue invoice > Drafts a friendly reminder for an unpaid invoice, and a firmer one if it's needed. Drafts a reminder that fits how late the payment is and how well you know the client: a friendly nudge first, then a firmer second reminder. Both name the invoice, the amount and how to pay. Use the slug `invoice-reminder` in a setup's `blueprints`. It suits agencies, local businesses and consultancies and firms. #### What someone asks Invoice 2026-041 to Acme for €3,200 is three weeks overdue. They're a good client. #### Steps 1. Read the invoice: The invoice details and the days overdue are noted. 2. Draft the reminders: Both reminders name the invoice number, amount and how to pay. Consequences appear only when the request names them. 3. Check the details: The details in both reminders match the request. ## Run your shop Bundle slug: `online-shop`. Writes product descriptions, answers reviews and customer emails, and plans your posts. ### Write product descriptions > Writes product descriptions that sell, from your product details. Writes descriptions for the products in the request: a short opening that sells the product, the details buyers look for and the words people search for. It keeps to the facts you give and lists the details it still needs. Use the slug `product-descriptions` in a setup's `blueprints`. It suits online shops. #### What someone asks Write descriptions for these six ceramic mugs. Details are below. #### Steps 1. Read the products: Every product has its facts and the details it still needs listed. 2. Find the search words: The common search words for these products are listed with where they were seen. 3. Write the descriptions: Every product has a description with an opening line, details and care or size information. 4. Check the facts: Every claim matches a detail in the request. The reply has every description and the details still needed. ### Reply to customer reviews `review-replies`, described above under Answer customers faster. ### Draft replies to customer emails `customer-email-replies`, described above under Answer customers faster. ### Plan a week of posts `week-of-posts`, described above under Get found online. ### Compare competitors > Compares your competitors' pricing, customers and positioning in one table. Researches the competitors you name, or finds the three closest ones, from their own websites and public reviews. It compares their pricing, who they sell to and how they describe themselves, in one table with the sources linked. Use the slug `competitor-comparison` in a setup's `blueprints`. It suits startups, agencies and online shops. #### What someone asks Compare us with Linear, Jira and Asana. We are a project tracker for small agencies. #### Steps 1. Pick the competitors: The competitors to compare are named by the request or confirmed by the person. 2. Read their pricing: Every competitor's plans and prices come from its own pricing page, with the address. 3. Read how they describe themselves: Every competitor has its headline, target customer and main claims, with links. 4. Read their reviews: Every competitor has its most common praise and complaints, with links. 5. Check the sources: Every remaining price and claim is confirmed by its source. 6. Write the comparison: The table has a row for every competitor, with the sources listed. Every takeaway names the finding it rests on. competitors.md is published. ## Cut admin Bundle slug: `cut-admin`. Finds savings in your software bills, compares tools before you buy, chases invoices, writes job posts and onboarding checklists, and turns your to-dos into issues. ### Cut your software costs > Finds savings in your software subscriptions and drafts the emails to get them. Goes through the subscriptions you list, finds overlaps, unused seats and cheaper plans, and checks current prices on the web. It drafts the cancellation and negotiation emails for your review. Use the slug `software-spend-review` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Here are our 14 software subscriptions with prices and seats. Where can we save? #### Steps 1. List the subscriptions: Every subscription is in the table, with the monthly and yearly total. 2. Check current prices: Every tool has its current cheapest fitting plan, with the pricing page address. 3. Find overlaps and unused seats: Every overlap and every unused seat is listed with the tools involved. 4. Choose the cuts with you: The person chose the savings to go after. 5. Draft the emails: Every chosen saving has its email of at most 120 words. ### Compare tools before you buy > Compares the tools you're choosing between on price, features and reviews. Researches the tools you name, or finds the main ones for what you need, and compares price, the features that matter for your case, and what reviewers say. It ends with a recommendation and why. Use the slug `tool-comparison` in a setup's `blueprints`. It suits startups, agencies, online shops, local businesses and consultancies and firms. #### What someone asks Compare accounting software for a five-person company in Germany. #### Steps 1. Pin down your needs: The must-haves, budget and team size are known. 2. Shortlist the tools: Three to five tools are shortlisted, or the ones the request names. 3. Work out the yearly cost: Every tool has a yearly cost for the team size, with its pricing page address. 4. Check the must-haves: Every must-have for every tool is marked yes, partly or no, with a link. 5. Read the reviews: Every tool has its most common praise and complaints, with links. 6. Compare and recommend: The table covers every shortlisted tool. The recommendation names its reason and a runner-up. tool-comparison.md is published. ### Chase an overdue invoice `invoice-reminder`, described above under Run client work. ### Write a job post > Writes a job post from a role description. Writes a clear job post from the role description in the request: what the person will do, what they need, what you offer and how to apply. It avoids jargon and wording that puts good candidates off. Use the slug `job-post` in a setup's `blueprints`. It suits startups, agencies, online shops, local businesses and consultancies and firms. #### What someone asks Write a job post for a part-time bookkeeper, remote, 20 hours a week. #### Steps 1. Read the role: The tasks, requirements and terms are noted, and the details still needed are listed. 2. Fill in details with you: The salary range, location, hours and start date are known, or the person chose to leave them out. 3. Write the job post: The post has every section and at most six must-haves. 4. Check the language: Every requirement comes from the request. job-post.md is published. ### Write an onboarding checklist > Writes the onboarding checklist for a new hire. Writes a checklist for a new hire's first day, first week and first month from their role and what the request says about your team and tools, and names who is responsible for which step. Use the slug `onboarding-checklist` in a setup's `blueprints`. It suits startups, agencies and consultancies and firms. #### What someone asks Write the onboarding checklist for Sam, our new support lead, starting Monday. #### Steps 1. Read the role and team: The role, start date, team and every named tool are noted. 2. Draft the checklist: Every item has an owner and a due date. The first month ends with measurable goals. 3. Check owners and access: Every named tool has an access item before day one. onboarding.md is published. ### Write a runbook for a task your team rarely does > Writes the steps for a manual task into your docs, checked against how your product works. Works out the steps for a manual task from your product's code and docs, and writes a runbook into your docs in one reviewed pull request: what you need, the exact steps, how to check it worked and how to undo it. Use the slug `write-a-runbook` in a setup's `blueprints`. It suits startups. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks We resend failed invoice emails by hand every few weeks and look up the steps every time. Can you write a runbook? #### Steps 1. Pin down the task: The task and the place for the runbook are known. 2. Work out the steps from the code: Every step is backed by the code or a script, with file references. 3. Write the runbook: The runbook has every section, and every command exists in the repository or its tools. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ### File a list of tasks as tracked issues > Files one issue per task from a checklist you paste, in the right project. Reads the list of tasks you paste, checks for issues that already exist, and files one linked issue per task in the project you name. Use the slug `file-a-checklist-as-issues` in a setup's `blueprints`. It suits startups and agencies. It works with Linear, Jira and GitHub Issues. #### What someone asks Can you file these in Jira under OPS? Rotate the payment provider keys, renew the invoice font license, archive the 2023 reminder letters. #### Steps 1. Read the list: Every task in the request is listed. 2. Check for existing issues: Every task is matched to an existing issue or marked new. 3. File one issue per task: Every new task has exactly one issue, and the reply lists the links. ### Check that your product follows a rule from your accountant > Tells you whether your product follows a rule your accountant gave you, with the cases that break it. Turns your accountant's rule into checks, reads how your product handles it, and answers yes, partly or no, with the cases that break it. Use the slug `check-a-rule-from-your-accountant` in a setup's `blueprints`. It suits startups and consultancies and firms. It works with GitHub. It changes code in a repository, so it needs a code repository and the "developer" path. #### What someone asks Our accountant says we have to keep every invoice PDF for ten years. Does our product do that? #### Steps 1. Turn the rule into checks: The rule is restated as concrete checks. 2. Find how your product handles it: The code the rule touches is listed with file references. 3. Look for cases that break it: Every case that breaks a check is listed with file references. 4. Answer yes, partly or no: The reply starts with yes, partly or no and lists the breaking cases. Then devboxes runs the repository's tests and linter, fixes the code once when a test fails, opens a pull request when both pass, and a second agent reviews the pull request. ## For AI assistants - [System prompt](https://devboxes.ai/system.llms.txt): read this before you help someone set up devboxes.