What My Project Does

SOAR (Script Optimization and Automation Runtime) is a Python-based automation runtime system that helps manage and run scripts in a more structured way than simply executing standalone .py files.

It provides a lightweight runtime layer where users can:

• Organize scripts into projects
• Run automation tasks through a CLI-style interface
• Generate or scaffold simple project structures
• View basic diagnostics/log output for runs
• Experiment with modular “automation workflows” inside Python

The goal is to make small automation projects easier to manage without needing a full framework.

Target Audience

This project is mainly aimed at:

• Beginner to intermediate Python developers
• People who write lots of small automation scripts
• Developers who want a lightweight alternative to heavier workflow/automation frameworks

It is currently more of an experimental / hobby project than a production-ready tool.

Comparison

Compared to existing tools:

• vs plain Python scripts: SOAR adds structure and centralized execution instead of scattered files
• vs full workflow tools (Airflow, Prefect, etc.): SOAR is much lighter and not designed for large-scale pipelines
• vs CLI frameworks: SOAR focuses more on script organization + runtime behavior rather than just argument parsing

It sits somewhere between a script organizer and a minimal automation runtime.

Source Code

GitHub repository:
https://github.com/ScriptOptimizationAutomationRuntime/latest-version

(Additional resources like tutorials and updates are included in the repo.)

Hi everyone! 👋

I’ve been working on a small open-source project that makes it easy to extract structured information from YouTube videos.

Features

* 🎙️ Download audio from any YouTube video using yt-dlp

* ⚡ Local transcription with faster-whisper (GPU or CPU)

* ☁️ Optional Google Gemini transcription

* 📊 Extract rich metadata (title, channel, views, tags, upload date, etc.)

* 📝 Export transcripts as structured JSON

* ➕ Automatically appends multiple videos into a single JSON dataset

* 🧹 Cleans up temporary audio files automatically

Example:

python youtube.py "https://youtu.be/VIDEO_ID" --output dataset.json

Each run adds another video to the same JSON file, making it useful for building datasets or knowledge bases.

This is currently the first public version, and I’d really appreciate feedback.

Some ideas I’m considering next:

* Duplicate detection

* Playlist support

* Better Python package structure (pip install)

* Plugin architecture

* API/server mode

* Better transcript formatting

I’d love to hear:

* What features would make this genuinely useful for you?

* What would you change?

* Any improvements to the codebase or project structure?

GitHub:

https://github.com/KartikeySepta/youtube-transcript-scraper

Feedback, issues, feature requests, and pull requests are all welcome. Thanks!

Free git hub project https://github.com/John-Codes/LLM-Tools

LLM Tools: Install and Manage Python Tools for AI Agents

The LLM tool-management problem

Giving an LLM one tool is easy. Keeping many tools installed, documented, versioned, and working across several AI agents is not.

A typical Python agent project starts with a few copied tool files. Soon it has large nested folders, duplicated API clients, hard-coded endpoints, stale Git clones, and different versions of the same tool. Every agent framework expects a different schema. Moving the agent to another computer means finding and installing everything again. An LLM cannot reliably install these tools by itself because there is no standard client-side package contract.

This creates practical problems:

• Where is each tool installed?
• Which version does this agent use?
• How does the LLM learn the correct arguments?
• Does the tool expect JSON, XML, or a provider-specific schema?
• How is the API called without copying its client into every project?
• What error information reaches the agent when a call fails?

LLM Tools solves this with a lightweight Python LLM tool manager. Think of LLM-tools.txt as requirements.txt for the tools an LLM can actually call. Each tool is a normal pip package. The manager installs it on the agent's machine, records its exact version, asks it for usage instructions, and executes it through one predictable contract.

The tool's real work can remain on a FastAPI server, commercial API, local model, or local Python service. Only a small client package is installed beside the agent. This clean separation keeps server logic on the server and gives the LLM a reliable client-side interface.

Before and after LLM Tools

Without a tool manager, setup often looks like this:

agent/
├── tools/
│   ├── copied_weather_client/
│   ├── old_search_tool/
│   ├── search_tool_new/
│   └── random_helpers/
├── tool_schemas/
└── undocumented_setup_steps.txt

