07 · A local app with no code

At a glance

Solves	You want a small tool that does not exist, and you do not write code
Needs	Code development mode; an empty folder
Takes	5–10 minutes to a minimum viable version; debugging varies
Risk	Medium — it generates and runs code

The situation

You want somewhere to capture ideas: add, search, categorise, simple interface, data stored locally.

Every note-taking app is either too heavy or wants a subscription, and the features you actually need number four.

Preparation

1. Make an empty folder for the workspace, e.g. my-tools
2. Choose code development mode (代码开发) when creating the task — its defaults suit this better
3. Stay on default permissions

Use an empty folder

Code generation writes a lot of files. In an empty directory you can delete the whole thing and start again without collateral damage.

The prompt

Round one: minimum viable version

Build me a locally runnable idea-capture tool.

Four features only:
1. Add an entry (title + body + tags)
2. Search by keyword
3. Filter by tag
4. Edit and delete

Requirements:
- Single-page app; double-clicking the HTML opens it, nothing to install
- Data stored in browser local storage, surviving a close and reopen
- Clean, light interface, comfortable to look at for a long time
- Works on a phone too

Build those four and get it running. Do not add anything else.

"Minimum viable first" is the whole point

The official recommendation: complete the core features, then add complexity.

Asking for ten features gets you ten half-broken ones and no way to tell which broke what. Four working features make the fifth easy.

Round two: confirm it runs

Open the preview in the Browser view on the right and click through all four features.

Round three: describing a bug

Clicking save gives a white screen. The console says
TypeError: Cannot read properties of null.

To reproduce:
1. Click "add"
2. Title "test", body left empty
3. Click save

It does not fail when the body has content.

Describing the actual symptom is ten times more useful than "it does not work". Three parts:

• The symptom — what you actually saw (white screen, the error text, a dead button)
• Reproduction — the steps that produce it
• The boundary — when it works and when it does not

The third is the most valuable. "It does not fail when the body has content" narrows the problem to empty-value handling immediately.

Use screenshots

Error screens, console output and log screenshots all help it locate the problem. Ctrl / Cmd + V pastes them straight into the input box.

That assumes the current model takes image input — see the model list.

Why it is written that way

"Double-clicking the HTML opens it, nothing to install" determines the technology choice. Without it you may get a project needing npm install and node server.js — which, for someone who does not write code, is unusable.

"Data stored in browser local storage" pins down persistence. Without it a refresh may lose everything.

"Build those four. Do not add anything else." Models have a strong urge to add features. Unchecked, you get tag clouds, export, theme switching and keyboard shortcuts — three of which are broken.

"Get it running." A clear definition of done: working beats complete.

Acceptance checklist

• [ ] Double-clicking the file opens it, no extra steps
• [ ] All four features work when clicked through
• [ ] Close the browser, reopen — the data is still there
• [ ] The layout holds up on a phone
• [ ] Empty values, very long text and special characters do not crash it
• [ ] You can tell from the Changes view which files it generated

Try the awkward inputs

Empty title, 5,000 characters of body, <script> in a tag field — AI-generated code is usually fine on the happy path and falls over at the edges.

Two minutes now beats fixing it later.

Iterating

Once it runs you can extend it in use. Directions the official docs suggest:

Want	What it might do
Fuzzy search that does not need exact keywords	Add local vector or semantic search
A push of pending items every morning	Configure an automation that aggregates to-dos
Capture from QQ or WeChat any time	Connect a messaging platform and add a mobile input channel
Automatically link new entries to existing ones	Add relationship analysis and knowledge organisation

One capability at a time

"Split your upgrade requests" — one class of capability per round makes iteration far more stable.

Ask for three at once and, when something breaks, you cannot tell which change did it.

How to phrase an upgrade:

Add one feature: export.

Support Markdown and CSV, exporting the current filtered results (not everything).

Only that one — leave everything else alone.

That last line is useful: explicitly bounding the change reduces the chance it "improves" something else along the way.

Variations

Start from a design

Use design mode: generate the interface by conversation, refine it on the Ardot canvas, then generate the application code in one click.

Two triggers: say "generate an application from the current canvas design", or click Generate app at the top of the canvas tab.

Afterwards you can still adjust the code in conversation: "rewrite it in React", "add a dark mode", "convert to Tailwind".

Take this route when you have firm opinions about the interface. Straight prompt generation gives you something usable, rarely something striking.

Store data in a file instead of the browser

Change the storage: instead of browser local storage, read and write
data.csv in the workspace.

That way I can open it in Excel and back it up easily.

This connects the tool to the Library's CSV-as-source-of-truth idea — data separate from presentation, so changing data never touches code.

A plain local script

When you do not need an interface:

Write a script that scans every image under D:/photos and files them into
YYYY-MM subfolders by EXIF capture date.

Requirements:
- Dry-run by default: print the plan without moving anything
- Only move with an --execute flag
- Skip and log files with no EXIF
- Print a log line for every step

The dry-run design is worth learning: build the preview into the script, the same idea as preview-then-execute but frozen into code.

FAQ

I cannot read the code — is it safe?

For a pure front-end single-page app (HTML plus JS, data in the browser) the risk is very low — it runs in the browser sandbox.

What deserves caution is scripts that run on your system: Python, PowerShell, shell. For those, ask first:

Explain what every line of this script does, marking specifically: which files
it reads, which it writes, whether it uses the network, whether it deletes anything.

If you cannot follow the answer, do not run it. This is also why default permissions stop before executing a script.

It keeps getting worse the more I change it.

Two options:

1. Start a new task. After a long conversation the model starts forgetting earlier context; rather than fighting a bad context, open a new task and restate the current code and requirement
2. Have it back up first. Copy the current version to index-v1.html before changing anything

Can it build a real desktop app?

It can generate an Electron-style project, but packaging, signing and distribution are outside "no code".

If the goal is your own use, a single HTML page is enough, and it comes with none of the distribution or update headaches.

Can I give these tools to colleagues?

A single HTML file can just be sent; each person's data is their own. For shared data, look at the Library's publish as website with a CSV data source.

Next

08 Turn a routine into a Skill