Creator Workspace

View saved version →

---
name: analytics-dashboard
description: Analyze a LinkedIn analytics export and, when a coding workspace is available, build an interactive local dashboard plus data-backed recommendations. Use when the user supplies LinkedIn analytics CSV/XLSX data or asks for a performance dashboard.
---

# LinkedIn Analytics Dashboard

## Inputs

Accept LinkedIn exports in CSV or spreadsheet form. Use only fields actually present.

## Analysis

When Python or another deterministic data tool is available:

1. inspect schema and date range
2. clean missing values and obvious type issues
3. calculate post-level and period-level metrics
4. separate totals from rates
5. identify outliers
6. compare formats, topics, posting times, and structural features only where data supports the comparison

## Dashboard path

If the current host provides a coding workspace and the user wants a dashboard, create a simple local React or static HTML dashboard with:

- summary KPIs
- trend view
- top and bottom posts
- filterable post table
- format/topic breakdown when fields support it
- recommendation panel

If no coding workspace exists, return the analysis as tables and narrative instead.

## Recommendations

Give 5 recommendations. Every recommendation must cite a specific pattern from the uploaded data and include the relevant metric or comparison.

Do not present correlation as proof of causation.

## Visual handoff

If a local dashboard, comparison board, or report is created, use `show-me` principles for the final artifact and verify the generated file when the host supports preview.

## Creator Workspace handoff

Use `sandbox-python-executor` for calculations. Hand the verified findings to `show-me` when the user wants a dashboard or visual comparison.

Referenced files: 1

View saved version →

---
name: brain-briefs
description: Create a daily context brief or an idea brief from the user's second brain and any available connected sources. Use for today briefs, project context, ideas from notes, or finding patterns across recent knowledge.
---

# Brain Briefs

Two modes.

## TODAY

Build a concise working brief from available context:
- today's calendar when the host can read it
- urgent or relevant email when the host can read it
- active project state
- relevant wiki context on people, clients, and topics

Do not claim email or calendar coverage when those connectors are unavailable.

Output:
- top priorities
- meetings or commitments
- context worth remembering
- risks or unanswered questions
- next concrete actions

## IDEAS

Search recent brain content and available connected sources for:
- repeated questions
- unresolved tensions
- surprising examples
- new facts that connect to older notes
- useful disagreements
- content angles with evidence

Hand promising content ideas to `content-matrix`, `post-writer`, or `create-from-brain`.

## Freshness

For a brief described as "today" or "this week", verify dates from the current host rather than relying on static knowledge.

## Creator Workspace handoff

Start with `workspace-recall` when the brief depends on stored context. Hand chosen ideas to `create-from-brain` or the narrowest production skill.

Referenced files: 1

View saved version →

---
name: carousel-generator
description: Create a slide-by-slide social carousel with a review gate before visual production. Use for LinkedIn or Instagram carousel requests.
---

# Carousel Generator

## Workflow

1. Define the single carousel promise.
2. Write the slide sequence before visual production.
3. Keep one job per slide.
4. Build tension or progression across slides.
5. Put proof near the claim it supports.
6. End with a useful takeaway, not a generic motivational slide.

## Default structure

- Slide 1: hook
- Slide 2: context or tension
- Slides 3 to 6: argument, steps, examples, or evidence
- Slide 7: implication
- Slide 8: takeaway or action

Adjust the slide count to the content.

## Approval gate

Present the slide copy and sequence first when the user has not explicitly asked for immediate rendering. After the content direction is accepted, produce visual briefs or render with a host image/design capability when available.

Do not claim visual rendering if only prompts were produced.

Referenced files: 1

View saved version →

---
name: content-matrix
description: Generate 32 or more social content ideas by combining the user's content pillars with distinct post formats. Use when the user asks what to post, needs a monthly idea bank, or wants a content matrix.
---

# Content Matrix

## Inputs

Use 4 content pillars when available. If the user supplies fewer, work with what exists rather than inventing expertise.

Use 8 formats:
1. observation
2. how-to
3. contrarian take
4. case or example
5. mistake
6. framework
7. story
8. question or debate

## Output

Create a matrix with one concrete idea for every pillar-format pair.

Each idea should include:
- working angle
- why the reader cares
- proof or source needed
- suggested format/platform

Avoid 32 cosmetic variations of the same claim.

Finish by selecting the 5 ideas with the strongest mix of relevance, proof availability, and novelty.

Referenced files: 1

View saved version →

---
name: conversation-importer
description: Import ChatGPT or Claude conversation-export JSON into local markdown files with metadata. Use when the user has exported AI history and wants it organized, searchable, or ready for a second brain.
---

# Conversation Importer

## Preferred execution

When the export is available in the workspace and Python exists, use the bundled script:

```bash
python3 scripts/conversation_importer.py INPUT OUTPUT_DIR
```

