i
Natural-language queries
Ask in English. The writer agent is primed with the full database schema, so it produces valid joins and column references rather than hallucinated ones.
Multi-agent system
Python 3.11
LangChain · GPT-4o-mini
PostgreSQL
Open source
Ask your repositories anything.
GitPulseAnalytics turns a plain-English question about GitHub activity into working analysis code. A writer agent drafts it, a reviewer agent scores it, an executor agent runs it — and the table, chart, or forecast comes back in seconds.
3Specialised agents
4Postgres tables
0–100Code quality score
30dForecast horizon
Streamlit · localhost:8501
main.py
>
Plot the trend of closed issues over time and forecast the next 30 days
Writer
Code generated
Reviewer
Accepted
Executor
Chart rendered
Code quality
88 / 100
01 / Overview
Repository data is rich. Querying it shouldn't need SQL.
GitPulseAnalytics collects issues, pull requests, commits, and repository metadata from the GitHub API into PostgreSQL, then puts a natural-language layer on top of it.
Instead of hand-writing a join across four tables and a plotting script every time a question comes up, you type the question. The system generates schema-aware Python that connects to the database, loads the relevant tables into pandas, and renders the answer as text, a table, or a chart.
Forecasting is built in: Prophet for issue volume, ARIMA/SARIMA for commits and pull requests, projected thirty days out.
Every query is generated, statically checked, scored, and executed — and you can read exactly what ran. Design principle
02 / Features
Built like a pipeline, not a prompt box
Each query passes through generation, static analysis, LLM review, and sandboxed execution before a result is shown.
ii
Two-layer code review
Deterministic static checks — AST compile, banned file I/O, import correctness — run alongside an LLM reviewer returning a 0–100 score and an accept/reject verdict.
iii
Charts and tables on demand
matplotlib, seaborn, and plotly output renders directly into the Streamlit surface. Charts are produced only when the question actually calls for one.
iv
Time-series forecasting
Prophet models issue trends; statsmodels ARIMA/SARIMA handles commit and PR velocity. Per-repository fits are aligned on a shared index for clean comparison.
v
Normalised Postgres store
A collection notebook pulls repos, issues, pulls, and commits through PyGithub into four typed tables, so analysis runs against a relational store rather than raw API responses.
vi
Transparent by default
The generated code, the review score, and the execution result all appear in the interface. Nothing runs behind a curtain — you can read exactly what was executed.
03 / Method
One question, four stages
The orchestrator coordinates three specialised agents, each with a single responsibility.
01
Query intake
main.py
An analytics question is typed into the Streamlit interface and handed to the orchestrator. There are no dropdowns, filters, or pre-built dashboards to configure first.
02
Writer agent
writer_agent.py
A GPT-4o-mini call through LangChain receives the question plus the full schema of all four tables. It returns executable Python — Postgres connection, pandas loading, analysis, and Streamlit rendering — with markdown fences stripped by the orchestrator.
Note
Temperature is held at 0.1 to keep generated code stable across repeat runs of the same question.
03
Reviewer agent
reviewer_agent.py
Two checks run in sequence. Static analysis compiles the code and flags concrete violations — plt.show() calls, file I/O, input(), missing imports, incorrect Prophet usage, or a timestamp column that contradicts the question. An LLM reviewer then scores quality from 0 to 100 and returns ACCEPTED or REJECTED.
Precedence
Static findings cap the score at 70, and anything below 50 is forced to REJECTED — so deterministic checks always outrank the model's opinion.
04
Executor agent
executor_agent.py
The code runs inside a LangChain PythonREPL, with execution errors caught and surfaced rather than crashing the app. The generated code, quality score, and result — text, dataframe, or figure — return together to the interface.
Current behaviour
Review runs before execution and is reported alongside the output; this build surfaces the score rather than using it as a hard gate.
04 / Data model
Four tables, one schema contract
The same schema is embedded in the writer agent's prompt and enforced by the reviewer's static checks.
| Table | Contents | Key columns |
|---|---|---|
| github_repos | Repository-level popularity metrics | repo · stars · forks |
| github_issues | Issue lifecycle and labelling | state · created_at · closed_at · labels |
| github_pulls | Pull request flow and authorship | state · merged_at · user_login |
| github_commits | Commit history per contributor | sha · author_login · committed_at |
05 / In practice
Things you can ask it
Q.01Show the most active repositories by number of commits
Q.02Plot the trend of issues over time
Q.03Compare pull request statistics between repositories
Q.04Predict the number of issues for the next month
Q.05Visualise the relationship between stars and forks
Q.06Which contributors closed the most issues last quarter?
06 / Tech stack
What it's built with
Python 3.11 throughout, with a deliberately small and well-supported dependency surface.
AI & orchestration
- LangChain
- LangGraph
- OpenAI GPT-4o-mini
- langchain-experimental
- PythonREPL
Data & storage
- PostgreSQL
- psycopg2
- pandas
- NumPy
- PyGithub
Analysis & forecasting
- Prophet
- statsmodels
- ARIMA / SARIMA
- Jupyter
Interface & visualisation
- Streamlit
- matplotlib
- seaborn
- plotly
Read the source
The full multi-agent pipeline, the data collection notebook, and setup instructions are on GitHub. Clone it, point it at your own repositories, and start asking questions.