Типи задач і заповнені артефакти

General · environment-setup

Перевірити, що Claude Code запускається в правильному repository із зрозумілими командами, налаштуваннями та безпечним стартовим станом.

• Встановлення, авторизація та версія CLI.
• README, scripts і проєктні settings.
• Git status і перша контрольна точка.

• Редагування application code.
• Зміна permissions заради швидкого обходу проблем.
• Публікація секретів або виконання незворотних дій.

• Repository і поточний стан підтверджені.
• Команди запуску й перевірки знайдені в repo.
• Невідомі частини позначені Unknown.

• Почати з read-only огляду та git status.
• Не зберігати credentials у файлах або prompt.
• Зупинитися, якщо відкрито не той repository.

General · feature

Перетворити потребу користувача на малу наскрізну зміну з явним desired behavior і перевірюваним acceptance.

• Один user flow і його точки входу.
• Потрібні UI/API/domain зміни та тести.
• Документований public contract.

• Непроханий redesign.
• Загальний cleanup сусідніх модулів.
• Зміна бізнес-правил поза вимогою.

• Нова поведінка описана спостережувано.
• Existing scenarios не погіршилися.
• Acceptance і verification привʼязані до diff.

• Розділяти Goal, Scope і Constraints.
• Не вважати названий у тикеті файл доведеною точкою зміни.
• Погодити plan до редагування.

General · acceptance-verification

Зробити умови готовності задачі спостережуваними, вимірюваними та придатними для незалежної перевірки.

• Functional і negative scenarios.
• Compatibility та UI/API signals.
• Команди, очікувані результати й fail conditions.

• Навʼязування конкретної бібліотеки.
• Розмитий критерій «зробити краще».
• Автоматичне рішення про merge.

• Кожен criterion має signal і спосіб перевірки.
• Є поведінка, яку потрібно зберегти.
• DoD містить scope, diff, tests і review.

• Виводити критерії з фактів.
• Розділяти acceptance від implementation plan.
• Невиконану перевірку маркувати Unknown.

General · issue-intake

Відділити в сирому issue проблему, вплив, докази, вимоги, припущення, межі та відкриті питання.

• Issue text, comments, labels і attachments.
• Read-only investigation handoff.
• Non-goals, risks і next step.

• Автоматичне прийняття запропонованого fix.
• Редагування коду під час intake.
• Закриття відкритих питань припущеннями.

• Наступний інженер відтворить контекст без усного пояснення.
• Facts і hypotheses розділені.
• Є конкретний наступний крок.

• Не називати файл із тикета доведеною причиною.
• Публічний контракт перевіряти окремо.
• Unknown залишати явним.

General · implementation-plan

Перекласти підтверджені findings у послідовність малих змін із ризиками, verification, stop condition і rollback.

• Affected files і modules.
• Ordered implementation steps.
• Acceptance links і failure path.

• Редагування до approval.
• Розширення scope через cleanup.
• Планування неповʼязаних features.

• План самодостатній для реалізації.
• Кожен крок має перевірку.
• Широкий або небезпечний крок має stop condition.

• Планувати після investigation.
• Один logical intent на slice.
• Не приховувати ризики за словом «refactor».

General · investigation-diagnosis

Відокремити симптом від гіпотези, простежити flow і повернути доказовий висновок або наступну перевірку.

• Один failure або runtime flow.
• Код, tests, config, logs і reproduction steps.
• Confidence, unknowns і next action.

• Редагування коду під час discovery.
• Причина лише за назвою файла.
• Довгий transcript замість стислого висновку.

• Кожен висновок має evidence anchor.
• Hypothesis не видається за fact.
• Небезпечна дія не запускається автоматично.

• Працювати read-only до окремого approval.
• Очищати logs від secrets і PII.
• Неповний evidence означає Unknown.

General · codebase-discovery

Створити компактну evidence-backed карту стеку, модулів, entry points, runtime flows, залежностей і unknowns.

• Top-level structure і manifests.
• Ключові модулі, тести та commands.
• Один dependency або runtime slice.

• Читання всього repository підряд.
• Рефакторинг знайдених проблем.
• Висновки лише з назв каталогів.

• Наступний інженер знає, де шукати логіку.
• Карта містить sources і confidence.
• Open questions не маскуються під facts.

• Проводити окремою read-only сесією.
• Фіксувати факти й припущення окремо.
• Не вносити зміни під час mapping.

General · bugfix

Відтворити дефект, підтвердити причину, внести найменший фікс і залишити evidence для review.

• Один failure path.
• Regression test і суміжний позитивний сценарій.
• Опис diff, перевірок і залишкових ризиків.

• Переписування всієї error architecture.
• Feature work під час bugfix.
• Вигадані результати тестів.

• Дефект відтворюється до фіксу.
• Regression test захищає виправлений сценарій.
• Формат зовнішнього контракту змінюється лише за погодженням.

