andyk/recursive_llm

<explanation>

1. Identify the project type and purpose

- This is an open‑source command‑line tool (not a multi‑tier web app) whose sole responsibility is to automate “recursive” LLM prompting.

- It uses Python (run_recursive_gpt.py) to read an English‑language prompt from STDIN or a text file, submit it to the OpenAI API, receive back a new prompt, and repeat until a base case is reached.

2. Analyze the file structure

- Top‑level files:

• README.md – detailed description, use cases, dependencies.

• run_recursive_gpt.py – the orchestration script.

• prompt_*.txt – various example prompt templates (fibonacci, counting, factorial).

• shell_demo_*.mp4 – recorded usage demos (documentation/artifacts, but not part of the runtime flow).

3. Examine the README for additional insights

- Confirms two recursion layers:

a) English‑based “recursive” prompt that regenerates itself toward a goal.

b) A Python function that calls itself with the model’s output.

- Highlights external dependency: OpenAI’s text‑davinci‑003 (or GPT‑3.5) API.

4. Main components to include in the diagram

a. User/Developer (initiates the process via CLI or file redirect)

b. Prompt Templates (prompt_*.txt) or STDIN (initial prompt state)

c. Recursive Python Function (run_recursive_gpt.py)

d. OpenAI API / LLM service (text‑davinci‑003)

e. Terminal Output (prints “response #n” lines)

5. Relationships and data flow

- User → (initial prompt text) → Python script

- Python script ↔ (HTTP request/response) ↔ OpenAI API

- Python script → (stdout) → Terminal / User

- Python script → (recursive call) → itself, feeding the last API response back as the next prompt

6. Architectural patterns and design principles

- Client‑Service: local CLI client calling an external RESTful LLM service

- Separation of concerns: prompt templates (data) are decoupled from orchestration logic (code)

- Two recursion layers:

• Prompt‑level recursion (state encoded in English text)

• Code‑level recursion (run_recursive_gpt → run_recursive_gpt)

- Stateless orchestration aside from passing the evolving prompt string

7. Relevant technologies and libraries

- Python 3.x, openai Python SDK

- OpenAI REST API (text‑davinci‑003 or GPT‑3.5)

- Shell / STDIN/STDOUT

8. Guidelines for tailoring the diagram (open‑source CLI tool)

- Highlight the “core loop”: read prompt → call API → update prompt → repeat

- Emphasize extensibility: show how adding a new prompt_*.txt file plugs in as an alternative starting state

- Show integration point with OpenAI (the only external dependency)

9. Diagramming best practices

- Use distinct shapes or colors:

• Blue boxes for local artifacts (scripts, prompt files)

• Green box for the running process (Python recursion engine)

• Orange box for external service (OpenAI API)

• Grey icon for the User/Terminal

- Label every component clearly (e.g., “run_recursive_gpt.py”, “prompt_fibonacci_no_base_case.txt”)

- Draw directional arrows for data flow:

• Arrow from User → Python script (“initial prompt”)

• Arrow from Python → OpenAI API (“prompt text”)

• Arrow from OpenAI API → Python (“updated prompt”)

• Loop arrow from the Python script back to itself (“recursive call”)

• Arrow from Python → User/Terminal (“print response #n”)

- Optionally annotate the loop with a termination condition (“stop when base case recognized”)

10. Capture essential architectural elements without over‑complicating

- Don’t try to model CI/CD or documentation videos—focus on runtime flow

- Separate your diagram into three vertical layers (top to bottom or left to right):

1. User/CLI layer

2. Local orchestration layer (scripts + prompt files)

3. External LLM service layer

By following these guidelines, you’ll produce a clear, accurate system design diagram that highlights the recursive orchestration at the heart of this open‑source project, the data flow between local code and the external LLM, and the extensibility hooks provided by modular prompt templates.

</explanation>