| name | repo-intake |
| description | Use when starting from an unfamiliar repository or GitHub URL and you need a fast performance-focused intake: how to run it, where the user-facing surfaces are, which endpoint is best to optimize, and what the next agents need. |
Repo Intake
Turn an unknown repo into an actionable performance job.
Optimize for speed and downstream clarity, not completeness. The point is to give the instrumenter, planner, and engineers a shared target fast.
Deliverables
- Working install, run, and test commands
- The best candidate endpoint or workflow to optimize
- Likely hot-path files and dependencies
- Instrumentation entry points
- A short risk list for anything that may block the demo
Workflow
- Normalize the input.
Accept either a local path or a GitHub URL. Identify the app root, package manager, lockfiles, Docker files, and CI hints.
- Prove the app can run, or say exactly why it cannot.
Capture the smallest command set needed to install and start the app locally.
- Map the real surfaces.
Find HTTP routes, API handlers, background jobs, database access, cache calls, and outbound network calls.
- Pick one optimization target.
Prefer the endpoint or workflow that is easy to demo, latency-sensitive, and likely to show a meaningful before/after.
- Prepare the handoff.
Keep it crisp enough that another agent can start work without re-reading the repo.
Handoff Format
- Repo summary: stack, framework, and where the app starts
- Commands: install, run, test, and benchmark entrypoint
- Target: exact endpoint or workflow, plus why it is the best demo target
- Code map: the few files most likely to matter
- Instrumentation hooks: where request and child spans should be added
- Risks: missing env vars, flaky setup, or unclear ownership
Guardrails
- Prefer one strong target over a long list of maybe-targets.
- Do not refactor during intake.
- If the repo is broken, still produce the cleanest possible path forward.
- Separate facts from guesses.
