Everyone Should Have an OPINIONS.md

A game changer that wasn't possible without agents

If you write, build, post, or argue in public, you should have an OPINIONS.md.

This is different from an AGENTS.md, or a knowledge base. OPINIONS.md is a compact, living map of what you actually believe.

I manage mine with the Hermes agent (OpenClaw would work too) and GPT 5.5. It is a markdown file in my dotfiles, updated daily by a cron job. It reads everything I write on X and Substack, extracts durable opinions, merges them into the existing structure, and commits the result back to GitHub.

I did it as an experiment, but it turned out to be a lot more helpful than I expected. More on how I actually built it later in the post. But first let me walk you through why it’s useful.

The problem

Many of us leave a long trail of opinions across the internet. X posts, replies, quote tweets, blog posts, Substack essays, GitHub issues, podcast transcripts, YouTube transcripts, Discord messages, forum comments, internal docs.

This trail is super valuable, but it’s not something that’s easy to see, understand, or be sent to an agent for interrogation or as context. It is too long, too noisy, and chronological instead of conceptual. It mixes jokes, experiments, technical details, frustration, half formed thoughts, and actual durable beliefs.

What I want is something that reflects the essence of my opinions. A small file that says: these are the beliefs stable enough to matter.

What mine looks like

To give you a sense for what it looks like, here is my current OPINIONS.md shared as-is. If you asked me to articulate my opinions today, I could not have given you anything as good as this.

This is one of the things that weren’t possible without an agent.

# OPINIONS.md

This file is a compact map of Kun Chen's public viewpoints inferred from his public X activity and Substack posts.
It is optimized for readability and conciseness, so it consolidates repeated signals and keeps evidence links sparse.

## AI agents, orchestration, and developer tools

### Agents should be judged by useful work, not demos

Kun judges coding agents by whether they complete valuable work in messy real codebases, not by toy demos or impressive screenshots.
He prefers agents that gather evidence with search, grep, tests, and tools instead of relying on unsupported reasoning.
He accepts slower and more tool-heavy agents when they produce more trustworthy results, because wrong answers and rework cost more than latency.
He sees hallucination as an engineering and incentive problem that can be reduced by training models to admit uncertainty and by surrounding them with verification.
Evidence: x.com/kunchenguid/status/1885867478489976954, x.com/kunchenguid/status/1954225404828631469

### Agentic engineering changes the work rather than eliminating engineering

Kun thinks AI is shifting software work from hand-writing code toward steering, specification, review, orchestration, system design, and product judgment.
He expects engineers to learn agentic engineering while still understanding fundamentals well enough to control and evaluate what agents produce.
He believes AI amplifies competence and judgment, which means weak taste and weak requirements can produce more slop faster.
He expects people who keep learning and building with AI to gain leverage, while people who refuse to explore the ceiling face the highest career risk.
Evidence: x.com/kunchenguid/status/2041414813977542709, x.com/kunchenguid/status/2050720538629460407

### Requirements, tests, and review are the new bottlenecks

Kun believes code has rarely been the deepest bottleneck in software work.
The harder questions are what is worth building, what users actually need, and how to verify that the result works.
He sees tests as central to AI coding because tests encode intent and give agents a feedback loop.
He favors TDD with agents when requirements are clear, because LLMs write better tests from intent than from the implementation they just generated.
He thinks humans should review generated tests especially carefully because bad tests can bless the wrong behavior.
Evidence: x.com/kunchenguid/status/1966949744909136067, x.com/kunchenguid/status/2030858831937561041

### Human accountability must remain explicit

Kun treats AI as a tool, not a teammate or co-author.
Humans remain accountable for AI-assisted changes because they choose the goals, approve the outputs, and own the consequences.
He dislikes agents auto-adding themselves as commit co-authors because it serves vendor branding more than user trust.
He would rather source control record useful AI-assistance metadata such as model, prompt, token usage, session context, and human approval.
Evidence: x.com/kunchenguid/status/2034743250033201335, x.com/kunchenguid/status/2035453569256870288

