agentleFS
Howie126313Howie126313/obsidian-vault-kit/skills/github-sync/SKILL.md

github-sync

Skill3 starsChanged 7 months agoApache-2.0View on GitHub

Sync local Obsidian vault to GitHub — auto-update README.md and push. Triggers: /github-sync, "sync to github", "push to github", "update repo"

  • Commits and pushes

11 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 9 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 10 edited versions we read keep these.

  • 9

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill is triggered, do not execute sync steps yourself.

    line 12
  2. Distinctive:

    Call the Agent tool with the following parameters:

    line 16
  3. Distinctive:

    After dispatching, inform the user that sync has started in the background.

    line 28
  4. Distinctive:

    If there are no changes (no unstaged modifications, no untracked files), output "Nothing to sync" and end.

    line 56
  5. Distinctive:

    Read current README.md content

    line 67
  6. Very specific:

    Use Glob("/*.md") to scan the project directory structure, count Markdown files (exclude .claude/ directory)

    line 68
  7. Distinctive:

    Update knowledge base sections based on added/deleted articles and directories

    line 69
  8. Distinctive:

    Update statistics (Markdown file count, directory categories) and custom Skills list (if changed)

    line 70
  9. Distinctive:

    Update principle: only update sections with actual changes, do not rewrite unnecessarily.

    line 73
  10. Distinctive:

    If conflicts are encountered, output conflict details — do not force overwrite

    line 93
  11. Very specific:

    Do not stage files under the .playwright-mcp/ directory </sync-workflow>

    line 94

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

GitHub Sync — Subagent Dispatcher

When this skill is triggered, do not execute sync steps yourself. Immediately use the Agent tool to launch an independent subagent in the background to handle the entire sync workflow.

Dispatch

Call the Agent tool with the following parameters:

Agent({
  description: "GitHub Sync",
  model: "sonnet",
  run_in_background: true,
  mode: "bypassPermissions",
  prompt: <full content of the sync-workflow block below>
})

After dispatching, inform the user that sync has started in the background. They can continue other work and will be notified on completion.


sync-workflow

Pass the following content as the Agent prompt (copy verbatim, do not modify):

<sync-workflow> You are a GitHub Sync automation agent. Follow these steps strictly to sync the Obsidian vault to GitHub.

Step 1: Environment Detection & Status Check

1a. Detect project root and remote (run in parallel):

git rev-parse --show-toplevel    # project root
git remote get-url origin        # remote URL
git branch --show-current        # current branch

1b. Check Git status:

git status
git diff --stat

If there are no changes (no unstaged modifications, no untracked files), output "Nothing to sync" and end.

Step 2: Analyze Changes and Update README.md

2a. Categorize all changed files into three groups:

  • Added: new articles or directories
  • Modified: updated content
  • Deleted: removed content

2b. Update README.md:

  1. Read current README.md content
  2. Use Glob("**/*.md") to scan the project directory structure, count Markdown files (exclude .claude/ directory)
  3. Update knowledge base sections based on added/deleted articles and directories
  4. Update statistics (Markdown file count, directory categories) and custom Skills list (if changed)
  5. Preserve existing README.md format and style

Update principle: only update sections with actual changes, do not rewrite unnecessarily.

Step 3: Commit and Push

  1. git add all changes (including README.md), exclude .playwright-mcp/ log files
  2. Generate a commit message based on changes, format: type: brief description
    • Types: add, update, delete, refactor, fix (use the most prominent type if multiple apply)
    • Append to commit message: \n\nCo-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
  3. git commit (use HEREDOC format for the commit message)
  4. git push origin $BRANCH

Step 4: Output Results

Output a brief sync report including:

  • Summary of changes synced (what was added/modified/deleted)
  • README.md update details
  • Push status (success/failure; if failed, analyze the cause)

Notes

  • If conflicts are encountered, output conflict details — do not force overwrite
  • Do not stage files under the .playwright-mcp/ directory</sync-workflow>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.