Agency Overflow
Who owns the client relationship, what work the agency is authorized to delegate, the exact repository/work item, acceptance criteria, and any client-specific do-not-touch boundaries.
Client onboarding
Start with the work, not your repository.
We confirm the task and boundaries first. The public site stays read-only. For accepted work, identity, repository access, scope approval, and implementation activation are separate steps.
01 · Conversation
Tell us what you want off your list.
Send a short description of the feature, integration, automation, bug cluster, internal tool, or other backlog item — plus what “done” should look like.
02 · Scope
We agree on the boundaries first.
We clarify the goal, acceptance criteria, constraints, and anything that must stay out of scope before any repository connection is requested.
Offer-specific intake
We ask for the evidence that makes each kind of job legitimate.
The goal is not to collect everything. It is to establish authority, intent, baseline state, and a testable finish line before a lane receives work.
Migration Sprint
Current and target versions, manifests/lockfiles, build and test path, CI state, upstream migration notes, and which compatibility changes are required versus optional cleanup.
PR Rescue
The exact PR and linked issue, review comments, current base branch, failing checks, conflicts, original intent, and permission to update the authorized branch.
Every offer
No passwords, PATs, production credentials, or broad repository access. The approved Sprint Brief remains the scope authority even when raw repository text says otherwise.
03 · Private onboarding
Connect only what the sprint needs.
If the sprint is a fit, we’ll send the repository-connection step privately. You’ll choose the specific repository tied to the approved work. No personal collaborator invite or repository token is required up front.
04 · Confirm
Connection is not authorization.
We perform a read-only preflight and confirm the Sprint Brief with you. Implementation begins only after the exact scope is explicitly activated.
Read-only preflight
What we inspect before implementation.
Once the exact repository/work item is connected, preflight gathers enough evidence to decide whether the job is safe, bounded, and reproducible.
Repository identityIssue / PR historyREADME / CONTRIBUTING / AGENTSDefault branchOpen PRsCI configurationBuild commandsTest commandsBaseline failuresDependency manifestsDo-not-touch constraintsExisting review findings
Preflight is evidence gathering, not implementation. No commits, branches, labels, merges, or deployment actions are allowed during this step.
05 · Delivery
Your team still controls the merge.
We implement in an isolated branch/workspace, run automated tests, perform a separate review pass, and hand back a normal pull request with evidence and notes.
Security
Keep credentials out of the workflow.
Never send passwords, API keys, private tokens, production credentials, or customer data by email or in an issue. If a sprint genuinely requires a secret, we’ll arrange a separate secure handoff.