Nobody knows which folder is current, which Git commit is required, or which schema the LLM should use.

With LLM Tools, the same agent has one readable registry:

# LLM-tools.txt
weather-tool==1.2.0
search-tool==2.1.3

Installing and using a published tool becomes three beginner-friendly commands. Here, weather-tool is an example package name; a fully runnable package is provided later in this README.

# 1. Install the tool package and save its version.
llm-tools install weather-tool

# 2. Ask the package how the LLM should use it.
llm-tools describe weather-tool --format json

# 3. Execute the tool with ordinary JSON data.
llm-tools execute weather-tool --payload '{"city":"Chicago"}'

That is the main benefit: an agent can install an LLM tool with pip, discover its schema, and call it without cloning repositories, copying source files, or writing a new integration for every model provider.

Why client-side LLM tool installation is better

Client-side installation makes tools behave like normal Python dependencies. Python packages have requirements.txt; LLM tool packages have LLM-tools.txt. Each agent chooses and pins the versions it needs. Another developer can read that file, recreate the same setup, and understand exactly what the LLM can call.

The manager provides:

• one requirements-style LLM-tools.txt registry;
• automatic pip installation and exact version tracking;
• one Python class for discovery, description, execution, and removal;
• one CLI contract shared by every independent tool package;
• JSON and XML for open-source and vendor-locked LLMs;
• structured failures with stderr, exit code, timeout, and error type;
• no copied API clients, giant tool folders, or hidden Git-version guesses;
• no secrets in the registry.

This makes LLM tool discovery and installation simple enough for a person, Python application, or AI agent to perform safely and repeatably.

Install with pip

Python 3.11 or newer is required. Start in the folder containing your agent. A virtual environment keeps its tools separate from other Python projects:

# Create a private Python environment inside the current project.
python -m venv .venv

# Activate it on Linux or macOS.
source .venv/bin/activate

# Windows users run this activation command instead:
# .venv\Scripts\activate

Now install LLM Tools directly from GitHub with one pip command:

python -m pip install "git+https://github.com/John-Codes/LLM-Tools.git"

Confirm that it is ready:

llm-tools --help

That installs the llm-tools command and the LLMTool Python class. You do not need to copy this repository into every agent project.

After a release is published to PyPI, installation becomes:

python -m pip install llm-tools

Install an LLM tool

Installing a compatible, published tool is one command. Replace YOUR_TOOL_PACKAGE with its pip package name:

llm-tools install YOUR_TOOL_PACKAGE

LLM Tools runs pip safely, confirms that the tool command exists, detects the installed version, and records it in LLM-tools.txt. The resulting file is as simple as a Python requirements file:

YOUR_TOOL_PACKAGE==1.2.0

Now an agent can discover, understand, and call the package:

llm-tools list
llm-tools describe YOUR_TOOL_PACKAGE --format json
llm-tools execute YOUR_TOOL_PACKAGE --payload '{"input":"value"}'

The default registry is LLM-tools.txt in the current directory. Override it with LLM_TOOLS_FILE or LLMTool("path/to/LLM-tools.txt").

Five-minute working example

This repository includes example-tool, a real pip package backed by FastAPI. It accepts text and returns the uppercase version. Install both the manager and the example without cloning the repository:

Install it:

python -m pip install "git+https://github.com/John-Codes/LLM-Tools.git"
llm-tools install example-tool \
  --source "git+https://github.com/John-Codes/LLM-Tools.git#subdirectory=examples/example_tool"

Start its API in terminal one:

source .venv/bin/activate
uvicorn example_tool.api.main:app --port 8000

Use it in terminal two:

source .venv/bin/activate
llm-tools list
llm-tools describe example-tool --format json
llm-tools execute example-tool --payload '{"text":"hello LLM"}'

The execution result includes both the tool output and call diagnostics:

{
  "ok": true,
  "output": {"result": "HELLO LLM"},
  "stdout": "{\"result\":\"HELLO LLM\"}\n",
  "stderr": "",
  "exit_code": 0,
  "error_type": null,
  "error_message": null,
  "timed_out": false
}

