agentleFS
serejarisserejaris/ris-claude-code/skills/manager/SKILL.md

manager

Skill243 starsChanged 3 months agoMITView on GitHub

Связывает сессию с задачами штаба в файлах tasks/ или в GitHub issues. Запись — «синкни сессию»: итог сессии в задачу и файл дня. Чтение — «что по <задаче>»: текущее состояние задачи.

7 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

Manager

Два режима: запись переносит итог сессии в задачу, чтение отвечает, что с задачей сейчас.

Развилка: где лежат задачи

Сначала прочитай файл правил штаба и файл правил отдела (AGENTS.md или CLAUDE.md).

  • Задачи лежат в файлах (tasks/): работай по разделу «Уровень 1», остальной документ не нужен.
  • Задачи в GitHub issues: работай с раздела «Уровень 2: задачи в GitHub issues».
  • Строки о том, где лежат задачи, нет: предложи её дописать, например «Задачи отдела лежат в tasks/», и спроси человека до первой записи.

Уровень 1: задачи в файлах

Запись, в конце сессии:

  1. Найти задачу. Ищи задачу этой сессии в tasks/ отдела (путь из правил: где лежат задачи). Файла нет: создай tasks/<ГГГГ-ММ-ДД>-<slug>.md с разделами:

    # <название задачи>
    
    ## Результат
    ## Контекст
    ## Как проверить
    ## Текущее состояние
    ## Следующий шаг
    ## Результат и решение человека
  2. Обновить файл задачи. Перепиши «Текущее состояние» (что сделано и где лежит) и «Следующий шаг» (одно действие). «Результат и решение человека» заполняет человек; агент переносит туда только его слова из сессии.
  3. Файл дня. Допиши строку со ссылкой на файл задачи в файл дня штаба: путь из правил штаба, по умолчанию tasks/<ГГГГ-ММ-ДД>.md в штабе. Формат строки: - <отдел>: <что сделано> → ../<отдел>/tasks/<файл>.md.
  4. Саммари в чат:

    ✓ сделано: ...
    ✎ ждёт человека: ...
    дальше: ...

Чтение: «что по <задаче>» ищется по tasks/ отделов из карты отделов штаба; ответ берётся из разделов «Текущее состояние» и «Следующий шаг».

Уровень 2: задачи в GitHub issues

Источник правды по задаче — GitHub issue: тело, состояние, лейблы, эпик. Доска (GitHub Project) показывает, что активно на неделе, и обновляется вслед за issue.

  1. Запись — в конце сессии: прочитать, что сделано; найти существующие issues; обновить их прогрессом и комментарием о работе; соблюсти инварианты эпика, W-label и доски; новый issue создать, только когда ни один не подошёл.
  2. Чтение — в любое время: «что по <задаче>» → поиск по репозиториям из конфига, сжатое состояние найденных issues с эпиком, лейблами, колонкой доски и последней активностью.

Все операции с issue (прочитать, изменить, записать, синк доски) идут через manager: он держит контракт записи, инварианты и синк доски.

Что читать дальше

Справочники лежат рядом со скиллом. Читай целиком тот, что нужен на текущем шаге; каждый начинается с оглавления.

ШагСправочник
Любой вызов: выбрать режим, режим работы по умолчанию, язык ответа, цикл планирования, когда применять, pre-flightreferences/modes.md
Запись: алгоритм синка, авторизация, связь коммита и issue, артефакты планирования, колонка доски, чистка плана при закрытии, «обновить или создать», комментарий как запасной каналreferences/write-mode.md
Чтение: алгоритм, пакетное чтение доски, доказательство эпика, связанный контекст, ложные совпаденияreferences/read-mode.md
Поиск существующих issue: ключи, критерий совпадения, пакетный GraphQL и защиты jqreferences/search.md
Эпик: что считается эпиком, как найти, агрегирующий эпик, видимый корень, блок Related, проверка до синкаreferences/parent-epic.md
W-label: текущая неделя, дата события, дрейфы, бэклог, быстрое создание лейблаreferences/w-labels.md
Заголовок нового issue: формула {действие} {объект}, правила, примерыreferences/titles.md
Тело issue: критерий готовности, шаблоны тела, обновления и комментарияreferences/templates.md
Что показать пользователю: план, отчёт, ответ на чтениеreferences/output.md
Интеграция с CRM (если включена в конфиге)references/crm.md
Частые ошибки — сверка перед выполнением планаreferences/mistakes.md

