M&A Technical Due Diligence

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

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

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

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."

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."

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."

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."

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."

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

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

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

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.

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

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)

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)?"

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

mkdir -p .claude/commands

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

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

/ma-due-diligence [TargetName]

---
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

mkdir -p .github

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

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

@workspace /ma-due-diligence [TargetName]

# 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
- **Oracle 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."

---
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

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

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

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

---
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
- Oracle 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

mkdir -p .factory/droids

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

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

---
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
- Oracle 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