agentleFS
cellinlabcellinlab/cell-skills/skills/opc-case-research/SKILL.md

opc-case-research

Skill29 starsChanged 7 months agoMITView on GitHub

Systematic public-information research for OPC, super-individual, creator IP, and one-person business cases, with Chinese outputs focused on content strategy, IP positioning, channel strategy, business models, timelines, and replicable lessons. Use when Codex needs to research a named person, creator brand, or one-person company case; produce a case brief or structured report; map sources and evidence; compare facts versus inferences; or turn scattered public materials into a reusable research deliverable.

The file

Show its rules and text

We split this skill into the rules it gives an agent

30 rules. About 0 are common, 27 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈27

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to research a specific person, creator brand, or one-person business case as an "OPC / super-individual / creator IP" …

    line 11
  2. Distinctive:

    If the request is only a fast initial screen, do not load every reference file.

    line 29
  3. Distinctive:

    Treat these as the input contract:

    line 33
  4. Distinctive:

    If the user does not specify otherwise, assume:

    line 44
  5. Distinctive:

    Prefer source types in this order:

    line 74
  6. Distinctive:

    Read references/search-playbook.md when constructing search queries, sampling plans, or source maps.

    line 80
  7. Distinctive:

    Do not jump straight into opinions.

    line 84
  8. Distinctive:

    Read references/research-standard.md for the full checklist and evaluation rules.

    line 109
  9. Distinctive:

    Every important point should be marked as one of:

    line 113
  10. Distinctive:

    When in doubt, downgrade confidence instead of overstating certainty.

    line 119
  11. Distinctive:

    Use cautious language for:

    line 121
  12. Distinctive:

    Read references/evidence-schema.md when building evidence tables or appendices.

    line 129
  13. Distinctive:

    Default to a minimum evidence slice with 6-12 rows or bullet-equivalents that support the most important claims across:

    line 135
  14. Distinctive:

    If the user did not ask for tables, the evidence slice can be a compact appendix or a short "evidence snapshot" section instead of a full …

    line 143
  15. Distinctive:

    When evidence is weak, incomplete, or highly indirect:

    line 147
  16. Very specific:

    keep a to verify next list if the case is still worth researching

    line 152
  17. Very specific:

    Read references/report-template.md before drafting a full report.

    line 188
  18. Very specific:

    Use the copyable templates in assets/ when the output should become a reusable document or table.

    line 189
  19. Distinctive:

    use private or non-public information

    line 208
  20. Distinctive:

    When information is weak, say so clearly and narrow the claim.

    line 214
  21. Distinctive:

    Read for the full SOP, evidence rules, deliverables, quality bar, and uncertainty handling.

    line 219
  22. Distinctive:

    Read for search query patterns, source mapping, verification rules, and sampling.

    line 221
  23. Distinctive:

    Read for field definitions for evidence, timeline, content samples, and business model tables.

    line 223
  24. Distinctive:

    Read when drafting a standard long-form report.

    line 225
  25. Distinctive:

    Use when creating a short case brief.

    line 227
  26. Distinctive:

    Use when creating a full report draft.

    line 229
  27. Distinctive:

    Use when creating the evidence table.

    line 231
  28. Distinctive:

    Use when creating the timeline table.

    line 233
  29. Distinctive:

    Use when creating the content sampling table.

    line 235
  30. Distinctive:

    Use when creating the business model table.

    line 237

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OPC Case Research

Overview

Use this skill to research a specific person, creator brand, or one-person business case as an "OPC / super-individual / creator IP" example.

Default to:

  • public information only
  • Chinese output
  • single-case research
  • emphasis on content strategy, IP positioning, and business model
  • explicit separation of facts, inferences, and unknowns

Quick Start

  1. Confirm the target and scope. If the user did not specify depth, use the standard mode.
  2. Build a base profile and source map before writing conclusions.
  3. Build the timeline before interpreting strategy or causality.
  4. Analyze content system, IP positioning, channels, and business model together.
  5. End with replicability analysis instead of generic praise.

If the request is only a fast initial screen, do not load every reference file. Read only what is needed.

Default Inputs

Treat these as the input contract:

  • Required: target person, brand, or case name
  • Optional: focus areas such as content, IP, business model, channels, key decisions, or methods
  • Optional: depth
    • quick: short case brief
    • standard: structured research output
    • deep: standard output plus evidence tables, samples, and estimates
  • Optional: time range
  • Optional: comparison target

If the user does not specify otherwise, assume:

  • use public information
  • write in Chinese
  • prioritize content strategy, IP building, and monetization
  • analyze one case at a time
  • include a minimum evidence slice in standard and deep outputs

Workflow

1. Scope the Request

