Project Tracking
@dev-project
Runs a development project from start to result — sets up the project folder, a journal (status, decisions, what's next), a task checklist, and memory across sessions, so work resumes where it left off instead of from scratch. Use when the user says «начнём проект», «на чём мы остановились», «что дальше», «сохрани прогресс», «возобнови работу», «покажи статус». Do NOT use for writing code (dev-build), testing (dev-test), deployment (dev-deploy), or requirements (dev-spec).
Who the Project Tracking skill is for
- Anyone returning to work over days and weeks — pick up where you left off, not from scratch.
- Solo developers and freelancers — keep status, decisions and a checklist in one journal.
- MVP teams — tie the spec → code → tests stages together with one memory.
- Anyone running several projects — an index of projects with paths and statuses.
What you can do
- Set up a project — a folder,
SPEC.mdand aDEV-JOURNAL.mdjournal, plus an entry in the project index. - Resume work — at the start of each session read the journal and briefly restate where you stopped and what's next.
- Log a decision — what was chosen, why, and which alternatives were rejected, right at the moment of choice.
- Keep a task checklist — a live status of slices: what's done, what's next, what was deferred from the MVP.
Related skills: Spec & Architecture, Build, Test & Debug.
How it works: two levels of memory
The agent memory (global) remembers the user — OS, installed runtimes, preferred stack and cross-project principles; learned once, never asked again. The project journal (per-project) remembers the specific work — status, decisions, bugs and the checklist. Every new session on an existing project starts with a resume protocol: read the memory → find the journal → restate the status → continue from the first unfinished task. That turns «start over» into «continue».
Useful details
- Log immediately rule: learned, decided or finished — write it down at once, not deferred to the end of the session.
- The slice checklist lives in the journal, while the session's active work lives in todowrite; a finished task is marked in both.
- Journal up to ~150 lines: if it grows, the old part is archived.
- Honest status: «done» is written only when it was run and verified.
Ready to stop losing progress? Launch the Project Tracking skill or start with the full AI Developer.
What is remembered between sessions?
Two levels. The global memory remembers the user — OS, installed runtimes, preferred stack and cross-project principles. The project journal remembers the specific work — status, decisions, bugs and the slice checklist.
Do I have to restate the status every time?
Yes — at the start of every session on an existing project a resume protocol runs: read the memory → find the journal → briefly restate where you stopped and what you're doing now → continue from the first unfinished task.
Where is the project journal stored?
In a DEV-JOURNAL.md file inside the project's own folder, next to SPEC.md. The template lives in references. If the journal grows beyond ~150 lines, the old part is archived into DEV-JOURNAL.archive.md.
Can I keep API keys and tokens in memory?
No, never. Secrets, tokens, passwords and API keys must not end up in memory or the journal — it's a risk. The memory lives on the user's machine, and stuffing secrets there is unsafe.
What if there is no project journal yet?
The skill says so plainly: «I don't see a project journal — let's create one or clarify the path». Then a folder, SPEC.md and DEV-JOURNAL.md are set up, and the project is added to the index.
Is it paid?
You can use the skill within your AgentHere plan — you pay tokens as the model runs. See the pricing page for exact limits.
Ведение проекта и память
Связующее звено между dev-spec → dev-build → dev-test: отслеживать этапы, помнить решения и продолжать с того же места. Без этого каждая сессия начинается с нуля — агент переспрашивает, переделывает, забывает, почему выбрали этот стек.
Когда активирован
- «Начнём проект» / «создай проект» — заводит папку и журнал.
- Возврат к работе: «продолжим», «на чём мы остановились», «что дальше».
- «Сохрани прогресс», «запиши решение», «покажи статус проекта».
- В начале любой новой сессии по существующему проекту — протокол возобновления.
Не активируй для написания кода (dev-build), тестов (dev-test) или ТЗ (dev-spec) — эти навыки сами делают свою часть; этот навык её фиксирует.
Два уровня памяти
- Память агента (глобальная, кросс-проектная) —
~/.agenthere/memory/ai-developer/— в домашней директории пользователя (Windows —%USERPROFILE%\.agenthere\memory\ai-developer\), не в рабочей директории:stack.md— предпочтения пользователя: ОС, установленные рантаймы (Node/Python), любимый стек, кодировки/пакетный менеджер. Один раз узнал — больше не переспрашиваешь.decisions.md— кросс-проектные паттерны и принципы, которые пользователь хочет соблюдать всегда.projects.md— индекс проектов: название, путь к папке, статус, дата.
- Журнал проекта (per-проектный) — в папке самого проекта:
SPEC.md— ТЗ (ведёт dev-spec).DEV-JOURNAL.md— статус, решения, что дальше, чек-лист. Шаблон — в конце этого навыка.
Глобальная память — про пользователя; журнал проекта — про конкретную работу.
Протокол возобновления (КАЖДУЮ новую сессию по проекту)
В самом начале разговора, если есть существующий проект:
- Прочитай
~/.agenthere/memory/ai-developer/(все файлы) — узнаешь пользователя. - Найди папку проекта (спроси путь, если неоднозначно) и прочитай
DEV-JOURNAL.md+SPEC.md. - Кратко перескажи пользователю: на чём остановились, что decided, что делаем сейчас.
- Продолжай с первой невыполненной задачи в чек-листе журнала.
Это превращает «начать заново» в «продолжить». Без журнала агент честно скажет: «Не вижу журнала проекта — давай создадим или уточни путь».
Заведение нового проекта
- Создай папку проекта (или используй текущую рабочую).
- Положи туда
SPEC.md(через dev-spec) иDEV-JOURNAL.md(из шаблона). - Запиши проект в
~/.agenthere/memory/ai-developer/projects.md. - Узнай окружение один раз и сохрани в
stack.md: ОС, есть ли Node/Python, пакетный менеджер, любимый язык. Больше не переспрашивай.
Журнал — что и когда записывать
Журнал (DEV-JOURNAL.md) ведёт навык dev-project, но записывают все этапы:
| Событие | Что записать | Когда |
|---|---|---|
| Решение по архитектуре/стеку | что выбрали + почему + отвергнутые альтернативы | сразу в dev-spec |
| Готовая задача из чек-листа | [x] + дата | сразу в dev-build после коммита |
| Найденный/починенный баг | кейс + корень + фикс | сразу в dev-test |
| Деплой | URL, хостинг, как обновлять, где env | сразу в dev-deploy |
| Новая задача всплыла | [-] строка в чек-лист | когда обнаружили |
| Решение «не делать в MVP» | что и почему отложено | сразу |
Правило немедленной фиксации: узнал/решил/закончил → сразу запиши. Не откладывай на конец сессии — к концу забудется половина, а контекст мог сжаться.
Чек-лист задач (todowrite)
Для активной работы используй инструмент todowrite — живой чек-лист текущей сессии
(быстро, в контексте). Журнал DEV-JOURNAL.md — долговечная запись между сессиями.
Связь: завершённую задачу из todowrite отметь и в журнале ([x] + дата).
Что НЕ хранить
- Болтовню, временные состояния, логи разговоров, дубликаты.
- То, что легко перепроверить (содержимое файлов — есть же
read). - Секреты, токены, пароли, ключи API — никогда. (РФ-резидентность данных: память живёт на машине пользователя; пихать туда секреты — риск.)
- Журнал — до ~150 строк; если разросся — архивируй старое в
DEV-JOURNAL.archive.md.
Границы (✅ / ⚠️ / 🚫)
- ✅ Всегда: протокол возобновления в начале сессии; запись решения сразу; обновлять чек-лист после каждого среза.
- ⚠️ Спросить: перед удалением/архивацией больших кусков журнала; перед сменой зафиксированного решения (объясни, что меняется и почему).
- 🚫 Никогда: не хранить секреты; не перезаписывать чужие файлы журнала без подтверждения; не врать в статусе («готово», когда не запускалось).
Выходные критерии
- В начале сессии по существующему проекту выполнен протокол возобновления.
- Каждое решение/завершённая задача/баг записаны в журнал.
-
stack.mdхранит окружение пользователя (чтобы не переспрашивать). - Чек-лист в журнале отражает реальное состояние (что сделано, что дальше).
- Нет секретов в памяти/журнале.
Шаблон DEV-JOURNAL.md
Кладётся в корень проекта рядом с SPEC.md. Живой документ — обновляй по ходу;
архивируй старое в DEV-JOURNAL.archive.md, когда активная часть перевалит за ~150
строк. Чек-лист отражает реальность: [x] только для запущенного и проверенного.
# DEV-JOURNAL — <название проекта>
**Статус:** <идея / в разработке / готов MVP / на паузе>
**Начат:** <дата> · **Обновлён:** <дата>
**Стек:** <из SPEC.md, одна строка>
**Цель (из SPEC):** <одна фраза>
**Деплой:** <URL / ещё не деплоили>
## Что сделали (кратко)
- <дата> — <что> (commit/файл).
- <дата> — <что>.
## Текущий этап
<одна-две строки: над чем работаем прямо сейчас>
## Чек-лист задач
- [x] <задача> — <дата>
- [ ] <задача> ← текущая
- [ ] <задача>
- [-] <отложено из MVP: что и почему>
## Журнал решений
- <дата> — **Решили:** <X> вместо <Y>. **Почему:** <причина>. **Альтернативы:** <что
отвергли>. *(Защищает от «а почему так?» через месяц и от отката к худшему.)*
## Баги и фиксы
- <дата> — **Баг:** <симптом>. **Кейс:** <как воспроизвести>. **Корень:** <почему>.
**Фикс:** <что сделал>. **Тест:** <имя теста, который закрыл кейс>.
## Что дальше (next)
1. <следующая задача>
2. <задача>
## Заметки
<подводные камни, зависимости, что узнать у пользователя>
Правила ведения журнала
- Записывай сразу после события (решение / коммит / фикс) — не откладывай на конец.
- Решение без причины бесполезно — всегда пиши «почему».
- Завершённые этапы архивируй, когда активная часть перевалит за ~150 строк.