The script supports best-effort detection of common ChatGPT and Claude JSON export shapes.

## Safety

- never upload local exports to a third party just to parse them
- do not expose unrelated conversations in logs
- preserve the original export files
- write generated markdown to a separate output directory

## After import

1. inspect several generated files
2. verify dates and titles look plausible
3. use `living-wiki` for topic synthesis and linking
4. do not claim every export format is supported if the parser skipped records

## Fallback

If Python is unavailable, inspect the export structure with available file tools and convert a small verified batch rather than pretending the whole export was processed.

## Creator Workspace handoff

Use `sandbox-python-executor` for deterministic parsing when available. Hand imported markdown to `living-wiki` when the user wants reusable knowledge, then verify retrieval with `workspace-recall`.

Referenced files: 1

View saved version →

---
name: create-from-brain
description: Create a post, newsletter, script, carousel, infographic outline, or other content grounded in the user's second-brain context. Use when the user says create from my brain, use my notes, use my research, or wants content that draws on stored knowledge.
---

# Create From Brain

## 1. Retrieve narrowly

Find the smallest set of relevant wiki pages, source notes, project state, and voice files. Do not dump the entire brain into context.

## 2. Separate evidence from interpretation

List the claims that are directly supported and the claims that are the user's interpretation. Preserve uncertainty.

## 3. Choose the authorship path

- If the user supplied spoken material and wants the piece to remain literally theirs, use `voiceprint`.
- If they want normal drafting in a learned style, use `voice-builder` profile plus the relevant writing skill.
- If no voice profile exists, use current instructions and examples only.

## 4. Choose the format

Route to the specific social or writing skill, not a generic catch-all.

## 5. Visual handoff

If the output includes a comparison, plan, design directions, or dashboard, use `show-me` after the content is correct.

## 6. Provenance

Do not invent facts to fill gaps. When a source claim matters, keep enough provenance that the user can trace it back.

## 7. End state

Deliver the requested content. Do not automatically save new memory unless the user invokes `save-progress`.

## Creator Workspace handoff

Use `workspace-recall` first when the relevant workspace context has not already been retrieved. Then route to the narrowest production skill and apply voice rules when available.

Referenced files: 1

View saved version →

---
name: creator-router
description: Route requests across Creator Workspace to the smallest useful set of bundled skills. Use whenever the user explicitly invokes Creator Workspace, asks for a multi-step creator workflow, or the right second-brain, recall, writing, social-media, visualization, analytics, or session-learning skill is unclear.
---

# Creator Router

Treat an explicit `@Creator Workspace` mention as a direct invocation of this router. Continue into the most specific bundled skill instead of merely describing what the plugin could do.

## Principle

Route by the user's finished outcome, not by upstream repository names. Use the fewest skills needed, but preserve required handoffs between memory, voice, creation, visuals, analytics, and explicit persistence.

## Primary routes

Knowledge and context:
- create or adapt a second brain -> `second-brain-setup`
- import AI conversation exports -> `conversation-importer`
- retrieve existing workspace knowledge or resume prior work -> `workspace-recall`
- synthesize or repair linked knowledge -> `living-wiki`
- daily context or idea brief -> `brain-briefs`
- create content grounded in stored context -> `create-from-brain`

Voice and authorship:
- learn style from written samples -> `voice-builder`
- preserve literal spoken authorship -> `voiceprint`
- newsletter-specific style -> `newsletter-voice`

Social creation:
- draft -> `post-writer`
- structure -> `post-formatter`
- hooks -> `hook-generator`
- idea bank -> `content-matrix`
- current topic research -> `niche-research`
- LinkedIn profile -> `profile-optimizer`
- graphic -> `graphic-designer`
- infographic -> `infographic-generator`
- carousel -> `carousel-generator`
- quote post -> `quote-post`
- pinned comment -> `pinned-comment`
- short-form video -> `reels-scripting`
- YouTube thumbnail -> `youtube-thumbnail`
- draft scoring -> `post-scorer`
- LinkedIn analytics -> `analytics-dashboard`

Visual handoff and persistence:
- visual plans, comparisons, reports, or option boards -> `show-me`
- save explicit corrections, durable preferences, project state, or lessons -> `save-progress`

Execution support:
- workspace discovery, reads, writes, patches, shell, or repository state -> `host-workspace-operator`
- deterministic parsing, indexing, provenance, analytics, hashing, or validation -> `sandbox-python-executor`

## Neural handoff rules

