How it works
You give it work in Slack. It shows what it understood. Then it works on your existing code. You review a change — not a chat log.
Step 1
Ask where the work already is.
Mention Velden or type /velden in the Slack thread. Starting in the app is a fallback, not the usual path.
You ask in the thread where the work already is. You
Could the sidebar show a short preview under each note? The first line is enough.
Step 2
Shows its understanding before it writes code.
You see the ask restated, the scope, and what it will not touch. If that is wrong, you stop it there.
What you see in Slack before it writes code. Velden
Here's what I understood: Add a one-line preview under each note in the sidebar, from the first sentence of the body.
- Scope
- : The note list in the sidebar.
- Won't change
- : The editor, sharing, and delete.
Risk: low · Confidence: high
Looks right, continue
Step 3
Asks only the questions it cannot infer.
Product decisions, grouped, rare. Not homework about which file to open.
Only when it cannot infer the answer. Velden
I need a quick clarification before I proceed:
When a note has no text yet, what should the preview show?
Nothing“Empty note”
Step 4
Hands back a change. You decide what goes live.
What changed, whether the checks passed, and a preview when your repo builds one. Velden never merges; going live stays a human decision.
What comes back: a change to review, not a chat log. Velden
Ready for review
- Changed
- : NoteList, notePreview
Automated checks passed.
Send to engineering reviewRequest changesOpen preview