Project overview and demo

🏛️ govbot

govbot enables distributed data anaylsis of government updates via a friendly terminal interface. Git repos function as datasets, including the legislation of all 47 states/jurisdictions.

Quick Start

1. Install

sh -c "$(curl -fsSL https://raw.githubusercontent.com/chihacknight/govbot/main/actions/govbot/scripts/install-nightly.sh)"

2. Set up your project

govbot

Running govbot with no config file launches an interactive setup wizard that:

1. Asks what data sources you want (all 47 states or specific ones)
2. Guides you through creating tags for topics you care about
3. Creates govbot.yml, .gitignore, and a GitHub Actions workflow

3. Run the pipeline

govbot

With a govbot.yml in your directory, running govbot executes the full pipeline:

1. Clones/updates legislation repositories
2. Tags bills based on your tag definitions
3. Generates RSS feeds in the docs/ directory

Other Commands

govbot clone all           # download all state legislation datasets
govbot clone il ca ny      # download specific states
govbot logs                # stream legislative activity as JSON Lines
govbot logs | govbot tag   # process and tag data
govbot build               # generate RSS feeds
govbot load                # load bill metadata into DuckDB
govbot delete all          # remove all downloaded data
govbot update              # update govbot to latest version
govbot --help              # see all commands and options

🏛️ Govbot Legislation Effort

• Nearly all state governments
• Federal

WIP: Ideally, these scripts should be accessible via the following ways.

• CLI / Unix pipe friendliness where possible. CLI is the most portable of solutions.
• GitHub Actionable if possible

Contribute

Folder Structure

This repo is a monorepo, with actions being self contained. actions as a name is because it's what Github expects.

Requirements For Each Action

• Be a runnable as basic scripts in python, bash, rust, or typescript which can run as shell scripts with args.
• Have an action.yml file to run as a runner, most likely in GitHub Actions.
• Have a schemas folder that uses JSON schema to define types.
  • This allow other actions to import your schema for validation.
• Have __snapshots__ that contain real file/folder outputs. This serves two purposes: (1) they show expected results and (2) they can be directly used as inputs for downstream snapshot tests.
  • Each action manages its own snapshot rendering through a render_snapshots.sh script.
  • Validation occurs via .github/validate-snapshots.yml for each specific module.