gjalla-log
The gjalla-log command displays semantic change history for a project, showing when architecture elements, rules, capabilities, and other primitives were created, modified, or deleted, along with timestamps and authors. Use this to audit structural evolution, understand when constraints changed, or investigate who modified specific components over a specified time window (default seven days).
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/gjalla/engineering/HEAD/commands/gjalla-log.md -o ~/.claude/commands/gjalla-log.mdgjalla-log.md
Show semantic change history for this project — what architecture elements, rules, capabilities, and other primitives changed, when, and by whom. 1. Use the gjalla CLI: `gjalla log` (this surface is CLI-first today). - Default: `gjalla log --since 7d` — last 7 days. - If the user specified a time window ($1): `gjalla log --since $1` - If the user specified a type ($2): `gjalla log --type $2` - For a specific element: `gjalla log --element architecture.api-server` - For a specific commit: `gjalla log --commit abc1234` 2. Present the changes as a timeline: - Group by commit (same commit SHA = one group) - Show date, short SHA, source (attestation vs analysis), author if available - For each change: primitive type, primitive id, change type (created/modified/deleted) - Highlight any rule changes — these affect constraints for future work 3. Suggested follow-ups: - "To understand a specific element's current state: /gjalla-context architecture" - "To see the impact of your uncommitted changes: /gjalla-impact" If gjalla MCP tools are not available, suggest: ``` gjalla log --since 7d gjalla log --type rule --since 30d ```
Create a commit attestation for your changes
Load architecture context for this repo
Master-spec delta — what changes in the system when this merges
Review a spec OR a code change against master spec, rules, and production readiness
Initialize gjalla in this repo
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.