Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored.

Apache-2.0Auto-check passedDocuments & Office

Install Impl Tracking

skills CLI
$ npx skills add hashgraph-online/awesome-codex-plugins --skill impl-tracking -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install hashgraph-online/awesome-codex-plugins impl-tracking --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/hashgraph-online/awesome-codex-plugins.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/JuliusBrussee/blueprint/skills/impl-tracking .claude/skills/impl-tracking && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
impl-tracking
GitHub stars
1.2k
Token cost
~4.3k tokens
SKILL.md length
1,168 words
Files
1
Skills in repo
736
Repo updated
First seen
Licence
Apache-2.0

At a glance

Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored.

  • Works in 7 steps: Agent encounters a problem in session 5 → Agent tries approach X — spends 30… → Session ends → …
  • Phrases: implementation tracking
  • SKILL.md covers Core Principle: Track…, Why Implementation Tracking…, Full Implementation Tracking… and Dead Ends: The Most Critical…, plus 6 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Impl Tracking is an agent skill from hashgraph-online/awesome-codex-plugins. Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored. Covers the full tracking document template, dead ends prevention, cross-iteration continuity, spec compaction, and inter-session feedback protocol. Trigger phrases: "implementation tracking", "track progress", "session tracking", "what did the agent do", "dead ends", "failed approaches"

Its SKILL.md is about 4.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Documents & Office. The repository describes itself as: A curated list of awesome OpenAI Codex / ChatGPT plugins, skills, and resources. The 1 Codex Marketplace. See live plugins at: https://hol.org/plugins/best-codex-plugins. The licence is Apache-2.0.

When your agent uses it

  • Phrases: implementation tracking
  • Session tracking
  • What did the agent do
  • Failed approaches

Example prompts

  • “implementation tracking”
  • “track progress”
  • “session tracking”
  • “/impl-tracking”

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Agent encounters a problem in session 5
  2. Agent tries approach X — spends 30 minutes, fails
  3. Session ends
  4. In session 6, a new agent encounters the same problem
  5. Agent has no memory of session 5's failure
  6. Agent tries approach X again — wastes another 30 minutes
  7. This repeats indefinitely

What it can do on your machine

Read from SKILL.md and the folder at commit 16b4156. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown and xml).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Impl Tracking loads about 4.3k tokens when it runs. Until then it costs about 112 tokens; SKILL.md has 1,168 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~112
When it runs · the whole SKILL.md, loaded when a task matches
~4.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from hashgraph-online/awesome-codex-plugins at commit 16b4156, republished under its Apache-2.0 licence (© hashgraph-online). 1,168 words, ~4,318 tokens.

