Wave 3 / Step 10 of the remediation plan (Phase 1 — usable by a non-author), per
research/02.
State what the plugin can and cannot do for a PERSONAL profile, dated 'as of
2026-05', without replacing one false claim with another:
- README.md: new 'Boundaries (as of 2026-05)' section. (a) post-level analytics API
EXISTS but is partner-gated (vetted Community Management app + verified org +
Page) — not self-serve; CSV is the practical floor; saves visible natively
(count-only, ~Sept 2025) with no self-serve API pull. (b) auto-publish is
technically POSSIBLE self-serve (w_member_social) but deliberately NOT built — a
design + ToS choice, explicitly 'not an impossibility' (avoids the new false
'cannot auto-publish' claim). (c) dwell internal-only for organic, not exportable.
- commands/calendar.md: the publish action now states plainly it marks a post YOU
posted manually as published — the tool does not post on your behalf.
- commands/report.md: dated the saves/no-self-serve-API note ('as of 2026-05').
- commands/import.md: dated 'Why CSV' note — API is partner-gated, CSV is the floor.
Verify: grep -niE 'cannot auto-publish|only way to (get|access)' README.md
commands/*.md -> no matches; grep -ni 'as of 2026' README.md -> 2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wave 2 / Step 7 of the remediation plan (research/02 D2/D4).
The tool parses the LinkedIn analytics CSV export, which has no saves/dwell — and
there is no self-serve API to pull them. Stop implying it tracks them:
- report.md: replace "Saves (10x weight) and expert comments (7-9x) are the
highest-impact signals" with honest wording — saves rank highest in the
engagement ORDER (cite references/algorithm-signals-reference.md, not a restated
coefficient), but are visible only in native LinkedIn post analytics (count-only,
~Sept 2025+) with no self-serve API, so this tool does not auto-track them; dwell
is internal to LinkedIn for organic posts.
- types.ts: document why PostMetrics intentionally omits saves/dwell (no ingest
source) so a future contributor does not "add the missing fields".
- strategy.md: reconcile two saves references (signature-content criterion +
authority scorecard) to say the count is read from native LinkedIn analytics, not
captured by this tool.
No new metric field, no manual-entry feature (operator Q3).
Verify: report.md has no "Saves (10x"/"highest-impact signals" and does say "no
self-serve API"; tsc --noEmit clean; analytics suite 106/106; structural lint
0 failed (report.md cites the reference, so stat-consistency stays green).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Wave 2 / Step 4 of the remediation plan (docs/remediation/plan.md).
PRIMARY (the real fresh-clone failure):
- scripts/analytics/node_modules is gitignored, so a fresh clone has neither
tsx nor csv-parse. Surface an idempotent `npm install --silent` prerequisite
at point-of-use in report.md (Step 1b) and import.md (Step 4).
DEVIATION FROM PLAN (correction-in-scope, to satisfy the plan's own Verify gate):
- The plan assumed prepending `npm install` was sufficient. Verified it is NOT:
the commands invoke the CLI with an absolute src/cli.ts path but from the
user's arbitrary CWD, and `node --import tsx` resolves the `tsx` specifier
relative to CWD, not the script. There is no global tsx, so the call still
fails with ERR_MODULE_NOT_FOUND from any CWD other than scripts/analytics.
- Complete fix: invoke the locally-installed tsx by its absolute
node_modules/.bin/tsx path in all CLI calls (report.md x10, import.md x3), so
they resolve from any working directory once the install above has run.
Verified: 0 ERR_MODULE_NOT_FOUND running `report` from /tmp.
SECONDARY (latent correctness / hardening):
- Add findPluginRoot(): walks up to the dir holding .claude-plugin/plugin.json
and anchors getAnalyticsRoot() on it, falling back to the legacy 4-up count.
MEASURED that ../../../../ already resolved to the plugin root from BOTH
src/utils and build/utils (both 4 levels deep), so the plan's "src-vs-build
depth miscalibration" premise was false — this is correct-by-construction
hardening (survives a future source move), not a live-bug fix.
- Reconcile cli.ts usage/help text: `node build/cli.js` -> `node --import tsx
src/cli.ts` (the real runtime).
- Fix report.md troubleshooting: "Verify tsx is available" -> the actual
install command on ERR_MODULE_NOT_FOUND.
Test-first: scripts/analytics/tests/storage-root.test.ts (red on missing
findPluginRoot export, green after). Full suite 106/106, tsc --noEmit clean,
structural lint 0 failed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
BREAKING CHANGE: the marketplace slug, the agent namespace
(linkedin-studio:<agent>), and the runtime state-file path
(~/.claude/linkedin-studio.local.md) all change. Reinstall required;
existing state migrated in place (post metrics, streak, history preserved).
The /linkedin:* commands are unchanged — the command namespace is set
per-command in frontmatter and was always independent of the plugin slug.
Functionality is byte-identical to v2.4.0; this release is pure identity.
- dir + manifests: plugins/linkedin-studio + plugin.json + root marketplace.json
- agent namespace updated in commands/newsletter.md (only functional invoker)
- state path updated in 4 hook scripts + topic-rotation prompt + state template
- catch-all skill dir renamed skills/linkedin-studio (5 functional skills unchanged)
- docs + version bump to 3.0.0 across README badge, CHANGELOG, root README/CLAUDE.md
- historical records (CHANGELOG past entries, docs/ build artifacts,
config-audit v5.0.0 snapshots) intentionally retain the old slug
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-05-29 11:32:02 +02:00
Renamed from plugins/linkedin-thought-leadership/commands/report.md (Browse further)
