LinkedIn Reply Handler (linkedin-reply-handler)

The linkedin-reply-handler skill manages inbound comment traffic on your own LinkedIn posts. It crafts personalized, conversational replies that extend audience dwell time, foster professional relationships, and trigger the algorithm's multi-touch distribution multipliers while gracefully handling LinkedIn's structural 2-level thread flattening.

When an author replies to comments within the first 2 hours of publication, the LinkedIn feed algorithm registers the post as an active discussion hub, significantly expanding reach across 2nd- and 3rd-degree connection networks.

When to use this skill

Ideal Use Cases:

• Responding to inbound comments on your recent posts during the critical 1-to-4 hour post-launch window.
• Performing a systematic "Batch Sweep" across dozens of unread comments on high-velocity viral posts.
• De-escalating technical skepticism or respectful pushback with poise, empirical facts, and authority.
• Converting high-intent commenter questions into private direct message conversations or sales discovery calls.
• Untangling complex discussions occurring within flattened multi-party comment sub-threads.

Disambiguation ('Not for X, use Y'):

• Not for commenting on someone else's post -> use linkedin-comment-drafter.
• Not for drafting the main post itself -> use linkedin-post-writer.
• Not for monitoring post metrics or alerting on author replies over time -> use linkedin-thread-monitor.
• Not for segmenting audience commenters into ICP lead tiers -> use linkedin-engager-analytics.
• Not for cleaning up robotic phrasing -> use linkedin-humanizer.

Understanding LinkedIn's 2-Level Thread Flattening

A major architectural trap on LinkedIn is 2-level thread flattening:

[Post Author Update]
  └── [Comment Level 1: User A] (Top-level comment)
        └── [Reply Level 2: User B] (First reply to User A)
        └── [Reply Level 2: User C] (Reply to User B - FLATTENED FLUSH)
        └── [Reply Level 2: Post Author] (Reply to User C - FLATTENED FLUSH)

1. Level 1: The top-level comment directly underneath the author's post.
2. Level 2: The first reply to that top-level comment.
3. Level 3+ (Flattened): Any subsequent reply to a Level 2 comment is NOT indented further. Instead, LinkedIn groups it flush at Level 2, scrambling chronological order and obscuring who is replying to whom.

Handling Strategy for Flattened Threads:

• Explicit Name Anchoring: When replying in flattened sub-threads, always open with the commenter's name or handle (e.g. @David: ...).
• Context Re-anchoring: Briefly restate the specific sub-point being addressed (e.g. "Regarding the cache eviction edge case you mentioned...").
• Thread Consolidation: If multiple participants ask related questions in a flattened sub-thread, draft a single comprehensive reply that addresses both parties, preserving readability for future readers.

The Batch-Sweep Workflow

On viral posts with 50+ comments, manual one-by-one replying causes context fatigue. The Batch-Sweep engine streamlines this into 4 structured stages:

1. Thread Ingestion & Triage:
   • Ingest all comments on the target post via URL or API.
   • Categorize each comment into one of four buckets:
     • Bucket A (High-Intent Prospect / In-Depth Technical): Requires thoughtful, customized reply with actionable details.
     • Bucket B (Peer Agreement / Thoughtful Additive): Requires warm validation and an engaging counter-question to keep the conversation moving.
     • Bucket C (Brief Validation / Thumbs-up): Quick acknowledgement without bloating the thread.
     • Bucket D (Spam / Troll / Bad-Faith): Politely ignore or hide. Do not feed bad-faith arguments.
2. Parallel Reply Generation:
   • Generate tailored draft responses for all Bucket A and Bucket B comments in parallel.
   • Apply specific conversational hooks that invite the commenter to reply again (triggering algorithmic second-wave boosts).
3. Unified Review Grid:
   • Present all drafted replies in a consolidated review table with commenter name, original comment snippet, and proposed response.
4. Staged Approval Execution:
   • User reviews the grid, modifies individual replies if needed, and approves the batch with a single confirmation.

Reply Framework Archetypes

The skill applies four core reply archetypes depending on the incoming comment type:

1. The Ping-Pong Extender (For thoughtful comments)

• Goal: Get the commenter to reply back, doubling the post's comment count.
• Pattern: Validate their perspective -> add a 1-sentence nuance -> ask a low-friction question.
• Example: "Spot on, Alex. We noticed the exact same bottleneck when scaling beyond 10k connections. Did your team resolve that via application-level connection pooling or an external proxy like PgBouncer?"

2. The Graceful Clarifier (For skeptical pushback)

• Goal: Defuse tension, welcome nuance, and demonstrate senior confidence without defensive posturing.
• Pattern: Thank them for pointing out the edge case -> clarify the operational boundary -> affirm common ground.
• Example: "Fair challenge, Elena. In pure single-tenant environments, this abstraction adds unnecessary overhead. Our approach was specifically designed for multi-tenant setups where noisy-neighbor isolation is non-negotiable. Appreciate the nuance!"

3. The Bridge to DM (For prospective buyers or enterprise inquiries)