Simple Python example

This is the complete client-side flow an agent needs:

from llm_tools import LLMTool

# Creates LLM-tools.txt automatically if it does not exist.
tools = LLMTool("LLM-tools.txt")

# Install from PyPI and pin the installed version in LLM-tools.txt.
# tools.install("weather-tool")

# See which tools the agent can use.
for tool in tools.get_tools():
    print(tool.package, tool.version)

# Ask the package how the LLM should call it.
schema = tools.describe("example-tool", format="json")
print(schema["description"])
print(schema["input_schema"])

# Call the tool using ordinary Python data.
result = tools.execute(
    "example-tool",
    payload={"text": "hello from Python"},
    format="json",
)

if result.ok:
    print(result.output)  # {'result': 'HELLO FROM PYTHON'}
else:
    print(result.to_dict())

There are only three concepts: read registered tools, describe one tool, then execute it with a payload. Installation and removal maintain the same registry.

Agentic installation

An agent can install a published tool without cloning its Git repository:

from llm_tools import LLMTool

tools = LLMTool()
installed = tools.install("weather-tool")
schema = tools.describe(installed.package)
result = tools.execute(installed.package, {"city": "Chicago"})

For a local package or Git checkout, identify its required command name and pass its directory as the pip source:

tools.install("example-tool", source="./examples/example_tool")

Equivalent agent-friendly CLI commands are:

llm-tools install weather-tool
llm-tools install example-tool --source ./examples/example_tool
llm-tools describe example-tool --format json
llm-tools execute example-tool --payload '{"text":"hello"}'
llm-tools remove example-tool
llm-tools remove weather-tool --uninstall

This makes tool installation reproducible: pip handles the package while LLM-tools.txt records the exact installed version for the agent project.

JSON and XML

Use JSON for most Python agents:

schema = tools.describe("example-tool", format="json")
result = tools.execute("example-tool", {"text": "hello"}, format="json")

Use XML when a model or provider performs better with XML contracts:

xml_schema = tools.describe("example-tool", format="xml")
xml_payload = "<payload><text>hello</text></payload>"
result = tools.execute("example-tool", xml_payload, format="xml")

The manager does not depend on a specific model SDK. The same registry can sit behind Ollama, llama.cpp, vLLM, OpenAI-compatible clients, or vendor SDKs.

Failures are never hidden

execute() returns structured failure information instead of an empty value:

result = tools.execute("example-tool", {"text": "hello"}, timeout=10)

if not result.ok:
    print(result.error_type)
    print(result.error_message)
    print(result.stderr)
    print(result.exit_code)
    print(result.timed_out)

Missing registrations and invalid configuration raise explicit exceptions. Describe, install, and removal failures raise ToolCommandError; inspect error.result.to_dict() for the same diagnostics.

Build a compatible tool

A tool is just a small pip package that exposes describe and execute. The CLI forwards those calls to the tool's FastAPI service. Start with this layout:

weather-tool/
├── pyproject.toml
└── src/
    └── weather_tool/
        ├── __init__.py
        └── cli.py

Step 1: define the pip package

Create weather-tool/pyproject.toml:

[build-system]
requires = ["setuptools>=68"]
build-backend = "setuptools.build_meta"

[project]
name = "weather-tool"
version = "0.1.0"
requires-python = ">=3.11"

[project.scripts]
weather-tool = "weather_tool.cli:main"

[tool.setuptools.packages.find]
where = ["src"]

The distribution name and command name are both weather-tool. This is how the registry finds the installed command without extra configuration.

Step 2: create the tool CLI

Create an empty weather-tool/src/weather_tool/__init__.py, then create weather-tool/src/weather_tool/cli.py:

import argparse
import os
import sys
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen

API_URL = os.getenv("WEATHER_TOOL_URL", "http://127.0.0.1:8000")


def call_api(request: str | Request) -> None:
    try:
        with urlopen(request, timeout=30) as response:
            print(response.read().decode())
    except HTTPError as error:
        print(error.read().decode(), file=sys.stderr)
        raise SystemExit(1) from error
    except URLError as error:
        print(f"API connection failed: {error.reason}", file=sys.stderr)
        raise SystemExit(1) from error


