Full Cycle Developer

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 по таблице:

Цикл 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: 1. MAX_ROUNDS исчерпан — объяснить что не получилось и передать управление 2. Фатальная ошибка (тесты красные и fix-субагент не может починить за 3 попытки) 3. Неоднозначность в задаче, которую нельзя разрешить без решения пользователя

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

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

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

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

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

Логика: 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 (обязательно)

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

---

Rules

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

AGENTS.md — full-cycle-skill

What is this

A documentation repository for the full-cycle OpenClaw skill — automated development pipeline: code → test → lint → 4-role parallel review → fix → PR.

Stack

• Platform: OpenClaw (AI agent orchestration)
• Primary language: Markdown (documentation)
• CI: None (docs-only repo)
• Target stacks: Python (pytest + ruff), Rust (cargo + clippy), .NET (dotnet), Go

Structure

full-cycle-skill/
├── SKILL.md                    # OpenClaw skill entry point — v3.3
├── README.md                   # EN + RU documentation
├── AGENTS.md                   # This file — AI agent context
├── docs/
│   ├── how-it-works.md         # Detailed pipeline description
│   ├── cron-anti-freeze.md     # Anti-freeze cron pattern
│   ├── setup-for-agents.md     # Setup guide for AI agents
│   └── stack-customization.md  # Adapting to different stacks
├── examples/
│   ├── python-project.md       # Python FastAPI example
│   └── rust-project.md         # Rust project example
└── LICENSE                     # MIT

Development Rules

• This is a docs-only repository — no executable code
• SKILL.md is the single source of truth for the skill behavior
• When updating the skill in workspace, sync changes here too
• Keep examples based on real projects (gitlab-reviewer, ralph-rs)
• Versioning: update version: field in SKILL.md front matter on breaking changes

Status

• ✅ Initial documentation created (2026-03-06)
• ✅ SKILL.md v3.3 (full cycle with cron anti-freeze)
• ✅ docs/ — all 4 topic files
• ✅ examples/ — Python + Rust
• 🔲 clawhub publication

How to use locally

# Copy skill to your OpenClaw workspace
cp SKILL.md ~/.openclaw/workspace/skills/full-cycle/SKILL.md

# Trigger in OpenClaw chat
# "full cycle для <project> <task>"

Pitfalls

• Cron anti-freeze is mandatory — without it, the main session may freeze after spawning subagents
• Scope rule: reviewers must only check DIFF changes, not pre-existing issues
• MAX_ROUNDS = 3 — if exceeded, report to user with details; don't loop infinitely
• False alarms: always verify BLOCKING findings in real code before spawning fix-subagent
• DOCS rule: developer subagent must update AGENTS.md + README before final commit
• Sessions_history limit: use limit=2 to get last message from review subagents

Cron Anti-Freeze Pattern

The Problem

OpenClaw subagents are asynchronous. When the main session spawns subagents (developer, 4 reviewers, fix-subagent), it doesn't actively wait — it relies on completion events to resume.

The freeze scenario: 1. Main session spawns 4 review subagents 2. All 4 finish successfully 3. Completion event is fired... but main session doesn't wake up 4. The full-cycle pipeline stalls indefinitely 5. User has to manually ping the agent to continue

This is a known issue with event-driven async orchestration: completion events may not always reliably resume the parent session.

Without anti-freeze: the user must ping the agent manually → defeats the purpose of full automation.

---

The Solution: Dual Cron as Insurance

Rule: After spawning any group of subagents → immediately schedule two cron jobs.

spawn subagents
     │
     ├─► cron_1 at T + expected_runtime + 3min  (primary)
     └─► cron_2 at T + expected_runtime + 6min  (backup)

Both crons fire at scheduled time and check subagent status:

• If all done → aggregate results → proceed with pipeline
• If still active → reschedule to now + 5min, delete current cron

---

Timing Formula

T = time subagents were spawned
expected_runtime = subagent runTimeoutSeconds
buffer = 3 min

cron_1 = T + expected_runtime + buffer
cron_2 = T + expected_runtime + buffer + 3min

Timing Table

---

Cron Job Template

Full-cycle self-ping: round {N} review <project>/<branch>.
Check subagents list (labels contain '<role>').

If ALL done → aggregate sessions_history, count blocking.
  blocking > 0 → spawn fix-subagent (do NOT message user).
  blocking = 0 → create PR → send user final output.

If ANY active → delete this cron, schedule new one at now+5min with same text.

Do NOT message user until final result (PR or fatal error).

Self-Rescheduling Logic

# Pseudocode inside cron-triggered session event:

active_subagents = subagents(action="list")["active"]
my_review_labels = ["developer-review", "architect-review", "tester-review", "security-review"]

still_running = any(
    any(label in s.get("label", "") for label in my_review_labels)
    for s in active_subagents
)

if still_running:
    # Remove current cron (it's deleteAfterRun anyway)
    # Schedule new cron for now + 5 minutes
    cron_create(
        text="Full-cycle self-ping: round {N} review <project>/<branch>. [same instructions]",
        runAt="now+5min",
        deleteAfterRun=True
    )
else:
    # All subagents done → aggregate and proceed
    reviews = collect_results_from_sessions_history()
    blocking_count = aggregate_blocking(reviews)
    
    if blocking_count > 0:
        spawn_fix_subagent(blocking_list)
        schedule_fix_crons()
    else:
        create_pr()
        send_final_output_to_user()

---

Key Properties

deleteAfterRun: true

Each cron is one-shot:

