Alex Bogle

Posted on Jun 16

How I Contributed to Awesome Second Brain — And What I Learned From Getting Rejected

#opensource #ai #secondbrain #hermes

How I Contributed to Awesome Second Brain — And What I Learned From Getting Rejected

A detailed account of contributing an assembled-stack solution to an open-source comparison repo, the mistakes I made, the feedback I got, and the lessons that stuck.

What is Awesome Second Brain?

Awesome Second Brain is an open-source curated comparison of AI second-brain, memory, and knowledge systems. It is not a product. It is a decision-making resource.

The repo maps the full second-brain lifecycle — Collect, Organize, Evolve, Use, Govern — and compares tools across those stages. It covers everything from end-to-end apps like Membase and Khoj, to local workspaces like GBrain and Obsidian, to agent memory layers like Honcho and Supermemory.

The goal: help people answer "what should I use?" and "what tradeoffs am I signing up for?"

It has 200+ stars, active maintainers, and a strict contribution bar. Claims must be sourced. Metadata must be accurate. Broad claims must be narrowed to evidence.

I contributed a solution profile, setup guide, example workflow, and comparison page for an assembled stack: Hermes Agent + Obsidian + Honcho.

This is the full story of that contribution — including the parts where I got it wrong.

What I Contributed

1. Solution Profile (`solutions/hermes-obsidian-honcho.md`)

A full core profile covering:

Deployment model: Multi-component stack — Obsidian vault (local Markdown), Honcho (self-hosted or managed memory layer), Hermes Agent (local gateway), AgentMail (hosted email API)
Lifecycle coverage: Collect through Govern — how each component maps to a stage
Capabilities matrix: 10 evaluation areas with honest assessments
Strengths, limitations, best-for, not-ideal-for, tradeoffs
Official links and sources

2. Setup Guide (`setup-guides/hermes-obsidian-honcho.md`)

A step-by-step guide covering:

Architecture overview (local vs hosted components)
Prerequisites and install commands
Honcho SDK installation and Hermes integration
AgentMail SDK configuration
Full-stack verification steps
Known failure modes
Setup time estimate (~60 minutes)

3. Example Workflow (`examples/daily-email-triage.md`)

A practical scenario showing how the stack works together:

Agent checks AgentMail inbox via SDK
Categorizes emails by priority
Logs to Obsidian daily journal
Updates Honcho with contact conclusions
Replies via AgentMail SDK

4. Comparison Page (`comparisons/assembled-stack-vs-app.md`)

A decision-oriented comparison between assembled stacks and end-to-end apps:

8 evaluation dimensions (setup time, operations, inspectability, portability, cost, etc.)
"When to choose each" guidance
Common assembled stack patterns

The PR Timeline

Date	Event
June 10	Opened PR #19 with initial submission
June 10	Maintainer (@rokpiy) reviewed — rejected with detailed feedback
June 10	Revised and resubmitted
June 10	Second review — rejected again with new issues
June 16	Final fixes pushed
June 16	PR #19 merged

Two rejections. Three rounds of fixes. One merged PR.

Here is what went wrong, what I learned, and what I would do differently.

Round 1: The First Rejection

What I Got Wrong

1. Unverified implementation details presented as verified

The setup guide included commands I had not verified against official documentation. The most egregious example: a Python snippet that read ~/.hermes/config.yaml directly and a script called ~/.hermes/scripts/agentmail_cli.py — a file that does not exist anywhere in the Hermes Agent repository or documentation.

I wrote these from memory and assumption. I assumed the config lived in config.yaml because many tools use that pattern. I assumed there was a CLI script because I had seen similar patterns in other projects. I was wrong on both counts.

The maintainer's feedback was direct:

"The setup guide still presents unverified implementation details as a verified path. For example, the AgentMail verification snippet opens '~/.hermes/config.yaml' literally inside Python, and the example calls ~/.hermes/scripts/agentmail_cli.py even though that script is not defined or sourced in the guide."

2. Metadata inaccuracies in the core profile

The snapshot table had factual errors:

