---
name: configuration-inventory
description: Generate comprehensive configuration and externalized settings inventory
---

# Configuration & Externalized Settings Inventory

Analyze the project to produce a comprehensive inventory of all configuration sources, build profiles, runtime profiles, externalized properties, secrets workflows, feature flags, startup dependencies, and framework versions. Save to `.github/modernize/assessment/engines/facts/configuration-inventory.md`.

> Note: This skill produces a comprehensive reference document. For structured findings suitable for automated processing, see `fact-profile-settings`, `fact-environment-variables`, and `fact-xml-configs`.

## Input Parameters

- `workspace-path` (optional): Path to the project to analyze (defaults to current directory)

## Scope Boundaries — Avoid Redundancy with Other Skills

This skill is part of a set of four complementary assessment skills. To avoid content duplication across their output documents, observe these scope rules:

- **Introduction**: Write a 1-2 sentence intro focused on the configuration landscape (number of config sources, profiles, secrets approach). Do NOT restate the application's architecture type, business domain, or API surface.
- **Database architecture details** (entity models, ER diagrams, ORM mappings, caching strategy rationale, repository methods) are owned by the `data-architecture` skill. In the Properties Inventory, list database-related property keys and values as raw configuration entries, but do NOT explain their behavioral implications (e.g., do not explain what `spring.jpa.open-in-view=false` means for lazy loading — that belongs in `data-architecture.md`).
- **API endpoints** are owned by the `api-service-contracts` skill. Do NOT list HTTP endpoints, controller routes, or actuator paths.
- **Business workflows and validation rules** are owned by the `business-workflows` skill. Do NOT describe business processes or entity validation constraints.
- **Entity/domain model listings** are owned by `data-architecture` and `business-workflows`. Do NOT enumerate entity names, fields, or relationships.

## Execution Steps

### Step 1: Generate Configuration Sources Section

Identify all configuration files and sources and produce the complete `## Configuration Sources` section:

- Java (Spring): `application.properties`, `application.yml`, `bootstrap.properties`, `bootstrap.yml` — note that `bootstrap.*` files are distinct from `application.*` (bootstrap configures the config server connection and runs before application context; application configures the app itself)
- .NET: `appsettings.json`, `appsettings.{Environment}.json`, `web.config`, `launchSettings.json`
- JavaScript/TypeScript: `.env`, `.env.local`, `.env.production`, `config/*.js`, `config/*.ts`
- Shared: `docker-compose.yml` environment sections, Kubernetes ConfigMaps/Secrets YAML files
- Config server references: Spring Cloud Config (note the external Git repository URI), Azure App Configuration, AWS AppConfig, Consul KV
- Secret stores: HashiCorp Vault, Azure KeyVault, AWS Secrets Manager references
- External configuration repositories: document the URI/path of any external config repos (e.g., `spring.cloud.config.server.git.uri`)

### Step 2: Generate Build Profiles Section

Identify build-time profiles that affect compilation, packaging, and dependency resolution, and produce the complete `## Build Profiles` section:

- **Java/Maven**: profiles in `pom.xml` (e.g., `springboot`, `buildDocker`, `dev`, `cloud`) — for each, document activation condition (auto, manual `-P`, system property `-Denv=`), purpose, and key dependencies or plugins added
- **Java/Gradle**: build types and flavors in `build.gradle`
- **.NET**: build configurations (Debug, Release), conditional compilation symbols, MSBuild properties
- **JavaScript/TypeScript**: build scripts in `package.json`, webpack/vite/esbuild configurations per environment

For each build profile extract:
- Profile name
- Activation condition (automatic, manual flag, system property, environment variable)
- Purpose (what it enables)
- Key dependencies or plugins added/removed

### Step 3: Generate Runtime Profiles Section

List all runtime profile-specific or environment-specific configuration and produce the complete `## Runtime Profiles` section:

- Java (Spring): Profile-specific files (`application-dev.yml`, `application-prod.yml`), `@Profile` annotations, `spring.profiles.active` settings, combined profile activation (e.g., `mysql,key-vault`)
- .NET: Environment-specific files (`appsettings.Development.json`, `appsettings.Production.json`), `ASPNETCORE_ENVIRONMENT` usage
- JavaScript/TypeScript: `.env.development`, `.env.production`, NODE_ENV-based branching
- Identify profile activation conditions, defaults, and how profiles compose (multiple active profiles)

### Step 4: Generate Properties Inventory Section

For each service/module, catalog all configuration properties and produce the complete `## Properties Inventory` section:

- Property keys with their default values
- Which profiles/environments override each property
- Data types and expected value ranges (where inferable)
- Properties sourced from environment variables (`${ENV_VAR}`, `%ENV_VAR%`)
- Placeholder references and property resolution chain

> Do NOT include JVM startup parameters, `-Xms`/`-Xmx` heap settings, `-D` system properties, container memory/CPU limits, or instance counts here — those belong in the `## Startup Parameters & Resource Requirements` section (Step 5).

### Step 5: Generate Startup Parameters & Resource Requirements Section

Document JVM startup options, runtime parameters, and per-service resource allocations, and produce the complete `## Startup Parameters & Resource Requirements` section:

- JVM heap settings (`-Xms`, `-Xmx`) per service
- System properties passed at startup (`-Dspring.profiles.active=`, `-Dazure.keyvault.uri=`, etc.)
- Docker/container environment variable overrides (`SPRING_PROFILES_ACTIVE`, `ASPNETCORE_ENVIRONMENT`)
- Memory allocation per service (Docker `mem_limit`, Kubernetes `resources.requests/limits`, cloud deployment settings)
- CPU allocation if specified
- Instance count and scaling configuration
- JVM heap settings mapped to service memory allocation (e.g., `-Xms2048m -Xmx2048m` for 2Gi services)