### Good agent systems need orchestration, isolation, and fresh context

Kun thinks effective agent work requires moving from micromanaging steps to directing agents through goals, principles, measurable objectives, and review loops.
He prefers deterministic harnesses for repeated long-running loops instead of asking one context window to remember everything.
He believes agents should use fresh context windows, isolated worktrees, explicit review phases, and fix phases to reduce context rot.
He sees overnight agents as useful for measurable optimization tasks where progress can be verified and failed attempts can be discarded.
Evidence: x.com/kunchenguid/status/2040275267370041784, x.com/kunchenguid/status/2046413891857797597

### Agent-facing interfaces deserve first-class design

Kun believes tools for agents should be designed as deliberately as human UIs.
Agent interfaces should optimize token efficiency, speed, composability, compact output, reliability, and easy chaining.
He is skeptical that generic MCP surfaces or human-oriented JSON APIs are always the best interface for agents.
He sees purpose-built agent CLIs and AXI-style tools as promising because shells, pipes, and concise commands give agents efficient building blocks.
He worries that broad auto-enabled tool search can save upfront tokens while adding extra turns, search failures, and lower success rates.
Evidence: x.com/kunchenguid/status/2036175602638791047, x.com/kunchenguid/status/2041900381350117648

### CLI agents and IDE agents will coexist

Kun expects CLI coding agents and IDE-based agents to coexist because they serve different workflows.
CLI agents are scriptable, portable, composable, and useful as building blocks for automation.
IDEs provide more opinionated interactive experiences and richer visual context.
He is skeptical that GUI-only computer use is the long-term agent interface because the world can build interfaces for agents instead of forcing agents to mimic humans.
Evidence: x.com/kunchenguid/status/1944075518975857118, x.com/kunchenguid/status/1946087577192399052

### Model choice should follow task shape, not fandom

Kun is pragmatic about models and harnesses.
He sees Claude as pleasant for interactive work, while GPT or Codex can be better for non-interactive background execution, bug finding, and skill invocation.
He thinks Claude Code's popularity reflects model quality, subsidies, and lock-in more than harness quality alone.
He believes higher reasoning effort can reduce total cost on complex tasks when it avoids bad answers, correction turns, and rework.
He is wary of very large context windows and automatic memory when they add stale information, bloated context, or inefficient processes.
Evidence: x.com/kunchenguid/status/2044240037483819220, x.com/kunchenguid/status/2043771618984636593

## AI labs, markets, and openness

### Model labs should act more like infrastructure providers

Kun thinks LLM labs create the most ecosystem value by making frontier models cleaner, cheaper, faster, and more reliable.
He is skeptical when labs use model power, product bundling, or platform control to favor their own downstream apps and block competing harnesses.
He expects many downstream products to be better built by specialized ecosystem players than by model labs themselves.
He sees LLMs potentially becoming commodity infrastructure that fades into the background like power plants, internet providers, or payment rails.
Evidence: x.com/kunchenguid/status/2033999261894119844, x.com/kunchenguid/status/2050990987728798151

### AI product moats require more than a wrapper

Kun is skeptical of AI products whose moat is only a prompt over commodity models.
He thinks durable AI businesses need distribution, workflow ownership, proprietary context, customer trust, operational depth, or a superior ability to build and iterate quickly.
He believes frontier labs can temporarily make subsidy itself a moat, especially when power users receive far more compute value than their subscriptions cost.
He advises AI startups to avoid direct cash-burning competition with frontier labs and instead find narrow, defensible niches.
Evidence: x.com/kunchenguid/status/1771341403068801344, x.com/kunchenguid/status/2031173685646885335

### Open AI requires more than open weights

Kun does not equate open weights with fully open AI.
He thinks true openness also involves training data, training stack, inference stack, hardware assumptions, and reproducibility.
He sees model weights as closer to a compiled binary than source code because the training data and process are the source material compressed into the model.
He worries that centralized LLM distribution lets whoever controls the channel encode and spread a worldview.
Evidence: x.com/kunchenguid/status/1884109795176899041, x.com/kunchenguid/status/1885176573722321147

