Anyone who takes notes seriously runs into the same thing. You’re in a meeting or reading a doc, you write something down fast, and the note is never quite finished. Maybe someone drops a term you don’t know and you jot it down to look up later. Maybe you sketch a concept that isn’t fully clear yet and want to expand it once you have a minute. Maybe there’s a number you meant to check, or a “wait, is this true?” that you scribbled and skipped past. So you leave yourself a marker and tell yourself you’ll come back to it.
You don’t come back to it. The note just sits there, saved but useless, because the missing bits are the parts you actually needed. I had folders full of these. Notes that were most of the way there and nowhere near done, all stuck on a few small questions I never got around to researching. That’s the thing I wanted to fix, and the fix turned into a small skill I use all the time now: Note Completer.
The problem: notes that ask more than they answer
The annoying part of a half-done note isn’t the missing information itself. It’s the cost of going back for it. To finish one note you have to load the whole context again. What was I thinking, why did I flag this, what did I need to know? Then you open a browser, run a few searches, and come back to type the answer in. One note is a few minutes. A backlog of them is an afternoon you never actually book.
So the questions stack up. And there’s a quieter cost too: a note with open questions in it isn’t just unfinished, it’s something you can’t trust. You can’t hand it to a colleague or lean on it in a decision, because you don’t know which parts you checked and which are still guesses. A few gaps make the whole thing shaky.
What I wanted was easy to describe and tedious to do by hand. Something that reads a note the way I would, finds the spots where I left a question, goes and gets the answer, and puts it back into the note in the right place and in a voice that matches the rest, without me sitting there feeding it one line at a time.
The options I looked at
The first option was discipline: finish every note before you close it. That advice is useless here. The reason the questions exist is that I didn’t have the answer when I was writing. Telling me to just finish the note ignores that the missing piece usually needs research I can’t do in the middle of a meeting.
The second option was a normal chatbot. Copy a question out of the note, paste it into a chat window, read the answer, paste it back. It works, and I did it for a while. But it throws away the context. The assistant can’t see the rest of my note, so the answers come out generic. And the copy-out, paste-back loop, done for every question in every note, is the exact friction I was trying to get rid of.
The third option was a research agent that swallows the whole document and rewrites it. Powerful, but wrong for this. I don’t want my notes rewritten. I want my words left alone and the holes filled. An agent that reprocesses everything tends to smooth out my voice and polish prose that was fine as it was.
Lining those up told me the shape I actually needed. Not discipline, not a generic chatbot, not a rewriter. Something narrow: a skill that treats my note as the truth, touches only the questions I marked, and leaves the rest exactly how I wrote it.
The solution: Note Completer
Note Completer does one thing. You mark the questions you want answered inside your markdown note, and it fills them in where they are, in context, in your voice.
This fits how I already work. I keep my notes in Obsidian, which means every note is just a plain markdown text file sitting in a folder on disk. There’s no database, no proprietary format, no export step. That’s the reason the whole thing is possible: because my notes are ordinary files, Amazon Quick can open them directly, the same way it would open any other file.
I run it as a skill inside Amazon Quick. That matters, because Quick is already sitting on top of my files and can search the web, so the skill has everything it needs in one place: it reads the note straight from my folder, researches each question, and writes the answers back into the same file. I don’t move anything around or switch apps. I point Quick at the note, it does the work, and the finished note is right where I left it.
The marking is the important choice. Instead of explaining to an assistant what I want, I put the request where it belongs. I wrap an inline question in ==question== markers, right at the point where the answer should go.
In a note about a service I might write:
The default timeout is ==what is the default connection timeout for this API?==.
That highlighted bit is both the question and the slot for the answer. It also kicks in when I hand it a file ending in .md, or when I just say “answer the questions in the note”.
The == syntax isn’t arbitrary, and this is where Obsidian pays off a second time. In Obsidian, text wrapped in == renders as a highlight, the same yellow marker you’d use on paper. So my questions show up highlighted while I’m writing, easy to spot in a wall of text. And because the skill keeps the == markers and only swaps the question for the answer, the answers stay highlighted too once it’s done. I can glance at any note and instantly see which lines came from Note Completer, sitting right next to the words I wrote myself.
Once it’s running, it works in a few steps. It reads the whole note first, not just the question, so an answer about a timeout gets scoped to the service the rest of the note is about instead of answered in a vacuum. For each ==question== it goes and finds the answer, searching the web when the question needs outside or current facts and using what it already knows when it doesn’t. Then it writes the answer back in place, replacing the marker so the note reads like a finished document. No separate answer key, no Q&A section tacked on the end, no reshuffling of the parts I didn’t ask about.
So the note goes in with holes and comes out whole. The paragraphs I wrote stay put. Only the marked gaps change, and they turn into answers that fit the sentence they land in. I can clear a note with five open questions in one pass instead of five separate context switches, and I never have to leave the document I’m working in.
Under the hood it uses a small, deliberate set of tools: reading the file, editing it precisely, and searching the web when a question needs it. That narrowness is why I trust it with real notes. It isn’t rewriting my thinking. It’s finishing the sentences where I asked it to.
The best part is what it did to my habit. Now, when I hit a gap while I’m writing, I don’t stop and I don’t stress about it. I drop in a ==question== and keep going, because I know I can point Note Completer at the file later, through Quick, and get a finished note back. The marker turned “I’ll deal with it later,” a promise I always broke, into a task the tool actually clears.
Conclusions
Unfinished notes aren’t a discipline problem, they’re a tooling problem. The missing pieces need research you can’t do while you’re writing, and going back for them by hand costs too much. Note Completer, running as a skill in Amazon Quick, takes that cost away by answering inline ==questions== inside your markdown, in context and in your own voice.
If you write notes in markdown, try it on your worst backlog first. Open the note that’s been almost done for a month, wrap each open question in ==markers==, point Quick at it, and let the skill fill them in. You’ll get back a note you can actually use.
Ecco la skill:
---
name: note-completer
display_name: Note Completer
description: "Answer inline questions in a markdown note. Activate when the user pastes a note with ==question== markers, provides a filename ending in .md, or says 'rispondi alle domande nella nota', 'completa nota', or 'rispondi a nota:'. Also activate when the user message contains text with == delimiters that look like inline questions."
icon: "📝"
trigger: rispondi alle domande nella nota
inputs:
- name: nota
description: "Either a file path to a local markdown note, or the full text of the note pasted in the prompt. When it's a file path, the skill reads and modifies that file in place. When it's inline text, the skill returns the completed note in the response."
type: string
required: true
tools: [file_read, file_edit, web_search, url_fetch]
---
## Overview
This skill answers inline questions embedded in a markdown note. Questions are delimited by `==` markers (e.g. `==What is a VPC?==`) and are always an explicit question with question marks. Ignore everything delimitated by '==' if it is not an explicit question. The skill reads the full note to understand context, researches each question using web search, and replaces the question text between `==` with a concise technical answer in English.
## Workflow
### Step 1: Determine Input Mode
- **Mode**: `agentic`
- **Input**: `{{nota}}` — either a file path or inline note text
- **Output**: The full note content + a flag indicating whether to modify a file or respond inline
- **Validate**: The note contains at least one `==...==` block
- **On failure**: If no `==` markers found, ask the user to clarify which parts are questions
Detect whether `{{nota}}` is a file path (ends in `.md`, `.txt`, or is a path-like string pointing to an existing file) or raw note text. If it's a file path, read it with `file_read`. Store the full note content and remember the input mode for Step 5.
### Step 2: Parse Context and Extract Questions
- **Mode**: `agentic`
- **Input**: Full note content from Step 1
- **Output**: A list of questions extracted from `==...==` blocks, plus understanding of the note's topic/context
- **Validate**: At least one question extracted
- **On failure**: Re-scan the note; if still nothing, inform the user
Read the entire note carefully to understand its topic, domain, and context. This context will guide your web searches to produce relevant, domain-appropriate answers.
Extract all strings between `==` delimiters. Each `==content==` block is one question. Preserve their order and position in the note. Ignore everything delimitated by '==' if it is not an explicit question.
### Step 3: Research Answers
- **Mode**: `agentic`
- **Tool**: `web_search`, `url_fetch`
- **Input**: Each question + the note's context
- **Output**: A concise technical answer in English for each question
- **Validate**: Each answer is factual, concise, and in technical English
- **On failure**: If web search yields no good result, try rephrasing the query using the note's context. If still no answer, write "No authoritative answer found" as the answer.
For each question:
1. Formulate a search query that combines the question with relevant context from the note (e.g., if the note is about AWS networking, search "VPC peering AWS" not just "VPC peering")
2. Use `web_search` to find authoritative sources
3. If needed, use `url_fetch` to get detailed content from the best result
4. Compose a concise, technically accurate answer in English — typically 1-3 sentences unless the question demands more
Answers should be:
- Always in **English** (technical English), regardless of the note's language
- Concise but complete — no filler, no unnecessary preamble
- Factual and sourced from web results, not from general knowledge alone
### Step 4: Insert Answers into Note
- **Mode**: `agentic`
- **Input**: Original note content + answers for each question
- **Output**: Updated note with `==answer==` replacing each `==question==`
- **Validate**: Every original `==question==` block has been replaced with `==answer==`; no other content in the note has changed
- **On failure**: Re-check the replacements; ensure no accidental edits to surrounding text
Replace each `==original question==` with `==answer==`. The `==` delimiters remain — only the content between them changes from a question to the answer.
Critical: Do NOT modify any other part of the note. Only the content between `==` markers changes.
### Step 5: Deliver Output
- **Mode**: `deterministic`
- **Tool**: `file_edit` (for file mode) or direct response (for inline mode)
- **Input**: Updated note content + input mode from Step 1
- **Output**: Modified file or inline response
- **Validate**: For file mode — verify the edit was applied. For inline mode — the complete note is in the response.
- **On failure**: If `file_edit` fails, try `file_write` to overwrite the file with the complete updated content.
If the input was a **file path**: use `file_edit` to apply the changes to the original file. Do not create new files or touch any other file.
If the input was **inline text**: return the completed note directly in the chat response, preserving all original formatting.
## Output
The original note with every `==question==` replaced by `==concise technical answer in English==`. All other content remains untouched.
## Lessons Learned
### Do
- Read the full note first before answering any question — context matters for accurate answers
- Use the note's domain/topic to refine web search queries
- Keep answers concise and technical — these are inline annotations, not essays
- Preserve the `==` delimiters around answers so the user can spot them easily
- Verify that no surrounding content was accidentally modified
### Don't
- Don't answer from general knowledge alone — always verify with web search
- Don't change the note's language or formatting outside `==` blocks
- Don't create additional files or modify files other than the one specified
- Don't remove the `==` markers — they stay as visual delimiters around answers
- Don't add citations or URLs inside the `==` block — keep it clean
### Common Failures
- **File not found**: The user may give a relative filename — try searching in common locations (Downloads, Desktop) before failing
- **Ambiguous questions**: Some `==` blocks might be very short or unclear — use the surrounding note context to interpret them
- **No web results**: For very niche questions, broaden the search or acknowledge "No authoritative answer found"
### When to Ask the User
- If the note contains no `==` markers at all
- If a `==` block is ambiguous and could be interpreted as either a question or intentional formatting
- If the file path doesn't resolve to an existing file