全周期开发者技能：AI驱动的自动化软件开发与代码审查工作流

Full Cycle Developer by aaaaqwq/claude-code-skills

26 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/aaaaqwq/claude-code-skills --skill 'Full Cycle Developer'

AI/机器学习开发自动化

🇨🇳中文介绍

使用时机

当用户说：

"full cycle для [проект] [задача/issue]"
"сделай full cycle"
"работай в full cycle режиме"

提示词位置

所有角色提示词都位于 /opt/projects/llm-review-prompts/prompts/。根据项目技术栈从 AGENTS.md 中选择正确的语言变体。

prompts/
├── developer/   dotnet | rust | python | go
├── architect/   dotnet | rust | python | go
├── tester/      manual | e2e | autotests
├── reviewer/    general
└── security/    general

执行模式 — 主会话作为编排器

用户只看到一个最终输出。主会话静默执行所有步骤 — 没有中间消息。

编排方案

ГЛАВНАЯ СЕССИЯ (молча)
│
├── Шаг 1-3: sessions_spawn(developer-субагент)  → ждёт → [diff, tests green]
│
├── Шаг 4: sessions_spawn × 4 (параллельно):
│   ├── Developer review  → sessionKey_dev
│   ├── Architect review  → sessionKey_arch
│   ├── Tester review     → sessionKey_test
│   └── Security review   → sessionKey_sec
│   └── Ждёт все 4 через subagents(action="list")
│   └── Забирает результаты через sessions_history
│
├── Шаг 4e: Final review — inline в главной сессии
│   (читает промпт reviewer/general.md + PREVIOUS_REVIEWS из 4 ролей)
│
├── Шаг 5: sessions_spawn(fix-субагент)
│   (передаёт агрегированные BLOCKING/MUST HAVE явно в task)
│   → ждёт → [tests green, commit]
│
└── Шаг 6: создаёт PR → Output пользователю

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 1-3: Developer-子代理

主会话使用以下任务生成子代理：

## DEVELOPER SUBAGENT — <project> <task>

INIT:
- git fetch origin && git pull origin main && git checkout -b <branch>
- Прочитать: AGENTS.md, docs/, ROADMAP.md
- memory_search("<project> architecture decisions")
- memory_search("<task topic> patterns")
- Загрузить TASK_CONTEXT из issue или описания

DEVELOP:
- Читать prompts/developer/<stack>.md
- Написать реализацию следуя Critical Rules из AGENTS.md

TEST:
- Читать prompts/tester/autotests.md
- Написать тесты — каждый тест должен падать при сломанной реализации
- Запустить тесты → должны быть green
- Не заканчивать пока тесты красные

LINT (обязательно для Python):
- python3 -m ruff check src/ tests/ 2>&1 | head -30
- Исправить все ошибки ruff перед коммитом
- Не коммитить с красным ruff

ЕСЛИ ROADMAP есть — прочитать, найти текущий пункт, запомнить для architect.

DOCS (ОБЯЗАТЕЛЬНО перед финальным коммитом):
- Обновить AGENTS.md: статус задачи, новые решения, pitfalls (раздел Status + Pitfalls)
- Если изменился публичный API или CLI — обновить README (EN + RU секция)
- Если архитектурное решение — добавить запись в docs/ или соответствующий .md
- Если ROADMAP.md / BACKLOG.md — отметить пункт выполненным (✅)
- Не коммитить реализацию без обновлённых доков

Output: один блок в конце:
BRANCH: <branch-name>
STACK: <python|rust|dotnet|go>
TESTS: <N passed>
LINT: ruff clean / <N errors>
DOCS: AGENTS.md updated / README updated / skipped (reason)
DIFF_SUMMARY: <3-5 строк что изменилось>

超时时间：runTimeoutSeconds=900

完成后 — 从 sessions_history 中获取 BRANCH、STACK、TESTS、DIFF_SUMMARY。

步骤 4: 4 个评审子代理并行

cd <project_root> && git diff origin/main...<branch> 2>&1 | head -400

提前读取提示词（主会话）：

cat /opt/projects/llm-review-prompts/prompts/developer/<stack>.md
cat /opt/projects/llm-review-prompts/prompts/architect/<stack>.md
cat /opt/projects/llm-review-prompts/prompts/tester/manual.md
cat /opt/projects/llm-review-prompts/prompts/security/general.md

同时生成所有 4 个，每个的任务包含：

