# Direct Edit — instructions for AI

Save this file in your website project and ask your AI to read it before making changes. Not every AI tool loads this file automatically; reference it in the tool’s project instructions if needed. Preserve existing project instructions.

For AI: The basic rules always apply. Use other prompts only for the current task and elements that exist on the website or have been requested by the user. Replace bracketed placeholders with actual values first; find missing information in the project or ask the user. The presence of this file is not a request to perform every change described here.

Source: https://directedit.dev/en/ai-support

## Must-have: Send this to AI first

```text
I will use the Direct Edit editor (directedit.dev) on my static HTML website. Before I give you a concrete task, follow these rules:

What Direct Edit can do:
- Works on a static website made of HTML, CSS and JS – not on a CMS or server-side framework (e.g. WordPress, Shopify).
- Editing happens directly on the page by clicking. The editor reads and saves straight into the HTML files; it uses no database.
- Editable automatically, without any special attributes: text, links, images, icons (Font Awesome / Bootstrap) and background images.
- Only two things need special HTML: duplicable blocks and videos (I will describe them below when I need them).

What NOT to do:
- Do not add any data-* attributes to elements for the editor; it is not necessary. They work on their own and unnecessary attributes only clutter the site.
- Do not touch the folder where the editor itself runs.
```

## Must-have: Website rules do not break the editor

```text
I use Direct Edit on a static HTML website. Prepare .htaccess like this:

- rules must not block or rewrite editor URLs,
- clean URL rules or .html removal rules must not affect URLs such as proxy.php?file=pricing.html,
- if the editor is in the [FILL-IN-HERE] folder, add this exception directly below RewriteEngine On / RewriteBase /:

  RewriteRule ^[FILL-IN-HERE]/ - [L]

Keep all other working website redirects as they are.
```

## Elements can be duplicated by the editor

```text
I want to enable copying and deleting of repeated blocks in Direct Edit on a static HTML website.

Update the HTML below so [FILL-IN-HERE] can be duplicated and deleted in the editor. Do not change the design, CSS classes, structure or the content of the individual cards – only add the attributes described below. Keep responsiveness in mind, since cards will be added and removed.

How it works:
- The attribute goes on the SHARED PARENT element (the container). Its DIRECT CHILDREN are what gets copied and deleted.
- data-direct-edit-duplicable-selector=""  → all direct children of the container are duplicable.
- data-direct-edit-duplicable-selector=".card"  → only the direct children matching the CSS selector are duplicable (multiple selectors separated by commas).
- data-direct-edit-duplicable-min="N"  → optional; the editor will not delete below N items.
- data-direct-edit-duplicable-max="M"  → optional; the editor will not add above M items.

Put the attribute on the EXISTING container; do not create a new wrapper for it.

Example – a card container, copying and deleting without limits:

<div class="cards" data-direct-edit-duplicable-selector="">
  <div class="card">...</div>
  <div class="card">...</div>
  <div class="card">...</div>
</div>

Example – only .card items are duplicable, always at least 1 and at most 6:

<div class="cards" data-direct-edit-duplicable-selector=".card" data-direct-edit-duplicable-min="1" data-direct-edit-duplicable-max="6">
  <div class="card">...</div>
</div>
```

## So videos can be edited in the editor

```text
I use Direct Edit and I want the videos on my website to be editable.

Please update the HTML below so videos are written in a standard way, because only then can Direct Edit edit them:

- embed YouTube or Vimeo as a standard <iframe> pointing to the embed URL (e.g. https://www.youtube.com/embed/... or https://player.vimeo.com/video/...),
- add a local video file (MP4, WebM or OGG) as a standard <video> with a nested <source src="...">,
- do not use custom JS players or <div> elements that load the video via script - those cannot be edited.

Keep the existing design, CSS classes and video dimensions.

Embedded player example:

<iframe src="https://www.youtube.com/embed/[FILL-IN-HERE]" title="Video" allowfullscreen></iframe>

Local file example:

<video controls>
  <source src="videos/[FILL-IN-HERE].mp4" type="video/mp4">
</video>
```

## Dismiss the banner and continue editing

```text
I use Direct Edit on a static HTML website. Create or adapt the cookie banner so the editor recognizes it and leaves its controls to the website's JavaScript.

- For a custom banner, add the cookie-banner CSS class to its existing container. If it has a separate backdrop, add cookie-overlay to that element. A separate cookie preferences panel can also use the cookie-banner class.
- Preserve existing IDs, classes, content and JavaScript bindings. Add the classes without renaming existing elements. Check that the added classes do not conflict with existing CSS.
- Apply these names only to cookie UI. Do not put them on body, a wrapper around the whole page, ordinary navigation, an accordion or another modal. The exclusion also applies to every descendant of the marked element.
- The editor recognizes cookie-banner and cookie-overlay as IDs too. One form is enough; if a matching ID or class already exists, do not add another marker.

Example of adding classes to existing HTML:

<div id="my-backdrop" class="backdrop cookie-overlay"></div>
<div id="my-banner" class="banner cookie-banner">
    ...existing content and buttons...
</div>

Direct Edit also recognizes the following names, each as either an ID or a complete CSS class:
- CookieYes: cky-consent-container, cky-modal, cky-overlay, cky-btn-revisit-wrapper
- Cookiebot: CybotCookiebotDialog, CybotCookiebotDialogBodyUnderlay
- OneTrust / CookiePro: onetrust-consent-sdk, onetrust-banner-sdk, onetrust-pc-sdk, onetrust-pc-dark-filter
- Complianz: cmplz-cookiebanner-container, cmplz-cookiebanner, cmplz-soft-cookiewall, cmplz-manage-consent
- Custom banners: cookie-banner, cookie-overlay

For a recognized service, preserve its own structure and names. Matching is exact: cookie-policy-text, for example, is not automatically excluded.

Expected behavior:
- The editor does not hide or open the banner itself, or grant consent on the user's behalf. Visibility still depends on the website code and the visitor's stored choice.
- The editor does not force the recognized banner, backdrop or descendants to appear and adds no editing or duplication controls. Animations can remain. This also applies to elements inserted later by JavaScript.
- Preserve acceptance, rejection and a link to reopen settings. Closing must also hide the backdrop and release any scroll or focus lock owned by the banner.
- Attach button handlers through addEventListener; the editor removes inline handlers such as onclick from the preview. Closing the interface must not depend on external tracking being available.
- Do not change editor files or invent new data-* attributes. A matching name alone cannot fix a broken banner script or make the preview load an external service it filters out.

Verify on both the public page and in the editor: first visit, acceptance, rejection, reload and reopening settings. After closing, the page must respond and scroll. In the editor, then open and save an ordinary text edit. Check desktop and mobile. Test actual tracking and consent changes on the public website.
```