Hey guys, I bought the paid version. And for the life of me cannot make it work. I swear I am following the instructions but totally stuck. We cannot see the templates other than Openclaw, Hermes, and Claude Code. There is no Nick's Stack. However when we launch Hermes, we cannot get terminal to work -so there is no way to actually use the Hermes template. Anyone feel charitable and want to jump on a zoom with me?

Part 7 was about turning trusted knowledge into repeatable work through SOP prompts. Once those workflows existed, I needed a simple way to find them and start the right one without remembering internal names or digging through setup notes. The final piece I added was a Skill Command Registry. It is a small, human-facing reference that gives each approved workflow a plain-English activation phrase. It can also record an optional shortcut, what the workflow does, its current status, and any reminders about verification or human review. In practice, it acts like a control panel, but there is no dashboard or complicated interface. I can intentionally start a workflow by using a phrase I am likely to remember. For example, second brain capture (SBC) starts the workflow that extracts and routes source material into my Second Brain. Capturing something does not make it trusted or approved. Human review still decides what happens next. Hermes capability builder (HCB) shows me the current top three capability candidates and starts planning for the one I choose. Choosing a candidate does not authorize the build. Building still requires separate approval. That distinction matters. A memorable command starts a workflow. It does not give the workflow new powers or remove its existing safeguards. The registry does not authorize publishing, sending, spending, destructive changes, or work outside the scope I approved. Each workflow still carries its own verification steps and human approval gates. The Skill Command Registry simply makes those workflows easier to find and use intentionally. It improves the interface between me and the system, not the correctness of the result. This closes the eight-part series. It started with making an organically grown vault easier to understand. From there, I added source mapping, capture and review, confidence labels, structural validation, and SOP prompts for recurring work. The Skill Command Registry became the final human-facing layer that ties those workflows together.

Hey @Nick Vasilescu! I’ve been using Orgo for the past few days and have a question about something I believe you mentioned in one of your videos. You said agents can communicate directly with one another. Does Orgo have a built in feature that enables this? If so, how does it work?

I’ve spent 6 parts making my knowledge easier to organize, trace, review, label, and validate. All useful. But stored knowledge still doesn’t perform a recurring job by itself. Part 7 closes that gap a little. The piece I added is a small repository of SOP prompts: instructions I give an AI assistant for work I do over and over. I want to be clear about what I mean by “SOP prompt,” because it isn’t a clever line of wording or a trick phrase. It is closer to an old-school standard operating procedure. It defines who is doing the work, what the job is, what inputs it needs, the rules it has to follow, what the output should look like, how to check the work, and where a human has to sign off before anything goes out the door. The repository itself is just an index, not one giant do-everything prompt. It is a list of named jobs I can look up. Two examples from mine: one turns raw research into a discovery checklist. Another coordinates narrow specialist work with verification and approval steps built in. The shift is from typing “help me with this again” every time to having a repeatable job with defined inputs, a consistent output shape, a way to check the result, and a human review step before anything consequential happens. A few things I learned the hard way are worth saying plainly. Writing the SOP prompt down makes the work more repeatable. It does not guarantee the result is correct. The assistant still needs the right current information to work from. Stale or missing inputs can produce stale or wrong outputs no matter how well the prompt is written. Verification has to live inside the workflow itself, not happen as an afterthought. And for anything public, client-facing, paid, sensitive, destructive, or touching real infrastructure, a human still reviews it before it goes anywhere. That part is not optional, and I’m not trying to engineer it away. I also learned not to build one universal prompt for everything. Different jobs need different context and approval rules. Cramming them into one prompt makes each workflow harder to understand and maintain. I would rather keep named, separate workflows in an index where I can find and update them. When a real run exposes a missing input, rule, or check, I update the SOP.

In Part 5, I added human-assigned confidence labels to help distinguish between notes I trust, notes that need review, and notes that should not quietly become authoritative. That helped at the note level. But it raised a broader question: How do I know whether the knowledge system around those notes is structurally healthy? That is what the Second Brain Validation Report Lite is designed to examine. It is a read-only health check that produces a human-readable report. It scans for a defined set of structural warning signs without changing the underlying knowledge base. The checks look for: - required operating notes that may be missing; - unresolved or ambiguous links; - path and filename problems; - duplicate titles; - patterns that resemble secrets or sensitive values; - gaps in provenance or source information. I think of it as an instrument panel, not a truth engine. A clean run means only that the specified checks did not find matching problems at the time the report was generated. It does not prove that the content is accurate, current, complete, secure, compliant, retrieved correctly, or safe to act on. That distinction matters. A validator can tell me that a source field is missing. It cannot tell me whether the source itself is reliable. It can flag two notes with the same title. It cannot decide whether they should be merged, renamed, or intentionally kept separate. It can identify something that looks like a secret. It cannot confirm that the match is an actual credential or leak. It can find a broken link. It cannot know whether the best response is to repair it, remove it, or reconsider the surrounding note. The report gives me evidence for review. It does not give itself permission to make changes. A read-only finding should not become an automatic cleanup instruction. Some apparent problems are harmless. Some require context. Some may expose a more important issue than the scanner originally detected. The order matters too. I would address sensitive findings before cosmetic cleanup. I would not create empty notes simply to make the report look cleaner. I would use judgment on duplicate titles and broken links rather than optimizing for a cleaner-looking report.