### AI evaluation needs systematic evidence

Kun distrusts screenshots and one-off anecdotes as proof of model bias, truthfulness, or coding ability.
He prefers canonical evaluation datasets, careful benchmark design, and awareness of contamination and selection bias.
He thinks telemetry from production coding tools can be misleading because users send different task types to different models.
He views harness quality as important but not a permanent moat when open alternatives can catch up.
Evidence: x.com/kunchenguid/status/1764864913573646473, x.com/kunchenguid/status/2035029157445607471

## Software engineering, craft, and process

### Great engineers create valuable outcomes

Kun defines great engineers by their ability to get valuable things built.
That requires technical depth, breadth, strategy, leadership, delivery, communication, and political skill when problems have organizational constraints.
He sees compensation as an imperfect but sometimes useful market signal of created value, not as a pure measure of greatness.
He believes senior individual contributors create leverage through technical direction, ambiguous decisions, stakeholder alignment, process repair, and helping other teams succeed.
Evidence: x.com/kunchenguid/status/1555956306875273216, x.com/kunchenguid/status/2041286279170834668

### Managers and senior engineers must create leverage

Kun believes managers earn trust because employees implicitly trust them with their careers.
Managers create value by recruiting strong people, helping existing people grow, and creating conditions where the team can do better work.
If a team needs neither hiring nor growth support, he questions whether it needs a manager.
He also believes founders and star ICs should not be forced into management or coaching roles when they create more value by playing directly.
Evidence: x.com/kunchenguid/status/1628244112796426240, x.com/kunchenguid/status/1745652997605212233

### Code quality decays without active stewardship

Kun thinks codebases naturally drift toward entropy unless senior engineers actively hold the quality bar.
He prefers review cultures that require authors to explain how changes were tested rather than making reviewers personally rediscover every bug.
He believes solo ownership can burn people out and reduce quality when collaboration, shared context, and contributor growth would be better.
He wants principal engineers to remove processes where small changes require excessive meetings and approvals.
Evidence: x.com/kunchenguid/status/1743484100516970992, x.com/kunchenguid/status/1746381160022953985

### Pull requests will evolve under agentic workflows

Kun expects pull requests to become less central as work shifts from human-written code reviewed by another human to agent-written code steered and reviewed by the human author.
He still sees PRs as useful for CI gates, release automation, metadata, and team coordination.
He does not think humans must read every line of agent-written code if they provide strong requirements, require tests and evidence, and review summaries, risks, and targeted diffs.
He believes CI remains hard to replace because local validation cannot cover every platform and environment.
Evidence: x.com/kunchenguid/status/2046369388673347633, x.com/kunchenguid/status/2046482906567295483

### Tools should make good choices easy

Kun values ergonomics because a sound architecture that is hard to use correctly still produces performance and maintainability problems.
He likes opinionated defaults when they can be centrally optimized, while preserving customization for advanced users.
He prefers terminal-centered workflows with grep, fzf, Neovim-style editing, and low visual clutter, while recognizing configuration can become a time sink.
He values reproducible environments, demos, and personal infrastructure because they turn fragile manual memory into repeatable systems.
He prefers clear ownership boundaries between tools over ideological purity about forcing everything through one layer.
He thinks frameworks and abstractions should earn their complexity by matching the actual problem shape.
He believes terminal and developer tools deserve visual craft, pacing, and polish when those details improve comprehension without stealing attention from the user's real task.
Evidence: x.com/kunchenguid/status/1946656375658160587, kunchenguid.substack.com/p/how-i-built-a-reproducible-mac-setup, kunchenguid.substack.com/p/how-i-built-a-starry-night-in-tui

## Product, startups, and organizations

### Building is easier, so judgment matters more

