Comment Writer

Purpose

Write LinkedIn comments that give the recipient something: a sharper observation, a relevant data point, a better question, or a well-argued disagreement. Comments are where technical people actually build reputation, because a good comment is proof of thinking in under fifty words. This skill exists because the default alternative, "Great insights!", is reputation-neutral at best.

When to use this skill

• The user wants to comment on a specific post, article, or announcement
• The user wants to engage with peers without sounding spammy
• The user wants to disagree with a popular post without starting a fight
• The user says "write a comment on this", "how do I respond to this", "something better than 'great post'", or similar

Required inputs

1. The post to comment on (text, screenshot transcription, or link the agent can read)
2. Whatever the user actually knows or has experienced that relates to it. "Nothing" is a valid input; it changes which modes are available.

Optional inputs

• Preferred mode (see the five modes below)
• Relationship to the author (close peer, stranger, senior person, potential employer)
• Whether the user may mention their employer or projects
• Length appetite (one-liner to three sentences)

The five modes

1. Technical insight. Add a fact, mechanism, or edge case the post missed, grounded in the user's real knowledge. Structure: acknowledgement clause, the addition, optional source.
2. Supportive. Genuine encouragement tied to something specific in the post. "The part about X is underrated" beats "great post".
3. Respectful disagreement. Steelman the post, present the objection with its evidence or reasoning, offer the alternative or the question. Tone: a colleague across the desk, not a reply guy.
4. Question. Ask what the post made you actually wonder. Real questions only; the user should want the answer.
5. Peer feedback. For posts sharing work: one thing that works, one thing worth reconsidering, framed as experience-based suggestion.

Workflow

1. Read the post properly. Identify its actual claim, not its headline emotion. Note what evidence it offers and what it assumes.
2. Inventory the user. What does the user know, have done, or genuinely wonder that touches this post? If nothing, the available modes are question and (specific) supportive. Do not invent a relevant experience; see truth rules.
3. Choose a mode. Default to insight or question when available; disagreement only when the user actually disagrees.
4. Draft at 20 to 60 words, in the mode's structure.
5. Check against the quality bar below.
6. Deliver two or three options in different modes, labeled, with a one-line note on when each fits.

Truth and credibility rules

• Never fabricate credentials, projects, employers, or anecdotes. A comment like "we saw the same thing in production" requires a real production experience the user has stated.
• If the user has no relevant experience, do not imply one. Insight from reading ("I'd assumed X until your point about Y") is honest; manufactured war stories are not.
• Disagreement must rest on reasons the user can defend, or on sources the user has actually engaged with.
• The comment never discloses employer or client details the user has not cleared.

Writing rules

• Default voice per voice-guide.md, compressed: 20 to 60 words, one to three sentences, no headers, no lists.
• Open with substance, not with praise. If praise appears, it carries a specific reason.
• Banned as complete comments: "Great insights!", "Absolutely agree!", "This is so true!", "Well said!", "Powerful!", any fire emoji alone. These may appear only as a clause followed by the substance that earns them.
• No links dropped without a sentence explaining why they matter.
• No hijacking: the comment responds to the post, not to a topic it reminds you of.

Output format

[Option 1 - insight]
<comment>

[Option 2 - question]
<comment>

[Option 3 - disagreement]  (only if the user actually disagrees)
<comment>

[Notes]
One line per option on when it fits.

Two or three options by default; one if the user asked for exactly one.

Worked example

Input: the post claims "We split our monolith into 12 microservices and deployment got 3x faster. Microservices work." The user has migrated a monolith to three services at their current job (cleared to mention generically) and their speedup came mostly from CI and deploy automation done before the split.

Output (the three options):

[Option 1 - insight]
Congratulations on the shipping pace. Worth separating for anyone
planning the same move: our team's biggest speedup came from CI and
deploy automation, which we built before splitting. Attribution matters
when arguing for the split itself.

[Option 2 - question]
How did you attribute the 3x? I ask because when we split our monolith,
the deploy speedup arrived with the pipeline work, and I've never been
sure how much the split itself contributed.

[Option 3 - respectful disagreement]
The 3x number may be doing more work than it should. Twelve services
plus a 3x deploy gain usually means the pipeline improved too, and the
pipeline is the cheaper lesson for most teams reading this.

Notes: each option is under 60 words, uses only the user's real experience, and disagrees with the claim, not the person. The full walkthrough is in examples/technical-comment.md.

Edge cases

• The post is pure hype with no claim. The honest modes are question ("what did it actually do?") or silence. The skill may recommend not commenting; that is a valid deliverable.
• The author is the user's manager or a senior figure. Disagreement mode gets softened to question mode; the substance survives, the framing adapts. The skill does not coach deception, only register.
• The user wants to argue publicly. Draft the strongest respectful version. If the user pushes past it toward personal attack, decline that version and point at the code of conduct spirit: critique the claim.
• The post is job-seeking content from a friend. Supportive mode with a specific compliment plus, if true, an offer ("happy to refer you at my shop") only when the user confirms they mean it.
• Thread-style engagement farming ("comment 'INTERESTED' and I'll DM you"). The skill declines to draft these and says why once.

When NOT to use this skill

• The user wants a post, not a comment: use the appropriate creation skill.
• The user wants bulk-generated comments for many posts: this skill writes one comment per reading; mass engagement is out of scope and against the kit's philosophy.
• The user wants comments pretending expertise ("as a leading voice in...") they do not have: declined under truth rules.

Shared references

• ../../references/voice-guide.md — voice rules and banned patterns
• ../../references/credibility-rules.md — the fact triage system

These paths assume the full repository is present. This skill works standalone: the rules above are the core, the references add depth.