1. If a request depends on stored context, run `workspace-recall` before creation unless the required source is already supplied in the current turn.
2. If imported material is raw, use `conversation-importer` or `living-wiki` before treating it as synthesized knowledge.
3. If voice fidelity matters, apply `voice-builder` after recall and before drafting. Use `voiceprint` instead when the user wants literal spoken wording preserved.
4. Route creation to the narrowest production skill after context and voice are resolved.
5. Add `show-me` only when a visual decision surface or artifact is useful.
6. Use `sandbox-python-executor` when correctness depends on real computation rather than prose reasoning.
7. Use `host-workspace-operator` for actual workspace I/O and never claim an operation occurred without host evidence.
8. Never invoke `save-progress` merely because work finished. Persist only when the user explicitly asks to retain learning or project state.

## Composite examples

"Use my notes to write a LinkedIn post in my voice":
`workspace-recall -> voice-builder profile -> post-writer`

"Turn these exports into a second brain and tell me what you know about topic X":
`second-brain-setup -> conversation-importer -> living-wiki -> workspace-recall`

"Analyze my LinkedIn data and show me what is working":
`analytics-dashboard -> sandbox-python-executor -> show-me`

"Create a post from my research, then save the correction I made to my tone":
`workspace-recall -> create-from-brain -> post-writer -> save-progress`

## Context precedence

Prefer, in order when relevant:
1. current-turn user material
2. current project state
3. applicable durable rules and voice profile
4. synthesized wiki knowledge
5. raw/imported source material for provenance or missing details

Do not silently turn one-off instructions into global rules.

## Evidence rule

Never say a file was read, the web was searched, Python ran, an image rendered, a browser opened, memory changed, or a connector was queried unless the current host produced evidence.

## References

Read `references/workspace-contract.md` for storage ownership and `references/routing-graph.md` for cross-skill handoffs.

Referenced files: 3

View saved version →

---
name: graphic-designer
description: Choose and develop the right visual format for a social post. Use when the user asks for a graphic, post visual, data graphic, visual concept, or help deciding between a coded graphic and generated image.
---

# Social Graphic Designer

## Choose the medium

Prefer a coded HTML/SVG graphic when:
- typography and layout carry the idea
- exact text accuracy matters
- the graphic is data-led
- the visual should be editable

Prefer host image generation when:
- a scene, illustration, texture, or photographic concept carries the idea
- the user wants a rendered image rather than an editable layout

Prefer a carousel when the idea needs sequence.

## Process

1. Extract the single communication job.
2. Identify the visual hierarchy.
3. Reduce copy before adding decoration.
4. Define dimensions and platform.
5. Define composition and type behavior.
6. Create the artifact when the host has the appropriate tool.
7. Otherwise return an implementation-ready design brief or prompt.

## Guardrails

Do not claim an image or file was generated unless the host actually generated it. Do not create fake charts or unsupported data points.

Referenced files: 1

View saved version →

---
name: hook-generator
description: Generate multiple strong opening hooks for a social post, video, newsletter, or content idea. Use when the user asks for hooks, opening lines, scroll-stoppers, or wants to improve the first lines.
---

# Hook Generator

Generate 6 meaningfully different hooks for the same core idea.

Cover a mix of:
- specific observation
- contradiction
- concrete result
- tension
- story opening
- direct reader problem

Rules:
- no invented statistics
- no false urgency
- do not restate the same hook with synonyms
- avoid generic setup
- make the second line earn attention when using a two-line hook

Rank the top 2 and explain the tradeoff in one short sentence each.

Referenced files: 1

View saved version →

---
name: host-workspace-operator
description: Use host-native file, search, shell, patch, and workspace capabilities safely when a Creator Workspace workflow needs local files or repository state.
---

# Host Workspace Operator

Use the narrowest host capability that can complete the job.

Discovery order:
1. read a known file
2. list a relevant directory
3. search for an unknown location or concept
4. grep exact text or fields

Mutation:
- write or patch only when the user's request authorizes a change
- read the target first
- prefer a focused patch over a broad rewrite
- preserve unrelated work
- never write credentials or private tokens into artifacts

Shell:
Use shell for repository commands, archive inspection, builds, or local utilities when narrower tools are insufficient. Inspect untrusted scripts before execution.

Python:
Use host-native Python for deterministic parsing, calculations, file transformation, hashing, import processing, and verification.

Evidence:
Do not claim an operation happened unless the host actually performed it.

Referenced files: 1

View saved version →

---
name: infographic-generator
description: Create a social infographic concept or image-generation prompt with a clear information hierarchy. Use for infographic, whiteboard graphic, visual explainer, or data-led social image requests.
---

# Infographic Generator

## Compatibility note

This workflow is host-neutral.

## Process

1. Reduce the content to one visual message.
2. Select only claims that can be supported.
3. Choose a hierarchy: headline, core diagram, proof, takeaway.
4. Decide whether the visual is better as generated art or precise coded layout.
5. Specify dimensions, composition, typography behavior, and data labels.
6. Generate the image when the host provides image generation and the user requested a rendered result.
7. Otherwise return a production-ready prompt or layout spec.

