|
| 1 | +--- |
| 2 | +name: write-article |
| 3 | +description: >- |
| 4 | + Collaboratively writes a planned Jekyll blog article one section at a time, |
| 5 | + creating the post structure and pausing for the author's review and explicit |
| 6 | + approval after every section. Use when an article plan is ready to become a |
| 7 | + draft and the author wants to control the writing section by section. |
| 8 | +disable-model-invocation: true |
| 9 | +--- |
| 10 | + |
| 11 | +# Write Article |
| 12 | + |
| 13 | +Turn an approved article plan into a finished Jekyll post with the author. Follow `structure-spec.md` for the article itself. This skill defines only the collaborative writing process. |
| 14 | + |
| 15 | +## Prepare |
| 16 | + |
| 17 | +1. Read `structure-spec.md`. |
| 18 | +2. Read the approved article plan and the material it references. If the plan is not clear from the conversation or workspace, ask the author for it. |
| 19 | +3. Read the voice references required by the specification. |
| 20 | +4. Privately distil a writing brief from the plan: the reader, intended outcome, central idea, evidence boundaries, and useful voice cues. |
| 21 | +5. Propose one working title and briefly say what it foregrounds. Ask the author to approve or revise it before continuing. |
| 22 | + |
| 23 | +## Create the article |
| 24 | + |
| 25 | +After the working title is approved: |
| 26 | + |
| 27 | +1. Determine the date, slug, and context from the plan or ask only for what cannot be inferred. |
| 28 | +2. Create the post file and front matter as specified in `structure-spec.md`. |
| 29 | +3. Add an empty section structure based on the plan and the specification's flexible spine. |
| 30 | +4. Show the structure to the author and revise it until they approve it. |
| 31 | + |
| 32 | +Do not add draft prose while creating the structure. |
| 33 | + |
| 34 | +## Write one section at a time |
| 35 | + |
| 36 | +For each section: |
| 37 | + |
| 38 | +1. Privately define the section's job, key point, supporting material, and relationship to previously approved sections and the planned next section. |
| 39 | +2. If essential information is missing, ask one focused question instead of filling the gap with generic prose or invented detail. |
| 40 | +3. Write only that section in the post file, using the plan as source material and `structure-spec.md` as the writing standard. |
| 41 | +4. Do two editing passes before presenting it: first for substance and continuity, then for prose and voice, using the specification's criteria. |
| 42 | +5. Present the section and ask the author directly whether they approve it or want changes. |
| 43 | +6. Apply specific feedback to the current section. If the intent is unclear, ask rather than guessing. |
| 44 | +7. Re-read the revised section in context and ask again until the author explicitly approves it. |
| 45 | +8. Only then move to the next section. |
| 46 | + |
| 47 | +Do not draft a later section while waiting for approval. Do not rewrite an approved section unless the author asks, or first explain why a necessary correction affects it. |
| 48 | + |
| 49 | +Follow the drafting order recommended by `structure-spec.md`. The initial title is a working title: revisit it with the author when the specification calls for the final title. |
| 50 | + |
| 51 | +## Complete the article |
| 52 | + |
| 53 | +1. Once the text and final title are approved, propose an image concept following `structure-spec.md`. |
| 54 | +2. Create the image only after the author approves the concept, then ask them to review the result. |
| 55 | +3. Add the approved image and its real metadata to the post. |
| 56 | +4. Review the complete article for flow and correctness. Obtain approval before changing previously approved prose. |
| 57 | +5. Check the completed post against `structure-spec.md`. |
| 58 | +6. Report the post path and any unresolved issues. Use the publishing skill for preview and publication work when requested. |
0 commit comments