Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
alirezarezvani avatar

Tc Tracker

  • 540 installs
  • 23.5k repo stars
  • Updated July 17, 2026
  • alirezarezvani/claude-skills

tc-tracker is a Claude Code skill that tracks technical changes with a strict lifecycle, file-level audit trail, and AI session handoffs for developers who pause and resume agent work without losing context.

About

tc-tracker is a technical change management skill backed by Python CLI scripts that enforce a strict state machine, append-only revision history, and session-handoff blocks for AI coding agents. Initialize tracking with tc_init.py, create changes via tc_create.py with scope and priority flags, and advance states through tc_update.py while recording file-level edits. Developers reach for tc-tracker when long-running agent sessions risk losing context between pauses, when multiple agents touch the same feature, or when an audit trail of what changed and why is required. The handoff block lets a fresh session resume in-progress work with full TC state.

  • Strict TC state machine with append-only revision history
  • Four CLI scripts: tc_init, tc_create, tc_update, tc_status under docs/TC/
  • Atomic updates for status, touched files, and structured session handoff blocks
  • Sequential TC IDs and scope/priority metadata on create
  • Idempotent project init for docs/TC/ layout

Tc Tracker by the numbers

  • 540 all-time installs (skills.sh)
  • Ranked #721 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/alirezarezvani/claude-skills --skill tc-tracker

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs540
repo stars23.5k
Security audit3 / 3 scanners passed
Last updatedJuly 17, 2026
Repositoryalirezarezvani/claude-skills

How do you hand off in-progress AI coding sessions?

Track technical changes (TCs) with a strict lifecycle, file-level audit trail, and AI session handoffs so you can pause and resume agent work without losing context.

Who is it for?

Developers running multi-session Claude Code or Cursor agents on features that need tracked state and clean handoffs.

Skip if: Skip tc-tracker for one-shot prompts or when Git commits alone provide sufficient change history without agent session continuity.

When should I use this skill?

An agent session needs to pause, resume, or track a technical change with structured lifecycle states and handoff context.

What you get

TC records with state history, file-level audit trail, and session-handoff blocks for agent resume.

  • TC state records
  • session-handoff block
  • file-level audit log

By the numbers

  • Bundles 3 Python CLI scripts: tc_init.py, tc_create.py, and tc_update.py

Files

SKILL.mdMarkdownGitHub ↗

TC Tracker

Track every code change with structured JSON records, an enforced state machine, and a session handoff format that lets a new AI session resume work cleanly when a previous one expires.

Overview

A Technical Change (TC) is a structured record that captures what changed, why it changed, who changed it, when it changed, how it was tested, and where work stands for the next session. Records live as JSON in docs/TC/ inside the target project, validated against a strict schema and a state machine.

Use this skill when the user:

  • Asks to "track this change" or wants an audit trail for code modifications
  • Wants to hand off in-progress work to a future AI session
  • Needs structured release notes that go beyond commit messages
  • Onboards an existing project and wants retroactive change documentation
  • Asks for /tc init, /tc create, /tc update, /tc status, /tc resume, or /tc close

Do NOT use this skill when:

  • The user only wants a changelog from git history (use engineering/changelog-generator)
  • The user only wants to track tech debt items (use engineering/tech-debt-tracker)
  • The change is trivial (typo, formatting) and won't affect behavior

Storage Layout

Each project stores TCs at {project_root}/docs/TC/:

docs/TC/
├── tc_config.json          # Project settings
├── tc_registry.json        # Master index + statistics
├── records/
│   └── TC-001-04-05-26-user-auth/
│       └── tc_record.json  # Source of truth
└── evidence/
    └── TC-001/             # Log snippets, command output, screenshots

TC ID Convention

  • Parent TC: TC-NNN-MM-DD-YY-functionality-slug (e.g., TC-001-04-05-26-user-authentication)
  • Sub-TC: TC-NNN.A or TC-NNN.A.1 (letter = revision, digit = sub-revision)
  • NNN is sequential, MM-DD-YY is the creation date, slug is kebab-case.

State Machine

planned -> in_progress -> implemented -> tested -> deployed
   |            |              |           |          |
   +-> blocked -+              +- in_progress <-------+
        |                          (rework / hotfix)
        +-> planned
See references/lifecycle.md for the full transition table and recovery flows.

Workflow Commands

The skill ships five Python scripts that perform deterministic, stdlib-only operations on TC records. Each one supports --help and --json.

1. Initialize tracking in a project

python3 scripts/tc_init.py --project "My Project" --root .

Creates docs/TC/, docs/TC/records/, docs/TC/evidence/, tc_config.json, and tc_registry.json. Idempotent — re-running reports "already initialized" with current stats.

2. Create a new TC record

python3 scripts/tc_create.py \
  --root . \
  --name "user-authentication" \
  --title "Add JWT-based user authentication" \
  --scope feature \
  --priority high \
  --summary "Adds JWT login + middleware" \
  --motivation "Required for protected endpoints"

Generates the next sequential TC ID, creates the record directory, writes a fully populated tc_record.json (status planned, R1 creation revision), and updates the registry.

3. Update a TC record

# Status transition (validated against the state machine)
python3 scripts/tc_update.py --root . --tc-id TC-001-04-05-26-user-auth \
  --set-status in_progress --reason "Starting implementation"

# Add a file
python3 scripts/tc_update.py --root . --tc-id TC-001-04-05-26-user-auth \
  --add-file src/auth.py:created

# Append handoff data
python3 scripts/tc_update.py --root . --tc-id TC-001-04-05-26-user-auth \
  --handoff-progress "JWT middleware wired up" \
  --handoff-next "Write integration tests" \
  --handoff-next "Update README"