角色提示词（完整文本）
PROJECT_CONTEXT (AGENTS.md)
TASK_CONTEXT (描述 + AC)
DIFF (git diff)
在最后以一个区块返回发现的指令

⚠️ 对所有角色（尤其是 Security）的范围限制： 仅检查 DIFF 中的更改。在此 MR 之前已存在的 Pre-existing issues → 不是 BLOCKING，在 MINOR 部分标记为 [pre-existing]。Security 不应因为当前变更未引入的问题而阻止 MR。

每个角色的任务模板

## <ROLE> REVIEW

<полный текст промпта роли>

---

PROJECT_CONTEXT:
<содержимое AGENTS.md>

TASK_CONTEXT:
<описание задачи + acceptance criteria>

DIFF:
<git diff>

---

Верни findings одним блоком в конце:
[BLOCKING/MINOR/CRITICAL/HIGH/MEDIUM/MUST HAVE/SHOULD HAVE]: описание, файл:строка, fix
Итого: X blocking, Y minor.

每个超时时间：runTimeoutSeconds=1200

# Собрать sessionKeys всех 4 субагентов
role_keys = {
    "developer": key_dev,
    "architect": key_arch,
    "tester":    key_test,
    "security":  key_sec,
}

# Ждать в цикле через subagents(action="list")
while True:
    active = subagents(action="list")["active"]
    active_keys = {s["sessionKey"] for s in active}
    if not any(v in active_keys for v in role_keys.values()):
        break
    exec("sleep 15")

# Забрать результаты
reviews = {}
for role, key in role_keys.items():
    hist = sessions_history(sessionKey=key, limit=2)
    reviews[role] = hist["messages"][-1]["content"]  # последнее сообщение

步骤 4b (Architect) + ROADMAP

在 architect 的任务中添加：

Дополнительно: обнови ROADMAP.md
- Если ROADMAP.md есть → найди текущую задачу и отметь [x], добавь новые пункты если выявлены
- Если нет → создай ROADMAP.md (текущее состояние + ближайшие задачи + дальние планы)
Сохрани изменения: exec("cd <project_root> && git add ROADMAP.md && git commit -m 'docs: update ROADMAP'")

步骤 4e: 最终评审（内联）

主会话自行汇总并做出裁决：

收集 PREVIOUS_REVIEWS：

## Developer Review
<reviews["developer"]>

## Architect Review
<reviews["architect"]>

## Tester Review
<reviews["tester"]>

## Security Review
<reviews["security"]>

读取 prompts/reviewer/general.md，应用于 PREVIOUS_REVIEWS + DIFF。做出裁决：APPROVE / REQUEST_CHANGES。

步骤 5: Fix-子代理

根据表格汇总所有 BLOCKING：

角色	在 MR 前修复	放入 issue
Developer	BLOCKING	MINOR, SUGGESTION
Architect	BLOCKING	MINOR
Tester	MUST HAVE	SHOULD HAVE → issue
Security	CRITICAL, HIGH	MEDIUM → issue, LOW → ignore

修复 → 评审循环（重复直到干净）

review_round = 1
MAX_ROUNDS = 3

while blocking_count > 0:
    if review_round > MAX_ROUNDS:
        → прервать, сообщить пользователю: "Не удалось устранить все BLOCKING за 3 итерации"
    fix_subagent(blocking_list)
    review_round += 1
    повторить шаг 4 (все 4 роли + 4e) → получить новый blocking_count

每次 fix-子代理之后 — 必须重复完整的评审步骤 4（所有 4 个角色并行 + 4e 最终评审）。不能仅基于"已应用修复"就认为分支干净 — 新的更改可能会引入新的 BLOCKING。

只有当评审结果显示 blocking_count == 0 时，才进入步骤 6。

⚠️ 关键规则：不中断循环

主会话不应向用户发送中间评审结果。

循环 develop → review → fix → review → ... 完全自主执行。用户不应为了继续而 ping 代理 — 这是编排的失败。

在 PR 之前可以给用户写消息的唯一情况：

MAX_ROUNDS 已用尽 — 解释失败原因并移交控制权
致命错误（测试失败且 fix-子代理在 3 次尝试后无法修复）
任务中存在无法在没有用户决定的情况下解决的歧义

在所有其他情况下 — 静默启动下一步。

🔔 通过 cron 强制自唤醒（防冻结）

