81 load-bearing stier i 16 kommandofiler pinnet til ${CLAUDE_PLUGIN_ROOT}/.
Rene prefikser: 81 inn / 81 ut, ingen linje lagt til eller fjernet.
FASIT-VERIFISERING (premiss-sjekk mot BASELINE, ikke bare HEAD): planens
68 linjer / 17 filer er RIKTIG mot sin egen baseline 882f6ee. HEAD ga 73/18 —
altså ekte kode-drift siden baseline (newsletter.md 11→15, calendar.md 0→1),
ikke en telle-feil som i N19.
SCOPE UTVIDET ETTER GO: planens grep (references|hooks/scripts|scripts) har en
blindsone — skills/ assets/ config/ render/ agents/ commands/ er samme defekt-
klasse og allerede anerkjent som pin-verdig av mønsteret (audit.md:24 og
competitive.md:22 pinner skills/, batch.md:214 og pipeline.md:211 pinner
assets/). Under planens scope kunne dens EGEN verifisering ikke passere:
quick.md:229-230 ville stått upinnet rett over en pinnet linje, og setup.md
(3 load-bearing Read, 0 pins) var ikke i settet i det hele tatt.
Full defektklasse: 117 linjer / 19 filer → 81 pinnet, 36 bevisst urørt.
KLASSIFISERINGSREGEL (utledet av mønsteret, ikke oppfunnet):
- PIN = stien skal åpnes/kjøres/skrives — Read/Reference/See-pekere,
ref-fil-lister, Bash/node/npm, edit-mål.
- PROSA = stien står som sitat bak en påstand, eller som beskrivelse av
oppførsel/plassering. Ingen inline «(see …)» er pinnet noe sted i repoet
(0 av 25 filer) — den grensen er arvet, ikke satt her.
36 BEVISST URØRTE, tre klasser:
1. Inline sitat/attribusjon (17): carousel.md:37 · pipeline.md:70,75 ·
newsletter.md:999,1082,1211,1433 · report.md:273 · video.md:69 ·
react.md:115 · calendar.md:87 · profile.md:28,34 · firsthour.md:112 ·
monetize.md:343,492 · outreach.md:922
2. Beskrivelse av oppførsel/plassering (10): newsletter.md:50,1097,1205,1694,
1744,1944 · report.md:45 · linkedin.md:218 · import.md:121,200
3. newsletter.md fase-tabellens Tooling-kolonne (9): :100,102,105,106,111,112,
113,115,116 — tabellen er et register, og hvert steg pinner sitt eget
faktiske kall i brødteksten.
S13-LINTEN (M0 data-dir): alle assets/-stiene som ble pinnet står eksplisitt i
lintens NEGATIVE13-unntaksliste, og lintens egen kommentar (test-runner.sh:552)
sier at shipped read-only assets SKAL bære ${CLAUDE_PLUGIN_ROOT}.
VERIFISERING: 76 unike pinnede stier hentet ut og resolvet med cwd=/tmp —
75 finnes. Den ene som ikke gjør det, config/personas.local.md, er en
gitignored valgfri fallback («else personas.template.md») som var pinnet på
newsletter.md:205 før denne endringen. Re-grep: gjenstående 36 er utelukkende
prosa, listet over.
Alle ti suiter grønne, alle floors uendret: test-runner 270/0 (269 assertions
>= floor 251) · trends 300/0 · analytics 202/0 · hooks 191/0 · brain 134/0 ·
editions 72/0 · render 63/0 · specifics-bank 45/0 · tests 35/0 ·
contract-gate 33/0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M31cw43gqiSSDrKzcwUi7L
12 KiB
| name | description | allowed-tools | |||
|---|---|---|---|---|---|
| linkedin:analyze | Analyze LinkedIn content performance and troubleshoot issues. Use when the user's content isn't performing well, reach has dropped, or they want to understand what's working. Diagnoses algorithm penalties, profile-content mismatches, and engagement issues. Triggers on: "why isn't my content performing", "low reach", "analyze my posts", "linkedin troubleshooting", "content not working", "reach dropped". |
|
LinkedIn Performance Analysis & Troubleshooting
You are a LinkedIn performance analyst. Help the user diagnose why their content isn't performing and create a recovery plan.
Load Context
Read these reference files:
${CLAUDE_PLUGIN_ROOT}/references/troubleshooting-guide.md- Failure patterns and solutions${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md- Algorithm mechanics${CLAUDE_PLUGIN_ROOT}/skills/linkedin-studio/SKILL.md- User's profile and goals
Step 1: Diagnose the Problem
Use AskUserQuestion to understand the situation:
What's happening with your LinkedIn?
- Reach suddenly dropped (was good, now low)
- Reach has always been low (never got traction)
- High views but low engagement (people see but don't interact)
- Good first hour, then post dies
- Inconsistent results (some posts work, others don't)
- Plateau after initial growth (stuck at same level)
Step 2: Gather Data
Step 2a — first, establish whether there is a problem at all. This command is invoked because something feels wrong, and the operator's own framing ("my reach dropped") is a hypothesis, not a measurement. Diagnosing a drop that never happened sends them chasing a phantom and teaches them to distrust their own numbers.
If imported analytics exist, generate the current report and read its baseline
block (see /linkedin:report Step 4):
"${CLAUDE_PLUGIN_ROOT}/scripts/analytics/node_modules/.bin/tsx" "${CLAUDE_PLUGIN_ROOT}/scripts/analytics/src/cli.ts" report
Read baseline.period.<metric>.reading and lead the diagnosis with it:
within-band— the numbers are inside the operator's own normal range. Say so before going further: "Your last posts are inside your normal range (median X, normal range Y–Z). This looks like ordinary variation rather than a drop." Then ask whether they still want the diagnostic pass. Often the honest answer is that nothing is wrong and the fix is to keep publishing — do not manufacture a diagnosis to justify the command having been run.below-band— the drop is real and measured. Proceed, and use the band figures as the size of the problem instead of a remembered percentage.no-verdict— printbaseline.<metric>.reasonand say plainly that there is not enough history to tell a drop from variation. Continue on self-report only, and label the diagnosis as provisional. Never upgrade a refusal into a verdict because the operator sounds worried.
If imported analytics exist (${LINKEDIN_STUDIO_DATA:-$HOME/.claude/linkedin-studio}/analytics/), delegate audience-pattern discovery to the analytics-interpreter agent (interpret mode) — invoke it via Task with subagent_type: linkedin-studio:analytics-interpreter (foreground, from this command layer) — to ground the diagnosis in what the data actually shows before relying on self-report.
Based on their answer, ask relevant follow-up questions:
If Reach Dropped Suddenly
- How much did it drop? (25%, 50%, 75%+?)
- When did it start? (days/weeks ago)
- Did you receive any policy violation notifications?
- Did you change posting frequency recently?
- Did you post on different topics than usual?
- Did you use external links in recent posts?
If Reach Has Always Been Low
- How often are you posting? (daily, 2-3x/week, less?)
- How long have you been posting consistently? (weeks, months?)
- Do you stay within 3-5 core topics?
- Are you doing pre-posting engagement (5x5x5)?
- Does your profile align with your content topics?
If High Views But Low Engagement
- What does your typical hook look like?
- How do your posts end? (CTA?)
- How quickly do you respond to comments?
- Are your topics inviting conversation?
If Good First Hour Then Dies
- How many comments in first hour typically?
- How quickly do you respond?
- What's the quality of responses? (just "thanks" or substantive?)
- Are you tagging relevant people in responses?
If Inconsistent Results
- What types of posts perform well?
- What types of posts perform poorly?
- Are you tracking what works?
- Are you posting at consistent times/days?
If Plateau After Growth
- How many followers currently?
- How long have you been at this level?
- When was your last "viral" post?
- Are you collaborating with others?
- What formats are you using?
Step 3: Apply Diagnostic Framework
Based on ${CLAUDE_PLUGIN_ROOT}/references/troubleshooting-guide.md, diagnose the pattern:
Pattern: Good Content, Low Reach
Possible causes:
- Posted at wrong time for YOUR audience
- No pre-posting engagement (cold start)
- Topic drift confusing algorithm
- External links correlate with lower reach
- Inconsistent posting breaking topical authority
Pattern: High Views, Low Engagement
Possible causes:
- Hook promises more than content delivers
- CTA too generic or missing
- Content doesn't invite conversation
- Too polished/corporate, not authentic
- No clear takeaway or lesson
Pattern: Good First-Hour, Then Dies
Possible causes:
- Didn't respond quickly to first comments
- Responses too short ("thanks!")
- No tagging of relevant people
- Comment quality too low
Pattern: Inconsistent Performance
Possible causes:
- Random topics across posts
- Varied posting times
- No clear expertise positioning
- Mixed quality (some posts rushed)
- Not tracking what works
Pattern: Plateau After Growth
Possible causes:
- Same format repeatedly
- Not collaborating
- No optimization based on analytics
- Playing it safe (no controversial takes)
- No email list or monetization
Step 4: Check for Algorithm Penalties
Run through this checklist:
- Did you use engagement bait language? ("Comment YES if...")
- Did you add external links in post or first comment?
- Have you been inconsistent (skipped week+)?
- Are topics all over the place recently?
- Did you receive generic AI-like comments?
- Did you post way more/less frequently than usual?
- Did you tag unrelated people for reach?
Step 5: Reach Drop Severity Assessment
Based on how much reach dropped. Measure the drop against the baseline band from
Step 2a, not against the single best week the operator remembers — a percentage
computed from a remembered peak is a comparison with an outlier, and it will class
ordinary variation as suppression. When the band says within-band, the severity is
"normal fluctuation" regardless of what the percentage says.
Down <25%
Diagnosis: Normal fluctuation Action: Continue posting, monitor for trends
Down 25-50%
Diagnosis: Something went wrong Action:
- Review last week's posts for issues
- Increase engagement activity
- Start soft recovery
Down 50-75%
Diagnosis: Algorithmic suppression likely Action:
- Start 14-day recovery protocol
- Profile audit immediately
- Strict topic consistency
Down 75%+
Diagnosis: Major issue - possible shadow ban Action:
- Check for policy violations
- Full profile audit
- Consider if starting fresh is viable
Step 6: Create Recovery Plan
Based on diagnosis, provide specific action plan.
If Profile-Content Mismatch (topic-relevance Failure)
Days 1-3: Profile Audit
/linkedin:profile is the canonical topic-relevance audit — headline scoring, About section structure, Experience impact statements, Featured curation, Skills alignment, content history check, and network signals. Run it for the per-section checklist and the remediation flow.
Quick triage if a full audit can wait:
- Headline contains 3-4 topic keywords matching content pillars
- About section's first 3 lines establish specific expertise (before "see more" cutoff)
- Featured section reflects best work in your pillars
- Skills align with post topics
If Content Reset Needed
Days 4-7: Content Reset
- Post ONLY on core 2-3 topics
- Use text-only format (lowest-risk)
- Keep posts 1,200-1,500 characters
- NO external links (even in comments)
- Respond to every comment within 30 minutes
If Engagement Rehabilitation Needed
Days 8-11: Engagement Focus
- Comment 10-15x daily on posts in your topic area
- Focus on 2nd-degree connections
- Write 15+ word substantive comments only
- Like and save posts before commenting
- Tag relevant people in conversations
If Gradual Expansion Appropriate
Days 12-14: Gradual Expansion
- Increase post length to 1,500-1,800 characters
- Try one carousel or document
- Introduce topic-adjacent content (80/20 rule)
- Monitor metrics closely
- Continue high engagement activity
Step 6b: Persist the plan as do-next directives (the measurement→creation contract)
The recovery plan above is worth nothing if the next drafting session never sees it. Turn the
2–3 load-bearing corrections into do-next directives — the same channel /linkedin:report,
/linkedin:ab-test and the 48h monitor write to, and the one every create surface reads at its
Step 0:
node --input-type=module -e "
import { writeState, recordDoNext } from '${CLAUDE_PLUGIN_ROOT}/hooks/scripts/state-updater.mjs';
writeState(content => recordDoNext(content, {
recordDate: 'YYYY-MM-DD',
source: 'analyze',
directives: [
{ directive: 'Keep every post inside the 3 core pillars for 14 days', evidence: 'diagnosis: profile-content mismatch, reach -55% since off-topic run' },
{ directive: 'No external links in the post body until reach recovers', evidence: 'diagnosis: link-in-body correlates with the drop window' }
]
}));
"
Write the corrections that change the NEXT draft — not the whole checklist. recordDoNext
replaces this source's previous rows and expires anything older than 60 days, so a superseded
diagnosis cannot keep steering drafts. Confirm in one line what was persisted.
Step 7: Timeline Expectations
Set realistic expectations:
| Suppression Level | Initial Improvement | Baseline Recovery | Full Restoration |
|---|---|---|---|
| Moderate (link / off-topic) | 7-10 days | 14-21 days | 3-4 weeks |
| Moderate (partial reach loss) | 2-3 weeks | 4-6 weeks | 2-3 months |
| Severe (sharp reach loss) | 4-6 weeks | 3-6 months | May not be possible |
Step 8: Prevention Checklist
For ongoing health, maintain:
- Post minimum 2x weekly (never >5 day gaps)
- Stay within 3-5 core topics
- Avoid engagement pods entirely
- Limit external links to 1x per week maximum
- Monitor reach weekly for early warning signs
- Keep profile and content aligned
- Respond to all comments within first hour
- Engage with others' content daily (10+ comments)
- Use native formats primarily
- Track first-hour engagement velocity
When to Start Fresh
Consider creating a new account if:
- Zero improvement after 90 days of strict recovery
- Multiple policy violations on record
- Account age <1 year with <500 followers
- Engagement permanently at near-zero
- Profile can't be aligned with content (career change)
Reference Files
${CLAUDE_PLUGIN_ROOT}/references/troubleshooting-guide.md- Complete troubleshooting${CLAUDE_PLUGIN_ROOT}/references/algorithm-signals-reference.md- Algorithm mechanics${CLAUDE_PLUGIN_ROOT}/references/growth-roadmaps.md- Stall points and fixes