agentleFS
optaveoptave/ops-codegraph-tool/.claude/skills/titan-forge/SKILL.md

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

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
  1. Distinctive:

    No args → run next incomplete phase

    line 17
  2. Very specific:

    If not in a worktree, stop: "Run /worktree first."

    line 31
  3. Very specific:

    If behind == 0 → already up to date, skip the merge entirely and print "Already up to date with origin/main."

    line 38
  4. Very specific:

    If there are merge conflicts, stop: "Merge conflict detected.

    line 43
  5. Distinctive:

    After a successful merge, run a duplicate-commit check to detect re-applied work:

    line 45
  6. Distinctive:

    If any subjects are duplicated, print a warning listing them: "WARNING: Duplicate commit subjects found after merge — prior work may have …

    line 49
  7. Very specific:

    Validate state: If titan-state.json has currentPhase other than "sync" and no existing execution block, stop: "State not ready.

    line 57
  8. Distinctive:

    If any targets were recovered, print: "Recovered N completed targets from branch git log — skipping re-application."

    line 85
  9. Very specific:

    Determine next phase: Use --phase N if provided, otherwise find the lowest phase number not in completedPhases.

    line 87
  10. Very specific:

    Ask for confirmation: before starting (unless $ARGUMENTS contains --yes).

    line 92
  11. Distinctive:

    Delete the symbol/export

    line 101
  12. Very specific:

    Verify no consumers: codegraph fn-impact <target> -T --json

    line 102
  13. Distinctive:

    Remove any orphaned imports

    line 103
  14. Distinctive:

    Run lint to clean up

    line 104
  15. Distinctive:

    Update imports in all consumers

    line 108
  16. Distinctive:

    Use contextually appropriate error handling

    line 113
  17. Distinctive:

    Keep dispatcher thin — handler per node kind

    line 118
  18. Distinctive:

    Read the gauntlet recommendation for the specific target

    line 122
  19. Very specific:

    Skip if done: Check if target is already in execution.completedTargets.

    line 137
  20. Distinctive:

    Understand before touching: Run codegraph commands:

    line 143
  21. Distinctive:

    Check if already fixed: If the file has changed since gauntlet ran, re-check metrics:

    line 152
  22. Distinctive:

    If the target now passes all thresholds, skip with note: "Target already passes — skipping."

    line 156
  23. Distinctive:

    Before running gate or tests, verify the diff matches the intent.

    line 168
  24. Distinctive:

    Test file for the target → OK

    line 184
  25. Distinctive:

    If recommendation says "split" → diff should show new functions extracted, original simplified

    line 190
  26. Distinctive:

    If recommendation says "remove dead code" → diff should show deletions, not additions

    line 191
  27. Distinctive:

    If violation was "complexity > threshold" → diff should reduce complexity, not just move code around

    line 192
  28. Distinctive:

    If the diff does something entirely different from the recommendation → DIFF FAIL

    line 193
  29. Distinctive:

    If the diff deletes code (lines removed > 10), identify deleted symbols by comparing the pre-change file against removed lines:

    line 201
  30. Distinctive:

    If the deleted symbol has active callers not updated in this diff → DIFF FAIL: "Deleted <symbol> still has <N> callers not updated in this …

    line 214
  31. Distinctive:

    If the gauntlet recommendation mentioned specific symbols to remove/refactor, verify they were actually addressed:

    line 217
  32. Distinctive:

    If all recommended symbols were addressed → DIFF PASS (implicit — no warnings emitted)

    line 220
  33. Very specific:

    Add to execution.failedTargets with reason starting with "diff-review: ".

    line 227
  34. Very specific:

    If testCmd == "NO_TEST_SCRIPT" → skip pre-gate test run (no test script configured).

    line 234
  35. Distinctive:

    If tests fail → go to rollback (step 13).

    line 239
  36. Very specific:

    Use the Skill tool to invoke titan-gate.

    line 244
  37. Very specific:

    If FAIL on cycle/test/lint/build (gate auto-rolls back staged changes on Step 2/4 cycle.

    line 245
  38. Very specific:

    Add target to execution.completedTargets

    line 253
  39. Very specific:

    Add to execution.failedTargets with reason: { "target": "<name>", "reason": "<why>", "phase": N }

    line 266
  40. Distinctive:

    When all targets in the phase are processed:

    line 274
  41. Very specific:

    Add phase number to execution.completedPhases

    line 276
  42. Distinctive:

    If all phases are complete:

    line 301
  43. Distinctive:

    Merge conflict with main: Stop, report, ask user to resolve.

    line 318
  44. Distinctive:

    Gate detects new cycle: Stop immediately — this is a real problem, not skippable.

    line 319
  45. Distinctive:

    Target already fixed on main: Check if file has changed since gauntlet.

    line 320
  46. Very specific:

    --target <name>: Run only that target. Useful for retrying entries in failedTargets.

    line 323
  47. Distinctive:

    One phase per invocation: Stop after the phase completes.

    line 329
  48. Distinctive:

    Resumable: If interrupted, re-running picks up where it left off.

    line 330
  49. Very specific:

    Gate before commit: Every commit must pass /titan-gate.

    line 332
  50. Very specific:

    One commit per logical unit: Use commit messages from sync.json.

    line 333
  51. Distinctive:

    Stage only specific files: Never git add . or git add -A.

    line 334

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-run orchestrator)