Настройка: Manager Config

До первого использования задай это в AGENTS.md проекта (предпочтительно) или в CLAUDE.md (совместимость). Конфига агента у проекта ещё нет — запусти corp-doctor, он создаст или починит его. Владелец, репозитории, пути и номера досок берутся только отсюда.

## Manager Config

### GitHub owner
Имя пользователя или организация GitHub для поиска issue:
- owner: your-github-handle

### Repos to scan (cross-repo issue search scope)
Репозитории, в которых manager ищет:
- ~/Projects/main
- ~/Projects/ops
- ~/Projects/marketing

### Tasks index file (optional)
Путь к курируемому индексу текущей недели. Manager читает его ПЕРВЫМ, до любого `gh search`, чтобы сузить запросы:
- tasks_index: ~/docs/tasks.md
(если файла нет — manager работает без индекса, поиск идёт по всем repos)

### Tasks directory (optional)
Путь к файлам дня и планам недели, которые создаёт weekly-planning:
- tasks_dir: ~/docs/tasks/

### Domain → repo routing
| Domain | Repo |
|--------|------|
| коммерция / B2B-сделки | crm |
| запуски продуктов | main |
| эксплуатация / инфраструктура | ops |
| контент | marketing |

### GitHub Projects integration
Место на доске — инвариант (см. «Железные инварианты»). Объяви свои доски:
- weekly_project: <number>          # общая доска «всё активное на этой неделе» по всем репозиториям
- weekly_project_owner: your-github-handle
- status_field: Status              # поле single-select, в котором хранится колонка
- status_in_progress: In progress   # имя (или id) опции активной колонки
- domain_projects (optional):       # доски по доменам, если они у тебя есть
    | Domain | Project number |
    | коммерция | <number> |
    | продукт | <number> |

Закешируй здесь найденные ID полей и опций (`gh project field-list <N> --owner OWNER --format json`), чтобы manager не запрашивал их каждый запуск.

### W-label convention (optional)
- enabled: true
- format: W{NN} (ISO week)
(если false — manager создаёт issues без W-label)

### Standing write authorization
- mode: ask-each-time | execute-after-plan
(по умолчанию: ask-each-time — показать план и спросить. execute-after-plan — выполнить записи после показа краткого плана. В обоих режимах спрашивай при настоящей неоднозначности или жёстком блокере)

### CRM integration (optional)
- crm_path: ~/Projects/crm
- crm_pointer_format: [[<slug>]]
(если не используется — секция игнорируется; см. references/crm.md)

corp-doctor — скилл первичной настройки и починки этого конфига. Тип работы живёт в лейблах, эпике и на доске (см. references/titles.md).

Железные инварианты

Каждый issue, который трогает manager, соблюдает первые три; активный issue текущей недели — ещё 4–6:

  1. W-label — текущая или будущая неделя либо неделя события с датой, если W-label включён в конфиге. Лейбла нет в репозитории — создай его.
  2. Эпик — ровно один, через GitHub Sub-issues API. Каждый issue, который сам не эпик, привязан к эпику. См. references/parent-epic.md.
  3. Трек задают заголовок и эпик. Лейблы — только W-label и лейблы типа работы.
  4. Место на доске — активный issue текущей недели стоит на доменной доске (если она есть) и на недельной доске. W-label без места на доске = Project drift.
  5. Эпик виден на доске — для активного дочернего issue текущей недели эпик сам стоит на нужной доске с непустой колонкой статуса.
  6. Комментарий о работе — в записи, когда над issue в этой сессии шла реальная работа: комментарий в таймлайн с итогом и ссылками на коммиты; он пишется в дополнение к смене колонки, лейбла или места на доске. Синк только лейбла или доски без работы над задачей обходится без комментария.

Эпика нет ни в одном репозитории — manager до синка показывает это в плане и предлагает создать новый эпик или выбрать существующий. После синка у каждого issue есть эпик.

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.