titan-forge
Skill94 starsChanged 3 months agoApache-2.0View on GitHub
Execute the sync.json plan — refactor code, validate with /titan-gate, commit, and advance state (Titan Paradigm Phase 4)
- Deletes or force-pushes
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-gateSkill
- titan-gauntletSkill
- titan-grindSkill
- titan-reconSkill
- titan-resetSkill
- titan-runSkill
- titan-syncSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
51 rules. About 0 are common, 33 are distinctive, and 18 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈33
Distinctive · estimate
This author's own choices. Worth a look.
18
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 17
No args → run next incomplete phase
- Very specific: line 31
If not in a worktree, stop: "Run /worktree first."
- Very specific: line 38
If behind == 0 → already up to date, skip the merge entirely and print "Already up to date with origin/main."
- Very specific: line 43
If there are merge conflicts, stop: "Merge conflict detected.
- Distinctive: line 45
After a successful merge, run a duplicate-commit check to detect re-applied work:
- Distinctive: line 49
If any subjects are duplicated, print a warning listing them: "WARNING: Duplicate commit subjects found after merge — prior work may have …
- Very specific: line 57
Validate state: If titan-state.json has currentPhase other than "sync" and no existing execution block, stop: "State not ready.
- Distinctive: line 85
If any targets were recovered, print: "Recovered N completed targets from branch git log — skipping re-application."
- Very specific: line 87
Determine next phase: Use --phase N if provided, otherwise find the lowest phase number not in completedPhases.
- Very specific: line 92
Ask for confirmation: before starting (unless $ARGUMENTS contains --yes).
- Distinctive: line 101
Delete the symbol/export
- Very specific: line 102
Verify no consumers: codegraph fn-impact <target> -T --json
- Distinctive: line 103
Remove any orphaned imports
- Distinctive: line 104
Run lint to clean up
- Distinctive: line 108
Update imports in all consumers
- Distinctive: line 113
Use contextually appropriate error handling
- Distinctive: line 118
Keep dispatcher thin — handler per node kind
- Distinctive: line 122
Read the gauntlet recommendation for the specific target
- Very specific: line 137
Skip if done: Check if target is already in execution.completedTargets.
- Distinctive: line 143
Understand before touching: Run codegraph commands:
- Distinctive: line 152
Check if already fixed: If the file has changed since gauntlet ran, re-check metrics:
- Distinctive: line 156
If the target now passes all thresholds, skip with note: "Target already passes — skipping."
- Distinctive: line 168
Before running gate or tests, verify the diff matches the intent.
- Distinctive: line 184
Test file for the target → OK
- Distinctive: line 190
If recommendation says "split" → diff should show new functions extracted, original simplified
- Distinctive: line 191
If recommendation says "remove dead code" → diff should show deletions, not additions
- Distinctive: line 192
If violation was "complexity > threshold" → diff should reduce complexity, not just move code around
- Distinctive: line 193
If the diff does something entirely different from the recommendation → DIFF FAIL
- Distinctive: line 201
If the diff deletes code (lines removed > 10), identify deleted symbols by comparing the pre-change file against removed lines:
- Distinctive: line 214
If the deleted symbol has active callers not updated in this diff → DIFF FAIL: "Deleted <symbol> still has <N> callers not updated in this …
- Distinctive: line 217
If the gauntlet recommendation mentioned specific symbols to remove/refactor, verify they were actually addressed:
- Distinctive: line 220
If all recommended symbols were addressed → DIFF PASS (implicit — no warnings emitted)
- Very specific: line 227
Add to execution.failedTargets with reason starting with "diff-review: ".
- Very specific: line 234
If testCmd == "NO_TEST_SCRIPT" → skip pre-gate test run (no test script configured).
- Distinctive: line 239
If tests fail → go to rollback (step 13).
- Very specific: line 244
Use the Skill tool to invoke titan-gate.
- Very specific: line 245
If FAIL on cycle/test/lint/build (gate auto-rolls back staged changes on Step 2/4 cycle.
- Very specific: line 253
Add target to execution.completedTargets
- Very specific: line 266
Add to execution.failedTargets with reason: { "target": "<name>", "reason": "<why>", "phase": N }
- Distinctive: line 274
When all targets in the phase are processed:
- Very specific: line 276
Add phase number to execution.completedPhases
- Distinctive: line 301
If all phases are complete:
- Distinctive: line 318
Merge conflict with main: Stop, report, ask user to resolve.
- Distinctive: line 319
Gate detects new cycle: Stop immediately — this is a real problem, not skippable.
- Distinctive: line 320
Target already fixed on main: Check if file has changed since gauntlet.
- Very specific: line 323
--target <name>: Run only that target. Useful for retrying entries in failedTargets. - Distinctive: line 329
One phase per invocation: Stop after the phase completes.
- Distinctive: line 330
Resumable: If interrupted, re-running picks up where it left off.
- Very specific: line 332
Gate before commit: Every commit must pass /titan-gate.
- Very specific: line 333
One commit per logical unit: Use commit messages from sync.json.
- Distinctive: line 334
Stage only specific files: Never git add . or git add -A.
≈ “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 FORGE — Execute Sync Plan
You are running the FORGE phase of the Titan Paradigm.
Your goal: read sync.json, find the next incomplete execution phase, make the actual code changes for each target, validate with /titan-gate, commit, and advance state.
Context budget: One phase per invocation. Do not attempt all phases in one session — the context window will fill. Run one phase, report, stop. User re-runs for the next phase.
Arguments (from $ARGUMENTS):
- No args → run next incomplete phase
--phase N→ jump to specific phase--target <name>→ run single target only (for retrying failures)--dry-run→ show what would be done without changing code--yes→ skip confirmation prompt (typically passed by/titan-runorchestrator)
Step 0 — Pre-flight
- Worktree check:
If not in a worktree, stop: "Rungit rev-parse --show-toplevel && git worktree list/worktreefirst." - Sync with main (conditional):
git fetch origin main behind=$(git rev-list HEAD..origin/main --count)- If
behind == 0→ already up to date, skip the merge entirely and print "Already up to date with origin/main." If
behind > 0→ merge:git merge origin/main --no-editIf there are merge conflicts, stop: "Merge conflict detected. Resolve conflicts and re-run
/titan-forge."After a successful merge, run a duplicate-commit check to detect re-applied work:
git log origin/main..HEAD --no-merges --format="%s" | sort | uniq -dIf any subjects are duplicated, print a warning listing them: "WARNING: Duplicate commit subjects found after merge — prior work may have been re-applied. Step 5 will auto-recover completed targets from git log so they are skipped." Do not stop — proceed to Step 3.
- If
- Load artifacts. Read:
.codegraph/titan/sync.json— execution plan (if missing: "Run/titan-syncfirst.").codegraph/titan/titan-state.json— current state.codegraph/titan/gauntlet.ndjson— per-target audit details.codegraph/titan/gauntlet-summary.json— aggregated results
- Validate state. If
titan-state.jsonhascurrentPhaseother than"sync"and no existingexecutionblock, stop: "State not ready. Run/titan-syncfirst." Initialize execution state (if first run). Before writing a blank
executionblock, recover already-completed work from the branch's git log to prevent re-doing commits that are already on the branch:git log origin/main..HEAD --no-merges --format="%s"Cross-reference each subject line against
sync.json → executionOrder[*].targets[*].commitMessage. For every match, mark that target as already completed and its phase as completed if all targets in the phase matched.Then write
titan-state.jsonwith the recovered state (pre-populatedcompletedTargets,completedPhases, andcommitsfromgit log origin/main..HEAD --no-merges --format="%H %s"):{ "execution": { "currentPhase": <lowest incomplete phase, or 1 if none recovered>, "completedPhases": [<phases where all targets matched>], "currentTarget": null, "completedTargets": [<targets whose commit subjects appeared in git log>], "failedTargets": [], "commits": [<SHAs of matched commits>], "currentSubphase": null, "completedSubphases": [], "diffWarnings": [] } }If any targets were recovered, print: "Recovered N completed targets from branch git log — skipping re-application."
- Determine next phase. Use
--phase Nif provided, otherwise find the lowest phase number not incompletedPhases. - Print plan:
Phase N: <label> — N targets, estimated N commits
- Ask for confirmation before starting (unless
$ARGUMENTScontains--yes).
Step 1 — Phase-specific execution strategies
Each phase type requires different code-change logic:
Phase 1: Dead code cleanup
- Delete the symbol/export
- Verify no consumers:
codegraph fn-impact <target> -T --json - Remove any orphaned imports
- Run lint to clean up
Phase 2: Shared abstractions
- Extract function/interface to new or existing file
- Update imports in all consumers
- Verify with:
codegraph exports <file> -T --json
Phase 3: Empty catches / error handling
- Replace
catch {}withcatch (e) { logger.debug(...) }or explicit fallback - Use contextually appropriate error handling
- Subphases: each distinct catch pattern = one commit
Phase 4: Extractor decomposition
- Split large
walkXNodeswitch cases into handler functions - Keep dispatcher thin — handler per node kind
- Subphases: each extractor = one commit
Phase 5: General decomposition
- Read the gauntlet recommendation for the specific target
- Apply the recommended decomposition strategy
- Subphases: each function split = one commit
Phase 6: Small FAIL fixes
- Read the gauntlet recommendation for the specific target
- Apply the recommended fix (complexity reduction, metric improvement)
- Group by domain where possible
Step 2 — Per-target execution loop
For each target in the current phase:
- Skip if done. Check if target is already in
execution.completedTargets. If so, skip. - Update state. Set
execution.currentTargetintitan-state.json. - Read gauntlet entry. Find this target in
gauntlet.ndjson→ get recommendation, violations, metrics. - Understand before touching. Run codegraph commands:
If blast radius > 0:codegraph context <target> -T --jsoncodegraph fn-impact <target> -T --json - Check if already fixed. If the file has changed since gauntlet ran, re-check metrics:
If the target now passes all thresholds, skip with note: "Target already passes — skipping."codegraph complexity --file <file> --health -T --json - Read source file(s). Understand the code before editing.
- Apply the change based on phase strategy (Step 1) + gauntlet recommendation.
- Stage changed files:
git add <specific changed files> Diff review (intent verification): Before running gate or tests, verify the diff matches the intent. This catches cases where the code change is structurally valid but doesn't match what was planned.
Collect the context:
git diff --cached --stat git diff --cachedLoad the gauntlet entry for this target (from
gauntlet.ndjson) and the sync plan entry (fromsync.json → executionOrder.find(e => e.phase === currentPhase)).Check all of the following:
D1. Scope — only planned files touched: Compare staged file paths against
sync.json → executionOrder.find(e => e.phase === currentPhase).targetsand their known file paths (from gauntlet entries). Flag any file NOT associated with the current target or phase.- File in a completely different domain → DIFF FAIL
- File is a direct dependency of the target (consumer or import) → OK (expected ripple)
- Test file for the target → OK
D2. Intent match — diff aligns with gauntlet recommendation: First, check if this target is a dead-code target (present in
titan-state.json → roles.deadSymbols). If so, the expected recommendation is "remove dead code" — skip gauntlet entry lookup (dead-code targets have no gauntlet.ndjson entry) and verify the diff shows only deletions (no new functions or logic added). If the diff contains non-trivial additions for a dead-code target → DIFF FAIL.Otherwise, read the gauntlet entry's
recommendationfield andviolationslist. Verify the diff addresses them:- If recommendation says "split" → diff should show new functions extracted, original simplified
- If recommendation says "remove dead code" → diff should show deletions, not additions
- If violation was "complexity > threshold" → diff should reduce complexity, not just move code around
- If the diff does something entirely different from the recommendation → DIFF FAIL
D3. Commit message accuracy: Compare the planned commit message from
sync.jsonagainst what the diff actually does.- Message says "remove dead code" but diff adds new functions → DIFF WARN
- Message says "extract X from Y" but diff only modifies Y without creating X → DIFF FAIL
D4. Deletion audit: If the diff deletes code (lines removed > 10), identify deleted symbols by comparing the pre-change file against removed lines:
# Get the pre-change version's symbols (temp file for shell portability) D4_PRE_EXT="${changed_file##*.}" D4_PRE_TMP=$(mktemp "/tmp/titan-d4-pre-XXXXXX.${D4_PRE_EXT}") git show HEAD:<changed-file> > "$D4_PRE_TMP" codegraph where --file "$D4_PRE_TMP" -T --json 2>/dev/null rm -f "$D4_PRE_TMP"Cross-reference with
git diff --cached -- <changed-file>to find symbols whose definitions appear only in removed lines (lines starting with-). For each deleted symbol:codegraph fn-impact <deleted-symbol> -T --json 2>/dev/nullIf the deleted symbol has active callers not updated in this diff → DIFF FAIL: "Deleted
<symbol>still has<N>callers not updated in this commit."D5. Leftover check: If the gauntlet recommendation mentioned specific symbols to remove/refactor, verify they were actually addressed:
- Dead symbols listed for removal but still present in the diff → DIFF WARN: "Gauntlet listed
<symbol>for removal but it was not deleted." - Functions marked for decomposition but original is unchanged → DIFF WARN: "Gauntlet recommended decomposing
<symbol>but original function was not simplified." - If all recommended symbols were addressed → DIFF PASS (implicit — no warnings emitted)
On DIFF FAIL:
git reset HEAD -- $(git diff --cached --name-only) git checkout -- $(git diff --name-only)Add to
execution.failedTargetswith reason starting with"diff-review: ". Continue to next target. On DIFF WARN: Log the warning but proceed to gate. Include the warning in the gate-log entry.Run tests — detect the project's test command from
package.json(same detection as gate Step 4):testCmd=$(node -e "const p=require('./package.json');const s=p.scripts||{};const script=s.test?'test':s['test:ci']?'test:ci':null;if(!script){console.log('NO_TEST_SCRIPT');process.exit(0);}const fs=require('fs');const runner=fs.existsSync('yarn.lock')?'yarn':fs.existsSync('pnpm-lock.yaml')?'pnpm':fs.existsSync('bun.lockb')?'bun':'npm';console.log(runner+(script==='test'?' test':' run '+script));")- If
testCmd == "NO_TEST_SCRIPT"→ skip pre-gate test run (no test script configured). - Otherwise:
If tests fail → go to rollback (step 13).$testCmd 2>&1
Note: Gate (Step 11) also runs tests. This pre-gate test is a fast-fail optimization — it catches obvious breakage before running the full gate checks (codegraph analysis, semantic assertions, arch snapshot). For projects with fast test suites the duplication is negligible; for slow suites, the tradeoff is: catch failures ~2x faster at the cost of ~2x test time on passing targets.
- If
- Run /titan-gate:
Use the Skill tool to invoke
titan-gate.- If FAIL on cycle/test/lint/build (gate auto-rolls back staged changes on Step 2/4 cycle; Step 1 may also report cycle violation via
--cyclesflag — treat that the same as Step 2) → go to rollback (step 13) to also revert working tree. - If FAIL on any other check — complexity (Step 3), semantic (Step 5), structural/arch (Steps 1, 5.5, 6-8) — gate does NOT auto-rollback its staging area; forge must clean up for the next target → unstage with
git reset HEAD -- $(git diff --cached --name-only) && git checkout -- $(git diff --name-only), add toexecution.failedTargetswith reason, log the gate report, and continue to the next target. Do NOT go to step 13 — that step is for Step 2/4 failures where gate already unstaged; going there again would attempt a duplicate rollback.
- If FAIL on cycle/test/lint/build (gate auto-rolls back staged changes on Step 2/4 cycle; Step 1 may also report cycle violation via
- On success:
git commit -m "<commit message from sync.json>"- Record commit SHA in
execution.commits - Add target to
execution.completedTargets - Record any diff-review warnings by appending to
execution.diffWarnings(if any). Each entry must follow this schema:{ "target": "<target-name>", "check": "<D3 or D5>", "message": "<warning text>", "phase": N } - Update
titan-state.json
- Record commit SHA in
- On failure (test or gate):
# Discover dirty files at rollback time (don't rely on carried file list) git reset HEAD -- $(git diff --cached --name-only) git checkout -- $(git diff --name-only)- Add to
execution.failedTargetswith reason:{ "target": "<name>", "reason": "<why>", "phase": N } - Clear
execution.currentTarget - Continue to next target — don't block the whole phase
- Add to
Step 3 — Phase completion
When all targets in the phase are processed:
- Add phase number to
execution.completedPhases - Advance
execution.currentPhaseto the next phase number - Clear
execution.currentTarget - Write updated
titan-state.json
Step 4 — Report
Print:
## Phase N Complete: <label>
Targets: X/Y completed, Z failed
Commits: N
Files changed: N
### Failed targets (if any):
- <target>: <reason>
### Next: Phase M — <label> (N targets)
Run /titan-forge to continue.If all phases are complete:
## All phases complete
Total commits: N
Total targets: X completed, Y failed
Failed targets: <list or "none">
Run /titan-gate on the full branch to validate.Edge Cases
- Test failure mid-phase: Revert target, mark failed, continue. Don't block the whole phase.
- Merge conflict with main: Stop, report, ask user to resolve.
- Gate detects new cycle: Stop immediately — this is a real problem, not skippable.
- Target already fixed on main: Check if file has changed since gauntlet. If metrics now pass, skip with note.
- Interrupted mid-phase: Re-running picks up from
execution.currentTarget. Already-committed targets are skipped. --dry-run: Walk through all targets, print what would be done (phase strategy, gauntlet recommendation, files affected), but make no changes.--target <name>: Run only that target. Useful for retrying entries infailedTargets.
Rules
- One phase per invocation. Stop after the phase completes. User re-runs for next.
- Resumable. If interrupted, re-running picks up where it left off.
- Always use
--jsonand-Tfor codegraph commands. - Gate before commit. Every commit must pass
/titan-gate. No exceptions. - One commit per logical unit. Use commit messages from
sync.json. - Stage only specific files. Never
git add .orgit add -A. - Rollback on failure is gentle —
git reset HEAD -- $(git diff --cached --name-only)to unstage, thengit checkout -- $(git diff --name-only)to revert working tree. Nevergit reset --hard. - Subphase awareness — phases 3-6 have subphases. Each subphase = one commit. Track at subphase level.
- Never skip
/titan-gate. Even for "trivial" changes.
Relationship to Other Skills
| Skill | Produces | Used by /titan-forge |
/titan-recon | titan-state.json, GLOBAL_ARCH.md | State tracking, domain context |
/titan-gauntlet | gauntlet.ndjson, gauntlet-summary.json | Per-target recommendations |
/titan-sync | sync.json | Execution plan (phases, targets, commits) |
/titan-gate | Gate verdict | Called per-commit for validation |
/titan-reset | Clean slate | Removes all artifacts |
Self-Improvement
This skill lives at .claude/skills/titan-forge/SKILL.md. Edit if phase strategies need refinement or execution loop needs adjustment after dogfooding.
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.