• Goal: Transition an interested prospect from public comments to private discovery without sounding like a sleazy salesperson.
• Pattern: Answer the public question concisely -> offer to share internal raw docs or benchmark data via DM.
• Example: "Great question, Marcus. We benchmarked 3 different approaches before choosing this stack. I have a 2-page internal RFC detailing our exact schema migration—happy to drop it into your LinkedIn DMs if useful."

4. The Short & Crisp (For quick praise)

• Goal: Acknowledge genuine support without robotic repetition.
• Pattern: Personal greeting -> 1 sentence of genuine appreciation.
• Example: "Appreciate you reading, Priya! Really glad the breakdown on query caching was helpful."

De-Escalation Protocol: Handling Skeptics & Pushback

When someone challenges your post in the comments:

• Never be defensive: Defensive authors look junior and fragile to prospective buyers.
• Acknowledge the merit of their view: Almost every critique highlights a legitimate edge case under different operating conditions.
• Clarify the boundary condition: Reframe the disagreement as a trade-off: "You are 100% right if your team is operating at 500+ engineers. Our framework was designed specifically for early-stage teams under 20 engineers where communication latency is the primary bottleneck."
• Invite their solution: Ask what tools or workflows they deployed to solve that trade-off.

How It Works Step-by-Step

When executing linkedin-reply-handler, follow these phases:

1. URL & Thread Parsing:
   • Parse the target LinkedIn post or comment URL using lib.url_parser.parse_comment_url or parse_post_url.
   • Verify post accessibility and parse hierarchical thread structure.
2. Categorization & Triage:
   • Classify all target comments into Buckets A, B, C, or D.
   • Filter out low-effort bot spam.
3. Reply Formulation:
   • Draft context-aware responses adhering to references/voice-rules.md.
   • Prevent repetitive language (ensure no two replies in the same thread use the same opening sentence).
   • Resolve flattened level-2 thread naming collisions.
4. Approval Gate Presentation:
   • Queue responses in lib.publora_client.PubloraClient via client.reply(comment_urn=..., text=..., approved=False).
   • Output structured review payload for user inspection.
5. Execution:
   • Upon explicit approval command, dispatch calls with rate-limiting pauses (3-5 seconds between replies) to mimic natural human cadence.

Approval Gate

Every batch or single reply requires user verification before transmission:

[STAGED REPLY BATCH APPROVAL]
Target Post URN: urn:li:activity:7123456789012345678
Total Staged Replies: 3

1. Target Comment: urn:li:comment:(activity:7123456789012345678,9901)
   Commenter: Sarah Chen (CTO at FinScale)
   Inbound: "Did you encounter race conditions when invalidating Redis keys across regions?"
   Drafted Reply: "Great point, Sarah. Cross-region replication lag was our biggest headache during week 2. We solved it by switching from eager invalidation to versioned cache keys with short TTLs. Did your team evaluate consistent hashing for this?"

2. Target Comment: urn:li:comment:(activity:7123456789012345678,9902)
   Commenter: David Ross (Head of Growth)
   Inbound: "Love the transparency here. What tool are you using for real-time alerting?"
   Drafted Reply: "Thanks, David! We use a lightweight combination of Prometheus alerts piped into a dedicated Slack channel with custom pager webhooks."

Batch Approval Token: a77192f0-11cc-44ee-88bb-334455667788
Status: PENDING APPROVAL.
Command: Type 'APPROVE a77192f0-11cc-44ee-88bb-334455667788' to publish all 2 replies.

Examples

Example 1: Handling Technical Skepticism on an Architecture Post

Inbound Comment: "Calling microservices an unforced error is overly simplistic. What happens when your team grows to 100 developers? Monoliths don't scale org-wise."

Fair critique, Daniel. At 100+ engineers with distinct organizational domains, microservices become an organizational necessity to prevent PR gridlock.

Our post was specifically aimed at seed-to-Series-A teams with fewer than 20 engineers, where premature microservice decomposition introduces distributed systems complexity long before you have the headcount to support it.

At what team size did your organization find the tipping point where service decoupling paid for its overhead?

Example 2: Replying to an Inbound Commercial Prospect

Inbound Comment: "We are struggling with this exact database latency issue in our healthcare app. How long did this migration take your team?"

The initial schema redesign took about two weeks of focused architecture planning, followed by a phased 4-day zero-downtime migration over a holiday weekend.

Given healthcare compliance and HIPAA audit constraints, the rollback tooling took the most care. I actually wrote a checklist on our staging rollout strategy—happy to DM it over if you'd like to take a look!

Example 3: Thread-Flattened Level-3 Reply

Context: Commenter B responded to Commenter A's remark about Docker image sizes underneath your post.

@Kavita: Building on what Jason pointed out regarding multi-stage Docker builds: stripping out the build-time compiler dependencies in Stage 1 cut our final production image from 1.4GB down to 88MB. That single change reduced our ECS deployment rollouts by almost 4 minutes.

Example 4: De-escalating Cynical Pushback

Inbound Comment: "Yet another startup claiming to revolutionize developer productivity. We've heard this sales pitch 100 times before."

Healthy skepticism is totally justified—our industry has burned a lot of credibility on vague AI productivity promises.

That is why we open-sourced our raw latency benchmark scripts on GitHub and published our unedited post-mortem. We don't ask anyone to take our word for it; you can run the reproduction suite locally in 3 minutes.