一个只包含你仓库内的Markdown文件的工单追踪器。不 数据库，且不存储任何板式视图——只绘制了唯一的视图 从文件夹中实时传输。构建为 Claude Code 插件， 不过这种格式手工操作同样有效。

“Kerjaan”在印尼语中意为“工作”——需要完成的事情。

它解决的问题

工单通常是为已经熟悉代码库的人写的。那 悄悄地把其他人都锁在外面——客户、经理、同事—— 另一个团队——所以他们每个问题都必须被大声回答 一个知道的人。

kerjaan 推送票单自包含：打开一个文件，且 只要了解系统背景，读者就能立刻明白是什么 正在发生的事情以及被问的内容。

而且因为它只是仓库里的文件，历史记录会随代码一起传播， 没有服务需要运行、托管或付费。

董事会

settings.md 写一次，首次使用该棋盘时：Claude 会从仓库中宣读价值并要求你确认。它是 test_command 每次切换执行一次，而非两次：参见“检查运行一次” 如下。

文件名： .md，例如。

kerjaan

A ticket tracker that is nothing but markdown files inside your repo. No database, and no board view stored anywhere — the one view there is gets drawn live from the folders. Built as a Claude Code plugin, though the format works just as well by hand.

“Kerjaan” is Indonesian for “work” — the stuff that needs doing.

The problem it solves

Tickets are usually written for people who already know the codebase. That quietly locks out everyone else — the client, the manager, the colleague from another team — so every question they have has to be answered out loud by somebody who does know.

kerjaan pushes tickets to be self-contained: one file is opened, with no context about the system at all, and the reader immediately understands what is happening and what is being asked.

And because it is only files in a repo, the history travels with the code and there is no service to run, host, or pay for.

The board

/.kerjaan/
├── backlog/      ideas, not ready to act on
├── todo/         the queue for one work session: ready, not started
├── in_progress/  being worked on
├── review/       done, not yet verified
├── done/         passed review
├── cancel/       abandoned
├── order.md      the order of the work in todo and in flight — optional
├── settings.md   language, test command, long-lived branches,
│                 side-by-side tests and worktree setup, how far
│                 the chain runs, when the handoff is written
└── handoff.md    the foreman's handoff across a summary — only for
                  a moment, ignored by git

settings.md is written once, the first time the board is used: Claude proposes values read off the repo and asks you to confirm them. Its test_command is run once per handover, not twice: see “The checks run once” below.

File name: .md, for example 260905160401 Send notifications through Telegram.md.

The ID has the form yymmddhhmmxx — creation time down to the minute, plus a two-digit sequence number.

What a ticket looks like

---
type: bug
priority: high
review: normal
labels: [telegram-bot]
reporter: mirza
assign_to: claude
created: 2026-09-05 16:04:01
updated: 2026-09-06 14:02:10
related: []
blocked_by: []
---

## Background
The Telegram bot checks for new messages every few seconds. When two messages
arrive at nearly the same moment, one of them is sometimes skipped and that
person never gets a reply.

## How to reproduce
1. Open a chat with the bot
2. Send three short messages within one second of each other
3. Wait ten seconds

Only two replies come back. The third message gets no answer at all, and
nothing anywhere says it was dropped.

## Request
Messages that arrive together must all still get a reply, with none lost.

## Done when
- [ ] The steps above produce three replies rather than two
- [ ] Run for a full day with no reports of a missed message

## History