Slash Command2 repo starsupdated 2d ago

gjalla-attest

gjalla-attest creates a structured accountability record for code commits by documenting what changed, why it changed, and which architectural rules were checked. Use it after making code changes to generate a two-phase attestation that assesses impact across eight dimensions (architecture, data model, data flows, rules, capabilities, API surface, dependencies, tech stack) and validates compliance before finalizing.

View source Repository: engineering

Install in Claude Code

Copy

mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/gjalla/engineering/HEAD/commands/gjalla-attest.md -o ~/.claude/commands/gjalla-attest.md

Then start a new Claude Code session; the slash command loads automatically.

Definition

gjalla-attest.md

Create an attestation documenting what changed, why, and which rules were checked.
Attestations create an accountability trail for every commit — especially important
when AI agents are writing code.

1. Check what has changed: `git diff --stat HEAD`
- If no changes, tell the user there's nothing to attest and stop.

2. Load the master spec using `get_architecture_spec` MCP tool.
- Identify which architecture elements are affected by the changes.
- Drill in with `get_architecture_element_details(elementId="...")` when an
element's behavior or boundary is materially changing.

3. Load rules using `get_project_rules` MCP tool.
- Identify which rules are scoped to the affected elements.

4. Draft the attestation using the gjalla CLI: `gjalla attest`.
- This is a two-phase process: first draft, then finalize.
- The draft covers all eight primitives: architecture, data model, data flows,
rules, capabilities, API surface, external dependencies, tech stack.
- (Write APIs route through the CLI; the MCP server is read-mostly today.)

5. For each primitive, assess: did this change affect it?
- If yes, document what changed and why.
- If no, mark as `changed: false`.

6. Check rule compliance:
- For each applicable rule, report: COMPLIANT / NOT APPLICABLE / NEEDS REVIEW.
- If any rule is violated, flag it explicitly with the reason.

7. Write a summary that explains the *why*, not just the *what*.
- Bad: "Added rate limiting"
- Good: "Token-bucket rate limiting on auth endpoints protects against credential-stuffing;
chose gateway-level enforcement over per-service to avoid duplicating config."

8. Present the attestation to the user for review before finalizing.

9. After user approval, finalize using `prepare_attestation` (phase 2).

If gjalla MCP tools are not available, create a manual attestation by:
- Reading the git diff
- Documenting changes across the eight primitives
- Writing the attestation to `.gjalla/attestations/` in the repo