Workspace tour

A tour of the project workspace: where to look for what, and how each section maps to the rest of the platform.

What is the workspace?

Each project (and each multi-project system) has a workspace: the source of truth. It houses your live system documentation, your master spec, and configuration for all guardrails to keep your code shipping as expected.

  • Overview: single-page snapshot of system health and what just changed
  • Activity: audit trail of PR analyses (outcomes of all code review guardrails), commit attestations (per-commit diff of capabilities, architecture, and more), and telemetry (what agents are making which changes? how many tokens are they spending on each change?)
  • Explore Specs & Docs: a live view of your system architecture, surface area, service dependencies, and more, to make sure you understand and trust your codebase
  • Steering and Guardrails: rules, decisions, principles, skills, and agent context. Consistent data available no matter what agent provider your teams use.
  • Automations: when and how architecture, security, interoperability, and other reviews and reports run
  • Configuration: repo connection, GitHub App, members, integrations

Overview

The default landing page for a project.

Overview pulls together the signals you most often need at a glance:

  • Activity heatmap & recent evolution: what changed and when
  • Current state: if you’ve connected your GitHub repo, this shows high level information about your system: tech stack, external services, key capabilities, and more
  • Recent changes feed: what in your system has changed in your recent commits?
  • Health by category: per-domain health signals derived from recent PR reviewer findings (rules, security, architecture, capabilities, impact, quality)
  • Guardrails in place: which structural protections are installed (CLI hooks, GitHub App, rule checks)

Activity

The audit log of every PR analysis run, commit attestation, and finding.

  • Commit attestations: how did your system change in this commit? Was a data flow altered? Was a capability added or removed?
  • PR reviews: what the per-domain evaluators surfaced in each PR (by category and severity)
  • Attribution and telemetry: which agents made which changes? how many tokens did they spend on each change? which rules were checked?

Filter by commit, git branch, agent, change category, etc. The same data is available from the CLI via gjalla log, which is most helpful when agents are planning and debugging.

Explore Specs & Docs

The live view of your system to keep your team in the loop, onboard your new teammates, and provide steering to your agents.

Sub-sections roughly correspond to categories of changes gjalla tracks per commit.

  • Code Structure

    High-level repo layout including the responsibilities and contents of each directory.

  • Architecture

    C4-style nested architecture diagram which can be viewed with varying levels of detail.

  • Data Model

    Domain entities, their attributes, and their associations.

  • Data Flows

    End-to-end paths data takes through the system, with data source, data sinks, and the steps taken in between. Can be viewed visually in the architecture diagram or as a sequence diagram.

  • Surface Area

    External surfaces of the codebase: API endpoints, webhooks, etc.

  • Capabilities

    Behavioral specs, aggregated using OpenSpec compatible formats built by your agents over time.

  • Tech Stack + Services

    Languages, frameworks, tools, and external services (with cost data where available).

  • Technical Glossary

    Project-specific terminology and definitions.

All of this is available to agents via the CLI and the MCP server.

Steering and Guardrails

The governance surface: what agents and humans should know and follow when they touch this codebase.

  • Rules

    Active checks and constraints. Available to your agents at implementation time to steer their work. The Rule Evaluator runs these on every PR (when Change Review is on).

  • Decisions

    Architectural decisions you've made (proposed, accepted, superseded).

  • Principles

    Guiding principles which inform how agents should design and implement changes. Used by the Semantic Rule Evaluator and surfaced as agent context.

  • Skills

    Reusable engineering patterns installed as native SKILL.md files during gjalla sync. A package of battle-tested skills come pre-packaged for you (can be toggled on or off as desired).

  • Context

    Custom context or guidance for your agents and collected memories (an alpha feature!).

Automations

Where you decide which evaluators run, when they run, and which ones block merges.

The page covers the Change Review master switch, per-domain code review evaluators, always-on signals, and reports. See Reviews and automations for what each control does.

Configuration

Project-level settings.

GitHub repo connection and the gjalla GitHub App, member access, integrations, etc.

Operational costs

Based on your codebase, gjalla catalogs your external services and matches them to our database of service costs, giving you one view of what your product costs to operate. Open Explore Specs & Docs → Tech Stack + Services to see each cataloged service with its cost details in the detail panel.

Estimates come from our database, but your usage, rates, or tier may differ. Click the edit icon next to a service to expand its row and adjust the base cost, usage cost, or units, then save.

Custom docs

Use gjalla’s understanding of your system to generate custom documentation for prospects, marketing material, or internal use. Custom Docs mix text and diagrams with sources for each fact, and they refresh automatically when PRs are merged, so they never go stale.

Open the Custom Docs view, type your question or desired output into the input box, and submit. gjalla uses your prompt and its analysis of your codebase to craft the document. It can take a couple of minutes.

Systems vs. projects

On Custom, you can group multiple projects into a System. The System workspace surfaces an aggregated Overview, Activity, and Explore view across every member project, so you can see the big picture architecture in one place. Mappings and integration surfaces can also be explicitly defined, and made available to your agents as steering at implementation time.

From the CLI, use gjalla log --system <id> to see interleaved change history across every project in a system, and --interop to focus on cross-service surface area and external services.