Step 0 — Pre-flight

  1. Worktree check:
    git rev-parse --show-toplevel && git worktree list
    If not in a worktree, stop: "Run /worktree first."
  2. 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-edit

      If 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 -d

      If 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.

  3. Load artifacts. Read:
    • .codegraph/titan/sync.json — execution plan (if missing: "Run /titan-sync first.")
    • .codegraph/titan/titan-state.json — current state
    • .codegraph/titan/gauntlet.ndjson — per-target audit details
    • .codegraph/titan/gauntlet-summary.json — aggregated results
  4. Validate state. If titan-state.json has currentPhase other than "sync" and no existing execution block, stop: "State not ready. Run /titan-sync first."
  5. Initialize execution state (if first run). Before writing a blank execution block, 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.json with the recovered state (pre-populated completedTargets, completedPhases, and commits from git 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."

  6. Determine next phase. Use --phase N if provided, otherwise find the lowest phase number not in completedPhases.
  7. Print plan:

    Phase N: <label> — N targets, estimated N commits

  8. Ask for confirmation before starting (unless $ARGUMENTS contains --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 {} with catch (e) { logger.debug(...) } or explicit fallback
  • Use contextually appropriate error handling
  • Subphases: each distinct catch pattern = one commit

Phase 4: Extractor decomposition

  • Split large walkXNode switch 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:

  1. Skip if done. Check if target is already in execution.completedTargets. If so, skip.
  2. Update state. Set execution.currentTarget in titan-state.json.
  3. Read gauntlet entry. Find this target in gauntlet.ndjson → get recommendation, violations, metrics.
  4. Understand before touching. Run codegraph commands:
    codegraph context <target> -T --json
    If blast radius > 0:
    codegraph fn-impact <target> -T --json
  5. Check if already fixed. If the file has changed since gauntlet ran, re-check metrics:
    codegraph complexity --file <file> --health -T --json
    If the target now passes all thresholds, skip with note: "Target already passes — skipping."
  6. Read source file(s). Understand the code before editing.
  7. Apply the change based on phase strategy (Step 1) + gauntlet recommendation.
  8. Stage changed files:
    git add <specific changed files>
  9. 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 --cached

    Load the gauntlet entry for this target (from gauntlet.ndjson) and the sync plan entry (from sync.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).targets and 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 recommendation field and violations list. 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.json against 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/null

    If 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.failedTargets with 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.

  10. 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:
      $testCmd 2>&1
      If tests fail → go to rollback (step 13).

    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.

  11. 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 --cycles flag — 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 to execution.failedTargets with 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.
  12. 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
  13. 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.failedTargets with reason: { "target": "<name>", "reason": "<why>", "phase": N }
    • Clear execution.currentTarget
    • Continue to next target — don't block the whole phase

Step 3 — Phase completion

When all targets in the phase are processed:

  1. Add phase number to execution.completedPhases
  2. Advance execution.currentPhase to the next phase number
  3. Clear execution.currentTarget
  4. 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 in failedTargets.

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 --json and -T for 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 . or git add -A.
  • Rollback on failure is gentle — git reset HEAD -- $(git diff --cached --name-only) to unstage, then git checkout -- $(git diff --name-only) to revert working tree. Never git 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

SkillProducesUsed by /titan-forge
/titan-recontitan-state.json, GLOBAL_ARCH.mdState tracking, domain context
/titan-gauntletgauntlet.ndjson, gauntlet-summary.jsonPer-target recommendations
/titan-syncsync.jsonExecution plan (phases, targets, commits)
/titan-gateGate verdictCalled per-commit for validation
/titan-resetClean slateRemoves 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.