I listed Plastic Labs as the maintainer of Obsidian MD. Plastic Labs builds Honcho. Obsidian is made by Obsidian MD. I mixed them up.
I claimed the stack had "active public repos" across the board. Obsidian is proprietary. AgentMail is a proprietary hosted service. Only Hermes Agent and Honcho have public repos.
I listed Hermes Agent's license as Apache 2.0. It is MIT.

The maintainer:

"The new core profile still has source/maintainer and status inaccuracies: it lists Plastic Labs as Obsidian MD and says the stack has active public repos even though Obsidian and AgentMail are not being evaluated as public repos here."

3. Overbroad claims without evidence

The comparison page made sweeping claims:

"High inspectability — all data is local files and queryable databases" — but AgentMail is hosted
"Free/OSS software for core components" — but AgentMail is proprietary and has pricing
"You run servers (PostgreSQL, Redis)" — only true for self-hosted Honcho, not the managed service
"Work offline or air-gapped" — AgentMail requires internet

The maintainer:

"Some assembled-stack claims still read broader than the evidence in the PR, especially the setup guide's 'commands verified against official documentation' framing and the comparison page's generalized local-stack cost/portability/inspectability claims."

What I Fixed

Removed all unverified scripts and commands. Replaced agentmail_cli.py with official AgentMail SDK calls (client.inboxes.create(), client.inboxes.messages.send(), client.inboxes.messages.list()). Replaced the config.yaml Python snippet with proper SDK verification. Replaced pip install hermes-agent with the official curl installer.
Corrected all metadata. Fixed maintainer names, repo status, and license. Every claim now matched the official source.
Narrowed all broad claims. Every "all local" or "free" claim was qualified with "varies by component" and specific caveats for hosted services.

Round 2: The Second Rejection

Even after the first round of fixes, the maintainer found remaining issues. The same categories — unverified details, metadata, and broad claims — but more subtle this time.

The key lesson: fixing the obvious mistakes is not enough. You need to re-verify everything, including the things you think you already fixed.

I had corrected the big errors but left smaller ones. A phrase like "commands verified against official documentation" survived the first round because I was focused on the broken scripts. But that phrase was itself an unverified claim — I had not actually verified every command against the official docs at that point.

The maintainer's second review was shorter but pointed. I had been sloppy in my fixes. I patched the broken parts but did not do a full verification pass.

What I Fixed

Removed the phrase "commands verified against official documentation" entirely. If I cannot point to the exact doc page for every command, I cannot say it is verified.
Did a full verification pass — read every official doc page, checked every command, confirmed every URL, verified every maintainer name and license.
Narrowed the remaining broad claims in the comparison page — inspectability, portability, cost, operations, and offline capability all got component-specific qualifications.

The Final Fix: What Actually Got Merged

The merged PR (commit b4df09c) contained these changes across 4 files, 105 insertions, 65 deletions:

`solutions/hermes-obsidian-honcho.md` — 3 line fixes

- Company / maintainer: Nous Research (Hermes Agent), Plastic Labs (Obsidian MD), Obsidian MD (Obsidian)
+ Company / maintainer: Nous Research (Hermes Agent), Plastic Labs (Honcho), Obsidian MD (Obsidian)

- Status: Active public repos
+ Status: Mixed — Hermes Agent and Honcho have public repos; Obsidian is proprietary

- Open source: Hermes Agent is open source (Apache 2.0)
+ Open source: Hermes Agent is open source (MIT)

`setup-guides/hermes-obsidian-honcho.md` — major rewrite

Prerequisites table: removed unverified version numbers, fixed Hermes install from pip to curl
Honcho config: removed wrong config.yaml approach, replaced with hermes memory setup and ~/.hermes/honcho.json
AgentMail verification: removed config.yaml reading and agentmail_cli.py, replaced with official SDK calls
Known failure modes: fixed config path references
Added 4 new official source links

`examples/daily-email-triage.md` — SDK replacement

Replaced python3 ~/.hermes/scripts/agentmail_cli.py triage with client.inboxes.messages.list()
Replaced python3 ~/.hermes/scripts/agentmail_cli.py reply with client.inboxes.messages.send()

`comparisons/assembled-stack-vs-app.md` — claim narrowing

