{"owner":"simulot","repo":"immich-go","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":2444,"categories":["gemini-rule","copilot-instructions","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"immich-go":{"command":"npx","args":["-y","@modelcontextprotocol/server-immich-go"]}}},"found":["GEMINI.md",".github/copilot-instructions.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"GEMINI.md":"# GEMINI.md\n\nread instructions in .github/copilot-instructions.md for more details on development conventions and release note generation.\n\n\n## Project Overview\n\nThis project, `immich-go`, is a command-line tool written in Go. Its primary purpose is to provide an efficient way to upload large photo and video collections to a self-hosted [Immich](https://immich.app/) server.\n\nIt is designed as a cross-platform application (Windows, macOS, Linux, FreeBSD) with no external dependencies like Node.js or Docker, making it easy to install and use.\n\nKey features include:\n-   Uploading from multiple sources: local folders, Google Photos Takeout archives, iCloud, and even other Immich servers.\n-   Smart management of assets, including duplicate detection, photo stacking (bursts, RAW+JPEG), and metadata handling.\n-   A rich set of commands for interacting with Immich, such as `upload`, `archive`, and `stack`.\n\nThe project uses the Cobra library for its CLI structure and `goreleaser` to manage its release process.\n\n## Building and Running\n\n### Prerequisites\n\n-   Go (version 1.25 or higher, as specified in `go.mod`)\n\n### Building the Application\n\nTo build the application from the source, run the following command from the project root:\n\n```sh\ngo build -o immich-go main.go\n```\n\nFor a production-ready, statically linked binary similar to the CI build, use:\n\n```sh\nCGO_ENABLED=0 go build -ldflags=\"-s -w -extldflags=-static\" -o immich-go main.go\n```\n\n### Running the Application\n\nOnce built, the application can be run directly from the command line:\n\n```sh\n./immich-go --help\n```\n\nThe main commands are `upload`, `archive`, and `stack`. Here is a basic usage example:\n\n```sh\n./immich-go upload from-folder --server http://your-immich-server:2283 --api-key YOUR_API_KEY /path/to/photos\n```\n\n## Development\n\n### Testing\n\nThe project has both unit and end-to-end (E2E) tests.\n\n**Unit Tests:**\n\nRun all unit tests with race condition detection and coverage:\n\n```sh\ngo test -race -v -count=1 -coverprofile=coverage.out ./...\n```\n\n**End-to-End (E2E) Tests:**\n\nE2E tests require a running Immich server and are run against a specific client test suite.\n\n```sh\n# Navigate to the E2E client directory\ncd internal/e2e/client\n\n# Run the E2E tests\ngo test -v -tags=e2e -timeout=30m ./...\n```\n\n### Linting\n\nThe project uses `golangci-lint` for code quality. To run the linter, you can use the `golangci-lint` command:\n\n```sh\ngolangci-lint run\n```\n\nThis is also integrated into the CI pipeline.\n\n",".github/copilot-instructions.md":"You are helping me for the design. don't update the code if not explicitly requested\n\nDon't write reasoning documentation \n    except is this is explicitly requested. Write it in the scratchpad folder.\n\nWhen implementing an immich end point, \n    refer to the api specifications located at .github/immich-api-monitor/immich-openapi-specs-baseline.json\n\nNever commit the code by yourself.\n   prepare the commit message and ask for confirmation before \n\n## Release Notes Generation\n\nWhen asked to generate release notes:\n1. Use the script: `./scripts/generate-release-notes.sh [version]`\n   - Example: `./scripts/generate-release-notes.sh v0.30.0`\n   - Without version, it defaults to \"NEXT\"\n\n2. The script will:\n   - Find commits since the last stable release\n   - Generate a prompt file: `release-notes-prompt.txt`\n   - if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n   - Create target file: `docs/releases/release-notes-[version].md`\n\n3. Process the prompt with this chat to generate the final release notes\n\n4. Release notes should be categorized as:\n   - ✨ New Features (user-visible functionality)\n   - 🚀 Improvements (enhancements to existing features)\n   - 🐛 Bug Fixes (fixes to existing functionality)\n   - 💥 Breaking Changes (changes requiring user action)\n   - 🔧 Internal Changes (refactoring, CI/CD, tests - only if significant)\n\n5. Guidelines:\n   - Remove technical prefixes (feat:, fix:, chore:, refactor:, doc:, e2e:, test:)\n   - Write from user's perspective\n   - Combine related commits\n   - Start with a brief, friendly introduction. Be concise and professional.\n   - Explain CLI changes, list concerned flags, add examples if needed\n   - Skip mean less commits (e.g., \"update README\", \"fix typo\")\n   - Skip purely internal changes unless they significantly impact users\n   \n\n## commit messages generation\n  - use conventional commit style\n  - the commit title should prioritize features that affects the user experience\n  - the commit details list other changes\n  - maintain a provisional change log in the folder scratchpad\n  - but newer commit scratchpad content\n  - only changes in the command line options are concidered as breaking change. The project is not about publish an API or a library.\n\n## prepare a pull-request to merge with the develop branch\n\n- if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n- use the git commits messages\n- use the provisional change log in the folder scratchpad if present \n- the pull-request should be named: `feature: [feature]`\n\n## prepare a pull-request to merge with the main branch\n\n- propose the new version using semantic versioning\n- be sure that the file `docs/releases/release-notes-[version].md` exists or generate it.\n- if the `docs/releases/release-notes-[NEXT].md` exists, it will be used as a base, and rename it with the new version number\n- the pull-request should be named: `release: [version]`\n\n\n\n## Development Conventions\n\n-   **Branching:** The project follows a specific branching strategy.\n    -   `feature/*` and `bugfix/*` branches should be based on and merged into `develop`.\n    -   `hotfix/*` branches should be based on and merged into `main`.\n-   **Commits:** While not strictly enforced, it's good practice to follow conventional commit message formats.\n-   **Dependencies:** Manage dependencies using Go modules (`go.mod` and `go.sum`).\n-   **Contributing:** Refer to `CONTRIBUTING.md` for more detailed contribution guidelines.\n\n\n## Working on a new feature\n\n- Storyboarding and design discussions should be documented in the `scratchpad/` directory.\n- Implementation progress and summaries should also be documented in the `scratchpad/` directory.   \n- propose unit tests for testing tricky aspects of the feature\n- propose e2e tests:\n    - explain the case to be tested: \n    - propose a description of test data needed for the test. \n    - I'll provide the data and files for the test\n    - ensure that the entire upload process works as expected, including file discovery, processing, and uploading to the Immich server.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/plugin.json)"},"files":{"GEMINI.md":"# GEMINI.md\n\nread instructions in .github/copilot-instructions.md for more details on development conventions and release note generation.\n\n\n## Project Overview\n\nThis project, `immich-go`, is a command-line tool written in Go. Its primary purpose is to provide an efficient way to upload large photo and video collections to a self-hosted [Immich](https://immich.app/) server.\n\nIt is designed as a cross-platform application (Windows, macOS, Linux, FreeBSD) with no external dependencies like Node.js or Docker, making it easy to install and use.\n\nKey features include:\n-   Uploading from multiple sources: local folders, Google Photos Takeout archives, iCloud, and even other Immich servers.\n-   Smart management of assets, including duplicate detection, photo stacking (bursts, RAW+JPEG), and metadata handling.\n-   A rich set of commands for interacting with Immich, such as `upload`, `archive`, and `stack`.\n\nThe project uses the Cobra library for its CLI structure and `goreleaser` to manage its release process.\n\n## Building and Running\n\n### Prerequisites\n\n-   Go (version 1.25 or higher, as specified in `go.mod`)\n\n### Building the Application\n\nTo build the application from the source, run the following command from the project root:\n\n```sh\ngo build -o immich-go main.go\n```\n\nFor a production-ready, statically linked binary similar to the CI build, use:\n\n```sh\nCGO_ENABLED=0 go build -ldflags=\"-s -w -extldflags=-static\" -o immich-go main.go\n```\n\n### Running the Application\n\nOnce built, the application can be run directly from the command line:\n\n```sh\n./immich-go --help\n```\n\nThe main commands are `upload`, `archive`, and `stack`. Here is a basic usage example:\n\n```sh\n./immich-go upload from-folder --server http://your-immich-server:2283 --api-key YOUR_API_KEY /path/to/photos\n```\n\n## Development\n\n### Testing\n\nThe project has both unit and end-to-end (E2E) tests.\n\n**Unit Tests:**\n\nRun all unit tests with race condition detection and coverage:\n\n```sh\ngo test -race -v -count=1 -coverprofile=coverage.out ./...\n```\n\n**End-to-End (E2E) Tests:**\n\nE2E tests require a running Immich server and are run against a specific client test suite.\n\n```sh\n# Navigate to the E2E client directory\ncd internal/e2e/client\n\n# Run the E2E tests\ngo test -v -tags=e2e -timeout=30m ./...\n```\n\n### Linting\n\nThe project uses `golangci-lint` for code quality. To run the linter, you can use the `golangci-lint` command:\n\n```sh\ngolangci-lint run\n```\n\nThis is also integrated into the CI pipeline.\n\n",".github/copilot-instructions.md":"You are helping me for the design. don't update the code if not explicitly requested\n\nDon't write reasoning documentation \n    except is this is explicitly requested. Write it in the scratchpad folder.\n\nWhen implementing an immich end point, \n    refer to the api specifications located at .github/immich-api-monitor/immich-openapi-specs-baseline.json\n\nNever commit the code by yourself.\n   prepare the commit message and ask for confirmation before \n\n## Release Notes Generation\n\nWhen asked to generate release notes:\n1. Use the script: `./scripts/generate-release-notes.sh [version]`\n   - Example: `./scripts/generate-release-notes.sh v0.30.0`\n   - Without version, it defaults to \"NEXT\"\n\n2. The script will:\n   - Find commits since the last stable release\n   - Generate a prompt file: `release-notes-prompt.txt`\n   - if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n   - Create target file: `docs/releases/release-notes-[version].md`\n\n3. Process the prompt with this chat to generate the final release notes\n\n4. Release notes should be categorized as:\n   - ✨ New Features (user-visible functionality)\n   - 🚀 Improvements (enhancements to existing features)\n   - 🐛 Bug Fixes (fixes to existing functionality)\n   - 💥 Breaking Changes (changes requiring user action)\n   - 🔧 Internal Changes (refactoring, CI/CD, tests - only if significant)\n\n5. Guidelines:\n   - Remove technical prefixes (feat:, fix:, chore:, refactor:, doc:, e2e:, test:)\n   - Write from user's perspective\n   - Combine related commits\n   - Start with a brief, friendly introduction. Be concise and professional.\n   - Explain CLI changes, list concerned flags, add examples if needed\n   - Skip mean less commits (e.g., \"update README\", \"fix typo\")\n   - Skip purely internal changes unless they significantly impact users\n   \n\n## commit messages generation\n  - use conventional commit style\n  - the commit title should prioritize features that affects the user experience\n  - the commit details list other changes\n  - maintain a provisional change log in the folder scratchpad\n  - but newer commit scratchpad content\n  - only changes in the command line options are concidered as breaking change. The project is not about publish an API or a library.\n\n## prepare a pull-request to merge with the develop branch\n\n- if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n- use the git commits messages\n- use the provisional change log in the folder scratchpad if present \n- the pull-request should be named: `feature: [feature]`\n\n## prepare a pull-request to merge with the main branch\n\n- propose the new version using semantic versioning\n- be sure that the file `docs/releases/release-notes-[version].md` exists or generate it.\n- if the `docs/releases/release-notes-[NEXT].md` exists, it will be used as a base, and rename it with the new version number\n- the pull-request should be named: `release: [version]`\n\n\n\n## Development Conventions\n\n-   **Branching:** The project follows a specific branching strategy.\n    -   `feature/*` and `bugfix/*` branches should be based on and merged into `develop`.\n    -   `hotfix/*` branches should be based on and merged into `main`.\n-   **Commits:** While not strictly enforced, it's good practice to follow conventional commit message formats.\n-   **Dependencies:** Manage dependencies using Go modules (`go.mod` and `go.sum`).\n-   **Contributing:** Refer to `CONTRIBUTING.md` for more detailed contribution guidelines.\n\n\n## Working on a new feature\n\n- Storyboarding and design discussions should be documented in the `scratchpad/` directory.\n- Implementation progress and summaries should also be documented in the `scratchpad/` directory.   \n- propose unit tests for testing tricky aspects of the feature\n- propose e2e tests:\n    - explain the case to be tested: \n    - propose a description of test data needed for the test. \n    - I'll provide the data and files for the test\n    - ensure that the entire upload process works as expected, including file discovery, processing, and uploading to the Immich server.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"GEMINI.md","path":"GEMINI.md","rawUrl":"https://raw.githubusercontent.com/simulot/immich-go/HEAD/GEMINI.md","title":"Gemini Agent & Antigravity Instructions","category":"gemini-rule","format":"markdown","content":"# GEMINI.md\n\nread instructions in .github/copilot-instructions.md for more details on development conventions and release note generation.\n\n\n## Project Overview\n\nThis project, `immich-go`, is a command-line tool written in Go. Its primary purpose is to provide an efficient way to upload large photo and video collections to a self-hosted [Immich](https://immich.app/) server.\n\nIt is designed as a cross-platform application (Windows, macOS, Linux, FreeBSD) with no external dependencies like Node.js or Docker, making it easy to install and use.\n\nKey features include:\n-   Uploading from multiple sources: local folders, Google Photos Takeout archives, iCloud, and even other Immich servers.\n-   Smart management of assets, including duplicate detection, photo stacking (bursts, RAW+JPEG), and metadata handling.\n-   A rich set of commands for interacting with Immich, such as `upload`, `archive`, and `stack`.\n\nThe project uses the Cobra library for its CLI structure and `goreleaser` to manage its release process.\n\n## Building and Running\n\n### Prerequisites\n\n-   Go (version 1.25 or higher, as specified in `go.mod`)\n\n### Building the Application\n\nTo build the application from the source, run the following command from the project root:\n\n```sh\ngo build -o immich-go main.go\n```\n\nFor a production-ready, statically linked binary similar to the CI build, use:\n\n```sh\nCGO_ENABLED=0 go build -ldflags=\"-s -w -extldflags=-static\" -o immich-go main.go\n```\n\n### Running the Application\n\nOnce built, the application can be run directly from the command line:\n\n```sh\n./immich-go --help\n```\n\nThe main commands are `upload`, `archive`, and `stack`. Here is a basic usage example:\n\n```sh\n./immich-go upload from-folder --server http://your-immich-server:2283 --api-key YOUR_API_KEY /path/to/photos\n```\n\n## Development\n\n### Testing\n\nThe project has both unit and end-to-end (E2E) tests.\n\n**Unit Tests:**\n\nRun all unit tests with race condition detection and coverage:\n\n```sh\ngo test -race -v -count=1 -coverprofile=coverage.out ./...\n```\n\n**End-to-End (E2E) Tests:**\n\nE2E tests require a running Immich server and are run against a specific client test suite.\n\n```sh\n# Navigate to the E2E client directory\ncd internal/e2e/client\n\n# Run the E2E tests\ngo test -v -tags=e2e -timeout=30m ./...\n```\n\n### Linting\n\nThe project uses `golangci-lint` for code quality. To run the linter, you can use the `golangci-lint` command:\n\n```sh\ngolangci-lint run\n```\n\nThis is also integrated into the CI pipeline.\n\n","isInternal":false,"tokens":620,"sizeBytes":2489},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/simulot/immich-go/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"You are helping me for the design. don't update the code if not explicitly requested\n\nDon't write reasoning documentation \n    except is this is explicitly requested. Write it in the scratchpad folder.\n\nWhen implementing an immich end point, \n    refer to the api specifications located at .github/immich-api-monitor/immich-openapi-specs-baseline.json\n\nNever commit the code by yourself.\n   prepare the commit message and ask for confirmation before \n\n## Release Notes Generation\n\nWhen asked to generate release notes:\n1. Use the script: `./scripts/generate-release-notes.sh [version]`\n   - Example: `./scripts/generate-release-notes.sh v0.30.0`\n   - Without version, it defaults to \"NEXT\"\n\n2. The script will:\n   - Find commits since the last stable release\n   - Generate a prompt file: `release-notes-prompt.txt`\n   - if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n   - Create target file: `docs/releases/release-notes-[version].md`\n\n3. Process the prompt with this chat to generate the final release notes\n\n4. Release notes should be categorized as:\n   - ✨ New Features (user-visible functionality)\n   - 🚀 Improvements (enhancements to existing features)\n   - 🐛 Bug Fixes (fixes to existing functionality)\n   - 💥 Breaking Changes (changes requiring user action)\n   - 🔧 Internal Changes (refactoring, CI/CD, tests - only if significant)\n\n5. Guidelines:\n   - Remove technical prefixes (feat:, fix:, chore:, refactor:, doc:, e2e:, test:)\n   - Write from user's perspective\n   - Combine related commits\n   - Start with a brief, friendly introduction. Be concise and professional.\n   - Explain CLI changes, list concerned flags, add examples if needed\n   - Skip mean less commits (e.g., \"update README\", \"fix typo\")\n   - Skip purely internal changes unless they significantly impact users\n   \n\n## commit messages generation\n  - use conventional commit style\n  - the commit title should prioritize features that affects the user experience\n  - the commit details list other changes\n  - maintain a provisional change log in the folder scratchpad\n  - but newer commit scratchpad content\n  - only changes in the command line options are concidered as breaking change. The project is not about publish an API or a library.\n\n## prepare a pull-request to merge with the develop branch\n\n- if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n- use the git commits messages\n- use the provisional change log in the folder scratchpad if present \n- the pull-request should be named: `feature: [feature]`\n\n## prepare a pull-request to merge with the main branch\n\n- propose the new version using semantic versioning\n- be sure that the file `docs/releases/release-notes-[version].md` exists or generate it.\n- if the `docs/releases/release-notes-[NEXT].md` exists, it will be used as a base, and rename it with the new version number\n- the pull-request should be named: `release: [version]`\n\n\n\n## Development Conventions\n\n-   **Branching:** The project follows a specific branching strategy.\n    -   `feature/*` and `bugfix/*` branches should be based on and merged into `develop`.\n    -   `hotfix/*` branches should be based on and merged into `main`.\n-   **Commits:** While not strictly enforced, it's good practice to follow conventional commit message formats.\n-   **Dependencies:** Manage dependencies using Go modules (`go.mod` and `go.sum`).\n-   **Contributing:** Refer to `CONTRIBUTING.md` for more detailed contribution guidelines.\n\n\n## Working on a new feature\n\n- Storyboarding and design discussions should be documented in the `scratchpad/` directory.\n- Implementation progress and summaries should also be documented in the `scratchpad/` directory.   \n- propose unit tests for testing tricky aspects of the feature\n- propose e2e tests:\n    - explain the case to be tested: \n    - propose a description of test data needed for the test. \n    - I'll provide the data and files for the test\n    - ensure that the entire upload process works as expected, including file discovery, processing, and uploading to the Immich server.\n","isInternal":false,"tokens":924,"sizeBytes":4130},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":196},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":182},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/simulot/immich-go/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":175}],"systemPromptSnippet":"<yakaai_skills repo=\"simulot/immich-go\">\n<!-- File: GEMINI.md (Tokens: ~620 | Category: gemini-rule) -->\n# GEMINI.md\n\nread instructions in .github/copilot-instructions.md for more details on development conventions and release note generation.\n\n\n## Project Overview\n\nThis project, `immich-go`, is a command-line tool written in Go. Its primary purpose is to provide an efficient way to upload large photo and video collections to a self-hosted [Immich](https://immich.app/) server.\n\nIt is designed as a cross-platform application (Windows, macOS, Linux, FreeBSD) with no external dependencies like Node.js or Docker, making it easy to install and use.\n\nKey features include:\n-   Uploading from multiple sources: local folders, Google Photos Takeout archives, iCloud, and even other Immich servers.\n-   Smart management of assets, including duplicate detection, photo stacking (bursts, RAW+JPEG), and metadata handling.\n-   A rich set of commands for interacting with Immich, such as `upload`, `archive`, and `stack`.\n\nThe project uses the Cobra library for its CLI structure and `goreleaser` to manage its release process.\n\n## Building and Running\n\n### Prerequisites\n\n-   Go (version 1.25 or higher, as specified in `go.mod`)\n\n### Building the Application\n\nTo build the application from the source, run the following command from the project root:\n\n```sh\ngo build -o immich-go main.go\n```\n\nFor a production-ready, statically linked binary similar to the CI build, use:\n\n```sh\nCGO_ENABLED=0 go build -ldflags=\"-s -w -extldflags=-static\" -o immich-go main.go\n```\n\n### Running the Application\n\nOnce built, the application can be run directly from the command line:\n\n```sh\n./immich-go --help\n```\n\nThe main commands are `upload`, `archive`, and `stack`. Here is a basic usage example:\n\n```sh\n./immich-go upload from-folder --server http://your-immich-server:2283 --api-key YOUR_API_KEY /path/to/photos\n```\n\n## Development\n\n### Testing\n\nThe project has both unit and end-to-end (E2E) tests.\n\n**Unit Tests:**\n\nRun all unit tests with race condition detection and coverage:\n\n```sh\ngo test -race -v -count=1 -coverprofile=coverage.out ./...\n```\n\n**End-to-End (E2E) Tests:**\n\nE2E tests require a running Immich server and are run against a specific client test suite.\n\n```sh\n# Navigate to the E2E client directory\ncd internal/e2e/client\n\n# Run the E2E tests\ngo test -v -tags=e2e -timeout=30m ./...\n```\n\n### Linting\n\nThe project uses `golangci-lint` for code quality. To run the linter, you can use the `golangci-lint` command:\n\n```sh\ngolangci-lint run\n```\n\nThis is also integrated into the CI pipeline.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~924 | Category: copilot-instructions) -->\nYou are helping me for the design. don't update the code if not explicitly requested\n\nDon't write reasoning documentation \n    except is this is explicitly requested. Write it in the scratchpad folder.\n\nWhen implementing an immich end point, \n    refer to the api specifications located at .github/immich-api-monitor/immich-openapi-specs-baseline.json\n\nNever commit the code by yourself.\n   prepare the commit message and ask for confirmation before \n\n## Release Notes Generation\n\nWhen asked to generate release notes:\n1. Use the script: `./scripts/generate-release-notes.sh [version]`\n   - Example: `./scripts/generate-release-notes.sh v0.30.0`\n   - Without version, it defaults to \"NEXT\"\n\n2. The script will:\n   - Find commits since the last stable release\n   - Generate a prompt file: `release-notes-prompt.txt`\n   - if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n   - Create target file: `docs/releases/release-notes-[version].md`\n\n3. Process the prompt with this chat to generate the final release notes\n\n4. Release notes should be categorized as:\n   - ✨ New Features (user-visible functionality)\n   - 🚀 Improvements (enhancements to existing features)\n   - 🐛 Bug Fixes (fixes to existing functionality)\n   - 💥 Breaking Changes (changes requiring user action)\n   - 🔧 Internal Changes (refactoring, CI/CD, tests - only if significant)\n\n5. Guidelines:\n   - Remove technical prefixes (feat:, fix:, chore:, refactor:, doc:, e2e:, test:)\n   - Write from user's perspective\n   - Combine related commits\n   - Start with a brief, friendly introduction. Be concise and professional.\n   - Explain CLI changes, list concerned flags, add examples if needed\n   - Skip mean less commits (e.g., \"update README\", \"fix typo\")\n   - Skip purely internal changes unless they significantly impact users\n   \n\n## commit messages generation\n  - use conventional commit style\n  - the commit title should prioritize features that affects the user experience\n  - the commit details list other changes\n  - maintain a provisional change log in the folder scratchpad\n  - but newer commit scratchpad content\n  - only changes in the command line options are concidered as breaking change. The project is not about publish an API or a library.\n\n## prepare a pull-request to merge with the develop branch\n\n- if the file: `docs/releases/release-notes-[version].md` already exists, it will be used as a base\n- use the git commits messages\n- use the provisional change log in the folder scratchpad if present \n- the pull-request should be named: `feature: [feature]`\n\n## prepare a pull-request to merge with the main branch\n\n- propose the new version using semantic versioning\n- be sure that the file `docs/releases/release-notes-[version].md` exists or generate it.\n- if the `docs/releases/release-notes-[NEXT].md` exists, it will be used as a base, and rename it with the new version number\n- the pull-request should be named: `release: [version]`\n\n\n\n## Development Conventions\n\n-   **Branching:** The project follows a specific branching strategy.\n    -   `feature/*` and `bugfix/*` branches should be based on and merged into `develop`.\n    -   `hotfix/*` branches should be based on and merged into `main`.\n-   **Commits:** While not strictly enforced, it's good practice to follow conventional commit message formats.\n-   **Dependencies:** Manage dependencies using Go modules (`go.mod` and `go.sum`).\n-   **Contributing:** Refer to `CONTRIBUTING.md` for more detailed contribution guidelines.\n\n\n## Working on a new feature\n\n- Storyboarding and design discussions should be documented in the `scratchpad/` directory.\n- Implementation progress and summaries should also be documented in the `scratchpad/` directory.   \n- propose unit tests for testing tricky aspects of the feature\n- propose e2e tests:\n    - explain the case to be tested: \n    - propose a description of test data needed for the test. \n    - I'll provide the data and files for the test\n    - ensure that the entire upload process works as expected, including file discovery, processing, and uploading to the Immich server.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/simulot/immich-go/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}