writing-shape
把素材堆一段一段塑造成一篇文章
中文翻譯
--- name: writing-shape description: "寫作，exploit：把原始素材一段一段塑造成文章。" disable-model-invocation: true --- <what-to-do> 使用者已經（或即將）傳來一份原始素材的 markdown 檔。把它當成輸入的素材堆：從整齊的片段清單，到一大坨沒有結構的散文，到逐字稿都可以。格式不重要。在做任何其他事之前，先從頭到尾讀完它。 然後進行一場塑形 session，產出一份獨立的文章文件。這是 **exploit**：探索已經做完，素材堆已經固定：決定一個結構，並從素材堆裡挖東西來填它。不要編輯原始素材檔：對這個 skill 來說它是唯讀的。 如果使用者沒說文章要存到哪裡，就問一次並記住路徑。 </what-to-do> <supporting-info> ## 迴圈 1. **讀素材堆。** 完整讀完輸入檔。對裡面有什麼形成大致的感覺。 2. **確立先備知識。** 跟使用者確定讀者走進來時知道什麼：一開始就**已打好地基（grounded）** 的概念。其他所有東西都必須由某個區塊先打好地基，後面的區塊才能倚靠它。見[打地基](#grounding)。 3. **擬 2 到 3 個候選的開頭。** 每個開頭都應該暗示這篇文章不同的論點或角度。全部都給使用者看。逼使用者挑一個或組合成混合版。選定的開頭決定了文章其餘部分必須做什麼。 4. **一段一段地長出來。** 開頭落地之後，問「有了這個開頭，讀者接下來需要聽到什麼？」從素材堆取材來回答。下一個區塊只能倚靠已打好地基的概念，並在落地時打好新的地基。要爭論下一個區塊採取的形式：段落、清單、表格、callout、引用、程式碼區塊。每個格式的選擇都要是刻意的、站得住腳的。 5. **邊做邊附加到文章檔。** 不要批次處理。每一段或每個區塊一談定就立刻寫入，讓使用者看得到文章逐漸成形。 6. **重複第 4 步直到文章完成。** 什麼時候算完成由使用者決定。 ## 打地基 每個**概念**在某個區塊能倚靠它之前，都必須先**打好地基**：讀者要嘛走進來時就知道，要嘛在之前的區塊遇過它。一個去抓還沒打好地基的概念的區塊會讓讀者迷路。單位是概念，不是它的名稱：就算看不到任何行話，一個區塊也可能倚靠讀者缺少的想法。如果概念有名稱（一個**術語**），替它打地基就是把想法和術語一起落地。 一個概念有兩種方式被打好地基： - **先備知識（Prerequisite）**：在開頭之前就已打好地基。由讀者自己帶來。一開始就固定。 - **引入（Introduced）**：由某個區塊建立它，從此對文章的其餘部分來說它都已打好地基。 隨時保持一份已打好地基的清單。當你問「讀者接下來需要聽到什麼？」時，下一步需要的、還沒打好地基的概念本身就是答案：先替它打地基（在這裡或之前的區塊），否則你就走不了那一步。這是[從素材堆裡取材](#pulling-from-the-pile)的點出缺口，提升一個層級：那裡是素材堆缺少素材；這裡是文章缺少地基。 槓桿是：你讓什麼變成先備知識、又讓什麼在文章裡面打地基。前面要求太多，就會把讀者擋在門外；裡面打太多地基，開頭就會淹沒在定義裡。確立先備知識時，跟使用者一起決定這點。 ## 對話的感覺 這是顛倒過來的 grilling session。在發想階段，問題是「你實際上注意到了什麼？」這裡則是「這篇文章實際上在論證什麼，而讀者需要用什麼順序聽到它？」要反駁。不准讓薄弱的轉場混過去。如果一段沒有資格留下，就砍掉。 要持續使用的具體招式： - 「這一段為讀者做了什麼是上一段沒做的？」 - 「如果我把這個砍掉，什麼會壞？」 - 「這是散文，還是該做成清單？為什麼是散文？」 - 「這句話同時做兩件事：拆開，或選一件。」 - 「開頭承諾了 X。我們已經漂到 Y。要嘛重新接回去，要嘛改開頭。」 ## 從素材堆裡取材 把原始素材當成採石場，不是劇本。取一個片段，改寫成能配合周圍的段落，然後放上去。一個片段可以拆到好幾段、跟另一個合併，或被改寫。素材堆的工作是被挖掘；文章的工作是讀起來像同一個聲音。 如果素材堆缺少文章需要的東西，就明確點出缺口：「這裡需要一個範例，素材堆裡沒有。現在給我一個，不然我們就砍掉這一節。」 ## 真正該有的格式爭論 選擇怎麼呈現一個區塊時，要跟使用者大聲權衡這些取捨，不要默默決定： - **散文 vs. 清單。** 散文承載論證；清單承載並列的項目。如果項目不是真的並列，散文比較好。如果是，清單掃讀起來比較快。 - **行內 vs. callout。** 提示、警告和題外話放進 callout（`> [!TIP]`、`> [!NOTE]`），但只有在放在行內真的會打斷主要論證時才這樣。否則就留在行內。 - **表格 vs. 重複的結構。** 如果同樣的形狀重複 3 次以上、欄位也一樣，就用表格。否則用帶粗體開頭的散文。 - **引用 vs. 改寫。** 原文措辭本身就是重點時用引用。只有想法重要時用改寫。 - **程式碼區塊 vs. 行內 code。** 多行、可執行或用來說明 → 區塊。單一 token 或識別字 → 行內。 ## 寫作節奏 每個區塊一談定就附加到文章檔。每次寫入之前都從磁碟重新讀檔：使用者可能在兩輪之間編輯過。絕對不要盲目覆蓋。如果使用者想重寫某一段，就原地編輯那一段；其他的不要動。 ## 範圍外 - 去挖掘素材堆裡沒有的新片段（缺口照「從素材堆裡取材」處理）。 - 編輯原始素材檔。 - 發佈、為特定平台排版，或加上使用者沒要求的 frontmatter。 </supporting-info>
英文原文
--- name: writing-shape description: "Writing, exploit: shape raw material into an article, paragraph by paragraph." disable-model-invocation: true --- <what-to-do> The user has passed (or will pass) a markdown file of raw material. Treat it as the input pile: anything from a tidy list of fragments to a wall of unstructured prose to a transcript. The format does not matter. Read it end-to-end before doing anything else. Then run a shaping session that produces a separate article document. This is **exploit**: the exploring is done, the pile is fixed: commit to a structure and mine the pile to fill it. Do not edit the raw material file: it is read-only to this skill. If the user did not say where to save the article, ask once and remember the path. </what-to-do> <supporting-info> ## The loop 1. **Read the pile.** Read the input file in full. Form a sense of what's in it. 2. **Establish the prerequisites.** Settle with the user what the reader knows walking in: the concepts that are **grounded** from the start. Everything else must be grounded by a block before a later block can lean on it. See [Grounding](#grounding). 3. **Draft 2–3 candidate openings.** Each opening should imply a different thesis or angle for the article. Show all of them. Force the user to pick or compose a hybrid. The chosen opening defines what the rest of the article must do. 4. **Grow paragraph by paragraph.** After the opening lands, ask "given this opening, what does the reader need to hear next?" Pull material from the pile to answer. The next block may only lean on grounded concepts, and grounds new ones as it lands. Argue about the form the next block takes: a paragraph, a list, a table, a callout, a quote, a code block. Each format choice should be deliberate and defensible. 5. **Append to the article file as you go.** Don't batch. Write each agreed paragraph or block immediately so the user can see the article taking shape. 6. **Loop step 4 until the article is done.** The user decides when it's done. ## Grounding Every **concept** has to be **grounded** before a block can lean on it: the reader either walked in knowing it or met it in an earlier block. A block that reaches for an ungrounded concept loses the reader. The unit is the concept, not the word for it: a block can lean on an idea the reader lacks even with no jargon in sight. Where a concept has a name (a **term**), grounding it means landing the idea and the term together. A concept gets grounded one of two ways: - **Prerequisite**: grounded before the opening. The reader brings it. Fixed at the start. - **Introduced**: a block establishes it, and from then on it's grounded for the rest of the article. Keep a running list of what's grounded. When you ask "what does the reader need to hear next?", an ungrounded concept the next move needs is itself the answer: ground it first (here or in an earlier block) or you can't make the move. This is the gap-naming of [Pulling from the pile](#pulling-from-the-pile) one level up: there the pile is missing material; here the article is missing a foundation. The lever is what you make a prerequisite versus what you ground inside the article. Demand too much up front and you shut readers out; ground too much inside and the opening drowns in definitions. Settle it with the user when you establish prerequisites. ## Conversational feel This is a grilling session inverted. In ideation, the question was "what are you actually noticing?" Here it's "what is this article actually arguing, and in what order does the reader need to hear it?" Push back. Refuse to let weak transitions slide. If a paragraph doesn't earn its place, cut it. Specific moves to keep using: - "What does this paragraph do for the reader that the previous one didn't?" - "If I cut this, what breaks?" - "Is this prose, or should it be a list? Why prose?" - "This sentence is doing two jobs: split it or pick one." - "The opening promised X. We've drifted to Y. Either re-thread it or change the opening." ## Pulling from the pile Treat the raw material as a quarry, not a script. Pull a fragment, rework it to fit the surrounding paragraph, and place it. A fragment may be split across multiple paragraphs, merged with another, or paraphrased. The pile's job is to be mined; the article's job is to read as one voice. If the pile lacks something the article needs, name the gap explicitly: "We need an example here and the pile doesn't have one. Give me one now or we cut this section." ## Format arguments to actually have When choosing how to render a block, weigh these tradeoffs out loud with the user, not silently: - **Prose vs. list.** Prose carries argument; lists carry parallel items. If items aren't truly parallel, prose is better. If they are, a list is faster to scan. - **Inline vs. callout.** Tips, warnings, and asides go in callouts (`> [!TIP]`, `> [!NOTE]`), but only if they'd genuinely derail the main argument inline. Otherwise leave them inline. - **Table vs. repeated structure.** If the same shape repeats 3+ times with the same fields, a table. Otherwise prose with bold leads. - **Quote vs. paraphrase.** Quote when the original wording is the point. Paraphrase when only the idea matters. - **Code block vs. inline code.** Multi-line, runnable, or illustrative → block. Single token or identifier → inline. ## Writing rhythm Append to the article file as each block is agreed. Re-read the file from disk before every write: the user may have edited between turns. Never overwrite blindly. If the user wants a paragraph rewritten, edit that specific paragraph in place; leave the rest alone. ## Out of scope - Mining for new fragments that aren't in the pile (handle gaps as in "Pulling from the pile"). - Editing the raw material file. - Publishing, formatting for a specific platform, or adding frontmatter the user didn't ask for. </supporting-info>