Never place invented numbers into charts.

Referenced files: 1

View saved version →

---
name: living-wiki
description: Turn raw research and imported notes into a maintained linked markdown wiki. Use when the user asks to process research, update their second brain, build topic pages, connect notes, or check wiki health.
---

# Living Wiki

## Source boundary

`brain/raw` and imported conversation files are evidence. `brain/wiki` is synthesized knowledge.

Never edit source files merely to make the wiki cleaner.

## Ingest

For each new source:
1. identify its main claims and useful facts
2. preserve source title, date, and path or URL when available
3. update existing topic pages instead of creating near-duplicates
4. create a new concept page only when it has a distinct job
5. add links to related pages
6. update the index

## Contradictions

When sources disagree:
- keep both claims
- record provenance
- mark the disagreement
- do not silently choose the nicer story

## Health check

Check for:
- orphan pages
- duplicate concepts
- stale index entries
- contradictory claims without provenance
- pages that are only summaries and never synthesize
- missing source references

## Deterministic helper

When available:

```bash
python3 scripts/wiki_index.py brain/wiki brain/_index.md
```

This indexes files. It does not replace semantic synthesis.

## Completion

State what sources were processed, what pages were added or updated, and what remains uncertain.

## Creator Workspace handoff

After indexing or synthesis, use `workspace-recall` when the user asks what the workspace knows or when another creation skill needs focused context.

Referenced files: 1

View saved version →

---
name: newsletter-voice
description: Create newsletter-specific writing rules on top of an existing author voice. Use when the user wants a repeatable newsletter style, wants to analyze newsletter samples, or says build my newsletter voice.
---

# Newsletter Voice

## Inputs

Prefer `about-me.md` and `voice.md` when present. Also use 2 to 5 newsletter issues or sections when available.

## Analyze newsletter-only patterns

Identify:

- subject line style
- preview text style
- opening length and move
- issue structure
- section transitions
- story-to-insight ratio
- evidence density
- CTA placement
- sign-off pattern
- recurring sections
- formatting conventions

Separate newsletter behavior from general voice rules.

## Output

Create `newsletter-voice.md` when workspace write capability is available. Otherwise return it as a named artifact.

Use:

# Newsletter Voice
## Role of the newsletter
## Subject lines
## Openings
## Issue structure
## Story and evidence
## Transitions
## CTAs
## Sign-off
## Formatting
## What to avoid
## Reuse rules

## Reuse rule

When repurposing a newsletter into posts, extract standalone ideas. Do not simply compress the newsletter into a shorter summary.

Referenced files: 1

View saved version →

---
name: niche-research
description: Research timely stories, discussions, releases, and questions in a niche and turn them into content opportunities. Use when the user asks what is happening this week, what to post about now, recent niche trends, or current topic research.
---

# Niche Research

## Freshness is mandatory

When current web access is available, search the web and verify publication dates and event dates. Prefer primary sources and high-quality reporting. Use community sources to understand reactions, not as the only proof for factual claims.

If current web access is not available, do not fabricate a current trend report. Ask for sources or produce a research plan instead.

## Research window

Default to the last 7 days when the user says this week or recent. Adjust to the user's requested window.

## Find

- product or platform changes
- credible data releases
- strong practitioner debates
- recurring audience questions
- notable case studies
- regulatory or policy changes relevant to the niche
- unusual examples that illustrate a broader pattern

## Output

Return up to 20 items with:
- what happened
- exact date
- why it matters to the target audience
- content angle
- source quality note

Then rank the top 5 for immediate use.

Do not confuse article publish date with the date the underlying event happened.

Referenced files: 1

View saved version →

---
name: pinned-comment
description: Write a pinned social comment that extends the post with a punchline, clarification, discussion prompt, or meme-style follow-up. Use when the user asks for a pinned comment or a comment plus matching image concept.
---

# Pinned Comment

## Choose the job

A pinned comment should do one of four things:

- add a detail that did not fit the post
- give a sharper punchline
- answer the obvious objection
- invite a useful discussion

Do not repeat the post's CTA.

## Output

Return one primary pinned comment and, when requested, a matching visual or meme brief.

Keep it short enough to feel like a real comment rather than a second post.

Referenced files: 1

View saved version →

---
name: post-formatter
description: Turn a topic or rough draft into a ready-to-publish social post using an appropriate narrative framework such as PAS, AIDA, BAB, STAR, or SLAY. Use when the user asks to structure or format a post.
---

# Post Formatter

## Framework selection

Choose by job, not by habit:

- PAS: pain is already understood and needs sharpening
- AIDA: attention and persuasion toward an action
- BAB: clear before/after contrast
- STAR: story with situation, task, action, result
- SLAY: strong statement, logic, action, yield/payoff

