This project is a personal knowledge vault — a Second Brain for managing scattered information and thoughts. You capture web articles and notes with a single command, and AI automatically organizes and connects this material into meaningful atomic notes. You can find the notes you need instantly by asking questions in plain language, weave several notes together into the draft of a new piece of writing, or even polish that writing together with AI.

Source Repository: https://github.com/slowww-ai/second-brain

Chapters

1. Capture: Saving URLs as Raw Material
2. Distill & Connect: Refining Raw Material into Atomic Notes
3. Vector Indexing & Search: Finding Notes by Meaning
4. Synthesis: Weaving Connected Notes into New Writing
5. Collaborative Writing: Polishing Drafts with AI

---

Chapter 1: Capture — Saving URLs as Raw Material

Welcome to the journey of building a Second Brain! The very first piece of this system — and its most important habit — is capture.

Have you ever had dozens of browser tabs open with things you meant to read later, or saved a link you absolutely had to see, only to forget where you stashed it? These "I have to read this later" thoughts create open loops in your head, and they're the prime culprit behind scattered attention.

The capture stage is a very simple solution to this problem. Think of it as a digital butterfly net you swing whenever you stumble on something interesting while browsing. No need to worry about organizing or understanding it yet — you just snag it.

In this chapter, you'll learn the capture process that serves as the front door to this system, and you'll master how to save a web page into your knowledge vault as "raw material" with a single command.

The Core Goal: Capturing Information in One Second

The philosophy of the capture stage is minimizing friction. The moment saving something requires several steps — or makes you wonder "which folder should this go in?" — you start putting it off. This system removes that hesitation.

• The problem: You find an interesting article on the web, but you don't have time to read it right now.
• The old way: Leave the browser tab open, or add it to your bookmarks and forget about it.
• The Second Brain way: Copy the URL and type a single command. The information is saved safely and instantly, and you can get back to focusing on what you were doing.

This one simple habit alone frees you from the pressure to read and lets you build up knowledge with a much calmer mind.

/jina-capture: Your Digital Butterfly Net

The simplest way to capture a web page is to use the /jina-capture command in the Claude Code chat window.

For example, suppose you've found a great article about the Zettelkasten method.

/jina-capture https://en.wikipedia.org/wiki/Zettelkasten

What happens when you enter this command?

1. Claude Code uses an external service called jina.ai to fetch the contents of that URL.
2. It strips out unnecessary elements like ads and menus, keeping only the main text, and converts it into clean Markdown.
3. It saves the converted content into the wiki/raw/ folder under a filename built from today's date and the article's title. Something like wiki/raw/2024-10-26-zettelkasten.md.

Now it's fine to close that browser tab. The article's contents are preserved, intact and in their original form, in the wiki/raw/ folder on your computer.

The wiki/raw/ Folder: Where Everything Begins

The wiki/raw/ folder is like the pantry of your Second Brain. Just as you toss the vegetables and meat you bought at the market straight into the fridge without trimming them first, this is where you throw the information you capture from the web — or a passing thought — exactly as it is, raw and unprocessed.

There's just one thing to remember about this folder.

'Only add — never edit or delete.'

This is an archive that preserves originals. How to cook this raw material later is something you'll learn in the next chapter, Distill & Connect: Refining Raw Material into Atomic Notes. For now, just focus on diligently gathering ingredients.

You can also write your own notes and drop them in here.

A Peek Under the Hood

Let's walk through a simple diagram of what happens inside the system when you enter the /jina-capture command.

This whole process is handled automatically by a single line. You don't need to know any of the complicated steps — you just swing the "digital butterfly net."

The exact behavior of this command is defined in our project's .claude/skills/jina-capture/SKILL.md file. This file is a kind of "instruction manual" that tells Claude Code how to behave when it hears the /jina-capture command.

# Part of the .claude/skills/jina-capture/SKILL.md file
---
name: jina-capture
description: Fetch a web page as clean markdown and save it directly to wiki/raw/ as a new capture.
---
# Jina Capture

Convert any URL into a timestamped markdown file in `wiki/raw/`
using the Jina Reader service (`https://r.jina.ai/<url>`).

## Steps

1. **Confirm the target folder.** The default is `wiki/raw/`.
2. **Fetch the markdown.** Call the `https://r.jina.ai/<url>` address.
3. **Extract the title and slug.** Parse the title from Jina's output.
4. **Write the file.** Save it to `wiki/raw/<YYYY-MM-DD>-<slug>.md` with frontmatter.
...

As you can see, many of the automation features in the Second Brain workflow are powered by predefined "skills" that carry out specific tasks.

Wrapping Up

In this chapter, you learned about capture, the very first stage of the Second Brain system.

• Why does capture matter?: It clears the "I should read this later" thoughts (open loops) out of your head so you can focus on what you're doing right now.
• How do you capture?: With a single /jina-capture <URL> command, you can save any web page into the wiki/raw/ folder exactly as it is.
• The role of the wiki/raw/ folder: It's a vault for storing unprocessed raw material. The key is to honor the rule: "only add — never edit or delete."

You now have a powerful tool that lets you safely store any piece of information you run into while exploring the web in your own knowledge vault, without ever losing track of it.

But gathering ingredients alone doesn't make a meal. In the next chapter, we'll look at how to refine all this collected raw material into meaningful pieces of knowledge and connect them to one another.

---

Next up: Chapter 2: Distill & Connect — Refining Raw Material into Atomic Notes

---

Chapter 2: Distill & Connect — Refining Raw Material into Atomic Notes

In the previous chapter, we learned how to use the digital butterfly net (/jina-capture) to capture interesting bits of information from the web into the wiki/raw/ folder as raw material. By now your raw/ folder is probably like a pantry stacked with all kinds of articles and notes.

But having lots of ingredients doesn't automatically produce a meal. A long article or a tangle of rambling notes is, on its own, hard to revisit and hard to connect to other ideas. From here, we'll learn how to refine this raw material into meaningful pieces of knowledge through the distill and connect processes — the very heart of this system.

The Problem: You've Gathered Information, But You Can't Use It

Think about that "Zettelkasten Wikipedia page" sitting in your raw/ folder. The content is good, but it's quite long. Suppose later you want to look up just the concept of "atomic notes" — do you really have to reread the whole long article? And what if, while writing another piece about the importance of "cross-referencing," you want to quote a relevant passage from the Zettelkasten article?

This is exactly the problem the distill stage solves. It's the process of extracting only the gems — the core concepts — from the raw ore of a long article.

• The problem: A long article mixes several concepts together, making it hard to reuse.
• The old way: Reread the entire long article every time and hunt for the part you need.
• The Second Brain way: Read the article once, break it into several small "atomic notes," and link those notes to one another.

It's like getting a giant LEGO castle with no instruction manual: first you break it all down into the smallest blocks and sort them by type. Once you've done that, building whatever you want next — a car, a spaceship — becomes far easier.

/ingest: Your Knowledge Alchemist

The command that handles this seemingly complex distill-and-connect process in a single shot is /ingest. The word "ingest" means to take in or digest — and that's literally what it does: Claude Code digests the new ingredients in your raw/ folder and turns them into nourishing knowledge in your notes/ folder.

Just type this into the Claude Code chat window.

/ingest

When you issue this command, Claude begins the following alchemy:

1. It looks through the wiki/raw/ folder to check for new files that haven't been processed yet.
2. When it finds new files, it reads their contents and identifies the core concepts.
3. It splits each core concept into a small unit called an atomic note. An atomic note is one that contains a single idea or concept that can't be broken down any further.
4. It saves each of these split-out notes as its own file in the wiki/notes/ folder.
5. It links related notes to one another using [[wikilinks]].
6. It records the raw/ files that have been processed so they won't be processed again.

For example, processing the raw/2024-10-26-zettelkasten.md file with /ingest might produce files like these in the notes/ folder:

• notes/zettelkasten.md
• notes/atomic-notes.md
• notes/evergreen-notes.md

And inside zettelkasten.md you'd find a link like [[atomic-notes]], marking the beginning of a knowledge network between notes.

A Peek Under the Hood

Let's walk through a simple diagram of what happens inside the system when you enter the /ingest command.

This whole process is a collaboration between Claude Code and a few helper scripts. You just chant the magic spell — /ingest.

A Deeper Look at the Code: What Drives /ingest?

Behind the magic lie a well-crafted "instruction manual" and a "tool."

First, the manual that tells Claude Code how to behave when it receives the /ingest command is defined in the .claude/commands/ingest.md file.

# Part of the .claude/commands/ingest.md file
---
description: Process new files in wiki/raw/ into distilled notes in wiki/notes/
---

Your job is to turn new raw captures into clean, linked wiki notes.

Steps:

1. Run `python scripts/ingest.py list-new` to find raw files not yet referenced...
...
3. For each new raw markdown file:
   a. Read it...
   b. Identify the 1–3 core concepts in the file.
   c. ...create a new note in `wiki/notes/<slug>.md` with proper frontmatter, and `[[wikilinks]]`...
...
6. **Record each processed raw file in the ledger.** After you finish... run:
   `python scripts/ingest.py record <raw-filename> <note1,note2,...>`
...

Following this manual, Claude uses a Python script called scripts/ingest.py as its tool. This script plays two important roles.

1. Finding new ingredients (list-new)

Even when hundreds of files pile up in the raw/ folder, Claude skips the ones it already processed and pinpoints exactly the files that were newly added or changed.

# You can also run this directly in your terminal.
python scripts/ingest.py list-new

Running the command above shows you a list of files that haven't been processed yet, like this:

2024-10-26-zettelkasten.md  (new)
2024-10-27-some-other-article.md (new)

2. Stamping things "done" (record)