Resolve only the ambiguity that blocks the work. If the target is clearly identifiable, start immediately.

Set the working mode:

  • quick: decide whether the case is worth deeper study
  • standard: produce the default structured case study
  • deep: add evidence tables, sampling, and cautious estimates

2. Build the Base Profile and Source Map

Collect:

  • identity labels
  • platform presence
  • official pages or landing pages
  • visible business entry points
  • likely primary and secondary sources

Prefer source types in this order:

  • A: first-party statements, official pages, original program or event pages
  • B: mainstream media, platform profile pages, databases, partner pages
  • C: reposts, forums, summaries, comments, only for leads

Read references/search-playbook.md when constructing search queries, sampling plans, or source maps.

3. Build the Timeline First

Do not jump straight into opinions. Build an event sequence first.

Minimum expectations:

  • quick: 5+ meaningful nodes
  • standard: 10+ nodes
  • deep: 10-20 nodes plus notes on why each node matters

Track:

  • role shifts
  • platform shifts
  • format shifts
  • commercialization upgrades
  • major public launches or collaborations

4. Analyze the Four Core Layers

Analyze these together, not in isolation:

  1. Identity and positioning
  2. Content system and channel strategy
  3. Business model and monetization structure
  4. Key decisions, turning points, and path evolution

Read references/research-standard.md for the full checklist and evaluation rules.

5. Classify Evidence Carefully

Every important point should be marked as one of:

  • fact
  • inference
  • unknown

When in doubt, downgrade confidence instead of overstating certainty.

Use cautious language for:

  • revenue structure
  • team size
  • conversion assumptions
  • audience profile assumptions
  • operational scale

Read references/evidence-schema.md when building evidence tables or appendices.

6. Build a Minimum Evidence Slice

Even in standard mode, do not leave evidence fully implicit.

Default to a minimum evidence slice with 6-12 rows or bullet-equivalents that support the most important claims across:

  • identity or self-positioning
  • timeline
  • content or IP
  • channels
  • business model

If the user did not ask for tables, the evidence slice can be a compact appendix or a short "evidence snapshot" section instead of a full spreadsheet.

7. Shrink Claims When Public Information Is Thin

When evidence is weak, incomplete, or highly indirect:

  • narrow the scope instead of compensating with confident writing
  • separate confirmed facts, best-effort inferences, and unknowns
  • reduce the depth of business-model claims first
  • keep a to verify next list if the case is still worth researching

A smaller but more reliable output is better than a complete-looking report built on speculation.

8. Produce the Right Deliverable

Choose the smallest deliverable that still answers the user.

For quick, produce:

  • one-line positioning
  • identity tags
  • main platforms
  • visible monetization entry points
  • 3-5 reasons the case matters
  • open questions

For standard, produce:

  • case brief
  • source map summary
  • timeline
  • content and IP analysis
  • channel analysis
  • business model analysis
  • evidence snapshot or minimum evidence slice
  • replicability analysis
  • limitations and unknowns

For deep, add:

  • full evidence table
  • content sampling table
  • business model table
  • estimate disclosures when needed

Read references/report-template.md before drafting a full report. Use the copyable templates in assets/ when the output should become a reusable document or table.

Output Requirements

Always aim for:

  • Chinese writing
  • research tone, not fan tone
  • visible structure
  • evidence awareness
  • at least a small evidence trail for the main claims
  • explicit dates or time ranges when claims depend on time
  • direct linkage between content strategy, channel choice, and business model
  • actionable takeaways for people studying super-individual paths

Hard Rules

Do not:

  • use private or non-public information
  • present unverified claims as facts
  • invent revenue, team, or deal details
  • turn gossip into business analysis
  • hide uncertainty behind confident phrasing

When information is weak, say so clearly and narrow the claim.

Resource Map

  • references/research-standard.md
    • Read for the full SOP, evidence rules, deliverables, quality bar, and uncertainty handling.
  • references/search-playbook.md
    • Read for search query patterns, source mapping, verification rules, and sampling.
  • references/evidence-schema.md
    • Read for field definitions for evidence, timeline, content samples, and business model tables.
  • references/report-template.md
    • Read when drafting a standard long-form report.
  • assets/case-brief-template.md
    • Use when creating a short case brief.
  • assets/research-report-template.md
    • Use when creating a full report draft.
  • assets/evidence-table.csv
    • Use when creating the evidence table.
  • assets/timeline-table.csv
    • Use when creating the timeline table.
  • assets/content-sample-table.csv
    • Use when creating the content sampling table.
  • assets/business-model-table.csv
    • Use when creating the business model table.

Not for This Skill

This skill is not for:

  • celebrity gossip
  • private intelligence gathering
  • legal, financial, or investment due diligence
  • unsupported claims about real income or private operations

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.