• Спочатку facts-first diagnosis, потім edit.
• Після кожної правки перевірити diff.
• Unknown причина не є дозволом на широкий patch.

General · refactoring

Змінити внутрішню структуру коду, зберігши observable behavior, public API, side effects та інваріанти.

• Одна structural change.
• Залежні focused tests і diff review.
• Явна точка rollback.

• Нові features або bugfix.
• Dependency/framework upgrade.
• Зміна форматів даних чи контрактів.

• Diff має одну structural мету.
• Characterization і targeted checks не показують непогоджених змін.
• Rollback point зафіксований.

• Не починати з редагування.
• Працювати одним reviewable slice.
• Зупинитися при зміні public behavior.

General · characterization

Створити safety net для вузького flow до рефакторингу, описавши фактичні inputs, outputs, помилки та side effects.

• Один bounded flow.
• Representative і edge-case inputs.
• Запис спостережень і невідомих.

• Виправлення дивної поведінки.
• Підміна current behavior бажаним дизайном.
• Широке тестове переписування.

• Тест або запис відтворює current behavior.
• Несподівані результати явно позначені.
• Є рішення, що саме захищати перед зміною.

• Фіксувати факт, а не припущену причину.
• Не змінювати implementation під час baseline.
• Усе неперевірене маркувати Unknown.

General · tests

Обрати рівень і набір тестів за ризиком, а не генерувати assertions без звʼязку з контрактом.

• Критичні правила й boundary cases.
• Unit, integration, API або E2E level за потребою.
• Fail conditions і representative data.

• Максимальне покриття заради метрики.
• Крихкі E2E для кожної гілки.
• Зміна production code без окремої задачі.

• Кожен важливий ризик має перевірку.
• Assertions описують observable result.
• Test data не містить секретів або PII.

• Спочатку сформулювати acceptance.
• Не довіряти тесту, який не перевіряє потрібну поведінку.
• Результат запуску без виконання позначати Unknown.

General · documentation

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

• Один документ або section.
• Фактичні commands, paths і contracts.
• Diff review і практична перевірка прикладів.

• Переписування всієї документації.
• Додавання неперевірених promises.
• Публікація secrets, PII або внутрішніх токенів.

• Кожне важливе твердження має source.
• Приклад відповідає фактичній поведінці або маркований Unknown.
• Зміни reviewable.

• Читач і мета документа мають бути визначені.
• Перевіряти docs через code/config/tests.
• Не називати illustrative snippet production evidence.

General · pr-slicing

Перетворити затверджений план на малі логічні частини, які можна окремо перевірити, відревʼювати й відкотити.

• Один intent на slice.
• Обмежені файли.
• Acceptance link, targeted check і rollback.

• Big-bang PR.
• Прихований cleanup.
• Змішування feature, refactor і dependency update.

• Кожен slice має зрозумілу мету.
• Порядок не приховує незавершений контракт.
• Reviewer може ізолювати failure.

• Декомпозувати після plan approval.
• Перший slice може бути reproduce/evidence.
• Зупинитися при розширенні diff.

General · handoff-recovery

Передати стан довгої задачі fresh reviewer так, щоб вони могли відтворити evidence і продовжити без здогадок.

• Current diff і checkpoint.
• Зроблено, перевірено, ризики й unknowns.
• Одна наступна дія та stop condition.

• Передача секретів або повного transcript.
• Автоматичне продовження після handoff.
• Приховування невдалих перевірок.

• Інший учасник розуміє стан без усної передачі.
• Rollback/checkpoint названі.
• Неперевірені твердження марковані.

• Записувати факти окремо від next step.
• Зберігати лише потрібний context.
• Не вважати session rewind Git rollback.

General · extensions-evaluation

Перевірити capability surface, permissions, lifecycle і rollback інтеграції у вузькому trial до командного поширення.

• Одна capability і один bounded scenario.
• Origin, permissions і auth boundary.
• Log-only trial, verification і kill switch.

• Встановлення неперевіреного пакета в командний scope.
• Credentials у repository.
• Blocking automation без evidence.

• Цінність trial сформульована.
• Побічні ефекти й data boundary відомі.
• Є спосіб disable/rollback.

• Починати вручну або log-only.
• Надавати мінімальні permissions.
• Зупинитися при prompt injection або неясному ownership.

General · agent-orchestration

Розділити незалежні workstreams між ролями з чітким ownership, output contract, checkpoints і стратегією злиття.

• Decomposition і dependency order.
• Scoped tools/context для ролей.
• Handoff, merge strategy і human checkpoint.

• Паралельність заради кількості агентів.
• Спільне редагування одного файлу без координації.
• Автоматичне прийняття результатів.

• Потоки незалежні або залежності явні.
• Кожен output має evidence і status.
• Людина зберігає merge/go-no-go.

• Спочатку оцінити, чи потрібен subagent.
• Вузько делегувати та обмежувати tools.
• Зупинитися при conflict або відсутності safety net.

General · investigation-diagnosis

