Dependency Injection Convention Extraction Prompt Template

This prompt is for framework teams and platform engineers who need to standardize dependency injection (DI) patterns across a codebase. The job-to-be-done is extracting the actual DI conventions—injection styles, lifetime scopes, registration patterns, and resolution rules—from DI container configuration and constructor signatures, not from documentation that may be stale or aspirational. The ideal user is a senior developer or architect who understands DI concepts and needs to produce a reference document that reflects the codebase as it is, not as it was intended to be. Required context includes access to DI container configuration files (e.g., Startup.cs, Program.cs, module registries), constructor signatures across the codebase, and any custom DI abstractions or factories.

Do not use this prompt when the codebase has no centralized DI container or when injection is handled entirely by a framework with zero custom configuration. It is also inappropriate for codebases where DI is so inconsistent that no convention can be extracted—in that case, a convention definition prompt is needed first. This prompt assumes the codebase has enough DI usage to surface patterns; it will not invent conventions where none exist. For high-risk domains such as healthcare or finance, always pair the output with a human review step to verify that extracted lifetime scopes and resolution rules do not introduce thread-safety or resource-leak risks.

After running this prompt, you should have a structured DI conventions document with concrete examples and anti-patterns. The next step is to validate the output against a representative sample of constructor signatures and registration calls that were not included in the prompt context. If the extracted conventions fail to explain more than 10% of sampled injection sites, expand the context and re-run. Avoid treating the output as a prescriptive standard until the team has reviewed and ratified it against their actual intent.

This prompt template instructs an AI coding agent to analyze a repository's dependency injection (DI) configuration, constructor signatures, and registration code to produce a structured conventions document. The template is designed to be copied directly into your AI harness, with square-bracket placeholders that you replace with actual repository context, output schema requirements, and operational constraints before execution. The prompt forces the model to identify injection styles, lifetime scopes, registration patterns, resolution rules, and anti-patterns rather than generating generic DI documentation.

textCopy
You are a senior software engineer analyzing a codebase to document dependency injection conventions.

Analyze the provided repository context to extract all dependency injection patterns, conventions, and rules. Your output must be grounded in the actual code, configuration, and constructor signatures found in the context.