问题： 主会话在启动子代理后可能会"冻结" — completion event 并不总是会唤醒会话。没有外部触发器，循环就会停止。

规则： 启动一组子代理 → 立即设置两个 cron。没有例外。

Cron 时间安排：

子代理类型	超时	Cron 1	Cron 2
4 个评审角色	1200s (20 分钟)	T + 20 分钟	T + 23 分钟
Fix-子代理	600s (10 分钟)	T + 12 分钟	T + 15 分钟

逻辑：cron 应在预期完成之后触发，而不是在期间。

Cron 文本模板：

Full-cycle самопинг: раунд {N} ревью <project>/<branch>.
Проверь subagents list (labels содержат '<role>').

Если ВСЕ done → агрегируй sessions_history, подсчитай blocking.
  blocking > 0 → запусти fix-субагент (не пиши пользователю).
  blocking = 0 → создай PR → напиши пользователю итог.

Если ЕСТЬ active → удали этот cron, поставь новый на T+5 мин с тем же текстом.

НЕ пиши пользователю пока нет финального результата (PR или фатальная ошибка).

自延续逻辑（如果子代理仍处于 active 状态）：

# В тексте systemEvent cron должен содержать инструкцию:
# "если active → удали себя (cron remove), поставь новый cron на now+5min"
# Это обеспечивает polling без busy-loop

deleteAfterRun: true — 每个 cron 只运行一次
两个 cron：如果第一个没有唤醒会话 — 第二个将在 3 分钟后触发
如果主会话已自行继续 — cron 将在空的 subagents list 上触发 → no-op（子代理已完成，PR 已存在或 fix 已启动）
当子代理已将结果返回给活动会话时，不要使用 cron — 立即汇总

在启动 fix-子代理前如何检查 BLOCKING

在启动 fix-子代理之前，检查实际代码（不要盲目相信评审者的输出）：

打开 BLOCKING findings 中提到的文件
确保问题确实存在于代码中，而不是误报
没有源代码访问权限的评审者经常出错（基于差异分析）
误报不需要修复 — 它们不是 BLOCKING

这可以节省轮次，并且不会在代码中引入不必要的更改。

如果 BLOCKING = 0 第一次就通过 → 不需要 fix-子代理，直接进入步骤 6。

如果 BLOCKING > 0 → 使用以下任务生成 fix-子代理：

## FIX SUBAGENT — <project> <branch>

cd <project_root> && git checkout <branch>

Исправить следующие BLOCKING findings:

<нумерованный список с файл:строка и конкретным fix для каждого>

После каждого fix — запустить тесты:
<команда запуска тестов>
Не коммитить пока тесты красные.

Запустить линтер (Python):
python3 -m ruff check src/ tests/ 2>&1 | head -30
Исправить все ошибки ruff. Не коммитить с красным ruff.

Обновить документацию (ОБЯЗАТЕЛЬНО):
- AGENTS.md: добавить найденные pitfalls, обновить статус
- README / docs: если fix затронул поведение — обновить соответствующую секцию

После всех fix:
git add -A
git commit -m "fix: <краткое описание>"
git push https://KoshelevDV:$(gh auth token)@github.com/KoshelevDV/<repo>.git <branch>

Создать сводный issue для MINOR/MEDIUM:
gh issue create --repo KoshelevDV/<repo> \
  --title "Minor: <feature>" \
  --body "<список>"

Output в конце:
TESTS: <N passed>
LINT: ruff clean / <N errors>
FIXES: <N blocking fixed>
ISSUE: <url или none>

超时时间：runTimeoutSeconds=600

步骤 5.5: 更新文档（修复后，PR 前）

当 blocking_count == 0 且测试通过后 — 更新项目文档：

cd <project_root>

# 1. AGENTS.md — обновить статус, стек, питфолы, новые решения
# Добавить в секцию Status: что реализовано, что изменилось
# Добавить в Pitfalls: нетривиальные находки из ревью

# 2. README.md — если добавлены новые возможности (config options, API endpoints, etc.)
# Обновить секцию конфигурации, добавить пример использования новой фичи

# 3. Коммит документации
git add AGENTS.md README.md
git commit -m "docs: update AGENTS.md and README for <feature>"
git push ...

在 AGENTS.md 中更新什么：

## Status — 将功能标记为已实现
## Pitfalls — 添加评审过程中发现的非平凡限制
技术栈，如果添加了新的依赖项

在 README.md 中更新什么：