You wouldn't want to cook the same ingredient twice, right? When Claude finishes processing a file, it uses the record command to stamp it "this one's done!" This record is stored in a small database file called wiki/index.db.

# Part of scripts/ingest.py
def record(raw_name: str, produced: str) -> None:
    # ... (omitted) ...
    con = connect() # Connect to the database
    con.execute(
        # Insert or update the processing record in the 'ingested' table
        "INSERT OR REPLACE INTO ingested(...) VALUES (?, ?, ?, ?)",
        (raw_name, content_hash(path), ... , produced),
    )
    con.commit() # Save the changes
    # ... (omitted) ...

So /ingest isn't a simple command — it's an automated workflow that combines well-defined rules with efficient tooling.

wiki/notes/: Your Living Knowledge Network

The notes created by /ingest are stored in the wiki/notes/ folder. This folder has a different character from the raw/ folder.

Folder	Rule	Role
wiki/raw/	Append-only (no editing or deleting)	An archive that preserves originals — the pantry
wiki/notes/	Freely editable and deletable	A living knowledge wiki — the tidy kitchen

The notes inside the notes/ folder can become evergreen notes that keep growing along with your thinking. Once Claude sketches out a draft, you can open the note yourself to refine it, add new thoughts, and link it to other notes — tending your own knowledge garden. It's especially convenient if you use a Markdown editor like Obsidian, which lets you see the connections between notes visually and jump between them easily.

Wrapping Up

In this chapter, you learned about the distill and connect process — the core of the Second Brain system.

• Why does distillation matter?: It turns long articles and notes into atomic notes, small reusable units of knowledge, making it easy to connect and expand ideas.
• How do you distill?: A single /ingest command automatically analyzes the new material in your raw/ folder and builds an interlinked network of atomic notes in your notes/ folder.
• The difference between raw/ and notes/: raw/ is a "record of the past" you don't edit, in order to preserve originals; notes/ is your "present knowledge" that you can refine and grow at any time.

You now hold a powerful alchemy that transforms scattered fragments of information into a meaningful knowledge network. Well-organized notes are wonderful in their own right, but they only become a true Second Brain when you can pull them up and put them to use the instant you need them.

In the next chapter, we'll explore how to search this knowledge network you've built intelligently — by meaning.

---

Next up: Chapter 3: Vector Indexing & Search — Finding Notes by Meaning

---

Chapter 3: Vector Indexing & Search — Finding Notes by Meaning

In the previous chapter, we learned how to use the /ingest command to distill captured raw material into meaningful atomic notes and connect them to one another with [[wikilinks]]. By now your wiki/notes/ folder has begun to take shape as a web of interconnected knowledge — a true wiki.

But what happens when your notes grow to dozens, even hundreds? When you need a specific piece of information, remembering exactly which file held it is no easy feat. Searching by keyword in your file explorer (Ctrl+F) often just isn't enough. For example, imagine you wrote a note about "the Pomodoro Technique" and later go looking for "ways to improve focus." The two phrases use different keywords but their meanings are very close. Traditional search struggles to connect them.

In this chapter, you'll learn the vector indexing and search technique that gives your Second Brain a smart memory. With it, you'll have the magical experience of finding the note you want in an instant based on meaning rather than keywords.

The Problem: My Wiki Needs a Smart Librarian

Your wiki is now like a library with a vast collection of books. But without a librarian to tell you where the books are, it's useless.

• The problem: It's hard to find information when you can only vaguely recall the concept — like "I had an idea about productivity-boosting habits... which note was that again?" — without remembering the exact keywords.
• The old way: Rely on memory to search for various keywords in filenames or body text. If that fails, give up.
• The Second Brain way: Pose a natural question, like "/ask productivity habits." The system understands the meaning, finds the most relevant notes, and answers.

This is the difference between a librarian who only knows book titles and a wise librarian who understands the contents of every book and recommends, "If you're looking for that topic, check these books and chapter 3 of that one." Our goal is to build an intelligent search system like the latter.

Giving Notes a 'Meaning Address'

How can a computer understand the meaning of a piece of text? The secret lies in a technique called vector embedding. There's no need to overthink it — let's understand it with a simple analogy.

Imagine a giant map called meaning space, where the meaning of every note can be represented as a single point.

• "Apple" and "orange" both share the trait of being "fruit," so they sit close to each other on the map.
• "Apple" and "car," on the other hand, mean entirely different things, so they sit very far apart on the map.

Vector embedding does exactly this. A powerful AI model like Gemini reads the contents of our notes and converts their meaning into a combination of hundreds of numbers (a vector). That combination of numbers becomes a unique address (coordinates) on the meaning space map.

This process breaks down into two stages.

1. Indexing: The process of assigning a meaning address to every note in our wiki and registering it on the map.
2. Searching: The process of converting our question into a meaning address as well, then finding the notes whose addresses are closest on the map.

Stage 1: Indexing — Building the Knowledge Map (reindex.py)

The reindex.py script is responsible for reading every note in our wiki and building the meaning map. Fortunately, this process is mostly handled automatically. When you run the /ingest command from the previous chapter, this indexing process runs automatically as the final step after new notes are created.

The reindex.py script does the following:

1. It checks every note in the wiki/notes/ folder.
2. It picks out only the notes that have changed since they were last indexed or that are newly added.
3. It sends the body of those notes to the Gemini model.
4. It gets back a vector (a list of numbers) representing each note's meaning from the Gemini model.
5. It stores this vector, along with the note's ID, in a special database called wiki/lancedb/.

Below is part of the reindex.py code — the core piece that takes a note's body and converts it into a vector.

# Part of scripts/reindex.py

def embed(client, text: str) -> list[float]:
    # Ask the Gemini model for an embedding of the text.
    resp = client.models.embed_content(model=MODEL, contents=text)
    # Return the vector values that came back.
    return resp.embeddings[0].values

# ... (inside the loop) ...
for p in NOTES.glob("*.md"):
    # ... (omitted) ...
    # Convert the note body into a vector
    vec = embed(client, body[:8000])
    # ... (store in the database) ...

This code shows the process of passing each note's text (body) to the embed function to get a list of numbers (vec). With this, every fragment of our knowledge gains a searchable meaning address.

Stage 2: Searching — Summoning the Knowledge You Need Instantly (/ask)

Now that we have a well-made map, it's time to find our way. The /ask command serves as our intelligent search box.

Ask a question related to your wiki in the Claude Code chat window.

/ask What are the core principles of Zettelkasten?

When you issue this command, the following happens in an instant:

1. Claude processes your question ("What are the core principles of Zettelkasten?") using the scripts/search.py script.
2. search.py converts your question sentence into a question vector, again through the Gemini model.
3. It then sends a query to the wiki/lancedb/ database: "Find the 5 note vectors that are semantically closest to this question vector!"
4. The database returns a list of the most relevant notes — zettelkasten.md, atomic-notes.md, and so on.
5. Claude reads the contents of these notes and generates an answer to the question based on that information.
6. Finally, it shows the answer in the chat window, citing its sources — which notes it referred to — like [[zettelkasten]].

Let's walk through the flow of this whole process with a diagram.

Below is part of the code showing how search.py turns a question into a vector and searches the database.

# Part of scripts/search.py

def semantic(query: str, limit: int = 10) -> None:
    # 1. Convert the question (query) into a vector
    qvec = embed_query(query)
    db = lancedb.connect(str(LANCE_DIR))
    table = db.open_table("notes")

    # 2. Search the database for the closest vectors
    results = table.search(qvec).limit(limit).to_list()

    # 3. Print the results
    for r in results:
        print(f"{r['id']}") # Print the ID of each found note

So the /ask command does more than just search files — it's a powerful feature that lets you converse with the knowledge network you've built.

Wrapping Up

In this chapter, you learned how to build an intelligent search system that can find scattered notes by meaning.

• Why does meaning-based search matter?: Even without knowing the exact keywords, you can find what you want with a natural question — like searching for "that thing kind of like this."
• How does it work?: Every note is converted into a vector (numerical coordinates) representing its meaning via an AI model (Gemini), and stored (indexed) in a specialized database (LanceDB). At search time, the question is also turned into a vector to find the notes at the nearest distance.
• How do you use it?: A single /ask <question> command gives you an answer grounded in the contents of your wiki right away.

Your Second Brain is no longer just a warehouse for storing information — it has become a conversational partner that offers wise advice whenever you need it. Everything is now in place to collect information, process it, and pull it out when you need it.

So what can we do with all of this? In the next chapter, we'll explore the synthesis stage — using these well-organized, searchable notes as raw material to generate entirely new writing or reports.

---

Next up: Chapter 4: Synthesis — Weaving Connected Notes into New Writing

---

Chapter 4: Synthesis — Weaving Connected Notes into New Writing

In the previous chapter, we learned how to use the /ask command to converse with our own knowledge base and pinpoint the notes we need based on meaning rather than keywords. Your Second Brain is now both a well-organized library and a smart librarian.

The whole point of going through every stage — collecting, distilling, and searching information — is ultimately to create something new. The final stage, where you weave scattered fragments of knowledge into your own articles, reports, and idea notes, is synthesis.

In this chapter, you'll learn how to assemble individual notes — those LEGO blocks — into an entirely new creation. Just as a documentary director weaves together countless video clips into a single story, you'll have the remarkable experience of watching your Second Brain gather fragments of knowledge and write you the draft of a complete piece.

The Problem: I Have the Ingredients, But the Cooking Is Daunting

Imagine you want to write a blog post about "the importance of Personal Knowledge Management (PKM)." Over time you've gathered and organized dozens of related notes — Zettelkasten, atomic notes, evergreen notes, and more. But now that you actually sit down to write, you have no idea where to start.

