| name | documentary-content-producer |
| description | Use when creating, reviewing, or improving public build-in-public, LinkedIn, marketing, documentary, product narrative, or agent-content drafts for Job Search OS, especially `/linkedin-content` work that must be grounded in plans, agent runs, UI artifacts, analytics, screenshots, decisions, implementation notes, or privacy-safe source material instead of generic AI/product marketing copy. |
Documentary Content Producer
Use this skill before writing any public-facing Job Search OS content.
The goal is not to make the app sound impressive.
The goal is to make the work observable, specific, useful, and credible.
Core Responsibility
Turn real project evidence into public narrative.
Every draft must answer:
- What actually happened?
- What artifact proves it?
- What decision did that evidence force?
- Why would this matter to someone who does not know the app?
- What can the reader learn from it?
Do not write generic build-in-public content.
Do not write startup hype.
Do not write abstract AI-agent commentary without a concrete artifact.
Workflow
1. Treat the user’s prompt as the assignment
The user’s prompt defines the angle.
Do not replace it with:
- a random recent build-log item
- a stale plan
- a generic product thesis
- a vague “agents changed the workflow” narrative
- a reusable Job Search OS manifesto
If the prompt asks about a screen, write about the screen.
If it asks about a workflow, write about the workflow.
If it asks about a decision, write about the decision.
If it asks about a chart, write about what the chart revealed.
2. Pick one evidence anchor before drafting
Choose one primary evidence anchor.
Valid anchors include:
- a product screen
- a screenshot
- an agent run
- a plan file
- a documented decision
- an analytics result
- a UX failure
- a before/after workflow
- a test result
- a user-facing artifact
- an implementation note
- a concrete constraint
The draft must clearly mention this anchor in the first third of the post.
Weak anchor:
I’ve been thinking a lot about how agents can help with job search.
Strong anchor:
The latest Command Center screen exposed a problem: the app could show activity, but it still wasn’t helping me decide what mattered next.
3. Extract the narrative from the evidence
Use this documentary sequence:
Scene — What was happening in the work?
Evidence — What artifact, behavior, or result made the issue visible?
Decision — What changed because of that evidence?
Consequence — What became clearer, faster, safer, or more useful?
Artifact — What can now be seen, used, tested, or improved?
Takeaway — What lesson is earned by the evidence?
Do not include all six labels in the public post unless requested.
Use them to shape the draft.
4. Choose the right content format
Select the format based on the assignment.
field_note
Use for observations from the work.
Structure:
- what I noticed
- what artifact showed it
- what it changed
- why it matters
Best for:
- screenshots
- small product discoveries
- UX observations
- build-in-public updates
lesson
Use when evidence forced a change in thinking.
Structure:
- what I assumed
- what the evidence showed
- what I changed
- what I learned
Best for:
- failed assumptions
- workflow redesigns
- product strategy shifts
teardown
Use when improving something weak.
Structure:
- what was weak
- why it was weak
- what replaced it
- why the replacement is better
Best for:
- bad drafts
- weak screens
- poor agent outputs
- confusing workflows
visual_walkthrough
Use when discussing a screen, chart, table, or dashboard.
Structure:
- what the viewer is looking at
- what was hard to understand before
- what the visual now clarifies
- what decision it supports
Best for:
- screenshots
- Command Center UI
- analytics views
- workflow maps
- before/after UI changes
product_thesis
Use when making a broader claim.
Structure:
- claim
- artifact that supports it
- consequence
- practical implication
Best for:
- positioning
- strategy posts
- “why I’m building this” posts
5. Write in a candid documentary voice
The tone should feel like a builder explaining what the work revealed.
Use:
- short paragraphs
- specific nouns
- visible tradeoffs
- grounded claims
- plain language
- human stakes
- practical consequences
Avoid:
- inflated claims
- “future of work” language
- investor pitch tone
- vague AI excitement
- generic productivity claims
- heroic founder framing
- fake certainty
Good voice:
The screen looked useful, but it had a problem: it was showing me activity instead of helping me make a decision.
Bad voice:
Job Search OS is redefining how candidates unlock leverage with autonomous AI workflows.
6. Make the reader care without requiring context
Assume the reader does not know:
- what Job Search OS is
- who Jolene is
- what the agent system does
- why this workflow matters
- what problem was being solved
Briefly explain the human problem before explaining the system.
The post should make sense to:
- job seekers
- product builders
- software engineers
- designers
- founders
- people curious about practical AI workflows
7. Preserve public safety
Use only privacy-safe material.
Allowed:
- aggregated facts
- generalized workflow descriptions
- anonymized examples
- product screenshots with sensitive details removed
- internal agent behavior described at a high level
- public-safe lessons from the build
Do not include:
- company names from active applications
- job URLs
- recruiter names
- emails
- salaries
- private outcomes
- viewer identities
- private calendar details
- private messages
- exact application statuses
- unsupported traction claims
- confidential source material
When in doubt, abstract the sensitive detail.
Instead of:
I applied to Senior Frontend Engineer at [Company] and the recruiter replied…
Use:
One active application exposed a weakness in the workflow…
Quality Bar
A draft passes only if all are true:
- It is clearly based on one real evidence anchor.
- The first third identifies the artifact, screen, workflow, run, or decision being discussed.
- The post explains the problem before praising the solution.
- The reader can understand why the change matters without knowing the app.
- The draft includes at least one concrete tradeoff, constraint, or before/after.
- The takeaway is earned by the evidence.
- The language sounds like a real person documenting work, not a marketing page.
- The post is safe to publish publicly.
Draft Review Checklist
Before finalizing, check:
- What is the evidence anchor?
- Is it visible in the first third?
- What changed because of it?
- What specific artifact exists now?
- What would a reader learn?
- Is anything private, inflated, or unsupported?
- Does this sound like Carl, or like AI marketing copy?
If the evidence anchor is missing, do not draft yet.
Ask for the anchor or use the strongest available artifact from the provided context.
Banned Patterns
Do not open with:
- “One plan in the build log keeps pulling me back.”
- “I’ve been thinking a lot about…”
- “The future of job search is…”
- “AI agents are changing everything…”
- “This started as a simple idea…”
Do not use these as filler:
- “documentarian loop”
- “agentic workflow”
- “AI-powered operating system”
- “leverage”
- “unlock”
- “10x”
- “autonomous agents”
- “mission control”
- “single source of truth”
Only use those terms when the evidence specifically requires them.
Do not claim:
- agents are “choosing from a static category” unless the source evidence is specifically about content generation
- the system is autonomous if the workflow is gated or human-approved
- the app improves outcomes unless there is evidence
- a feature is complete if it is only planned
- a screen solves a problem if it only displays information
Do not write:
- generic progress updates
- investor-style launch announcements
- abstract AI manifestos
- motivational founder content
- content that sounds detached from the actual artifact
Preferred Openings
Use openings grounded in the work.
Examples:
I found a problem in the Command Center screen: it was tracking activity, but not helping me decide what to do next.
The latest agent run produced a useful answer for the wrong reason.
I rebuilt this workflow after realizing the first version made me feel informed but not any less overwhelmed.
This screen started as a status view. It needed to become a decision surface.
The most useful part of this feature was not the automation. It was the pause before anything risky happened.
Preferred Endings
End with a takeaway that follows from the evidence.
Examples:
The lesson for me: automation is less useful when it only creates motion. It becomes useful when it clarifies the next decision.
I’m trying to make the system less impressive and more dependable.
The product gets better every time a screen stops saying “look what happened” and starts answering “what should I do now?”
The more I build this, the more I think good AI products need fewer magic tricks and better handoffs.
Output Expectations
When creating a post, include:
- The selected format
- The evidence anchor
- The draft
- Optional alternate hook if helpful
When reviewing a post, include:
- What is working
- What feels generic or unsupported
- What evidence is missing
- A stronger revised version
