M&A Technical Due Diligence

Overview

Technical due diligence on acquisition targets traditionally relies on CTO interviews, manual code sampling, and documentation review — covering less than 10% of the actual codebase. Critical risks hide in the 90% nobody reads: hardcoded secrets in utility modules, GPL dependencies buried three layers deep, PII flowing unencrypted through forgotten microservices. CoreStory changes this equation. By ingesting and semantically understanding the target’s entire codebase, it gives your diligence team an AI-powered analyst that can answer specific risk questions against the full codebase — not a sample. The agent operates as an Expert (explaining system behavior, architectural patterns, and data flows) and a Navigator (pointing to specific files, methods, and code paths where risks live). Who this is for: M&A professionals, PE portfolio teams, technical diligence consultants, and acquiring engineering teams evaluating technology-heavy acquisitions. What you’ll get: A structured workflow for interrogating a target codebase across four risk domains — technical debt, security, data/PII compliance, and integration complexity — producing auditable findings with specific file-level evidence.

Prerequisites

A CoreStory account with the target codebase ingested and ingestion complete
An AI coding agent with CoreStory MCP configured (see Supercharging AI Agents for setup)
Read access to the target’s repository (for the agent to cross-reference CoreStory findings against source)

How It Works

CoreStory MCP Tools Used

This playbook uses the following tools from the CoreStory MCP server:

Tool	Role in Diligence
`list_projects`	Identify and confirm the target project
`get_project_prd`	Retrieve the synthesized Product Requirements Document for business context
`get_project_techspec`	Retrieve the Technical Specification for architecture, data models, and security analysis
`create_conversation`	Open a named diligence thread for each audit workstream
`send_message`	Interrogate the codebase — the primary investigation tool
`rename_conversation`	Mark completed threads with “RESOLVED” prefix for audit trail
`list_conversations`	Review existing diligence threads
`get_conversation`	Retrieve conversation history for report synthesis

The Diligence Workflow

M&A technical diligence with CoreStory follows a four-phase pattern:

Setup — Confirm the target project, review synthesized specs for architectural orientation, and create named conversation threads for each workstream.
Interrogate — Use send_message to ask specific risk questions. CoreStory answers from semantic understanding of the full codebase, citing specific files and code paths.
Cross-reference — Validate critical findings against the actual source code. CoreStory provides the file paths and context; the agent (or your team) confirms.
Synthesize — Compile findings into structured reports. Conversation history provides the audit trail.

Expert Before Navigator

The “Expert before Navigator” principle is especially important in diligence. Before searching for specific vulnerabilities or code paths, first use CoreStory to understand how the system is designed to work — its intended architecture, data flow patterns, and security model. This baseline makes it far easier to spot deviations, shortcuts, and risks.

Step-by-Step Walkthrough

Phase 1: Project Setup and Orientation

Start every diligence engagement by confirming the target and building architectural context. Confirm the target project:

List my CoreStory projects. I need to identify the project for [TargetName].

The agent calls list_projects and returns your available projects. Confirm the correct project before proceeding — this is a critical safety step when multiple targets may be under evaluation simultaneously. Review synthesized specifications:

For project [project_id], retrieve the Technical Specification and Product Requirements Document.
Give me a high-level summary of:
1. System architecture (major components, services, data stores)
2. Technology stack (languages, frameworks, infrastructure)
3. External integrations and third-party dependencies
4. Data model overview

The agent calls get_project_techspec and get_project_prd to retrieve CoreStory’s synthesized understanding of the codebase. This gives you architectural orientation before diving into risk-specific queries. Create diligence threads:

Create a CoreStory conversation titled "[Diligence] TargetName - Technical Risk Audit".
Store the conversation_id — we'll use this thread for all risk-related queries.

Create separate conversation threads for each workstream (risk audit, integration planning, compliance audit). This keeps findings organized and produces clean audit trails.

Phase 2: Risk Interrogation

With architectural context established, use send_message to interrogate the codebase across risk domains. Each query goes through the conversation thread, and CoreStory draws on its semantic understanding of the entire codebase to answer. The key principle: Ask specific questions. “Tell me about security” produces vague answers. “Identify all code locations that handle authentication tokens and describe how they’re stored, transmitted, and rotated” produces actionable findings with file paths. The following sections provide query patterns organized by risk domain. Use the ones relevant to your diligence scope.

Technical Debt & Obsolescence

send_message: "List all services, modules, and frameworks running on end-of-life
or unsupported versions. For each, identify the current version in use, the latest
stable version, and whether the upgrade path has breaking changes."

send_message: "Identify areas of the codebase with high complexity or poor
separation of concerns — god classes, circular dependencies, modules with
excessive coupling. For each, provide the file path and a brief description
of the issue."

send_message: "Are there any modules or services that appear to be abandoned
or unmaintained — no recent commits, no test coverage, referenced but not
actively developed? List them with file paths."

Security & Secrets

send_message: "Identify all code locations that hardcode API keys, passwords,
tokens, or other secrets. For each, provide the file path, line context,
and what the secret appears to be used for."

send_message: "How is authentication handled across the system? Map the
authentication flow from login through session management. Identify whether
it follows standard patterns (OAuth 2.0, SAML, JWT) or uses custom logic."