Kun thinks AI makes building software dramatically easier, which raises the relative importance of knowing what to build.
He wants founders to understand real problems, talk to customers, observe decisions, and seek honest feedback before validating their own idea.
He thinks good ideas start with named people who care about a real problem, not with abstract brainstorming or technology-first excitement.
He favors narrow prototypes, minimal initial scope, and assembling existing building blocks when the goal is to learn quickly.
He frames distribution as finding the people who already have the problem, not merely promoting a product.
He believes product updates often belong inside the product at the right moment rather than in generic announcement channels.
Evidence: x.com/kunchenguid/status/2045369540427890884, kunchenguid.substack.com/p/zero-to-one-handbook-for-entrepreneurial

### Idea quality depends on the builder

Kun thinks a good idea is relative to the builder's context.
The best solo-builder ideas sit at the intersection of problems the builder understands deeply, can solve with their resources, and enjoys enough to keep pursuing.
He prefers exploring multiple ideas before committing when the goal is learning and discovery.
He sees building as something he naturally does for fun and would keep doing even without financial pressure.
He also thinks large companies can give entrepreneurial engineers real zero-to-one experience, with lower financial risk and easier access to users, resources, and cross-functional partners.
Evidence: x.com/kunchenguid/status/2041234698723344451, kunchenguid.substack.com/p/zero-to-one-handbook-for-entrepreneurial

### AI enables smaller serious companies

Kun expects AI to increase individual leverage enough to make one-person and very small-team companies more viable.
He does not think every company should rebuild giant SaaS products internally just because agents can write code.
He expects many SaaS tools to remain useful, but with more interactions mediated by agents rather than direct human UI use.
He thinks future work systems need better shared context, work tracking, memory, cost control, and collaboration models for humans working with many agents.
Evidence: x.com/kunchenguid/status/2041324401166287021, x.com/kunchenguid/status/2041571735322161397

### Enterprise AI adoption needs behavior change

Kun believes many companies overestimate AI maturity because demos and casual agent usage are closer to average adoption than frontier adoption.
True adoption involves background agents, agent-built customer features, agent-run experiments, and redesigned internal review, approval, and go-to-market processes.
He thinks enterprise rollout fails when companies merely provide tools and expect usage to emerge organically.
Adoption requires education, value discovery, planning, workflow redesign, and incentive changes.
Evidence: x.com/kunchenguid/status/2046791114318086351, x.com/kunchenguid/status/2041334084648243256

### Incentives shape product quality

Kun thinks many organizational product-quality problems come from incentives that reward shipping cool things more than conversion, retention, and customer outcomes.
He believes large companies need reward systems that prioritize the main quest over internal side quests, especially when AI makes internal tool rebuilding easier.
He is skeptical of outcome-based pricing when outcomes are hard to define and attribute.
He thinks companies should optimize AI products around users, profit, and team-level customer maturity rather than token consumption alone.
Evidence: x.com/kunchenguid/status/2029243249949540363, x.com/kunchenguid/status/2034552927164244334

## Career, learning, and work

### Curiosity and compounding learning are durable advantages

Kun treats curiosity, motivation, and repeated building as more important than early specialization.
He likes the growth check of asking what a person can do this month that they could not do last month.
He thinks people should build things they find fun because enjoyment sustains effort, learning, and long-term compounding.
He thinks entrepreneurial engineers should deliberately build credibility, communication ability, customer understanding, and trust, not just technical execution skill.
He advises planning careers by identifying the end game and working backward instead of optimizing only for the next job.
Evidence: x.com/kunchenguid/status/2041276542110814628, kunchenguid.substack.com/p/zero-to-one-handbook-for-entrepreneurial

### Education should include agents and real products

Kun believes students should learn CS fundamentals but should not spend most of their time hand-writing code for its own sake.
He would rather they learn agentic engineering, system design, and how to build many real things with users.
He sees LeetCode-style preparation as something to do when target companies require it, not as the center of long-term software skill.
He thinks technical interviews need to be reimagined because current systems, especially LeetCode-heavy ones, do not work very well.
Evidence: x.com/kunchenguid/status/2041250656644964568, x.com/kunchenguid/status/2041298362000154749

### Career moves are context-dependent

