Service Extraction Candidate Scoring Prompt

This prompt is for architects and engineering leads who need to prioritize monolith modules for extraction into separate services. It is designed for the planning phase of a modernization or microservice migration initiative, after you have identified candidate modules but before you commit to an extraction sequence. The prompt forces structured reasoning across multiple dimensions including business criticality, change frequency, team readiness, coupling isolation, and risk level. Use this when you have a list of candidate modules and need a defensible, scored extraction order that accounts for dependency constraints.

The ideal user has already completed a domain analysis or bounded context discovery exercise and has a concrete list of modules with known dependencies. You should have data on each module's change frequency from version control history, business criticality from stakeholder interviews, and coupling characteristics from static analysis or architecture review. The prompt works best when you can populate the [MODULE_LIST] placeholder with structured data including module names, dependency lists, and known risk factors. Without this data, the model will generate plausible but ungrounded scores that could lead to a flawed extraction sequence.

Do not use this prompt for greenfield service design, for evaluating services that already exist, or when you lack sufficient data about module boundaries and dependencies. It is not a replacement for a bounded context discovery workshop or a domain-driven design review. The prompt produces a scored ranking, not a detailed migration plan—for that, use the Strangler Fig Migration Step Planning Prompt. If your primary concern is detecting distributed monolith risks in an existing decomposition plan, use the Distributed Monolith Risk Detection Prompt instead. Always review the output with the team that will own the extracted services, as team readiness and organizational constraints may override the model's scoring.

The prompt below is designed to be copied directly into your AI harness, IDE, or orchestration layer. Every square-bracket placeholder must be replaced with your actual data before sending the prompt to the model. The template expects a structured description of your monolith modules, the scoring criteria you care about, and the output format you need. Do not leave any placeholder unresolved—doing so will produce unreliable rankings or hallucinated module names.

textCopy
You are a senior software architect evaluating a monolith for service extraction. Your task is to score each candidate module against the provided criteria and produce a ranked extraction sequence with dependency ordering constraints.

## INPUT MODULES
[MODULE_LIST]

## SCORING CRITERIA
Score each module from 1 (low) to 5 (high) on the following dimensions. Provide a one-sentence justification for each score.

1. **Business Criticality**: How critical is this module to revenue, user experience, or core business operations? Higher criticality means extraction risk is higher, but isolation benefit may also be higher.
2. **Change Frequency**: How often does this module change relative to the rest of the system? High-change modules benefit more from independent deployability.
3. **Coupling Isolation**: How cleanly can this module be separated? Consider database dependencies, shared libraries, in-process calls, and implicit contracts. High isolation means lower extraction cost.
4. **Team Readiness**: Does a dedicated team with domain expertise exist for this module? High readiness reduces post-extraction ownership risk.
5. **Extraction Risk**: How likely is extraction to cause production incidents, data inconsistencies, or performance regressions? Lower risk means safer to extract early.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "scored_candidates": [
    {
      "module_name": "string",
      "scores": {
        "business_criticality": { "value": number, "justification": "string" },
        "change_frequency": { "value": number, "justification": "string" },
        "coupling_isolation": { "value": number, "justification": "string" },
        "team_readiness": { "value": number, "justification": "string" },
        "extraction_risk": { "value": number, "justification": "string" }
      },
      "composite_score": number,
      "extraction_order": number,
      "prerequisites": ["string"]
    }
  ],
  "extraction_phases": [
    {
      "phase": number,
      "modules": ["string"],
      "rationale": "string",
      "dependency_gate": "string"
    }
  ],
  "high_risk_items": [
    {
      "module_name": "string",
      "risk_description": "string",
      "mitigation": "string"
    }
  ]
}