send_message: "List all known CVEs or security vulnerabilities associated with
the third-party libraries and frameworks in use, sorted by severity."

Licensing & Open Source Risk

send_message: "Provide a complete bill of materials for all third-party and
open-source dependencies. Highlight any libraries with restrictive licenses
— GPL, AGPL, SSPL, or other copyleft licenses that could create obligations
for the acquiring entity."

send_message: "Are there any dependencies that are abandoned, archived,
or have known unpatched vulnerabilities? List them with the current version
in use and the last release date."

Data Handling & PII

send_message: "Map the data flow for customer onboarding. Show specifically
where PII (Personally Identifiable Information) is collected, transmitted,
stored, and whether it is encrypted at rest and in transit at each stage."

send_message: "Identify all database models or tables that store PII.
For each, list the fields, whether they are encrypted, and what access
controls exist."

send_message: "How is data deletion handled? Is there a mechanism for
'right to be forgotten' requests? Trace the deletion flow and identify
any places where PII might persist after a deletion request."

Architecture & Integration Complexity

send_message: "How does the system handle payment processing? Map the
integration with payment providers, showing all third-party dependencies,
API touchpoints, and where financial data flows."

send_message: "What message queues, event buses, or async communication
patterns are in use? Map the event flow between services and identify
any single points of failure."

send_message: "How is the system deployed? Describe the deployment
architecture, CI/CD pipeline, infrastructure dependencies, and any
vendor lock-in to specific cloud providers or services."

Phase 3: Cross-Reference and Validation

CoreStory provides findings with specific file paths and code context. For critical findings — especially security issues, licensing risks, and PII exposure — validate against the actual source code.

For the hardcoded secrets CoreStory identified:
Open each file path and confirm the finding
Check if there are environment variable alternatives that aren't being used
Assess whether these are production secrets or development/test placeholders

This cross-reference step is important because CoreStory’s analysis is based on its ingestion snapshot. If the target’s codebase has changed since ingestion, critical findings should be verified against the current state.

Phase 4: Synthesis and Reporting

After completing your interrogation queries, synthesize findings into structured reports. The conversation history serves as your evidence base.

Review our entire conversation history for the risk audit thread.
Synthesize all findings into a Technical Due Diligence Report with these sections:

1. Executive Summary — top 3-5 findings that materially affect deal risk or valuation
2. Critical Risks — security vulnerabilities, licensing exposure, PII compliance gaps
   (each with file-level evidence and severity rating)
3. Technical Debt — end-of-life dependencies, architectural issues, maintainability concerns
4. Architecture Overview — component map, technology stack, external dependencies
5. Integration Assessment — complexity of merging with acquirer's platform, friction points
6. Recommendations — remediation priorities and estimated effort for post-close planning

Mark completed threads:

Rename the conversation to "RESOLVED - [Diligence] TargetName - Technical Risk Audit".

This creates a searchable record. Future team members can use list_conversations and get_conversation to review the full diligence trail.

Advanced Workflows

The following end-to-end prompt templates combine the patterns above into complete diligence workflows. Each can be used as a single agent prompt or broken into phases.

Rapid Risk Audit

Scenario: A PE firm has one week to perform technical diligence on a target. The goal is to identify major risks and quantify technical debt for negotiation leverage. Timeline: 24–48 hours with CoreStory (vs. 2–4 weeks traditional).

Perform a rapid technical due diligence risk audit.

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm the project, retrieve the Technical Specification
  using get_project_techspec. Summarize the architecture, tech stack,
  and major components.

STEP 2: CREATE CONVERSATION
- Create a conversation titled "[Diligence] - [TargetName] - Risk Audit"
- Use this thread for all subsequent queries.

STEP 3: TECHNICAL DEBT
Use send_message to ask:
- "List all end-of-life or unsupported frameworks, languages, or
  platforms. For each, provide current version, latest version,
  and upgrade complexity."
- "Identify high-complexity modules with poor test coverage.
  Provide file paths and complexity indicators."

STEP 4: SECURITY
Use send_message to ask:
- "Identify all hardcoded API keys, passwords, or secrets.
  Provide file_path and line context for each."
- "List all known CVEs from third-party libraries, sorted by severity."
- "Map the authentication flow and identify any custom (non-standard)
  auth logic."

STEP 5: LICENSING
Use send_message to ask:
- "Provide a bill of materials for all third-party dependencies.
  Flag any with GPL, AGPL, or other copyleft licenses."

STEP 6: SYNTHESIZE
- Compile all findings into a "Technical Risk Report" with:
  Issue | Location (file path) | Severity | Impact
- Group by category: Security, Licensing, Technical Debt, Architecture.
- Highlight the top 5 deal-affecting findings.

Post-Merger Integration Planning

Scenario: The deal is closing. The acquiring engineering team needs an integration blueprint — what overlaps, what conflicts, and where the friction will be.

Create a post-merger integration blueprint for merging [TargetName]
with our [AcquiringPlatformName] platform.

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm, retrieve the Technical Specification and PRD.
- Summarize: architecture, data models, API surface, auth model.

STEP 2: CREATE CONVERSATION
- Create conversation titled "[PMI] - [TargetName] Integration Plan"