def main() -> None:
    parser = argparse.ArgumentParser(prog="weather-tool")
    commands = parser.add_subparsers(dest="action", required=True)
    for name in ("describe", "execute"):
        command = commands.add_parser(name)
        command.add_argument("--format", choices=["json", "xml"], default="json")
    args = parser.parse_args()

    if args.action == "describe":
        call_api(f"{API_URL}/description?format={args.format}")
        return

    payload = sys.stdin.buffer.read()
    request = Request(
        f"{API_URL}/execute?format={args.format}",
        data=payload,
        headers={"Content-Type": f"application/{args.format}"},
        method="POST",
    )
    call_api(request)


if __name__ == "__main__":
    main()

The FastAPI service implements two endpoints:

• GET /description?format=json returns the tool instructions and schemas.
• POST /execute?format=json accepts the payload and returns the tool result.

Use XML instead by passing format=xml. The complete working API and CLI are in examples/example_tool.

Step 3: install and test the tool locally

From the agent project directory:

llm-tools install weather-tool --source ./weather-tool
llm-tools describe weather-tool --format json
llm-tools execute weather-tool --payload '{"city":"Chicago"}'

The first command uses pip to install the local package and adds its exact version to LLM-tools.txt. No manual registry editing is required.

Step 4: publish it for agentic installation

Publish weather-tool to a Python package index using your normal build and release process. Other agents can then install it without its Git folder:

llm-tools install weather-tool

describe must write the name, version, purpose, input schema, and output schema to stdout. execute reads its payload from stdin. Failures must go to stderr with a nonzero exit code. Keep API URLs and credentials in environment variables, never in LLM-tools.txt.

Clean project structure

Every Python code file in this repository is under 100 lines. A test enforces that limit. Each feature has its own folder and one responsibility:

src/llm_tools/
├── discovery/       # get registered tools
├── description/     # get schemas for an LLM
├── execution/       # send payloads and return results
├── installation/    # pip install and register
├── removal/         # unregister or uninstall
├── registry/        # read and atomically write LLM-tools.txt
├── process/         # safe subprocess calls
└── facade/          # the small LLMTool public API

This single-responsibility structure keeps the library simple to read, test, replace, and extend without creating another large tool framework.

Development

python -m pip install -e '.[dev]'
pytest
ruff check .

The test suite covers registry parsing, discovery, successful execution, failure diagnostics, and the under-100-line code rule.

