Add FeedLog to your product with a coding agent

Open your project in a coding agent, then copy and send the prompt below. The agent will find the appropriate navigation location, add a link to your FeedLog portal and verify the change.

This is the simplest integration. It adds a direct link without Widget, SSO or server-side changes. You only need your FeedLog portal URL.

Copy prompt

Add a link to this product's FeedLog feedback portal. Work directly in the current repository: inspect the codebase, make the required changes, run the relevant checks, and verify the result. Do not stop at providing instructions or example code.

Communicate with me in the language I use. Follow all repository-level instructions, including AGENTS.md, CLAUDE.md, contribution guides, and existing coding conventions.

## Goal

Add one clear, user-facing way to open the product's FeedLog portal. This is a basic link integration:

- link directly to the FeedLog portal;
- do not install `@feedlog/widget`;
- do not add JWT signing or SSO;
- do not add a server-side redirect or proxy;
- do not change the application's authentication system.

The same direct link should work for signed-in and signed-out users.

## Inspect the project first

Before asking me where to edit, inspect the repository and determine:

- the frontend framework, version, package manager, and application entry points;
- how primary navigation, help menus, account menus, settings, and mobile navigation are organized;
- whether the product already has a Feedback, Feature requests, Support, Help, Roadmap, or Changelog link;
- how external URLs and public runtime configuration are managed;
- how navigation labels are translated;
- which reusable link, menu-item, button, and external-link components the project uses;
- the existing lint, typecheck, test, build, and browser-test commands.

Reuse the project's existing components, styles, configuration, localization, and external-link behavior. Do not redesign the navigation or refactor unrelated code.

Ask a focused question only when required information cannot be discovered from the repository.

## Determine the FeedLog URL

Search the repository and deployment configuration for an existing FeedLog portal URL. It should be an absolute `https://` URL in production and may use a FeedLog subdomain or the product's custom feedback domain.

If no reliable URL exists, ask me for the FeedLog portal URL. Do not guess it from the product name, repository name, email domain, or marketing-site URL.

The FeedLog URL is public and does not require a secret. Follow the project's existing public-configuration convention. If the project centralizes external URLs, add it there. If an environment variable is appropriate and no naming convention exists, use:

```env
FEEDLOG_URL=
```

Use any client-public prefix required by the framework. Do not add a server secret for this integration.

Avoid copying the literal URL into several components. Prefer the project's existing centralized configuration when the link appears in more than one responsive or localized navigation component.

## Choose the link location

Prefer an existing location where users already look for feedback or help, in this order when applicable:

1. an existing Feedback or Feature requests item;
2. an existing Help, Support, or resources menu;
3. the user or account menu;
4. the product's primary navigation or settings navigation.

Use the repository's information architecture rather than adding the link to every possible location. When desktop and mobile navigation are separate implementations of the same menu, keep both versions consistent.

If there are multiple equally plausible product areas and the correct placement is a product decision that cannot be inferred, ask me one focused placement question before changing navigation.

Do not replace an existing support channel, documentation link, roadmap, or changelog unless it is clearly intended to point to FeedLog. Preserve unrelated destinations.

## Label and behavior

Use the product's established terminology. Prefer an existing localized label. If no suitable term exists, use a concise label such as `Feedback` in English and add equivalent translations through the project's normal localization system.

Follow the application's established behavior for external links. If there is no convention, open FeedLog in a new tab so users do not lose in-progress work, and add the appropriate `rel="noopener noreferrer"` protection.

Use the project's external-link icon and accessible-name conventions when they exist. The link must remain keyboard accessible and understandable without relying only on an icon.

Do not add tracking parameters unless the project already has an approved analytics convention for external navigation.

## Handle incomplete repositories

This integration normally requires only the frontend application.

If the current repository does not contain the user-facing navigation, ask where the frontend application is located. Do not add the link to an unrelated backend, infrastructure, or documentation repository merely to make a change.

If the repository contains several applications, identify the customer-facing product before editing. Do not add the link to admin tools, internal dashboards, demo applications, or marketing sites unless the repository clearly indicates that one of those is the requested product.

## Verify the integration

Run the applicable repository checks, including lint, typecheck, tests, and production build. Do not fix unrelated pre-existing failures unless they block this integration; identify them separately.

Verify as many of these behaviors as the environment allows:

1. The link appears in the intended desktop and mobile location.
2. The label uses the project's localization system where applicable.
3. The destination is the configured FeedLog portal URL.
4. The link follows the project's external-navigation convention.
5. Keyboard navigation and the accessible name work correctly.
6. Existing navigation items still work.
7. The application builds and loads successfully.

Use the repository's approved browser-testing workflow when one exists. If browser verification is not possible, provide exact manual verification steps.

## Definition of done

Report the integration as complete only when:

- a user-facing FeedLog link has been added in the appropriate product location;
- the URL is configured according to project conventions;
- responsive and localized variants are consistent where applicable;
- the relevant automated checks pass;
- the destination and interaction have been verified, or any external limitation is clearly identified.

## Final report

At the end, report concisely:

1. the files changed;
2. where the FeedLog link appears;
3. how the FeedLog URL is configured;
4. whether the link opens in the current tab or a new tab;
5. the checks and tests run and their results;
6. anything incomplete or not verified.

Do not add Widget or SSO functionality unless I ask for it separately. Do not finish with only sample code or recommendations. Make the changes in the repository.

The agent may ask for your FeedLog URL or where the customer-facing frontend is located if it cannot find either one in the repository.