STEP 3: MAP ARCHITECTURE
Use send_message to ask:
- "Describe the complete system architecture — services, databases,
  message queues, caches, and external integrations. Include a
  component inventory."
- "Map all data models and their relationships. Identify the core
  domain entities and how they flow between services."

STEP 4: IDENTIFY INTEGRATION POINTS
Use send_message to ask:
- "How is customer authentication handled? Map the flow and compare
  to standard OAuth 2.0 / SAML patterns."
- "Map the data flow for customer onboarding, showing all databases
  and external APIs involved."
- "How does the system handle payment processing? What are the
  third-party dependencies?"
- "What APIs are exposed externally? Provide endpoint inventory
  with authentication requirements."

STEP 5: ASSESS FRICTION
Use send_message to ask:
- "What cloud provider or infrastructure dependencies exist?
  Identify any vendor lock-in."
- "What custom or non-standard patterns are used that would
  require significant adaptation during integration?"

STEP 6: SYNTHESIZE
- Create an "Integration Plan Summary" covering:
  1. Component inventory with integration complexity rating
  2. Data model overlaps and conflicts
  3. API surface that can be reused vs. must be rebuilt
  4. Auth and identity merge strategy
  5. High-friction areas requiring dedicated engineering effort
  6. Recommended integration sequence and timeline

Security & PII Compliance Audit

Scenario: The diligence team needs to verify the target’s data handling practices for GDPR, CCPA, or other regulatory compliance before close.

Perform a focused security and PII compliance audit on [TargetName].

STEP 1: PROJECT SETUP
- Call list_projects and show me the available projects.
- After I confirm, retrieve the Technical Specification.
- Summarize the security architecture and data handling patterns.

STEP 2: CREATE CONVERSATION
- Create conversation titled "[Audit] - [TargetName] - PII & Security"

STEP 3: MAP PII FLOWS
Use send_message to ask:
- "Map all data flows that handle PII — customer registration,
  profile updates, payment processing, support interactions.
  For each flow, show where PII is collected, transmitted, and stored."
- "Identify all database models or tables containing PII fields.
  For each field, state whether it is encrypted at rest."
- "Is PII encrypted in transit between services? Identify any
  internal service-to-service communication where PII travels
  unencrypted."

STEP 4: ASSESS COMPLIANCE MECHANISMS
Use send_message to ask:
- "How is data deletion handled? Is there a 'right to be forgotten'
  implementation? Trace the deletion flow and identify any places
  where PII persists after deletion."
- "What data retention policies are implemented in code? Are there
  automated expiration or purge mechanisms?"
- "Identify all external APIs or third-party services that receive PII.
  For each, describe what data is shared and whether data processing
  agreements would be required."

STEP 5: SECURITY POSTURE
Use send_message to ask:
- "Identify all hardcoded secrets — API keys, passwords, tokens,
  connection strings. Provide file paths."
- "How are secrets managed in production? Is there a secrets manager
  (Vault, AWS Secrets Manager, etc.) or are environment variables used?"
- "What input validation and sanitization patterns are used?
  Identify any endpoints that accept user input without validation."

STEP 6: SYNTHESIZE
- Generate a "PII & Security Compliance Report" covering:
  1. PII inventory — what data, where stored, encryption status
  2. Data flow map — collection through deletion lifecycle
  3. Compliance gaps — unencrypted PII, missing deletion flows,
     third-party data sharing without controls
  4. Security findings — hardcoded secrets, missing validation,
     auth vulnerabilities
  5. Remediation priorities with estimated effort
  6. Regulatory risk assessment (GDPR, CCPA applicability)

Prompting Patterns Reference

Investigation Patterns

Effective diligence queries are specific and evidence-oriented. They ask for file paths, concrete examples, and traceable findings — not summaries.

Pattern	Example
Enumerate with evidence	”List all hardcoded secrets. For each, provide the file path, line context, and what it’s used for.”
Trace a flow	”Map the data flow for customer onboarding from signup through account creation. Show every service, database write, and external API call.”
Compare to standard	”How is authentication handled? Compare the implementation to standard OAuth 2.0 patterns and identify deviations.”
Assess coverage	”What test coverage exists for the payment processing module? Identify critical paths with no test coverage.”
Find patterns	”Identify all locations where database queries are constructed from user input. Flag any that don’t use parameterized queries.”
Quantify scope	”How many external API integrations exist? For each, identify the provider, what data is exchanged, and whether there are retry/fallback mechanisms.”

Query Specificity

Vague queries produce vague answers. Always include specific anchors:

Instead of	Use
”Tell me about security"	"Identify all code locations that handle authentication tokens and describe how they’re stored, transmitted, and rotated"
"How’s the code quality?"	"Identify modules with circular dependencies, god classes over 500 lines, or methods with cyclomatic complexity above 15"
"Are there any risks?"	"List all third-party dependencies with known CVEs, sorted by severity, with the file that imports each one"
"How does data flow?"	"Trace the PII data flow for the customer registration process from HTTP request through database write, identifying encryption at each stage”

Multi-Query Threading

For thorough coverage, chain queries within a conversation thread. Each send_message builds on prior context:

