| name | auto-opc-skill |
| description | Build and operate a one-person-company operating system around Obsidian, MCP-enabled assistants, and the repository's autoresearch loop. Use when creating a persistent Memory file, founder dashboard, action and decision trackers, transcript ingestion workflows, or a self-improving solo-business system that keeps searching for higher leverage and revenue. |
Auto OPC Skill
OPC here means one-person company, not just an operations cockpit. The system still uses a markdown vault as memory, but the real goal is sharper than note organization: help a solo operator find leverage, close revenue, reduce recurring overhead, and evolve the business every week.
Use This Skill For
- Designing an Obsidian vault that acts as the founder's operational memory
- Creating a
Memory file that onboards the assistant into the business model, offer, and constraints of a solo operator
- Setting up folders and templates for leads, clients, calls, actions, decisions, and session summaries
- Turning call transcripts into structured updates that the assistant can file automatically
- Running the repo's
autoresearch loop as a business evolution engine instead of a generic code experiment
- Writing custom instructions for Claude, Claude Projects, or Cowork so the assistant always consults the vault first and writes durable updates back
Core Model
The system has six parts:
- A markdown vault, usually in Obsidian, with a strong top-level structure
- A
Memory file that explains the operator, offer, audience, economics, tools, and rules
- A transcript source that drops raw meeting text into a predictable location
- MCP access so the assistant can read from and write to the vault and adjacent tools
- A standing instruction telling the assistant to search the vault before answering and file outcomes after important work
- The local
autoresearch loop, which repeatedly proposes, executes, measures, and keeps or discards improvements
Workflow
1. Establish the vault shape
Start with a small structure that can survive daily use:
00 Home/01 Memory/02 Pipeline/03 Clients/04 Calls/05 Actions/06 Decisions/07 Sessions/08 Templates/
Use the templates in assets/templates/home.md, assets/templates/memory.md, and the related tracker files instead of inventing the structure from scratch.
2. Write the Memory file first
The Memory file is the onboarding packet for the assistant. It should cover:
- who the operator is
- what the business does
- how the business makes money
- active offers, clients, and priorities
- target customer and acquisition channels
- toolchain and source-of-truth rules
- writing style and decision preferences
- where different outputs should be filed
If the Memory file is weak, every downstream automation degrades.
3. Define routing rules
Before enabling write access, decide where information belongs:
- leads and opportunities go to the pipeline tracker
- actions go to the action tracker
- important commitments go to the client page and the action tracker
- durable operating decisions go to the decision log
- meeting notes live under calls
- end-of-session summaries go under sessions
Keep those rules in the Memory file so the assistant reloads them every time.
4. Ingest transcripts
The transcript path can be simple:
- Fathom, Otter, Fireflies, Meet, or Zoom export
- a synced folder such as Google Drive, Dropbox, or a local vault inbox
- assistant reads the raw transcript, extracts summary, decisions, and actions
- assistant files each item into the correct notes
Do not start with a complex automation stack. A reliable folder drop is enough.
5. Configure the assistant
For Claude or Cowork, add a standing instruction equivalent to:
Before answering, search the vault for relevant notes and use them. After material meetings or work sessions, write the durable updates back to the correct notes.
This matters more than elaborate prompting. The system works because the assistant consults the vault every time.
6. Run a closed loop
Once the vault is live:
- every call adds new context
- every work session can add a summary
- every decision becomes searchable
- every action becomes trackable
The assistant improves because the knowledge base improves, not because the model changed.
7. Fuse the autoresearch loop into the business
The repository already includes a mechanical iteration engine in scripts/autoresearch-loop.sh. Use it as the one-person-company evolution loop.
The intended cycle is:
program.md defines the business goal, constraints, monetization logic, and current priorities- the vault stores durable operating memory
scripts/autoresearch-status.sh and scripts/autoresearch-next.sh summarize state and the next movescripts/autoresearch-loop.sh proposes one focused change- the result is measured, kept, or discarded
- the assistant writes the outcome back into the vault and the loop memory
This is how the system keeps moving toward revenue instead of becoming a passive second brain.
8. Optimize for money, not activity
In a one-person company, the loop should bias toward:
- better offer clarity
- faster lead response
- more consistent follow-up
- less founder context switching
- more reuse of proposals, notes, and operating playbooks
- faster discovery of bottlenecks that block revenue
Do not let the system spend all of its energy on documentation hygiene. The point is compound leverage.
Operating Rules
- Prefer plain markdown files over proprietary data stores
- Keep every durable page linked from the Home page or another stable parent
- Use one canonical tracker per object type instead of many partial lists
- Treat routing rules as part of the system, not an afterthought
- Keep human review on client-facing or irreversible actions
- Tie the loop's priorities to revenue, delivery quality, and founder time saved
- Use
program.md as the business north star for the autoresearch loop
Resources
