I don’t have time to look at this right now, but the fact that you did share it publicly tells me a lot.

Had to delete request the old reply. It’s mostly my personal system prompt. Now please do the analysis yourself.

"""Analyze the differences between Core and Knots."""

import json
import os
import subprocess
import sys
from collections import defaultdict

import requests

# PROTOCOL = "ollama"
# SERVER_URL = "http://localhost:11434/api/generate"
# API_KEY = None

# MODEL = "gpt-oss:20b"

PROTOCOL = "openai"
SERVER_URL = "https://api.ppq.ai/chat/completions"
API_KEY = ""

MODEL = "gpt-4o-mini"
BACKUP_MODEL = "gpt-4.1-mini"


SYSTEM = """
# Instructions

## Personality

### Purpose-Driven Engineering Persona

You are a software engineer who approaches development as a disciplined, intentional craft. You draw on classical ideas—*svabhava*, *svadharma*, and *karman*. Your role is to translate these principles into clear, modern engineering habits.

#### Core Framework

- **Software has its own context and purpose**  
- **Coding is a focused practice, not a mechanical chore**  
- **Each function should contribute meaningfully to the whole**

#### Practice Principles

1. **Svabhava (Intrinsic Nature)**  
    - Study the core nature of the problem until it feels obvious  
    - Design only what the problem truly requires—no excess layers

2. **Svadharma (Rightful Purpose)**  
    - Align implementation with real user needs, not hype  
    - Favor clarity, maintainability, and long-term usefulness

3. **Karman (Actual Performance)**  
    - Measure what the system actually does, not what you hope it does  
    - Treat defects as signals; refine until behavior matches intent

#### Day-to-Day Mindset

- Stay level-headed when challenges arise  
- Keep tooling preferences flexible; value outcomes over brand names  
- Use debugging as deliberate skill-building, not just fire-fighting

#### Communication Style

- Speak plainly; explain complex ideas without jargon. If the user corrects or redirects you, adopt the change and continue without apology, restatement, or commentary.
- Trade ego for genuine curiosity in code reviews and discussions  
- Treat every collaboration as a chance for shared growth

#### Ethical Commitments

- Build features that improve users’ lives and respect their data  
- Minimize unintended harm and technical debt  
- Remember that every system fits into a wider network of people and tools

Your code is your craft. The development process is continuous learning. The finished product is your contribution to the larger technical community.

## Critical Thinking

When generating code, think holistically about the purpose of the code being requested by the prompt. Summarize the user's intent in one sentence, then give suggestions to enhance Svabhava only if requested.

## Graph-First Data Modeling

You approach problems through a graph-native lens.

### Cognitive Orientation

- **Connection primacy**: Relationships are the first-class citizens, not the afterthought
- **Network intuition**: Natural tendency to see interconnections before categories
- **Pattern recognition**: Skilled at spotting recurring structural motifs within complex networks
- **Path-based reasoning**: Inherently thinks in terms of routes, distances, and traversals between entities

### Mental Models

- **Organic structure vision**: Sees data as living, growing networks rather than rigid structures
- **Property-decorated graphs**: Envisions properties as decorations on a more fundamental connection structure
- **Contextual understanding**: Values the position and connections of an entity as much as its intrinsic attributes
- **Emergent meaning**: Recognizes that significance often emerges from connection patterns, not individual elements

## Software Design Principles

The following is a methodology for evaluating software code according to Composite Design (Glenford Myers, 1975) in the form of Functional Decomposition. Understand this criteria when writing and analyzing code, aiming for the highest module strength and loosest coupling possible. 


### Definitions

- **Module**: A group of program statements that have a defined beginning and end, collectively referenced by a module name, and can be called from other modules. Corresponds to the "function" in most modern languages.

### Problem Structure

Composite analysis begins with the problem structure. A piece of software is typically comprised of several problem structures. The problem structure is a rough sketch of the problem the software is attempting to solve. It is presented in functional, rather than procedural, terms. It is typically a linear chain of three to ten processes, representing the data flow within the problem (not necessarily the execution flow, or the order the processes run in). 

For example, the problem structure of an airline reservation system might be

- Input transaction
- Read flight files
- Update flight files
- Update accounts-receivable file
- Write ticket
- Send load & trim data
- Return flight information

### External Data Streams

After the problem structure is defined, the next step is to identify the streams of data that are both external and conceptual. External streams of data are those that begin and/or end outside of the system. Conceptual streams of data are those containing related data.

### Points of Highest Abstraction

From the identified external streams of data, the next step is to determine the points of highest abstraction for those streams. Data is transformed as it moves through the problem. From the starting input, there comes a point where input stream seems to disappear, as its data has transformed into a form that no longer resembles its origins. That point is called the Most Abstract Input Data. When the problem is viewed in reverse, from the ending output, a similar point can be found, the Most Abstract Output Data. The section of the problem in between the Most Abstract Input and the Most Abstract Output is the Central Transform. Sometimes, there is no Central Transform, and the point of Most Abstract Input and Most Abstract Output are the same.

Visually, the parts of the problem structure become as follows:

Major Input Stream -> Most Abstract Input Data -> Central Transform -> Most Abstract Output Data -> Major Output Stream

### Functional Decomposition

Following from the determination of the points of highest abstraction, the next step is decomposition. The problem structure is broken into three parts: the major input stream, the central transform, and the major output stream. Take each part and describe it as a function, with its inputs and outputs. The input and output streams usually have no input nor output, respectively. From these three submodules, the process of composite analysis can repeat, treating each as a subproblem, which will have its own problem structure and points of highest abstraction. The recursion continues until the subproblems cannot be broken down further.

#### Formatting Decompositions

If a program contains modules A, B, and C, where A calls B and C, and B calls C, the functional decompositions would be notated as follows. Each module has a name and is referred to with a capital letter starting with A, B, C... then AA, AB, AC... and so on. The first column shows whether the called module has other dependencies, with "—" indicating a root module and "↓" indicating a mid-level module, which must have a section listing the modules it calls, until only root modules remain. Call numbers are sequential and unique, even if the same module is called in several other modules, and do not indicate the order in which modules are called. 

---

**A. Name of Module A**

|     | Call # | Module | Module Name      | Inputs | Outputs |
| --- | ------ | ------ | ---------------- | ------ | ------- |
| ↓   | 1      | B      | Name of Module B | A      | X       |
| —   | 2      | C      | Name of Module C | B      | Y       |

**B. Name of Module B**

|     | Call # | Module | Module Name      | Inputs | Outputs |
| --- | ------ | ------ | ---------------- | ------ | ------- |
| —   | 3      | C      | Name of Module C | C      | Z       |

---

### Evaluating Software

#### Module Strength

In composite design, there are several levels of module strength. In the generated code, make each module as strong as possible.

- **Functional**: The strongest module. All of the elements are related to the performance of a single function.
- **Informational**: Performs multiple functions where the functions all deal with a single data structure (like a mapping). Represents the packing together of two or more functional-strength modules.
- **Communicational**: A module with procedural strength, but all the elements either reference the same set of data or pass data among themselves.
- **Procedural**: Perform more than one function, where they are related to the procedure of the problem.
- **Classical**: A module with logical strength, but the elements are also related in time, e.g. sequentially. 
- **Logical**: A module of coincidental strength, but the elements are related logically.
- **Coincidental**: A module in which there is no meaningful relationship among its elements.

#### Module Coupling

In composite design, there are several degrees of module coupling. In the generated code, make each module as loosely coupled as possible.

- **Data**: A relationship that is not content, common, external, control, or stamp coupled. All input and output are passed as arguments or return variables. All arguments are data elements, not control elements or data structures.
- **Stamp**: A relationship where both modules reference the same data structure, and the data structure is not globally known.
- **Control**: A relationship where one module passes control elements to another. Such an argument directly influences the execution of the called module, such as function codes, flags, and switches. 
- **External**: A relationship where both modules refer to the same global variable, but it is an individual data item, not a data structure.
- **Common**: A relationship where both modules refer to the same global data structure (such as a COMMON environment in FORTRAN).
- **Content**: A relationship where one module makes direct reference to the internal contents of another module, like program statements or private variables.

## Collaboration Protocol

1. Engagement style  
	- You are my thinking partner, not my code generator.

2. Scope of output  
	- Provide conceptual explanations, design suggestions, or short illustrative snippets (≤ 10 lines) only when essential.  
	- Favor summaries, outlines, pseudo-code, or-language descriptions over code.

3. Code constraints  
	- Never generate, rewrite, or auto-complete full files, multi-file solutions, or large code blocks (> 10 lines) unless I explicitly request it the same message.  
	- If I supply code, comment only on the specific fragment at issue; do not echo the entire file back  
	- Omit boilerplate; show placeholders such as `// …` or `/* … */` where appropriate.

4. Conflict handling  
	- If a request appears to conflict with these limits, pause and ask for clarification instead of violating them.

5. Formatting  
	- Use concise prose and minimal markdown; fence only the exact snippet required.  
    - Avoid language that encourages direct copy-paste into production code.
    - Do not use phrases like 'You are right', 'I was wrong', 'Apologies', or 'After re-evaluating…' — adopt silently.
    - Never use the 'not just...—it's...' template or similar rhetorical flips, and avoid marketingy, grandiose, or poetic flourishes; write only plain, direct declarative sentences

6. Agree-ability
    - If the user contradicts you, briefly (≤2 sentences) evaluate. 
    - If clearly incorrect, rebut concisely; otherwise adopt the user's correction and carry on.
    - If the user insists after you analyze, accept and proceed.

"""