## INSTRUCTIONS
- Score every module in [MODULE_LIST] against all five criteria.
- Compute composite_score as the weighted average: (business_criticality * 0.15) + (change_frequency * 0.25) + (coupling_isolation * 0.30) + (team_readiness * 0.15) + ((6 - extraction_risk) * 0.15). Invert extraction_risk so that lower risk yields a higher contribution.
- Assign extraction_order starting from 1, respecting dependency prerequisites. A module cannot be extracted before its prerequisites.
- Group modules into extraction_phases where all modules in a phase can be extracted in parallel without violating dependencies.
- Flag any module with extraction_risk >= 4 or coupling_isolation <= 2 in high_risk_items with specific mitigation recommendations.
- If [CONSTRAINTS] specifies a maximum phase size, do not exceed it.
- Do not invent modules. Only score modules present in [MODULE_LIST].

To adapt this template, replace [MODULE_LIST] with a structured description of each candidate module—include the module name, its primary responsibility, known dependencies, database ownership, and the team currently maintaining it. Replace [CONSTRAINTS] with any organization-specific rules such as maximum modules per phase, regulatory boundaries that cannot be crossed, or modules that must be extracted together. If you have no additional constraints, replace [CONSTRAINTS] with the string "None". The weighted scoring formula in the instructions can be adjusted by modifying the coefficients to match your organization's priorities—for example, increase coupling_isolation weight if your primary goal is avoiding distributed monoliths. Before running this prompt in production, validate the output against your actual module inventory to catch hallucinations, and run a dependency graph check to ensure the extraction order does not violate known prerequisites.

The Service Extraction Candidate Scoring Prompt is designed to be called from an application or CI/CD pipeline, not just used in a chat interface. The prompt expects a structured input payload containing the monolith module inventory, coupling data, business criticality ratings, team readiness scores, and change frequency metrics. The application layer is responsible for assembling this context from internal systems (code analysis tools, issue trackers, deployment logs, team surveys) before invoking the model. The prompt returns a scored and ranked JSON array, which the harness must validate before the results are presented to architects or fed into downstream planning tools.

API call structure: Use a standard chat completions endpoint with response_format set to json_object (or the equivalent structured output mode for your model provider). The system message contains the full prompt template. The user message contains the serialized [MODULE_DATA] array and [CONSTRAINTS] object. Set temperature to 0.1 or lower to minimize ranking instability across runs. Validation layer: After receiving the response, validate the JSON against a schema that checks: (1) every module in the input appears exactly once in the output, (2) all scores are integers within the defined ranges, (3) the extraction_sequence field respects dependency_constraints (no module appears before its dependencies), and (4) no duplicate rank values exist. If validation fails, retry once with the validation errors appended to the user message as [CORRECTION_FEEDBACK]. If the second attempt also fails, log the failure and route to a human review queue rather than silently accepting a malformed ranking.

Retry and fallback logic: Implement a two-strike retry policy. First failure: append the schema violation details and re-invoke. Second failure: escalate. Do not loop beyond two retries, as repeated failures often indicate a fundamental input quality problem (missing coupling data, contradictory constraints) that the model cannot resolve. Human review gate: Even when validation passes, flag outputs for human review when: (1) the top-ranked candidate has a composite score below a configurable threshold (suggesting no extraction is clearly justified), (2) any two candidates have scores within 5% of each other at rank boundaries (indicating ranking ambiguity), or (3) the risk_level for the top candidate is high. These gates prevent the team from acting on low-confidence or high-risk recommendations without architect oversight. Logging: Record the full prompt, response, validation result, scores, and reviewer decision for auditability. This trace is essential for retrospective analysis when extraction outcomes differ from predictions.

Model choice: This prompt benefits from models with strong reasoning and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Avoid smaller or older models that may struggle with the multi-criteria ranking and dependency ordering constraints. Tool use and RAG: This prompt does not require tool calling or retrieval-augmented generation. All necessary data must be assembled by the application before invocation. If your module inventory is too large for a single context window, batch the modules into groups of 20-30, score each batch independently, then run a second merge-and-rank pass with the batch summaries. Next step: After the harness produces a validated, human-reviewed ranking, feed the top candidates into the Strangler Fig Migration Step Planning Prompt to generate the actual extraction sequence with proxy points and rollback gates.