Dev

.agents/skills/grill-me/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+Once we reach shared understanding, record the decisions and their reasoning as an ADR under `docs/adr/` (filename: `NNNN-<slug>.md`, sequential number).

.agents/skills/update-design/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: update-design
+description: Review or update repository design documents, compare them with the actual codebase, and surface concrete gaps before implementation proceeds. Use when working on docs/design, ADRs, architecture notes, or when a plan depends on design quality.
+---
+
+# update-design
+
+Review design documents against the current repository state and improve them before implementation depends on them.
+
+## Phase 1: Gather Context
+
+Read only what is relevant:
+
+1. `docs/design/*.md`, `docs/adr/*.md`, and architecture notes under `docs/`
+2. `docs/development-memo.md` when present
+3. the source directories touched by the design
+4. build manifests and CI workflows that constrain implementation
+5. `AGENT.md`
+
+If design docs do not exist, report that first and switch to proposing a minimal design outline derived from the current memo and README.
+
+## Phase 2: Evaluate the Design
+
+Score each relevant document across these categories:
+
+1. module and ownership boundaries
+2. data flow and control flow
+3. interfaces, types, and configuration surface
+4. failure modes, validation, and observability
+5. testing and rollout strategy
+
+Use a 100-point scale. Treat 90+ as ready for implementation.
+
+## Phase 3: Check Against the Code
+
+Confirm whether the design matches reality:
+
+1. documented modules exist
+2. names and paths match the codebase
+3. described behaviors are implemented or clearly marked as planned
+4. validation steps match the actual tooling
+
+Call out both directions:
+
+- documented but not implemented
+- implemented but undocumented
+
+## Phase 4: Produce Improvements
+
+Return a concise report in this shape:
+
+```markdown
+## Design Review
+
+### <document>
+| Category | Score |
+|---|---:|
+| Module boundaries | XX |
+| Data flow | XX |
+| Interfaces | XX |
+| Failure modes | XX |
+| Testing and rollout | XX |
+
+Average: XX.X
+
+Issues:
+- ...
+
+Recommended edits:
+- ...
+
+Code mismatch:
+- ...
+```
+
+## Editing Rules
+
+- keep design docs implementation-oriented
+- prefer concrete file paths, types, commands, and invariants
+- do not restate obvious code when a short reference is enough
+- if a design decision matters later, suggest an ADR under `docs/adr/`

.agents/skills/update-docs/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: update-docs
+description: Synchronize README, docs, and AGENT guidance with the actual codebase and tooling. Use when implementation changed commands, behavior, configuration, architecture, or project structure.
+---
+
+# update-docs
+
+Update repository documentation to match the current implementation.
+
+## Phase 1: Inspect the Current Source of Truth
+
+Read the smallest set of files that define behavior:
+
+1. entry points and changed source files
+2. build and dependency manifests
+3. CI workflows
+4. `README.md`, `docs/`, `AGENT.md`
+5. `docs/development-memo.md` when present
+
+Do not update docs from memory. Derive every command and path from the repository.
+
+## Phase 2: Update the Right Document
+
+Use this split:
+
+- `README.md`: how to install, run, configure, and use the project
+- `docs/`: design rationale, ADRs, requirements, internal notes
+- `AGENT.md`: repo-specific instructions for Codex
+
+For GitReal specifically, keep `README.md` and `docs/development-memo.md` aligned on:
+
+1. executable name `git-real`
+2. user-facing command `git real`
+3. safety model around `arm`, backups, and rescue
+4. planned Go-based architecture
+
+Common updates:
+
+1. build, test, lint, format, or release commands
+2. config file names and option descriptions
+3. module layout and entry points
+4. examples and sample outputs
+5. workflow or validation requirements
+
+## Phase 3: Consistency Check
+
+Verify consistency across docs:
+
+1. file paths
+2. command names
+3. option flags
+4. module names
+5. stated prerequisites
+
+If the repo has no established command for something, say that plainly instead of inventing one.
+
+## Phase 4: Report the Update
+
+Summarize in this form:
+
+```markdown
+## Documentation Update
+
+Updated:
+- <file>: <what changed>
+
+Open gaps:
+- ...
+
+Remaining assumptions:
+- ...
+```
+
+## Editing Rules
+
+- keep README user-facing and concise
+- keep developer guidance close to the code it explains
+- prefer exact commands over prose-only instructions
+- remove stale claims instead of softening them