新的配置选项（附 YAML 示例）
新的 API 端点
行为变更

如果没有任何根本性的变化（仅内部修复）— 更新 AGENTS.md 即可。

步骤 6: PUSH + 输出

主会话创建 PR：

gh pr create \
  --title "<type>: <description>" \
  --body "..." \
  --base main --head <branch>

然后向用户发送唯一一条消息：

✅ Full cycle завершён — <project> / <branch>

Tests:   <N passed / Y total>
Commits: <N>

Self-review:
  Developer  — <N blocking fixed, M minor → issue>
  Architect  — <N blocking fixed>
  QA/Manual  — <N ACs covered, M missing → issue>
  Security   — CLEAR / <N critical fixed>
  Final      — APPROVE ✅ / REQUEST_CHANGES ⚠️

PR: <url>
Issues: <url или none>

严重性表格（必需）

角色	= BLOCKING	→ issue
Developer	BLOCKING	MINOR, SUGGESTION
Architect	BLOCKING	MINOR
Tester	MUST HAVE	SHOULD HAVE, NICE TO HAVE
Security	CRITICAL, HIGH	MEDIUM, LOW

来自 tester 的 MUST HAVE = BLOCKING — 缺少针对 AC 的测试 = 未完成的功能。

不向用户发送中间消息（仅最终结果）
永远不要推送失败的测试
在 MR 前修复 BLOCKING 和 CRITICAL/HIGH
MINOR → 一个汇总的 issue，不是提交
在 developer-子代理中始终读取 docs/
TASK_CONTEXT 是必需的 — 没有它 developer-子代理不会开始
在 checkout 前进行 git fetch — 始终基于最新的远程仓库

🇷🇺Русский

When to Use

Triggered when user says:

"full cycle для [проект] [задача/issue]"
"сделай full cycle"
"работай в full cycle режиме"

Prompts Location

All role prompts live in /opt/projects/llm-review-prompts/prompts/. Select the right language variant based on project stack from AGENTS.md.

prompts/
├── developer/   dotnet | rust | python | go
├── architect/   dotnet | rust | python | go
├── tester/      manual | e2e | autotests
├── reviewer/    general
└── security/    general

Execution Mode — ГЛАВНАЯ СЕССИЯ КАК ОРКЕСТРАТОР

Пользователь видит только один итоговый Output. Главная сессия молча выполняет все шаги — без промежуточных сообщений.

Схема оркестрации

ГЛАВНАЯ СЕССИЯ (молча)
│
├── Шаг 1-3: sessions_spawn(developer-субагент)  → ждёт → [diff, tests green]
│
├── Шаг 4: sessions_spawn × 4 (параллельно):
│   ├── Developer review  → sessionKey_dev
│   ├── Architect review  → sessionKey_arch
│   ├── Tester review     → sessionKey_test
│   └── Security review   → sessionKey_sec
│   └── Ждёт все 4 через subagents(action="list")
│   └── Забирает результаты через sessions_history
│
├── Шаг 4e: Final review — inline в главной сессии
│   (читает промпт reviewer/general.md + PREVIOUS_REVIEWS из 4 ролей)
│
├── Шаг 5: sessions_spawn(fix-субагент)
│   (передаёт агрегированные BLOCKING/MUST HAVE явно в task)
│   → ждёт → [tests green, commit]
│
└── Шаг 6: создаёт PR → Output пользователю

Правила главной сессии

НЕ отправлять промежуточных сообщений пользователю между шагами
Вызовы инструментов идут молча — только итог
Если что-то пошло не так → сообщить причину + что успело закоммититься

Execution Pipeline

1-3. DEVELOP   — developer-субагент: INIT + код + тесты → green
4.   REVIEW    — 4 ревью-субагента параллельно → главная сессия агрегирует → Final inline
5.   FIX       — fix-субагент получает BLOCKING список явно → фиксит → тесты green
6.   PUSH      — главная сессия открывает PR → Output

Шаг 1-3: Developer-субагент

Главная сессия спавнит субагент с task:

## DEVELOPER SUBAGENT — <project> <task>

INIT:
- git fetch origin && git pull origin main && git checkout -b <branch>
- Прочитать: AGENTS.md, docs/, ROADMAP.md
- memory_search("<project> architecture decisions")
- memory_search("<task topic> patterns")
- Загрузить TASK_CONTEXT из issue или описания

