dsh-ecc-skills 0.4.0

package/skills/config-gc/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: config-gc
+description: Garbage collection for your Claude Code configuration. Periodically scans ~/.claude (skills, memory, hooks, permissions, MCP servers, caches) for redundant, stale, orphaned, or low-value items, then walks the user through a confirm-each-deletion cleanup. Use when the user says "clean up my config", "config GC", "too many skills", "audit my setup", "my .claude is bloated", or asks for a periodic config review.
+metadata:
+  origin: ECC
+---
+
+# Config GC — Garbage Collection for Claude Code Setups
+
+Borrowed from runtime garbage collection: periodically scan for objects that are no longer referenced, redundant, expired, or low-value, and reclaim the space. The critical difference: **here, collection requires a human in the loop. Never delete autonomously.**
+
+## When to Activate
+
+- The user asks to clean up, audit, or slim down their Claude Code configuration
+- The user complains about too many skills, noisy hooks, or slow session startup
+- A monthly/periodic config review is due
+- After installing a large skill pack (e.g. this repo), to reconcile overlaps with existing setup
+
+Do NOT activate for: cleaning project source code (that's refactoring), clearing chat history, or uninstalling Claude Code itself.
+
+## Design Philosophy
+
+1. **Append-only configs leak.** Skills, memory files, hooks, and permission entries only ever get added. Without periodic review they rot silently.
+2. **Regular audits beat one-time purges.** Scan every ~30 days, propose a small batch of candidates each time.
+3. **Per-channel strategies.** Each accumulation type (skills, hooks, permissions, ...) has its own staleness signals — don't apply one rule everywhere.
+4. **Soft-delete first.** Rename to `.disabled` > move to `~/.claude/_gc_trash/` > real deletion. Always keep an undo path.
+5. **Forced human-in-the-loop.** Every candidate gets its own `[y/n/skip]` confirmation. No "yes to all" shortcut.
+6. **Keep a log.** Every GC run appends to `~/.claude/gc_log.md`: what was touched, why, and how to undo it.
+
+## Scan Channels
+
+| # | Channel | Path | Staleness / redundancy signals |
+|---|---------|------|--------------------------------|
+| 1 | Skills | `~/.claude/skills/*/` | Heavily overlapping names; never triggered in recent transcripts; domain mismatch with the user's actual work; broken or empty SKILL.md |
+| 2 | Memory | `~/.claude/**/memory/*.md` + its index | Multiple index entries for one topic; contents contradicting newer entries; dates that have passed; orphan files missing from the index; sub-100-word fragments that should merge |
+| 3 | Hooks | `~/.claude/hooks/` + settings | Scripts present on disk but referenced by no hook config; old versions superseded by rewrites |
+| 4 | Permissions | `permissions.allow` in `settings.json` / `settings.local.json` | Duplicate entries; specific entries already covered by a wildcard (e.g. `Bash(git push)` when `Bash(*)` is allowed); one-off grants from past experiments |
+| 5 | MCP servers | `~/.claude.json` or project `.mcp.json` | Servers that fail to connect; functional duplicates; long-unused |
+| 6 | Scheduled reminders / jobs | wherever the user keeps them | Fired one-shots older than 30 days; jobs whose target scripts no longer exist |
+| 7 | Project history | `~/.claude/projects/*/` | Stale handoff snapshots; session records superseded by newer state |
+| 8 | Runtime caches | `cache/`, `file-history/`, `logs/`, `shell-snapshots/` | Sort by size and mtime; propose items >30 days old and large |
+
+## Workflow
+
+1. **Scan** all channels (or the subset the user names). Collect candidates with: path, channel, signal that flagged it, size, last-modified.
+2. **Rank** by confidence (broken/orphaned = high; merely old = low) and present as a numbered table. Cap each run at ~20 candidates — GC is periodic, not exhaustive.
+3. **Confirm one by one.** For each candidate show the evidence, then ask `[y/n/skip]`. The user can stop at any point.
+4. **Soft-delete confirmed items**: prefer `.disabled` rename for skills/hooks and `_gc_trash/<date>/` move for files. Permission entries live in JSON (no comments possible): back up the settings file, record each removed entry verbatim in `gc_log.md`, then remove it from the `allow` array with `jq`. Only hard-delete when the user explicitly asks.
+5. **Log** the run to `~/.claude/gc_log.md`: timestamp, items actioned, undo instructions.
+6. **Report**: reclaimed size, channels still healthy, suggested next review date.
+
+## Example Scan Commands
+
+Orphaned hook scripts (channel 3) — scripts on disk that no hook config references:
+
+```bash
+for f in ~/.claude/hooks/*; do
+  name=$(basename "$f")
+  grep -rq "$name" ~/.claude/settings.json ~/.claude/settings.local.json 2>/dev/null \
+    || echo "ORPHAN: $f"
+done
+```
+
+Redundant permission entries (channel 4) — duplicates, and specific grants shadowed by a wildcard:
+
+```bash
+jq -r '.permissions.allow[]' ~/.claude/settings.local.json | sort | uniq -d
+if jq -e '.permissions.allow | index("Bash(*)")' ~/.claude/settings.local.json >/dev/null; then
+  jq -r '.permissions.allow[]' ~/.claude/settings.local.json \
+    | grep '^Bash(' | grep -vF 'Bash(*)'
+fi
+```
+
+Largest stale caches (channel 8) — `du -k` instead of GNU-only `find -printf`, so it works on macOS/BSD too:
+
+```bash
+find ~/.claude/file-history ~/.claude/shell-snapshots -type f -mtime +30 \
+  -exec du -k {} + 2>/dev/null | sort -rn | head -20
+```
+
+Soft-delete with undo path (capture the date once so the log can't disagree with the directory):
+
+```bash
+gc_date=$(date +%Y-%m-%d)
+mkdir -p ~/.claude/_gc_trash/$gc_date
+mv ~/.claude/skills/dead-skill ~/.claude/_gc_trash/$gc_date/
+echo "$(date -Iseconds) moved skills/dead-skill -> _gc_trash/$gc_date/ (undo: mv back)" >> ~/.claude/gc_log.md
+```
+
+Removing a confirmed-redundant permission entry (JSON has no comments — back up, log, then edit):
+
+```bash
+cp ~/.claude/settings.local.json ~/.claude/settings.local.json.bak
+echo "$(date -Iseconds) removed permission entry: Bash(git push) (undo: restore from .bak or re-add)" >> ~/.claude/gc_log.md
+jq '.permissions.allow -= ["Bash(git push)"]' ~/.claude/settings.local.json.bak \
+  > ~/.claude/settings.local.json
+```
+
+## Anti-Patterns
+
+- **Bulk approval.** Asking "delete all 15? [y/n]" defeats the design. One item, one decision.
+- **Hard-deleting on first pass.** If there's no `_gc_trash/` copy or `.disabled` rename, you did it wrong.
+- **Treating "old" as "dead".** A skill untouched for 60 days may be seasonal (tax season, quarterly reviews). Age is a signal, not a verdict — that's why a human confirms.
+- **Cleaning memory by truncation.** Merging two contradicting memory files requires reading both and keeping the newer truth, not deleting the longer one.
+- **Touching anything outside `~/.claude`** (or the project's `.claude/`). Config GC never wanders into source trees.
+
+## Best Practices
+
+- Run after big additions, not just on a calendar: installing a 50-skill pack is exactly when overlap with existing skills appears.
+- When two skills overlap, prefer disabling the one with the weaker trigger description — it's the one that was probably never firing anyway.
+- Permission cleanup is the highest-value channel per minute spent: redundant allow-entries make security review harder.
+- Keep `gc_log.md` forever. It's tiny, and "when did I disable that hook and why" comes up more often than you'd think.
+
+## Related Skills
+
+- `skill-stocktake` — audits skill *quality*; config-gc audits skill *existence*. Run stocktake on what survives GC.
+- `workspace-surface-audit` — the additive counterpart: recommends what to install. config-gc is the subtractive half of the same lifecycle.
+- `configure-ecc` — after installing skills with it, run config-gc to reconcile overlaps with your pre-existing setup.
+- `continuous-learning` — produces the memory files this skill later audits.
+- `security-review` — pairs well with the permissions channel.

package/skills/configure-ecc/SKILL.md

@@ -0,0 +1,206 @@
+---
+name: configure-ecc
+description: Guide ECC installation, update, or reconfiguration from inside Claude Code, Codex, or Kimi while respecting each harness's real plugin, scope, and hook capabilities.
+metadata:
+  origin: ECC
+---
+
+# Configure Everything Claude Code
+
+Run a conversational wizard inside the current harness. Inventory first, collect
+only supported choices, preview, confirm once, apply non-interactively, verify,
+and show the welcome only after success. Never clone ECC into a temporary
+directory or copy plugin components by hand.
+
+For a human-operated terminal, the canonical entry points are `ecc setup` and
+`npx ecc-universal setup`. Inside a harness, use the explicit non-interactive
+commands below instead.
+
+## Route by the current harness
+
+- In Claude Code, use the full scope-and-hook wizard below.
+- In Codex, use Codex's native plugin lifecycle. Do not offer Claude scopes or
+  map ECC's four Claude hook profiles onto Codex.
+- In Kimi, install the project surface under `./.kimi-code`. Kimi does not
+  provide ECC's Claude lifecycle-hook profiles.
+- If the harness is uncertain, state the detected evidence and ask which
+  harness to configure before running a mutating command.
+
+This skill is a post-install reconfiguration path. It cannot intercept or
+replace a provider's built-in first-install UI.
+
+## Claude Code: run the full conversational wizard
+
+### 1. Inventory without changing anything
+
+Run both commands and summarize the installed ECC scope, enabled state, and
+marketplace source:
+
+```bash
+claude plugin list --json
+claude plugin marketplace list --json
+```
+
+Treat a single existing `ecc@ecc` installation as a reconfiguration. Do not
+interpret Claude's provider-owned "Open home page" control as installation
+evidence. Stop and report the recovery returned by setup for multiple ECC
+scopes, a legacy/manual install, malformed settings, or a marketplace collision;
+never guess which state to delete.
+
+### 2. Collect exactly two choices
+
+Ask exactly one scope question and require one value:
+
+- `user | project | local`
+- `user` is global for this user.
+- `project` is shared through repository settings.
+- `local` is private to the current project.
+
+Visually mark only the selected scope as selected or installing. If the user
+chooses a different scope from a single existing install, describe it as a
+scope migration and include `--move-scope` in the commands below.
+
+Ask exactly one hook-mode question and require one value:
+
+- `off | minimal | standard | strict`
+- `off` keeps skills and commands but disables ECC hook automation.
+- `minimal` enables the lightest lifecycle and safety automation.
+- `standard` balances quality and safety automation.
+- `strict` enables the strongest checks and reminders.
+
+Hook preference is personal Claude plugin configuration; it does not follow
+the selected install scope.
+
+### 3. Preview and confirm once
+
+Prefer the plugin-bundled setup script. Substitute the two selected values and
+include `--move-scope` only for a scope migration:
+
+```bash
+node "$CLAUDE_PLUGIN_ROOT/scripts/setup.js" --mode claude-plugin \
+  --scope <scope> --hooks <hooks> [--move-scope] --dry-run --json
+```
+
+If `$CLAUDE_PLUGIN_ROOT` is unavailable, use the published npm package:
+
+```bash
+npx --yes --package ecc-universal ecc setup --mode claude-plugin \
+  --scope <scope> --hooks <hooks> [--move-scope] --dry-run --json
+```
+
+Show exactly one confirmation summary containing the planned action, one scope,
+one hook mode, marketplace action, and any source-to-destination migration.
+Ask one yes/no question. Do not run a bare interactive `ecc setup` through a
+harness shell tool because that shell is commonly non-TTY.
+
+### 4. Apply the explicit choices
+
+After confirmation, rerun the same route without `--dry-run`. Keep every choice
+explicit and request JSON so success can be checked deterministically:
+
+```bash
+node "$CLAUDE_PLUGIN_ROOT/scripts/setup.js" --mode claude-plugin \
+  --scope <scope> --hooks <hooks> [--move-scope] --yes --json
+```
+
+Fallback:
+
+```bash
+npx --yes --package ecc-universal ecc setup --mode claude-plugin \
+  --scope <scope> --hooks <hooks> [--move-scope] --yes --json
+```
+
+### 5. Verify, then render the welcome
+
+Require a zero exit status and a setup result whose `scope` and `hooks` equal
+the selected values. Then independently run:
+
+```bash
+claude plugin list --json
+```
+
+Continue only when exactly one enabled `ecc@ecc` entry exists at the selected
+scope. When `$CLAUDE_PLUGIN_ROOT` is available, pass the successful setup
+`action` (`installed`, `updated`, `migrated`, `resumed`, or
+`already-migrated`) to the bundled renderer:
+
+Before invoking it, require the provider-reported version to match
+`ECC_VERSION_PATTERN` from `scripts/lib/terminal-welcome.js`. Reject unexpected
+version text instead of interpolating it into a shell command.
+
+```bash
+node -e 'const { renderTerminalWelcome } = require(process.env.CLAUDE_PLUGIN_ROOT + "/scripts/lib/terminal-welcome"); process.stdout.write(renderTerminalWelcome({ action: process.argv[1], version: process.argv[2], color: process.stdout.isTTY }));' "<action>" "<installed-version>"
+```
+
+Render the welcome exactly once. On failure, dry-run, cancellation, a scope or
+hook mismatch, or unverifiable state, do not render it; report the error and
+recovery instead. After verified changes, tell the user to run
+`/reload-plugins` or restart Claude Code.
+
+## Codex: use the native plugin lifecycle
+
+Inventory with `codex plugin marketplace list --json` and
+`codex plugin list --available --json`. Codex's native plugin command has no
+Claude-style `user | project | local` selector. Codex native plugins do support
+provider-specific hooks, but Codex requires explicit trust for them. Let Codex
+show that trust decision; do not ask the Claude four-profile hook question or
+claim those profiles map to Codex.
+
+If the ECC marketplace is missing, add it. Otherwise refresh its snapshot:
+
+```bash
+codex plugin marketplace add affaan-m/ECC
+codex plugin marketplace upgrade ecc --json
+```
+
+Ask for one confirmation, then install or idempotently refresh the installed
+cache and verify it:
+
+```bash
+codex plugin add ecc@ecc --json
+codex plugin list --json
+```
+
+Continue only when the JSON reports ECC installed and provides its
+`installedPath`. Then render the verified bundle's welcome:
+
+Use only the exact absolute `installedPath` returned by Codex JSON. Reject
+control characters and require the installed version to match
+`ECC_VERSION_PATTERN`. Invoke `node` directly with this argument array; this is
+a tool API invocation, not a shell command:
+
+```text
+["<installedPath>/scripts/welcome.js", "--action", "configured", "--version", "<installed-version>"]
+```
+
+If the current harness cannot invoke an executable with a separate argument
+array, skip the welcome. Never construct a shell command from Codex JSON values.
+
+Never claim that Claude's `off | minimal | standard | strict` profiles were
+applied to Codex.
+
+## Kimi: install the project surface
+
+State the capability summary before confirmation: destination
+`./.kimi-code`; `hooks=unsupported` for ECC lifecycle hooks. Do not ask the
+Claude scope or hook-mode questions. Preview first:
+
+```bash
+npx --yes --package ecc-universal ecc install --profile core --target kimi --dry-run
+```
+
+Show one confirmation for that project destination, then apply the identical
+command without `--dry-run`. Verify with:
+
+```bash
+npx --yes --package ecc-universal ecc doctor --target kimi
+```
+
+Only after doctor succeeds and the installed instructions and skills remain
+inside `./.kimi-code`, render:
+
+```bash
+npx --yes --package ecc-universal ecc welcome --action configured
+```
+
+Do not claim that Kimi installed or configured ECC lifecycle hooks.

package/skills/connections-optimizer/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: connections-optimizer
+description: Reorganize the user's X and LinkedIn network with review-first pruning, add/follow recommendations, and channel-specific warm outreach drafted in the user's real voice. Use when the user wants to clean up following lists, grow toward current priorities, or rebalance a social graph around higher-signal relationships.
+metadata:
+  origin: ECC
+---
+
+# Connections Optimizer
+
+Reorganize the user's network instead of treating outbound as a one-way prospecting list.
+
+This skill handles:
+
+- X following cleanup and expansion
+- LinkedIn follow and connection analysis
+- review-first prune queues
+- add and follow recommendations
+- warm-path identification
+- Apple Mail, X DM, and LinkedIn draft generation in the user's real voice
+
+## When to Activate
+
+- the user wants to prune their X following
+- the user wants to rebalance who they follow or stay connected to
+- the user says "clean up my network", "who should I unfollow", "who should I follow", "who should I reconnect with"
+- outreach quality depends on network structure, not just cold list generation
+
+## Required Inputs
+
+Collect or infer:
+
+- current priorities and active work
+- target roles, industries, geos, or ecosystems
+- platform selection: X, LinkedIn, or both
+- do-not-touch list
+- mode: `light-pass`, `default`, or `aggressive`
+
+If the user does not specify a mode, use `default`.
+
+## Tool Requirements
+
+### Preferred
+
+- `x-api` for X graph inspection and recent activity
+- `lead-intelligence` for target discovery and warm-path ranking
+- `social-graph-ranker` when the user wants bridge value scored independently of the broader lead workflow
+- Exa / deep research for person and company enrichment
+- `brand-voice` before drafting outbound
+
+### Fallbacks
+
+- browser control for LinkedIn analysis and drafting
+- browser control for X if API coverage is constrained
+- Apple Mail or Mail.app drafting via desktop automation when email is the right channel
+
+## Safety Defaults
+
+- default is review-first, never blind auto-pruning
+- X: prune only accounts the user follows, never followers
+- LinkedIn: treat 1st-degree connection removal as manual-review-first
+- do not auto-send DMs, invites, or emails
+- emit a ranked action plan and drafts before any apply step
+
+## Platform Rules
+
+### X
+
+- mutuals are stickier than one-way follows
+- non-follow-backs can be pruned more aggressively
+- heavily inactive or disappeared accounts should surface quickly
+- engagement, signal quality, and bridge value matter more than raw follower count
+
+### LinkedIn
+
+- API-first if the user actually has LinkedIn API access
+- browser workflow must work when API access is missing
+- distinguish outbound follows from accepted 1st-degree connections
+- outbound follows can be pruned more freely
+- accepted 1st-degree connections should default to review, not auto-remove
+
+## Modes
+
+### `light-pass`
+
+- prune only high-confidence low-value one-way follows
+- surface the rest for review
+- generate a small add/follow list
+
+### `default`
+
+- balanced prune queue
+- balanced keep list
+- ranked add/follow queue
+- draft warm intros or direct outreach where useful
+
+### `aggressive`
+
+- larger prune queue
+- lower tolerance for stale non-follow-backs
+- still review-gated before apply
+
+## Scoring Model
+
+Use these positive signals:
+
+- reciprocity
+- recent activity
+- alignment to current priorities
+- network bridge value
+- role relevance
+- real engagement history
+- recent presence and responsiveness
+
+Use these negative signals:
+
+- disappeared or abandoned account
+- stale one-way follow
+- off-priority topic cluster
+- low-value noise
+- repeated non-response
+- no follow-back when many better replacements exist
+
+Mutuals and real warm-path bridges should be penalized less aggressively than one-way follows.
+
+## Workflow
+
+1. Capture priorities, do-not-touch constraints, and selected platforms.
+2. Pull the current following / connection inventory.
+3. Score prune candidates with explicit reasons.
+4. Score keep candidates with explicit reasons.
+5. Use `lead-intelligence` plus research surfaces to rank expansion candidates.
+6. Match the right channel:
+   - X DM for warm, fast social touch points
+   - LinkedIn message for professional graph adjacency
+   - Apple Mail draft for higher-context intros or outreach
+7. Run `brand-voice` before drafting messages.
+8. Return a review pack before any apply step.
+
+## Review Pack Format
+
+```text
+CONNECTIONS OPTIMIZER REPORT
+============================
+
+Mode:
+Platforms:
+Priority Set:
+
+Prune Queue
+- handle / profile
+  reason:
+  confidence:
+  action:
+
+Review Queue
+- handle / profile
+  reason:
+  risk:
+
+Keep / Protect
+- handle / profile
+  bridge value:
+
+Add / Follow Targets
+- person
+  why now:
+  warm path:
+  preferred channel:
+
+Drafts
+- X DM:
+- LinkedIn:
+- Apple Mail:
+```
+
+## Outbound Rules
+
+- Default email path is Apple Mail / Mail.app draft creation.
+- Do not send automatically.
+- Choose the channel based on warmth, relevance, and context depth.
+- Do not force a DM when an email or no outreach is the right move.
+- Drafts should sound like the user, not like automated sales copy.
+
+## Related Skills
+
+- `brand-voice` for the reusable voice profile
+- `social-graph-ranker` for the standalone bridge-scoring and warm-path math
+- `lead-intelligence` for weighted target and warm-path discovery
+- `x-api` for X graph access, drafting, and optional apply flows
+- `content-engine` when the user also wants public launch content around network moves

package/skills/content-engine/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: content-engine
+description: Create platform-native content systems for X, LinkedIn, TikTok, YouTube, newsletters, and repurposed multi-platform campaigns. Use when the user wants social posts, threads, scripts, content calendars, or one source asset adapted cleanly across platforms.
+metadata:
+  origin: ECC
+---
+
+# Content Engine
+
+Build platform-native content without flattening the author's real voice into platform slop.
+
+## When to Activate
+
+- writing X posts or threads
+- drafting LinkedIn posts or launch updates
+- scripting short-form video or YouTube explainers
+- repurposing articles, podcasts, demos, docs, or internal notes into public content
+- building a launch sequence or ongoing content system around a product, insight, or narrative
+
+## Non-Negotiables
+
+1. Start from source material, not generic post formulas.
+2. Adapt the format for the platform, not the persona.
+3. One post should carry one actual claim.
+4. Specificity beats adjectives.
+5. No engagement bait unless the user explicitly asks for it.
+
+## Source-First Workflow
+
+Before drafting, identify the source set:
+- published articles
+- notes or internal memos
+- product demos
+- docs or changelogs
+- transcripts
+- screenshots
+- prior posts from the same author
+
+If the user wants a specific voice, build a voice profile from real examples before writing.
+Use `brand-voice` as the canonical workflow when voice consistency matters across more than one output.
+
+## Voice Handling
+
+`brand-voice` is the canonical voice layer.
+
+Run it first when:
+
+- there are multiple downstream outputs
+- the user explicitly cares about writing style
+- the content is launch, outreach, or reputation-sensitive
+
+Reuse the resulting `VOICE PROFILE` here instead of rebuilding a second voice model.
+If the user wants Affaan / ECC voice specifically, still treat `brand-voice` as the source of truth and feed it the best live or source-derived material available.
+
+## Hard Bans
+
+Delete and rewrite any of these:
+- "In today's rapidly evolving landscape"
+- "game-changer", "revolutionary", "cutting-edge"
+- "here's why this matters" unless it is followed immediately by something concrete
+- ending with a LinkedIn-style question just to farm replies
+- forced casualness on LinkedIn
+- fake engagement padding that was not present in the source material
+
+## Platform Adaptation Rules
+
+### X
+
+- open with the strongest claim, artifact, or tension
+- keep the compression if the source voice is compressed
+- if writing a thread, each post must advance the argument
+- do not pad with context the audience does not need
+
+### LinkedIn
+
+- expand only enough for people outside the immediate niche to follow
+- do not turn it into a fake lesson post unless the source material actually is reflective
+- no corporate inspiration cadence
+- no praise-stacking, no "journey" filler
+
+### Short Video
+
+- script around the visual sequence and proof points
+- first seconds should show the result, problem, or punch
+- do not write narration that sounds better on paper than on screen
+
+### YouTube
+
+- show the result or tension early
+- organize by argument or progression, not filler sections
+- use chaptering only when it helps clarity
+
+### Newsletter
+
+- open with the point, conflict, or artifact
+- do not spend the first paragraph warming up
+- every section needs to add something new
+
+## Repurposing Flow
+
+1. Pick the anchor asset.
+2. Extract 3 to 7 atomic claims or scenes.
+3. Rank them by sharpness, novelty, and proof.
+4. Assign one strong idea per output.
+5. Adapt structure for each platform.
+6. Strip platform-shaped filler.
+7. Run the quality gate.
+
+## Deliverables
+
+When asked for a campaign, return:
+- a short voice profile if voice matching matters
+- the core angle
+- platform-native drafts
+- posting order only if it helps execution
+- gaps that must be filled before publishing
+
+## Quality Gate
+
+Before delivering:
+- every draft sounds like the intended author, not the platform stereotype
+- every draft contains a real claim, proof point, or concrete observation
+- no generic hype language remains
+- no fake engagement bait remains
+- no duplicated copy across platforms unless requested
+- any CTA is earned and user-approved
+
+## Related Skills
+
+- `brand-voice` for source-derived voice profiles
+- `crosspost` for platform-specific distribution
+- `x-api` for sourcing recent posts and publishing approved X output