• Fires once at scheduled time
• Auto-deletes after execution
• No manual cleanup needed

Two Crons = Redundancy

If cron_1 fires but doesn't wake the session (rare but possible):

• cron_2 fires 3 minutes later
• Same logic, fresh attempt

If both fire but session is already running (cron woke it):

• First cron: does its work
• Second cron: checks subagents → all done or no relevant ones → no-op

No Double-Execution Risk

If the main session already continued on its own (completion event worked):

• Cron fires → checks subagents list → all done already
• blocking_count was already processed, fix was spawned or PR was created
• Cron sees the work is done → no-op

---

When NOT to Use Cron

Skip cron scheduling when subagents already returned results in the active session:

# Subagent returns result synchronously in same session turn
result = await sessions_spawn(task=..., waitForCompletion=True)
# → result available immediately
# → NO cron needed, aggregate immediately

Only schedule crons when you're using fire-and-forget spawning without waiting for completion in the same turn.

---

Example: Review Round Crons

# After spawning all 4 review subagents:
now = current_time()

cron_create(
    label="full-cycle-review-ping-1",
    text="""
    Full-cycle self-ping: round 1 review my-project/feat/jwt-auth.
    Check subagents list (labels contain 'review').
    
    If ALL done → aggregate sessions_history for keys: [key_dev, key_arch, key_test, key_sec]
    Count blocking findings. 
    blocking > 0 → spawn fix-subagent with blocking list.
    blocking = 0 → create PR → send user final output.
    
    If ANY active → delete this cron, schedule new at now+5min with same text.
    Do NOT message user until PR or fatal error.
    """,
    runAt=now + timedelta(minutes=23),
    deleteAfterRun=True
)

cron_create(
    label="full-cycle-review-ping-2",
    text="[same text as ping-1]",
    runAt=now + timedelta(minutes=26),
    deleteAfterRun=True
)

---

Example: Fix Round Crons

# After spawning fix subagent:
now = current_time()

cron_create(
    label="full-cycle-fix-ping-1",
    text="""
    Full-cycle self-ping: fix round 1 for my-project/feat/jwt-auth.
    Check subagents list (labels contain 'fix').
    
    If done → re-run full review (spawn 4 roles again) → schedule review crons.
    If active → reschedule this cron to now+5min.
    
    Do NOT message user.
    """,
    runAt=now + timedelta(minutes=13),
    deleteAfterRun=True
)

---

Why This Works

The anti-freeze pattern is essentially polling with exponential backoff collapsed to fixed intervals:

1. First check at T+N (expected completion time + buffer) 2. If not done: reschedule at T+N+5, T+N+10, etc. 3. Eventually all subagents finish → pipeline continues

The dual-cron redundancy ensures no single missed event causes a permanent stall.

Result: Full cycle automation that's self-healing and doesn't require user intervention.

How It Works — Full Cycle Pipeline

ASCII Pipeline Diagram

User trigger: "full cycle для <project> <task>"
                         │
                         ▼
         ┌───────────────────────────────────┐
         │     MAIN SESSION (Orchestrator)    │
         │           [SILENT]                 │
         └───────────────────────────────────┘
                         │
         ┌───────────────▼───────────────────┐
         │  STEP 1-3: DEVELOP                 │
         │  ┌─────────────────────────────┐  │
         │  │  Developer Subagent          │  │
         │  │  • git checkout -b branch    │  │
         │  │  • Read AGENTS.md + docs/    │  │
         │  │  • memory_search(context)    │  │
         │  │  • Implement feature         │  │
         │  │  • Write tests (green ✅)    │  │
         │  │  • Fix lint (clean ✅)       │  │
         │  │  • Update AGENTS.md + README │  │
         │  │  • git commit + push         │  │
         │  └─────────────────────────────┘  │
         │  Output: BRANCH, STACK, DIFF       │
         └───────────────────────────────────┘
                         │
         ┌───────────────▼───────────────────┐
         │  STEP 4: REVIEW (parallel × 4)     │
         │                                    │
         │  ┌──────────┐  ┌──────────────┐   │
         │  │ Developer│  │  Architect   │   │
         │  │  review  │  │   review     │   │
         │  └────┬─────┘  └──────┬───────┘   │
         │       │               │            │
         │  ┌────┴─────┐  ┌──────┴───────┐   │
         │  │  Tester  │  │   Security   │   │
         │  │  review  │  │   review     │   │
         │  └────┬─────┘  └──────┬───────┘   │
         │       └───────┬───────┘            │
         │               ▼                    │
         │  STEP 4e: Final Review (inline)    │
         │  Orchestrator reads all 4 reviews  │
         │  → APPROVE or REQUEST_CHANGES      │
         └───────────────────────────────────┘
                         │
              ┌──────────┴──────────┐
              │                     │
         BLOCKING = 0         BLOCKING > 0
              │                     │
              ▼          ┌──────────▼──────────┐
         STEP 6          │  STEP 5: FIX         │
                         │  Fix Subagent         │
                         │  • Fix BLOCKING list  │
                         │  • Tests green ✅     │
                         │  • Lint clean ✅      │
                         │  • git commit + push  │
                         └──────────┬───────────┘
                                    │
                         ┌──────────▼───────────┐
                         │ repeat STEP 4 (re-review)│
                         │ max 3 rounds           │
                         └──────────┬────────────┘
                                    │
         ┌──────────────────────────▼────────────┐
         │  STEP 6: PUSH + OUTPUT                 │
         │  • gh pr create                        │
         │  • Single message to user              │
         │  ✅ Full cycle done — PR: <url>        │
         └────────────────────────────────────────┘