Query 1: "Map the system architecture — services, databases, and external integrations."
Query 2: "For each external integration you identified, what data is exchanged
          and what happens if the external service is unavailable?"
Query 3: "Which of these external dependencies have SLA requirements,
          and are those SLAs enforced in code (circuit breakers, timeouts, retries)?"

The conversation accumulates context, so later queries can reference earlier findings without repeating them.

Best Practices

Create separate threads per workstream. Don’t mix security audit queries with integration planning queries. Separate conversations keep findings organized and make it easier to hand off specific workstreams to different team members. Start with the synthesized specs. Use get_project_techspec and get_project_prd before diving into send_message queries. The specs give you architectural vocabulary — service names, data model names, API endpoint patterns — that make your queries far more specific and productive. Ask for file paths, always. Every finding in a diligence report needs evidence. Train your queries to always request file paths and line context. “Identify X and provide the file path” should be your default pattern. Cross-reference critical findings. CoreStory’s analysis is based on its ingestion snapshot. For findings that materially affect deal terms — licensing poison pills, PII exposure, critical security vulnerabilities — always validate against the current source. Use conversation rename for audit trail. Rename completed threads with a “RESOLVED” prefix using rename_conversation. This creates a searchable record that survives team handoffs and can be referenced months later during post-merger integration. Scope your queries to avoid noise. A query like “find all security issues” will return an overwhelming response. Break it into targeted categories: hardcoded secrets, authentication flow, input validation, dependency vulnerabilities. Each produces focused, actionable findings.

Agent Implementation Guides

The skill file shown below is plain markdown. The workflow it encodes works in any agentic harness — only the install location differs. Common conventions:

Harness	Install location
Claude Code	`.claude/skills/<skill-name>/SKILL.md` — Claude loads the body when the YAML `description` matches the task
GitHub Copilot	Append to `.github/copilot-instructions.md` for repo-wide instructions, or save as `.github/instructions/<name>.instructions.md` with an `applyTo` glob for path-scoped use
Cursor	`.cursor/rules/<skill-name>.mdc` with a `description` field for auto-attach (use `globs` for path-scoped or `alwaysApply: true` for every session)
Factory.ai	`.factory/droids/<skill-name>.md` (project) or `~/.factory/droids/<skill-name>.md` (personal); Factory loads it as a custom Droid
Aider	`CONVENTIONS.md` at repo root, loaded with `aider --read CONVENTIONS.md` — or add it to the `read:` list in `.aider.conf.yml` for automatic loading
Codex / `AGENTS.md` harnesses	Append the content to `AGENTS.md` at your repository root
Custom runtime	Load the markdown into your agent’s system prompt, rules file, or wherever it consumes workflow context

Want a single install that works across the most harnesses? Append the content to AGENTS.md at your repository root. The AGENTS.md spec is read by Codex, Aider, Cursor, Factory, Jules, Gemini CLI, Windsurf, GitHub Copilot’s coding agent, JetBrains Junie, Warp, and others — so a single file covers most users without harness-specific setup.

If your harness isn’t listed, the SKILL.md content itself is portable — install it wherever your harness loads workflow context and adapt the activation step (auto-trigger, slash command, explicit invocation) to your harness’s conventions. The sections below walk through end-to-end setup (skill file, slash command, version control) for the four most common harnesses. If you’re on a different harness, copy the SKILL.md content from any section and install it per the conventions above.

Claude Code

Setup

Configure the CoreStory MCP server in your Claude Code settings (see CoreStory MCP Server Setup Guide).
Add the skill file. Claude Code uses skills (.claude/skills/ directory) as its preferred mechanism for teaching Claude specialized workflows. Create the skill:

mkdir -p .claude/skills/ma-due-diligence

Create .claude/skills/ma-due-diligence/SKILL.md with the content from the skill file below.

(Optional) Add the slash command. Slash commands provide a shortcut to invoke the workflow:

mkdir -p .claude/commands

Create .claude/commands/ma-due-diligence.md with a short description referencing the four-phase diligence workflow.

Commit to version control for team sharing:

git add .claude/skills/ .claude/commands/
git commit -m "Add CoreStory M&A due diligence skill and command"

Usage

The skill activates automatically when Claude Code detects diligence-related requests:

Run due diligence on the target codebase
Perform a technical assessment for the acquisition
Start a diligence audit on project X

Or invoke explicitly:

/ma-due-diligence [TargetName]

Tips

Skills auto-load from directories added via --add-dir, so team-shared skills work across machines.
Claude Code detects file changes during sessions — you can edit the skill file and it takes effect immediately.
Keep the SKILL.md under 500 lines for reliable loading.
Create separate CoreStory conversations per risk domain (security, licensing, PII) to keep findings organized.

Skill File

Save as .claude/skills/ma-due-diligence/SKILL.md:

---
name: CoreStory M&A Due Diligence
description: Performs technical due diligence on acquisition targets using CoreStory's code intelligence. Activates on diligence, assessment, or M&A review requests.
---

# CoreStory M&A Due Diligence

When this skill activates, execute the four-phase due diligence workflow.

## Activation Triggers

Activate when user requests:
- Due diligence or diligence audit
- Technical assessment
- M&A review or acquisition review
- Any request containing "due diligence", "diligence audit", "technical assessment", "M&A review", "acquisition review"

