Forward Deployed Engineer delivery contract for AWS engagements, build-first artifacts, grounded cost estimates, Well-Architected review, evolution roadmap
日本語の概要は準備中です。原文の説明を表示しています。
This skill should be used when the user asks to "write a LinkedIn post", "draft a post about", "help me post on LinkedIn", "create LinkedIn content", or when Genesis proactively generates post ideas during surplus compute. Also triggered by content calendar execution or when the user shares a topic they want to write about.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Write LinkedIn posts that sound authentically human — in the user's real voice, with genuine substance, avoiding every AI-generated content pattern. The bar is: a reader cannot distinguish this from the user having written it themselves.
Before writing any post, load the user's voice via voice-master's overlay resolution:
../voice-master/SKILL.md and follow its User Calibration
Overlay section. Voice-master will load the user's exemplars and
voice-dimensions from the out-of-repo overlay (or fall back to the
in-repo template with a warning if no overlay exists).social. Select 3-5 social-medium exemplars
matching this post's topic and tone from whatever voice-master loads.../voice-master/references/anti-slop.md — apply the Universal
and Professional / LinkedIn sections (forum / long-form sections
do not apply here).Use exemplars as stylistic reference — match sentence structure, vocabulary, directness. Do NOT copy exemplar content.
If no overlay is present, voice-master falls back to the template and emits a warning. Your output will be generic in that case; surface this clearly.
Every post MUST comply with the anti-slop rules. Failure to follow these rules produces content that damages the user's professional reputation. Treat violations as bugs, not style preferences.
Share something that actually happened — a project, a decision, a mistake, a win. Grounded in specifics: technologies, team size, timeline, outcome.
Structure: Start in the middle of the story (not "Last week I..."). Give enough context to follow. Share the insight without moralizing. End with the thought, not a question.
Take a position on something in the industry. Must be a genuinely held opinion with reasoning — not a repackaged platitude.
Structure: State the observation. Give evidence or reasoning (specific examples, data, or experience). Acknowledge the counterargument. Land on your position. Keep it under 800 characters unless the argument genuinely needs more.
Explain something technical clearly. Aimed at the intersection of the user's audience: technical enough to be useful, clear enough for adjacent roles.
Structure: Start with the problem or situation. Explain the concept or approach. Include a concrete example. Avoid tutorial tone — this is a peer sharing knowledge, not a teacher lecturing.
React to industry news, a trend, or someone else's post. Add original perspective — never just summarize what happened.
Structure: Brief context (assume audience saw the news). Your take — specifically, what everyone is missing or getting wrong. Why it matters to people like the user's audience.
Pose a genuine question the user is thinking about. Not engagement bait — a real question with no obvious answer.
Structure: Set up why this question matters. Ask it clearly. Share your current thinking if you have one (makes it a discussion, not a poll).
Clarify the angle — If the user provides a topic, identify the specific angle before writing. "Cloud computing" is not an angle. "Why multi-cloud is mostly a lie companies tell themselves" is an angle.
Draft in voice — Write the post using the loaded voice exemplars. Vary sentence length. Include at least one specific detail (a technology name, a number, a company, a situation). Avoid perfect structure.
Anti-slop check — Re-read against the banned patterns list. If any pattern appears, rewrite that section. Common failures: the opener defaults to a banned pattern, the ending becomes an engagement prompt, the structure is too clean.
Length check — LinkedIn posts have a 3,000-character limit. Most good posts are 500-1,500 characters. Go longer only if the content justifies it. Short posts that land well outperform long posts that meander.
Hashtag check — 2-3 maximum, only genuinely relevant ones. Place at the end, not inline.
During surplus compute or content calendar execution, Genesis generates post drafts and stages them for user review. Proactive posts should:
---
type: <experience | insight | technical | commentary | question>
topic: <brief topic description>
estimated_length: <short(500ch) | medium(1000ch) | long(1500ch+)>
hashtags: <2-3 relevant tags>
---
[POST CONTENT]
---
genesis_notes: |
<why this angle was chosen, what voice rules were applied,
any concerns about authenticity>
../voice-master/SKILL.md — Voice authority. Follow its User Calibration Overlay section to load exemplars and voice-dimensions from the user overlay; exemplars themselves live outside the repo at ~/.claude/skills/voice-master/exemplars/.../voice-master/references/anti-slop.md — Universal + Professional/LinkedIn anti-slop rules../linkedin-content-calendar/SKILL.md — Calendar planning../linkedin-hook-writer/SKILL.md — Opening line generationまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Forward Deployed Engineer delivery contract for AWS engagements, build-first artifacts, grounded cost estimates, Well-Architected review, evolution roadmap
日本語の概要は準備中です。原文の説明を表示しています。
Canonical guide to Genesis browser automation - layers (Camoufox, Chromium, the user's Chrome over CDP, TinyFish, desktop), per-tool timeouts, safety gates, verify-after-act, what a click checks (scroll, hit test, covered targets), overlays, iframes, tabs, and failure diagnosis
日本語の概要は準備中です。原文の説明を表示しています。
Update Claude Code (the CC CLI / "clog code") to a new version, or bump the pinned CC version. Use when the user asks to update Claude Code, bump the CC pin, evaluate a new CC release, or says "clog code update". Routes to the canonical, standardized process in docs/reference/cc-compatibility.md — do NOT re-derive the update mechanism by grepping every time. Do NOT use for general "what changed in CC" trivia with no intent to update.
日本語の概要は準備中です。原文の説明を表示しています。
This skill should be used when a session's job is to DRIVE OPEN PRs TO MERGE rather than to write new code — "close out the open PRs", "review and fix the open PRs", "what's blocking our PRs", "which PRs are mergeable". It owns the In Review column: it reads each PR's gate status, verifies and fixes review findings on PRs OTHER sessions built, replies in-thread, and stops at the merge gate for the user's per-PR approval. Do NOT load it for building a feature and opening its PR — that is a build session (`genesis-development`).
日本語の概要は準備中です。原文の説明を表示しています。
Code understanding tool selection. Use when exploring architecture, finding definitions, tracing call chains, assessing blast radius of changes, or debugging code paths in the Genesis codebase.
日本語の概要は準備中です。原文の説明を表示しています。
End-to-end content creation and publishing. Takes a topic (or generates one), drafts in the user's voice, gets approval via Telegram, and publishes to Medium via browser automation. Invoke with "publish a post about X", "write and publish to Medium", "content-publish", or when an ego-dispatched session needs to create and distribute content.
日本語の概要は準備中です。原文の説明を表示しています。