gjalla-setup
The gjalla-setup command initializes gjalla in a repository by installing the CLI tool if needed, connecting the repo to a gjalla project through interactive setup, syncing local cache, and optionally bootstrapping architecture context from the codebase. Use this command when first integrating gjalla into a repository to enable architecture analysis and MCP tools for code review and context exploration.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/gjalla/engineering/HEAD/commands/gjalla-setup.md -o ~/.claude/commands/gjalla-setup.mdgjalla-setup.md
Initialize gjalla in the current repository. Run the setup flow to connect this repo to a gjalla project. 1. Check if gjalla CLI is installed: `gjalla --version` - If not installed, tell the user: "gjalla CLI is required. Install with: pip install gjalla" - Stop and wait for the user to install. 2. Check current status: `gjalla status` - If already configured, report the current project connection and cache status. - Ask if the user wants to reconfigure or just sync. 3. If not configured, run: `gjalla setup` - This walks through project selection/creation and API key configuration. - Follow the interactive prompts. 4. After setup, sync the local cache: `gjalla sync` 5. If the project was just created via CLI (not connected via GitHub App), run `gjalla state bootstrap` to generate initial architecture context from the local codebase. This analyzes the repo and creates gjallastate/gjallamap/gjallarules locally so MCP tools return architecture data immediately. For GitHub App-connected projects, cloud analysis triggers automatically — bootstrap is not needed. 6. Verify everything works by querying the live MCP: call `get_project_state(metadata_only=true)` to confirm the connection and show project size. 7. Report to the user: - Project name and ID - Number of architecture elements, rules, and capabilities loaded - Available MCP tools - Suggest next steps: "Try /gjalla-context to explore your architecture, or /gjalla-review to review your current changes."
Create a commit attestation for your changes
Load architecture context for this repo
Master-spec delta — what changes in the system when this merges
Show recent semantic change history
Review a spec OR a code change against master spec, rules, and production readiness
Break a feature spec into intentional waves and bite-sized tasks grouped by dependency. Use after a spec is written to prepare for easy-to-track implementation.
Review a code change (diff or PR) for ship-readiness before merge. Use when reviewing your own or someone else's changes prior to committing/merging/etc.
Make sure your code is ready to commit, then stage changes into clean, atomic commit. Use before committing.