.agents/skills/update-plan/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: update-plan
+description: Stress-test an implementation plan against the current codebase, design docs, and repo constraints before presenting it. Use for substantial plans, phased work, refactors, or multi-file features.
+---
+
+# update-plan
+
+Run this immediately before presenting a substantial implementation plan.
+
+## Phase 1: Gather Inputs
+
+Collect the minimum relevant context:
+
+1. the current draft plan
+2. `AGENT.md`
+3. related design docs, ADRs, requirements, roadmap items, issue notes, and `docs/development-memo.md`
+4. the source files and manifests the plan touches
+
+## Phase 2: Validate the Plan
+
+Check the plan for:
+
+1. correct assumptions about the current codebase
+2. independently verifiable steps
+3. separation of structural cleanup from behavior changes
+4. explicit validation for each risky step
+5. impact on docs, config, CI, and tests
+
+## Phase 3: Find Gaps
+
+Flag these issues by priority:
+
+- `P0`: plan contradicts code or requirements
+- `P1`: step ordering, missing validation, or unclear ownership
+- `P2`: useful follow-up work or documentation debt
+
+## Phase 4: Rewrite the Plan
+
+Return the improved plan with:
+
+1. ordered steps
+2. affected files or directories
+3. validation per step
+4. risks or dependencies
+5. missing design or documentation prerequisites
+
+Use this output shape:
+
+```markdown
+## Plan Check
+
+Issues:
+- P0: ...
+- P1: ...
+- P2: ...
+
+Revised plan:
+1. ...
+2. ...
+3. ...
+```
+
+## Plan Quality Bar
+
+- each step should change one coherent thing
+- each step should have an observable completion signal
+- broad refactors must justify why they cannot be split
+- if design is too vague, route back through `update-design`

.github/workflows/ci.yml

@@ -0,0 +1,21 @@
+name: ci
+
+on:
+  pull_request:
+  push:
+    branches:
+      - main
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: go.mod
+
+      - run: go mod download
+      - run: make check

.github/workflows/release.yml

@@ -0,0 +1,88 @@
+name: release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+permissions:
+  contents: write
+
+jobs:
+  build-release:
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - goos: darwin
+            goarch: amd64
+            archive_ext: tar.gz
+            binary_name: git-real
+          - goos: darwin
+            goarch: arm64
+            archive_ext: tar.gz
+            binary_name: git-real
+          - goos: linux
+            goarch: amd64
+            archive_ext: tar.gz
+            binary_name: git-real
+          - goos: linux
+            goarch: arm64
+            archive_ext: tar.gz
+            binary_name: git-real
+          - goos: windows
+            goarch: amd64
+            archive_ext: zip
+            binary_name: git-real.exe
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-go@v5
+        with:
+          go-version-file: go.mod
+
+      - run: go mod download
+
+      - name: Build archive
+        run: |
+          set -euo pipefail
+          artifact_name="git-real_${{ matrix.goos }}_${{ matrix.goarch }}"
+          archive_name="${artifact_name}.${{ matrix.archive_ext }}"
+
+          mkdir -p "dist/${artifact_name}"
+
+          GOOS="${{ matrix.goos }}" GOARCH="${{ matrix.goarch }}" go build -o "dist/${artifact_name}/${{ matrix.binary_name }}" ./cmd/git-real
+
+          if [ "${{ matrix.archive_ext }}" = "zip" ]; then
+            zip -j "dist/${archive_name}" "dist/${artifact_name}/${{ matrix.binary_name }}"
+          else
+            tar -C dist -czf "dist/${archive_name}" "${artifact_name}"
+          fi
+
+      - uses: actions/upload-artifact@v4
+        with:
+          name: release-${{ matrix.goos }}-${{ matrix.goarch }}
+          path: dist/*.*
+          if-no-files-found: error
+
+  publish-release:
+    runs-on: ubuntu-latest
+    needs: build-release
+
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          path: dist
+          pattern: release-*
+          merge-multiple: true
+
+      - name: Generate checksums
+        run: |
+          set -euo pipefail
+          sha256sum dist/* > dist/SHA256SUMS
+
+      - uses: softprops/action-gh-release@v2
+        with:
+          files: dist/*

.gitignore

@@ -141,3 +141,8 @@ dist
 vite.config.js.timestamp-*
 vite.config.ts.timestamp-*
 .vite/
+
+# Go
+.cache/
+coverage.out
+/git-real