# The service catch-up pack **A free pack from Perform.** For the meeting in twenty minutes about a service you do not know. **Free and provided as is, with no warranty. It runs in your environment and sends nothing to Perform. It is not legal, tax, security or accounting advice. Treat anything you point it at as untrusted input. Full terms at the end of this file.** --- ## How to use this Copy everything below the second line into Claude, ChatGPT, Copilot or whatever assistant you already use, then paste your readme, the entry-point files and the commit log in the same message. That is the whole setup. No account, no install, nothing to configure. If you would rather have it installed and available every time, the same pack is on the page you downloaded this from as a Claude Skill. --- ## What this does There is a meeting in twenty minutes about a service you do not know, and everyone in the room will assume you do. This builds the mental model, and gives you the questions that make the twenty minutes count. One output, one page. You fill it as you read, so nothing gets written twice. ## What to give it Paste what you can get in two minutes: 1. The readme and any architecture notes. 2. The directory listing, the entry-point files, and the handler bodies for the busiest one or two interfaces. A route table on its own will not give you the main path. 3. Recent incidents or alerts if you have them, and the last fifty commit messages with real dates and file paths. `git log --date=short --name-only -50` gives you both. Relative dates like "2 months ago" cannot be lined up against an incident, and a log with no paths cannot tell you which files change most. 4. The on-call rotation and the alert configuration. Two minutes of reading, and they tell you what the team already knows is fragile, because somebody paid for that alert with a bad night. You do not need the whole codebase. Entry points, handler bodies, the readme and the commit log carry most of it. If something is missing, the page will say so, which is more useful than a confident guess. **When two sources disagree, the disagreement goes on the page.** The readme says one owner, the codeowners file says another. The architecture note describes a queue the code no longer uses. Where one of the two sources is code, trust the code on what happens and the humans on why, because documentation goes stale and code does not. Where both are documents, name both and let the room settle it. A contradiction you resolve quietly is a guess you will assert out loud. ## When to stop short **If the service is small and clear, say so and stop.** Three files, one endpoint, no incidents, one owner: that is four lines, not a page. Reserve the full write-up for the ones where the reading actually changed what you thought. ## Step 1. Fill the page as you read First, check what you actually got. Name which of the four inputs are missing, and say which fields will be degraded by each absence. Two minutes here saves you from writing a confident page off a pathless log and a route table. This is the only place anything gets written. Work down the fields, and put the answer in the field the moment you have it. ``` # [Service name] ## In one line ## How old it is and who built it ## Who breaks if it does ## What it needs to run ## How work gets in ## The main path [5 to 8 steps. Without the handler body, write the inferred shape, mark it inferred, and list what you would read to confirm it] ## What it writes ## Where it breaks [From Step 2] ## What the incidents and the commits say together [From Step 2] ## Ownership ## What pages someone ## What I could not tell from what I read ``` What to look for in each field: - **In one line.** What it does, in a sentence a non-engineer would follow. - **How old it is and who built it.** The first commits in the log, and whether their authors are still committing. Age tells you which era of decisions you are looking at, and an original author who has gone is a warning about the comments nobody can explain. If the log does not reach back far enough, say so here. - **Who breaks if it does.** Which teams, which customer-facing features, which reports. If it goes down at 2pm on a Tuesday, who notices and how fast. - **What it needs to run.** The databases, queues, third parties and internal services. Mark which of these it cannot survive without. - **How work gets in.** Endpoints, consumers, scheduled jobs, event subscriptions, CLI. For each, what triggers it and roughly how often. Everything else follows from this, so do it before the main path. - **The main path.** For the busiest interface, the sequence from request to result. Five to eight steps, not a full trace. This needs the handler body. If all you have is the route table, say that the main path is inferred and name what you would read to confirm it. - **What it writes.** Everywhere it changes stored state, and what protects each one. This is the short list that matters most, because reads are forgiving and writes are not. - **Ownership.** Three answers, however many lines they take. Who owns it on paper, listing every source and what each one says, including the sources that disagree. Who has actually committed in the last six months. Whether those are the same people. When they are not, that gap is the real state of the service, and it is the most useful thing you can walk into the meeting knowing. - **What pages someone.** From the rotation and the alert config: which of the failures in the "where it breaks" list would wake a human, and which would happen in silence. A risk nobody is paged for is a different risk. - **What I could not tell from what I read.** Every gap, plainly. This field separates what you know from what you are assuming, so you do not assert something in the meeting that turns out to be wrong. Anything the fields above could not answer goes here by name. ## Step 2. Find where it breaks The two hardest fields get their own pass, because this is the section that makes you useful in the meeting. First, gather the candidates: - **Recent incidents.** What went wrong, how often, whether the same thing keeps happening. - **The scary parts.** The signals in the code and history: files with the highest change rate (count paths in the log, and skip this signal if your log has none), comments containing apologies or warnings, retries wrapped in retries, hardcoded values with no explanation, a default or fallback that lets a bad input produce a plausible answer where an error belongs, a test file that is skipped, a migration that never completed, a config value with a person's name in it. - **The single points.** Anything with one instance, one owner, one credential, or one person who understands it. - **What is not covered.** Where tests are absent around behaviour that matters. Absence of tests around money or permissions is the finding. **Then read the incidents against the commit log, because that pairing produces most of what you will say in the meeting.** For each incident, find the commits around it and answer three things: 1. **Did a fix ship?** An incident with no commit after it is either unfixed or outside the log you were given. Check whether the causal change is even inside your window before you say nobody fixed it, because a truncated log looks exactly like neglect. 2. **Did the fix hold?** A second incident in the same area after a fix means the first fix treated a symptom. 3. **Who did the fixing?** When one name appears on every incident fix, you have found both the single point of failure and the person to ask. Where the dates will not line up, say which readings they permit and stop there. A commit dated "2 months ago" against an incident dated 2 June could be the cause or the response, and picking one is how a wrong story gets told in a meeting. The reverse read is worth the same. A burst of commits in one area with no incident attached is usually somebody preventing one, and they know something about that area that is written down nowhere. Then rank what you found. **Damage first, likelihood second.** A rare failure that loses money or corrupts data outranks a weekly failure that retries and recovers. Where two are equal on damage, the more frequent one goes first. ## Step 3. The three questions Finish with the three questions to ask in the meeting. Not general questions. Questions that come from what you just read, that the people in the room will recognize as coming from someone who looked. The ones that usually earn their place: - A question about the specific scary part you found, asked without judgement. "I noticed the retry around the payment call has no idempotency key. Is that handled somewhere I did not look?" - A question about the ownership gap. "The codeowners file says platform, and the last six months of commits are all from one person on payments. Which is it?" - A question about the thing that is not there. "I could not find tests around the refund path. Is that covered somewhere else?" Each one should be answerable in a sentence by whoever knows, and each one should make the room glad you asked. --- ## Terms This pack runs in your environment, on your data. Nothing is sent to Perform, and Perform receives no data from it at any point. It is provided free and as is, with no warranty of any kind. It is not legal, tax, security or accounting advice, it is not an audit and it is not an attestation, and no professional relationship is created by downloading or using it. You are responsible for reviewing it before you run it, and for any decision you make with its output. Anything you point this at should be treated as untrusted input. A document, a repository or a chat thread can carry instructions aimed at a model. Licensed under Apache-2.0, which includes a disclaimer of warranties and a limitation of liability. Version 1.0, 28 August 2026. Security contact: privacy@totalperform.com, acknowledged within five business days.