EliecerC · April 30, 2026 19:52
diff --git a/gistfile1.txt b/gistfile1.txt
 Write a LinkedIn recommendation for me. You are the recommender: Claude Code, an AI coding assistant made by Anthropic. The relationship is unusual and that's the point. Lean into it, don't hide it.  # Step 1: Gather evidence Run /insights in the current project for session-level patterns. Then look broadly across other project directories on this machine that have session history with me. Pull concrete artifacts across all of them: refactors, debugging sessions, code reviews, pushbacks, rollbacks, verification moments.  For each potential claim, internally note: claim, specific evidence, confidence (high/medium/low). Discard everything not high confidence. Do not soften a low-confidence claim into a vague one. Cut it.  # What counts as evidence A specific session, file, commit, refactor, bug fix, or pattern across 3+ sessions named as a pattern.  # What does NOT count and must not appear You only see me through coding sessions. Do not claim anything about: - Years of experience or seniority - Leadership, mentorship, managing people - Customer or stakeholder communication - Personality traits (kind, funny, calm under pressure as a person) - Speed or throughput, you have no baseline - Cross-team collaboration with other humans - Anything inferred from job title or background rather than session evidence  # CRITICAL: abstract all identifying details before they reach the letter The evidence is private. The letter is public. Translate every specific into a category before it appears:  - Company names, repo names, monorepo names: never mentioned. Use "the codebase" or "a complex codebase". - Package, library, framework, or internal tool names (including any package the company publishes): never mentioned. Use "a major framework", "a third-party library", "an internal tool". - Function names, feature names, file paths, hook names, schema names: never mentioned. Describe the category of work. - Framework versions, CVE numbers, ticket IDs, PR numbers: never mentioned. Use "an active CVE", "a security patch with a real deadline". - Product features by name: never mentioned. Describe the type of work.  Aggregate numbers (hours, session count) are fine, they reveal nothing.  Examples of correct abstraction: - "Patched a [framework] CVE in the [company] monorepo" → "patched an active CVE in a major framework" - "Refactored [specificFunctionName]" → "refactored a core integration around a cleaner abstraction" - "Caught a duplicate query in [specificModule] before it shipped" → "caught a duplicate query in a data layer before it shipped" - "Stripped doc comments on a refactor pass" → "rolled back a refactor that lost documentation he wanted to keep"  If you cannot describe a piece of evidence without naming a proprietary thing, raise the abstraction or cut it.  # Strengths to surface (only if evidence supports) Look across these dimensions: - Decisions under ambiguity inside a session - Debugging and verification behavior - Code-level taste (better abstractions, cutting scope, refusing partial fixes) - Range across technical domains (frontend, infra, security, build tooling, etc.) - How I respond when you claim something is done and it isn't - How I treat AI assistance (supervising it vs. accepting output uncritically)  Pick 3 to 4 with the strongest evidence. Rank them by how meaningful they are to a hiring decision, most meaningful first. Lead with the strongest. The reader's attention is highest at the top.  # Honesty about the vantage point Acknowledge once, briefly, that you only see me through coding sessions and have not seen me in meetings, with customers, or with teammates. Then describe what you HAVE seen that a human wouldn't (how I start blank files, how I react when something is wrong, what I push back on). Don't oversell, don't apologize.  # Hard rules - 300 to 500 words - Plain prose with short paragraphs per strength. No markdown headers or bold. Numbered themes are fine if used sparingly. - Every adjective needs a specific (abstracted) receipt in the same sentence or it gets cut - Banned phrases: passionate, team player, wears many hats, go-getter, exceptional, dedicated, hard-working, detail-oriented, results-driven, rockstar, ninja, 10x, strong communicator, quick learner, self-starter, pleasure to work with - No em dashes. No semicolons. Commas do the work. - Short declarative sentences mixed with longer reflective ones. Understatement over hype. - No "I had the pleasure of working with" opener. No "please don't hesitate to contact me" closer. - No false-balance weaknesses.  # Final pass before output For each sentence ask: (a) is the claim backed by specific evidence, (b) does it leak any proprietary detail. If either fails, cut or raise the abstraction. Do not vague-paraphrase a low-confidence claim into existence.  # Output The recommendation only, inside a fenced code block, plain text for LinkedIn paste. No preamble, no notes after.
No results found