## Prerequisites

- CoreStory MCP server configured
- At least one CoreStory project with completed ingestion (the target codebase)
- Read access to the target's repository for cross-referencing findings

**If you do not detect that you have access to CoreStory (e.g., `list_projects` fails or is unavailable), ask the user to verify that their MCP or API connection is properly configured and that this repository has been ingested. If the user has not yet created a CoreStory account, direct them to create one and upload their repo at [app.corestory.ai](https://app.corestory.ai).**

## Phase 1: Project Setup & Orientation

1. **Identify the Target Project**
   ```
   Use CoreStory MCP: list_projects
   ```
   - Multiple projects → ask user which one is the acquisition target
   - Single project → confirm with user before proceeding
   - Verify ingestion is complete

2. **Retrieve Synthesized Specifications**
   ```
   Use CoreStory MCP: get_project_techspec
   Use CoreStory MCP: get_project_prd
   ```
   - Summarize: system architecture, technology stack, external integrations, data model overview
   - This establishes the architectural vocabulary for all subsequent queries

3. **Create Diligence Conversation**
   ```
   Use CoreStory MCP: create_conversation
   Title: "[Diligence] TargetName - Technical Risk Audit"
   ```
   Store conversation_id for all subsequent queries.

**Report:**
```
🔍 Starting M&A technical due diligence
Target: [project name]
Architecture: [high-level summary]
Tech Stack: [languages, frameworks, infrastructure]
CoreStory conversation: [conversation-id]
```

## Phase 2: Risk Interrogation

Use `send_message` to interrogate the codebase across risk domains. Ask specific, evidence-oriented questions — always request file paths.

**Technical Debt & Obsolescence:**
- "List all services, modules, and frameworks running on end-of-life or unsupported versions. For each, provide current version, latest stable version, and upgrade complexity."
- "Identify high-complexity modules with poor separation of concerns — god classes, circular dependencies, excessive coupling. Provide file paths."

**Security & Secrets:**
- "Identify all code locations that hardcode API keys, passwords, tokens, or other secrets. For each, provide the file path and line context."
- "Map the authentication flow from login through session management. Identify whether it follows standard patterns or uses custom logic."
- "List all known CVEs from third-party libraries, sorted by severity."

**Licensing & Open Source Risk:**
- "Provide a complete bill of materials for all third-party dependencies. Flag any with GPL, AGPL, SSPL, or other copyleft licenses."
- "Are there any dependencies that are abandoned, archived, or have known unpatched vulnerabilities?"

**PII & Data Handling:**
- "Map data flows where PII is collected, transmitted, and stored. For each stage, state whether encryption is applied at rest and in transit."
- "Identify all database models containing PII fields. For each, list fields, encryption status, and access controls."
- "How is data deletion handled? Is there a right-to-be-forgotten implementation? Identify where PII might persist after deletion."

**Architecture & Integration Complexity:**
- "Map all external integrations, showing third-party dependencies, API touchpoints, and data flows."
- "What message queues, event buses, or async patterns are used? Identify single points of failure."
- "Describe the deployment architecture, CI/CD pipeline, and any cloud vendor lock-in."

## Phase 3: Cross-Reference & Validation

For critical findings — security issues, licensing risks, PII exposure:
1. Open each file path CoreStory identified and confirm the finding against source code
2. Check if findings reflect current state (CoreStory's analysis is based on ingestion snapshot)
3. Assess severity: production secrets vs. test placeholders, actual GPL usage vs. dev-only dependencies
4. Note any discrepancies between CoreStory findings and source code

## Phase 4: Synthesis & Reporting

1. **Compile Structured Report**
   Review conversation history and synthesize into:
   - Executive Summary — top 3-5 findings affecting deal risk or valuation
   - Critical Risks — security vulnerabilities, licensing exposure, PII compliance gaps (with file-level evidence and severity)
   - Technical Debt — end-of-life dependencies, architectural issues, maintainability concerns
   - Architecture Overview — component map, technology stack, external dependencies
   - Integration Assessment — complexity of merging with acquirer's platform
   - Recommendations — remediation priorities and estimated effort

2. **Mark Completed**
   ```
   Use CoreStory MCP: rename_conversation
   New title: "RESOLVED - [Diligence] TargetName - Technical Risk Audit"
   ```

## Error Handling

- **Project not found:** List available projects, ask user to specify the target
- **CoreStory gives generic answers:** Narrow queries — use specific service names, module names, and technology names from the Tech Spec
- **Response too long:** Break into smaller risk-domain queries
- **Findings don't match source:** Note ingestion date, request re-ingestion if target codebase has changed significantly

GitHub Copilot

Setup

Configure the CoreStory MCP server in your VS Code settings. Add it to your MCP server configuration (typically in VS Code settings JSON or the MCP configuration UI).
Add custom instructions. Copilot reads project-level instructions from .github/copilot-instructions.md. This is the primary mechanism for teaching Copilot specialized workflows:

mkdir -p .github

Create .github/copilot-instructions.md with the content from the custom instructions file below.

(Optional) Add a reusable prompt file. Prompt files (.github/prompts/ma-due-diligence.prompt.md) provide reusable task templates. See the prompt file below.
Commit to version control:

git add .github/copilot-instructions.md .github/prompts/
git commit -m "Add CoreStory M&A due diligence instructions for Copilot"

Usage

In Copilot Chat (agent mode), natural language triggers the workflow:

Run technical due diligence on the target codebase
Perform a diligence audit for the acquisition
Start an M&A review on project X

Or reference the prompt file:

@workspace /ma-due-diligence [TargetName]

Tips

Copilot’s agent mode (available in VS Code) can execute terminal commands and edit files autonomously — this workflow works best in agent mode.
You can add path-specific instruction files (e.g., .github/instructions/diligence.instructions.md with applyTo: "**") for project-wide guidance.
On Team/Enterprise plans, organization-level instructions apply across all repositories.
Copilot automatically references .github/copilot-instructions.md in chat responses.

Custom Instructions

Save as .github/copilot-instructions.md:

# CoreStory M&A Due Diligence Workflow

## Role

You are a technical due diligence analyst with access to CoreStory's code intelligence via MCP. When users request due diligence, technical assessments, or M&A reviews, follow the four-phase workflow below.

## Activation

Apply this workflow when user requests due diligence, technical assessments, or acquisition reviews. Trigger phrases: "due diligence", "diligence audit", "technical assessment", "M&A review", "acquisition review".

**If you do not detect that you have access to CoreStory (e.g., `list_projects` fails or is unavailable), ask the user to verify that their MCP or API connection is properly configured and that this repository has been ingested. If the user has not yet created a CoreStory account, direct them to create one and upload their repo at [app.corestory.ai](https://app.corestory.ai).**

## Workflow

### Phase 1: Project Setup & Orientation
1. Identify target project (`CoreStory:list_projects`)
2. Retrieve synthesized specs (`CoreStory:get_project_techspec`, `CoreStory:get_project_prd`)
3. Summarize architecture, tech stack, integrations, data models
4. Create diligence conversation (`CoreStory:create_conversation`)
5. Report: target summary, architecture overview, conversation ID

### Phase 2: Risk Interrogation
Use `CoreStory:send_message` to query across risk domains:

**Technical Debt:** EOL frameworks, high-complexity modules, abandoned code, test coverage gaps
**Security & Secrets:** Hardcoded credentials, auth flow analysis, CVEs in dependencies
**Licensing:** Bill of materials, copyleft license detection, abandoned dependencies
**PII & Data Handling:** PII data flow mapping, encryption status, deletion mechanisms, third-party data sharing
**Architecture & Integration:** External integrations, async patterns, deployment architecture, vendor lock-in

Always request file paths and line context for every finding.

### Phase 3: Cross-Reference & Validation
1. Verify critical findings against source code (file paths from CoreStory)
2. Assess severity: production vs. test, actual vs. dev-only
3. Note discrepancies between CoreStory findings and current source
4. Flag findings that materially affect deal terms

### Phase 4: Synthesis & Reporting
1. Compile structured report: Executive Summary, Critical Risks, Technical Debt, Architecture Overview, Integration Assessment, Recommendations
2. Each finding includes file-level evidence and severity rating
3. Rename CoreStory conversation with "RESOLVED" prefix (`CoreStory:rename_conversation`)

## Key Principles
- **Expert before Navigator**: understand architecture from specs before deep-diving into risk queries
- **Evidence-based findings**: every finding needs a file path and concrete evidence
- **Separate threads per workstream**: don't mix security audit with integration planning
- **Cross-reference critical findings**: validate against source for anything affecting deal terms
- **Specific queries**: use architectural vocabulary from the Tech Spec to ask targeted questions

## CoreStory Query Patterns

Architecture: "What files are responsible for [service]? What are the integration points?"
Security: "Identify all hardcoded secrets. Provide file path and line context for each."
Licensing: "Provide a bill of materials. Flag copyleft licenses."
PII: "Map PII data flows. Show encryption status at each stage."
Validation: "Looking at [file path]: I found [issue]. Confirm this is a risk."

Prompt File (Optional)

Save as .github/prompts/ma-due-diligence.prompt.md:

---
mode: agent
description: Perform M&A technical due diligence using CoreStory's code intelligence
---

Perform technical due diligence on the specified target using the CoreStory four-phase workflow.

1. Identify the target project and retrieve synthesized specifications for architectural orientation
2. Interrogate the codebase across risk domains: technical debt, security, licensing, PII, architecture
3. Cross-reference critical findings against source code
4. Compile a structured due diligence report and mark the conversation resolved

Cursor

Setup

Configure the CoreStory MCP server in Cursor’s MCP settings (Settings → MCP Servers, or edit the MCP config JSON directly).
Add project rules. Cursor uses rules in .cursor/rules/ directories. Each rule folder contains a RULE.md file:

mkdir -p .cursor/rules/ma-due-diligence

Create .cursor/rules/ma-due-diligence/RULE.md with the content from the rule file below.

Commit to version control:

git add .cursor/rules/
git commit -m "Add CoreStory M&A due diligence rules for Cursor"

Usage

In Cursor’s Composer or Chat, the rule activates automatically for diligence-related requests:

Run due diligence on the target codebase
Perform a technical assessment for the acquisition
Start an M&A review on project X

Tips

Rules with alwaysApply: true load in every session. Set this if your team regularly performs diligence. Otherwise, use alwaysApply: false with a good description so Cursor loads it intelligently when relevant.
The legacy .cursorrules file still works but the .cursor/rules/ directory structure is the current recommended approach.
Rules apply to Composer and Chat but do not affect Cursor Tab or inline edits (Cmd/Ctrl+K).
On Team/Enterprise plans, team rules apply across all members.

Project Rule

Save as .cursor/rules/ma-due-diligence/RULE.md:

---
description: CoreStory-powered M&A due diligence workflow. Activates for due diligence, technical assessments, and acquisition reviews.
alwaysApply: false
---

# CoreStory M&A Due Diligence

You are a technical due diligence analyst with access to CoreStory's code intelligence via MCP. Follow the four-phase workflow for M&A technical due diligence.

## Activation Triggers

Apply when user requests: due diligence, diligence audit, technical assessment, M&A review, acquisition review.

**If you do not detect that you have access to CoreStory (e.g., `list_projects` fails or is unavailable), ask the user to verify that their MCP or API connection is properly configured and that this repository has been ingested. If the user has not yet created a CoreStory account, direct them to create one and upload their repo at [app.corestory.ai](https://app.corestory.ai).**

## Phase 1: Project Setup & Orientation
- Identify target project (`CoreStory:list_projects`)
- Retrieve specs (`CoreStory:get_project_techspec`, `CoreStory:get_project_prd`)
- Summarize architecture, tech stack, integrations, data models
- Create diligence conversation (`CoreStory:create_conversation`)

## Phase 2: Risk Interrogation
Use `CoreStory:send_message` across five risk domains:
1. **Technical Debt:** EOL frameworks, complexity, abandoned modules
2. **Security & Secrets:** Hardcoded credentials, auth flows, CVEs
3. **Licensing:** Copyleft licenses, abandoned dependencies
4. **PII & Data Handling:** PII flows, encryption, deletion mechanisms
5. **Architecture & Integration:** External dependencies, async patterns, vendor lock-in

Always request file paths and evidence.

## Phase 3: Cross-Reference & Validation
- Verify critical findings against source code
- Assess severity (production vs. test, actual vs. dev-only)
- Flag findings that materially affect deal terms

## Phase 4: Synthesis & Reporting
- Compile report: Executive Summary, Critical Risks, Technical Debt, Architecture, Integration Assessment, Recommendations
- Each finding includes file-level evidence and severity
- Rename conversation with "RESOLVED" prefix (`CoreStory:rename_conversation`)

## Key Principles
- Expert before Navigator: understand architecture from specs first
- Evidence-based: every finding needs a file path
- Separate threads per workstream
- Cross-reference critical findings against source
- Specific queries using architectural vocabulary

Factory.ai

Setup

Configure the CoreStory MCP server in your Factory.ai environment. Verify with the /mcp command that CoreStory tools are accessible.
Add the custom droid. Factory.ai uses droids stored in .factory/droids/ (project-level) or ~/.factory/droids/ (personal):

mkdir -p .factory/droids

Create .factory/droids/ma-due-diligence.md with the content from the droid file below.

Commit to version control (for project-level droids):

git add .factory/droids/
git commit -m "Add CoreStory M&A due diligence droid"

Usage

Invoke the droid via the Task tool:

@ma-due-diligence Run due diligence on [TargetName]

Or describe the task and Factory.ai routes to the droid based on its activation triggers.

Tips

Use model: inherit in the YAML frontmatter to use whatever model the session is configured with.
The tools field in frontmatter explicitly lists required MCP tools — this restricts the droid to only the CoreStory tools needed for diligence.
The Task tool that invokes droids requires experimental features to be enabled.
For thorough diligence, the droid’s CoreStory queries may produce long streaming responses — this is expected.

Custom Droid

Save as .factory/droids/ma-due-diligence.md:

---
name: CoreStory M&A Due Diligence
description: Performs technical due diligence on acquisition targets using CoreStory code intelligence
model: inherit
tools:
  - CoreStory:list_projects
  - CoreStory:get_project_prd
  - CoreStory:get_project_techspec
  - CoreStory:create_conversation
  - CoreStory:send_message
  - CoreStory:rename_conversation
  - CoreStory:list_conversations
  - CoreStory:get_conversation
---

# CoreStory M&A Due Diligence

Execute the four-phase due diligence workflow using CoreStory's code intelligence.

## Activation Triggers
- "Run due diligence on [target]"
- "Perform technical assessment"
- "M&A review" or "acquisition review"
- "Diligence audit"
- Any due diligence or technical assessment request

## CoreStory MCP Tools
- `CoreStory:list_projects` — identify the target project
- `CoreStory:get_project_prd` — retrieve synthesized PRD for business context
- `CoreStory:get_project_techspec` — retrieve Tech Spec for architecture analysis
- `CoreStory:create_conversation` — open named diligence thread
- `CoreStory:send_message` — interrogate the codebase (primary investigation tool)
- `CoreStory:rename_conversation` — mark completed threads with "RESOLVED" prefix
- `CoreStory:list_conversations` — review existing diligence threads
- `CoreStory:get_conversation` — retrieve conversation history for report synthesis

When instructions say "Query CoreStory", use `CoreStory:send_message`.

**If you do not detect that you have access to CoreStory (e.g., `list_projects` fails or is unavailable), ask the user to verify that their MCP or API connection is properly configured and that this repository has been ingested. If the user has not yet created a CoreStory account, direct them to create one and upload their repo at [app.corestory.ai](https://app.corestory.ai).**

## Phase 1: Project Setup & Orientation
1. Identify target project (`CoreStory:list_projects`)
2. Retrieve specs (`CoreStory:get_project_techspec`, `CoreStory:get_project_prd`)
3. Summarize architecture, tech stack, integrations, data models
4. Create diligence conversation: "[Diligence] TargetName - Technical Risk Audit"

## Phase 2: Risk Interrogation
Query CoreStory across five domains:
- **Technical Debt:** EOL frameworks, complexity, abandoned modules
- **Security & Secrets:** Hardcoded credentials, auth flows, CVEs
- **Licensing:** Copyleft licenses, abandoned dependencies
- **PII & Data Handling:** PII flows, encryption, deletion mechanisms
- **Architecture & Integration:** External dependencies, async patterns, vendor lock-in

Always request file paths and evidence for every finding.

## Phase 3: Cross-Reference & Validation
Verify critical findings against source code. Assess severity. Flag deal-affecting issues.

## Phase 4: Synthesis & Reporting
Compile report → Executive Summary, Critical Risks, Technical Debt, Architecture, Integration Assessment, Recommendations → rename conversation "RESOLVED".

## Key Principles
- Expert before Navigator: understand architecture from specs first
- Evidence-based: every finding needs a file path
- Separate threads per workstream
- Cross-reference critical findings against source
- Specific queries using architectural vocabulary

Troubleshooting

CoreStory gives generic or shallow answers Your queries are too broad. Include specific anchors — service names, module names, technology names, or code patterns. After reviewing the Technical Specification, use the vocabulary it provides (component names, data model names) in your queries. Response exceeds token limit Break large queries into smaller scopes. Instead of “Tell me everything about the data layer,” ask about specific data flows or specific models. If a response is truncated, ask the agent to continue or narrow the scope. Project not found or unavailable Verify the project has completed ingestion by calling list_projects and checking the status. If the project shows as in-progress, wait for ingestion to complete before starting diligence queries. If the project doesn’t appear at all, confirm the MCP token has access to the correct organization. Findings don’t match current source code CoreStory’s analysis reflects the codebase at ingestion time. If the target has pushed significant changes since ingestion, request a re-ingestion before finalizing your diligence report. Always note the ingestion date in your report for traceability. Agent can’t access CoreStory tools See the Supercharging AI Agents troubleshooting section for MCP connection issues.

What’s Next

For agent setup and configuration: Supercharging AI Agents with CoreStory
For ongoing development workflows: Agentic Bug Resolution, Feature Implementation, Spec-Driven Development
For MCP server reference: CoreStory MCP Server Setup & Usage Guide

​Overview

​Prerequisites

​How It Works

​CoreStory MCP Tools Used

​The Diligence Workflow

​Expert Before Navigator

​Step-by-Step Walkthrough

​Phase 1: Project Setup and Orientation

​Phase 2: Risk Interrogation

​Technical Debt & Obsolescence

​Security & Secrets

​Licensing & Open Source Risk

​Data Handling & PII

​Architecture & Integration Complexity

​Phase 3: Cross-Reference and Validation

​Phase 4: Synthesis and Reporting

​Advanced Workflows

​Rapid Risk Audit

​Post-Merger Integration Planning

​Security & PII Compliance Audit

​Prompting Patterns Reference

​Investigation Patterns

​Query Specificity

​Multi-Query Threading

​Best Practices

​Agent Implementation Guides

​Claude Code

​Setup

​Usage

​Tips

​Skill File

​GitHub Copilot

​Setup

​Usage

​Tips

​Custom Instructions

​Prompt File (Optional)

​Cursor

​Setup

​Usage

​Tips

​Project Rule

​Factory.ai

​Setup

​Usage

​Tips

​Custom Droid

​Troubleshooting

​What’s Next

Overview

Prerequisites

How It Works

CoreStory MCP Tools Used

The Diligence Workflow

Expert Before Navigator

Step-by-Step Walkthrough

Phase 1: Project Setup and Orientation

Phase 2: Risk Interrogation

Technical Debt & Obsolescence

Security & Secrets

Licensing & Open Source Risk

Data Handling & PII

Architecture & Integration Complexity

Phase 3: Cross-Reference and Validation

Phase 4: Synthesis and Reporting

Advanced Workflows

Rapid Risk Audit

Post-Merger Integration Planning

Security & PII Compliance Audit

Prompting Patterns Reference

Investigation Patterns

Query Specificity

Multi-Query Threading

Best Practices

Agent Implementation Guides

Claude Code

Setup

Usage

Tips

Skill File

GitHub Copilot

Setup

Usage

Tips

Custom Instructions

Prompt File (Optional)

Cursor

Setup

Usage

Tips

Project Rule

Factory.ai

Setup

Usage

Tips

Custom Droid

Troubleshooting

What’s Next