SideNote Pro workflows for developers

Ask questions about a repository

Index a project folder in Settings, Folder context. Generated and vendor directories such as .git, node_modules, bin, obj, dist and build are excluded automatically, so the index reflects your code rather than your dependencies.

This is most valuable on a codebase you did not write. Questions worth asking on day one:

• Where is authentication configured, and which files define session expiry?
• Which files handle database migrations, and what order do they run in?
• Where is the retry logic for outbound HTTP calls?
• Which configuration values are read at startup, and where do their defaults live?

The Sources list is often more useful than the prose answer. It names the four files you should open, which was the real question. Open and Reveal are one click from there.

Settings › Folder context

Triage errors without leaving the terminal

Select a stack trace or error message anywhere, in a terminal, a log viewer, a browser console, press Ctrl+Shift+Q, type the one thing the trace does not contain, and choose the Ask row. Or give Ask SideNote a shortcut of its own and type your question in the composer.

That last part matters. A stack trace tells the model where it broke. What it cannot tell the model is what you were doing, what changed recently, or what you expected. This started after we moved the job to run concurrently turns a generic answer into a useful one.

A custom action worth building: Explain this error to someone unfamiliar with this codebase, then list the three most likely causes in order of likelihood: {{selection}}. Bind it to a key and it becomes the reflex for any unfamiliar failure.

Keep the commands you keep looking up as an Active Note: a build invocation, a deployment checklist, a query you run once a month. Float it while you work, or attach it with adjust this command for the staging environment when it needs changing. The answer is text, and nothing runs until you run it yourself.

Capture what you cannot paste

A rendering bug

Region capture, then this layout breaks at this width, which element is most likely overflowing? Combine with folder context over your source and you get a file rather than general advice.

A profiler or monitoring graph

What does this pattern suggest about where time is going?

A tool's error dialog

that will not let you select its text. Ctrl+Shift+X captures it from where you are.

A diagram in documentation

Region capture beats describing an architecture diagram in prose.

Your model needs image support for any of this. Worth checking on local providers, where many small models are text-only.

Match depth to the problem

Developer questions split cleanly, and the split is worth acting on because the cost difference is large.

The left column is the majority of daily use and does not need a heavyweight model. Escalate when a fast answer is visibly shallow rather than starting deep. See a model for each task.

Reading code and reviewing changes

• Select an unfamiliar function and press Explain. Faster than reading it cold, and you still read it afterwards.
• Select a diff and ask for a commit message. A worthwhile custom action.
• Ask what would a reviewer object to here on your own change before opening a pull request.
• Ask what is this code assuming that is not checked on anything handling input.
• For a design document, index the folder it lives in and ask what it contradicts elsewhere.