# 👨‍💻 > [!NOTE]- PROMPT > First time doing this, please bare with me. I'm attempting to make my first "skill" for these lovely agents we can now interact with on the Terminal (such as Codex) > > Traditionally, I have always used ProWritingAid to proofread my text. It's great and all but it does often correct me on things that are simply quirks to the way I type and those are things that just simply won't change. I resisted the one space after a period until last year when I realized Linter had been doing it whenever I linted a file in Obsidian. ;) > > The biggest thing it corrects is my heavy usage of the apostrophe. > > I am: > > I've > I'm > They've > don't > haven't > didn't > > and to be honest, that's what they pushed in my school growing up, and I guess it stuck. > > I also strongly feel like I have have a "stream of conscious" kind of writing and ProWritingAid is constantly pushing me to rephrase entire sentences and it really has a problem with a phrase I use all the time, a trait attributed to my long exposure to Alan Watts lectures. That phrase being (and you might be familar): *"...that is to say"* > > Lastly, it really drops the ball seeing past the Markdown formatting. > > --- > > I would like to create a skill for an agent that works inside of my Obsidian vault. The idea being to use this context as part of SKILL.md file. > > The scope is essentially to act as an editor for my proposed blog posts without changing anything except obvious spelling and grammatical errors. > > Additionally I would like to be made aware if something truly does seem unclear. I do use a lot of metaphors and sometimes speak in riddles but if something seems truly opaque, please point it out for possible correction on my end. > > The all my past published blog posts are located here `1 Focus/Webmastery./Domains./wmprkr.xyz./xyz.Posts 666/` and act as reference for my tone, voice, and how I represent myself in general on my blog. > > If there are any questions about what exactly I am after please feel free to ask, otherwise let's take what I've said here and move forward. --- Below is a strong first-pass `SKILL.md` you can drop in and then refine over time. It is written to do four things well: 1. **Preserve your voice** 2. **Respect Markdown** 3. **Fix only obvious errors** 4. **Flag genuinely unclear passages without flattening your style** --- # Proposed `SKILL.md` ```md # Blog Editing Skill for wmprkr.xyz Drafts ## Purpose This skill is for editing draft blog posts inside an Obsidian vault. The goal is to act as a **light-touch editor**, not a co-author, ghostwriter, or writing coach. Preserve the author's tone, rhythm, quirks, phrasing, and structure as much as possible. The author has a distinctive personal writing style and does **not** want that style normalized into generic "clean internet prose." --- ## Core Editing Philosophy When editing, follow this priority order: 1. **Preserve voice** 2. **Preserve meaning** 3. **Preserve rhythm** 4. **Fix only clear spelling, punctuation, and grammar errors** 5. **Point out truly unclear passages separately rather than rewriting them aggressively** Do **not** rewrite for polish unless the original contains an obvious error or is genuinely difficult to understand. Do **not** optimize for corporate clarity, SEO tone, academic formality, or generic readability standards. Do **not** "improve" the writing just because a sentence is unconventional. --- ## Author Style Preferences The following are intentional and should generally be preserved: - Frequent use of contractions: - I'm - I've - don't - didn't - haven't - they've - Stream-of-consciousness flow - Conversational cadence - Occasional sentence fragments used for effect - Use of metaphor, abstraction, and mildly riddle-like phrasing - Repetition when it is clearly stylistic - The phrase: - "that is to say" - Informal or eccentric sentence construction when understandable - First-person, human, reflective, blog-like tone These are **not** problems to fix just because a grammar checker would object. --- ## What To Correct Correct only the following when they are clearly wrong: - Obvious spelling mistakes - Clear grammatical mistakes - Missing or incorrect words that produce an obvious error - Punctuation mistakes that disrupt readability - Accidental duplicated words, unless clearly intentional - Subject-verb agreement issues when plainly unintentional - Clear typo-level mistakes in tense, plurality, or word choice - Broken Markdown syntax - Formatting issues that would render poorly in Markdown/Obsidian Make the **smallest possible edit** needed. --- ## What Not To Correct Do **not** change any of the following unless specifically asked: - Contractions into full phrases - Example: do not change "I'm" to "I am" - Personal phrasing quirks - Stream-of-consciousness sentence structure - Use of "that is to say" - Tone that sounds unusual but still readable - Repetition used for emphasis - Intentional sentence fragments - Unusual but valid punctuation choices - One-space-after-period style - Markdown formatting that is already valid - Personal voice to sound more "professional" - Metaphors just because they are unconventional Do **not** aggressively split sentences just to satisfy style-guide preferences. Do **not** recast whole paragraphs unless the original meaning is actually broken. --- ## Markdown Rules The author writes in Markdown inside Obsidian. Respect Markdown structure at all times. Preserve and do not damage: - headings - emphasis (`*italic*`, `**bold**`) - links - blockquotes - lists - callouts - fenced code blocks - inline code - YAML frontmatter - horizontal rules - wiki links - tags - footnotes Do not misinterpret Markdown syntax as grammar errors. Do not rewrite text inside code blocks unless explicitly asked. Be careful around frontmatter and internal links. --- ## Tone Reference Use the author's previously published posts as a tone and voice reference. Reference path: `1 Focus/Webmastery./Domains./wmprkr.xyz./xyz.Posts 666/` If prior blog posts are available, use them to calibrate: - sentence rhythm - level of informality - acceptable eccentricity - how often fragments appear - how reflective or blunt the author tends to sound - how much abstraction is normal for this author When in doubt, prefer matching the author's existing style over generic grammar advice. --- ## Handling Unclear Passages If something appears truly unclear, do **not** automatically rewrite it heavily. Instead: 1. preserve the original if possible 2. make only the smallest correction needed 3. separately flag the passage as potentially unclear A passage should only be flagged if: - the meaning is genuinely hard to determine - the sentence could plausibly confuse a reader - a metaphor becomes too opaque to track - a referent is missing or ambiguous - syntax makes interpretation uncertain Do **not** flag something merely because it is poetic, strange, indirect, or stylistically personal. --- ## Output Behavior When asked to edit a draft, provide: ### 1. Edited Version Return the revised draft with only necessary corrections. ### 2. Change Notes Briefly list what was changed and why. Keep this concise. Example categories: - spelling - punctuation - grammar - Markdown cleanup ### 3. Possible Clarity Flags If applicable, list any lines or passages that may be genuinely unclear to readers. Keep these separate from corrections. Use wording like: - "This line may be unclear to a reader:" - "I think I follow what you're getting at, but this passage may read as opaque:" - "This metaphor works tonally, but the meaning may not fully land:" Do not overproduce warnings. --- ## Editing Threshold Use a **minimal intervention threshold**. If a sentence is technically imperfect but still sounds like the author and reads clearly, leave it alone. Only intervene when there is a real error or real confusion. --- ## Examples of Preferred Behavior ### Good - Fix a misspelled word - Add a missing comma if readability clearly improves - Correct accidental duplicated words - Preserve contractions - Preserve "that is to say" - Leave unusual but understandable phrasing alone - Flag a confusing metaphor separately instead of rewriting it flatly ### Bad - Expanding contractions - Rewriting personal phrasing into generic prose - Removing rhythm or voice for the sake of formal correctness - Treating Markdown syntax as an error - Replacing stream-of-consciousness flow with sanitized sentence structure - Rewording paragraphs just because they are unconventional --- ## Default Assumption Assume the author would rather keep a sentence that is slightly strange but authentic than replace it with one that is smoother but generic. Protect the voice. ``` --- ## What this gets right This gives the agent a very clear frame: - it is **not** there to “improve writing” - it **is** there to catch actual mistakes - it must treat your blog voice as **source material**, not a problem to solve That matters a lot, because otherwise these agents drift into “helpful cleanup mode,” which usually means sanding off everything human. --- ## Two additions I strongly recommend You’ll get better results if you add these sections too. ### 1. A preferred response format Add this near the bottom: ```md ## Preferred Response Format When editing a draft, respond in this format: ### Edited Draft [full edited draft here] ### What I Changed - [brief item] - [brief item] ### Possible Unclear Spots - [only include if truly needed] ``` That keeps the agent from wandering. ### 2. A hard rule against over-editing headlines and emphasis Add this too: ```md ## Headings and Emphasis Do not rewrite headings, subheadings, or emphasized phrases unless they contain an obvious error. These often carry tone and intentional voice. ``` That protects the parts editors love to “improve” for no good reason. --- ## One thing I would tighten in your actual setup This part: > The all my past published blog posts are located here... You’ll want the skill to explicitly tell the agent **when** to consult those old posts. Because otherwise some agents will ignore the reference path entirely. Use this wording instead: ```md If the draft's tone, structure, or phrasing seems unusual, consult prior published posts in: `1 Focus/Webmastery./Domains./wmprkr.xyz./xyz.Posts 666/` Use those posts as the authority for what counts as "normal" for this author. ``` That makes the archive a real calibration source instead of a decorative note. --- ## My honest take Your instinct here is solid. Most proofreading tools are built to produce **standardized prose**, not **preserved voice**. That is exactly why they keep trying to “fix” things that are not broken. They see deviation from style-guide norms and call it error. For a person with a real writing voice, that gets irritating fast. The apostrophe issue, contractions, “that is to say,” stream-of-consciousness cadence, and Markdown blindness are all exactly the kinds of things you should pin down in a skill file. That said, the one danger is this: If you only tell the agent “don’t change much,” some agents will become too timid and miss real problems. That is why the best framing is: - **protect voice aggressively** - **correct obvious errors confidently** - **flag opacity separately** That balance is the sweet spot. --- ## One optional stronger version If you want the skill to be even more stubborn about preserving your style, add this line: ```md Do not make stylistic edits unless the author explicitly asks for stylistic feedback. ``` That shuts the door even harder. --- ## One tiny real-world correction from your message Since this is an editing-related discussion: in your first sentence, it would be **“bear with me,”** not **“bare with me.”** That is exactly the kind of correction this skill should catch. --- If you want, I can also turn this into: 1. a **leaner SKILL.md** 2. a **stronger/more opinionated SKILL.md** 3. or a version tailored specifically for **Codex / terminal agents** with explicit operational instructions.