Blog Feedback Workflow — Optimization Discussion

Prepared by Asia Shcherbakova, 2026-03-25. For review by Patrick and his Claude Code with the goal of proposing workflow improvements.

---

Purpose

This document is a request for Patrick and his Claude to propose a better workflow for Asia’s blog feedback role.

The Winter 2026 study group blog post was the first real test of the current approach. It worked — the critical factual error (Point 8) was caught and corrected, and several improvements made it into the post — but there was friction worth addressing before the next post.

Since Patrick is the one who initiates workflow improvements in the Baseworks system, and Asia’s role is more about fact-checking and ensuring content connects accurately to what we know and what happened, it makes more sense for Patrick’s side to propose the solution.

---

What Happened This Session

Patrick instructed Asia to use /write-blog-post to structure her feedback session. Asia used the skill, described the workflow problem to her Claude, and followed Claude’s recommendation to produce a structured feedback document (_feedback-winter-study-group-asia.md). That document contained:

• The current text (quoted)
• Asia’s issue, summarized
• A proposed revision drafted in Patrick’s voice by Claude

Patrick reviewed the document and applied many of the changes. He noted, however, that several of the proposed revisions went against voice guidelines — specifically, they contained negative framing (“rather than X,” “instead of Y”) where the guidelines call for describing what something is, not what it is not.

The proposed revisions were drafted by Claude based on Asia’s directional notes. None of the wording in the proposals was Asia’s. The issue is that Claude, working from Asia’s plain-language feedback, produced suggestions that were directionally correct but not fully voice-compliant — and Patrick had to do the corrective work himself.

---

The Core Friction

Asia’s feedback is observational and factual, not editorial. When she writes “this framing doesn’t explain why,” she’s identifying a gap — not proposing a sentence. The translation from gap identification to voice-compliant proposed text is currently being done by Asia’s Claude, which doesn’t have the same depth of editorial context that Patrick’s Claude has built up over many sessions.

Asia’s original preference was to route her feedback directly to Patrick’s Claude — skipping the Asia-side drafting layer entirely. Patrick’s decision was that the /write-blog-post layer on Asia’s side should be sufficient. That may be right, but the current implementation means Patrick still ends up doing voice correction on proposals that should have been right before they reached him.

---

Asia’s Question for Patrick

What is the best mechanism for Asia’s raw feedback to be:

1. Received as-is (observational, factual, plain language)
2. Filtered or translated through voice guidelines
3. Presented to Patrick as proposals he can approve or skip — without requiring voice correction on his end

The ideal outcome is a workflow where Asia’s role stays what it is (content fact-checker, not editor), and the friction of voice-non-compliant proposals doesn’t land on Patrick’s desk.

---

Conversation Log

The session that produced this discussion, lightly edited for readability. Tool outputs and timing markers removed.

---

Asia 1

/write-blog-post For the post from Three Forms to 21, the Winter 2026 Study Groups, I’d like to provide a round of feedback for the post that gets shared with Patrick and that may influence this skill for future posts. I need to know what the best possible way to go through this feedback process would be for you. In the past, we had Google Docs where we had strikethrough and notes, and we just want to find a more productive workflow to be able to work on posts in the future. Whatever feedback I provide here may contextually carry over into the creation of new posts using this skill.

---

Claude 1

One open inbox item to note first: the Voice Guide updates from Patrick’s session (em dashes, contractions, capitalization) are pending your review in VOICE-GUIDE-GOVERNANCE.md.

---

Feedback Workflow for Blog Posts

Here’s how I’d recommend approaching this, given you’re replacing Google Docs:

For this session — just talk to me

The fastest path: tell me what you want changed, section by section, in plain language. You don’t need to paste the text back to me — I have the draft. You can say things like:

• “Cut the second sentence in ‘Who Was in the Room’”
• “The ice story feels too long — trim it”
• “I don’t like ‘tangibly physical’ — find a better phrase”
• “Move the PrimerPrint section earlier”

I apply the change, tell you what I did, and we move on. Git tracks every version, so nothing is lost.

For future posts — Obsidian comment blocks (optional)

If you want to annotate the draft before a Claude session, Obsidian supports %% comment text %% — these are invisible in Reading mode but visible in Edit mode. I can read and process them all at once. This is the closest analog to Google Docs inline comments.

---

Asia 2

Okay thank you. The difficulty of the process that we need to address here is that it is Patrick’s post. I cannot make direct changes into Patrick’s post (this is where I think the Google revision was actually very useful but Patrick doesn’t want to use that — so we have to come up with something that works for him.)

I’m pasting my feedback below, numbered as I was going through the text. Point 0 is a typo. Point 8 is a very critical issue that needs to be addressed. All the other points are just my recommendations and thoughts. If it was my blog post, I would have directly written something in. But because it’s Patrick’s post, I’m communicating my feedback to you as an interface.

Apart from the wheelchair paragraph (point 8) — which I think has to be reworked entirely — my feedback below is not really about major rewrites but about potential strategic one-sentence enhancements here and there. It’s crucial that any changes to be made should not be significant rewrites but just inserting a phrase here and there.

Perhaps you can look at my feedback and suggest a workflow. The way I see it, based on my understanding of how Patrick works with you, it would be you who suggests a rewrite and Patrick reviews it. But how to implement the workflow technically to make it easy for Patrick — I don’t know. Please advise. Also let’s discuss the workflow before you make any changes.

(Asia’s full numbered feedback points followed — see _feedback-winter-study-group-asia.md for the complete list.)

---

Claude 2

The Core Workflow Problem

Asia’s feedback → Patrick’s post → Patrick’s approval → applied changes.

The challenge: you can’t edit it directly, and Patrick doesn’t want Google Docs. What you need is a proposal layer — a structured document that shows Patrick exactly what the proposed change is for each point, so he can approve/reject/modify without having to interpret your feedback himself.

Recommended Workflow

1. I create a structured feedback document with: the current text (quoted), the issue (Asia’s note, summarized), and a specific proposed revision in Patrick’s voice (drafted by me, based on your direction).
2. A short inbox item for Patrick pointing him to that document.
3. Patrick reads the document in Obsidian, tells his Claude Code which items to apply.
4. The revision is committed. Asia sees the result in the vault.

Why this works better than Google Docs

• Patrick gets proposed text, not raw notes to interpret
• He approves at the item level — no ambiguity
• Git tracks the before/after — no separate revision history needed
• The feedback document stays in the vault permanently (audit trail)

---

Asia 3

Okay thank you very much for your response. I like your proposal. [Asia confirmed approach for Points 8 and 1–3, specified minimal changes only, and approved proceeding with the feedback document.]

Note: I originally wanted to give my feedback to Patrick’s Claude, so that we avoided the layer of my Claude. But Patrick’s decision was that the /write-blog-post layer on my side should be sufficient.

---

Claude 3

(Feedback document _feedback-winter-study-group-asia.md created and committed. Patrick’s inbox updated.)