Call this FIRST at the START of every coding session. Returns a summary of the entire project: domains, features, their statuses, recent decisions, and open conflicts. Use this to orient yourself before writing any code. If you need detail on a specific feature, follow up with get_feature_context.

Get FULL details for a specific feature before working on it. Returns description, components, involved files, repo ownership, recent decisions, and open conflicts for that feature. Always call this before modifying code that belongs to a feature.

Check past architectural decisions before proposing changes. Prevents re-debating settled decisions. Call this when you are unsure why something was built a certain way, or before making a significant architectural choice.

Check for open conflicts before starting work. Conflicts indicate areas where code changes contradicted prior decisions or where patterns collided. You MUST check conflicts before modifying affected features.

Before modifying any file, call this to understand which feature and component owns it. This prevents accidental cross-feature changes and helps you stay within the right domain. For multi-repo projects, pass file paths in repo:path form (for example "web:src/app/page.tsx").

Read hosted proposal summaries for Hybrid mode. This is read-only: local project-memory files remain authoritative, and proposal application must happen through the VibeCompass package sync flow.

Log EVERY significant architectural decision you make during this session. This creates a permanent record that future sessions will read. If you chose between two approaches, log why. If you changed an existing pattern, explain the reasoning. Future sessions depend on this.

Update a feature's status when you make progress. Mark "in_progress" when you start working on it, "complete" when done, "blocked" if stuck. This keeps the project brain accurate for the next session.

Flag a conflict when you notice contradictory patterns, duplicated logic across features, or disagreement with a past decision. Conflicts are surfaced to the developer in the dashboard for resolution. Do not try to auto-resolve conflicts — flag them and move on.

Call this at the END of every coding session. Summarize what you accomplished, what is left to do, and any blockers. List all features you touched. The next AI session will read this summary to continue where you left off.