Kun left big tech to build because AI timing, personal runway, family readiness, and desire for new experience aligned.
He views the move as not purely financial in expected value terms, but aligned with what he wants to do.
He warns people not to blindly copy major career moves because runway, family context, learning goals, opportunity cost, and personal preference differ.
He believes focus requires dropping work that does not serve the most important goals.
Evidence: x.com/kunchenguid/status/2041226783668994096, x.com/kunchenguid/status/2041299460941381930

### Being effective matters more than being right

Kun thinks people often overvalue being correct when the goal is to be effective.
He sees political and organizational constraints as real parts of engineering work rather than distractions from technical purity.
He prefers promotion conversations that align on a growth path rather than simply asking whether a promotion can happen immediately.
He thinks career success comes from creating value in the system as it exists while improving the system where possible.
Evidence: x.com/kunchenguid/status/1752253952740241888, x.com/kunchenguid/status/1662174745817935872

## Platforms, discourse, and trust

### Social platforms reward shallow signals

Kun believes algorithmic feeds reward hype, clickbait, mass-audience takes, and overbroad claims more easily than nuanced truth.
He thinks deep thinking is hard to distribute when shallow posts travel farther.
He prefers explainers that teach one concept at a time rather than combining multiple concepts for audiences with different background knowledge.
He expects authenticity to matter more as AI-generated content becomes common.
Evidence: x.com/kunchenguid/status/1746748560614539438, x.com/kunchenguid/status/1936848043581870085

### Platforms should compete without suppressing alternatives

Kun does not think platform fees are inherently wrong.
He objects when a platform suppresses competition by disallowing alternatives.
He sees Windows Phone as a cold-start failure in app ecosystems rather than merely a product-quality failure.
He thinks apps have abused push notifications for marketing and wants user-side intelligence to punish irrelevant senders.
Evidence: x.com/kunchenguid/status/1764936209766424674, x.com/kunchenguid/status/2048903872798925247

### Trust requires plain accountability

Kun thinks customer-impacting incidents should be answered with accountability, explanation, prevention steps, and refunds where appropriate.
He dislikes defensive minimization when users were harmed.
He is wary of exposing full agent trajectories that touched private data because they can reveal sensitive context, prompt-injected material, or internal information.
He prefers transparency when companies commercialize or significantly build on open source work.
Evidence: x.com/kunchenguid/status/2047851689697501294, x.com/kunchenguid/status/2001948072759509444

## Society and institutions

### Institutions matter because coordination creates value

Kun sees a company as a group of people creating value together that individuals could not create alone.
He thinks multi-agent systems inherit many human collaboration problems, including bottlenecks, duplicated work, diffusion of responsibility, information loss, and red tape.
He believes organizational topology and communication design can matter more than raw intelligence because smarter participants still fail under poor coordination structures.
He expects layered structures with clear roles and rich cross-tier communication to beat both bottlenecked hubs and chaotic peer meshes in many multi-agent settings.
He prefers turning intuitions about organization design into runnable simulations and comparable evidence instead of relying only on memes or stereotypes.
Evidence: x.com/kunchenguid/status/1751362665690419626, kunchenguid.substack.com/p/org-bench-lets-simulate-the-org-charts

The surprise: introspection

After I created this file for the first time, I asked the agent whether any of the opinions looked objectively wrong. That turned out to be one of the most useful interactions in the whole process.

It did not say “you are absolutely right”. It gave me extremely useful feedback. To list a few examples:

“Code has rarely been the deepest bottleneck”

This is true for many senior/product engineering contexts, but not universal.
In infra, performance, compilers, distributed systems, security, robotics, scientific computing, and gnarly legacy migrations, implementation difficulty can absolutely be the bottleneck.
Better phrasing: “In much product software, code is often not the deepest bottleneck.”

“LLMs may become commodity infrastructure like power plants”

Plausible, but not objective.
There are counterforces: brand, distribution, memory, ecosystem lock-in, safety policy, data advantage, product bundling, latency, and trust.
The “power plant” analogy is useful as a strategic warning, but it may underweight vertical integration and consumer relationship ownership.
I’d keep it, but label it as an expectation, not a fact.

“Open weights are closer to a compiled binary than source code”

