Dependency Injection Misuse Detection Prompt

This prompt is designed for platform engineers and software architects who need an automated first pass at auditing dependency injection (DI) container usage across a codebase. The primary job-to-be-done is to identify structural anti-patterns—such as the service locator pattern, direct resolution of concrete classes, and missing interface bindings—that undermine the testability, maintainability, and loose coupling that DI containers are meant to provide. The ideal user is someone responsible for architecture governance who wants to catch these violations before they become entrenched, either as part of a CI/CD pipeline or a pre-refactor analysis sprint.

To use this prompt effectively, you must provide a structured set of DI configuration files, module registration code, and class resolution call sites as the [INPUT]. The prompt works best when the input is scoped to a single DI container's configuration and its consumer code, rather than an entire monorepo at once. It is not a general-purpose code quality scanner; it will not detect logic bugs, performance issues, or security vulnerabilities. It is also not a replacement for a human architect's judgment—it will flag potential violations, but it cannot understand nuanced architectural intent, such as when a service locator is intentionally used as a bridge in a legacy migration or when a concrete class resolution is an accepted framework convention.

After running this prompt, you should expect a structured violation report that you can feed into a human review queue or an automated governance gate. The next step is to have an architect triage the findings, dismiss false positives, and create refactoring tasks for confirmed violations. Avoid using this prompt on codebases that do not use a formal DI container, as it will produce meaningless results. For high-risk or regulated systems, always require human review of the output before accepting any automated refactoring suggestions.

This prompt template is designed to analyze code for common dependency injection anti-patterns, including service locator misuse, concrete class resolution, missing interface bindings, and container configuration errors. Replace each square-bracket placeholder with your specific context before sending to the model. The template includes structured output requirements and evaluation criteria to distinguish genuine misuse from framework conventions or intentional patterns.

codeCopy
You are a dependency injection auditor reviewing code for DI container misuse. Analyze the provided code and configuration against established DI principles and patterns.

[CODE_SNIPPETS]

[DI_CONTAINER_CONFIG]

[FRAMEWORK_CONTEXT]

Analyze the code for the following anti-patterns:

1. **Service Locator Pattern**: Code that resolves dependencies from a container directly rather than receiving them through constructor injection, property injection, or method injection.
2. **Concrete Class Resolution**: Direct instantiation or resolution of concrete classes instead of their interface abstractions.
3. **Missing Interface Bindings**: Interfaces used as constructor dependencies without corresponding container registrations.
4. **Container-Aware Code**: Application code that references the DI container directly outside of composition root.
5. **Scoping Violations**: Dependencies registered with incorrect lifetimes (e.g., scoped service injected into singleton).
6. **Ambiguous Resolution**: Multiple registrations for the same interface without explicit resolution rules.
7. **Property Injection Abuse**: Required dependencies injected via optional property injection instead of constructor injection.

For each violation found, provide:
- **Location**: File path and line number or method name
- **Violation Type**: Which anti-pattern from the list above
- **Severity**: [CRITICAL], [HIGH], [MEDIUM], or [LOW]
- **Evidence**: The specific code or configuration that demonstrates the violation
- **Impact**: What can go wrong (testability, maintainability, runtime errors)
- **Remediation**: Specific refactoring guidance

[OUTPUT_SCHEMA]

Return results as a JSON object with this structure:
{
  "analysis_summary": {
    "total_violations": number,
    "critical_count": number,
    "high_count": number,
    "medium_count": number,
    "low_count": number,
    "files_analyzed": number,
    "framework_conventions_noted": ["string"]
  },
  "violations": [
    {
      "id": "string",
      "location": "string",
      "violation_type": "string",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "evidence": "string",
      "impact": "string",
      "remediation": "string",
      "is_false_positive_risk": boolean,
      "false_positive_rationale": "string | null"
    }
  ],
  "composition_root_review": {
    "location_found": "string | null",
    "issues": ["string"],
    "recommendations": ["string"]
  },
  "framework_specific_notes": ["string"]
}

[CONSTRAINTS]

- Do not flag framework bootstrapping code in the composition root as service locator misuse.
- Do not flag factory pattern implementations that legitimately resolve from the container.
- Do not flag test code that uses the container for test fixture setup.
- Distinguish between intentional property injection for optional dependencies and abuse for required dependencies.
- If the framework convention requires a specific pattern (e.g., controller activation in ASP.NET Core), note it as a framework convention, not a violation.
- Flag any business logic or domain code that references the container as [CRITICAL].
- Flag scoping violations that could cause runtime errors as [CRITICAL].

