titan-sync
Skill94 starsChanged 3 months agoApache-2.0View on GitHub
Identify overlapping fixes across audit results, plan shared abstractions, produce an ordered execution plan with logical commit grouping (Titan Paradigm Phase 3)
In this repository22 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- architectSkill
- bench-checkSkill
- create-skillSkill
- deps-auditSkill
- dogfoodSkill
- fixerSkill
- housekeepSkill
- overseeSkill
- paritySkill
- releaseSkill
- resolveSkill
- sweepSkill
- test-healthSkill
- titan-closeSkill
- titan-forgeSkill
- titan-gateSkill
- titan-gauntletSkill
- titan-grindSkill
- titan-reconSkill
- titan-resetSkill
- titan-runSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
17 rules. About 0 are common, 8 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 41
Found nothing: Stop: "No Titan artifacts found.
- Very specific: line 47
If not in a worktree, stop: "Run /worktree first."
- Very specific: line 53
If there are merge conflicts, stop: "Merge conflict detected.
- Very specific: line 61
Validate state: If titan-state.json fails to parse, stop: "State file corrupted.
- Very specific: line 63
Check GAUNTLET completeness: If gauntlet-summary.json has "complete": false:
- Distinctive: line 67
All FAIL and DECOMPOSE targets with violations and files
- Distinctive: line 90
Cross-reference with GAUNTLET results: Check which changed files overlap with:
- Distinctive: line 146
Check code ownership for cross-team coordination:
- Distinctive: line 152
If different teams own files in the same cluster, note the coordination requirement.
- Distinctive: line 154
Run branch structural diff to see what's already changed:
- Distinctive: line 160
Avoid re-auditing or conflicting with in-progress work.
- Very specific: line 222
Run /titan-gate before committing
- Very specific: line 270
Update titan-state.json: set currentPhase to "sync".
- Distinctive: line 310
Logical commits matter: Never mix concerns.
- Distinctive: line 311
If GAUNTLET found zero failures, produce minimal plan (dead code + warnings only).
- Very specific: line 312
Keep codegraph path queries targeted — same file or community only.
- Very specific: line 313
If any command fails or produces unexpected output, log it to issues.ndjson before continuing.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Titan GLOBAL SYNC — Cross-Cutting Analysis & Execution Plan
You are running the GLOBAL SYNC phase of the Titan Paradigm.
Your goal: analyze GAUNTLET results to find overlapping problems, identify shared abstractions that should be built before individual fixes, group changes into logical commits, and produce an ordered execution plan.
Context budget: This phase reads artifacts, not source. Keep codegraph queries targeted — only for specific relationship questions between failing targets.
Step 0 — Pre-flight: find or join the Titan worktree
Locate the Titan session. Prior phases (RECON, GAUNTLET) may have run in a different worktree or branch. Search for it:
git worktree listFor each worktree, check if it contains Titan artifacts:
ls <worktree-path>/.codegraph/titan/titan-state.json 2>/dev/nullAlso check branches:
git branch -a --list '*titan*'Decision logic:
- Found exactly one worktree with
titan-state.jsonandcurrentPhaseis"gauntlet": GAUNTLET completed — this is the right session. Merge its branch into your worktree. - Found a worktree but
currentPhaseis not"gauntlet": Suspicious — could be mid-phase or a different run. IfcurrentPhaseis"recon", GAUNTLET hasn't run yet. If"sync"or later, someone else may be ahead. Ask the user: "Found Titan state at<path>with phase<phase>. Is this the session to continue?" - Found multiple worktrees with
titan-state.json: List them withcurrentPhaseandlastUpdated. Ask the user which to continue. - Found a branch (not worktree) with titan artifacts: Merge it:
git merge <titan-branch> --no-edit - Found nothing: Stop: "No Titan artifacts found. Run
/titan-reconthen/titan-gauntletfirst."
- Found exactly one worktree with
- Ensure worktree isolation:
If not in a worktree, stop: "Rungit rev-parse --show-toplevel && git worktree list/worktreefirst." - Sync with main:
If there are merge conflicts, stop: "Merge conflict detected. Resolve conflicts and re-rungit fetch origin main && git merge origin/main --no-edit/titan-sync." - Load artifacts. Read:
.codegraph/titan/titan-state.json— state, domains, batches, file audits.codegraph/titan/GLOBAL_ARCH.md— architecture, dependency flow, shared types.codegraph/titan/gauntlet.ndjson— per-target audit details.codegraph/titan/gauntlet-summary.json— aggregated results
- Validate state. If
titan-state.jsonfails to parse, stop: "State file corrupted. Run/titan-reset." - Check GAUNTLET completeness. If
gauntlet-summary.jsonhas"complete": false:"GAUNTLET incomplete (
<N>/<M>batches). SYNC will plan based on known failures only. Run/titan-gauntletfirst for a complete plan." - Extract. From artifacts, collect:
- All FAIL and DECOMPOSE targets with violations and files
- Common violation patterns by pillar
- Community assignments
- Dead symbols (cleanup candidates)
- Domain boundaries and dependency flow
Step 1 — Drift detection: has main moved since GAUNTLET?
The codebase may have changed between GAUNTLET and now. Detect this before planning on stale audit data.
- Compare main SHA:
Compare againstgit rev-parse origin/maintitan-state.json → mainSHA. If identical, skip to Step 2. - If main has advanced, find what changed:
git diff --name-only <mainSHA>..origin/main - Cross-reference with GAUNTLET results. Check which changed files overlap with:
- Files that were audited (
gauntlet.ndjson → filefield) - FAIL/DECOMPOSE targets (the ones SYNC plans around)
- Dead symbols targeted for removal
- Files that were audited (
Classify staleness:
Level Condition Action none main unchanged Continue normally low Changed files don't overlap with any audited targets Continue — note drift moderate Some FAIL/DECOMPOSE targets are in changed files (<30% affected) Continue but flag affected targets — their audit results may be outdated. Mark clusters containing them as "needs-verification"high >30% of FAIL targets affected OR shared dependencies changed Warn user: "Main has changed significantly since GAUNTLET. Audit results for N targets may be stale. Recommend /titan-gauntletre-run for affected targets before planning."critical New files added to src/ that would be in priority queue, or deleted files that were FAIL targets Stop: "Codebase structure changed. Run /titan-reconto rebuild baseline, then/titan-gauntlet."- Append drift report to
.codegraph/titan/drift-report.json(the file is a JSON array — read existing entries, push the new entry, write back; same schema as GAUNTLET, with"detectedBy": "sync"). - Update state: Set
titan-state.json → mainSHAto currentorigin/main. - If
moderate: Proceed but annotate affected clusters insync.jsonwith"driftWarning": true. The execution order should prioritize non-stale targets and defer stale ones pending re-audit. - If re-running SYNC and a previous
drift-report.jsonexists withreassessmentScope.targets, re-read GAUNTLET results only for those targets and rebuild affected clusters.
Step 2 — Find dependency clusters among failing targets
For FAIL/DECOMPOSE targets that share a file or community, check connections:
codegraph path <target1> <target2> -T --jsonGroup connected failures into clusters. Also check for cycles among them:
codegraph cycles --functions --jsonFilter to cycles including at least one FAIL/DECOMPOSE target.
Step 3 — Identify shared dependencies and ownership
For each cluster, find what they share:
codegraph deps <key-file> --jsonLook for:
- Shared imports: multiple failures import the same module → interface extraction candidate
- Shared callers: multiple failures called by the same function → caller needs updating
- Common violations: similar pillar violations across targets
Check code ownership for cross-team coordination:
codegraph owners <file1> <file2> -T --jsonIf different teams own files in the same cluster, note the coordination requirement.
Run branch structural diff to see what's already changed:
codegraph branch-compare main HEAD -T --jsonAvoid re-auditing or conflicting with in-progress work.
Step 4 — Detect extraction candidates
For DECOMPOSE targets:
codegraph context <target> -T --json
codegraph ast --kind call --file <file> -T --jsonLook for:
- Functions with multiple responsibilities (high cognitive + high fan-out + high
halstead.bugs) - Repeated patterns across failures (similar call chains)
- God files (many failing functions → split along community boundaries)
Step 5 — Plan shared abstractions
Identify what to build BEFORE individual fixes:
- Interface extractions — shared dependency → extract interface
- Utility extractions — repeated patterns → shared utility
- Module splits — god files → split by community structure
- Cycle breaks — circular deps → identify weakest link
For each, check blast radius:
codegraph fn-impact <shared-dep> -T --jsonStep 6 — Build execution order with logical commits
Phases (in order)
- Dead code cleanup — zero risk, reduces noise
- Commit:
chore: remove dead code
- Commit:
- Shared abstractions — before individual fixes
- One commit per abstraction:
refactor: extract X from Y
- One commit per abstraction:
- Cycle breaks — unblocks dependent targets
- One commit per break:
refactor: break cycle between X and Y
- One commit per break:
- Decompositions — highest risk, after abstractions
- One commit per decomposition:
refactor: split X into A and B
- One commit per decomposition:
- Fail fixes — ordered by blast radius (lowest first)
- Group by domain:
fix: address quality issues in <domain>
- Group by domain:
- Warn improvements — optional, lowest priority
- Group by domain:
refactor: address warnings in <domain>
- Group by domain:
Ordering within each phase
- Dependencies first (if A depends on B, fix B first)
- Lower blast radius first
- Same community together
Each commit should:
- Touch one domain where possible
- Address one concern
- Be independently revertible
- Run
/titan-gatebefore committing
Step 7 — Write the SYNC artifact
Write .codegraph/titan/sync.json:
{
"phase": "sync",
"timestamp": "<ISO 8601>",
"clusters": [
{
"id": 1,
"name": "<descriptive>",
"targets": ["t1", "t2"],
"sharedDeps": ["mod"],
"hasCycle": false,
"owners": ["team-a", "team-b"],
"proposedAction": "Extract interface"
}
],
"abstractions": [
{
"type": "interface_extraction|utility_extraction|module_split|cycle_break",
"description": "...",
"source": "<current location>",
"unblocks": ["t1", "t2"],
"blastRadius": 0,
"commit": "refactor: ..."
}
],
"executionOrder": [
{
"phase": 1,
"label": "Dead code cleanup",
"targets": ["sym1", "sym2"],
"risk": "none",
"commit": "chore: remove dead code",
"dependencies": []
}
],
"deadCodeTargets": ["<from recon>"],
"cyclesInvolvingFailures": []
}Update titan-state.json: set currentPhase to "sync".
Step 8 — Report to user
Print:
- Dependency clusters found (count)
- Shared abstractions proposed (count)
- Execution order summary (phases, target counts, estimated commits)
- Key insight: what SYNC prevented (e.g., "3 targets share configLoader — without SYNC, 3 conflicting refactors")
- Path to
sync.json - Next step: start Phase 1 (dead code cleanup), validate each commit with
/titan-gate
Issue Tracking
Throughout this phase, if you encounter any of the following, append a JSON line to .codegraph/titan/issues.ndjson:
- Codegraph bugs: incorrect path queries, wrong cycle detection, relationship errors
- Tooling issues: artifact parsing failures, state inconsistencies
- Process suggestions: better clustering strategies, execution order improvements
- Codebase observations: cross-cutting concerns not captured by GAUNTLET
Format (one JSON object per line, append-only):
{"phase": "sync", "timestamp": "<ISO 8601>", "severity": "bug|limitation|suggestion", "category": "codegraph|tooling|process|codebase", "description": "<what happened>", "context": "<command, cluster, or artifact involved>"}Log issues as they happen — don't batch them. The /titan-close phase compiles these into the final report.
Rules
- Read artifacts, don't re-scan. Codegraph commands only for targeted relationship queries.
- Always use
--jsonand-T. - The execution order is the key output.
- Logical commits matter. Never mix concerns.
- If GAUNTLET found zero failures, produce minimal plan (dead code + warnings only).
- Keep
codegraph pathqueries targeted — same file or community only. - If any command fails or produces unexpected output, log it to
issues.ndjsonbefore continuing.
Self-Improvement
This skill lives at .claude/skills/titan-sync/SKILL.md. Edit if clustering misses connections or execution order causes conflicts.
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
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.