### Step 6: Generate Startup Dependency Chain Section

Map the service startup order and readiness dependencies and produce the complete `## Startup Dependency Chain` section:

- Which services must start before others (e.g., config-server → discovery-server → business services → gateway)
- Health-check/wait mechanisms: `dockerize` wait-for-TCP, Kubernetes readiness probes, Spring Cloud Config retry, Docker Compose `depends_on` with health checks
- Startup timeout configurations
- Service readiness indicators (actuator health endpoints, custom health checks)

### Step 7: Generate Secrets & Sensitive Configuration Section

Flag sensitive configuration entries and document the secrets provisioning workflow, and produce the complete `## Secrets & Sensitive Configuration` section (including the `### Secrets Provisioning Workflow` subsection):

- Database passwords, API keys, connection strings with credentials
- Secret references: KeyVault URIs, Vault paths, encrypted property values
- Entries marked as sensitive by framework conventions (e.g., `spring.datasource.password`)
- **Do NOT output actual secret values** — show the reference path or "[MASKED]" placeholder
- Note encryption methods if present (Jasypt, DPAPI, sealed secrets)

Document how secrets flow through the system (`### Secrets Provisioning Workflow`):
- Secret source: environment variables, Key Vault, Vault, AWS Secrets Manager, sealed secrets
- Identity/access model: managed identities, service principals, RBAC permissions (e.g., "system-assigned managed identity with `get` and `list` permissions on Key Vault")
- Provisioning sequence: how secrets are set up during deployment (e.g., GitHub Actions retrieves service principal credentials → authenticates → creates MySQL secrets → binds to services)
- Which services need which secrets (e.g., data services need MySQL connection strings, all services need config server credentials)

### Step 8: Generate Feature Flags Section

Identify feature toggles and conditional configuration and produce the complete `## Feature Flags` section:

- Feature flag frameworks: Spring Feature Flags, LaunchDarkly, Unleash, .NET FeatureManagement, custom toggles
- Conditional beans/services (`@ConditionalOnProperty`, `@ConditionalOnExpression`)
- A/B testing flags and gradual rollout configurations
- Default values and controlling sources (config file, environment variable, remote service)

### Step 9: Generate Framework & Runtime Versions Section

Catalog the technology stack versions that affect configuration and produce the complete `## Framework & Runtime Versions` section:

- Core framework versions: Spring Boot, Spring Cloud, ASP.NET Core, Node.js, Express
- Target language/runtime version: Java 8/11/17/21, .NET 6/7/8, Node.js 18/20
- Key library versions: Hibernate, EF Core, Resilience4j, Eureka, etc.
- Docker base images and their versions (e.g., `openjdk:11-jre`, `mcr.microsoft.com/dotnet/aspnet:8.0`)
- Build tool versions: Maven, Gradle, MSBuild, npm/yarn/pnpm

### Step 10: Save Output

Save to `.github/modernize/assessment/engines/facts/configuration-inventory.md` with this exact structure:

```
# Configuration & Externalized Settings Inventory

A brief introduction (1-2 sentences) summarizing the configuration landscape.

## Configuration Sources

[Table: Source | Type | Path/Location | Notes]

## Build Profiles

[Table: Profile | Activation | Purpose | Key Dependencies/Plugins]

## Runtime Profiles

[Table: Profile | Activation Method | Config Files | Key Overrides]

## Properties Inventory

[Per-service tables: Property Key | Default | Profiles | Source]

## Startup Parameters & Resource Requirements

[Table: Service | JVM/Runtime Options | Memory | Instance Count]

## Startup Dependency Chain

[Ordered list: Service → waits for → Service, with mechanism (dockerize, health check, etc.)]

## Secrets & Sensitive Configuration

[Table: Secret Reference | Type | Storage (masked)]

### Secrets Provisioning Workflow

[Description of how secrets flow: source → identity/access → binding → services]

## Feature Flags

[Table: Flag Name | Default | Controlled By]

## Framework & Runtime Versions

[Table: Component | Version | Source]
```

## Scaling Rules

- If the project has **more than 100 properties**, group by category (database, messaging, security, etc.) and show representative examples with counts
- For multi-module projects, organize the properties inventory by module/service
- Collapse repetitive property patterns (e.g., 20 similar cache TTL settings) into a summary row with count

## Error Handling

- **Unsupported project type**: Output a single line: `> ERROR: Unsupported project type. This skill supports Java, .NET, JavaScript, and TypeScript projects only.`
- **No configuration files found**: Output: `> ERROR: No recognized configuration files found at {workspace-path}. Verify the path is correct.`
- **Insufficient info**: Generate a best-effort inventory from available data. Add a note: `> Note: Some configuration sources or properties could not be fully identified.`

## Success Criteria

- Configuration sources table lists all discovered config files, external config repos, and secret stores
- Build profiles are documented separately from runtime profiles with activation conditions and purposes
- Runtime profiles are documented with config files and key overrides
- Properties inventory covers all discovered properties with defaults and sources
- Startup parameters and resource requirements are documented per service
- Startup dependency chain shows service boot order with wait mechanisms
- Secrets are identified with references (no actual values exposed) and the provisioning workflow is described
- Feature flags are cataloged with defaults and controlling sources
- Framework and runtime versions are documented
- File saved to `.github/modernize/assessment/engines/facts/configuration-inventory.md`