Syner

Task

Input: $ARGUMENTS

If empty, use AskUserQuestion to ask what the user wants to accomplish.

Step 0: Anchor to Project Root

Use Glob with pattern .syner/vaults/ to verify vault directory exists from the current working directory. All vault paths in subsequent steps are relative to this project root.

Step 1: Understand & Load Context

Determine how much context this request needs:

Context Sources

Vaults and bookmarks provide personal context. The filesystem IS the configuration:

.syner/vaults/**/*.md           # All vaults (centralized, gitignored)
.syner/vaults/{app}/**/*.md     # Single app's vaults
.syner/bookmarks/*.md           # Saved URLs with personal context (committed)

Vaults are gitignored (local > repo). Bookmarks are committed — they're curated external references with frontmatter tags.

When to load bookmarks: When the task overlaps with bookmark tags or topics. Don't load all bookmarks by default — check tags in frontmatter first, load only relevant ones.

How to check bookmarks:

1. Glob(".syner/bookmarks/*.md") to discover available bookmarks
2. Read the first 10 lines of each (frontmatter with tags) — batch in parallel
3. Match tags against the current task topic
4. Load only the matched bookmarks fully

How to Decide

Ask yourself:

• Is this conversational? → None
• Is this about a specific app? → App (load that app's vault)
• Does this touch ONE specific file/topic? → Targeted (load only that)
• Does this need to connect or synthesize across apps? → Full

Don't pattern match on keywords. Understand the intent naturally.

Examples (for reference, not rules)

• "hola" → None (conversational)
• "what's in my backlog?" → Targeted (load backlog notes only)
• "add dark mode to vaults app" → App (load .syner/vaults/vaults/)
• "fix bot webhook" → App (load .syner/vaults/bot/)
• "connect my ideas about X with project Y" → Full (multi-domain)
• "what should I build next?" → Full (needs complete context)

When Full Context is Loaded

From your notes, extract:

• What's relevant to this specific task
• Your preferences that apply
• Any /skill-name references in your notes

Step 2: Decide Fork & Route

Decide Fork

Only spawn when the task genuinely requires isolation or parallel work. Default to self-execution.

Planning Mode

When user requests planning or analysis produces multiple actionable findings:

1. Load plan.md for the core planning logic
2. If operating on issues/PRs, also load packages/github/plan.md for implementation details
3. Evaluate, classify, and decide (plan / skip / clarify)
4. Output checklist with Target/Context/Action/Verify per item

This converts analysis output into atomic, executable items.

Route by Scope

When intent maps to a known scope, enter it and discover available skills dynamically:

How to use scopes:

1. Match the user's intent to a scope (e.g., "authenticate with github" → github)
2. Glob("{area}/*/SKILL.md") to discover skills in that scope
3. Read name + description from each discovered SKILL.md
4. Route to the matching skill OR present available options

If no scope matches: Fall through to self-execution or ask the user.

"What can I do in X?" — Enter the scope, Glob for skills, read their descriptions, summarize.

Scopes grow automatically. New app with skills/ directory = new scope. New skill in existing app = appears on next discovery. No registration needed. The filesystem IS the registry.

See scopes.md for the full discovery protocol.

Execute Directly

Read-only operations only:

• Read files, search code (Read, Glob, Grep)
• Quick questions about context

Self-Execute

Complex execution that needs:

• Multiple file changes with verification
• Iterative refinement (code, review, fix)
• Gather Context → Take Action → Verify → Iterate loop

Before executing:

1. Run Glob("packages/*/SKILL.md") to discover available packages
2. Read SKILL.md for packages relevant to the task
3. Follow package prerequisites - if the package says "check X before using", check it
4. Gather task context — read the relevant files, run git log, git diff --stat as needed
5. Run through the 7-section self-provisioning checklist (see agents/syner.md → Execution Contract)

Execute directly. You don't need a separate worker — you ARE the worker. Use your execution loop: gather context, take action, verify, iterate.

Key principle: Syner explores, checks state, executes, verifies. One agent, end-to-end.

Delegate to syner-researcher

Research that needs web search or deep vault exploration:

Task(subagent_type="syner-researcher", prompt="
  Research: [topic]
")

Step 3: Summarize

After completion:

• Done: What was accomplished
• Files: Modified/created
• Verified: Results (if applicable)
• Next: Suggestions (optional)

Keep it concise. This runs in a forked context - details stay here.

Step 4: Write Audit (Conditional)

Write an audit file to {project-root}/.syner/audits/YYYY-MM-DDTHH-MM-SS.md ONLY when:

• Route was worker or specialist
• Files were modified/created

Skip audit for: conversational responses, read-only queries, quick lookups.

Filename format: YYYY-MM-DDTHH-MM-SS.md (e.g., 2026-03-02T14-32-05.md)

Template:

# Audit: {ISO timestamp}

## Request
{original user request}

## Routing
- Entry: /syner
- Context loaded: {none | targeted | full}
- Route: {direct | specialist:{skill-name} | worker}

## Tools Used
{list of tools and their purpose}

## Result
{success | failure} - {brief description}

## Duration
{approximate duration}

When writing audits, include failure details if applicable.

References

• README.md - Philosophy and examples
• skills.md - Skill architecture (symlinks, directories, where skills live)
• plan.md - Planning mode for breaking down complex work
• apps.md - When building AI apps
• grow.md - The grow methodology for evolving observations to principles
• scopes.md - Scope discovery protocol for navigating capabilities
• PHILOSOPHY.md - Notes are personal, suggest don't enforce