5 broad claims narrowed to component-specific language
Offline claim qualified with "hosted services like AgentMail still require internet"
Cost claim qualified with "hosted services have separate pricing"

What I Learned

1. Verify Before You Write, Not After

The biggest mistake. I wrote the setup guide from memory and assumption. I assumed config.yaml because many tools use that pattern. I assumed a CLI script existed because I had seen similar patterns. Neither was true.

The fix: Before writing any command or claim, open the official docs. Find the exact page. Copy the exact command. Link to the page. If you cannot find it, mark it as Unknown.

2. "Verified" Is a Claim That Itself Needs Verification

I wrote "commands verified against official documentation" in the original setup guide. The maintainer caught it. That phrase is a claim — and it was not true. I had not verified every command.

The fix: Either verify every single command against the official docs and link to each one, or do not use the word "verified." There is no middle ground.

3. Metadata Accuracy Is Not Optional

Mixing up which company makes which product (Plastic Labs = Obsidian?) is the kind of error that destroys credibility. It takes 30 seconds to check. I skipped it and it cost me a review cycle.

The fix: For every component, open the official website or GitHub repo. Confirm the maintainer name, license, and repo status. Write it down. Do not rely on memory.

4. Scope Your Claims to Your Evidence

The original comparison said "High inspectability — all data is local files." But AgentMail is hosted. The claim was too broad. The fix: "Varies by component — locally-run components are inspectable; hosted-service components depend on that service's audit surfaces."

The fix: When making a claim about a multi-component stack, ask "is this true for every component?" If not, qualify it. "Varies by component" is honest and accurate. "All data is local" is neither.

5. Read the CONTRIBUTING.md Before You Start

The repo has explicit contribution guidelines. Claims must be sourced. Metadata must be accurate. Broad claims must be narrowed. I read them after the first rejection. I should have read them before the first submission.

The fix: Before contributing to any open-source project, read the contribution guidelines. Twice. They exist for a reason.

6. Small, Accurate Contributions Beat Large, Sloppy Ones

The first version tried to do too much — setup guide, example, 7 comparison pages, capabilities. More surface area meant more places to be wrong. The final merged version is tighter and more accurate because it was smaller and more focused.

The fix: Start with the smallest contribution that delivers value. Get it right. Then expand.

7. Maintainer Feedback Is a Gift

Two rejections stung. But the maintainer was specific, fair, and actionable. Every piece of feedback pointed to exactly what was wrong and what needed to change. Without that feedback, the merged PR would have been lower quality.

The fix: When you get critical feedback, do not defend. Read it carefully. Fix what is wrong. Verify the fix. Resubmit.

The Stack Itself: What It Does

For readers who want to understand what the contribution is actually about:

Hermes Agent (MIT, GitHub) is an open-source personal AI agent runtime. It connects to model providers, runs skills, and integrates with memory and knowledge systems.

Obsidian (proprietary, obsidian.md) is a local-first knowledge vault. Notes are Markdown files on your filesystem. No lock-in.

Honcho (AGPL-3.0, GitHub) is an agent memory layer. It maintains peer cards, conclusions, and session context. It can be self-hosted (FastAPI + PostgreSQL + Redis) or used as a managed service.

AgentMail (proprietary, agentmail.to) is a hosted email API. It gives agents an inbox for receiving and sending email.

Together, they form a local-first second brain: Obsidian owns the knowledge, Honcho owns the memory, Hermes connects everything, and AgentMail brings email into the loop.

The stack is not for everyone. It requires assembling and maintaining multiple components. But for technical users who want local ownership and inspectability, it is a strong option.

DEV Community

How I Contributed to Awesome Second Brain — And What I Learned From Getting Rejected

How I Contributed to Awesome Second Brain — And What I Learned From Getting Rejected

What is Awesome Second Brain?

What I Contributed

1. Solution Profile (`solutions/hermes-obsidian-honcho.md`)

2. Setup Guide (`setup-guides/hermes-obsidian-honcho.md`)

3. Example Workflow (`examples/daily-email-triage.md`)

4. Comparison Page (`comparisons/assembled-stack-vs-app.md`)

The PR Timeline