• The problem: You have plenty of related notes, but you have no sense of what order to arrange them in or what logic to thread them together with.
• The old way: Open a bunch of note files and spend hours copy-pasting content and trying to make the context fit. In the end the structure falls apart, or you give up before even starting.
• The Second Brain way: You command, "/brief the importance of personal knowledge management." The system finds all the related notes and, based on their content, writes you a logically structured draft in a matter of minutes.

The synthesis stage aims to eliminate this kind of blank-page daunting feeling (Blank Page Syndrome) and let you focus solely on the most enjoyable part of the creative process: refining and developing your ideas.

/brief: Your Personal Research Assistant

The /brief command is a powerful feature that researches your wiki on a topic you throw at it and synthesizes the results into a single briefing document. It's like a research assistant on call 24 hours a day.

Just give a simple command like this in the Claude Code chat window.

/brief The core principles and benefits of the Zettelkasten methodology

When you issue this command, Claude begins researching based on your notes and, after a moment, shows you a message saying it has created a Markdown file with a title like the following in the wiki/outputs/ folder.

"The file wiki/outputs/2024-10-29-zettelkasten-methodology-core-principles-and-benefits.md has been created."

Open this file and you'll see that it's not just a patchwork of related notes, but the draft of a single piece with a systematic structure like this:

• Summary (TL;DR): A summary compressing the entire content into a sentence or two.
• Key Points: A bulleted list capturing the article's main arguments.
• Details: The body that explains each key point in depth.
• Open Questions: Questions worth exploring further on this topic.
• Sources: The list of your notes referenced in writing this piece ([[zettelkasten]], [[atomic-notes]], and so on).

This draft isn't perfect, but as a starting point for setting up the skeleton of a piece and fleshing it out, it's hard to beat.

A Peek Under the Hood

What's going on behind a command as simple as /brief? It's a process that combines the search we learned in the previous chapter with AI's writing ability.

As you can see, /brief is a step further along: first it finds related notes (like /ask does), then it uses their content as raw material to produce a new output.

A Deeper Look at the Code: How Does Claude Perform /brief?

The reason Claude can carry out this complex task step by step is that clear behavioral instructions are defined in the .claude/commands/brief.md file. This file is the "task manual" for the /brief command.

# Part of the .claude/commands/brief.md file
---
description: Gather related notes on a topic and write a briefing document.
---

Topic: $ARGUMENTS

Your job is to write a briefing document on the given topic using only information from `wiki/notes/`.

Steps:

1. Run `python scripts/search.py "<topic keywords>"` to find related notes.
2. ...
3. Read all of the top ~10 notes.
4. ...
5. At `wiki/outputs/<date>-<slug>.md`, write a draft that includes sections like TL;DR, Key Points, Details, and Sources.
6. Under "Sources," list the note IDs you used as a bulleted list.
...

This manual instructs Claude to:

1. First, use scripts/search.py to find as many notes related to the topic as possible.
2. Read the contents of those notes carefully.
3. Based on that information, write a new Markdown file in the wiki/outputs/ folder, following the prescribed format.

Because the instructions are this clear, Claude can produce output of consistent quality every time.

wiki/outputs/: Your Creative Workshop

Each of this system's folders plays a different role.

Folder	Rule	Role
wiki/raw/	Append-only	Original archive, permanent storage
wiki/notes/	Freely editable	Living knowledge network, your core asset
wiki/outputs/	Deletable anytime	Output, a temporary workspace

The outputs/ folder is like your workshop. Once you've taken the draft Claude made for you, finished the piece, and published it to your blog, the files in this folder are no longer needed — so feel free to delete them anytime. Your core knowledge remains intact in the notes/ folder, so if you ever want to write another piece on the same topic later, you can issue the /brief command again whenever you like.

Wrapping Up

In this chapter, you learned about synthesis, the final stage of the Second Brain workflow.

• Why does synthesis matter?: Because it's the creative stage where you weave scattered fragments of knowledge into a tangible output (an article, a report, and so on). This is the ultimate goal of knowledge management.
• How do you synthesize?: With a single /brief <topic> command, you can marshal all the related notes in your wiki and automatically generate a draft with a systematic structure.
• The role of the wiki/outputs/ folder: It's a temporary workspace where the output generated by /brief is saved. The files here can be edited or deleted at any time.

You now have a powerful system that goes beyond merely collecting and organizing information — one that creates new value on the foundation of accumulated knowledge. The draft Claude generated is an excellent starting point, but it doesn't yet carry your distinctive voice or your deeper insight.

In the next chapter, we'll explore the collaborative writing process — refining and developing this draft by conversing with AI to complete a final piece.

---

Next up: Chapter 5: Collaborative Writing — Polishing Drafts with AI

---

Chapter 5: Collaborative Writing — Polishing Drafts with AI

In the previous chapter, we finished the synthesis stage — using the /brief command to weave scattered fragments of knowledge into a draft with a logical structure. Your wiki/outputs/ folder now holds an excellent starting point, generated from your knowledge base.

But an AI-generated draft is like a well-made report. The information is accurate, but it may still lack the charm that wins over a reader, or your own distinctive voice. Especially when you need to leave a short, sharp impression — like a blog post or a social media piece — how do you refine this draft into a compelling final product?

In this final chapter, you'll learn the crowning touch of this whole process: collaborative writing, where you treat AI not as a mere summarizer but as a creative partner and complete a piece together.

The Problem: You Can't Make a Bland Dish from Great Ingredients

Imagine you have a piece on "the Zettelkasten methodology" generated by /brief. The content is rich, but it's too long and too academic to share on social media. What if you wanted to turn it into a short piece that throws out a provocative question like "Does Zettelkasten really make you more productive?"

• The problem: It's hard to turn a long, information-rich article into a short, gripping piece carrying a particular angle or hook.
• The old way: You copy and paste bits of the long article here and there and try to trim the sentences down, but it usually just ends up as a flat summary of the original.
• The Second Brain way: In an editing studio called shortwrite.html, you use the long article as reference material and tell your AI editor, "Refine this with this provocative angle." While the AI handles the labor-intensive restructuring, you focus on coming up with more creative ideas.

This is like a documentary director handing hundreds of hours of raw footage to a professional editor and directing, "Make a 10-minute trailer focused on the protagonist's inner conflict." The director only sets the creative direction, and the editor takes over the grueling work of cutting and splicing countless clips to match that intent.

shortwrite.html: A Shared Editing Studio for You and AI

