Making UIs like text adventure games

At my company, we're shifting our interaction paradigm. Even though the business logic of our internal tools remains the same, the way we interact with them keeps evolving. We've gone from terminal clients, to web interfaces using tools like Streamlit or any simple frontend, and now we're diving into interacting with users as if it were a text adventure game.

For example:

========================================
   UTILITIES SYSTEM
========================================

What would you like to do today?

[1] Transform documents
    - PDF → Word
    - Optimize PDF to reduce file size
    - Sign documents
    - Summarize documents or texts
    - Apply company branding

[2] Backups and security
    - Download node backup
    - Receive node backup by email
    - Check node or server status

[3] System
    - Deploy new version
    - Analyze performance
    - View system logs

========================================
Enter the option number or type your request in natural language:
> _

Behind this interface there's an agent, no doubt, but there's more architecture than meets the eye.

The most common approach is a classic, predictable, boring, but solid pattern:

graph TD
    A["🧠 Business logic"] --> B["⚡ API"] --> C["🖥️ Console/Web/UI Interface"]

But now, with this new way of interacting, the pattern is somewhat different:

graph TD
    A["🧠 Business logic"] --> B["⚡ API"] --> C["🤖 Agent"] --> D["📋 Skills"] --> E["🖥️ Text Interface"]

A Skill is a markdown file that describes to the agent how to execute a specific task, with its parameters, options, etc.

For example, if someone wants to convert markdown to HTML, the Skill might look like this:

---
name: markdown-to-html-pandoc
description: Converts Markdown to HTML using pandoc. Use it when the user wants to transform Markdown documents into faithful and structured HTML.
---

# Markdown to HTML (Pandoc Skill)

## Objective

This skill converts Markdown content to HTML using pandoc as the transformation engine.

## Instructions

1. Save the Markdown to a file called `input.md`.
2. Run:

```bash
pandoc input.md -f markdown -t html -o output.html
```

3. Read `output.html`.
4. Return only the generated HTML.

## Example

### Input

```markdown
# Hello world

This is an **example**.
```

### Command

```shell
pandoc input.md -f markdown -t html -o output.html
```

### Expected output

```html
<h1>Hello world</h1>
<p>This is an <strong>example</strong>.</p>
```

Each agent has its own path. If you use Claude, this file should be placed in `$HOME/.claude/skills/`, with a folder name that identifies the skill, for example `markdown-to-html-pandoc/skill.md`. If you use a more general-purpose agent like Goose, it would be `~/.agents/skills/`.

## Rules

- Always use pandoc
- Do not modify the generated HTML
- Do not add explanations

You can even add a section on how to install the required tools depending on the operating system.

Of course, the example above is very simple. In practice, you need to interact with your internal APIs. To do this, we create a Skill with the IPs, API documentation, usage examples (for instance with curl), architecture information, and any detail the agent needs to execute the task. We also specify the keywords the user can use to trigger that Skill, such as "get node backup", "download node backup", "node backup by email", etc.

Let's say the user wants a CSV with the timestamp and log from the last 5 minutes.

> I want a CSV with the log from the last 5 minutes of node 23

• The logs Skill is activated, which has all the information to execute the task. It connects to the API and retrieves the data in JSON format.
• The plain text format transformation Skill is activated, converting JSON to CSV.
• The Skill that uploads files to our cloud is activated.

Status: PROCESSING...

Analyzing node 23 status...
Extracting logs from the last 5 minutes...
Restructuring format...
Uploading file to cloud...

> Here's the download link for the CSV with the logs from the last 5 minutes: https://example.com/node23_20260610_1230.csv

More actions you can take:
[1] Send by email
[2] Download directly
[3] View logs on screen

[4] Return to main menu

>

Simple, right?

My last piece of advice is to build the UI as an initial prompt. Inside ~/.agent/prompts/ you can create a custom prompt, for example ui.md, with instructions or templates for how the interaction with the user should look.

First impressions

We're still in the testing phase, observing how users interact. There's still a lot to tweak and learn.

Currently, we have a private repository with the Skills. To install them, we have a prompt in the documentation that users copy and paste into their own prompt. It automatically creates the necessary files in the Skills folder and makes some modifications: the UI prompt, a scheduler to check whether Skills need updating or if new ones should be added, etc.

I'll tell you upfront: this is not a UI killer. It has its limitations:

Pros

• Execute features using natural language
• Simple installation process (copy and paste a prompt)
• Cross-platform
• Low learning curve (or none at all)
• Accessible by default
• Saves a lot of resources on UX/UI design and interface development (native or web)

Cons

• Not multi-device, since it sometimes requires specific tools not available on phones, tablets, etc.
• Slower than a traditional graphical interface
• You need good hardware for a smooth experience
• It's hard for users to fine-tune advanced settings
• Users don't understand what's happening under the hood

In short, it's a different way for users to interact with tools — more natural, but with its limitations. Even so, it's an interesting experiment that's giving us good results and that we'll keep exploring.