feat: add GitHub issue fix command and release command

- Introduced a new command for fetching and validating GitHub issues, allowing users to address issues directly from the command line.
- Added a release command to bump the version of the application and build the Electron app, ensuring version consistency across UI and server packages.
- Updated package.json files for both UI and server to version 0.7.1, reflecting the latest changes.
- Implemented version utility in the server to read the version from package.json, enhancing version management across the application.

.claude/commands/gh-issue.md

@@ -0,0 +1,74 @@
+# GitHub Issue Fix Command
+
+Fetch a GitHub issue by number, verify it's a real issue, and fix it if valid.
+
+## Usage
+
+This command accepts a GitHub issue number as input (e.g., `123`).
+
+## Instructions
+
+1. **Get the issue number from the user**
+   - The issue number should be provided as an argument to this command
+   - If no number is provided, ask the user for it
+
+2. **Fetch the GitHub issue**
+   - Determine the current project path (check if there's a current project context)
+   - Verify the project has a GitHub remote:
+     ```bash
+     git remote get-url origin
+     ```
+   - Fetch the issue details using GitHub CLI:
+     ```bash
+     gh issue view <ISSUE_NUMBER> --json number,title,state,author,createdAt,labels,url,body,assignees
+     ```
+   - If the command fails, report the error and stop
+
+3. **Verify the issue is real and valid**
+   - Check that the issue exists (not 404)
+   - Check the issue state:
+     - If **closed**: Inform the user and ask if they still want to proceed
+     - If **open**: Proceed with validation
+   - Review the issue content:
+     - Read the title and body to understand what needs to be fixed
+     - Check labels for context (bug, enhancement, etc.)
+     - Note any assignees or linked PRs
+
+4. **Validate the issue**
+   - Determine if this is a legitimate issue that needs fixing:
+     - Is the description clear and actionable?
+     - Does it describe a real problem or feature request?
+     - Are there any obvious signs it's spam or invalid?
+   - If the issue seems invalid or unclear:
+     - Report findings to the user
+     - Ask if they want to proceed anyway
+     - Stop if user confirms it's not valid
+
+5. **If the issue is valid, proceed to fix it**
+   - Analyze what needs to be done based on the issue description
+   - Check the current codebase state:
+     - Run relevant tests to see current behavior
+     - Check if the issue is already fixed
+     - Look for related code that might need changes
+   - Implement the fix:
+     - Make necessary code changes
+     - Update or add tests as needed
+     - Ensure the fix addresses the issue description
+   - Verify the fix:
+     - Run tests to ensure nothing broke
+     - If possible, manually verify the fix addresses the issue
+
+6. **Report summary**
+   - Issue number and title
+   - Issue state (open/closed)
+   - Whether the issue was validated as real
+   - What was fixed (if anything)
+   - Any tests that were updated or added
+   - Next steps (if any)
+
+## Error Handling
+
+- If GitHub CLI (`gh`) is not installed or authenticated, report error and stop
+- If the project doesn't have a GitHub remote, report error and stop
+- If the issue number doesn't exist, report error and stop
+- If the issue is unclear or invalid, report findings and ask user before proceeding

.claude/commands/release.md

@@ -0,0 +1,56 @@
+# Release Command
+
+Bump the package.json version (major, minor, or patch) and build the Electron app with the new version.
+
+## Usage
+
+This command accepts a version bump type as input:
+
+- `patch` - Bump patch version (0.1.0 -> 0.1.1)
+- `minor` - Bump minor version (0.1.0 -> 0.2.0)
+- `major` - Bump major version (0.1.0 -> 1.0.0)
+
+## Instructions
+
+1. **Get the bump type from the user**
+   - The bump type should be provided as an argument (patch, minor, or major)
+   - If no type is provided, ask the user which type they want
+
+2. **Bump the version**
+   - Run the version bump script:
+     ```bash
+     node apps/ui/scripts/bump-version.mjs <type>
+     ```
+   - This updates both `apps/ui/package.json` and `apps/server/package.json` with the new version (keeps them in sync)
+   - Verify the version was updated correctly by checking the output
+
+3. **Build the Electron app**
+   - Run the electron build:
+     ```bash
+     npm run build:electron --workspace=apps/ui
+     ```
+   - The build process automatically:
+     - Uses the version from `package.json` for artifact names (e.g., `Automaker-1.2.3-x64.zip`)
+     - Injects the version into the app via Vite's `__APP_VERSION__` constant
+     - Displays the version below the logo in the sidebar
+
+4. **Verify the release**
+   - Check that the build completed successfully
+   - Confirm the version appears correctly in the built artifacts
+   - The version will be displayed in the app UI below the logo
+
+## Version Centralization
+
+The version is centralized and synchronized in both `apps/ui/package.json` and `apps/server/package.json`:
+
+- **Electron builds**: Automatically read from `apps/ui/package.json` via electron-builder's `${version}` variable in `artifactName`
+- **App display**: Injected at build time via Vite's `define` config as `__APP_VERSION__` constant (defined in `apps/ui/vite.config.mts`)
+- **Server API**: Read from `apps/server/package.json` via `apps/server/src/lib/version.ts` utility (used in health check endpoints)
+- **Type safety**: Defined in `apps/ui/src/vite-env.d.ts` as `declare const __APP_VERSION__: string`
+
+This ensures consistency across:
+
+- Build artifact names (e.g., `Automaker-1.2.3-x64.zip`)
+- App UI display (shown as `v1.2.3` below the logo in `apps/ui/src/components/layout/sidebar/components/automaker-logo.tsx`)
+- Server health endpoints (`/` and `/detailed`)
+- Package metadata (both UI and server packages stay in sync)