# Prompt, disclosure, and views
Use Mintlify-style prompt blocks, accordions, expandables, views, and visibility controls for progressive docs and agent-aware content.
Source: /docs/components/disclosure-views
Last modified: 2026-06-20
Use this family when the docs should teach progressively. Prompt blocks give agents and developers a copyable instruction. Disclosure components hide optional detail until needed. View and visibility controls let the same page support human readers and agent contexts.


> **Progressive docs**
>

  Start with the shortest successful path, then reveal caveats, alternatives, and agent context as the reader needs them.


## Prompt

Use `Prompt` for copyable agent instructions. Keep prompts concrete: name the product primitive, expected files, constraints, and verification step.


> **Generate an offer checkout button**
>

Create a Plandalf checkout button for an existing sales page.

- Use the browser SDK.
- Open offer `offer_123` in a modal.
- Listen for checkout completion.
- Do not expose private API keys in browser code.
- Link the docs page that explains Offers.


```mdx prompt.mdx

> **Generate an offer checkout button**
>

Create a Plandalf checkout button for an existing sales page.

- Use the browser SDK.
- Open offer `offer_123` in a modal.
- Do not expose private API keys in browser code.


```

## Accordions and expandables

Use accordions for grouped optional questions. Use `Expandable` for one local detail, especially nested API fields or implementation caveats.


> **When should this be an accordion?**
>

    Use an accordion when the reader may need the answer but should not be forced through it on the first pass.


> **When should this stay in the article?**
>

    If the detail changes the required path, keep it visible in the main flow.


> **Nested object example**
>

  `purchase.customer.email` is useful for fulfilment and CRM syncs, but it should stay inside a detailed field block until the page introduces purchase events.


```mdx disclosure.mdx


> **When should this be an accordion?**
>

    Use an accordion when the reader may need the answer but should not be forced through it.


> **Nested object example**
>

  `purchase.customer.email` is useful for fulfilment and CRM syncs.


```

## Views

Use adjacent `View` blocks when the same concept has different human, JavaScript, React, or agent presentations. The renderer turns adjacent views into a switcher.


### Human

Start by creating one test offer and connecting one visible checkout button. Keep the page focused on the sale the buyer is trying to complete.


### JavaScript

Load the browser SDK, call `openOffer`, and handle completion from the returned flow handle.


### Agent

Prefer the simplest working implementation first. Link to `/docs/offers/overview` when explaining what an offer contains.


```mdx views.mdx

### Human

Start by creating one test offer and connecting one visible checkout button.


### JavaScript

Load the browser SDK and call `openOffer`.


### Agent

Prefer the simplest working implementation first.

```

## Visibility

Use `Visibility` when content should exist in source for a specific audience. Human-visible content renders on the public docs page. Agent-only content stays out of the human page.


Agent note: keep implementation claims grounded in `/Users/wavy/plandalf/api` and the SDK repos before publishing.

```mdx visibility.mdx


Agent note: verify implementation claims before publishing.
```

## Prompt properties


- `title` (string):
  Optional heading above the prompt body.


- `description` (string):
  Short context line shown before the prompt text.


- `actions` (array; default: ["copy"]):
  Supported prompt actions. Use `["copy", "cursor"]` when the prompt should support both clipboard and Cursor handoff.


- `icon` (string):
  Icon shown beside the prompt title.


- `copyLabel` (string; default: Copy prompt):
  Accessible label for the copy action.


- `cursorLabel` (string; default: Open in Cursor):
  Accessible label for the Cursor handoff action.


## Disclosure properties


- `AccordionGroup.children` (Accordion[]; required):
  Group related accordions so optional detail reads as one section, not scattered toggles.


- `Accordion.title` (string; required):
  Visible accordion heading.


- `Accordion.icon` (string):
  Icon shown beside the accordion title.


- `Accordion.defaultOpen` (boolean; default: false):
  Opens the accordion on first load. Use sparingly for a detail that should be visible immediately.


- `Expandable.title` (string):
  Label for one inline reveal.


- `Expandable.defaultOpen` (boolean; default: false):
  Opens the inline detail by default.


## View and visibility properties


- `View.title` (string; required):
  Label shown in the generated view switcher.


- `View.icon` (string):
  Icon shown beside the view title.


- `View.when` (always | human | agent; default: always):
  Controls whether the view is available in human or agent contexts.


- `View.for` (humans | agents | human | agent):
  Compatibility alias for targeted views.


- `Visibility.for` (humans | agents; required):
  Use `humans` for visible reader text and `agents` for source-only agent context.


- `Visibility.mode` (visible | hidden | human | agent; default: visible):
  Compatibility mode for imported MDX that uses visibility labels instead of `for`.


## Related components


  - [Steps](/docs/components/steps): Put the progressive path into a numbered sequence.
  - [Attention components](/docs/components/attention): Call out constraints without hiding them.
  - [API fields and examples](/docs/components/api-fields-examples): Document request and response shape after the concept is clear.