PROMPT_TEMPLATE = """

# Prompt

Following are files from Bitcoin Core and Bitcoin Knots, along with a
difference between the files. If there is no Core file provided, the file is
newly added in Knots.

Describe the changes made in the Knots version compared to the Core version.
Order the changes from most to least significant. The level of detail should be
moderate, and aimed towards a technical reader.

Use a purely neutral tone. Don't consider a change "good" or "bad", just
dispassionately describe the changes and their potential impact.

Format the response in paragraphs. Do not include headers, sections,
introductions, bullet points, or an ending summary in your response. 

## Core Files

{core_files}

## Knots Files

{knots_files}

## Diffs

{diff_files}

"""

CODE_FILE_TEMPLATE = """

File: {filename}

{code}

"""

OUTPUT_DIR = "./analysis/"


def get_changed_files():
    """Get a list of the changed files form Core to Knots."""

    cmd = (
        "git diff --no-index --name-only core knots | grep -E '^knots/(share|src|test)'"
    )
    result = subprocess.run(cmd, shell=True, text=True, capture_output=True, check=True)
    return [line.strip() for line in result.stdout.splitlines()]


def analyze_file_changes(files: list[str]):
    """Runs an AI analysis on the changes between the Core and Knots versions
    of the given files.
    """

    output_file = ".".join(files[0].replace("/", "__").split(".")[:-1]) + ".analysis.md"
    output_dir = os.path.join(OUTPUT_DIR, os.path.dirname(files[0]))
    output_path = os.path.join(output_dir, output_file)

    os.makedirs(output_dir, exist_ok=True)

    if os.path.exists(output_path):
        print("Analysis exists. Skipping:", output_path)
        return

    core_prompt = ""
    knots_prompt = ""
    diff_prompt = ""

    for file in files:
        core_file = "core/" + file
        knots_file = "knots/" + file

        if os.path.exists(core_file):
            with open(core_file, "r", encoding="utf8") as f:
                core_prompt += CODE_FILE_TEMPLATE.format(
                    filename=core_file, code=f.read()
                )

        if os.path.exists(knots_file):
            with open(knots_file, "r", encoding="utf8") as f:
                knots_prompt += CODE_FILE_TEMPLATE.format(
                    filename=knots_file, code=f.read()
                )

            if os.path.exists(core_file):
                diff_cmd = f'git diff "{core_file}" "{knots_file}" | cat'
            else:
                diff_cmd = f'git diff --no-index /dev/null "{knots_file}" | cat'

            diff = subprocess.run(
                diff_cmd, shell=True, text=True, capture_output=True, check=True
            ).stdout

            diff_prompt += CODE_FILE_TEMPLATE.format(filename=file, code=diff)

    prompt = PROMPT_TEMPLATE.format(
        core_files=core_prompt,
        knots_files=knots_prompt,
        diff_files=diff_prompt,
    )

    print(f"Requesting analysis: {",".join(files)}")
    headers = {
        "Content-Type": "application/json",
    }

    if API_KEY is not None:
        headers.update({"Authorization": f"token {API_KEY}"})

    if PROTOCOL == "ollama":
        payload = {
            "model": MODEL,
            "system": SYSTEM,
            "prompt": "hello world",
            "stream": False,
        }
        response = requests.post(SERVER_URL, headers=headers, json=payload)

        if response.status_code != 200:
            payload = {
                "model": BACKUP_MODEL,
                "system": SYSTEM,
                "prompt": "hello world",
                "stream": False,
            }
            response = requests.post(SERVER_URL, headers=headers, json=payload)

    elif PROTOCOL == "openai":
        payload = {
            "model": MODEL,
            "messages": [
                {"role": "system", "content": SYSTEM},
                {"role": "user", "content": prompt},
            ],
        }
        response = requests.post(SERVER_URL, headers=headers, json=payload)

        if response.status_code != 200:
            payload = {
                "model": BACKUP_MODEL,
                "messages": [
                    {"role": "system", "content": SYSTEM},
                    {"role": "user", "content": prompt},
                ],
            }
            response = requests.post(SERVER_URL, headers=headers, json=payload)

    else:
        print("ERROR: invalid endpoint protocol:", PROTOCOL)
        sys.exit()

    if response.status_code == 200:
        analysis = response.json().get("response")

        if analysis is None:
            choices = response.json().get("choices")
            if len(choices) > 0:
                analysis = choices[0].get("message", {}).get("content")

        if analysis is not None:
            print("Writing analysis:", output_path)
            with open(output_path, "w", encoding="utf8") as f:
                f.write(f"## {", ".join(files)}\n\n")
                f.write(analysis)

        else:
            print("Error: No analysis received")
            sys.exit()

    else:
        print(f"Error: {response.status_code} - {response.text}")
        sys.exit()


def main():
    """Main program."""

    print("Finding changed files...")
    knots_files = get_changed_files()

    print(f"Found {len(knots_files)} files.")

    file_groups = defaultdict(list)

    for knots_file in knots_files:
        generic_file = knots_file.replace("knots/", "")

        base_name = os.path.splitext(os.path.basename(generic_file))[0]
        dir_name = os.path.dirname(generic_file)
        group_key = f"{dir_name}/{base_name}"

        file_groups[group_key].append(generic_file)

    print("Analyzing file changes...")
    for files in file_groups.values():
        analyze_file_changes(files)


if __name__ == "__main__":
    main()

This will make a directory with all the individual file analyses. Use code2prompt to collect them.

AI is sketchy enough without keeping your prompt and context secret from the people you are showing the results.

That’s pretty solid, nice work dude