---

Step-by-Step Details

Steps 1-3: Developer Subagent

Purpose: Implement the feature from scratch on a new branch.

Actions: 1. git fetch origin && git pull origin main && git checkout -b <branch> 2. Read AGENTS.md, docs/, ROADMAP.md (project context) 3. memory_search() for relevant architecture decisions 4. Read role prompt from prompts/developer/<stack>.md 5. Implement the feature following Critical Rules in AGENTS.md 6. Read prompts/tester/autotests.md and write tests 7. Run tests — must be green before committing 8. Run linter — must be clean before committing 9. Update docs (mandatory):

• AGENTS.md: status, new decisions, pitfalls
• README.md: if public API/CLI changed
• ROADMAP.md: mark completed item ✅

10. git commit and push

Output block:

BRANCH: feat/my-feature
STACK: python
TESTS: 42 passed
LINT: ruff clean
DOCS: AGENTS.md updated / README updated
DIFF_SUMMARY: Added JWT auth middleware, 3 new endpoints, tests cover happy path + errors

Timeout: 900 seconds

---

Step 4: 4 Parallel Review Subagents

Purpose: Independent review of the diff from 4 specialist perspectives.

All 4 subagents are spawned simultaneously with:

• Full role prompt text
• PROJECT_CONTEXT (AGENTS.md content)
• TASK_CONTEXT (task description + acceptance criteria)
• DIFF (git diff output, max 400 lines)

Reviewer Roles

Severity Table

Note: MUST HAVE from Tester = BLOCKING. A missing test for an AC = incomplete feature.

Scope Rule ⚠️

All reviewers must ONLY check changes in the DIFF.

Pre-existing issues that existed before this MR:

• → NOT BLOCKING
• → List in MINOR section with [pre-existing] tag
• Security especially: do NOT block PR for issues not introduced by current change

Step 4e: Final Review (Inline)

The orchestrator (main session) reads all 4 reviews and renders its own final verdict:

• Reads prompts/reviewer/general.md
• Aggregates findings from all roles
• Verdicts: APPROVE ✅ or REQUEST_CHANGES ⚠️
• Counts total blocking_count

Timeout per subagent: 1200 seconds

---

Step 5: Fix Subagent

Purpose: Fix all BLOCKING findings from the review.

Actions: 1. Receive explicit numbered list of BLOCKING findings (file:line + fix description) 2. Fix each finding 3. Run tests after each fix — must stay green 4. Run linter — must stay clean 5. Update AGENTS.md with discovered pitfalls 6. git commit -m "fix: ..." and push 7. Create a single combined issue for all MINOR/MEDIUM findings

Verification rule: Before spawning fix-subagent, orchestrator must verify findings in real code:

• Open the files mentioned in BLOCKING findings
• Confirm the issue actually exists (reviewers analyze by diff and can have false positives)
• Skip false alarms — don't fix what isn't broken

Timeout: 600 seconds

Fix → Review Loop

review_round = 1
MAX_ROUNDS = 3

while blocking_count > 0:
    if review_round > MAX_ROUNDS:
        report to user: "Could not resolve all BLOCKING in 3 iterations"
        break
    spawn fix_subagent(blocking_list)
    review_round += 1
    repeat full Step 4 (all 4 roles + 4e)
    update blocking_count

After each fix — mandatory full re-review (all 4 roles + final). Never consider branch clean based on "fix was applied" alone — new changes may introduce new BLOCKING.

---

Step 6: PR + Output

Actions:

gh pr create \
  --title "<type>: <description>" \
  --body "## Summary\n...\n## Changes\n...\n## Testing\n..." \
  --base main --head <branch>

Single message to user:

✅ Full cycle done — my-project / feat/my-feature

Tests:   42 passed / 42 total
Commits: 3

Self-review:
  Developer  — 2 blocking fixed, 1 minor → issue #42
  Architect  — 0 blocking
  QA/Manual  — 5 ACs covered, 1 SHOULD HAVE → issue #42
  Security   — CLEAR
  Final      — APPROVE ✅

PR: https://github.com/org/my-project/pull/15
Issues: https://github.com/org/my-project/issues/42

---

DOCS Rule

Why AGENTS.md + README are mandatory updates:

The developer subagent must update docs before the final commit because:

1. AGENTS.md is the AI context for the next session — stale docs = wrong decisions 2. README represents public API/CLI contract — undocumented changes = broken UX 3. ROADMAP alignment — orchestrator and architect need to know what's done

Skipping docs update = the feature is incomplete.

---

Interruption Rules

The orchestrator must NOT send intermediate messages to the user during:

• develop → review transition
• review → fix transition
• fix → re-review transition

Only valid interruptions: 1. MAX_ROUNDS exceeded — explain what failed, pass control to user 2. Fatal error — tests red and fix-subagent can't resolve in 3 attempts 3. Task ambiguity that requires user decision

All other cases: silently proceed to next step.

Setup Guide for AI Agents

This skill is designed for OpenClaw but the orchestration pattern can be adapted to any AI agent platform that supports subagent spawning and async coordination.

Prerequisites

• OpenClaw installed and running (see openclaw.ai)
• GitHub CLI (gh) authenticated: gh auth login
• A project with tests and a linter (Python/pytest+ruff, Rust/cargo+clippy, etc.)
• Access to OpenClaw tools: sessions_spawn, cron, subagents, sessions_history

