sync_core

Coordinates multi-file code changes with dependency tracking and atomic commits.

Updated Jan 14, 2026
One-click install
npx skills add https://github.com/jvsandhu/agentic-skills --skill sync-core-jvsandhu
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sync_core
Source: https://github.com/jvsandhu/agentic-skills/tree/main/skills/sync_core
Command: npx skills add https://github.com/jvsandhu/agentic-skills --skill sync-core-jvsandhu

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Changing a shared type, constant, or interface often breaks many dependent files, causing inconsistent states, dangling imports, and failed builds. This Skill provides a disciplined workflow for planning, sequencing, and verifying multi-file changes so they land as one atomic commit. ## Core Features & Use Cases - Dependency Mapping: Traces import/export chains to identify every file affected by a change before editing begins. - Ordered Change Sequence: Enforces a safe update order: types and interfaces first, then utils, services, and finally UI components. - Atomic Verification & Commit: Runs build, lint, and integration tests at each step and merges everything in a single Conventional Commit. - Use Case: When renaming a shared API constant used across services and components, map all importers, update core types first, propagate changes layer by layer, and submit one verified commit. ## Quick Start Use the sync_core skill to plan and apply a synchronized multi-file change for renaming the API_URL constant across all dependent files.

Frequently Asked Questions about sync_core

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely change code that is imported by many files?

First map the full import/export chain to identify every affected file, then update in order: types and interfaces, utils, services, and components last. Run builds and tests at each step and merge everything in one atomic commit.

What is the correct order for multi-file refactoring?

Update core data structures first (types, interfaces, constants), then utils and helpers, then services and controllers, and finally UI components and props. This order keeps the project compilable at each step.

How do I avoid breaking changes when updating shared interfaces?

Perform impact analysis before editing: extract all dependencies of the target file, check for other branches touching the same files, and flag breaking changes for versioning. Verify with cross-module integration tests before committing.

Why does my build fail after renaming a shared constant?

Builds fail when some import paths or references were missed during the rename. Trace the complete import chain, check both alias and relative paths, and run a full lint and build check to catch dangling imports.

When should multi-file changes be split into separate commits?

Synchronized changes that depend on each other should stay in one atomic commit to avoid inconsistent intermediate states. Split only when change groups are logically independent and each passes tests on its own.