Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
42 lines (28 loc) · 2.8 KB

CONTRIBUTING.md

File metadata and controls

42 lines (28 loc) · 2.8 KB
Raw

Contributing

Thank you for helping improve Ghost in the Shell. Use issues and pull requests against this repository. Broader questions and coordination: ghost.bizs.app/contribute.html.

Repository layout

Path Role
cmd/ Binaries: ghost, ghostctl, tool-cli, skill-cli, loop-cli, artifact-cli, artifact-server, …
internal/ Core packages (agent loop, control plane, sandbox, tools, LLM, scheduler, …)
architect/ Worlds, archetypes, skills, snippets, and related markdown assets
dashboard/ Vite + React UI (optional)
docker/ Compose for local stack (make up); optional per-world compose files under the same directory
docs/ Design and deep-dive documentation

Local development

Run the stack (Docker)

From the repo root, make up starts Postgres, Ghost, the dashboard, and local devtools via docker/docker-compose.yml. The dashboard listens on http://localhost:5173 by default. See README.md for configuration and world loading.

Work on Go or the dashboard

Use this checklist when you change the Go backend or dashboard/ (not required if you only use the prebuilt Docker images).

  • Go — version in go.mod. With asdf, run asdf install using .tool-versions.
  • Node.js — for the dashboard dev server and builds; same asdf flow.
  • Optional — golangci-lint and goimports if you run lint/format locally or use pre-commit hooks.

The Makefile lists targets such as build, test, lint, fmt, and Docker helpers (up, down, logs). A typical Go change: make fmt, make lint, make test (or go test ./... -race -count=1).

Design and documentation

  • Start with docs/design.md for architecture.
  • If you change behavior that others rely on (API, scheduler, storage, agent lifecycle, etc.), update the relevant doc under docs/ and, for substantial design shifts, docs/design.md.

Opening a pull request

  1. Scope — One focused change per PR when possible; easier to review and revert.
  2. Describe — What you changed and why. Link related issues (Fixes #123 or Refs #123).
  3. Verify — For Go changes, ensure tests and lint pass locally (make test, make lint or equivalent). For dashboard changes, run the project’s usual checks (see dashboard/package.json).
  4. Fill in — GitHub loads .github/pull_request_template.md when you open a PR; complete it so reviewers see testing notes and risk at a glance.