Download SKILL.mdSave it as .claude/skills/impl-tracking/SKILL.md (or your agent's skills folder).
name
impl-tracking
description
Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored. Covers the full tracking document template, dead ends prevention, cross-iteration continuity, spec compaction, and inter-session feedback protocol. Trigger phrases: "implementation tracking", "track progress", "session tracking", "what did the agent do", "dead ends", "failed approaches"

Implementation Tracking

Core Principle: Track Everything, Especially Failures

Implementation tracking documents are living records that agents read and update every session. They serve as persistent memory across iterations, preventing duplicate work and preserving hard-won knowledge about what works and what does not.

The most valuable information in an implementation tracking document is not what succeeded — it is what failed and why. Dead ends documented today prevent agents from wasting hours retrying the same failed approaches tomorrow.


Why Implementation Tracking Matters

PurposeWhat It Prevents
Cross-iteration continuityAgents starting from scratch every session
Dead end preventionAgents retrying approaches that already failed
Progress visibilityHumans not knowing what was done or what is left
Test health awarenessAgents not knowing current test state
Issue trackingKnown issues being forgotten between sessions
File change trackingUncertainty about what files were created or modified

Without implementation tracking, every agent session begins with expensive rediscovery. With it, agents resume exactly where the last session left off.


Full Implementation Tracking Document Template

Use this template for every implementation tracking document:

markdown
# Implementation Tracking: {Domain or Scope}

## Status: {IN_PROGRESS | COMPLETE | BLOCKED}

**Last Updated:** {Date}
**Current Phase:** {Spec | Plan | Implement | Iterate | Monitor}
**Blocking Issues:** {None | Brief description of blockers}

---

## Task Status

| Task ID | Task | Status | Notes |
|---------|------|--------|-------|
| T-1 | {Task description} | DONE | {Completion notes} |
| T-2 | {Task description} | DONE | {Completion notes} |
| T-3 | {Task description} | IN_PROGRESS | {Current state, what remains} |
| T-4 | {Task description} | BLOCKED | {What is blocking, dependency} |
| T-5 | {Task description} | NOT_STARTED | {Prerequisites} |

### Task Dependencies
- T-4 blockedBy T-3 (needs auth module before API integration)
- T-5 blockedBy T-3, T-4

---

## Files Created

| File | Purpose | Spec Reference |
|------|---------|---------------|
| `src/auth/login.{ext}` | Login handler | spec-auth.md R1 |
| `src/auth/session.{ext}` | Session management | spec-auth.md R2 |
| `tests/auth/login.test.{ext}` | Login unit tests | spec-auth.md R1 AC1-3 |

## Files Modified

| File | Change | Reason |
|------|--------|--------|
| `src/app.{ext}` | Added auth middleware | spec-auth.md R3 |
| `src/config.{ext}` | Added session config | spec-auth.md R2 |

---

## Issues & TODOs

- [ ] **Issue:** Session expiry not tested under concurrent access — need load test
- [ ] **TODO:** Add rate limiting to login endpoint (spec-api.md R7)
- [ ] **TODO:** Implement password reset flow (spec-auth.md R4, NOT_STARTED)
- [x] **Resolved:** TypeScript compilation error in session.ts — fixed incorrect import path

---

## Dead Ends & Failed Approaches

### DE-1: JWT with asymmetric keys for session tokens
**What was attempted:** Implemented RS256 JWT tokens with public/private key pair.
**Root cause of failure:** Key rotation complexity exceeded the session management requirements. Added 200+ lines of key management code for no user-visible benefit. Symmetric HS256 with server-side session store is simpler and meets all spec criteria.
**Verdict:** Do not reattempt. Use symmetric tokens with server-side sessions instead.

### DE-2: Redis for session storage
**What was attempted:** Used Redis as the session store backend.
**Root cause of failure:** Redis dependency adds operational complexity. The application's expected concurrent user count (< 10,000) is well within what a database-backed session store handles. Redis would be premature optimization.
**Verdict:** Do not reattempt unless concurrent user requirements change significantly (> 100,000).

### DE-3: Cookie-based CSRF protection
**What was attempted:** Double-submit cookie pattern for CSRF.
**Root cause of failure:** Incompatible with the API's token-based auth flow. Clients send bearer tokens in headers, not cookies. CSRF protection is inherently handled by the token-based approach.
**Verdict:** Do not reattempt. Token-based auth does not need separate CSRF protection.

---

## Test Health

| Test Suite | Passing | Failing | Skipped | Line Coverage |
|------------|---------|---------|---------|---------------|
| Unit tests | 45 | 2 | 0 | 78% |
| Integration | 12 | 1 | 3 | n/a |
| E2E | 0 | 0 | 0 | n/a |

### Failing Tests
- `tests/auth/session.test.{ext}:34` — Session refresh fails when token is expired more than 24h. Needs spec clarification on refresh window.
- `tests/integration/api-auth.test.{ext}:89` — Timeout on concurrent login test. Likely race condition in session creation.

### Test Notes
- E2E tests not yet created (blocked on T-4: API integration)
- Integration test skip: 3 tests require external OAuth provider mock (TODO)

---

## Session Log

### Session 3 (current)
- Completed T-2 (session management)
- Started T-3 (API integration) — 60% complete
- Discovered DE-3 (CSRF not needed with token auth)
- 2 new failing tests identified

### Session 2
- Completed T-1 (login handler)
- Discovered DE-1 (JWT asymmetric keys too complex)
- Discovered DE-2 (Redis premature for this scale)
- Test health: 38 pass, 0 fail

### Session 1
- Set up auth module structure
- Created initial test scaffolding
- Established file ownership: auth/ owned by auth-agent

Dead Ends: The Most Critical Section

Dead ends prevent agents from retrying failed approaches. This is the single most important function of implementation tracking.

Why Dead Ends Matter

Without dead end documentation:

  1. Agent encounters a problem in session 5
  2. Agent tries approach X — spends 30 minutes, fails
  3. Session ends
  4. In session 6, a new agent encounters the same problem
  5. Agent has no memory of session 5's failure
  6. Agent tries approach X again — wastes another 30 minutes
  7. This repeats indefinitely

With dead end documentation:

  1. Agent encounters a problem in session 5
  2. Agent tries approach X — spends 30 minutes, fails
  3. Agent documents the dead end: what was tried, why it failed, what to do instead
  4. In session 6, a new agent reads the dead end
  5. Agent skips approach X and uses the recommended alternative
  6. Problem solved in 5 minutes instead of 30
Dead End Format

Every dead end entry must include:

markdown
### DE-{N}: {Short description of the approach}
**What was attempted:** {Specific description of the approach taken}
**Root cause of failure:** {Why it did not work — a clear technical explanation, not just "it broke"}
**Verdict:** Do not reattempt. {Recommended alternative, or conditions under which the approach might become viable}
Rules for Dead Ends
  1. Always document the root cause. "It didn't work" is not useful. "Failed because the library's async API is incompatible with the synchronous middleware chain" is useful.
  2. Include the alternative. What should be done instead?
  3. Be specific about conditions. If a retry might make sense under different conditions, state those conditions explicitly.
  4. Never delete dead ends during compaction unless they are older than 5 sessions and the underlying conditions have changed.

Cross-Iteration Continuity

Implementation tracking documents are the primary mechanism for continuity between iteration loop passes and between human-initiated sessions.

How Agents Use Tracking Documents

At the start of every iteration or session, the agent:

  1. Reads the tracking document to understand current state
  2. Checks task status to identify the highest-priority unblocked work
  3. Reviews dead ends to avoid retrying failed approaches
  4. Checks test health to understand what is passing and failing
  5. Reviews open issues for context on known problems

At the end of every iteration or session, the agent:

  1. Updates task status for all tasks worked on
  2. Records new files created or modified
  3. Documents any dead ends discovered
  4. Updates test health with current pass/fail counts
  5. Adds issues for any new problems found
  6. Updates the session log with a summary of work done
The Read-Work-Update Cycle
┌─────────────────────────────────────┐
│  1. Read impl tracking              │
│  2. Identify highest-priority task  │
│  3. Check dead ends for this area   │
│  4. Implement                       │
│  5. Run validation gates            │
│  6. Update impl tracking            │
│  7. Commit                          │
└─────────────────────────────────────┘
        ↓ (next iteration)
┌─────────────────────────────────────┐
│  1. Read impl tracking (updated)    │
│  2. ...                             │
└─────────────────────────────────────┘

Spec Compaction

When implementation tracking files exceed approximately 500 lines, they become unwieldy for agents to process. Compaction compresses the file while preserving active context.

When to Compact
  • File exceeds 500 lines
  • More than half the tasks are DONE
  • Session log has more than 5 entries
  • Dead ends section has entries older than 5 sessions that are no longer relevant
Compaction Process
  1. Create archive: Copy current file to impl/archive/impl-{scope}-v{N}.md
  2. Remove from active file:
    • Completed tasks (keep only a count: "12 tasks completed, see archive")
    • Resolved issues (marked with [x])
    • Old session log entries (keep last 2-3 sessions)
    • Dead ends older than 5 sessions IF the underlying conditions changed
  3. Preserve in active file:
    • All IN_PROGRESS and NOT_STARTED tasks
    • All BLOCKED tasks with their blockers
    • All open issues
    • Recent dead ends (last 3-5 sessions)
    • Current test health
    • Active cross-references
    • Files created/modified (keep all — this is the file manifest)
  4. Target: Under 500 lines in the active file
  5. Add archive reference:
    markdown
    > **Archive:** Previous tracking history available in impl/archive/impl-all-v2.md
    > 12 tasks completed in prior sessions. See archive for details.
Show full SKILL.md (447 more words)Show less
Compaction Rules
  • Never delete information — always archive first
  • Never remove active dead ends — they prevent retrying failures
  • Always keep the full file manifest — agents need to know what files exist
  • Preserve test health — agents need current state, not historical

Inter-Session Feedback Protocol

For structured handoffs between sessions (especially when different humans or automation systems manage sessions), use the inter-session feedback protocol.

XML Format
xml
<session-report>
  <session-id>2026-03-14-session-3</session-id>
  <timestamp>2026-03-14T14:30:00Z</timestamp>

  <task id="T-1">
    <title>Implement session management</title>
    <status>DONE</status>
    <files-modified>true</files-modified>
    <summary>
      Implemented session creation, validation, and refresh.
      Added server-side session store with database backend.
      Created 3 new files, modified 2 existing files.
    </summary>
    <obstacles kind="NONE"></obstacles>
    <next-steps>
      Proceed to API integration (T-3). Session module is ready.
    </next-steps>
  </task>

  <task id="T-2">
    <title>API endpoint integration</title>
    <status>PARTIAL</status>
    <files-modified>true</files-modified>
    <summary>
      Completed GET /users and POST /login endpoints.
      PUT /users and DELETE /users not started.
    </summary>
    <obstacles kind="TEMPORARY">
      Waiting for session management to stabilize (now done).
    </obstacles>
    <next-steps>
      Continue with PUT/DELETE endpoints. All dependencies resolved.
    </next-steps>
  </task>

  <task id="T-3">
    <title>OAuth provider integration</title>
    <status>BLOCKED</status>
    <files-modified>false</files-modified>
    <summary>
      Investigation complete. OAuth provider requires API key registration.
    </summary>
    <obstacles kind="PERMANENT">
      Cannot proceed without OAuth API credentials.
      Human action required: register application with OAuth provider.
    </obstacles>
    <next-steps>
      Skip until credentials are available. Focus on other tasks.
    </next-steps>
  </task>
</session-report>
Field Definitions
FieldValuesPurpose
statusDONE, PARTIAL, BLOCKEDCurrent state of the work item
files-modifiedtrue, falseWhether code was modified (helps humans prioritize review)
summaryFree textWhat was accomplished — be specific
obstacles.kindNONE, TEMPORARY, PERMANENTTEMPORARY = will resolve on its own; PERMANENT = requires human action
next-stepsFree textWhat the next session should do with this item
When to Use the Feedback Protocol
  • Between human-managed sessions: When a human starts each session and needs to know what happened
  • Automation handoffs: When an orchestration system decides what to work on next
  • Work queue generation: The /ck:next-session command consumes this feedback to generate prioritized work items

For the full session feedback protocol reference, see references/session-feedback-protocol.md.


Work Queue Handoff

At the end of a session, generate a plan-next-session.md that prioritizes work for the next session:

markdown
# Next Session Work Queue

## WI-1: Complete API endpoint integration
- **Category:** feature
- **Size:** M
- **Priority:** high
- **Spec reference:** plan-api.md
- **What to do:** Implement PUT /users and DELETE /users endpoints
- **Files to modify:** src/api/users.{ext}, tests/api/users.test.{ext}
- **Acceptance criteria:**
  - [ ] PUT /users/{id} updates user record and returns 200
  - [ ] DELETE /users/{id} removes user and returns 204
  - [ ] Both endpoints require valid session token

## WI-2: Fix failing session refresh test
- **Category:** bugfix
- **Size:** S
- **Priority:** medium
- **Spec reference:** plan-auth.md
- **What to do:** Investigate and fix session refresh failure for tokens expired > 24h
- **Files to modify:** src/auth/session.{ext}, tests/auth/session.test.{ext}
- **Acceptance criteria:**
  - [ ] Session refresh test passes for tokens expired < 24h
  - [ ] Clear error message for tokens expired > 24h (if that is the intended behavior)

## WI-3: Create E2E test scaffolding
- **Category:** test
- **Size:** M
- **Priority:** medium
- **Spec reference:** plan-testing.md
- **What to do:** Set up E2E test framework and create smoke tests
- **Files to modify:** tests/e2e/setup.{ext}, tests/e2e/smoke.test.{ext}
- **Acceptance criteria:**
  - [ ] E2E framework runs successfully
  - [ ] Smoke test verifies application starts and login works

This removes the orientation cost at the start of each session — agents begin productive work immediately. The next agent reads this file and begins working immediately on the highest-priority item.


Integration with Other Skills

With ck:cavekit-writing

Implementation tracking references specs by requirement ID. When a task is completed, its acceptance criteria map back to spec requirements. When dead ends are found, they may reveal spec gaps that need revision.

With ck:validation-first

Test health in the tracking document reflects validation gate results. Failing tests indicate which gates are not passing. The tracking document records which gates each task must clear.

With ck:context-architecture

Implementation tracking documents live in context/impl/. When files grow too large, archive to context/impl/archive/. The CLAUDE.md in context/impl/ instructs agents on tracking conventions.

With ck:methodology

Implementation tracking is used primarily during the Implement and Iterate phases of the Hunt. The iteration loop reads and updates tracking documents every pass. The Monitor phase reviews tracking documents for progress signals.


Summary

  1. Track everything, especially failures — dead ends are the most valuable information
  2. Use the template — consistent format lets agents parse tracking documents reliably
  3. Update every session — stale tracking is worse than no tracking
  4. Document dead ends with root causes — "it didn't work" is not useful; "failed because X, do Y instead" is
  5. Compact when large — archive resolved content, keep active files under 500 lines
  6. Use the feedback protocol for structured handoffs between sessions
  7. Generate work queues to eliminate discovery overhead at session start

© hashgraph-online, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/JuliusBrussee/blueprint/skills/impl-tracking of hashgraph-online/awesome-codex-plugins.

Open the folder on GitHubat commit 16b4156

Compare with similar skills

Impl Tracking next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Impl Tracking compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Impl Tracking this skillhashgraph-online/awesome-codex-plugins1.2k—~4.3kAutomated safety check: PassApache-2.0
Markdown Article FormatterJimLiu/baoyu-skills26k6 repos~3.5kAutomated safety check: PassMIT
MarkitdownImCa0/just-laws78114 repos~3.2kAutomated safety check: NotesMIT
Obsidian MarkdownAtmosphere/atmosphere3.8k20 repos~1.3kAutomated safety check: PassApache-2.0
DOCXrvdbreemen/OTGW-firmware20733 repos~4.3kAutomated safety check: PassProprietary
Gzh Designisjiamu/gzh-design-skill3.9k1 repos~2.2kAutomated safety check: PassAGPL-3.0

Similar skills

  • Markdown Article Formatter

    JimLiu/baoyu-skills

    Reformats plain text or Markdown articles with frontmatter, a title, a summary, headings, bold, lists and code blocks, and saves a separate formatted copy.

    26k GitHub starsUsed in 6 repos~3.5k tokens
    Documents & OfficeAuto-check passed
  • Markitdown

    ImCa0/just-laws

    Convert files and office documents to Markdown. An agent skill from ImCa0/just-laws.

    781 GitHub starsUsed in 14 repos~3.2k tokens
    Documents & OfficeAuto-check: notes
  • Obsidian Markdown

    Atmosphere/atmosphere

    Create and edit Obsidian Flavored Markdown with wikilinks, embeds, callouts, properties, and other Obsidian-specific syntax.

    3.8k GitHub starsUsed in 20 repos~1.3k tokens
    Documents & OfficeAuto-check passed
  • DOCX

    rvdbreemen/OTGW-firmware

    A skill your agent uses whenever the user wants to create, read, edit, or manipulate Word documents (.docx files).

    207 GitHub starsUsed in 33 repos~4.3k tokens
    Documents & OfficeAuto-check passed
  • Gzh Design

    isjiamu/gzh-design-skill

    微信公众号文章排版引擎,将 Markdown 转换为可直接粘贴到公众号编辑器的 HTML。主题风格从 references/theme-index.md 注册的自定义主题库中选取,自动章节编号、关键词下划线标记、引言卡片、目录导航、代码块、图片/GIF、作者签名。支持 Markdown / Word(.docx) / PDF / 纯文本输入(非 Markdown…

    3.9k GitHub starsUsed in 1 repo~2.2k tokens
    Documents & OfficeAuto-check passed
  • Reads, creates and edits Word .docx files with python-docx, and drops to raw OOXML for tracked changes, comments and byte-exact edits.

    41k GitHub stars~2.5k tokensUpdated 3 days ago
    Documents & OfficeAuto-check passed

More from hashgraph-online/awesome-codex-plugins

All 736 skills in this repo
  • Anime Reaction Gif

    hashgraph-online/awesome-codex-plugins

    Create original anime-style reaction stickers as looping GIFs and MP4 previews, using generated character pose sheets and timed key poses.

    1.2k GitHub stars~922 tokensUpdated yesterday
    Auto-check passed
  • Calibredb

    hashgraph-online/awesome-codex-plugins

    Manage and query Calibre libraries with the calibredb CLI (local paths or Calibre Content server URLs).

    1.2k GitHub stars~1k tokensUpdated yesterday
    Auto-check passed
  • Rust API Test Harness

    hashgraph-online/awesome-codex-plugins

    A skill your agent uses when adding, changing, testing, or debugging Rust HTTP APIs and services, especially when Codex needs black-box integration tests, random-port app startup, real database test…

    1.2k GitHub stars~1.7k tokensUpdated yesterday
    Auto-check passed
  • Art

    hashgraph-online/awesome-codex-plugins

    Make a studio's game look like something at build time — a cover from a real frame of the game (free), painted covers, backdrops, textures and character plates from image models through the…

    1.2k GitHub stars~2.4k tokensUpdated yesterday
    Auto-check passed
  • Calle

    hashgraph-online/awesome-codex-plugins

    Use CALL-E from Codex through the calle CLI. An agent skill from hashgraph-online/awesome-codex-plugins.

    1.2k GitHub stars~2.9k tokensUpdated yesterday
    Auto-check passed
  • Game Balance Economy

    hashgraph-online/awesome-codex-plugins

    Balance game difficulty, resources, rewards, probability, progression, economies, and dominant strategies.

    1.2k GitHub stars~618 tokensUpdated yesterday
    Auto-check passed

Questions about Impl Tracking

What does Impl Tracking do?

Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored. Impl Tracking is an agent skill from hashgraph-online/awesome-codex-plugins. Implementation tracking documents for maintaining living records of what was built, what is pending, what failed, and what dead ends were explored.

When should I use Impl Tracking?

Impl Tracking fits situations like: phrases: implementation tracking; session tracking; what did the agent do; failed approaches.

How do I install Impl Tracking in Claude Code?

Run `npx skills add hashgraph-online/awesome-codex-plugins --skill impl-tracking -a claude-code`. Or copy the skill folder (plugins/JuliusBrussee/blueprint/skills/impl-tracking in hashgraph-online/awesome-codex-plugins) into .claude/skills/impl-tracking in your project. Claude Code loads it when a task matches its description.

How do I install Impl Tracking in Codex?

Run `npx skills add hashgraph-online/awesome-codex-plugins --skill impl-tracking -a codex`. Or copy the skill folder (plugins/JuliusBrussee/blueprint/skills/impl-tracking in hashgraph-online/awesome-codex-plugins) into .agents/skills/impl-tracking in your project. Codex loads it when a task matches its description.

Can I use Impl Tracking in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add hashgraph-online/awesome-codex-plugins --skill impl-tracking -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/impl-tracking, .gemini/skills/impl-tracking, .github/skills/impl-tracking and .opencode/skills/impl-tracking in your project.

What does Impl Tracking need to run?

SKILL.md names no scripts, command-line tools or credentials: Impl Tracking is instructions for the agent only.

Does Impl Tracking access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Impl Tracking safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Impl Tracking use?

Impl Tracking is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Impl Tracking use?

About 4.3k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Impl Tracking?

Skills that share tags, products or a category with Impl Tracking: Markdown Article Formatter (JimLiu/baoyu-skills, 26k stars), Markitdown (ImCa0/just-laws, 781 stars), Obsidian Markdown (Atmosphere/atmosphere, 3.8k stars) and DOCX (rvdbreemen/OTGW-firmware, 207 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Impl Tracking?

hashgraph-online (a GitHub organization) maintains it in hashgraph-online/awesome-codex-plugins, which has 1,232 GitHub stars. The repository holds 736 skills in this directory. The repository was last updated on October 6, 2026.

Source: hashgraph-online/awesome-codex-plugins on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.