serejaris/personal-corp-os

# Paperclip API

Управление компаниями AI-агентов через CLI и REST API. Без интерфейса.

## Когда использовать

- Создать/обновить задачу для агента
- Посмотреть статус агентов, задач, расходов
- Одобрить найм или стратегию
- Запустить heartbeat вручную
- Изменить промпт, модель или бюджет агента
- Прокомментировать задачу

## Конфигурация инстанса

# Daily retro (experimental)

Part of the Personal Corp framework. Weekly retro answers "what did the week give". Daily retro answers a smaller question every evening: what did my agents do today, and what did they leave half-done. You do not remember twenty sessions in five repos; the logs do.

Experimental means: the shape may change, it is not in the plugin's active skill list, you copy it by hand (see README).

## What it reads

Only local files, nothing leaves the machine:

| Harness | Logs |
|---|---|
| Claude Code (CLI and desktop) | `~/.claude/projects/<project>/<session>.jsonl` |
| Codex | `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl` |

# Art Director

Use this skill when the work is an art-direction search for a media production workspace.

The skill coordinates this loop:

```text
brief -> references -> generation branches -> HTML preview -> feedback -> next branches -> selected direction
```

For single-image production, use the host repo's image-generation or media-run instructions. For comic pages, albums, storyboards, or platform-specific assets, use the host repo's format-specific playbook when one exists.

## Default Output Shape

# Аудит правил агента

Скилл проверяет файлы правил агента в текущей папке и каталог скиллов, который агент видит на старте. Отдаёт отчёт таблицей: что не так и как сделать лучше. Файлы меняет только после «да» человека.

Скилл обычно зовёт человек без опыта в программировании: он ведёт папку с агентом для своей работы. Отчёт пиши простыми словами, на языке человека; термин объясняй один раз через то, что он меняет в работе агента.

## Что проверяется

- `AGENTS.md` в текущей папке и во всех её подпапках. Его читают Claude Code, Codex, Cursor и другие агенты, поэтому аудит строится вокруг него.
- `CLAUDE.md`, `CLAUDE.local.md` и `.claude/rules/` попадают в отчёт одной находкой, если в них свой текст: тогда Claude Code читает одни правила, остальные агенты другие. Разбирать их построчно не нужно.
- Скиллы из `.agents/skills` и `.claude/skills` этой папки (и папок выше до корня git-репозитория), `~/.agents/skills`, `~/.codex/skills`, `~/.claude/skills`.

## Четыре мерила

# /avatar: робот агента

Тело робота это харнес. Голову модель делает себе сама: цвет и глаза. Весь робот одного цвета палитры, мелкие детали того же цвета темнее. На теле стикер с логотипом компании модели, на лбу лента с именем модели. Рядом с этим файлом два скрипта и страница: `avatar.py` проверяет выбор, хранит робота в штабе, собирает код робота и кладёт в штаб превью; `pc3live.py` входит в живой класс урока и зажигает маячок; `robot.html` это плеер превью, его копирует `avatar.py`. Нужен Python 3, на Windows команда `python` вместо `python3`. Ниже `A` это путь к `avatar.py`, например `.agents/skills/avatar/avatar.py`, а `L` это путь к `pc3live.py` в той же папке.

Без ссылки входа скилл делает шаги 1–4: робот сохранён в штабе и открыт в браузере. Ссылка входа есть: дальше шаги 5 и 6.

## 1. Кто я

Харнес записан в `stack/harness.md`, строка Харнес. Нет файла: определи сам по таблице.

<!-- харнесы: live/sync.mjs -->
| Харнес | `--harness` |
|---|---|
| Claude Code | `claude-code` |

# Benchmark

Measure a pipeline on your own input before you pick an engine. One task file lists the variants; the scripts run them one by one in an isolated container and write numbers you can defend: time, cost per hour of input with a dated price source, quality against a reference.

Shape of a pipeline this skill knows:

`input (recording) → ASR engine → transcript → author model (notes, chapters) → code checks → judge model`

Each arrow is a slot. A variant fills one slot and keeps the rest fixed.

## When to use

- «ElevenLabs, Whisper or a Russian engine: what does an hour of our meetings cost and who makes fewer mistakes»;
- «move the notes step from Claude to GLM: does quality hold»;

