Analyze Repository

Produce a structured stack report for a repository by reading its manifest files. This is a deterministic, read-only procedure — do not guess, do not invoke language models against source code, and do not modify anything. Use file-reading tools available in the chat environment (read_file, file search, directory listing) to perform every step.

Inputs

If the user provided a modules[] array, skip detection and use it verbatim. Otherwise, run the full procedure.

Procedure

Step 1 — Walk the repository

• Start at repositoryPath, recurse to maximum depth 3.
• Skip these directory names at any depth: node_modules, .git, .vscode, .idea, dist, build, target, bin, obj.
• Cap total files scanned at 100. Stop once you reach this.
• Record a flat directory tree (first 30 entries) for context.

Step 2 — Identify config files

Match file basenames against this set (case-sensitive):

Read each match, truncate at 1000 characters, and remember the (path, content) pair.

Step 3 — Parse each config

Per file type, extract the following fields. If a field is absent, leave it unset — do not invent.

Step 4 — Group configs into modules

• Group parsed configs by directory of the config file.
• Each directory with ≥ 1 parsed config becomes one ModuleInfo with:
  • name = basename of directory
  • modulePath = absolute directory path (forward slashes)
  • language ∈ {java, dotnet, javascript, typescript, python, rust, go, other}
  • frameworks = [{ name, version? }]
  • buildSystems = list of { type, languageVersion? } (one per parsed config in the dir)
  • dependencies = combined dependency list (deduped)
  • ports, entryPoint
• isMonorepo = modules.length > 1.

Step 5 — Detect databases

Walk every module's dependencies[]. Lowercase each, then match:

Exact-name table (lowercased):

Pattern matches (regex on lowercased dep):

Each detected DB: { dbType, dependencies: [<names that matched>] }.

Step 6 — Detect environment variables

Walk this list for each module (using only config files in the module's directory or in the repo root for non-root modules):

a) .env.example / .env.sample / .env.template — line-based, safe even if truncated:

• Match ^([A-Za-z_][A-Za-z0-9_]*)(?:=(.*))?$. Skip blank lines and #.
• required = no = or empty value after =. Strip surrounding quotes from the value.

b) docker-compose.{yml,yaml} — parse as YAML; skip if truncated (truncation breaks YAML). For each service, read environment:

• List format - VAR=val or - VAR
• Map format VAR: val
• Same required rule.

c) application.properties / application.yml — extract ${VAR} / ${VAR:default} placeholders via regex. Each becomes one entry; defaultValue from the :default suffix if present.

d) Framework inference — append these based on (language, framework):

Classify each var by name (uppercased):

• secret — matches any of: DATABASE_URL$, CONNECTION_STRING$, equals REDIS_URL / MONGODB_URI / MONGO_URI; ends with _DSN or equals DSN; contains PASSWORD|PASSWD|TOKEN|SECRET|CREDENTIAL|API_KEY|PRIVATE_KEY|ACCESS_KEY; contains _AUTH_ / starts AUTH_ / ends _AUTH.
• database — starts with DB_, REDIS_, MONGO_, MYSQL_, PG_, POSTGRES_, MSSQL_, or DATABASE_.
• config — everything else.

Redact defaultValue for any var classified as secret — never surface credential-shaped defaults.

Deduplicate by name — keep the first occurrence (priority: explicit config files over framework inference).

Step 7 — Build the summary string

Template (mirror this exactly):

✅ Analyzed repository at <repositoryPath>. Detected <module description>.<monorepo clause><database clause><env clause> Ready for Dockerfile generation.

• <module description> — for 1 module: <language> project. For >1: N modules (<lang1>, <lang2>, ...).
• <monorepo clause> — Monorepo structure identified. if isMonorepo.
• <database clause> — Databases: <comma-separated dbTypes>. if any.
• <env clause> — N env var(s) detected. if any.

Step 8 — Output

Use the exact format in the next section.

Output format

Use these exact headings:

**Repository analysis** — `<repositoryPath>`

> <summary line from Step 7>

### Stack
- **Language:** <language> <languageVersion if present>
- **Framework:** <framework name + version, or "none detected">
- **Build system:** <buildSystem.type> (<languageVersion>)
- **Entry point:** <entryPoint or "not detected">

### Dependencies of note
- <up to 5 bullets — focus on items that affect the container:
  database drivers, native modules, gRPC/protobuf, web frameworks. Skip
  generic libraries like lodash, chalk, requests.>

### Databases detected
- <one bullet per detected DB: `<dbType>` (from `<dep1>, <dep2>`)> or "none"

### Environment variables to surface
- <up to 10 bullets: `<NAME>` *<classification>* (from `<source>`, required: <bool>)>
- ...and N more — <if list was truncated>

### Ports
- <comma-separated list, or "not detected">

### Structure
- <"Single project" OR "Monorepo with N modules:" then one bullet per module:
  `- <name> (<language>) — <modulePath>`>

### Recommended next step
<choose one:
 - "Run **generate-dockerfile** on `<modulePath>`."
 - "An existing Dockerfile was detected — run **fix-dockerfile** instead."
 - "This is a monorepo. Tell me which module to containerize first: <list>."
 - "No buildable project found — verify the path and retry.">

Constraints

• NEVER dump raw config file contents.
• NEVER invent fields. If a parser step yields nothing, write "not detected".
• NEVER recurse deeper than 3 levels or scan more than 100 files.
• NEVER report a defaultValue for a secret-classified env var.
• For a monorepo, list every module — never abbreviate.
• Target ≤ 25 lines of output for a single-module repo, ≤ 40 for a monorepo.
• If a section has no content, keep the header and write "none" / "not detected" — never omit a section.

Failure modes