Every change appends a sequential R<n> revision entry, refreshes updated, and re-validates against the schema before writing atomically (.tmp then rename).

4. View status

# Single TC
python3 scripts/tc_status.py --root . --tc-id TC-001-04-05-26-user-auth

# All TCs (registry summary)
python3 scripts/tc_status.py --root . --all --json

5. Validate a record or registry

python3 scripts/tc_validator.py --record docs/TC/records/TC-001-.../tc_record.json
python3 scripts/tc_validator.py --registry docs/TC/tc_registry.json

Validator enforces the schema, checks state-machine legality, verifies sequential R<n> and T<n> IDs, and asserts approval consistency (approved=true requires approved_by and approved_date).

See references/tc-schema.md for the full schema.

Slash-Command Dispatcher

The repo ships a /tc slash command at commands/tc.md that dispatches to these scripts based on subcommand:

CommandAction
/tc initRun tc_init.py for the current project
/tc create <name>Prompt for fields, run tc_create.py
/tc update <tc-id>Apply user-described changes via tc_update.py
/tc status [tc-id]Run tc_status.py
/tc resume <tc-id>Display handoff, archive prior session, start a new one
/tc close <tc-id>Transition to deployed, set approval
/tc exportRe-render all derived artifacts
/tc dashboardRe-render the registry summary

The slash command is the user interface; the Python scripts are the engine.

Session Handoff Format

The handoff block lives at session_context.handoff inside each TC and is the single most important field for AI continuity. It contains:

  • progress_summary — what has been done
  • next_steps — ordered list of remaining actions
  • blockers — anything preventing progress
  • key_context — critical decisions, gotchas, patterns the next bot must know
  • files_in_progress — files being edited and their state (editing, needs_review, partially_done, ready)
  • decisions_made — architectural decisions with rationale and timestamp
See references/handoff-format.md for the full structure and fill-out rules.

Validation Rules (Always Enforced)

1. State machine — only valid transitions are allowed. 2. Sequential IDsrevision_history uses R1, R2, R3...; test_cases uses T1, T2, T3.... 3. Append-only history — revision entries are never modified or deleted. 4. Approval consistencyapproved=true requires approved_by and approved_date. 5. TC ID format — must match TC-NNN-MM-DD-YY-slug. 6. Sub-TC ID format — must match TC-NNN.A or TC-NNN.A.N. 7. Atomic writes — JSON is written to .tmp then renamed. 8. Registry stats — recomputed on every registry write.

Non-Blocking Bookkeeping Pattern

TC tracking must NOT interrupt the main workflow.

  • Never stop to update TC records inline. Keep coding.
  • At natural milestones, spawn a background subagent to update the record.
  • Surface questions only when genuinely needed ("This work doesn't match any active TC — create one?"), and ask once per session, not per file.
  • At session end, write a final handoff block before closing.

Retroactive Bulk Creation

For onboarding an existing project with undocumented history, build a retro_changelog.json (one entry per logical change) and feed it to tc_create.py in a loop, or extend the script for batch mode. Group commits by feature, not by file.

Anti-Patterns

Anti-patternWhy it's badDo this instead
Editing revision_history to "fix" a typoHistory is append-only — tampering destroys the audit trailAdd a new revision that corrects the field
Skipping the state machine ("just set status to deployed")Bypasses validation and hides skipped phasesWalk through in_progress -> implemented -> tested -> deployed
Creating one TC per file changedFragments related work and explodes the registryOne TC per logical unit (feature, fix, refactor)
Updating TC inline between every code editSlows the main agent, wastes contextSpawn a background subagent at milestones
Marking approved=true without approved_byValidator will reject; misleading audit trailAlways set approved_by and approved_date together
Overwriting tc_record.json directly with a text editorRisks corruption mid-write and skips validationUse tc_update.py (atomic write + schema check)
Putting secrets in notes or evidenceRecords are committed to the repoReference an env var or external secret store
Reusing TC IDs after deletionBreaks the sequential guarantee and confuses historyIncrement forward only — never recycle
Letting next_steps go staleDefeats the purpose of handoffUpdate on every milestone, even if it's "nothing changed"

Cross-References

  • engineering/changelog-generator — Generates Keep-a-Changelog release notes from Conventional Commits. Pair it with TC tracker: TC for the granular per-change audit trail, changelog for user-facing release notes.
  • engineering/tech-debt-tracker — For tracking long-lived debt items rather than discrete code changes.
  • engineering/focused-fix — When a bug fix needs systematic feature-wide repair, run /focused-fix first then capture the result as a TC.
  • project-management/decision-log — Architectural decisions made inside a TC's decisions_made block can also be promoted to a project-wide decision log.
  • engineering-team/code-reviewer — Pre-merge review fits naturally into the tested -> deployed transition; capture the reviewer in approval.approved_by.

References in This Skill

  • references/tc-schema.md — Full JSON schema for TC records and the registry.
  • references/lifecycle.md — State machine, valid transitions, and recovery flows.
  • references/handoff-format.md — Session handoff structure and best practices.

Related skills

FAQ

What scripts does tc-tracker include?

tc-tracker ships Python CLI scripts tc_init.py to initialize project tracking, tc_create.py to open new technical changes with metadata, and tc_update.py to advance states and log file-level work.

How does tc-tracker help AI session handoffs?

tc-tracker writes append-only revision history and a session-handoff block per technical change so a new AI session can read TC state and resume in-progress work without lost context.

Is Tc Tracker safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.