shortwrite.html is a special web page in the root folder of our project. This file is a shared editing studio built for a human writer (that's you) and an AI editor to complete a piece together.

This studio is split into two panes.

1. Left pane (📖 Source): Where the long reference article (e.g., a draft made with /brief) is displayed. Its content is read-only reference material that can't be edited.
2. Right pane (✍️ Draft): Where the short piece you'll actually write and refine lives. This is where you and the AI take turns editing the piece.

Open shortwrite.html in your web browser (opening it through a local server is recommended), and load the long reference article on the left and the file for your new short piece on the right.

!https://user-images.githubusercontent.com/1521976/282247547-38038b39-8671-4033-a309-86eb79346610.png

The heart of this studio lies in the frontmatter of the right-hand draft file.

---
title:
angle:        # The specific angle/hook this piece takes (e.g., a provocative question — "Do we really need knowledge management?")
hook_type:    # The SNS writing pattern (e.g., head-on rebuttal, confession + realization)
source: 2024-10-29-zettelkasten-brief.md # The filename of the source it references
format: short
status: draft
---

(The body of the piece goes here)

The most important field here is angle. This angle is the creative direction you — the human director — give to your AI editor.

Dancing with AI: The /shortwrite Workflow

Now let's go step by step through how you collaborate with AI in this studio.

1. Set up your workspace: In shortwrite.html, open the source article and the draft file.
2. Set the creative direction: In the draft file's angle field, clearly write the perspective or core message you want the piece to take. For example, "A provocative argument for why you should stop collecting data."
3. Direct the AI: Now return to the Claude Code chat window and issue a command like this:

   /shortwrite
   Refine this draft file to match its 'angle'.
   

4. The AI's editing work: Claude takes your instruction and reads both the draft file and the source file. It grasps the intent you spelled out in angle and, based on the source content, rewrites or refines the entire draft anew.
5. Review and give further direction: When Claude is done, return to the shortwrite.html browser window and press the "Open Draft / ⟳" button to load what the AI revised. Look at the result, and if there's something you don't like, refine the angle to be more specific or give further instructions in the chat — like "Make the tone a bit gentler" or "Add a strong call-to-action sentence at the end."

Repeat this process a few times, and a draft that was once a flat list of information is reborn as a sharp, persuasive piece that perfectly reflects your intent.

A Peek Under the Hood

The /shortwrite workflow is a turn-based collaboration in which AI and human pass a conversation back and forth across a single file.

The core of this process lies in .claude/skills/shortwrite/SKILL.md, the manual that tells Claude how to behave.

# Part of the .claude/skills/shortwrite/SKILL.md file
---
name: shortwrite
description: Use this when deriving a short piece with a specific angle from a long source article...
---

# Shortwrite — Long source → short piece with a specific angle

## The draft file's contract

Every short draft has frontmatter like the following. **The `angle` and `hook_type` fields are the most important**:

---

title: angle: # The specific angle/hook this piece takes hook_type: # confession + realization / numbers + twist / ... source: # The filename of the long source article ...

## Order of work

1.  ...
2.  When the user says "write / refine it with this angle":
   a. **Read the entire source article** — it's the standard for factual accuracy.
   b. **Read the draft** — paying special attention to `angle` and `hook_type`. The `angle` decides what to keep and what to discard. *One piece carries only one angle.*
   c. Pull only the content from the source that best brings out the `angle` and **write the short draft**.
...

This manual tells Claude clearly: "You are a professional editor. When the writer sets a direction with angle, you must produce a piece that best realizes that intent without straying from the source content."

Wrapping Up: Closing Out the Creative Journey

In this chapter, you learned about collaborative writing — refining an auto-generated draft together with AI to complete a final product.

• Why does collaborative writing matter?: With the human setting the creative direction and the AI handling the grueling editing work, you're freed from tedious typing to focus on higher-level creative activity.
• How do you collaborate?: In a shared editing studio called shortwrite.html, you give the AI creative direction through the draft file's angle field, review the result, and raise the quality of the piece together as if in conversation.

And with that, the entire journey of the Second Brain workflow comes to an end. We've experienced the whole process — starting from capturing information from the web, distilling and connecting it into atomic notes, searching it by meaning, synthesizing new writing, and finally collaborating with AI to refine it.

You now have a powerful, systematic setup that goes beyond merely consuming information — one that lets you make knowledge your own and create new value. This Second Brain will be a lifelong partner in your learning and growth. May you fully enjoy the pleasure of tending your own knowledge garden.

---

Adapted from an auto-generated walkthrough by AI Codebase Knowledge Builder.

이 프로젝트는 흩어진 정보와 생각을 관리하는 **개인 지식 창고(Second Brain)**입니다. 웹 기사나 메모를 명령어 하나로 간단히 수집하고, AI가 이 자료들을 의미 있는 원자적 노트로 자동 정리 및 연결해줍니다. 사용자는 자연어 질문으로 필요한 노트를 즉시 찾을 수 있으며, 여러 노트를 엮어 새로운 글의 초안을 생성하거나 AI와 함께 글을 다듬을 수도 있습니다.

Source Repository: https://github.com/slowww-ai/second-brain

Chapters

1. 수집: URL을 원재료(raw)로 저장하기
2. 증류 및 연결: 원재료를 원자적 노트로 가공하기
3. 벡터 색인 및 검색: 노트를 의미 기반으로 찾기
4. 종합: 연결된 노트들을 엮어 새로운 글 생성하기
5. 협업 글쓰기: AI와 함께 초안 다듬기

---

Chapter 1: 수집: URL을 원재료(raw)로 저장하기

Second Brain(제2의 뇌)을 만드는 여정에 오신 것을 환영합니다! 이 시스템의 첫 번째 단추이자 가장 중요한 습관은 바로 '수집'입니다.

혹시 나중에 읽으려고 열어 둔 브라우저 탭이 수십 개에 달하거나, "이건 꼭 봐야지" 하고 스크랩해 둔 링크가 어디에 저장했는지 기억나지 않는 경험이 있으신가요? 이런 '나중에 읽어야 한다'는 생각들은 우리 머릿속에 '열린 고리(open loop)'를 만들어 집중력을 흩트러뜨리는 주범입니다.

'수집' 단계는 이 문제를 해결하기 위한 아주 간단한 해결책입니다. 마치 웹 서핑을 하다가 흥미로운 정보를 발견했을 때 휘두르는 '디지털 잠자리채'와 같습니다. 나중에 정리하거나 이해하려는 고민 없이, 일단 잡아두는 것이죠.

이번 장에서는 이 시스템의 현관문 역할을 하는 수집 과정을 배우고, 단 하나의 명령어로 웹페이지를 내 지식 창고의 '원재료'로 저장하는 방법을 익혀보겠습니다.

핵심 목표: 1초 만에 정보 포획하기

수집 단계의 철학은 '마찰 최소화'입니다. 정보를 저장하기 위해 여러 단계를 거치거나, "어떤 폴더에 넣어야 하지?"라고 고민하는 순간, 우리는 저장을 미루게 됩니다. 이 시스템은 그런 고민을 없애줍니다.

• 문제: 웹에서 흥미로운 기사를 발견했지만 지금 당장 읽을 시간은 없다.
• 기존 방식: 브라우저 탭을 그대로 열어두거나, 북마크에 추가하고 잊어버린다.
• Second Brain 방식: URL을 복사해 명령어 하나만 입력한다. 정보는 즉시 안전하게 저장되고, 나는 하던 일에 다시 집중할 수 있다.

이 간단한 습관만으로도 '읽어야 한다는 압박감'에서 벗어나 훨씬 평온한 마음으로 지식을 쌓아갈 수 있습니다.

/jina-capture: 당신의 디지털 잠자리채

웹페이지를 수집하는 가장 간단한 방법은 Claude Code 채팅창에 /jina-capture 명령어를 사용하는 것입니다.

예를 들어, 제텔카스텐(Zettelkasten)에 대한 좋은 글을 발견했다고 가정해 봅시다.

/jina-capture https://en.wikipedia.org/wiki/Zettelkasten

이 명령어를 입력하면 어떤 일이 일어날까요?

1. Claude Code가 jina.ai라는 외부 서비스를 이용해 해당 URL의 웹페이지 내용을 가져옵니다.
2. 광고, 메뉴 등 불필요한 요소를 제거하고 본문만 남겨 깔끔한 마크다운(Markdown) 형식으로 변환합니다.
3. 변환된 내용을 wiki/raw/ 폴더 안에 오늘 날짜와 글 제목을 딴 파일 이름으로 저장합니다. 예를 들면 wiki/raw/2024-10-26-zettelkasten.md 와 같은 식이죠.

이제 브라우저 탭을 닫아도 괜찮습니다. 기사의 내용은 고스란히 내 컴퓨터의 wiki/raw/ 폴더에 원본 그대로 보존되었으니까요.

wiki/raw/ 폴더: 모든 것의 시작점

wiki/raw/ 폴더는 우리 '제2의 뇌'의 식료품 저장고와 같습니다. 시장에서 사 온 채소나 고기를 다듬지 않고 일단 냉장고에 넣어두는 것처럼, 웹에서 수집한 정보나 순간 떠오른 메모를 가공하지 않은 날것(raw) 그대로 던져 넣는 곳입니다.

이 폴더에 대해서는 딱 한 가지만 기억하면 됩니다.

'추가만 하고, 절대 수정하거나 삭제하지 마세요.'

이곳은 원본을 보존하는 아카이브입니다. 나중에 이 원재료를 어떻게 요리할지는 다음 장인 증류 및 연결: 원재료를 원자적 노트로 가공하기에서 배우게 됩니다. 지금은 그저 부지런히 재료를 모으는 데만 집중하면 됩니다.

직접 메모를 작성해서 넣을 수도 있습니다.

내부 동작 원리 엿보기

/jina-capture 명령어를 입력했을 때, 시스템 내부에서는 어떤 일이 일어나는지 간단한 순서도로 살펴봅시다.

이 모든 과정은 명령어 한 줄로 자동 처리됩니다. 사용자는 복잡한 과정을 알 필요 없이 그저 '디지털 잠자리채'를 휘두르기만 하면 되는 것이죠.

이 명령어의 구체적인 행동 방식은 우리 프로젝트의 .claude/skills/jina-capture/SKILL.md 파일에 정의되어 있습니다. 이 파일은 Claude Code에게 /jina-capture 라는 명령을 들었을 때 어떻게 행동해야 하는지 알려주는 일종의 '설명서'입니다.

# .claude/skills/jina-capture/SKILL.md 파일의 일부
---
name: jina-capture
description: 웹 페이지를 깔끔한 마크다운으로 가져와 wiki/raw/에 새 캡처로 직접 저장합니다.
---
# Jina Capture

어떤 URL이든 Jina Reader 서비스(`https://r.jina.ai/<url>`)를 사용해
`wiki/raw/`에 타임스탬프가 찍힌 마크다운 파일로 변환합니다.

## 단계

1. **대상 폴더 확인.** 기본값은 `wiki/raw/` 입니다.
2. **마크다운 가져오기.** `https://r.jina.ai/<url>` 주소를 호출합니다.
3. **제목과 슬러그(slug) 추출.** Jina의 결과물에서 제목을 파싱합니다.
4. **파일 작성.** `wiki/raw/<YYYY-MM-DD>-<slug>.md` 경로에 머리말(frontmatter)과 함께 저장합니다.
...

이처럼 Second Brain 워크플로우의 많은 자동화 기능들은 특정 작업을 수행하도록 미리 정의된 '스킬(skill)'들에 의해 이루어집니다.

정리하며

이번 장에서는 Second Brain 시스템의 가장 첫 단계인 '수집'에 대해 배웠습니다.

• 왜 수집이 중요한가?: '나중에 읽어야지' 하는 생각(열린 고리)을 머리에서 비워내어 현재 하는 일에 집중할 수 있게 해줍니다.
• 어떻게 수집하는가?: /jina-capture <URL> 명령어 하나로 어떤 웹페이지든 wiki/raw/ 폴더에 원본 그대로 저장할 수 있습니다.
• wiki/raw/ 폴더의 역할: 가공되지 않은 원재료를 보관하는 저장고입니다. '추가만 하고 수정/삭제는 하지 않는다'는 규칙을 지키는 것이 중요합니다.

이제 여러분은 웹을 탐험하다 마주치는 어떤 정보든 놓치지 않고 여러분만의 지식 창고에 안전하게 보관할 수 있는 강력한 도구를 갖게 되었습니다.

하지만 재료를 모으기만 해서는 요리가 완성되지 않겠죠. 다음 장에서는 이렇게 모인 원재료들을 어떻게 의미 있는 지식 조각으로 다듬고 서로 연결하는지 알아보겠습니다.

---

다음으로 이동: 제2장: 증류 및 연결: 원재료를 원자적 노트로 가공하기

---

Chapter 2: 증류 및 연결: 원재료를 원자적 노트로 가공하기

이전 장에서 우리는 디지털 잠자리채(/jina-capture)를 이용해 웹상의 흥미로운 정보들을 wiki/raw/ 폴더에 원재료 그대로 수집하는 법을 배웠습니다. 이제 여러분의 raw/ 폴더는 각종 기사와 메모가 쌓여 있는 식료품 저장고와 같을 겁니다.

하지만 재료가 많다고 저절로 요리가 되진 않죠. 긴 기사나 두서없는 메모 뭉치는 그 자체로는 다시 보기도, 다른 아이디어와 연결하기도 어렵습니다. 지금부터 이 시스템의 심장부라 할 수 있는 '증류'와 '연결' 과정을 통해, 이 원재료들을 의미 있는 지식 조각으로 가공하는 법을 배워보겠습니다.

문제: 정보는 모았지만, 쓸 수가 없다

raw/ 폴더에 저장된 '제텔카스텐 위키피디아 페이지'를 생각해 봅시다. 내용은 좋지만, 분량이 꽤 깁니다. 나중에 '원자적 노트'라는 개념만 따로 찾아보고 싶을 때, 이 긴 글 전체를 다시 읽어야 할까요? 다른 글에서 '상호참조'의 중요성에 대해 쓰다가 제텔카스텐의 관련 내용을 인용하고 싶을 땐 어떻게 해야 할까요?

이것이 바로 '증류' 단계가 해결하려는 문제입니다. 긴 글이라는 원석에서 핵심 개념이라는 보석들만 추출해내는 과정이죠.

• 문제: 긴 글 안에 여러 개념이 섞여 있어 재활용하기 어렵다.
• 기존 방식: 필요할 때마다 긴 글 전체를 다시 읽고 필요한 부분을 찾는다.
• Second Brain 방식: 글을 한 번 읽어 여러 개의 작은 '원자적 노트'로 분해하고, 각 노트를 서로 연결해 둔다.

마치 커다란 레고 성을 조립 설명서 없이 받았을 때, 일단 가장 작은 블록 단위로 모두 분해해서 종류별로 정리해두는 것과 같습니다. 이렇게 해두면 나중에 자동차든 우주선이든 원하는 것을 훨씬 쉽게 만들 수 있죠.

/ingest: 당신의 지식 연금술사

이 복잡해 보이는 증류와 연결 과정을 단 한 번의 명령으로 처리해 주는 것이 바로 /ingest 명령어입니다. 'ingest'는 '섭취하다', '소화하다'라는 뜻으로, 말 그대로 Claude Code가 raw/ 폴더의 새로운 재료들을 소화해서 notes/ 폴더에 영양가 있는 지식으로 만들어주는 역할을 합니다.

Claude Code 채팅창에 간단히 입력해 보세요.

/ingest

이 명령을 내리면 Claude는 다음과 같은 연금술을 시작합니다.

1. wiki/raw/ 폴더를 살펴보고, 아직 처리되지 않은 새로운 파일이 있는지 확인합니다.
2. 새로운 파일을 발견하면, 그 내용을 읽고 핵심 개념들을 파악합니다.
3. 각 핵심 개념을 '원자적 노트(Atomic Note)'라는 작은 단위로 쪼갭니다. '원자적 노트'란, 더 이상 나눌 수 없는 단 하나의 아이디어나 개념만 담고 있는 노트를 의미합니다.
4. 쪼개진 노트들을 wiki/notes/ 폴더에 각각의 파일로 저장합니다.
5. 관련 있는 노트들끼리 [[위키링크]]를 사용해 서로 연결해 줍니다.
6. 처리가 끝난 raw/ 파일은 다시 처리되지 않도록 기록을 남깁니다.

예를 들어, raw/2024-10-26-zettelkasten.md 파일을 /ingest로 처리하면 notes/ 폴더에 다음과 같은 파일들이 생길 수 있습니다.

• notes/zettelkasten.md
• notes/atomic-notes.md
• notes/evergreen-notes.md

그리고 zettelkasten.md 파일 안에는 [[atomic-notes]]와 같은 링크가 포함되어, 노트 간의 지식 네트워크가 만들어지기 시작합니다.

내부 동작 원리 엿보기

/ingest 명령어를 입력했을 때, 시스템 내부에서는 어떤 일이 일어나는지 간단한 순서도로 살펴봅시다.

이 모든 과정은 Claude Code와 몇 가지 보조 스크립트의 협업으로 이루어집니다. 사용자는 그저 /ingest라는 마법 주문만 외우면 되는 것이죠.

코드 깊이 보기: 무엇이 /ingest를 움직이는가?

이 마법의 뒤에는 잘 짜인 '설명서'와 '도구'가 있습니다.

먼저, Claude Code가 /ingest 명령을 받았을 때 어떻게 행동해야 하는지 알려주는 설명서는 .claude/commands/ingest.md 파일에 정의되어 있습니다.

# .claude/commands/ingest.md 파일의 일부
---
description: Process new files in wiki/raw/ into distilled notes in wiki/notes/
---

Your job is to turn new raw captures into clean, linked wiki notes.

Steps:

1. Run `python scripts/ingest.py list-new` to find raw files not yet referenced...
...
3. For each new raw markdown file:
   a. Read it...
   b. Identify the 1–3 core concepts in the file.
   c. ...create a new note in `wiki/notes/<slug>.md` with proper frontmatter, and `[[wikilinks]]`...
...
6. **Record each processed raw file in the ledger.** After you finish... run:
   `python scripts/ingest.py record <raw-filename> <note1,note2,...>`
...

이 설명서에 따라 Claude는 scripts/ingest.py라는 파이썬 스크립트를 도구로 사용합니다. 이 스크립트는 두 가지 중요한 역할을 합니다.

1. 새로운 재료 찾아내기 (list-new)

raw/ 폴더에 파일이 수백 개 쌓여도, Claude는 이전에 처리했던 파일은 건너뛰고 새로 추가되거나 변경된 파일만 정확히 찾아냅니다.

# 터미널에서 직접 실행해 볼 수도 있습니다.
python scripts/ingest.py list-new

위 명령어를 실행하면, 다음과 같이 아직 처리되지 않은 파일 목록을 보여줍니다.

2024-10-26-zettelkasten.md  (new)
2024-10-27-some-other-article.md (new)

2. 처리 완료 도장 찍기 (record)

한번 요리한 재료를 또 요리하면 안 되겠죠? Claude가 파일 처리를 끝내면, record 명령을 통해 '이 파일은 처리 끝!'이라는 도장을 찍어둡니다. 이 기록은 wiki/index.db라는 작은 데이터베이스 파일에 저장됩니다.

# scripts/ingest.py 의 일부
def record(raw_name: str, produced: str) -> None:
    # ... (생략) ...
    con = connect() # 데이터베이스에 연결
    con.execute(
        # 'ingested' 테이블에 처리 기록을 추가하거나 갱신
        "INSERT OR REPLACE INTO ingested(...) VALUES (?, ?, ?, ?)",
        (raw_name, content_hash(path), ... , produced),
    )
    con.commit() # 변경사항 저장
    # ... (생략) ...

이처럼 /ingest는 단순한 명령이 아니라, 잘 정의된 규칙과 효율적인 도구가 결합된 자동화 워크플로우입니다.

wiki/notes/: 당신의 살아있는 지식 네트워크

/ingest를 통해 만들어진 노트들은 wiki/notes/ 폴더에 저장됩니다. 이 폴더는 raw/ 폴더와는 성격이 다릅니다.

폴더	규칙	역할
wiki/raw/	추가만 가능 (수정/삭제 금지)	원본을 보존하는 아카이브, 식료품 창고
wiki/notes/	자유롭게 수정/삭제 가능	살아있는 지식 위키, 잘 정리된 부엌

notes/ 폴더 안의 노트들은 여러분의 생각과 함께 계속해서 자라나는 '상록수 노트(Evergreen notes)'가 될 수 있습니다. Claude가 초안을 잡아주면, 여러분이 직접 노트를 열어 내용을 다듬고, 새로운 생각을 추가하고, 다른 노트와 연결하며 자신만의 지식 정원을 가꾸어 나갈 수 있습니다. 특히 Obsidian과 같은 마크다운 편집기를 사용하면 노트 간의 연결을 시각적으로 보거나 쉽게 이동할 수 있어 더욱 편리합니다.

정리하며

이번 장에서는 Second Brain 시스템의 핵심인 '증류와 연결' 과정을 배웠습니다.

• 왜 증류가 중요한가?: 긴 글과 메모를 재사용하기 쉬운 작은 지식 단위인 '원자적 노트'로 만들어, 아이디어를 쉽게 연결하고 확장할 수 있게 해줍니다.
• 어떻게 증류하는가?: /ingest 명령어 하나로 raw/ 폴더의 새로운 재료를 자동으로 분석하고, notes/ 폴더에 서로 연결된 원자적 노트 네트워크를 구축할 수 있습니다.
• raw/와 notes/의 차이: raw/는 원본 보존을 위해 수정하지 않는 '과거 기록'이고, notes/는 언제든 다듬고 키워나갈 수 있는 '현재의 지식'입니다.

이제 여러분은 흩어져 있던 정보 조각들을 의미 있는 지식 네트워크로 바꾸는 강력한 연금술을 손에 넣었습니다. 잘 정리된 노트들은 그 자체로도 훌륭하지만, 이 노트들을 필요할 때 즉시 찾아내 활용할 수 있을 때 비로소 진정한 '제2의 뇌'가 됩니다.

다음 장에서는 이렇게 구축한 지식 네트워크를 어떻게 '의미 기반으로' 똑똑하게 검색하는지 알아보겠습니다.

---

다음으로 이동: 제3장: 벡터 색인 및 검색: 노트를 의미 기반으로 찾기

---

Chapter 3: 벡터 색인 및 검색: 노트를 의미 기반으로 찾기

이전 장에서 우리는 /ingest 명령어를 통해 수집한 원재료들을 의미 있는 '원자적 노트'로 증류하고, [[위키링크]]를 통해 서로 연결하는 법을 배웠습니다. 이제 여러분의 wiki/notes/ 폴더는 서로 연결된 지식의 그물망, 즉 진정한 위키로 거듭나기 시작했습니다.

하지만 노트가 수십, 수백 개로 늘어나면 어떻게 될까요? 특정 정보가 필요할 때, 정확히 어떤 파일에 그 내용이 있었는지 기억하기란 쉽지 않습니다. 파일 탐색기에서 키워드로 검색(Ctrl+F)하는 것만으로는 부족할 때가 많습니다. 예를 들어, '뽀모도로 기법'에 대한 노트를 작성해두고 나중에 '집중력을 높이는 방법'을 찾는다고 상상해 보세요. 두 문구는 키워드가 다르지만 의미는 매우 가깝습니다. 기존 검색 방식으로는 이 둘을 연결하기 어렵죠.

이번 장에서는 우리 '제2의 뇌'에 똑똑한 기억력을 부여하는 '벡터 색인 및 검색' 기술을 배웁니다. 이를 통해 키워드가 아닌 '의미'를 기반으로 원하는 노트를 순식간에 찾아내는 마법 같은 경험을 하게 될 것입니다.

문제: 내 위키에 똑똑한 사서가 필요하다

여러분의 위키는 이제 방대한 장서를 갖춘 도서관과 같습니다. 하지만 책이 어디에 있는지 알려주는 사서가 없다면 무용지물이겠죠.

• 문제: "생산성을 높이는 습관에 대한 아이디어가 있었는데... 어떤 노트였지?"처럼, 정확한 키워드는 기억나지 않고 개념만 어렴풋이 떠오를 때 정보를 찾기 어렵다.
• 기존 방식: 파일 이름이나 본문 내용을 기억에 의존해 여러 키워드로 검색해본다. 실패하면 포기한다.
• Second Brain 방식: "/ask 생산성 습관"처럼 자연스러운 질문을 던진다. 시스템이 의미를 이해하고 관련성이 가장 높은 노트들을 찾아 답변해준다.

이것은 마치 책 제목만 아는 사서와, 모든 책의 내용을 이해하고 "이런 주제를 찾으신다면 이 책들과 저 책의 3장을 보시면 됩니다"라고 추천해주는 지혜로운 사서의 차이와 같습니다. 우리의 목표는 후자와 같은 지능형 검색 시스템을 구축하는 것입니다.

노트에 '의미 주소'를 부여하기

어떻게 컴퓨터가 글의 '의미'를 이해할 수 있을까요? 그 비밀은 **벡터 임베딩(Vector Embedding)**이라는 기술에 있습니다. 너무 어렵게 생각할 필요 없습니다. 간단한 비유로 이해해 봅시다.

모든 노트의 의미를 하나의 점으로 표현할 수 있는 거대한 '의미 공간'이라는 지도가 있다고 상상해 보세요.

• '사과'와 '오렌지'는 둘 다 '과일'이라는 공통점이 있으므로 지도에서 서로 가까운 곳에 위치합니다.
• 반면 '사과'와 '자동차'는 의미가 전혀 다르므로 지도에서 아주 멀리 떨어져 있습니다.

벡터 임베딩은 바로 이 작업을 해줍니다. Gemini와 같은 강력한 AI 모델이 우리 노트의 내용을 읽고, 그 의미를 나타내는 수백 개의 숫자 조합(벡터)으로 변환합니다. 이 숫자 조합이 바로 '의미 공간' 지도 위의 고유한 주소(좌표)가 되는 것입니다.

이 과정은 두 단계로 나뉩니다.

1. 색인 (Indexing): 우리 위키의 모든 노트에 '의미 주소'를 부여하고 지도에 등록하는 과정입니다.
2. 검색 (Searching): 우리의 질문 또한 '의미 주소'로 변환한 뒤, 지도에서 가장 가까운 주소를 가진 노트들을 찾는 과정입니다.

1단계: 색인 - 지식 지도 만들기 (reindex.py)

reindex.py 스크립트는 우리 위키의 모든 노트를 읽어 '의미 지도'를 만드는 역할을 합니다. 다행히 이 과정은 대부분 자동으로 처리됩니다. 이전 장에서 배운 /ingest 명령어를 실행하면, 새로운 노트를 만든 후 마지막 단계에서 이 색인 과정이 자동으로 실행되기 때문입니다.

reindex.py 스크립트는 다음과 같은 일을 합니다.

1. wiki/notes/ 폴더에 있는 모든 노트를 확인합니다.
2. 이전에 색인한 후 내용이 변경되었거나 새로 추가된 노트만 골라냅니다.
3. 해당 노트의 본문을 Gemini 모델에게 보냅니다.
4. Gemini 모델로부터 노트의 의미를 나타내는 벡터(숫자 목록)를 돌려받습니다.
5. 이 벡터를 노트의 ID와 함께 wiki/lancedb/라는 특별한 데이터베이스에 저장합니다.

아래는 reindex.py 코드의 일부로, 노트 본문을 받아 벡터로 변환하는 핵심적인 부분입니다.

# scripts/reindex.py 의 일부

def embed(client, text: str) -> list[float]:
    # Gemini 모델에게 텍스트의 임베딩을 요청합니다.
    resp = client.models.embed_content(model=MODEL, contents=text)
    # 반환된 벡터 값을 돌려줍니다.
    return resp.embeddings[0].values

# ... (루프 안에서) ...
for p in NOTES.glob("*.md"):
    # ... (생략) ...
    # 노트 본문을 벡터로 변환
    vec = embed(client, body[:8000])
    # ... (데이터베이스에 저장) ...

이 코드는 각 노트의 텍스트(body)를 embed 함수에 전달하여 숫자 목록(vec)을 얻는 과정을 보여줍니다. 이로써 우리의 모든 지식 조각은 검색 가능한 '의미 주소'를 갖게 됩니다.

2단계: 검색 - 필요한 지식 즉시 소환하기 (/ask)

이제 잘 만들어진 지도가 있으니, 길을 찾을 차례입니다. /ask 명령어는 우리의 지능형 검색창 역할을 합니다.

Claude Code 채팅창에 여러분의 위키와 관련된 질문을 해보세요.

/ask 제텔카스텐의 핵심 원칙은 무엇인가요?

이 명령을 내리면, 다음과 같은 일이 순식간에 일어납니다.

1. Claude가 scripts/search.py 스크립트를 이용해 여러분의 질문("제텔카스텐의 핵심 원칙은 무엇인가요?")을 처리합니다.
2. search.py는 질문 문장 또한 Gemini 모델을 통해 '질문 벡터'로 변환합니다.
3. 그리고 wiki/lancedb/ 데이터베이스에 쿼리를 날립니다: "이 질문 벡터와 의미적으로 가장 가까운 노트 벡터 5개를 찾아줘!"
4. 데이터베이스는 zettelkasten.md, atomic-notes.md 등 가장 관련성 높은 노트 목록을 반환합니다.
5. Claude는 이 노트들의 내용을 읽고, 그 정보를 바탕으로 질문에 대한 답변을 생성합니다.
6. 마지막으로, 어떤 노트를 참고했는지 [[zettelkasten]]처럼 출처를 밝히며 채팅창에 답변을 보여줍니다.

이 모든 과정의 흐름을 순서도로 살펴봅시다.

아래는 search.py가 어떻게 질문을 벡터로 바꾸고 데이터베이스를 검색하는지 보여주는 코드의 일부입니다.

# scripts/search.py 의 일부

def semantic(query: str, limit: int = 10) -> None:
    # 1. 질문(query)을 벡터로 변환
    qvec = embed_query(query)
    db = lancedb.connect(str(LANCE_DIR))
    table = db.open_table("notes")

    # 2. 데이터베이스에서 가장 가까운 벡터를 검색
    results = table.search(qvec).limit(limit).to_list()

    # 3. 결과 출력
    for r in results:
        print(f"{r['id']}") # 찾은 노트의 ID 출력

이처럼 /ask 명령어는 단순히 파일을 검색하는 것을 넘어, 여러분이 구축한 지식 네트워크와 '대화'할 수 있게 해주는 강력한 기능입니다.

정리하며

이번 장에서는 흩어져 있는 노트들을 의미 기반으로 찾아낼 수 있는 지능형 검색 시스템을 구축하는 방법을 배웠습니다.

• 왜 의미 기반 검색이 중요한가?: 정확한 키워드를 몰라도 "그 비슷한 얘기"를 찾는 것처럼 자연스러운 질문으로 원하는 정보를 찾을 수 있습니다.
• 어떻게 동작하는가?: 모든 노트를 AI 모델(Gemini)을 통해 '의미'를 나타내는 벡터(숫자 좌표)로 변환하고, 이를 특수 데이터베이스(LanceDB)에 저장(색인)합니다. 검색 시에는 질문 또한 벡터로 바꿔 가장 가까운 거리에 있는 노트를 찾습니다.
• 어떻게 사용하는가?: /ask <질문> 명령어 하나로 내 위키의 내용을 기반으로 한 답변을 바로 얻을 수 있습니다.

이제 여러분의 '제2의 뇌'는 단순히 정보를 저장하는 창고가 아니라, 필요할 때마다 지혜로운 조언을 건네주는 대화형 파트너가 되었습니다. 정보를 수집하고, 가공하고, 필요할 때 꺼내 쓰는 모든 준비가 끝났습니다.

그렇다면 이 모든 것을 활용해 우리는 무엇을 할 수 있을까요? 다음 장에서는 이렇게 잘 정리되고 검색 가능한 노트들을 재료 삼아 완전히 새로운 글이나 보고서를 생성하는 '종합' 단계에 대해 알아보겠습니다.

---

다음으로 이동: 제4장: 종합: 연결된 노트들을 엮어 새로운 글 생성하기

---

Chapter 4: 종합: 연결된 노트들을 엮어 새로운 글 생성하기

이전 장에서 우리는 /ask 명령어를 통해 우리만의 지식 베이스와 대화하고, 키워드가 아닌 '의미'를 기반으로 필요한 노트를 정확히 찾아내는 법을 배웠습니다. 이제 여러분의 '제2의 뇌'는 잘 정리된 도서관이자, 똑똑한 사서까지 갖춘 셈입니다.

정보를 수집하고, 증류하고, 검색하는 모든 단계를 거친 이유는 궁극적으로 '새로운 것을 창조'하기 위함입니다. 흩어져 있던 지식 조각들을 엮어 나만의 글, 보고서, 아이디어 노트를 만드는 마지막 단계, 바로 '종합'입니다.

이번 장에서는 낱개의 노트라는 레고 블록을 조립해 완전히 새로운 창작물을 만드는 방법을 배웁니다. 마치 다큐멘터리 감독이 수많은 영상 클립을 엮어 하나의 이야기를 만드는 것처럼, 우리의 '제2의 뇌'가 지식의 조각들을 모아 한 편의 글 초안을 써주는 놀라운 경험을 하게 될 것입니다.

문제: 재료는 있는데, 요리가 막막하다

블로그에 '개인 지식 관리(PKM)의 중요성'에 대한 글을 쓰고 싶다고 상상해 봅시다. 그동안 제텔카스텐, 원자적 노트, 에버그린 노트 등 관련 노트를 수십 개 모으고 정리해 두었습니다. 이제 막상 글을 쓰려고 하니 어디서부터 시작해야 할지 막막합니다.

• 문제: 관련 노트는 많지만, 이것들을 어떤 순서로 배열하고 어떤 논리로 엮어야 할지 감이 오지 않는다.
• 기존 방식: 여러 노트 파일을 열어두고, 내용을 복사-붙여넣기하며 문맥을 맞추느라 몇 시간을 보낸다. 결국 구조가 엉망이 되거나 시작도 못 하고 포기한다.
• Second Brain 방식: "/brief 개인 지식 관리의 중요성"이라고 명령한다. 시스템이 관련 노트를 전부 찾아 그 내용을 바탕으로 논리적인 구조를 갖춘 초안을 몇 분 만에 작성해준다.

'종합' 단계는 이처럼 백지상태의 막막함(Blank Page Syndrome)을 없애고, 여러분이 창작 과정에서 가장 즐거운 부분, 즉 '아이디어를 다듬고 발전시키는 일'에만 집중할 수 있도록 돕는 것을 목표로 합니다.

/brief: 당신의 개인 연구 보조원

/brief 명령어는 여러분이 던진 주제에 대해 여러분의 위키를 '연구'하고, 그 결과를 한 편의 브리핑 문서로 '종합'해주는 강력한 기능입니다. 마치 24시간 대기하는 연구 보조원과 같습니다.

Claude Code 채팅창에 다음과 같이 간단히 명령해 보세요.

/brief 제텔카스텐(Zettelkasten) 방법론의 핵심 원칙과 장점

이 명령을 내리면, Claude는 여러분의 노트를 바탕으로 연구를 시작하고, 잠시 후 wiki/outputs/ 폴더에 다음과 같은 제목의 마크다운 파일을 생성했다는 메시지를 보여줍니다.

"wiki/outputs/2024-10-29-zettelkasten-methodology-core-principles-and-benefits.md 파일이 생성되었습니다."

이 파일을 열어보면, 단순히 관련 노트를 짜깁기한 것이 아니라, 다음과 같이 체계적인 구조를 갖춘 한 편의 글 초안이 작성되어 있는 것을 볼 수 있습니다.

• 요약 (TL;DR): 전체 내용을 한두 문장으로 압축한 요약.
• 핵심 포인트: 글의 주요 주장을 담은 글머리 기호 목록.
• 세부 내용: 각 핵심 포인트를 상세히 설명하는 본문.
• 남은 질문들: 이 주제에 대해 더 탐구해볼 만한 질문들.
• 출처: 이 글을 작성하는 데 참고한 여러분의 노트 목록 ([[zettelkasten]], [[atomic-notes]] 등).

이 초안은 완벽하지는 않지만, 글의 뼈대를 잡고 살을 붙여나가기에는 더할 나위 없이 훌륭한 출발점입니다.

내부 동작 원리 엿보기

/brief라는 간단한 명령어 뒤에서는 어떤 일이 벌어지고 있을까요? 이는 이전 장에서 배운 '검색'과 AI의 '글쓰기 능력'이 결합된 과정입니다.

보시다시피, /brief는 먼저 /ask처럼 관련 노트를 찾은 다음, 그 내용을 재료로 삼아 새로운 결과물(output)을 만들어내는, 한 단계 더 나아간 작업입니다.

코드 깊이 보기: Claude는 어떻게 /brief를 수행할까?

Claude가 이 복잡한 작업을 순서대로 수행할 수 있는 이유는 .claude/commands/brief.md 파일에 행동 지침이 명확하게 정의되어 있기 때문입니다. 이 파일은 /brief 명령을 위한 '작업 설명서'입니다.

# .claude/commands/brief.md 파일의 일부
---
description: 주제에 대한 관련 노트를 모아 브리핑 문서를 작성합니다.
---

주제: $ARGUMENTS

당신의 임무는 `wiki/notes/`의 정보만을 사용해 주어진 주제에 대한 브리핑 문서를 작성하는 것입니다.

단계:

1. `python scripts/search.py "<주제 키워드>"`를 실행하여 관련 노트를 찾습니다.
2. ...
3. 상위 10개 정도의 노트를 모두 읽습니다.
4. ...
5. `wiki/outputs/<날짜>-<슬러그>.md` 경로에 TL;DR, 핵심 포인트, 세부 내용, 출처 등의 섹션을 포함한 초안을 작성합니다.
6. "출처"에는 사용한 노트 ID를 글머리 기호 목록으로 나열합니다.
...

이 설명서는 Claude에게 다음을 지시합니다.

1. 먼저 scripts/search.py를 사용해 주제와 관련된 노트를 최대한 찾아내라.
2. 그 노트들의 내용을 꼼꼼히 읽어라.
3. 그 정보를 바탕으로, 정해진 형식에 맞춰 wiki/outputs/ 폴더에 새로운 마크다운 파일을 작성하라.

이처럼 명확한 지침이 있기에 Claude는 매번 일관된 품질의 결과물을 만들어낼 수 있습니다.

wiki/outputs/: 당신의 창작물 작업실

이 시스템의 폴더들은 각기 다른 역할을 가집니다.

폴더	규칙	역할
wiki/raw/	추가만 가능	원본 아카이브, 영구 보관소
wiki/notes/	자유롭게 수정	살아있는 지식 네트워크, 핵심 자산
wiki/outputs/	언제든 삭제 가능	결과물, 임시 작업 공간

outputs/ 폴더는 여러분의 '작업실'과 같습니다. Claude가 만들어준 초안을 바탕으로 글을 완성한 뒤 블로그에 발행했다면, 이 폴더의 파일은 더 이상 필요 없으니 언제든 지워도 괜찮습니다. 핵심 지식은 notes/ 폴더에 그대로 남아있으므로, 나중에 같은 주제로 또 다른 글을 쓰고 싶다면 언제든 다시 /brief 명령을 내리면 됩니다.

정리하며

이번 장에서는 '제2의 뇌' 워크플로우의 최종 단계인 '종합'에 대해 배웠습니다.

• 왜 종합이 중요한가?: 흩어져 있는 지식 조각들을 엮어 실질적인 결과물(글, 보고서 등)을 만들어내는 창작의 단계이기 때문입니다. 이는 지식 관리의 궁극적인 목표입니다.
• 어떻게 종합하는가?: /brief <주제> 명령어 하나로, 내 위키의 관련 노트를 총동원하여 체계적인 구조를 갖춘 초안을 자동으로 생성할 수 있습니다.
• wiki/outputs/ 폴더의 역할: /brief를 통해 생성된 결과물이 저장되는 임시 작업 공간입니다. 이곳의 파일들은 언제든 수정하거나 삭제해도 괜찮습니다.

이제 여러분은 단순히 정보를 모으고 정리하는 것을 넘어, 축적된 지식을 바탕으로 새로운 가치를 창출하는 강력한 시스템을 갖추게 되었습니다. Claude가 생성해준 초안은 훌륭한 시작점이지만, 아직은 여러분의 독특한 목소리와 깊이 있는 통찰이 더해지지 않은 상태입니다.

다음 장에서는 이렇게 만들어진 초안을 AI와 함께 '대화'하며 다듬고 발전시켜 최종 결과물로 완성해나가는 '협업 글쓰기' 과정에 대해 알아보겠습니다.

---

다음으로 이동: 제5장: 협업 글쓰기: AI와 함께 초안 다듬기

---

Chapter 5: 협업 글쓰기: AI와 함께 초안 다듬기

이전 장에서 우리는 /brief 명령어를 통해 흩어져 있던 지식 조각들을 엮어 논리적인 구조를 갖춘 글의 초안을 만드는 '종합' 단계를 마쳤습니다. 이제 여러분의 wiki/outputs/ 폴더에는 여러분의 지식 베이스를 바탕으로 생성된 훌륭한 출발점이 준비되어 있습니다.

하지만 AI가 생성한 초안은 마치 잘 만들어진 보고서와 같습니다. 정보는 정확하지만, 아직 독자의 마음을 사로잡는 매력이나 여러분만의 독특한 목소리는 부족할 수 있습니다. 특히 블로그 포스트나 소셜 미디어 글처럼 짧고 강렬한 인상을 남겨야 할 때, 이 초안을 어떻게 매력적인 최종 결과물로 다듬을 수 있을까요?

이번 마지막 장에서는 이 모든 과정의 화룡점정, 즉 AI를 단순한 정보 요약기가 아닌 창의적인 파트너로 삼아 글을 함께 완성하는 '협업 글쓰기' 과정을 배워보겠습니다.

문제: 훌륭한 재료로 평범한 요리를 만들 수는 없다

/brief로 생성된 '제텔카스텐 방법론'에 대한 글이 있다고 상상해 봅시다. 내용은 알차지만, 이 글을 소셜 미디어에 공유하기에는 너무 길고 학술적입니다. "제텔카스텐이 정말로 생산성을 높여줄까?"라는 도발적인 질문을 던지는 짧은 글로 바꾸고 싶다면 어떻게 해야 할까요?

• 문제: 정보가 풍부한 긴 글을, 특정 '관점'이나 '훅(hook)'을 담은 짧고 흡입력 있는 글로 바꾸기가 어렵다.
• 기존 방식: 긴 글의 내용을 이리저리 복사해 붙여넣으며 문장을 줄여보지만, 결국 원래 글의 밋밋한 요약본이 되기 십상이다.
• Second Brain 방식: shortwrite.html이라는 편집실에서, 긴 글을 참고 자료로 삼아 "이런 도발적인 관점으로 글을 다듬어줘"라고 AI 편집자에게 지시한다. AI가 손이 많이 가는 재구성 작업을 처리하는 동안, 나는 더 창의적인 아이디어를 구상하는 데 집중한다.

이는 마치 다큐멘터리 감독이 수백 시간의 촬영 원본을 전문 편집자에게 넘기며 "주인공의 내적 갈등에 초점을 맞춰 10분짜리 예고편을 만들어주세요"라고 디렉팅하는 것과 같습니다. 감독은 창의적인 방향만 제시하고, 편집자는 그 의도에 맞춰 수많은 영상 클립을 자르고 붙이는 힘든 작업을 대신해 줍니다.

shortwrite.html: 당신과 AI의 공동 편집실

shortwrite.html은 우리 프로젝트의 루트 폴더에 있는 특별한 웹페이지입니다. 이 파일은 인간 작가(바로 당신)와 AI 편집자가 함께 글을 완성하기 위해 만들어진 '공동 편집실'입니다.

이 편집실은 두 개의 창으로 나뉘어 있습니다.

1. 왼쪽 창 (📖 원본): 참고할 긴 글 (예: /brief로 만든 초안)이 표시되는 곳입니다. 이곳의 내용은 수정할 수 없는, 오직 읽기 전용 참고 자료입니다.
2. 오른쪽 창 (✍️ 초안): 우리가 실제로 작성하고 다듬을 짧은 글이 있는 곳입니다. 이곳에서 당신과 AI가 번갈아 가며 글을 수정하게 됩니다.

shortwrite.html을 웹 브라우저에서 열고 (로컬 서버를 통해 여는 것을 권장합니다), 왼쪽에는 참고할 긴 글을, 오른쪽에는 새로 만들 짧은 글의 파일을 열어보세요.

!https://user-images.githubusercontent.com/1521976/282247547-38038b39-8671-4033-a309-86eb79346610.png

이 편집실의 핵심은 오른쪽 초안 파일의 **프런트매터(frontmatter)**에 있습니다.

---
title:
angle:        # 이 글이 취하는 특정 관점/훅 (예: 도발적인 질문 - "정말 지식 관리가 필요한가?")
hook_type:    # SNS 글쓰기 패턴 (예: 정면반박, 고백+깨달음)
source: 2024-10-29-zettelkasten-brief.md # 참고한 원본 파일명
format: short
status: draft
---

(여기에 글의 본문이 들어갑니다)

여기서 가장 중요한 필드는 angle입니다. 바로 이 angle이 인간 감독인 당신이 AI 편집자에게 내리는 '창의적 지시'입니다.

AI와 함께 춤을: /shortwrite 워크플로우

이제 이 편집실에서 AI와 어떻게 협업하는지 단계별로 알아봅시다.

1. 작업 공간 준비: shortwrite.html에서 원본 글과 초안 파일을 엽니다.
2. 창의적 방향 제시: 초안 파일의 angle 필드에 당신이 원하는 글의 관점이나 핵심 메시지를 명확하게 적습니다. 예를 들어, "데이터 수집을 멈춰야 하는 이유에 대한 도발적 주장" 처럼요.
3. AI에게 작업 지시: 이제 Claude Code 채팅창으로 돌아와 다음과 같이 명령합니다.

   /shortwrite
   이 초안 파일을 'angle'에 맞춰 다듬어줘.
   

4. AI의 편집 작업: Claude는 당신의 지시를 받고, 초안 파일과 원본 파일을 모두 읽습니다. 그리고 당신이 angle에 명시한 의도를 파악하여, 원본의 내용을 바탕으로 초안 전체를 새롭게 재구성하거나 다듬습니다.
5. 결과 확인 및 추가 지시: Claude가 작업을 마치면, shortwrite.html 브라우저 창으로 돌아가 '초안 열기/⟳' 버튼을 눌러 AI가 수정한 내용을 불러옵니다. 결과를 보고 마음에 들지 않는 부분이 있다면, angle을 더 구체적으로 수정하거나 채팅으로 추가 지시를 내립니다. "조금 더 부드러운 논조로 바꿔줘" 또는 "마지막에 강력한 행동 촉구 문장을 넣어줘" 와 같이요.

이 과정을 몇 번 반복하면, 단순한 정보의 나열이었던 초안이 당신의 의도가 완벽하게 반영된, 날카롭고 설득력 있는 글로 재탄생하게 됩니다.

내부 동작 원리 엿보기

/shortwrite 워크플로우는 AI와 인간이 하나의 파일을 사이에 두고 대화를 주고받는 턴제(turn-based) 협업 방식입니다.

이 과정의 핵심은 Claude에게 어떻게 행동해야 하는지를 알려주는 설명서, .claude/skills/shortwrite/SKILL.md 파일에 있습니다.

# .claude/skills/shortwrite/SKILL.md 파일의 일부
---
name: shortwrite
description: 긴 원본 글에서 특정 관점을 가진 짧은 글을 파생시킬 때 사용합니다...
---

# Shortwrite — 긴 원본 → 특정 관점의 짧은 글

## 초안 파일의 약속

모든 짧은 초안은 다음과 같은 프런트매터를 가집니다. **`angle`과 `hook_type` 필드가 가장 중요합니다**:

---

title: angle: # 이 글이 취하는 특정 관점/훅 hook_type: # 고백+깨달음 / 숫자+반전 / ... source: # 긴 원본 글의 파일명 ...

## 작업 순서

1.  ...
2.  사용자가 "이 관점으로 써줘 / 다듬어줘" 라고 말하면:
   a. **원본 글 전체를 읽으세요** — 사실 관계의 기준이 됩니다.
   b. **초안을 읽으세요** — 특히 `angle`과 `hook_type`을 주의 깊게 보세요. `angle`이 무엇을 남기고 무엇을 버릴지 결정합니다. *하나의 글에는 하나의 관점만 담습니다.*
   c. `angle`을 가장 잘 살리는 내용만 원본에서 뽑아내 **짧은 초안을 작성하세요**.
...

이 설명서는 Claude에게 "당신은 전문 편집자입니다. 작가가 angle로 방향을 제시하면, 당신은 원본 내용을 벗어나지 않는 선에서 그 의도를 가장 잘 구현하는 글을 만들어내야 합니다." 라고 명확히 알려줍니다.

정리하며: 창작의 여정을 마치며

이번 장에서는 자동 생성된 초안을 AI와 함께 다듬어 최종 결과물로 완성하는 '협업 글쓰기'에 대해 배웠습니다.

• 왜 협업 글쓰기가 중요한가?: 창의적인 방향 제시는 인간이, 고된 편집 작업은 AI가 맡음으로써, 인간은 지루한 타이핑에서 벗어나 더 높은 수준의 창작 활동에 집중할 수 있습니다.
• 어떻게 협업하는가?: shortwrite.html이라는 공동 편집실에서, 초안 파일의 angle 필드를 통해 AI에게 창의적인 지시를 내리고, 결과물을 확인하며 대화하듯 글의 완성도를 함께 높여갑니다.

이것으로 'Second Brain 워크플로우'의 모든 여정이 끝났습니다. 우리는 웹상의 정보를 수집하는 것에서 시작하여, 그것을 원자적 노트로 증류 및 연결하고, 의미 기반으로 검색하여, 새로운 글을 종합한 뒤, 마지막으로 AI와 협업하여 다듬는 전 과정을 경험했습니다.

이제 여러분은 단순히 정보를 소비하는 것을 넘어, 지식을 자신만의 것으로 만들고 새로운 가치를 창출하는 강력하고 체계적인 시스템을 갖추게 되었습니다. 이 '제2의 뇌'는 여러분의 학습과 성장을 돕는 평생의 파트너가 되어줄 것입니다. 여러분만의 지식 정원을 가꾸는 즐거움을 마음껏 누리시길 바랍니다

---

이 글은 AI Codebase Knowledge Builder로 생성한 코드베이스 분석을 블로그용으로 다듬은 글입니다.