[EXAMPLES]

Example violation:
{
  "id": "VIOL-001",
  "location": "src/services/OrderService.cs:23",
  "violation_type": "Service Locator Pattern",
  "severity": "CRITICAL",
  "evidence": "var paymentProcessor = container.Resolve<IPaymentProcessor>();",
  "impact": "Hides dependency from constructor, making testing difficult and obscuring class contracts.",
  "remediation": "Add IPaymentProcessor as a constructor parameter and let the container inject it.",
  "is_false_positive_risk": false,
  "false_positive_rationale": null
}

Example framework convention note:
{
  "framework_specific_notes": [
    "Startup.cs uses IServiceCollection directly, which is the expected composition root pattern for ASP.NET Core."
  ]
}

[RISK_LEVEL]

This analysis may identify patterns that appear to be violations but are actually framework conventions or intentional design decisions. Always review [CRITICAL] and [HIGH] findings with the development team before taking action. Framework-specific patterns should be documented as conventions, not violations.

Adaptation guidance: Replace [CODE_SNIPPETS] with the actual code files or methods you want analyzed. Include enough context for the model to trace dependency chains. Replace [DI_CONTAINER_CONFIG] with your container registration code, startup configuration, or module wiring. Replace [FRAMEWORK_CONTEXT] with the DI framework name and version (e.g., "Microsoft.Extensions.DependencyInjection 8.0", "Autofac 7.0", "Spring Boot 3.2"). The [OUTPUT_SCHEMA] section is already populated with a recommended JSON structure, but you can replace it with your own schema if your tooling requires a different format. The [CONSTRAINTS] section includes framework-aware rules; add or remove constraints based on your team's specific conventions and the DI framework in use. The [EXAMPLES] section provides one-shot guidance; consider adding framework-specific examples from your own codebase for better accuracy. The [RISK_LEVEL] note reminds reviewers that automated detection requires human judgment for final classification.

Next steps: After copying this template, test it against a known-clean codebase to establish a baseline for false positives. Run it against code with known violations to verify detection accuracy. Integrate the JSON output into your CI pipeline with a severity threshold that blocks builds on [CRITICAL] findings. Schedule periodic re-analysis as the codebase evolves, and maintain a suppression list for intentional patterns that the prompt should not flag.

Integrating the Dependency Injection Misuse Detection prompt into an application requires more than a single API call. The prompt is designed to be part of a deterministic harness that validates the model's output against a strict schema, retries on failure, and logs every result for auditability. The core workflow involves: (1) extracting the DI container configuration and relevant class files from the target repository, (2) assembling the prompt with the extracted source code and a defined output schema, (3) sending the request to a capable model, (4) validating the JSON response, and (5) surfacing violations in a review UI or CI check. This harness transforms an ad-hoc prompt into a repeatable engineering signal.

Start by building a validation layer that enforces the expected output schema before any result reaches a developer. The prompt instructs the model to return a JSON object with a violations array, where each violation must have file_path, line_number, violation_type (one of service_locator, concrete_resolution, missing_interface_binding, static_accessor), severity (error, warning, info), and description. Your harness should parse the response, validate each field's type and enum membership, and reject malformed outputs. If validation fails, implement a retry loop (maximum 2 retries) that feeds the raw response and validation errors back to the model with a repair instruction: 'The previous output failed schema validation. Return ONLY a valid JSON object matching the required schema.' This self-correction pattern resolves most format drift without human intervention. For high-risk codebases, add a human review gate that requires an architect to confirm error-severity violations before they are surfaced as blocking issues.

Model choice matters for this task. The prompt requires precise structural reasoning about code patterns, not creative generation. Use a model with strong code analysis capabilities and a large context window to accommodate multiple configuration files and class definitions. For periodic scanning of a repository, implement a pre-processing step that identifies DI configuration files (e.g., Startup.cs, Program.cs, services.yaml, decorators, module files) and extracts only the relevant registration blocks to stay within context limits. Store results in a violation database with fields for commit SHA, timestamp, file path, and violation fingerprint to track regressions over time. When integrating into CI/CD, run the check on changed files only and compare against the previous scan to flag new violations. Avoid running the full repository scan on every commit—the latency and cost are unnecessary when only a subset of files changed. Finally, log every prompt version, model version, raw response, and validation outcome so that false positives can be traced back to specific prompt or model behaviors.