Good analogy, but imperfect.
Weights are not source, but they are also not just binaries.
They can be inspected, fine-tuned, merged, quantized, distilled, and modified in ways compiled binaries generally cannot.
The stronger version is: “open weights alone are not enough for reproducibility or full open-source equivalence.”
That is much harder to argue with.

I can also ask:

• Which of these are actually falsifiable?

• Which are common consensus dressed up as personal taste?

• Which are stale?

• Which are too strong?

• Which opinions contradict each other?

It’s oddly enjoyable to find out more about myself this way.

This is platform-agnostic

I use X and Substack because that is where I currently post a lot.

The pattern generalizes to whatever platforms you use to share your thoughts, whether it’s Bluesky, Mastodon or GitHub.

The source does not matter much. The key is to separately sync each source, but consolidate opinions across.

Important filters

The most important part of the cron prompt is not “read my posts”. That part is easy.

The important part is what to leave out.

For X, the agent has to avoid overfitting to throwaway replies, jokes, dunks, or ambiguous posts without context.

For Substack, the failure mode is different. My posts often include technical walkthroughs. I do not want OPINIONS.md to become a cookbook of implementation details.

The prompt in my cron job has explicit rules:

• Extract durable opinions, principles, taste, values, critiques, predictions, tradeoffs, and recurring judgments.

• Treat technical details as evidence for underlying opinions, not content to copy.

• Ignore code snippets, commands, recipes, API usage, architecture walkthroughs, tool setup steps, debugging steps, and one-off tricks unless they reveal a broader opinion.

• Summarize technical posts at the level of what I value about engineering, tools, product, craft, constraints, trust, or organizations.

• Do not summarize technical posts at the level of how to implement the technical solution.

Without that filter, the file becomes a knowledge base. With the filter, it becomes more like my taste.

The file is allowed to reorganize itself

One detail I care about: the section structure should not be static.

The cron job preserves useful sections when they still work, but does not preserve them by inertia. After each update, it asks whether the current structure is still the clearest way to organize the opinions.

A file like this should not grow by appending forever. It should periodically reorganize itself into a better shape.

The watchdog

After the first version, I realized I could actually setup “alerts” about my opinions.

There are certain things I would really love to know about when they happen.

First, opinion drift. If I say something today that contradicts or materially refines something in OPINIONS.md, I want to know. It means when the cron job sees tension between something I just posted and an existing opinion, it would flag the old sentence, the new evidence, and a suggested action. Maybe the file is stale. Maybe the new post was contextual. Maybe I changed my mind. Those are different cases. The agent should not collapse them into one automatic edit.

Second, factual risk. When new opinions are identified and added to the file, I want the agent to check for their correctness and warns me if I said something wrong. Sometimes a valid opinion may become invalid because the world changed - I want to know when that happens too.

The cron job now has a watchdog pass that checks those things for me and would send me a message when anything’s worth my attention.

Why my agents need this

A lot of agentic work fails because the agent does not understand what I care about. So I added this to my AGENTS.md:

## Kun's Opinions

When you are working on something that would benefit from being informed by Kun's viewpoints, read ~/OPINIONS.md to understand what Kun believes.

This helps me get my agents much better aligned with my taste and beliefs.

Why I need this

I want to be extremely honest with myself and better understand my own opinions -

Did I say anything that’s objectively wrong? Did I imply something I didn’t intend to? Are my opinions changing?

Having an agent help manage this in a digestible format proved to be extremely valuable.

How to build your own

I built it over a few WhatsApp messages while the agent cloned my dotfiles, wrote helper scripts, tested them, set up the cron job, ran the first full sync, and pushed the result to GitHub.

You can get the same by telling your Hermes agent this:

Set up a daily Hermes cron job that maintains an OPINIONS.md file from my public writing and public activity.

Goal:
Create or update a repo-backed OPINIONS.md that captures my durable beliefs, changed views, recurring opinions, and meaningful refinements based on public sources I choose.

Before starting:
Collaborate with me to decide the input sources.

Ask me for any missing information, including:

1. Which public sources to use
   Examples: blog, newsletter, X/Twitter, Bluesky, Mastodon, LinkedIn, GitHub issues or comments, podcast transcripts, YouTube transcripts, RSS feeds, public talks, essays, or any other public archive.

2. How to access each source
   Examples: RSS feed URL, public profile URL, API access, export file, sitemap, transcript source, or local archive path.

3. The target repo URL.

4. Where to put the OPINIONS.md file inside that repo.

Setup requirements:

1. Clone or use the target repo locally under:
   ~/.hermes/workspaces/<repo-name>

2. Create source-specific helper scripts under:
   ~/.hermes/scripts/

   These scripts should fetch or ingest recent public items from the chosen sources.

3. Store durable sync state under:
   ~/.hermes/state/

   The job should only process new items since the last successful run.

4. Maintain the cron prompt as a source file at:
   ~/.hermes/scripts/opinions_cron_prompt.md

Cron job behavior:

1. Run daily at 3am.

2. Update OPINIONS.md with:
   - durable beliefs
   - changed views
   - recurring opinions
   - meaningful refinements to existing opinions

3. Ignore:
   - jokes
   - dunks
   - one-off reactions
   - weak or ambiguous signals
   - context-specific comments that should not become durable beliefs
   - content where the author is quoting, summarizing, or steelmanning someone else rather than expressing their own view

4. Preserve uncertainty.
   If a source item suggests a possible view but does not establish a durable opinion, do not add it as a belief.
   At most, mention it in the run summary as a weak signal.

5. Commit and push changes to the repo only when OPINIONS.md changed.

6. Deliver the run summary back to this chat.

OPINIONS.md watchdog:

Add a watchdog that always runs, even when there are no new source items.

The watchdog should do two things:

1. Opinion drift detection

   Compare new source items against existing and proposed OPINIONS.md.

   Flag only real tension, contradiction, or meaningful refinement of durable opinions.

   Prefer calling something a “refinement” instead of a “contradiction” unless the old and new views cannot both be true.

2. Factual-risk detection

   Scan OPINIONS.md for:
   - factual scaffolding
   - market, model, or product comparisons
   - causal claims
   - predictions
   - time-sensitive claims
   - claims that may become stale as the world changes

   Use targeted web checks for high-risk claims.

   Do not flag pure value judgments or subjective opinions.

Watchdog noise control:

1. Deduplicate watchdog warnings using:
   ~/.hermes/state/opinions-watchdog.json

2. Use a stable hash based on:
   - warning type
   - OPINIONS.md claim or section
   - source item or evidence URL

3. Do not repeat warnings already reported unless new evidence materially changes the warning.

4. Never block OPINIONS.md updates solely because watchdog warnings exist.

Cron configuration:

Create or update a Hermes cron job with:

- schedule: 0 3 * * *
- delivery: origin
- workdir: the local repo path under ~/.hermes/workspaces/
- enabled toolsets:
  - terminal
  - file
  - skills
  - code_execution
  - delegation
  - web
- relevant skills, if available, for the selected sources and git workflow

Verification:

After creating or updating the job, verify:

1. The cron job exists and is enabled.
2. The schedule is 0 3 * * *.
3. The workdir points to the local repo.
4. The web toolset is enabled.
5. The cron prompt was persisted correctly.
6. The watchdog state path is present:
   ~/.hermes/state/opinions-watchdog.json
7. The prompt requires the watchdog to run even when there are no new source items.
8. The prompt contains the final-response contract below.

Final cron output contract:

Every run summary must include:

1. Sources checked.
2. Number of new source items processed.
3. Whether OPINIONS.md changed.
4. Whether changes were committed and pushed.
5. Counts for:
   - drift warnings
   - factual-risk warnings
   - deduped or skipped repeat warnings

If warnings exist, include each warning with:

- type
- confidence
- claim or section
- source item or evidence URL checked
- suggested human action

If no warnings exist, say exactly:

No opinion drift or factual-risk warnings found.

Get an OPINIONS.md file created for yourself today - you won’t regret it.