The Mega-Prompt Wall

If you use AI to manage your personal knowledge base, you will eventually hit a wall.

I use Obsidian to run multiple databases—one for hotkeys, one for AI prompts, and several others. Initially, I tried to give my AI one massive set of instructions to handle everything. I wanted it to understand the technical rules of the software plugins I use, while also remembering the specific layout rules for each individual database.

It didn’t work. The instructions were too bloated, the AI lost the plot, and the system broke down.

But this failure was exactly what I needed. It forced me to stop treating the AI like a single brain and start treating it like a modular system. I needed a lean, pragmatic architecture. I needed a “master” instruction set that teaches the AI how the software works, and separate “sub-skills” that tell it how to handle a specific database.

More importantly, they needed to be able to talk to each other automatically. Here is how I built a bespoke system where the instructions trigger each other—preventing hallucinations, reducing prompt maintenance, and keeping the AI focused.

The Solution: Modular Instructions

To solve the context problem, I separated my instructions into two distinct layers: a Master Reference layer and a Task-Specific layer.

Here is how the architecture works under the hood:

Step 1: The Master Skill (The Rulebook)

First, I created Obsidian Bases Master Skill.md. This acts as the core rulebook.

It contains the comprehensive, raw documentation for the Obsidian plugin I use to build my databases. It contains no specific instructions about my actual databases, like hotkeys or prompts. It exists purely to teach the AI the technical syntax of the tool. I only update this file when the plugin itself receives an update.

By isolating this knowledge, we prevent the AI from confusing the tool’s mechanics with the content we want to create.

Step 2: The Database Skills (The Specifics)

Next, I created Hotkeys Database Skill.md.

This file contains the specific rules for my hotkeys database. It gives the AI targeted directives: put hotkeys in this folder, use this exact template, and name the files using this convention. If I need a new database for my AI prompts, I just create a new, separate skill file for it.

Step 3: The Trigger (The Glue)

AI agents do not natively read linked files just because a link exists in the text. They do, however, follow explicit, imperative instructions to use their system tools.

By placing the following block at the top of my specific Hotkeys skill, I force the AI to execute a setup step before it does any work:

# ⚠️ Master Skill Dependency
Before executing any instructions in this file, you MUST first read and ingest the master guidelines for Obsidian Bases located at:
`/Users/chris/Local/Knowledge/Commonplace/Bases/Obsidian Bases Master Skill.md`

Step 4: The Workflow in Action

Now, when I ask my AI to “Add a new hotkey for Premiere Pro,” the execution sequence looks like this:

1. Invocation: The AI loads Hotkeys Database Skill.md to learn how to do the task.
2. Interception: It reads the dependency block at the top and recognizes it cannot proceed yet.
3. Tool Execution: The AI pauses, reaches into my files, and reads the Master Skill rulebook.
4. Context Synthesis: It ingests the entire technical syntax from that master file into its memory.
5. Execution: Armed with both the specific rules (from the Hotkeys skill) and the technical syntax (from the Master skill), the AI safely creates the notes without breaking the database structure.

Summary

This is a lean, modular approach to writing AI instructions. You define the core rules once (the Master Skill) and reference them in your specific tasks (Hotkeys, Prompts). When you want to build a new database, you just write the specific rules for that database and paste the trigger block at the top. This design prevents silent failures and ensures the system remains scalable and resilient.