# Claude Code Analytics

Generate HTML report of Claude Code usage from `~/.claude/history.jsonl`.

## Data Sources

- **History:** `~/.claude/history.jsonl` — prompts with timestamps and project paths
- **Git:** Remote URLs and commit counts per project

## Output

Single HTML file with terminal aesthetic:
- ASCII art header
- Summary stats (projects, prompts, commits, days)

# CEO Council — Independent Strategic Analysis

Launch parallel sub-agents as isolated C-level experts. Each analyzes the same project data from their perspective. No coordination between experts — isolation produces genuine diversity of opinion. Then synthesize consensus and disagreements.

## Critical: How to Launch Experts

**MUST use the Task tool** with `subagent_type: "general-purpose"` and `model: "opus"`.

```
Task(
  subagent_type: "general-purpose",
  model: "opus",
  prompt: "<expert prompt with data>",
  description: "CFO analysis"

# CLAUDE.md Writer

Creates and refactors CLAUDE.md files following official Anthropic best practices (2025).

## Golden Rules

| Rule | Why |
|------|-----|
| **CLAUDE.md < 200 lines** | Loads on EVERY request, costs tokens |
| **Rules files < 500 lines each** | Official recommendation per file |
| **Critical rules FIRST** | Top = highest priority |
| **Modular rules → `.claude/rules/`** | Conditional loading, organized |
| **Use `paths:` frontmatter** | Load rules only for matching files |
| **No linting rules** | Use ESLint/Prettier/Biome instead |

# Claude sessions sync (between desktop-app accounts)

How it works (verified 2026-10-01…07, Claude Code 2.1.286, macOS):

- Session records live in `~/Library/Application Support/Claude/claude-code-sessions/<accountUuid>/<orgUuid>/local_*.json`. The second path level is the **organization** UUID; the app lists only the current account+org pair, which is why switching accounts hides the other side's sessions.
- Transcripts live in `~/.claude/projects/` and are shared across all accounts — never touch them. A record points at its transcript through the `cliSessionId` field.
- Active account: `~/Library/Application Support/Claude/config.json` → `lastKnownAccountUuid`. The active org folder is the one holding the freshest record (mtime).
- Account switches may leave empty race folders `<old-account>/<new-org>` — ignore them.

## Procedure

1. The app must be fully closed: `pgrep -f "/Applications/Claude.app/Contents/MacOS"` is empty; otherwise `osascript -e 'quit app "Claude"'` and wait. Copying while the app is alive can be rolled back by its in-memory list cache (`LSS-cached-sessions`) and record rewrites.
2. Identify both working folders: under each account UUID take the subfolder with the most `local_*.json` records (or the freshest one).
3. Run a bidirectional newest-wins sync of `local_*.json` — the script below. A one-way copy leaves drift: sessions you continued on one side go stale on the other.

# Corp Doctor

Один вход во все операции над контуром Personal Corp: диагностика, ремонт, новый отдел, маршрутизация задачи.

Скилл не собирает систему вслепую. Сначала он выясняет, что уже есть, потом чинит недостающее.

## Phase 0 — Меню

Первое действие: показать меню и дождаться явного выбора. До ответа человека ничего не читать и не создавать.

```text
Что делаем?

1. Диагностика — посмотреть контур и показать расхождения без правок

# corp-new: новый отдел штаба

Штаб это главная папка работы с агентом: файл правил, `me.md`, карта отделов. Отдел это соседняя папка штаба со своим файлом правил, словарём, скиллами и задачами, например `corp-sales` или `corp-learn`. Отдел знает свой штаб, штаб знает свои отделы: связь записана в правилах с обеих сторон.

Скилл идёт по шагам и отвечает таблицей ✓/✗. Правила отдела за человека он не пишет: ставит каркас с пустыми местами, их человек заполняет сам или вместе с агентом через /mp-grill-me. Исключение — готовые отделы из `templates/` (шаг 3): их правила уже заполнены. Чужие файлы не трогает, незакоммиченную работу не выбрасывает. GitHub не нужен: отдел живёт в локальной папке.

Команды даны для macOS и Linux (zsh, bash). На Windows агент делает то же средствами PowerShell.

## 1. Найти штаб