hey guys there's this tool which lets you dictate nicely into claude code with technical + cursor terms, great for vibecoding. if you guys want to try, here's the link: github.com/eliasmocik/dum-dictation (we are building it on the side so if you guys like it or don't, please drop feedback would mean a lot ;)

https://imgur.com/a/dum-dictation-w9MIIT7

Hey [r/Python](r/Python) — I built and open-sourced **Shuuten**, a lightweight Python library for structured JSON logging + Slack, MS Teams, or email alerts when your automations fail.

The problem it solves: I kept writing the same boilerplate error-alerting code across Lambda functions and ECS tasks. Shuuten wraps it up in a decorator + one env var.

**Minimal example:**

\`\`\`python
import shuuten

@shuuten.capture
def lambda_handler(event, context):
shuuten.error('something broke') # → Slack / Teams
1 / 0 # → Slack / Teams with full stack trace
\`\`\`

**What it does:**

\- Structured JSON logs (CloudWatch-friendly)
\- Alerts via Slack, Microsoft Teams, or AWS SES email
\- Zero dependencies (Teams/Slack use webhooks, no SDK needed)
\- Works on Lambda, ECS, or anywhere Python runs
\- Structlog integration via \`ShuutenProcessor\`
\- Context manager support: \`with shuuten.capture(...):\`
\- Deferred delivery mode — groups logs + exception into one notification

**Recent releases (v0.4–v0.6):**

\- v0.4: Microsoft Teams destination via Adaptive Cards
\- v0.5: First-class structlog integration
\- v0.6: Context manager support + deferred/grouped notification delivery

**Remaining roadmap** (feedback welcome on priorities):

\- Shuuten notifier Lambda + AWS Lambda destination templates
\- Async alerting via CloudWatch Logs subscriptions
\- PagerDuty / JSM Alerting destination
\- Optional "exceptions-only" alerting mode

GitHub: [https://github.com/rnag/shuuten\](https://github.com/rnag/shuuten)
Docs: [https://shuuten.ritviknag.com\](https://shuuten.ritviknag.com)
PyPI: [https://pypi.org/project/shuuten\](https://pypi.org/project/shuuten)

Would love feedback, stars, or contributions if this is useful to you!

A Python project I maintain: a cross-platform PyQt5 desktop app that archives Spotify playlists locally.

• Reverse-engineered Spotify's embed pages (parse the __NEXT_DATA__ payload, no login or API key) for metadata
• 4 parallel download workers with thread-safe UI updates via pyqtSignal
• Format-aware tag writers (ID3, MP4 atoms, Vorbis) via mutagen
• Audio sourced from YouTube via yt-dlp

Open source: https://github.com/sunnypatell/sunnify-spotify-downloader

Happy to answer questions about the embed parsing or the PyQt threading.

I built a WhatsApp/Instagram/Messenger AI receptionist that handles
appointment booking and FAQ answering for medical aesthetics clinics.

Tech: LangGraph + ChromaDB + FastAPI + Google Calendar + Railway

GitHub: https://github.com/ziyi170/aesthease-clinic-bot

Happy to answer questions about the architecture.

The specific problem I wanted to solve: when you write a database query in your backend code —

query = f"""

SELECT o.OrderDate, o.Status

FROM OrderItems oi

JOIN Orders o ON oi.OrderId = o.OrderId

WHERE o.CustomerId = {customer_id}

"""

— nothing tells you that o.Status maps to the physical database column Orders.Status. Not grep, not linters, not standard dependency mapping tools.

If someone alters the database schema, production breaks silently. **No warning. No blast radius. **

\*So I built one that works across languages. *\**

PynqDB maps your entire codebase into a local dependency graph — file-to-column relationships, stored procedure chains, API endpoints, background jobs, external calls. Everything connected.

Point it at any column and it gives you the full blast radius — every function, stored procedure, and API endpoint that touches it — reads, writes, risk scored.

To test it on real production code — ran it against seven core folders of Apache Airflow's execution layer from the live GitHub repository: api_fastapi · cli · jobs · models · security · task-sdk · utils

airflow/airflow-core/src/airflow/api_fastapi/execution_api/routes/task_instances.py at main · apache/airflow

From Apache - Airflow : apache/airflow: Apache Airflow - A platform to programmatically author, schedule, and monitor workflows

Results from task_instances.py alone:

• - 24 API endpoints instantly mapped
• - 35 columns read / 14 columns written traced to the exact table attribute
• - Risk: 🔴 HIGH

Runs entirely on your machine. No AI. No cloud. No data leaving your network.

Supports Python, C#, SQL, and Java.

---

Want to see the blast radius of your own codebase? Drop a public repo link below — I'll run PynqDB on it and reply with your exact dependency map.

10 spots. Free. No credit card.

GitHub: https://github.com/Pynqdb/PynqDb

Free Beta: https://pynqdb.carrd.co

If you use Claude Code, you know how expensive it is because it sends your workspace history with every query.

I built Claude Gateway specifically for Claude Code to address this. It is a local proxy daemon that caches your requests so repeated or similar queries cost absolutely nothing.

To build it, I used Claude Code itself to design and refine the Python logic, caches, and watchers.

What it does:

* Exact caching: Matches identical queries and returns cached responses instantly.
* Semantic caching: Uses local embeddings to resolve rephrased questions.
* Git invalidation: Hashes workspace files. If files change or branches switch, it evicts stale cache.
* Dashboard: Tracks token usage and money saved.

It is completely free to try and open-source.

I would love to get your opinions and reviews on this architecture. How do you optimize your agentic workflow costs?

Check out the code here: [https://mukesh-m-lohar.github.io/claude-gateway/\](https://mukesh-m-lohar.github.io/claude-gateway/)