DEVELOP:
- Читать prompts/developer/<stack>.md
- Написать реализацию следуя Critical Rules из AGENTS.md

TEST:
- Читать prompts/tester/autotests.md
- Написать тесты — каждый тест должен падать при сломанной реализации
- Запустить тесты → должны быть green
- Не заканчивать пока тесты красные

LINT (обязательно для Python):
- python3 -m ruff check src/ tests/ 2>&1 | head -30
- Исправить все ошибки ruff перед коммитом
- Не коммитить с красным ruff

ЕСЛИ ROADMAP есть — прочитать, найти текущий пункт, запомнить для architect.

DOCS (ОБЯЗАТЕЛЬНО перед финальным коммитом):
- Обновить AGENTS.md: статус задачи, новые решения, pitfalls (раздел Status + Pitfalls)
- Если изменился публичный API или CLI — обновить README (EN + RU секция)
- Если архитектурное решение — добавить запись в docs/ или соответствующий .md
- Если ROADMAP.md / BACKLOG.md — отметить пункт выполненным (✅)
- Не коммитить реализацию без обновлённых доков

Output: один блок в конце:
BRANCH: <branch-name>
STACK: <python|rust|dotnet|go>
TESTS: <N passed>
LINT: ruff clean / <N errors>
DOCS: AGENTS.md updated / README updated / skipped (reason)
DIFF_SUMMARY: <3-5 строк что изменилось>

Таймаут: runTimeoutSeconds=900

После завершения — забрать BRANCH, STACK, TESTS, DIFF_SUMMARY из sessions_history.

Шаг 4: 4 ревью-субагента параллельно

Получить diff:

cd <project_root> && git diff origin/main...<branch> 2>&1 | head -400

Прочитать промпты заранее (главная сессия):

cat /opt/projects/llm-review-prompts/prompts/developer/<stack>.md
cat /opt/projects/llm-review-prompts/prompts/architect/<stack>.md
cat /opt/projects/llm-review-prompts/prompts/tester/manual.md
cat /opt/projects/llm-review-prompts/prompts/security/general.md

Спавнить все 4 одновременно, каждый с task содержащим:

Промпт роли (полный текст)
PROJECT_CONTEXT (AGENTS.md)
TASK_CONTEXT (описание + AC)
DIFF (git diff)
Инструкцию вернуть findings в конце одним блоком

⚠️ Ограничение scope для ВСЕХ ролей (особенно Security): Проверять ТОЛЬКО изменения в DIFF. Pre-existing issues которые существовали до этого MR → не BLOCKING, оформить в MINOR-секции с пометкой [pre-existing]. Security не должен блокировать MR из-за проблем которые не введены текущим изменением.

Task-шаблон для каждой роли

## <ROLE> REVIEW

<полный текст промпта роли>

---

PROJECT_CONTEXT:
<содержимое AGENTS.md>

TASK_CONTEXT:
<описание задачи + acceptance criteria>

DIFF:
<git diff>

---

Верни findings одним блоком в конце:
[BLOCKING/MINOR/CRITICAL/HIGH/MEDIUM/MUST HAVE/SHOULD HAVE]: описание, файл:строка, fix
Итого: X blocking, Y minor.

Таймаут каждого: runTimeoutSeconds=1200

Ожидание всех 4

# Собрать sessionKeys всех 4 субагентов
role_keys = {
    "developer": key_dev,
    "architect": key_arch,
    "tester":    key_test,
    "security":  key_sec,
}

# Ждать в цикле через subagents(action="list")
while True:
    active = subagents(action="list")["active"]
    active_keys = {s["sessionKey"] for s in active}
    if not any(v in active_keys for v in role_keys.values()):
        break
    exec("sleep 15")

# Забрать результаты
reviews = {}
for role, key in role_keys.items():
    hist = sessions_history(sessionKey=key, limit=2)
    reviews[role] = hist["messages"][-1]["content"]  # последнее сообщение

Шаг 4b (Architect) + ROADMAP

В task для architect добавить:

Дополнительно: обнови ROADMAP.md
- Если ROADMAP.md есть → найди текущую задачу и отметь [x], добавь новые пункты если выявлены
- Если нет → создай ROADMAP.md (текущее состояние + ближайшие задачи + дальние планы)
Сохрани изменения: exec("cd <project_root> && git add ROADMAP.md && git commit -m 'docs: update ROADMAP'")

Шаг 4e: Final Review (inline)

Главная сессия сама агрегирует и выносит вердикт:

Собрать PREVIOUS_REVIEWS:

## Developer Review
<reviews["developer"]>

## Architect Review
<reviews["architect"]>

## Tester Review
<reviews["tester"]>

## Security Review
<reviews["security"]>

Прочитать prompts/reviewer/general.md, применить к PREVIOUS_REVIEWS + DIFF. Вынести вердикт: APPROVE / REQUEST_CHANGES.

Шаг 5: Fix-субагент

Агрегировать все BLOCKING по таблице:

Роль	Фиксить до MR	В issue
Developer	BLOCKING	MINOR, SUGGESTION
Architect	BLOCKING	MINOR
Tester	MUST HAVE	SHOULD HAVE → issue
Security	CRITICAL, HIGH	MEDIUM → issue, LOW → ignore

Цикл fix → review (повторять до чистоты)

review_round = 1
MAX_ROUNDS = 3

while blocking_count > 0:
    if review_round > MAX_ROUNDS:
        → прервать, сообщить пользователю: "Не удалось устранить все BLOCKING за 3 итерации"
    fix_subagent(blocking_list)
    review_round += 1
    повторить шаг 4 (все 4 роли + 4e) → получить новый blocking_count

После каждого fix-субагента — ОБЯЗАТЕЛЬНО повторить полное ревью шаг 4 (все 4 роли параллельно + 4e Final). Не считать ветку чистой только на основании "fix применён" — новые изменения могут внести новые BLOCKING.

Переходить к Step 6 только когда blocking_count == 0 по результатам ревью.

⚠️ КРИТИЧЕСКОЕ ПРАВИЛО: НЕ ПРЕРЫВАТЬ ЦИКЛ

Главная сессия НЕ должна отправлять промежуточные результаты ревью пользователю.

Цикл develop → review → fix → review → ... выполняется полностью автономно. Пользователь НЕ должен пинговать агента чтобы продолжить — это провал оркестрации.

Единственные случаи когда можно писать пользователю до PR:

MAX_ROUNDS исчерпан — объяснить что не получилось и передать управление
Фатальная ошибка (тесты красные и fix-субагент не может починить за 3 попытки)
Неоднозначность в задаче, которую нельзя разрешить без решения пользователя

Во всех остальных случаях — молча запустить следующий шаг.

🔔 Обязательный самопинг через cron (anti-freeze)

Проблема: главная сессия может "замереть" после запуска субагентов — completion event не всегда поднимает сессию. Без внешнего триггера цикл остановится.

Правило: запустил группу субагентов → сразу поставил два cron. Без исключений.

Тайминг cron-ов:

Тип субагентов	Таймаут	Cron 1	Cron 2
4 ревью-роли	1200s (20 мин)	T + 20 мин	T + 23 мин
Fix-субагент	600s (10 мин)	T + 12 мин	T + 15 мин

Логика: cron должен срабатывать после ожидаемого завершения , не во время.

Шаблон cron-текста:

Full-cycle самопинг: раунд {N} ревью <project>/<branch>.
Проверь subagents list (labels содержат '<role>').

Если ВСЕ done → агрегируй sessions_history, подсчитай blocking.
  blocking > 0 → запусти fix-субагент (не пиши пользователю).
  blocking = 0 → создай PR → напиши пользователю итог.

Если ЕСТЬ active → удали этот cron, поставь новый на T+5 мин с тем же текстом.

НЕ пиши пользователю пока нет финального результата (PR или фатальная ошибка).

Самопереносящаяся логика (если субагенты ещё active):

# В тексте systemEvent cron должен содержать инструкцию:
# "если active → удали себя (cron remove), поставь новый cron на now+5min"
# Это обеспечивает polling без busy-loop

deleteAfterRun: true — каждый cron однократный
Два cron-а: если первый не поднял сессию — второй сработает через 3 мин
Если главная сессия уже продолжила сама — cron сработает на пустом subagents list → no-op (subagents done, PR уже есть или fix уже запущен)
Не использовать cron когда субагенты уже вернули результаты в активную сессию — агрегировать немедленно

Как проверять BLOCKING перед fix-субагентом

Перед тем как запускать fix-субагент, проверить реальный код (не доверять слепо выводу ревьюеров):

Открыть файлы, упомянутые в BLOCKING findings
Убедиться что проблема действительно есть в коде, а не false alarm
Ревьюеры без доступа к исходникам часто ошибаются (анализируют по диффу)
False alarms не нужно фиксить — они не BLOCKING