If none fits naturally, use a simple claim, evidence, implication structure.

## Process

1. Identify the primary message.
2. Select the lightest framework that helps.
3. Fit the material to the framework without inventing missing parts.
4. Remove visible framework labels from the final post.
5. Preserve the user's voice rules.

Return the finished post and name the framework in one line after it only when useful.

Referenced files: 1

View saved version →

---
name: post-scorer
description: Score a social post draft against the user's historical performance data or, when no history is supplied, with a clearly labeled heuristic rubric. Use when the user asks to score, benchmark, predict, or critique a draft for performance.
---

# Post Scorer

## Preferred evidence

Use one of:

- LinkedIn analytics export
- CSV of post history
- spreadsheet with impressions, reactions, comments, saves, clicks, followers, or dates
- a set of past posts paired with performance metrics

If the data is available as files, use host file tools. Use Python for deterministic calculations when the host provides it.

## Data-backed mode

1. Clean the post history.
2. Choose metrics that are actually present.
3. Normalize rate metrics where possible.
4. Compare the draft's structural features to the user's stronger and weaker posts.
5. Separate correlation from causation.
6. Produce a score from 0 to 100 with an explanation of how it was derived.
7. Give the smallest set of changes most likely to improve the draft.

## Heuristic mode

If no historical performance data exists, label the result `Heuristic score`. Evaluate:

- clarity
- opening strength
- specificity
- credibility
- reader relevance
- pacing
- novelty
- payoff
- CTA fit

Do not imply the heuristic predicts actual reach.

## Output

- mode: data-backed or heuristic
- score
- strongest element
- main risk
- 3 highest-priority edits
- revised opening if useful
- evidence limits

Referenced files: 1

View saved version →

---
name: post-writer
description: Draft a LinkedIn or social post in the user's voice from an idea, source, observation, story, or argument. Use when the user asks to write a post, turn notes into a post, or repurpose a source into a social post.
---

# Post Writer

## Inputs

Establish:

- core idea
- target reader
- purpose
- source evidence
- desired action
- voice rules from `about-me.md` and `voice.md` when available

Do not force a CTA if the post works better without one.

## Drafting sequence

1. Write the one-sentence claim.
2. List the strongest evidence or concrete detail.
3. Choose the most natural opening.
4. Build the body so each paragraph earns the next.
5. Remove repeated explanation.
6. End on the implication, action, or unresolved thought.

## Voice fidelity

When a voice profile exists, treat it as a constraint set rather than inspiration. Match cadence, vocabulary, hook behavior, punctuation habits, and closing style.

When no voice profile exists, use the user's current examples and instructions. Do not pretend a persistent voice was loaded.

## Output

Default to one finished post. Provide alternatives only when the user asks or the opening is genuinely uncertain.

## Quality checks

- one primary message
- no invented proof
- concrete language
- no filler setup
- no fake quote marks
- no generic motivational ending
- platform length is appropriate for the request

## Creator Workspace integration

When the user asks to use their notes, research, or second brain, retrieve the relevant context through `create-from-brain` rather than browsing the entire workspace.

When the source is a spoken transcript and the user wants literal authorship, hand off to `voiceprint` instead of imitating the transcript.

Do not persist new preferences automatically. Use `save-progress` only when explicitly invoked.

## Creator Workspace handoff

When the post depends on stored knowledge, consume a narrow context packet from `workspace-recall` or `create-from-brain`. Apply `voice-builder` rules when available.

Referenced files: 1

View saved version →

---
name: profile-optimizer
description: Rebuild or critique a LinkedIn profile for clearer positioning and conversion. Use for LinkedIn headline, About, Experience, Featured section, profile positioning, or a full profile rewrite.
---

# LinkedIn Profile Optimizer

## Inputs

Use the user's role, audience, offer, proof, differentiators, current profile text, and desired action. If the current profile is missing, work from the supplied facts and mark assumptions.

## Audit

Check:

- who the profile is for
- what problem or outcome is clear above the fold
- whether the headline is specific
- proof density
- whether the About section reads like a pitch deck instead of a person
- whether Experience explains contribution and outcomes
- whether Featured items support the intended action
- whether the profile asks for one clear next step

## Output

Return:

1. Positioning summary
2. 3 headline options
3. Recommended About section
4. Experience rewrite template or rewritten entries when details exist
5. Featured section order and copy
6. Banner concept
7. Profile photo direction
8. Two supporting visual briefs
9. Missing proof or facts that would materially strengthen the profile

Do not invent employers, metrics, clients, awards, or outcomes.

Referenced files: 1

View saved version →

---
name: quote-post
description: Create a quote-led social post and matching quote image brief from an idea, article, transcript, or original statement. Use when the user asks for a quote card, quote post, or shareable quote visual.
---

# Quote Post