---

Step 1: Install the Skill

Copy SKILL.md to your OpenClaw workspace:

mkdir -p ~/.openclaw/workspace/skills/full-cycle
cp SKILL.md ~/.openclaw/workspace/skills/full-cycle/SKILL.md

OpenClaw will auto-discover the skill from the skills/ directory.

---

Step 2: Create Role Prompts

Create the prompts directory structure:

mkdir -p /opt/projects/llm-review-prompts/prompts/{developer,architect,tester,reviewer,security}

developer/python.md (template)

# Developer Review — Python

You are a senior Python developer reviewing a pull request diff.

Your job: identify code quality issues that BLOCK merge.

## What to check
- Correctness: logic errors, wrong assumptions
- Error handling: unhandled exceptions, missing validation
- Code style: PEP8 compliance, naming conventions
- DRY: duplicate code that should be extracted
- Edge cases: null/empty inputs, boundary conditions
- Dependencies: unnecessary imports, version constraints

## Scope rule
ONLY check changes in the DIFF provided. Do NOT report on pre-existing code issues.
Pre-existing issues → list with [pre-existing] tag in MINOR section.

## Output format

BLOCKING:

• [description] file.py:42 → fix: [specific fix]

MINOR:

• [description] file.py:15

Итого: X blocking, Y minor.

architect/python.md (template)

# Architect Review — Python

You are a software architect reviewing a pull request diff.

## What to check
- Design decisions: is the approach the right one?
- SOLID principles: SRP, OCP, LSP, ISP, DIP
- Coupling: tight coupling, circular dependencies
- Scalability: will this work at 10x load?
- ROADMAP alignment: does this fit the project direction?

## Scope rule
ONLY check changes in the DIFF.

## Output format

BLOCKING:

• [description] file.py:42 → fix: [specific fix]

MINOR:

• [description]

Итого: X blocking, Y minor.

tester/autotests.md (template)

# Tester Review — Autotests

You are a QA engineer reviewing test coverage for a pull request.

## What to check
- AC coverage: are all acceptance criteria covered by tests?
- Test quality: do tests actually validate the right things?
- Edge cases: negative tests, boundary values, error paths
- Test isolation: no side effects between tests
- Missing tests: which scenarios have zero coverage?

## Severity
- MUST HAVE: missing test for acceptance criteria → BLOCKING
- SHOULD HAVE: missing edge case test → issue
- NICE TO HAVE: additional coverage → suggestion

## Scope rule
ONLY check new/changed tests and untested new code in DIFF.

## Output format

MUST HAVE (blocking):

• [test description] covers AC: [which AC]

SHOULD HAVE (issue):

• [test description]

Итого: X must have, Y should have.

security/general.md (template)

# Security Review

You are a security engineer reviewing a pull request diff.

## What to check
- Injection: SQL, command, path traversal, template injection
- Authentication / Authorization: missing auth checks, privilege escalation
- Secrets: hardcoded credentials, API keys in code
- Input validation: unsanitized user input
- Cryptography: weak algorithms, improper use
- Dependencies: known CVEs in added packages

## Severity
- CRITICAL: remote code execution, auth bypass → BLOCKING
- HIGH: sensitive data exposure, privilege escalation → BLOCKING
- MEDIUM: info disclosure, DoS potential → issue
- LOW: defense-in-depth improvements → ignore for MR

## Scope rule
ONLY check changes in the DIFF. Pre-existing vulnerabilities:
- NOT BLOCKING for this MR
- Note with [pre-existing] tag

## Output format

CRITICAL/HIGH (blocking):

• [description] file.py:42 → fix: [specific fix]

MEDIUM (issue):

• [description]

LOW (ignore):

• [description]

Итого: X blocking, Y medium.

reviewer/general.md (template)

# Final Reviewer

You are the final reviewer aggregating inputs from 4 specialist reviewers.

## Your job
1. Read all 4 reviews (Developer, Architect, Tester, Security)
2. Identify unique BLOCKING findings (deduplicate overlapping ones)
3. Verify scope: are all blocking findings actually in the DIFF?
4. Render final verdict: APPROVE or REQUEST_CHANGES

## Output format

Final Verdict: APPROVE ✅ / REQUEST_CHANGES ⚠️

Total unique BLOCKING: N

• [description] (from Developer/Architect/Tester/Security)

Unique MINOR: M (→ single issue)

---

Step 3: Configure for Your Project

Update these values in SKILL.md when using it:

---

Step 4: Adapting Roles to Your Stack

---

Step 5: Trigger

In OpenClaw chat:

full cycle для <project> <task description>

Examples:

full cycle для my-api implement rate limiting
full cycle для my-service fix authentication bug (#23)
full cycle для my-app add export to CSV feature

---

How the Anti-Freeze Cron Works

The main session may "freeze" after spawning subagents — completion events aren't guaranteed to resume it. The cron pattern provides insurance:

1. Main session spawns 4 review subagents
2. Immediately schedules 2 crons:
   cron_1 at T + 23min (primary)
   cron_2 at T + 26min (backup)
3. Crons fire and check if subagents are still running:
   - All done → aggregate results → proceed
   - Still running → reschedule cron to now+5min
4. Eventually subagents finish → pipeline continues

See cron-anti-freeze.md for full details and code examples.

---

Minimal Viable Setup

If you want the simplest version without 4 roles:

1. Developer subagent: write code + tests + lint
2. Single reviewer subagent: general code review
3. Cron for anti-freeze
4. Fix if blocking > 0
5. Create PR

Role prompt for single reviewer:

Review this diff as a senior developer. 
Check: correctness, security basics, test coverage, code quality.
Scope: ONLY changes in DIFF.
Output: BLOCKING (must fix) / MINOR (create issue) / APPROVE.

---

Troubleshooting

Stack Customization

Adaptation Table

---

Python Stack

Requirements

• Python 3.11+
• pytest for tests
• ruff for linting and formatting

Developer subagent commands

# Install dependencies
pip install -r requirements.txt  # or: uv pip install -r requirements.txt

# Run tests
python3 -m pytest tests/ -q 2>&1 | tail -20

# Run linter
python3 -m ruff check src/ tests/ 2>&1 | head -30

# Fix lint errors
python3 -m ruff check --fix src/ tests/
python3 -m ruff format src/ tests/

Fix subagent lint loop

while ! python3 -m ruff check src/ tests/ --quiet; do
    python3 -m ruff check --fix src/ tests/
    python3 -m ruff format src/ tests/
done

Prompt files needed

prompts/developer/python.md
prompts/architect/python.md
prompts/tester/autotests.md
prompts/reviewer/general.md
prompts/security/general.md

---

Rust Stack

Requirements

• Rust stable toolchain
• cargo clippy for linting
• cargo fmt for formatting

Developer subagent commands

# Build check (faster than full build)
cargo check 2>&1 | grep "^error" | head -20

# Run tests (quiet mode)
cargo test -- --quiet 2>&1 | tail -15

# Run clippy
cargo clippy -- -D warnings 2>&1 | head -30

# Format check
cargo fmt --check

Lint and format in fix subagent

# Fix formatting
cargo fmt

# Check clippy (manual fix required)
cargo clippy -- -D warnings 2>&1 | head -30
# Fix issues, then:
cargo clippy -- -D warnings  # must be clean before commit

Important: Rust context economy

# Prefer cargo check over cargo build for diagnostics
cargo check 2>&1 | grep "^error\[" | head -40

# Test with quiet flag
cargo test -- --quiet 2>&1 | tail -15

# Only full build when checking binary output
cargo build --release 2>&1 | grep -E "^error" | head -20

Prompt files needed

prompts/developer/rust.md
prompts/architect/rust.md
prompts/tester/autotests.md
prompts/reviewer/general.md
prompts/security/general.md

---

.NET Stack

Requirements

• .NET 8 SDK
• dotnet format for formatting

Developer subagent commands

# Build
dotnet build 2>&1 | grep -E "error|warning" | head -30

# Run tests
dotnet test --logger "console;verbosity=minimal" 2>&1 | tail -20

# Format check
dotnet format --verify-no-changes 2>&1 | head -20

# Apply format
dotnet format

Fix subagent lint

dotnet format
dotnet build 2>&1 | grep "^.*error" | head -20
# Fix errors manually
dotnet test --logger "console;verbosity=minimal" 2>&1 | tail -20

Prompt files needed

prompts/developer/dotnet.md
prompts/architect/dotnet.md
prompts/tester/autotests.md
prompts/reviewer/general.md
prompts/security/general.md

---

Go Stack

Requirements

• Go 1.21+
• golangci-lint for linting

Developer subagent commands

# Build check
go build ./... 2>&1 | head -20

# Run tests
go test ./... -v 2>&1 | tail -30

# Lint
golangci-lint run 2>&1 | head -30

# Format
gofmt -w .

Fix subagent lint loop

gofmt -w .
go vet ./... 2>&1 | head -20
golangci-lint run 2>&1 | head -30

Prompt files needed

prompts/developer/go.md
prompts/architect/go.md
prompts/tester/autotests.md
prompts/reviewer/general.md
prompts/security/general.md

---

Multi-Language Projects

For projects with multiple languages (e.g., Python backend + TypeScript frontend):

1. Set STACK based on primary language in AGENTS.md 2. Add secondary linters in developer/fix subagent tasks explicitly:

   # Python backend
   python3 -m ruff check src/ tests/
   # TypeScript frontend
   cd frontend && npm run lint

3. Use developer/python.md prompt but add TS-specific notes in AGENTS.md

---

Updating SKILL.md for Your Stack

In SKILL.md, find the test/lint commands in subagent tasks and replace:

# Python → Rust example:

# Developer subagent section:
# Before: python3 -m pytest tests/ -q
# After:  cargo test -- --quiet

# Before: python3 -m ruff check src/ tests/
# After:  cargo clippy -- -D warnings

# Push command:
# Before: git push https://user:$(gh auth token)@github.com/org/repo.git <branch>
# After:  (same, just update org/repo)

---

Stack Detection from AGENTS.md

The skill reads AGENTS.md to determine stack. Your project's AGENTS.md should include:

## Stack
- Language: Python 3.12
- Test runner: pytest
- Linter: ruff
- Framework: FastAPI

The developer subagent selects prompts/developer/python.md based on this.

Example: Python Project (gitlab-reviewer)

Real-world example from the gitlab-reviewer project — a FastAPI service that reviews GitLab MRs using LLMs.

Project Context

• Stack: Python 3.12, FastAPI, pytest, ruff
• Task: Fix ruff lint errors (issue #11)
• Branch: fix/ruff-lint-11

---

Developer Subagent — Full Task Prompt

## DEVELOPER SUBAGENT — gitlab-reviewer fix ruff lint (#11)

INIT:
- cd /opt/projects/gitlab-reviewer
- git fetch origin && git pull origin main
- git checkout -b fix/ruff-lint-11
- Read AGENTS.md to understand project structure
- Read src/ directory structure

TASK_CONTEXT:
Issue #11: ruff check finds 47 lint errors across src/ and tests/.
Main categories: E501 (line too long), F401 (unused imports), 
E711 (comparison to None), B007 (unused loop variable).

DEVELOP:
- Run: python3 -m ruff check src/ tests/ 2>&1 | head -60
- Fix each category systematically:
  * F401: remove unused imports
  * E501: wrap long lines (max 88 chars)
  * E711: use `is None` / `is not None`
  * B007: rename unused loop vars to `_`
- Do NOT change logic, only lint fixes

TEST:
- python3 -m pytest tests/ -q 2>&1 | tail -20
- All tests must pass after lint fixes
- If any test breaks — investigate and fix without changing behavior

LINT (verify):
- python3 -m ruff check src/ tests/ 2>&1
- Must return: "All checks passed."

DOCS:
- Update AGENTS.md: Status section → mark #11 as fixed
- Add to Pitfalls: "E501 lines were wrapped but logic unchanged"

git add -A
git commit -m "fix: resolve 47 ruff lint errors (issue #11)"
git push https://KoshelevDV:$(gh auth token)@github.com/KoshelevDV/gitlab-reviewer.git fix/ruff-lint-11

Output:
BRANCH: fix/ruff-lint-11
STACK: python
TESTS: 23 passed
LINT: ruff clean
DOCS: AGENTS.md updated
DIFF_SUMMARY: Fixed 47 ruff errors: removed 12 unused imports, wrapped 28 long lines, fixed 5 None comparisons, renamed 2 unused loop vars

---

Security Review Subagent — Full Task Prompt

## SECURITY REVIEW

You are a security engineer reviewing a pull request diff.

### What to check
- Injection: SQL, command, path traversal, template injection
- Authentication / Authorization: missing auth checks, privilege escalation
- Secrets: hardcoded credentials, API keys in code
- Input validation: unsanitized user input
- Cryptography: weak algorithms, improper use

### Severity
- CRITICAL: remote code execution, auth bypass → BLOCKING
- HIGH: sensitive data exposure → BLOCKING
- MEDIUM: info disclosure, DoS potential → issue
- LOW: defense-in-depth → ignore for MR

### Scope rule
ONLY check changes in DIFF. Pre-existing issues → [pre-existing] in MINOR.

---

PROJECT_CONTEXT:
# AGENTS.md — gitlab-reviewer
## What is this
FastAPI service that fetches GitLab MR diffs and sends them to LLM for code review.
Uses GitLab API (token from env), OpenAI API (key from env).

## Stack
Python 3.12, FastAPI, httpx, python-gitlab, openai SDK

## Critical Rules
- Never log API tokens
- All GitLab/OpenAI tokens from environment variables only
- No hardcoded credentials anywhere

---

TASK_CONTEXT:
Fix ruff lint errors (issue #11). Pure style fixes — no logic changes.
AC: ruff check returns 0 errors. All 23 tests pass.

---

DIFF:
diff --git a/src/gitlab_reviewer/client.py b/src/gitlab_reviewer/client.py
index a3b2c1d..f4e5678 100644
--- a/src/gitlab_reviewer/client.py
+++ b/src/gitlab_reviewer/client.py
@@ -1,7 +1,5 @@
 import os
-import json
-import sys
 from typing import Optional
 
 class GitLabClient:
@@ -45,7 +43,7 @@ class GitLabClient:
-        for key, value in headers.items():
+        for _, value in headers.items():
             if value is None:
                 continue

---

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

---

Actual Cycle Output

✅ Full cycle завершён — gitlab-reviewer / fix/ruff-lint-11

Tests:   23 passed / 23 total
Commits: 2

Self-review:
  Developer  — 0 blocking, 0 minor
  Architect  — 0 blocking (lint-only change, no design impact)
  QA/Manual  — 23 ACs covered (all existing tests pass)
  Security   — CLEAR (no security-relevant changes in diff)
  Final      — APPROVE ✅

PR: https://github.com/KoshelevDV/gitlab-reviewer/pull/12
Issues: none

Timeline:

• T+0: full cycle triggered
• T+2min: developer subagent started
• T+8min: developer subagent done (fix + tests + lint)
• T+8min: 4 review subagents spawned (parallel)
• T+8min: cron_1 scheduled at T+31min
• T+23min: all 4 reviewers done (async)
• T+23min: final review inline → APPROVE, 0 blocking
• T+24min: PR created → output sent to user

Cron was not needed — all 4 subagents completed and triggered session resume before cron_1 fired. Cron_1 fired at T+31min → found 0 active subagents + PR already exists → no-op.

---

What the Fix Covered

ruff check src/ tests/ (before):
  src/gitlab_reviewer/client.py:3:8: F401 [*] `json` imported but unused
  src/gitlab_reviewer/client.py:4:8: F401 [*] `sys` imported but unused
  src/gitlab_reviewer/client.py:45:14: B007 Loop control variable `key` not used
  src/gitlab_reviewer/reviewer.py:12:5: E711 Comparison to `None` (use `is None`)
  ... (43 more)

ruff check src/ tests/ (after):
  All checks passed.

---

Lessons Learned (from AGENTS.md)

## Pitfalls

- **ruff E501**: When wrapping long lines, watch for string concatenation 
  that breaks semantics. Always run tests after wrapping.
- **B007 fix**: Renaming loop variable to `_` is correct, but if the variable 
  is used in inner scope, this causes NameError. Verify before renaming.
- **F401 in __init__.py**: Some imports in __init__.py exist for re-export. 
  Use `# noqa: F401` to suppress, don't delete.

Example: Rust Project (ralph-rs)

Real-world example from the ralph-rs project — a Rust CLI tool.

Project Context

• Stack: Rust stable, cargo, clippy
• Task: Implement config file support
• Branch: feat/config-file

---

Key Differences from Python

Test command

# Python:
python3 -m pytest tests/ -q 2>&1 | tail -20

# Rust:
cargo test -- --quiet 2>&1 | tail -15

Lint command

# Python:
python3 -m ruff check src/ tests/

# Rust:
cargo clippy -- -D warnings 2>&1 | head -30

Build check (prefer over full build for context economy)

# Use cargo check for faster error detection:
cargo check 2>&1 | grep "^error" | head -20

# Full build only when needed:
cargo build 2>&1 | grep -E "^error\[|^error:" | head -20

---

Developer Subagent — Task Prompt (Rust)

## DEVELOPER SUBAGENT — ralph-rs implement config file support

INIT:
- cd /opt/projects/ralph-rs
- git fetch origin && git pull origin main
- git checkout -b feat/config-file
- Read AGENTS.md (Critical Rules, Stack, Structure)
- Read src/ to understand current architecture

DEVELOP:
- Read prompts/developer/rust.md
- Implement config file parsing (TOML format, using `toml` crate)
- Config file location: ~/.config/ralph/config.toml
- Fallback to defaults if file not found
- Use serde for deserialization

TEST:
- Read prompts/tester/autotests.md
- Write tests for:
  * Config file loading (happy path)
  * Missing config file (fallback to defaults)
  * Invalid TOML (error handling)
  * Config value overrides
- Run: cargo test -- --quiet 2>&1 | tail -15
- All tests must pass

LINT:
- cargo clippy -- -D warnings 2>&1 | head -30
- Fix all clippy warnings before commit
- cargo fmt --check (apply cargo fmt if needed)
- Must be clean before commit

DOCS:
- Update AGENTS.md: add Config struct to Stack section
- Update README.md: add config file section with example TOML
- Update AGENTS.md Status: mark config file feature as implemented

git add -A
git commit -m "feat: add config file support (TOML, ~/.config/ralph/config.toml)"
git push https://KoshelevDV:$(gh auth token)@github.com/KoshelevDV/ralph-rs.git feat/config-file

Output:
BRANCH: feat/config-file
STACK: rust
TESTS: 18 passed
LINT: clippy clean
DOCS: AGENTS.md updated, README.md updated
DIFF_SUMMARY: Added Config struct with serde, load_config() function, TOML parsing via toml crate, 4 new tests covering happy path + error cases

---

Architect Review — Rust-Specific Focus

## ARCHITECT REVIEW — Rust

Key architectural concerns for Rust projects:

### Ownership and lifetimes
- Does the new code introduce unnecessary clones?
- Are lifetimes explicit where needed?
- Does config data outlive the parsers?

### Error handling
- Is `?` operator used consistently?
- Are errors typed with `thiserror` / `anyhow`?
- Are errors propagated, not swallowed?

### API design
- Is Config struct `pub` only where needed?
- Is the config loading function testable (dependency injection)?
- Does it use `PathBuf` not `String` for paths?

### Dependencies
- Is `toml` the right choice vs `serde_json` or `config` crate?
- Are new crate versions pinned appropriately?

DIFF review scope: ONLY changes in this PR.

---

Example Clippy Findings (BLOCKING)

Developer subagent output before fix:

cargo clippy -- -D warnings

error: redundant clone
  --> src/config.rs:45:30
   |
45 |     let path = config_path.clone().to_str()...
   |
   = help: remove `.clone()`
   [clippy::redundant_clone]

error: use of `unwrap` in a function that returns `Result`
  --> src/config.rs:67:18
   |  
67 |     let content = fs::read_to_string(&path).unwrap();
   |
   = help: use `?` instead
   [clippy::unwrap_used]

error[E0499]: cannot borrow `config` as mutable more than once at a time
  --> src/config.rs:89:5

After fix:

cargo clippy -- -D warnings
    Finished dev [unoptimized + debuginfo] target(s) in 2.34s
(no output = clean)

---

Context Economy Tips for Rust

# BAD (full build, lots of output):
cargo build

# GOOD (errors only):
cargo check 2>&1 | grep "^error" | head -20

# BAD (verbose test output):
cargo test

# GOOD (quiet, just results):
cargo test -- --quiet 2>&1 | tail -15

# BAD (full clippy with lots of warnings):
cargo clippy

# GOOD (only errors, fail on warnings):
cargo clippy -- -D warnings 2>&1 | head -30

# Redirect large outputs to file:
cargo build 2>&1 > /tmp/build.log && grep "^error" /tmp/build.log | head -20

---

Cycle Output (Rust Project)

✅ Full cycle завершён — ralph-rs / feat/config-file

Tests:   18 passed / 18 total
Commits: 3

Self-review:
  Developer  — 2 blocking fixed (redundant clone, unwrap→?), 1 minor → issue
  Architect  — 1 blocking fixed (Config not Send+Sync), 0 minor
  QA/Manual  — 4 ACs covered (load/fallback/invalid/override)
  Security   — CLEAR (config paths sanitized, no secrets in config)
  Final      — APPROVE ✅

PR: https://github.com/KoshelevDV/ralph-rs/pull/7
Issues: https://github.com/KoshelevDV/ralph-rs/issues/8

Fix subagent was needed (blocking = 3):

• Round 1: fix clippy errors + ownership issue → 1 round sufficient
• Re-review after fix: 0 blocking → PR created

---

Lessons Learned (Rust-specific)

## Pitfalls

- **clippy::unwrap_used in Result context**: Always use `?` operator 
  in functions returning Result. clippy -D warnings catches this.
  
- **Config struct thread-safety**: If Config is shared across async 
  tasks, it must implement Send + Sync. Use Arc<RwLock<Config>> for 
  mutable shared config.
  
- **toml crate vs config crate**: `toml` is simpler for single-file 
  configs. `config` crate supports multi-source merging (file + env vars).
  For ralph-rs, `toml` was sufficient.
  
- **cargo check vs cargo build**: Always use cargo check for error 
  detection in subagents — it's 3-5x faster and produces the same 
  error messages without building binaries.

full-cycle-skill

Automated development skill for OpenClaw AI agents: idea → code → test → lint → 4-role parallel review → fix → PR

 

---

What is this?

A skill for OpenClaw that automates the full development cycle:

1. Developer subagent writes code, tests, fixes lint, updates docs 2. 4 parallel reviewers (Python Dev / Architect / QA / Security) review the diff independently 3. Orchestrator (main session) aggregates results, counts blocking findings 4. Fix subagent (if needed) fixes all blocking findings 5. PR created — user sees only the final result

The cycle repeats review → fix up to 3 rounds. Each round reviewers only see the new diff.

Pipeline

User: "full cycle для my-project implement feature X"
         │
         ▼
┌─────────────────────────────────────────────────────────┐
│  MAIN SESSION (silent orchestrator)                      │
│                                                          │
│  Step 1-3: [developer subagent]                         │
│    └─ git checkout -b feature/X                         │
│    └─ implement + tests (green) + lint (clean)          │
│    └─ update AGENTS.md + README                         │
│                                                          │
│  Step 4: [4 parallel review subagents]                  │
│    ├─ Developer role  ──┐                               │
│    ├─ Architect role  ──┤──► aggregate BLOCKING         │
│    ├─ QA/Tester role  ──┤    count                      │
│    └─ Security role   ──┘                               │
│    └─ Step 4e: Final inline review                      │
│                                                          │
│  Step 5: (if BLOCKING > 0)                              │
│    └─ [fix subagent] → fixes → re-review               │
│    └─ repeat up to 3 rounds                             │
│                                                          │
│  Step 6: gh pr create → output to user                  │
└─────────────────────────────────────────────────────────┘
         │
         ▼
User sees: ✅ PR: https://github.com/...

See docs/how-it-works.md for the full detailed pipeline.

Quick Start

1. Install OpenClaw

See openclaw.ai or docs.openclaw.ai

2. Install this skill

Copy SKILL.md to your OpenClaw workspace:

mkdir -p ~/.openclaw/workspace/skills/full-cycle
cp SKILL.md ~/.openclaw/workspace/skills/full-cycle/SKILL.md

Or install via clawhub (when published):

/install-skill full-cycle

3. Set up role prompts

The skill requires role prompts at /opt/projects/llm-review-prompts/prompts/:

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

See docs/setup-for-agents.md for prompt templates.

4. Trigger

full cycle для <project> <task description>

Examples:

full cycle для gitlab-reviewer fix ruff lint (#11)
full cycle для my-api implement JWT authentication
full cycle для my-service refactor database layer

How it works

See docs/how-it-works.md

Anti-freeze cron pattern

See docs/cron-anti-freeze.md

Adapting for your stack

See docs/stack-customization.md

---

---

full-cycle-skill (RU)

Скилл автоматизации разработки для AI-агентов OpenClaw: идея → код → тесты → линтинг → 4 роли параллельного ревью → фикс → PR

Что это?

Скилл для OpenClaw, который автоматизирует полный цикл разработки:

1. Developer-субагент пишет код, тесты, исправляет линтинг, обновляет документацию 2. 4 параллельных ревьюера (Python Dev / Архитектор / QA / Security) проверяют diff независимо 3. Оркестратор (главная сессия) агрегирует результаты, считает blocking-находки 4. Fix-субагент (при необходимости) исправляет все blocking 5. Создаётся PR — пользователь видит только финальный результат

Цикл повторяет ревью → фикс до 3 раундов. В каждом раунде ревьюеры видят только новый diff.

Быстрый старт

1. Установить OpenClaw

Смотри openclaw.ai или docs.openclaw.ai

2. Установить скилл

mkdir -p ~/.openclaw/workspace/skills/full-cycle
cp SKILL.md ~/.openclaw/workspace/skills/full-cycle/SKILL.md

3. Настроить промпты ролей

Скилл требует промпты ролей в /opt/projects/llm-review-prompts/prompts/:

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

Шаблоны промптов — в docs/setup-for-agents.md.

4. Запустить

full cycle для <проект> <описание задачи>

Примеры:

full cycle для gitlab-reviewer исправить ruff lint (#11)
full cycle для my-api реализовать JWT авторизацию

Как работает

Смотри docs/how-it-works.md

Паттерн anti-freeze через cron

Смотри docs/cron-anti-freeze.md

Адаптация под свой стек

Смотри docs/stack-customization.md