Set up a new developer’s repositories interactively

Why use this

1. A new developer may need several repositories to agree on versions, configuration and local services before meaningful work begins. A setup script can appear to finish while one missing dependency leaves only part of the workspace usable.

2. This job could guide setup decisions and record the state of each repository with clear checkpoints. Making prerequisites and permission requests visible helps the developer understand what remains incomplete instead of receiving a blanket 'ready' claim.

Why an agent / simpler alternative

Useful judgment

Reconcile repository instructions, identify version conflicts and ask targeted questions when setup depends on local choices.

Simpler alternative

Follow a maintained onboarding guide manually when prerequisites are simple and consistent.

Unsuitable when

The workflow would install unapproved software, handle secrets in chat or modify unrelated system configuration.

Proposed inputs

1. Name

   Repository setup brief

   Owner

   Authorized maintainer

   Minimum scope

   Relevant repositories, branches and supported environment

   Quality check

   Verify ownership and current instructions

2. Name

   Local prerequisites inventory

   Owner

   Developer

   Minimum scope

   Required versions and available services without secrets

   Quality check

   Distinguish installed, missing and unverified components

Access and setup — proposed or unknown

Proposed minimum

1. Review fictional setup manifests and an interactive plan; no repository cloning, installation, credentials or commands.

Compatibility unknowns

1. Current OS support, dependency versions, service access and runtime compatibility are unknown.

External actions requiring approval

1. Software installation, account connections, credential creation and system/security changes require appropriate approval or handoff.

Expected deliverable and review checks

Proposed artifact

Onboarding-plan candidate with per-repository prerequisites, ordered checks and unresolved developer choices.

Critical checks

1. Scope changes to the selected workspace; keep secrets out of logs; distinguish completed setup steps from verified application behavior.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Two repositories require incompatible versions

   Why it matters

   One setup can silently break another

   Proposed response

   Identify the conflict and propose an approved isolation choice.

2. Signal

   A missing service is treated as optional

   Why it matters

   The workspace may fail on its first real task

   Proposed response

   Confirm its role and leave readiness unverified.

Effort and cost — unknown

Setup work

1. Map dependencies and environment boundaries.

Ongoing review

1. Developer reviews prompts and inspects later authorized setup/check evidence.

Unknowns

1. Dependency compatibility, access requirements, onboarding effort and service costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent frontend/backend/test manifests with a version conflict and missing service; draft an interactive setup sequence only.

Acceptance checks

1. Flag conflicts; ask needed choices; claim no configured workspace; execute nothing.

Stop conditions

1. Stop if instructions conflict or setup requires unapproved credentials or system access.

Limits

1. A setup plan cannot establish a working development environment, successful tests or secure credential handling.