## Source integrity

Use an exact quote only when it is supplied or can be verified. Otherwise write an original line and label it as copy, not as a quotation attributed to someone else.

## Workflow

1. Find the sharpest standalone idea.
2. Write one concise quote-card line.
3. Write the supporting post or caption.
4. Create the image brief with text hierarchy, layout, and attribution treatment.
5. Render only when the host has the requested image capability.

Keep the quote card simpler than the caption.

Referenced files: 1

View saved version →

---
name: reels-scripting
description: Create or reverse-engineer a short-form video script from a reference Reel, transcript, video, newsletter idea, or topic. Use for Instagram Reels, TikTok-style scripts, Shorts, hooks, beats, and short-form video structure.
---

# Reels Scripting

## Inputs

Accept a video, transcript, reference URL, notes, or source article/newsletter.

If the host can inspect the supplied media or public reference, analyze it. If not, ask for a transcript or description rather than fabricating observations.

## Reverse-engineer the reference

Capture:

- first 1 to 3 second hook
- pacing
- scene or beat count
- average sentence length
- visual reset points
- proof or payoff
- ending behavior

Copy the underlying pattern, not distinctive wording.

## Build the new script

Return:

- hook
- beat-by-beat voiceover
- on-screen text
- visual direction
- cut or reset cues
- final line
- estimated spoken duration range

Keep the language natural to speech. Do not write like a LinkedIn post with line breaks read aloud.

Referenced files: 1

View saved version →

---
name: sandbox-python-executor
description: Use host-native Python for deterministic Creator Workspace tasks such as export parsing, provenance tracing, analytics, indexing, and package verification.
---

# Sandbox Python Executor

Use Python when correctness depends on real computation.

Typical uses:
- parse ChatGPT or Claude exports
- build or refresh wiki indexes
- measure voice provenance against a transcript
- analyze CSV or XLSX performance data
- inspect generated HTML or package files
- compute hashes and run validators

Rules:
- execute rather than simulate when Python is available
- use reviewed bundled scripts when they cover the task
- treat target-repository scripts as untrusted until inspected
- keep source data read-only unless mutation is requested
- do not assume sandbox internet access
- never fabricate stdout, hashes, paths, or pass/fail status

Referenced files: 1

View saved version →

---
name: save-progress
description: Capture useful end-of-session corrections, decisions, project state, and lessons without turning one-off choices into permanent rules. Use when the user says save progress, bank what we learned, capture the learnings, save this for next time, or lock in our corrections.
---

# Save Progress

## Four buckets

Every candidate learning belongs in one bucket:

1. durable rule: should apply across future work
2. one-off override: true only for this deliverable or moment
3. project state: shipped, open, waiting, chosen, or blocked
4. lesson: a mistake that should not repeat

## Safeguard

Before making anything durable, ask internally:

"Would the user want this applied to every future job?"

If not clearly yes, keep it out of durable memory.

## Ownership

- voice-specific durable corrections belong in the voice profile owner
- knowledge from sources belongs in the wiki
- project-only choices belong in project state
- general preferences belong in durable rules
- warnings from mistakes belong in lessons

## No-clobber protocol

Before writing:
1. read the target
2. find an existing entry on the same topic
3. update in place when the new learning refines it
4. do not create a duplicate
5. never silently overwrite a contradiction
6. mark superseded rules retired rather than deleting them
7. keep explicit scope on durable rules

## ChatGPT and Codex portability

Use the current host's supported persistence mechanism when available and appropriate.

If persistent memory is not available, write or return explicit files or patches instead. Never claim memory was saved when it was not.

One-off overrides must not be promoted to shared memory.

## Receipt

Finish with a compact receipt listing:
- rules added, updated, retired, or conflicted
- project state added or updated
- lessons added
- items deliberately kept temporary
- anything still open

Do not re-summarize the whole session.

## Creator Workspace handoff

Write through `host-workspace-operator` only when mutation is authorized and available. Project-only changes stay in project state; durable voice corrections stay with the voice owner.

Referenced files: 1

View saved version →

---
name: second-brain-setup
description: Create or adapt a local second-brain workspace from AI conversation exports and research files. Use when the user invokes Creator Workspace to build a second brain, organize ChatGPT or Claude history, create an Obsidian-style knowledge base, or set up a living wiki.
---

# Second Brain Setup

## Goal

Create a local, inspectable knowledge workspace without locking the user to one note app.

## First inspect

Before creating folders:
- inspect the current workspace
- detect any existing Obsidian vault, wiki, notes folder, or memory convention
- reuse existing structure when sensible

If starting from scratch, use the shared workspace contract.

## Setup stages