## INPUT
[REPOSITORY_CONTEXT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "injection_styles": [
    {
      "style": "constructor_injection | property_injection | method_injection | service_locator",
      "locations": ["file paths where this style is used"],
      "prevalence": "primary | secondary | deprecated",
      "examples": ["code snippets showing the pattern"],
      "framework": "library or framework enabling this style"
    }
  ],
  "lifetime_scopes": [
    {
      "scope": "singleton | scoped | transient | request",
      "registration_pattern": "how this scope is declared in configuration",
      "typical_use": "description of when this scope is applied",
      "examples": ["registration code examples"],
      "anti_patterns": ["misuses of this scope found in the codebase"]
    }
  ],
  "registration_conventions": {
    "assembly_scanning_rules": ["patterns for automatic registration"],
    "manual_registration_patterns": ["patterns for explicit registration"],
    "naming_conventions": "interface-to-implementation naming rules",
    "module_separation": "how registrations are split across modules or assemblies"
  },
  "resolution_rules": {
    "ambiguity_handling": "how multiple implementations of an interface are resolved",
    "conditional_registration": "environment or feature-based registration patterns",
    "decorator_patterns": "how decorators or interception are registered",
    "open_generics": "how open generic types are registered and resolved"
  },
  "anti_patterns_found": [
    {
      "pattern": "description of the anti-pattern",
      "locations": ["file paths"],
      "risk": "why this is problematic",
      "recommendation": "how to fix it"
    }
  ],
  "resolution_consistency_checks": {
    "missing_registrations": ["interfaces used in constructors but not found in DI configuration"],
    "scope_mismatches": ["dependencies with shorter lifetime injected into longer-lived services"],
    "circular_dependencies": ["detected circular dependency chains"],
    "unused_registrations": ["registered services never injected"]
  },
  "source_references": [
    {
      "finding": "what was found",
      "file": "source file path",
      "line_range": "approximate location"
    }
  ]
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## TOOLS
[TOOLS]

## RISK LEVEL
[RISK_LEVEL]

Before producing the final output, verify:
1. Every convention claim is backed by at least one source reference.
2. Constructor signatures are matched against DI registrations for completeness.
3. Scope validation checks are performed across the dependency graph.
4. Anti-patterns are flagged with specific locations, not general warnings.
5. If a pattern is absent from the codebase, explicitly state that rather than omitting the field.

To adapt this template, replace each placeholder with concrete values. [REPOSITORY_CONTEXT] should contain the DI container configuration files, service registration modules, constructor signatures from key classes, and any existing DI documentation. [CONSTRAINTS] should specify the DI framework in use (e.g., Microsoft.Extensions.DependencyInjection, Autofac, Guice, Dagger), the maximum depth for dependency graph traversal, and any organizational rules that override framework defaults. [EXAMPLES] should include one or two correctly formatted output samples showing the expected level of detail for injection styles and lifetime scopes. [TOOLS] should list any available functions for file reading, symbol search, or dependency graph analysis that the model can invoke. [RISK_LEVEL] should be set to high for production services where incorrect DI documentation could lead to runtime errors, requiring human review of the output before it is published to team documentation.

After copying and adapting the template, wire it into your application with a validation step that checks the output JSON against the schema before accepting it. Run a post-generation consistency check: for every constructor dependency found in the codebase, verify that a corresponding registration exists in the output's resolution_consistency_checks.missing_registrations field or is accounted for in the registration conventions. If the risk level is high, route the output to a human reviewer with a diff view showing which constructor signatures were analyzed and which registrations were matched. Do not publish the DI conventions document until the resolution consistency checks pass and a reviewer confirms that scope mismatches and circular dependencies are accurately flagged.

This prompt is designed to be run as a batch analysis step, not a real-time chat interaction. The primary integration point is a CI/CD pipeline or a scheduled documentation job that checks out the repository, assembles the required context files, and invokes the model. Treat the prompt output as a draft artifact that requires structural validation before it is committed to the team's architecture knowledge base or developer portal.

Input Assembly: The harness must collect the files referenced by the [DI_CONFIG_FILES], [SERVICE_REGISTRATION_FILES], and [CONSTRUCTOR_SIGNATURES] placeholders. Use a script to concatenate these files with clear file-path headers into a single [CODEBASE_CONTEXT] block. To stay within context windows, filter to files that import DI container libraries (e.g., inversify, tsyringe, Microsoft.Extensions.DependencyInjection, wire) or contain decorators like @Injectable(). Output Validation: Before accepting the model's response, validate the JSON structure against the [OUTPUT_SCHEMA]. A post-processing validator should check that every extracted injection_style (constructor, property, method) is backed by a concrete code reference in the source_locations array. Flag any lifetime_scope values that don't match the expected enum (Singleton, Transient, Scoped, Request) for human review. Retry Logic: If the output fails JSON schema validation, implement a single retry with the validation error message appended to the [CONSTRAINTS] block, instructing the model to fix the specific structural issue. If the retry also fails, surface the raw output and the errors to a documentation engineer via a pull request comment rather than silently discarding it.

Model Choice and Tool Use: This task requires strong code comprehension and structured output adherence. Use a model with first-class JSON mode or structured output support (e.g., GPT-4o, Claude 3.5 Sonnet). Do not enable web browsing or arbitrary code execution tools; the model should reason solely from the provided [CODEBASE_CONTEXT]. Human Review Gate: The final DI conventions document must not be published automatically. Open a pull request with the generated markdown document and the validation report. The review checklist should include: (1) Are the extracted conventions actually the team's agreed-upon standards, or just observed patterns? (2) Do any detected anti-patterns represent intentional technical debt that should be documented as exceptions? (3) Are there resolution consistency warnings that indicate real bugs? Only merge after a senior engineer on the framework team approves.