The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

docs/guide/templates.md (1)

55-57: Terminology consistency: “bound data” vs. “data to bind.”

Line 55 uses “bound data” while Line 61 says “data to bind.” Prefer one term across the page (I’d keep “bound data”).

Apply this diff to Line 61:

-The `Render` method powers the [**ctx.Render()**](../api/ctx.md#render) function, which accepts a template name and data to bind.
+The `Render` method powers the [**ctx.Render()**](../api/ctx.md#render) function, which accepts a template name and bound data.

docs/guide/faster-fiber.md (1)

11-15: Clarify drop-in vs. non drop-in libraries.

• segmentio/encoding/json can act as a drop-in (same Marshal/Unmarshal signatures under a json import alias).
• minio/simdjson-go is primarily a high-performance parser and not a drop-in replacement for encoding/json encoders/decoders; it won’t plug into JSONEncoder/JSONDecoder without adapters.

A short note next to each bullet would prevent confusion.

Apply this diff:

-- [segmentio/encoding](https://github.com/segmentio/encoding)
-- [minio/simdjson-go](https://github.com/minio/simdjson-go)
+- [segmentio/encoding](https://github.com/segmentio/encoding) — Drop-in `json.Marshal`/`json.Unmarshal` under `github.com/segmentio/encoding/json`.
+- [minio/simdjson-go](https://github.com/minio/simdjson-go) — SIMD-accelerated JSON parser (not a drop-in encoder/decoder).

docs/intro.md (1)

132-166: Ports vary across examples (3000 vs. 8080).

Consider standardizing on one port across examples for consistency (e.g., 3000).

docs/guide/grouping.md (1)

8-9: Tone: “identical to Express.js” is stronger than necessary.

Suggest softening to “similar to Express.js” to avoid implying perfect parity in edge cases.

Apply this diff:

-In general, group functionality in Fiber behaves like Express.js. Groups are declared virtually, and all routes defined within a group are flattened into a single list with a prefix and processed in the order declared. This makes group behavior in Fiber identical to Express.js.
+In general, group functionality in Fiber is similar to Express.js. Groups are declared virtually, and all routes defined within a group are flattened into a single list with a prefix and processed in the order declared.

docs/guide/error-handling.md (2)

16-16: Tighten wording: errors are returned from handlers to Fiber’s error handler, not “to the handler function”.

The current phrasing can be misread. This edit is clearer and accurate.

-Ensure that Fiber catches all errors from route handlers and middleware by returning them to the handler function for processing.
+Return errors from your handlers and middleware so Fiber’s error handler can process them.

---

96-96: Add a short note on avoiding sensitive error leakage; optionally include a JSON error example.

Since many users copy docs verbatim, a one-liner reminding to avoid returning internal error strings directly (and to prefer structured JSON for APIs) is valuable.

-In most cases, the default error handler is sufficient. However, a custom handler is useful when you need to capture different error types and respond accordingly—for example, sending notification emails or logging to a centralized system. You can also send custom responses to the client, such as an error page or a JSON message.
+In most cases, the default error handler is sufficient. However, a custom handler is useful when you need to capture different error types and respond accordingly—for example, sending notification emails or logging to a centralized system. You can also send custom responses to the client (HTML pages or structured JSON). For production APIs, avoid leaking internal error details in responses; log them server‑side and return sanitized messages to clients.

Optional example (no change required in this PR):

// JSON-oriented error handler (sanitizes messages)
app := fiber.New(fiber.Config{
    ErrorHandler: func(c fiber.Ctx, err error) error {
        code := fiber.StatusInternalServerError
        var fe *fiber.Error
        if errors.As(err, &fe) {
            code = fe.Code
        }

        // Log full error internally
        // log.Printf("request_id=%s err=%v", c.GetRespHeader("X-Request-ID"), err)

        // Return a minimal, structured response
        type apiError struct {
            Error   string `json:"error"`
            Code    int    `json:"code"`
            TraceID string `json:"trace_id,omitempty"`
        }
        payload := apiError{
            Error: http.StatusText(code),
            Code:  code,
            // TraceID: c.GetRespHeader("X-Request-ID"), // if you set one
        }
        c.Set(fiber.HeaderContentType, fiber.MIMEApplicationJSONCharsetUTF8)
        return c.Status(code).JSON(payload)
    },
})

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: ReneWerner87
PR: gofiber/fiber#3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the `Test` method in `app.go`.

Learnt from: sixcolors
PR: gofiber/fiber#3016
File: middleware/session/config.go:122-122
Timestamp: 2024-09-25T16:18:34.719Z
Learning: In `DefaultErrorHandler(c *fiber.Ctx, err error)`, since `c` is a pointer to an interface, we need to dereference `*c` when calling interface methods like `SendStatus`.

Learnt from: ksw2000
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2025-07-08T13:41:20.627Z
Learning: ksw2000 suggests implementing a pluggable encoder/decoder registry system in Fiber instead of hardcoding all encoders in app.config. This would solve dependency management issues by allowing users to opt-in only to the formats they need, keeping JSON and XML as defaults while making CBOR and MsgPack explicit registrations.

Learnt from: ReneWerner87
PR: gofiber/fiber#0
File: :0-0
Timestamp: 2024-12-01T10:28:36.011Z
Learning: Fiber currently supports square bracket notation in form data with 'application/x-www-form-urlencoded' content type, but this feature is not available for multipart form data. The implementation for form-urlencoded is in ctx.go (BodyParser method), while multipart form data handling needs enhancement to support this feature.

Learnt from: sixcolors
PR: gofiber/fiber#3446
File: docs/middleware/logger.md:44-44
Timestamp: 2025-05-13T00:19:16.407Z
Learning: In documentation files for the Fiber framework, code examples are often partial and don't repeat import statements that were shown in earlier examples, focusing instead on demonstrating specific usage patterns.

Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.

Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/cache/cache_test.go:897-897
Timestamp: 2024-11-08T04:10:42.990Z
Learning: In the Fiber framework, `Context()` is being renamed to `RequestCtx()`, and `UserContext()` to `Context()` to improve clarity and align with Go's context conventions.