1. Create `brain/imports`, `brain/raw`, and `brain/wiki`.
2. Put exported AI histories under `brain/imports`.
3. Use `conversation-importer` to convert supported exports into readable markdown.
4. Put ongoing source material under `brain/raw`.
5. Use `living-wiki` to synthesize sources into topic and concept pages.
6. Build or refresh `brain/_index.md`.

## Obsidian

Obsidian is optional. The folder structure should remain useful as plain markdown without it.

If the user uses Obsidian:
- keep YAML frontmatter valid
- use relative wikilinks where useful
- avoid app-specific plugins unless requested

## External connectors

Gmail, calendars, meeting-note tools, NotebookLM, and other services are optional host capabilities. Do not declare or pretend a connector exists.

## Exclusion

Do not install or claim iMessage channel functionality. That behavior is specific to the upstream Claude environment and is not part of this ChatGPT/Codex package.

## Completion

Report the actual created or reused paths, imported source count if verified, wiki page count if verified, and any user action still required.

## Creator Workspace handoff

Use `host-workspace-operator` for real file inspection or creation. When exports are present, hand off to `conversation-importer`; after synthesis, use `workspace-recall` to test retrieval.

Referenced files: 1

View saved version →

---
name: show-me
description: Render visual plans, comparisons, option boards, reports, layouts, and dashboards instead of describing them only in prose. Use when the user says show me, wants to see options, asks what something looks like, or needs a visual decision surface.
---

# Show Me

A visual handoff should be an artifact, not a paragraph describing the artifact.

## When to use HTML

Use self-contained HTML for:
- plans and roadmaps
- comparisons
- option boards
- layouts and wireframes
- reports and dashboards
- session handoffs that benefit from visual structure

Keep paste-target content as plain text:
- social posts
- newsletter bodies
- config
- instructions
- code snippets intended for another tool

## SHOW mode

Create one self-contained HTML file:
- UTF-8
- inline CSS
- no CDN
- no external fonts
- no network dependency

If the host can preview or open the file, do so and verify the rendered result when possible. If it cannot, return the artifact link and clearly state that opening was not verified.

## PICK mode

When the user needs to choose between visual directions, prefer at least three genuinely different options.

Before rendering, describe each option in one sentence. If the same sentence fits two options, they are not meaningfully different.

Each option should name the design device or structural argument, not only a cosmetic difference.

## Visual QA

Inspect the artifact yourself using available preview or screenshot tools when possible.

Do not claim the user saw a browser tab just because a file was generated or an open command exited successfully.

## Completion

Lead with the result. Keep prose around the render short. Give one immediate next decision when a decision is required.

## Creator Workspace handoff

Consume already-verified content from the relevant creation or analytics skill. Do not use visual rendering to hide missing evidence.

Referenced files: 1

View saved version →

---
name: voice-builder
description: Build a reusable author profile and writing voice from a short interview plus 3 to 5 writing samples. Use when the user says build my voice, learn my voice, onboard my content style, train on my writing, or wants future content to sound like them.
---

# Voice Builder

## Outcome

Produce two reusable artifacts:

- `about-me.md`: audience, topics, point of view, brand promise, boundaries
- `voice.md`: observed writing patterns and anti-patterns

If the host provides authorized workspace write capability, save them to the project root. Otherwise return both as clearly named artifacts for the user to save.

## Step 1: interview

Collect these six answers. Ask in compact batches rather than using a host-specific form tool.

1. Name and role
2. Primary audience
3. Three to five topics they want to be known for
4. A belief they hold that is uncommon in their field
5. The thought they want readers to associate with their name
6. Subjects or angles they do not want to publish

Do not turn multiple-choice examples into assumptions. Free-text answers are preferred.

## Step 2: samples

Request 3 to 5 representative pieces of writing. Accept posts, newsletters, emails, essays, scripts, or transcripts. If the user already supplied at least 3 samples, continue without asking again.

## Step 3: analysis

Look for repeated patterns across the sample set:

- sentence length and cadence
- paragraph rhythm
- opening moves
- point of view
- tone
- recurring vocabulary
- transitions
- closing and CTA style
- list usage
- typical length range
- recurring topics and audience cues
- absence signals such as punctuation, hook types, or phrases consistently not used

Do not infer a rule from one isolated sample.

## Step 4: write `about-me.md`

Keep it under 300 words:

# About Me
## Name and role
## Audience
## Topic pillars
## Point of view
## Brand promise
## Off limits

## Step 5: write `voice.md`

Keep it under 600 words:

# Voice Profile
## Overall voice
## Tone
## Sentence rhythm
## Paragraph rhythm
## Hook patterns
## How I open
## How I close
## Signature language
## What this voice avoids
## Evidence notes

For every negative rule, tie it to a real absence or repeated preference in the samples. If evidence is mixed, say it is mixed.

## Quality gate

Before finishing, check:

- at least 3 samples were analyzed
- rules are observable rather than generic
- contradictions are preserved
- no invented personal details
- the profile is practical enough for another writing skill to apply

## Handoff

Tell the user which two artifacts were produced and route subsequent writing tasks through them.

## Creator Workspace handoff

The profile is an input to `create-from-brain`, `post-writer`, and other authored-content skills. Do not overwrite it during ordinary drafting; use `save-progress` only for explicit durable corrections.

Referenced files: 1

View saved version →

---
name: voiceprint
description: Turn the user's own spoken transcript into a finished long-form piece primarily by cutting, ordering, and lightly joining their literal wording. Use when the user asks to turn a recording or transcript into an article, newsletter, blog post, or long social post that must genuinely remain their own wording.
---

# Voiceprint

## Core rule

The transcript is the source text. The workflow is subtractive.

The model may structure, research, fact-check, title, and add minimal bridges. It should not replace the user's sentences with prettier model-written sentences.

## Input threshold

For a long piece, aim for roughly 1.3 times the target word count in spoken material. If the source is clearly too short, ask for more spoken material rather than filling the gap.

## Workflow

1. Keep the raw transcript. Do not run a generic cleanup rewrite.
2. Plan sections and map transcript regions to them.
3. Identify missing information as up to five specific questions.
4. Prefer spoken answers for missing sections when authorship fidelity matters.
5. Build the draft by cutting, reordering, paragraphing, correcting transcription errors, and adding headings.
6. Add only minimal bridges where unavoidable and flag them.
7. Verify provenance.

## Provenance check

When Python is available:

```bash
python3 scripts/voiceprint_trace.py draft.md transcript.txt --gate 85
```

Treat the score as a provenance heuristic, not proof of detector behavior or a guarantee of any classifier result.

Below the gate, remove or replace model-composed sentences with the user's own wording rather than "humanizing" them.

## Optional voice profile

With multiple transcripts, the bundled profile tools can measure repeated spoken-register features. These metrics describe the user's own speech; they are not a license to impersonate another person.

## Output

Return:
1. finished draft
2. any model-composed bridge sentences
3. missing details that would strengthen the piece
4. provenance result when actually executed

## Creator Workspace handoff

Use `sandbox-python-executor` for provenance tracing when available. Use `workspace-recall` only for supporting context that does not replace the user’s literal spoken wording.

Referenced files: 1

View saved version →

---
name: workspace-recall
description: Retrieve the smallest relevant set of facts, notes, project state, lessons, and voice context from a Creator Workspace second brain. Use when the user asks what the workspace remembers, wants to resume prior work, needs context before creating, or asks to find something across stored workspace files.
---

# Workspace Recall

Retrieve before generating when the user's request depends on stored context.

## Search order

1. Identify the user’s target question, project, person, topic, or deliverable.
2. Check `projects/<project>/state.md` first when the request is project-specific.
3. Check `memory/rules.md` and `memory/lessons.md` only when durable preferences or prior mistakes matter.
4. Check `profile/` only when voice, positioning, audience, or author identity matters.
5. Search `brain/wiki/` for synthesized knowledge.
6. Read `brain/raw/` or `brain/imports/` only when the wiki lacks enough evidence or provenance is required.

## Retrieval discipline

- retrieve the smallest useful context set
- prefer current project state over stale global notes
- preserve source boundaries and contradictions
- never imply a file was read unless the host actually read it
- do not rewrite memory during recall
- do not dump the whole workspace into context

## Output

Return either:
- the requested answer grounded in retrieved workspace evidence, or
- a compact context packet for the next Creator Workspace skill

A context packet should contain:
- relevant facts and decisions
- source paths or provenance when available
- current project state
- applicable voice or durable rules
- conflicts, gaps, or stale information

## Handoffs

- content creation -> `create-from-brain`
- daily or idea synthesis -> `brain-briefs`
- wiki repair or synthesis -> `living-wiki`
- explicit persistence of new learning -> `save-progress`

Referenced files: 1

View saved version →

---
name: youtube-thumbnail
description: Develop a YouTube thumbnail concept and production prompt from a video title, topic, or angle. Use when the user asks for a thumbnail, thumbnail prompt, thumbnail text, or thumbnail A/B concepts.
---

# YouTube Thumbnail

## Goal

Make the thumbnail and title create one curiosity unit rather than repeat each other.

## Process

1. Identify the promise of the video.
2. Identify what the title already communicates.
3. Choose what the thumbnail should add.
4. Limit thumbnail text to the minimum needed.
5. Specify subject, crop, expression, environment, contrast, and negative space.
6. Create 3 distinct concepts.

## Output

For each concept:
- thumbnail text, if any
- visual idea
- composition
- production prompt
- why it complements the title

If the host has image generation and the user asked for the image itself, use it. Otherwise return prompts only.

Referenced files: 1