Это экономит раунды и не вносит лишних изменений в код.

Если BLOCKING = 0 с первого раза → fix-субагент не нужен, сразу Step 6.

Если BLOCKING > 0 → спавнить fix-субагент с task:

## FIX SUBAGENT — <project> <branch>

cd <project_root> && git checkout <branch>

Исправить следующие BLOCKING findings:

<нумерованный список с файл:строка и конкретным fix для каждого>

После каждого fix — запустить тесты:
<команда запуска тестов>
Не коммитить пока тесты красные.

Запустить линтер (Python):
python3 -m ruff check src/ tests/ 2>&1 | head -30
Исправить все ошибки ruff. Не коммитить с красным ruff.

Обновить документацию (ОБЯЗАТЕЛЬНО):
- AGENTS.md: добавить найденные pitfalls, обновить статус
- README / docs: если fix затронул поведение — обновить соответствующую секцию

После всех fix:
git add -A
git commit -m "fix: <краткое описание>"
git push https://KoshelevDV:$(gh auth token)@github.com/KoshelevDV/<repo>.git <branch>

Создать сводный issue для MINOR/MEDIUM:
gh issue create --repo KoshelevDV/<repo> \
  --title "Minor: <feature>" \
  --body "<список>"

Output в конце:
TESTS: <N passed>
LINT: ruff clean / <N errors>
FIXES: <N blocking fixed>
ISSUE: <url или none>

Таймаут: runTimeoutSeconds=600

Шаг 5.5: Обновление документации (после fix, перед PR)

После того как blocking_count == 0 и тесты зелёные — обновить документацию проекта:

cd <project_root>

# 1. AGENTS.md — обновить статус, стек, питфолы, новые решения
# Добавить в секцию Status: что реализовано, что изменилось
# Добавить в Pitfalls: нетривиальные находки из ревью

# 2. README.md — если добавлены новые возможности (config options, API endpoints, etc.)
# Обновить секцию конфигурации, добавить пример использования новой фичи

# 3. Коммит документации
git add AGENTS.md README.md
git commit -m "docs: update AGENTS.md and README for <feature>"
git push ...

Что обновлять в AGENTS.md:

## Status — отметить фичу как реализованную
## Pitfalls — добавить нетривиальные ограничения, найденные в ходе ревью
Стек, если добавились новые зависимости

Что обновлять в README.md:

Новые config options (с примером YAML)
Новые API endpoints
Изменения в поведении

Если ничего принципиально не изменилось (только внутренние фиксы) — достаточно AGENTS.md.

Шаг 6: PUSH + Output

Главная сессия создаёт PR:

gh pr create \
  --title "<type>: <description>" \
  --body "..." \
  --base main --head <branch>

Затем отправляет единственное сообщение пользователю :

✅ Full cycle завершён — <project> / <branch>

Tests:   <N passed / Y total>
Commits: <N>

Self-review:
  Developer  — <N blocking fixed, M minor → issue>
  Architect  — <N blocking fixed>
  QA/Manual  — <N ACs covered, M missing → issue>
  Security   — CLEAR / <N critical fixed>
  Final      — APPROVE ✅ / REQUEST_CHANGES ⚠️

PR: <url>
Issues: <url или none>

Severity Table (обязательно)

Роль	= BLOCKING	→ issue
Developer	BLOCKING	MINOR, SUGGESTION
Architect	BLOCKING	MINOR
Tester	MUST HAVE	SHOULD HAVE, NICE TO HAVE
Security	CRITICAL, HIGH	MEDIUM, LOW

MUST HAVE от tester = BLOCKING — недостающий тест для AC = незавершённая фича.

Rules

НЕ отправлять промежуточных сообщений пользователю (только итог)
Никогда не пушить с красными тестами
BLOCKING и CRITICAL/HIGH фиксить до MR
MINOR → один сводный issue, не коммит
docs/ читать всегда в developer-субагенте
TASK_CONTEXT обязателен — без него developer-субагент не начинает
git fetch перед checkout — всегда от актуального remote

Weekly Installs

Repository

aaaaqwq/claude-…e-skills

GitHub Stars

First Seen

Jan 1, 1970

Security Audits

Gen Agent Trust HubFail SocketFail SnykFail

agent-browser 浏览器自动化工具 - Vercel Labs 命令行网页操作与测试

147,400 周安装