Штаб узнаётся так же, как в скилле `hq` (шаг 1): папка с `me.md` или `stack/harness.md`. Где искать, по порядку:

```sh
for d in . ./hq .. ../hq ~/Documents/GitHub/hq ~/hq; do

# Daily

**Отдел** — единица штаба со своими задачами: папка или репозиторий, на который ссылается файл правил штаба. Если в файле правил штаба они названы проектами, это те же отделы.

Каждый запуск читает задачи заново из источников. Файл дня — срез со ссылками; задача живёт в своём источнике.

## Шаги

1. Определи сегодняшнюю дату из системного времени.
2. Прочитай файл правил штаба (`CLAUDE.md` или `AGENTS.md` в корне штаба). Найди:
   - строки, где лежат задачи отделов, например `Обучение: ../corp-learn. Задачи отдела лежат в ../corp-learn/tasks/.` или `Задачи всех отделов — GitHub Project 3, owner my-handle.`;
   - раздел «Правила приоритета»: что важнее, сколько дел брать на день, какие колонки или лейблы значат «ждёт решения человека».
3. Строк о том, где лежат задачи, нет: остановись, скажи об этом и предложи дописать по строке на отдел в формате выше. Дальше иди только по путям, которые записаны в файле правил.
4. Прочитай задачи каждого отдела из его источника:

# Фейбл руки-агенты

## Зачем этот режим

Токены Fable — самый дорогой ресурс сессии (лимиты урезаны). Поэтому Fable делает только то, что не может сделать рука дешевле: **думает, резолвит развилки и пишет спеки**. Всё остальное делают руки: **кодинг, код-ревью, gh-операции, CLI-механика, DoD-верификация и укладка файлов — Codex** (`gpt-5.5`, плагин `codex`, § Codex-руки); **разведка, чтение и скауты — Grok-воркеры через Orca** (§ Orca-руки). Каждый tool call, который могла сделать рука, — сожжённый лимит.

Sonnet и Haiku не использовать ни для каких ролей (решение founder 04.07.2026).

Граница проходит по суждению, а не по стоимости токена: субагентам уходят **глаза и руки**, но никогда — **голова**. Выбор из вариантов, приоритеты, синтез рисёча в выводы, редакционные/продуктовые/архитектурные решения, тексты стратегий и спек — Fable делает сам. Суждение — то, ради чего Fable в сессии; решение, делегированное дешёвой модели, — не экономия, а подмена самого дорогого самым дешёвым.

## Жёсткие запреты

1. **Не писать код и не править файлы репо. Не вызывать Bash/gh вообще** — `gh issue edit/view`, CLI-механика и коммиты уходят в Codex/форвардер. Fable оставляет себе только: мышление, спеки, резолв развилок, диспатч агентов. Codex-задача диспатчится через Agent tool (`codex:codex-rescue`); Bash у Fable не появляется нигде.
2. **Не читать кодовую базу самому.** Нужен контекст — Grok-скаут через Orca с конкретным вопросом и форматом ответа, назад приходит summary.

# GitHub Issues CLI

Efficient GitHub Issues management via `gh` CLI with AI session context storage.

## Table of Contents

1. [Quick Reference](#quick-reference)
2. [JSON Output](#json-output-patterns)
3. [Search Filters](#advanced-search-filters)
4. [Bulk Operations](#bulk-operations)
5. [Issue to PR Workflow](#issue-to-pr-workflow)
6. [Milestones](#milestones-via-api)
7. [AI Session Context](#ai-session-context)
8. [Task Workflow](#task-workflow)

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time.

If a question can be answered by exploring the codebase, explore the codebase instead.

# /harness — режим работы агента

Человек задаёт, как агент работает в этой сессии, шапкой из четырёх строк. Модель каждый ставит свою: ту, что есть в его подписке и харнесе.

```
/harness
режим: оркестратор, критик
модель: <модель>
эффорт: низкий
макс: 3 субагента
```

Любую строку можно пропустить — тогда действует значение по умолчанию.

# html-draft — Flat Engineering Blueprint Diagrams

Generate one HTML page that renders a technical diagram in a strict flat-blueprint aesthetic — the look of a printed engineering specification sheet, not a marketing landing.

**Stack:** Tailwind v4 via `@tailwindcss/browser` CDN for layout + utilities, D3 v7 via jsDelivr CDN for SVG-based diagrams (nodes, connectors, layouts, animations).

**Use this when** the user wants an architecture diagram, system flow, technical spec sheet, or component map as a standalone HTML artifact (suitable for slides, reports, exports).

**Don't use this for:**
- Inline schemas inside markdown documents — use a mermaid renderer instead
- Newspaper / reading-first single-column pages with monospace ink-on-cream feel
- Multi-section interactive explainers with pill navigation

## Design philosophy

# Idea — fast capture of a single idea

Part of the Personal Corp framework — running a one-person business through AI agents.

One pipeline: your voice → a provenance-tracked folder in your ideas repo → (optional) an issue mirror on a GitHub Project view. The folder is the source of truth; everything else is a pointer to it.

This skill is **self-contained** — it inlines the folder structure, status enum, and provenance formats below. You don't need any external canon file.

## What this skill is NOT for

- **Mining ideas out of a transcript / meeting / thread** — that's bulk extraction from a source. Use a separate extraction skill for that. This skill captures ONE idea the user is voicing right now.
- **A dated work task with a deadline** — use an issue tracker / the `manager` skill. Ideas have no deadline; they're seeds.

## Setup

# it-ram-doctor

The snapshot only reads; step 4 kills, and only on the owner's word.

## When memory is short

"13 of 16 GB used" and the swap size do not show load: macOS keeps memory busy with cache and compression, and swap does not shrink until a reboot. Memory is short when any of these holds:

- pressure: `sysctl kern.memorystatus_vm_pressure_level` is 4 or stays at 2 for long ([threshold](https://github.com/anthropics/claude-code/issues/73834): on Apple silicon 2 appears under ordinary compression); `memory_pressure | tail -1` shows less than 25–30% free;
- `Swapouts` in `vm_stat` grow between two readings a minute apart;
- swap grows three readings in a row.

No signs: clean only on a direct request. Measure a process by `top -o mem` or `footprint`; `ps` understates the compressed part.

# make-3d: 3D-модель через варианты

Скилл про форму работы, а не про решение. На входе уже известно, какая модель нужна, какие у неё состояния и 2–3 кандидата формы. Если это ещё не решено, сначала разбери с человеком через `/mp-grill-me` и возвращайся сюда.

**Вариант** — одна форма модели, построенная целиком одним исполнителем. **Лист** — снимок варианта по общему шаблону. **Канон** — исходник сцены, который видит человек; до выбора его не трогает никто.

## Шаги

1. **Сцена.** Найди исходник сцены, команду сборки, где рисуются объекты, откуда берутся данные и адрес живой страницы. Сними, как сцена выглядит сейчас, и покажи снимок в чате картинкой. Готово: знаешь файлы объектов, команду сборки и живой адрес. Правила сцены (что где стоит, что нельзя закрывать, стиль) читай в её каноне (`DESIGN.md`, `CONTEXT.md`, README) и неси в бриф.

2. **Демо-данные.** Один набор на все варианты, где встречается каждое состояние модели и крайние случаи: ноль, один, много, каждый цвет. Готово: по набору можно проверить любое правило состояния.

3. **Копии сцены.** У каждого варианта своя папка-копия вне канона (`node_modules` симлинком на оригинал), свой порт и свой кеш сборщика. Папку для листов заведи постоянную, в репозитории человека (например `artifacts/<дата>-<модель>/<вариант>/`), чтобы листы пережили перезапуск сессии.

# make-landing: дизайн через варианты

**Вариант** — самостоятельное направление с визуальным референсом, полным контрактом и рабочим preview. **Канон** — исходная поверхность проекта, куда после выбора переезжает результат. До выбора авторы работают в своих папках.

Подходит для лендинга, героя, обложки и слайдов. Размеры и формат результата берутся из задачи. Если направление уже выбрано, выполняй обычную реализацию по его контракту.

## 1. Общий бриф

Найди исходник, текущую страницу, команду запуска и правила проекта. При редизайне сними исходную страницу и покажи картинкой в чате. Сохрани `brief.md`: аудитория, задача поверхности, проверенные тексты/оффер/CTA, обязательные секции, доступные ассеты, формат результата, ограничения и критерии готовности. При существенном пробеле проверь публичные первоисточники; приватный контекст остаётся локально. Источники фактов у всех авторов общие.

Число вариантов N возьми из запроса. Если его нет, уточни; предложи 6–10 для широкого поиска. Решение человека определяет N. При лимите исполнителей запускай волнами с полным scope до готового preview.

При запрете менять текст сохрани текстовый канон и список разрешённых фактических корректировок. Каждый автор использует его дословно. Композицию и порядок можно менять; полноту исходных смысловых секций проверяй отдельно. Дизайнерские заметки остаются в документах процесса.

# Manager

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

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

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

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

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

# Meeting Copilot

Create and maintain a local HTML dashboard for a live meeting. The dashboard gives the user a second-screen view of context, questions, topic progress, decisions, risks, and follow-ups while the call is happening.

This skill is designed for private workspaces. Do not publish raw transcripts, client names, personal notes, or generated meeting artifacts unless the user explicitly asks for a sanitized export.

## Modes

Use one of three modes:

| Mode | When | Output |
| --- | --- | --- |
| CREATE | Before the meeting | A local dashboard app with prepared context and questions |
| UPDATE | During the meeting | Updated questions, topics, decisions, risks, and follow-ups from transcript chunks |

# README Generator

Generate human-focused README files following current best practices.

**Core principle:** README is for humans, not agents. Research → Analyze → Write.

**Model recommendation:** Use `Task` tool with `model: haiku` for README generation — faster and cheaper for documentation tasks.

## When to Use

- Creating README for new project
- Rewriting outdated README
- User asks "write/create/update README"

# Retro

Запускается из штаба. Смотрит назад на неделю по задачам всех отделов.

## Правило данных

Каждый запуск читает файлы задач заново. Своей копии задач не держи и неделю из памяти чата не восстанавливай. Файл ретро это срез со ссылками, источник правды остаётся в задачах отделов.

## Шаги

1. Определи текущую ISO-неделю и её даты из системного времени. Если человек назвал другую неделю, возьми её.
2. Прочитай файл правил штаба (`CLAUDE.md` или `AGENTS.md`). Найди строки, где лежат задачи отделов, например:
   `Обучение: ../corp-learn. Задачи отдела лежат в ../corp-learn/tasks/.`
3. Если таких строк нет, остановись. Скажи, что в правилах штаба не указано, где лежат задачи отделов, и предложи дописать по строке на отдел в формате выше. Пути не угадывай.

# Safe Public Release

Turn a private, vendor-provided, runtime-generated, or mixed artifact into a public package without leaking secrets, private state, or material that cannot be redistributed.

One pipeline:

`intent → owner issue tree → inventory → provenance → license → security/privacy → allowlist → clean package → approval → publish → fresh public verification → maintenance`

The skill is **allowlist-first**. Never copy a whole runtime/private directory and hope denylist cleanup finds everything.

## Hard safety boundary

Publishing is an outward mutation. Before creating a public repository, changing visibility, pushing a release, or publishing to a registry:

# Вехи AI-native SDLC

Источник: [The AI-Native SDLC Playbook](https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6aba736348bdf4f08183f463_AI%20Native%20SDLC%20Playbook_designv2%20(1).pdf), Louis Claxton, Anthropic. Ниже пересказ, приложенный к работе с агентами; за формулировками и примерами идите в оригинал.

Скилл не говорит, как нанимать агентов: это делает ваш режим оркестрации (например, [harness](../harness/SKILL.md) или [fable-ruki-agenty](../fable-ruki-agenty/SKILL.md)). Он говорит, какой артефакт должен лечь в git до перехода к следующей стадии.

Главная мысль плейбука: каждая стадия кончается коммитом артефакта, который читает следующая стадия; цепочка коммитов и есть журнал аудита — кто попросил, что сделал агент, кто одобрил. Внимание человека стоит на воротах: он принимает артефакт, подготовленный агентом, и не начинает стадию с нуля.

## Роли

- **Владелец задачи** — человек, который ставит задачу и принимает ворота 1, 2 и 5 (вливание и прод).
- **Планировщик-лид** (вехи 1–3) — агент, который пишет intent.md, spec.md и plan.md, носит их владельцу на принятие, нанимает исполнителя только после закоммиченного plan.md и сверяет вехи скриптом. Отдельного агента нет — эту роль берёт оркестратор сессии или встроенный агент планирования харнеса (в Claude Code — `Plan`).
- **Исполнитель** — агент в своём worktree, работает по plan.md.
- **Ревьюер** (вехи 4–5) — агент, который не писал этот код: сверяет дифф с plan.md, требует вывод проверки в PR и порядок «падающий тест, потом починка», ставит одобрение, после которого PR видит владелец.

# Telegram Bot Ops

Use this skill when the real question is whether a Telegram bot is receiving
updates, processing them in the intended runtime, and sending visible responses
to the right chat, user, or forum topic.

## Public Safety

- Default to read-only diagnostics.
- Do not print tokens, `.env` values, connection strings, raw logs, private DMs,
  payment payloads, session files, or full user records.
- Use placeholders in notes and examples: `<TELEGRAM_BOT_TOKEN>`,
  `<TELEGRAM_USER_ID>`, `<CHAT_ID>`, `<TOPIC_ID>`, `<WEBHOOK_URL>`.
- Do not send Telegram messages, restart production services, change webhooks,

# To Issues

Break a plan into independently-grabbable task files using vertical slices (tracer bullets).

## Process

### 1. Gather context

Work from whatever is already in the conversation context. If `PRD.md` exists in the project folder root, read it in full. If the user points at another spec file, read that instead.

### 2. Explore the codebase (optional)

If you have not already explored the codebase, do so to understand the current state of the code. Task titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.

This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.

## Process

1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.

2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

Check with the user that these seams match their expectations.

3. Write the PRD using the template below, then save it as `PRD.md` in the root of the project folder (the folder you are working in for this demo or feature).

<prd-template>

# Weekly Planning

## Overview

Turn retro findings + existing backlog into a prioritized week with clear outcomes, issues in correct repos, and delegation matrix (founder vs agent).

## When to Use

- After weekly retro is complete
- Monday/Tuesday when planning the week
- When user says "план на неделю", "приоритизация", "что делаем"

## Iron Rule: Planning Is Not Execution

# Weekly Retro

Part of the Personal Corp framework — running a one-person business through AI agents.

Structured weekly retrospective. Gather facts from code and project management tools, interview the founder, capture findings into issues and canonical files.

## Setup

Before first use, define these in your project's `CLAUDE.md`:

```markdown
## Weekly Retro Config

