{"owner":"gofiber","repo":"fiber","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":1562,"categories":["root-instruction","copilot-instructions","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".github/copilot-instructions.md",".cursorrules (htmx-go-fiber-cursorrules-prompt-file.mdc)"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Agent Instructions\n\n> **Note for the AI agent:** Before running the startup script, verify that all dependencies and CLI tools are already available. If a `vendor/` directory exists **or** `go list -m -mod=readonly all` succeeds (indicating modules are cached), you may skip the entire startup script—including all `go mod` commands and `go install` steps. Otherwise, run the script as listed below.\n\n### General coding practices\n\n- When adding Go tests, always invoke `t.Parallel()` at the start of each test and subtest to maximize concurrency. The one exception is a test that calls `testing.AllocsPerRun`, which panics with `AllocsPerRun called during parallel test`: leave those sequential and say why in a comment, as `Test_Chain_NoAllocations` and `Test_Combined_DoesNotAllocate` do.\n- Prefer `github.com/gofiber/utils/v2` helpers (for example, `utils.Trim`) when performing common operations such as string manipulation, whenever it is practical and appropriate for the surrounding code.\n- Keep all protocol behavior RFC-compliant (e.g., HTTP/1.1 requirements) and document any intentional deviations.\n- Protect hot paths from regressions: profile changes.\n- Apply secure-by-default choices (validation, timeouts, sanitization) and ensure new code hardens attack surfaces.\n\n### Linter pitfalls (run `make lint` before every push)\n\nThe linter is the most common reason CI fails for generated changes. Always run\n`make lint` locally and fix every finding *before* committing — do not rely on\nCI to surface them. The `golangci-lint` config (`.golangci.yml`) enables strict\n`errcheck` settings (`check-type-assertions: true` and `check-blank: true`),\nwhich trip up the patterns below:\n\n- **Never discard a type-assertion result with `_`.** `v, _ := x.(T)` fails\n  `errcheck`. Use the comma-ok form and act on it instead:\n\n  ```go\n  v, ok := x.(T)\n  if !ok {\n      v = T{} // explicit fallback; the zero value is fine when that's intended\n  }\n  ```\n\n- **Never discard a returned `error` with `_`** (`check-blank`). Handle it, or\n  if it is genuinely safe to ignore, call the function without assignment or add\n  a justified `//nolint:errcheck // reason` comment.\n\n- When in doubt, run `make lint` (or `golangci-lint run ./<pkg>/...`) and treat a\n  non-zero exit as a blocker.\n\n---\n\n## Startup script (reference only – do not run)\n\n- Fetch dependencies:\n\n  ```bash\n  go mod tidy && go mod download && go mod vendor\n  ```\n\n- Install CLI tools referenced in Makefile:\n\n  ```bash\n  go install gotest.tools/gotestsum@latest                 # test runner\n  go install golang.org/x/vuln/cmd/govulncheck@latest      # vulnerability scanner\n  go install mvdan.cc/gofumpt@latest                       # code formatter\n  go install github.com/tinylib/msgp@latest                # msgp codegen\n  go install github.com/vburenin/ifacemaker@f30b6f9bdbed4b5c4804ec9ba4a04a999525c202  # interface impls\n  go install github.com/dkorunic/betteralign/cmd/betteralign@latest  # struct alignment\n  go mod tidy                                              # clean up go.mod & go.sum\n  ```\n\n## Makefile commands\n\nUse `make help` to list all available commands. Common targets include:\n\n- **audit**: run `go mod verify`, `go vet`, and `govulncheck` for quality checks.\n- **benchmark**: run benchmarks with `go test`.\n- **coverage**: generate a coverage report.\n- **format**: apply formatting using `gofumpt`.\n- **lint**: execute `golangci-lint`.\n- **test**: run the test suite with `gotestsum`.\n- **longtest**: run the test suite 15 times with shuffling enabled.\n- **tidy**: clean and tidy dependencies.\n- **betteralign**: optimize struct field alignment.\n- **generate**: run `go generate` after installing msgp and ifacemaker. On a pull request a maintainer\n  can get the same result without a local toolchain by commenting `/generate`, which runs the target\n  and pushes the regenerated files onto the branch.\n\nThese targets can be invoked via `make <target>` as needed during development and testing.\n\n## Pull request guidelines\n\n- PR titles must start with a category prefix describing the change: `🐛 bug:`, `🔥 feat:`, `📒 docs:`, or `🧹 chore:`.\n- Generated PR titles and bodies must summarize the *entire* set of changes on the branch (for example, based on `git log --oneline <base>..HEAD` or the full diff), **not** just the latest commit. The Summary section should reflect all modifications that will be merged.\n\n## Programmatic checks\n\nBefore presenting final changes or submitting a pull request, run each of the\nfollowing commands and ensure they succeed. Include the command outputs in your\nfinal response to confirm they were executed:\n\n```bash\nmake audit\nmake generate\nmake betteralign\nmake format\nmake lint\nmake test\n```\n\nAll checks must pass before the generated code can be merged.\n\nAfter completing the programmatic checks above, confirm that any relevant\ndocumentation has been updated to reflect the changes made, including PR\ninstructions when applicable.\n",".github/copilot-instructions.md":"# Copilot Usage\n\nWhen modifying code, always perform these steps:\n\n1. **Ensure code quality**\n   - `make format` to format the project.\n   - `make lint` for static analysis.\n   - `make test` to run the test suite.\n\n2. **Maintain documentation**\n   Review and update the contents of the `docs` folder if necessary.\n\n3. **Check Markdown**\n   - Finish by running `make markdown` to lint all Markdown files.\n",".cursorrules (htmx-go-fiber-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Go development with Fiber integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// HTMX with Go and Fiber .cursorrules\n\n// HTMX, Go, and Fiber best practices\n\nconst htmxGoFiberBestPractices = [\n  \"Use Fiber's HTML rendering for server-side templates\",\n  \"Implement Fiber's routing system for HTMX requests\",\n  \"Utilize Fiber's middleware for request processing\",\n  \"Use Fiber's JSON methods for API responses\",\n  \"Implement proper error handling with Fiber's error handling\",\n  \"Utilize Fiber's static file serving for assets\",\n];\n\n// Folder structure\n\nconst folderStructure = `\ncmd/\n  main.go\ninternal/\n  handlers/\n  models/\n  templates/\nstatic/\n  css/\n  js/\ngo.mod\ngo.sum\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Fiber's App.Get/Post/etc for routing HTMX requests\n2. Implement CSRF protection with Fiber middleware\n3. Utilize Fiber's Context for handling HTMX-specific headers\n4. Use Fiber's template engine for server-side rendering\n5. Implement proper logging with Fiber's Logger middleware\n6. Follow Fiber's best practices for project structure\n7. Use environment variables for configuration\n`;\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## Agent Instructions\n\n> **Note for the AI agent:** Before running the startup script, verify that all dependencies and CLI tools are already available. If a `vendor/` directory exists **or** `go list -m -mod=readonly all` succeeds (indicating modules are cached), you may skip the entire startup script—including all `go mod` commands and `go install` steps. Otherwise, run the script as listed below.\n\n### General coding practices\n\n- When adding Go tests, always invoke `t.Parallel()` at the start of each test and subtest to maximize concurrency. The one exception is a test that calls `testing.AllocsPerRun`, which panics with `AllocsPerRun called during parallel test`: leave those sequential and say why in a comment, as `Test_Chain_NoAllocations` and `Test_Combined_DoesNotAllocate` do.\n- Prefer `github.com/gofiber/utils/v2` helpers (for example, `utils.Trim`) when performing common operations such as string manipulation, whenever it is practical and appropriate for the surrounding code.\n- Keep all protocol behavior RFC-compliant (e.g., HTTP/1.1 requirements) and document any intentional deviations.\n- Protect hot paths from regressions: profile changes.\n- Apply secure-by-default choices (validation, timeouts, sanitization) and ensure new code hardens attack surfaces.\n\n### Linter pitfalls (run `make lint` before every push)\n\nThe linter is the most common reason CI fails for generated changes. Always run\n`make lint` locally and fix every finding *before* committing — do not rely on\nCI to surface them. The `golangci-lint` config (`.golangci.yml`) enables strict\n`errcheck` settings (`check-type-assertions: true` and `check-blank: true`),\nwhich trip up the patterns below:\n\n- **Never discard a type-assertion result with `_`.** `v, _ := x.(T)` fails\n  `errcheck`. Use the comma-ok form and act on it instead:\n\n  ```go\n  v, ok := x.(T)\n  if !ok {\n      v = T{} // explicit fallback; the zero value is fine when that's intended\n  }\n  ```\n\n- **Never discard a returned `error` with `_`** (`check-blank`). Handle it, or\n  if it is genuinely safe to ignore, call the function without assignment or add\n  a justified `//nolint:errcheck // reason` comment.\n\n- When in doubt, run `make lint` (or `golangci-lint run ./<pkg>/...`) and treat a\n  non-zero exit as a blocker.\n\n---\n\n## Startup script (reference only – do not run)\n\n- Fetch dependencies:\n\n  ```bash\n  go mod tidy && go mod download && go mod vendor\n  ```\n\n- Install CLI tools referenced in Makefile:\n\n  ```bash\n  go install gotest.tools/gotestsum@latest                 # test runner\n  go install golang.org/x/vuln/cmd/govulncheck@latest      # vulnerability scanner\n  go install mvdan.cc/gofumpt@latest                       # code formatter\n  go install github.com/tinylib/msgp@latest                # msgp codegen\n  go install github.com/vburenin/ifacemaker@f30b6f9bdbed4b5c4804ec9ba4a04a999525c202  # interface impls\n  go install github.com/dkorunic/betteralign/cmd/betteralign@latest  # struct alignment\n  go mod tidy                                              # clean up go.mod & go.sum\n  ```\n\n## Makefile commands\n\nUse `make help` to list all available commands. Common targets include:\n\n- **audit**: run `go mod verify`, `go vet`, and `govulncheck` for quality checks.\n- **benchmark**: run benchmarks with `go test`.\n- **coverage**: generate a coverage report.\n- **format**: apply formatting using `gofumpt`.\n- **lint**: execute `golangci-lint`.\n- **test**: run the test suite with `gotestsum`.\n- **longtest**: run the test suite 15 times with shuffling enabled.\n- **tidy**: clean and tidy dependencies.\n- **betteralign**: optimize struct field alignment.\n- **generate**: run `go generate` after installing msgp and ifacemaker. On a pull request a maintainer\n  can get the same result without a local toolchain by commenting `/generate`, which runs the target\n  and pushes the regenerated files onto the branch.\n\nThese targets can be invoked via `make <target>` as needed during development and testing.\n\n## Pull request guidelines\n\n- PR titles must start with a category prefix describing the change: `🐛 bug:`, `🔥 feat:`, `📒 docs:`, or `🧹 chore:`.\n- Generated PR titles and bodies must summarize the *entire* set of changes on the branch (for example, based on `git log --oneline <base>..HEAD` or the full diff), **not** just the latest commit. The Summary section should reflect all modifications that will be merged.\n\n## Programmatic checks\n\nBefore presenting final changes or submitting a pull request, run each of the\nfollowing commands and ensure they succeed. Include the command outputs in your\nfinal response to confirm they were executed:\n\n```bash\nmake audit\nmake generate\nmake betteralign\nmake format\nmake lint\nmake test\n```\n\nAll checks must pass before the generated code can be merged.\n\nAfter completing the programmatic checks above, confirm that any relevant\ndocumentation has been updated to reflect the changes made, including PR\ninstructions when applicable.\n",".github/copilot-instructions.md":"# Copilot Usage\n\nWhen modifying code, always perform these steps:\n\n1. **Ensure code quality**\n   - `make format` to format the project.\n   - `make lint` for static analysis.\n   - `make test` to run the test suite.\n\n2. **Maintain documentation**\n   Review and update the contents of the `docs` folder if necessary.\n\n3. **Check Markdown**\n   - Finish by running `make markdown` to lint all Markdown files.\n",".cursorrules (htmx-go-fiber-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for Go development with Fiber integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// HTMX with Go and Fiber .cursorrules\n\n// HTMX, Go, and Fiber best practices\n\nconst htmxGoFiberBestPractices = [\n  \"Use Fiber's HTML rendering for server-side templates\",\n  \"Implement Fiber's routing system for HTMX requests\",\n  \"Utilize Fiber's middleware for request processing\",\n  \"Use Fiber's JSON methods for API responses\",\n  \"Implement proper error handling with Fiber's error handling\",\n  \"Utilize Fiber's static file serving for assets\",\n];\n\n// Folder structure\n\nconst folderStructure = `\ncmd/\n  main.go\ninternal/\n  handlers/\n  models/\n  templates/\nstatic/\n  css/\n  js/\ngo.mod\ngo.sum\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Fiber's App.Get/Post/etc for routing HTMX requests\n2. Implement CSRF protection with Fiber middleware\n3. Utilize Fiber's Context for handling HTMX-specific headers\n4. Use Fiber's template engine for server-side rendering\n5. Implement proper logging with Fiber's Logger middleware\n6. Follow Fiber's best practices for project structure\n7. Use environment variables for configuration\n`;\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/gofiber/fiber/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\n## Agent Instructions\n\n> **Note for the AI agent:** Before running the startup script, verify that all dependencies and CLI tools are already available. If a `vendor/` directory exists **or** `go list -m -mod=readonly all` succeeds (indicating modules are cached), you may skip the entire startup script—including all `go mod` commands and `go install` steps. Otherwise, run the script as listed below.\n\n### General coding practices\n\n- When adding Go tests, always invoke `t.Parallel()` at the start of each test and subtest to maximize concurrency. The one exception is a test that calls `testing.AllocsPerRun`, which panics with `AllocsPerRun called during parallel test`: leave those sequential and say why in a comment, as `Test_Chain_NoAllocations` and `Test_Combined_DoesNotAllocate` do.\n- Prefer `github.com/gofiber/utils/v2` helpers (for example, `utils.Trim`) when performing common operations such as string manipulation, whenever it is practical and appropriate for the surrounding code.\n- Keep all protocol behavior RFC-compliant (e.g., HTTP/1.1 requirements) and document any intentional deviations.\n- Protect hot paths from regressions: profile changes.\n- Apply secure-by-default choices (validation, timeouts, sanitization) and ensure new code hardens attack surfaces.\n\n### Linter pitfalls (run `make lint` before every push)\n\nThe linter is the most common reason CI fails for generated changes. Always run\n`make lint` locally and fix every finding *before* committing — do not rely on\nCI to surface them. The `golangci-lint` config (`.golangci.yml`) enables strict\n`errcheck` settings (`check-type-assertions: true` and `check-blank: true`),\nwhich trip up the patterns below:\n\n- **Never discard a type-assertion result with `_`.** `v, _ := x.(T)` fails\n  `errcheck`. Use the comma-ok form and act on it instead:\n\n  ```go\n  v, ok := x.(T)\n  if !ok {\n      v = T{} // explicit fallback; the zero value is fine when that's intended\n  }\n  ```\n\n- **Never discard a returned `error` with `_`** (`check-blank`). Handle it, or\n  if it is genuinely safe to ignore, call the function without assignment or add\n  a justified `//nolint:errcheck // reason` comment.\n\n- When in doubt, run `make lint` (or `golangci-lint run ./<pkg>/...`) and treat a\n  non-zero exit as a blocker.\n\n---\n\n## Startup script (reference only – do not run)\n\n- Fetch dependencies:\n\n  ```bash\n  go mod tidy && go mod download && go mod vendor\n  ```\n\n- Install CLI tools referenced in Makefile:\n\n  ```bash\n  go install gotest.tools/gotestsum@latest                 # test runner\n  go install golang.org/x/vuln/cmd/govulncheck@latest      # vulnerability scanner\n  go install mvdan.cc/gofumpt@latest                       # code formatter\n  go install github.com/tinylib/msgp@latest                # msgp codegen\n  go install github.com/vburenin/ifacemaker@f30b6f9bdbed4b5c4804ec9ba4a04a999525c202  # interface impls\n  go install github.com/dkorunic/betteralign/cmd/betteralign@latest  # struct alignment\n  go mod tidy                                              # clean up go.mod & go.sum\n  ```\n\n## Makefile commands\n\nUse `make help` to list all available commands. Common targets include:\n\n- **audit**: run `go mod verify`, `go vet`, and `govulncheck` for quality checks.\n- **benchmark**: run benchmarks with `go test`.\n- **coverage**: generate a coverage report.\n- **format**: apply formatting using `gofumpt`.\n- **lint**: execute `golangci-lint`.\n- **test**: run the test suite with `gotestsum`.\n- **longtest**: run the test suite 15 times with shuffling enabled.\n- **tidy**: clean and tidy dependencies.\n- **betteralign**: optimize struct field alignment.\n- **generate**: run `go generate` after installing msgp and ifacemaker. On a pull request a maintainer\n  can get the same result without a local toolchain by commenting `/generate`, which runs the target\n  and pushes the regenerated files onto the branch.\n\nThese targets can be invoked via `make <target>` as needed during development and testing.\n\n## Pull request guidelines\n\n- PR titles must start with a category prefix describing the change: `🐛 bug:`, `🔥 feat:`, `📒 docs:`, or `🧹 chore:`.\n- Generated PR titles and bodies must summarize the *entire* set of changes on the branch (for example, based on `git log --oneline <base>..HEAD` or the full diff), **not** just the latest commit. The Summary section should reflect all modifications that will be merged.\n\n## Programmatic checks\n\nBefore presenting final changes or submitting a pull request, run each of the\nfollowing commands and ensure they succeed. Include the command outputs in your\nfinal response to confirm they were executed:\n\n```bash\nmake audit\nmake generate\nmake betteralign\nmake format\nmake lint\nmake test\n```\n\nAll checks must pass before the generated code can be merged.\n\nAfter completing the programmatic checks above, confirm that any relevant\ndocumentation has been updated to reflect the changes made, including PR\ninstructions when applicable.\n","isInternal":false,"tokens":1204,"sizeBytes":4989},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/gofiber/fiber/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot Usage\n\nWhen modifying code, always perform these steps:\n\n1. **Ensure code quality**\n   - `make format` to format the project.\n   - `make lint` for static analysis.\n   - `make test` to run the test suite.\n\n2. **Maintain documentation**\n   Review and update the contents of the `docs` folder if necessary.\n\n3. **Check Markdown**\n   - Finish by running `make markdown` to lint all Markdown files.\n","isInternal":false,"tokens":97,"sizeBytes":404},{"name":".cursorrules","path":".cursorrules (htmx-go-fiber-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/htmx-go-fiber-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: htmx go fiber","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Go development with Fiber integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// HTMX with Go and Fiber .cursorrules\n\n// HTMX, Go, and Fiber best practices\n\nconst htmxGoFiberBestPractices = [\n  \"Use Fiber's HTML rendering for server-side templates\",\n  \"Implement Fiber's routing system for HTMX requests\",\n  \"Utilize Fiber's middleware for request processing\",\n  \"Use Fiber's JSON methods for API responses\",\n  \"Implement proper error handling with Fiber's error handling\",\n  \"Utilize Fiber's static file serving for assets\",\n];\n\n// Folder structure\n\nconst folderStructure = `\ncmd/\n  main.go\ninternal/\n  handlers/\n  models/\n  templates/\nstatic/\n  css/\n  js/\ngo.mod\ngo.sum\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Fiber's App.Get/Post/etc for routing HTMX requests\n2. Implement CSRF protection with Fiber middleware\n3. Utilize Fiber's Context for handling HTMX-specific headers\n4. Use Fiber's template engine for server-side rendering\n5. Implement proper logging with Fiber's Logger middleware\n6. Follow Fiber's best practices for project structure\n7. Use environment variables for configuration\n`;\n","tokens":261,"sizeBytes":1161}],"systemPromptSnippet":"<yakaai_skills repo=\"gofiber/fiber\">\n<!-- File: AGENTS.md (Tokens: ~1204 | Category: root-instruction) -->\n# AGENTS.md\n\n## Agent Instructions\n\n> **Note for the AI agent:** Before running the startup script, verify that all dependencies and CLI tools are already available. If a `vendor/` directory exists **or** `go list -m -mod=readonly all` succeeds (indicating modules are cached), you may skip the entire startup script—including all `go mod` commands and `go install` steps. Otherwise, run the script as listed below.\n\n### General coding practices\n\n- When adding Go tests, always invoke `t.Parallel()` at the start of each test and subtest to maximize concurrency. The one exception is a test that calls `testing.AllocsPerRun`, which panics with `AllocsPerRun called during parallel test`: leave those sequential and say why in a comment, as `Test_Chain_NoAllocations` and `Test_Combined_DoesNotAllocate` do.\n- Prefer `github.com/gofiber/utils/v2` helpers (for example, `utils.Trim`) when performing common operations such as string manipulation, whenever it is practical and appropriate for the surrounding code.\n- Keep all protocol behavior RFC-compliant (e.g., HTTP/1.1 requirements) and document any intentional deviations.\n- Protect hot paths from regressions: profile changes.\n- Apply secure-by-default choices (validation, timeouts, sanitization) and ensure new code hardens attack surfaces.\n\n### Linter pitfalls (run `make lint` before every push)\n\nThe linter is the most common reason CI fails for generated changes. Always run\n`make lint` locally and fix every finding *before* committing — do not rely on\nCI to surface them. The `golangci-lint` config (`.golangci.yml`) enables strict\n`errcheck` settings (`check-type-assertions: true` and `check-blank: true`),\nwhich trip up the patterns below:\n\n- **Never discard a type-assertion result with `_`.** `v, _ := x.(T)` fails\n  `errcheck`. Use the comma-ok form and act on it instead:\n\n  ```go\n  v, ok := x.(T)\n  if !ok {\n      v = T{} // explicit fallback; the zero value is fine when that's intended\n  }\n  ```\n\n- **Never discard a returned `error` with `_`** (`check-blank`). Handle it, or\n  if it is genuinely safe to ignore, call the function without assignment or add\n  a justified `//nolint:errcheck // reason` comment.\n\n- When in doubt, run `make lint` (or `golangci-lint run ./<pkg>/...`) and treat a\n  non-zero exit as a blocker.\n\n---\n\n## Startup script (reference only – do not run)\n\n- Fetch dependencies:\n\n  ```bash\n  go mod tidy && go mod download && go mod vendor\n  ```\n\n- Install CLI tools referenced in Makefile:\n\n  ```bash\n  go install gotest.tools/gotestsum@latest                 # test runner\n  go install golang.org/x/vuln/cmd/govulncheck@latest      # vulnerability scanner\n  go install mvdan.cc/gofumpt@latest                       # code formatter\n  go install github.com/tinylib/msgp@latest                # msgp codegen\n  go install github.com/vburenin/ifacemaker@f30b6f9bdbed4b5c4804ec9ba4a04a999525c202  # interface impls\n  go install github.com/dkorunic/betteralign/cmd/betteralign@latest  # struct alignment\n  go mod tidy                                              # clean up go.mod & go.sum\n  ```\n\n## Makefile commands\n\nUse `make help` to list all available commands. Common targets include:\n\n- **audit**: run `go mod verify`, `go vet`, and `govulncheck` for quality checks.\n- **benchmark**: run benchmarks with `go test`.\n- **coverage**: generate a coverage report.\n- **format**: apply formatting using `gofumpt`.\n- **lint**: execute `golangci-lint`.\n- **test**: run the test suite with `gotestsum`.\n- **longtest**: run the test suite 15 times with shuffling enabled.\n- **tidy**: clean and tidy dependencies.\n- **betteralign**: optimize struct field alignment.\n- **generate**: run `go generate` after installing msgp and ifacemaker. On a pull request a maintainer\n  can get the same result without a local toolchain by commenting `/generate`, which runs the target\n  and pushes the regenerated files onto the branch.\n\nThese targets can be invoked via `make <target>` as needed during development and testing.\n\n## Pull request guidelines\n\n- PR titles must start with a category prefix describing the change: `🐛 bug:`, `🔥 feat:`, `📒 docs:`, or `🧹 chore:`.\n- Generated PR titles and bodies must summarize the *entire* set of changes on the branch (for example, based on `git log --oneline <base>..HEAD` or the full diff), **not** just the latest commit. The Summary section should reflect all modifications that will be merged.\n\n## Programmatic checks\n\nBefore presenting final changes or submitting a pull request, run each of the\nfollowing commands and ensure they succeed. Include the command outputs in your\nfinal response to confirm they were executed:\n\n```bash\nmake audit\nmake generate\nmake betteralign\nmake format\nmake lint\nmake test\n```\n\nAll checks must pass before the generated code can be merged.\n\nAfter completing the programmatic checks above, confirm that any relevant\ndocumentation has been updated to reflect the changes made, including PR\ninstructions when applicable.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~97 | Category: copilot-instructions) -->\n# Copilot Usage\n\nWhen modifying code, always perform these steps:\n\n1. **Ensure code quality**\n   - `make format` to format the project.\n   - `make lint` for static analysis.\n   - `make test` to run the test suite.\n\n2. **Maintain documentation**\n   Review and update the contents of the `docs` folder if necessary.\n\n3. **Check Markdown**\n   - Finish by running `make markdown` to lint all Markdown files.\n\n<!-- File: .cursorrules (htmx-go-fiber-cursorrules-prompt-file.mdc) (Tokens: ~261 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for Go development with Fiber integration.\"\nglobs: **/*\nalwaysApply: false\n---\n// HTMX with Go and Fiber .cursorrules\n\n// HTMX, Go, and Fiber best practices\n\nconst htmxGoFiberBestPractices = [\n  \"Use Fiber's HTML rendering for server-side templates\",\n  \"Implement Fiber's routing system for HTMX requests\",\n  \"Utilize Fiber's middleware for request processing\",\n  \"Use Fiber's JSON methods for API responses\",\n  \"Implement proper error handling with Fiber's error handling\",\n  \"Utilize Fiber's static file serving for assets\",\n];\n\n// Folder structure\n\nconst folderStructure = `\ncmd/\n  main.go\ninternal/\n  handlers/\n  models/\n  templates/\nstatic/\n  css/\n  js/\ngo.mod\ngo.sum\n`;\n\n// Additional instructions\n\nconst additionalInstructions = `\n1. Use Fiber's App.Get/Post/etc for routing HTMX requests\n2. Implement CSRF protection with Fiber middleware\n3. Utilize Fiber's Context for handling HTMX-specific headers\n4. Use Fiber's template engine for server-side rendering\n5. Implement proper logging with Fiber's Logger middleware\n6. Follow Fiber's best practices for project structure\n7. Use environment variables for configuration\n`;\n</yakaai_skills>"}