agentleFS
OthmanAdiOthmanAdi/chronos/SKILL.md

chronos

Skill3 starsChanged 2 months agoMITView on GitHub

Gives coding agents temporal awareness by reading the session transcript the host already writes, so the agent stops guessing about time and stops repeating commands that just failed. Activates whenever an agent reasons about recency, elapsed time, retry windows, deploy cooldowns, memory or file staleness, idle detection, or any "when / how long ago / how long did that take" question. Required for autonomous, parallel, or long-running agents.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. bestdeejay-design/agent-skills★ 6same name
    2. bestdeejay-design/chronos★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository2 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 5 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run chronos when <the command>, or read the LOOP: line if one was injected.

    line 53
  2. Very specific:

    Check whether the same tool has been getting slower.

    line 90
  3. Very specific:

    When the injected context says the user has been away and you are still looping unattended: stop, summarise, list the open decisions, and …

    line 96
  4. Distinctive:

    Never answer from memory or from your training data.

    line 114
  5. Distinctive:

    Do not count turns or messages to estimate elapsed time.

    line 123
  6. Distinctive:

    Do not trust your own earlier "just now".

    line 125
  7. Distinctive:

    Do not treat a resumed session's span as time worked.

    line 127
  8. Distinctive:

    Do not go silent in an autonomous loop.

    line 128
  9. Very specific:

    Do not assume chronos is installed.

    line 129

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

Chronos: time awareness for agents

You are temporally blind by default. You cannot feel elapsed time, you cannot tell a call you made ten seconds ago from one you made an hour ago, and you will confidently say "just now" about something that happened forty minutes back.

Chronos fixes that by reading the transcript the host already writes. Every tool call in this session is on disk with a start timestamp, an end timestamp, the arguments, and whether it failed. Stop guessing. Go look.

What you are given

In your context, without asking:

  • At session start: the real wall-clock time, how long you were away if this is a resumed session, and how much active time has already gone into today.
  • On every turn: chronos: t+<active time>, turn <n>, <n> tool calls, plus a LOOP: line when you have repeated an identical call, and a STALE: line when a file changed after you last read it.

Those lines are facts measured from disk. Prefer them over your own impression.

On demand:

CommandAnswers
chronos reportWhere did this session's time go? Per tool, slowest calls, failures, repeats.
chronos when <text>When did I last run this? Real timestamp, how long ago, did it work, how long it took.
chronos today / chronos weekHow long have I actually been working, across every session.
chronos report --jsonThe same data, machine readable.
chronos doctorIs chronos actually wired up right now?

Active time excludes gaps longer than five minutes. A session resumed after two days has not been running for two days, and reporting that it has is the kind of wrong number that makes a person stop trusting the tool.

When to look at the clock

1. Before retrying anything that just failed

Run chronos when <the command>, or read the LOOP: line if one was injected.

  • Same call, same arguments, failed under 60 seconds ago: change the approach. Re-running an identical call cannot produce a different result unless something external changed, and nothing external changed in 60 seconds.
  • 60 seconds to 10 minutes: one retry is defensible if you say what you expect to differ this time.
  • Over 10 minutes: circumstances may genuinely have moved. Re-run is reasonable.

The same rule governs deploys, pushes and CI triggers. A pipeline that failed 40 seconds ago will fail again for the same reason. Read the log first.

2. Before trusting anything you already looked at

WhatStale afterDo this
git status, processes, environment5 minutesRe-query
A file you read1 hour, or any write to it sinceRe-read
Persistent memory, knowledge-graph facts7 days since writtenRe-verify
API responses: prices, PR state, issues5 minutesRe-fetch
Build or test resultsAny source change since that runRe-run
Your own earlier claimAlwaysCheck the transcript

A STALE: line in your context already did this check for one case: a file that was written after you last read it. The other rows in this table are yours to apply, and chronos will not remind you about them.

3. Before summarising or reporting progress

Let the elapsed time set the length:

  • under 5 minutes: answer, no recap;
  • 5 to 30 minutes: one paragraph on what changed;
  • over 30 minutes: chronos report, and use its real numbers.

4. Before starting something long or destructive

Check whether the same tool has been getting slower. chronos report lists the slowest calls and the average per tool. If the last few runs of a command are each well above its average, something is degrading. Say so rather than waiting quietly.

5. Idle detection in autonomous loops

When the injected context says the user has been away and you are still looping unattended: stop, summarise, list the open decisions, and ask. Chronos tells you about an absence once it passes 30 minutes; the statusline shows one from 1 minute. Always escalate past two hours of session time with no user input, whatever either threshold says.

6. Never say "just now" or "in a moment"

Replace every vague interval with a measured one.

  • Wrong: "I just tried that."
  • Right: "That exact command failed 47 seconds ago. Repeating it will not help."
  • Wrong: "Let's wait a bit and retry."
  • Right: "Retry at 14:32 local, three minutes from now."

7. Date and time questions

Never answer from memory or from your training data. In order:

  1. The now line injected at session start, if the session is young.
  2. chronos report, whose numbers come from the transcript's own timestamps.
  3. date -u +"%Y-%m-%dT%H:%M:%SZ", or Get-Date -AsUTC -Format o on PowerShell 7, or Get-Date -Format o on Windows PowerShell 5.1.

Failure modes to avoid

  • Do not count turns or messages to estimate elapsed time. Message count and wall clock are unrelated; one long tool call can span more time than fifty messages.
  • Do not trust your own earlier "just now". The transcript is the record; your context is a summary of it.
  • Do not treat a resumed session's span as time worked. Use active time.
  • Do not go silent in an autonomous loop. Rule 5 always applies.
  • Do not assume chronos is installed. If you never saw a chronos: line in your context, it is not running: fall back to the shell commands below and say so.

Degraded mode: no hooks on this platform

Chronos ships hooks for Claude Code. On a host without them you still follow every rule above, you just gather the facts yourself:

NeedPOSIXPowerShell
Now, UTCdate -u +"%Y-%m-%dT%H:%M:%SZ"Get-Date -Format o
File mtimestat -c %Y f (GNU), stat -f %m f (BSD/macOS)(Get-Item f).LastWriteTimeUtc
Last commit timegit log -1 --format=%cI -- <path>same

State it plainly when you do: "No chronos context in this session; this timestamp comes from date -u."

Why this is a skill and not a note in a prompt

From arxiv 2510.23853, "Your LLM Agents are Temporally Blind" (October 2025): even with timestamps present in context, the strongest frontier models reach only 65% alignment with human temporal judgment, and timestamps appear in under 4% of reasoning traces. Putting a clock in the context is not enough. The model has to be told when to look at it. The seven rules above are that instruction.

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.