### Repos to scan

# Daily

Быстрый локальный скилл: человек спрашивает — сразу получает ответ в чате.

## Граница

Работай только с текущим отделом. Не обходи штаб, соседние отделы, календарь и внешние системы. GitHub разрешён только тогда, когда `tasks/README.md` называет GitHub Issues активным источником задач этого отдела.

## Алгоритм

1. Определи сегодняшнюю дату, ISO-неделю и все семь дат недели из системного времени. Имя плана всегда вычисляется заново: `reports/WNN-plan.html` или формат, принятый текущим отделом.
2. Прочитай `AGENTS.md`, `README.md` и блок "Активный режим" в `tasks/README.md`.
3. Собери активные задачи из одного указанного источника:
   - режим `локальные файлы` → прочитай `tasks/*.md`, кроме `README.md` и `_template.md`;

# Planning

Планирование смотрит вперёд и не выполняет запланированную работу.

## Пререквизит

До начала найди принятый отчёт `reports/ГГГГ-WNN-retro.html` за предыдущую неделю.

Если ретро не завершено или не принято, остановись и предложи сначала запустить `retro`.

## Граница

Планируй только текущий отдел. Не обходи штаб и соседние отделы. GitHub разрешён только как активный источник задач текущего отдела, указанный в `tasks/README.md`.

# Retro

Ретро смотрит назад. Сначала полностью закрой разбор недели, только затем разрешай переход к `planning`.

## Граница

Работай со всеми задачами текущего отдела. Не обходи другие отделы и не собирай общий срез Personal Corp.

Записи задач и системы результатов остаются источниками истины. HTML — датированное представление недели.

## Этап 1. Собрать факты

1. Определи календарную неделю и её даты.
2. Прочитай `AGENTS.md`, `README.md` и блок "Активный режим" в `tasks/README.md`.