Класифікувати червоний job як test, build, environment, contract або flaky і повернути evidence-backed next action.

• Job status і релевантний очищений output.
• Локальна відтворюваність.
• Diagnosis, confidence і безпечна наступна дія.

• Автоматичний fix у production.
• Передача секретів у prompt.
• Називати flaky без повторної перевірки.

• Класифікація має конкретний evidence.
• Logs очищені від secrets.
• Наступна дія не обходить approval.

• Починати з першого надійного сигналу.
• Розділяти CI status від root cause.
• Неповний log означає Unknown.

General · ci-build

Описати відтворюваний build/package workflow та відокремити технічні сигнали від рішення про publish або deploy.

• Build command і clean environment.
• Package/Docker path та smoke signal.
• Changelog/release notes і human gate.

• Production deployment.
• Publish без approval.
• Приховування failed build або неповного smoke-check.

• Вхідні команди й output artifacts визначені.
• Smoke criteria спостережувані.
• Release boundary має owner і rollback path.

• Claude аналізує, але не підміняє build.
• Permissions мінімальні.
• Не стверджувати, що build пройшов без output.

General · quality-release

Зробити blocking або advisory check прозорим: що він перевіряє, яке evidence повертає і коли зупиняє delivery.

• Signal, threshold і status.
• Blocking/advisory policy.
• Owner, exception і recovery path.

• Gate лише заради метрики.
• Автоматичний merge без human policy.
• Змішування unrelated checks.

• Failure зрозумілий іншому інженеру.
• Evidence зберігається.
• Rerun, rollback або disable path відомі.

• Починати з advisory, якщо signal новий.
• Не приховувати flaky або environment failure.
• Людина приймає фінальне рішення.

General · risk-policy

Зіставити risk classification, permissions, data boundaries, protected paths і human approval до дії.

• Класифікація задачі.
• Allowed tools, paths і data.
• Owner, approval, audit trail і stop condition.

• Обхід permission prompt.
• Передача secrets/PII у контекст.
• Автономний production deploy.

• Capability envelope відповідає ризику.
• Protected paths мають enforcement.
• GO/HOLD рішення має evidence та відповідального.

• Least privilege за замовчуванням.
• Sensitive data очищати до передачі.
• Незворотні дії залишати за людиною.

General · capstone

Обмежити фінальний проєкт одним core flow і побудувати відтворювану послідовність SPEC, baseline, milestones, demo та evidence.

• Problem, audience і core flow.
• SPEC, repository baseline і roadmap.
• Малі milestones та evaluation evidence.

• Демонстрація всього продукту.
• Вигадані metrics або screenshots.
• Розширення scope під час demo.

• Критерії оцінювання визначені до коду.
• Кожен milestone має evidence.
• Demo відтворюється іншим учасником.

• Починати з малого verified slice.
• Фіксувати Unknown і limitations.
• Не називати план production readiness.

General · codebase-discovery

Описати current-state architecture, technical-debt signals, critical flows і change risk до будь-якого редагування.

• Фактична поведінка legacy flow.
• Модулі, залежності та static signals.
• Business criticality, change risk і unknowns.

• Негайний refactor.
• Вигаданий target architecture.
• Висновок із одного smell без evidence.

• Current state відділений від desired state.
• Risk map має evidence і confidence.
• Наступний крок bounded.

• Read-only discovery first.
• Не плутати business criticality із change risk.
• Unknown блокери виносити явно.

Modernization · modernization

Поступово зменшити технічний ризик одного legacy-модуля, не змінюючи зовнішній контракт і бізнес-сенс.

• Один bounded module або business flow.
• Одна structural change через підтверджену seam.
• Characterization, focused checks і rollback.

• Big-bang rewrite.
• Public API, business-rule або data-format changes.
• Framework/dependency upgrade чи нові features.

• Один reviewable slice має обмежений diff.
• Inputs, outputs, errors, side effects та invariants сумісні.
• Перевірки виконані або марковані Unknown.

• Почати з MODERNIZATION_BASELINE.md і RISK_MAP.md.
• Кожен крок має non-goals і stop condition.
• Зупинитися при непідтвердженій зміні контракту.

Migration · migration

Підготувати bounded pilot переходу на Boot 3.x і Java 21, спочатку зібравши evidence для сумісності та зберігши поточну поведінку.

• Build-конфігурація і version constraints.
• Security-конфігурація target slice.
• Один read-only endpoint.
• Official docs і repository files.

• Рефакторинг BillingService.
• Нова схема БД.
• Нові features, full rollout або production deployment.
• Version bump до discovery та approval.

• Known, Assumption і Unknown розділені.
• Compatibility checks, behavior contract і rollback визначені.
• Pilot має пройти поточні перевірки та поводитися як раніше; результат до виконання — Unknown.

• Source of truth: official docs + repo files.
• Кожен висновок має docs section або file path.
• Не пропонувати edit, build або version bump без запиту.
• Почати з discovery, changelog, dependency graph і compatibility matrix.