Xgqq

XGQQ Obsidian Second Brain

Create a portable, user-owned Obsidian knowledge system. Treat Obsidian as the Markdown interface and the active AI agent as an authorized maintainer, never as the owner of the data.

Interpret the request

• Treat XGQQ and /XGQQ as explicit text triggers.
• If the trigger has no path, ask only for the target Vault path or whether the user wants an exportable ZIP.
• Resolve every script path relative to the directory containing this SKILL.md; do not depend on vendor-specific environment variables.
• Use Python 3.10 or newer. Prefer python, then use the host's available Python 3 launcher.
• Use one of four modes:
  • Initialize: create a new or empty accessible Vault.
  • Adapt: add missing structure to an accessible existing Vault without overwriting files.
  • Validate: inspect and report without writing.
  • Export: create a portable ZIP when the requested local path is unavailable to the current runtime.

Read references/architecture.md before initializing, adapting, or exporting. Read references/interview.md only when collecting user context or creating the first real project.

Select direct or export execution

Use direct execution only when the current runtime can resolve and access the supplied path and the user has authorized work there.

Use export execution when the agent runs in a cloud VM, container, remote sandbox, or other environment that cannot access the user's local path. Do not reinterpret a Windows path such as D:\Notes as a relative Linux path and do not claim a local Vault was changed.

For export execution, run:

python scripts/export_vault.py <output-zip>

Return the ZIP for the user to download and extract. Report that onboarding and future edits must occur after the Vault is available to a filesystem-capable agent.

Preview before writing

1. Resolve the target path to an absolute path.
2. Inspect only the root and .obsidian/; do not recursively read the whole Vault.
3. Distinguish an Obsidian application directory from a Vault directory. Never scaffold into a directory containing Obsidian.exe, resources/app.asar, or Contents/Resources/app.asar.
4. Run scripts/init_vault.py <vault-path> without --apply.
5. Report files that would be created and existing files that would be preserved.
6. Obtain confirmation before applying to an existing non-empty Vault. A direct request to initialize a new empty path is sufficient authorization to create the scaffold.

Do not install software, Obsidian plugins, AI-client integrations, MCP servers, REST APIs, sync services, or automation.

Apply the scaffold

Run:

python scripts/init_vault.py <vault-path> --apply

The script creates missing files only. Never add an overwrite flag or silently replace an existing file.

For an existing file that needs a user-approved merge:

1. Explain the exact fields or rules that need changing.
2. Save the original under Logs/Backups/<timestamp>/<relative-path>.
3. Patch only the approved parts.
4. Preserve unrelated content and formatting.

Do not move or delete existing notes during bootstrap. Preserve existing client configuration, plugin state, and hidden directories unless the user separately authorizes a change.

Onboard the user

After scaffolding, offer the onboarding interview. If accepted:

1. Ask exactly one question per turn.
2. Write only confirmed information.
3. Keep unknown fields explicitly pending; never infer identity, goals, preferences, strengths, or weaknesses.
4. Store stable personal context in Profile/, not in instruction files.
5. Keep one current primary goal in Profile/Goals.md.
6. Create the first project by copying Projects/_template/; never modify the template to hold user-specific data.
7. Give the project one current primary objective and use Inputs → Process → Outputs → Feedback.

Follow the field mapping and question order in references/interview.md.

Maintain boundaries

• Operate only inside the target Vault or the explicitly requested export path.
• Keep Markdown UTF-8 and use Obsidian [[wikilinks]].
• Preserve original URL, author, publication date, and access date for external sources.
• Separate verified facts, existing summaries, current inferences, and open questions.
• Never place passwords, API keys, recovery codes, or tokens in the Vault.
• Search first and read the smallest relevant set; never recursively load the whole Vault for context.
• Do not publish, send messages, connect accounts, or create scheduled jobs without separate authorization.
• Do not claim this scaffold is a strict implementation of Andrej Karpathy's LLM Wiki. It is a broader local Markdown workflow inspired by local-first knowledge systems.

Validate completion

For a direct Vault, run:

python scripts/validate_vault.py <vault-path> --full

Resolve all errors before declaring completion. Treat warnings as review items rather than silently changing user-owned state.

Report:

• the execution mode and resolved accessible path, or the exported ZIP path;
• files created and existing files preserved;
• validation errors and warnings;
• whether onboarding and the first project were completed;
• the next smallest action;
• any client or sandbox limitation that prevented direct local access.