Artifact-first навігація
Каталог артефактів 59 описів · 8 категорій
Це curated registry артефактів, згаданих у гайді та присутніх у цьому repository. Статус «документований приклад» означає, що матеріали описують форму артефакта, але файла в цьому repository немає.
Швидкий перехід
Оберіть, що ви хочете зробити, щоб перейти до відповідних артефактів.
Орієнтуватися в проєкті 7 Перші документи для розуміння проєкту, контексту та codebase.
Визначити й спланувати 6 Артефакти, які перетворюють ідею на межі, контракт і послідовність роботи.
Налаштувати й розширити workflow 10 Configuration, policy, skills та integrations для контрольованого workflow.
Виконати й контролювати 8 Операційні артефакти для запуску, ізоляції та контролю виконання.
Перевірити, передати й доставити 10 Evidence, review, handoff і delivery records для завершення роботи.
Дослідити legacy й ризики 6 Артефакти для опису поточної поведінки, technical debt і ризиків змін.
Модернізувати legacy без big-bang rewrite 7 Артефакти для baseline, seams, incremental slices, strangler rollout і roadmap.
Планувати міграцію й сумісність 5 Source-to-target analysis, changelog evidence, compatibility decisions і пофазна delivery-послідовність.
Приклад організації в проекті some-project/
├── CLAUDE.md # project instructions
├── README.md # project entry point
├── TASK_SPEC.md # task contract
├── SPEC.md # project specification
├── CAPSTONE_BRIEF.md # capstone brief
├── EVIDENCE.md # verification record
├── EVIDENCE_LOG.md # legacy evidence alias
├── HANDOFF_NOTE.md # handoff context
├── CHANGELOG.md # release notes
├── .claude/
│ ├── CLAUDE.local.md # local context
│ ├── settings.json # shared project settings
│ ├── settings.local.json # local settings
│ ├── rules/ # scoped rules
│ ├── skills/
│ │ └── SKILL.md # repeatable workflow
│ ├── agents/
│ │ └── reviewer.md # custom subagent
│ ├── hooks/ # hook configuration
│ └── mcp/ # MCP server/config
├── docs/
│ ├── SPEC.md # SPEC path variant
│ ├── EVIDENCE.md # EVIDENCE path variant
│ ├── CODEBASE_INVENTORY.md # codebase map
│ └── API_MAP.md # integration map
├── backlog/
│ └── roadmap # backlog / roadmap
├── src/
├── scripts/
│ └── internal checks # Repository validation scripts
├── plugins/
│ └── plugin-package # Plugin distribution
├── .git/
│ └── commit message # Commit metadata
├── worktree/ # Optional Git worktree
├── working diff # Current Git diff
└── external/
└── PR description # Pre-merge delivery artifact Це умовна схема: конкретний набір файлів і каталогів залежить від проєкту. Елементи показано як можливі місця або форми організації, а не як обов’язкову структуру.
Категорія
Контекст і правила 7 артефактів
Спільний контекст для більшості сесій і точка входу в conventions репозиторію.
Де знаходиться {project}/CLAUDE.md (repository; є в цьому repository) .claude/CLAUDE.md (repository; документований приклад) Усі поля commandsconventional — Команди запуску, тестів і перевірок. Приклад: npm run check
conventionsconventional — Стиль, архітектурні та naming-правила.
forbidden actionsconventional — Дії, яких агент не має виконувати без окремого рішення.
report formatconventional — Очікуваний формат результату та доказів.
Шаблон CLAUDE.md Скопіювати шаблон # CLAUDE.md
## Commands
- check: `npm run check`
- test: `npm test`
## Rules
- Keep changes inside the task scope.
- Report changed files and verification results.
## Do not
- Read or edit secrets without explicit approval.
Коли використовувати Коли правило стабільне, командне й потрібне в більшості задач.
Коли це поганий вибір Для одноразової гіпотези, task-specific деталей, секретів або повної енциклопедії проєкту.
Персональний шар контексту поверх спільних правил.
Де знаходиться .claude/CLAUDE.local.md (repository; документований приклад) Усі поля local preferencesconventional — Особисті налаштування workflow.
machine contextconventional — Локальні шляхи або особливості середовища.
Шаблон CLAUDE.local.md Скопіювати шаблон # CLAUDE.local.md
## Local context
- Database: localhost:<port>
- Fixture directory: <local-path>
## Preferences
- Explain the plan before multi-file changes.
Коли використовувати Коли контекст потрібен лише одному розробнику або машині.
Коли це поганий вибір Для спільних правил, permissions, секретів чи вимог, які має бачити команда.
Зменшує шум глобального контексту та наближає правило до affected area.
Де знаходиться {project}/.claude/rules/ (repository; документований приклад) Усі поля scoperequired — Шляхи або умови, на які поширюється правило.
rule contentrequired — Інструкції для визначеної області.
Шаблон .claude/rules/ Скопіювати шаблон # Rule: <area-name>
Applies to: `src/<area>/**`
- Preserve the public contract.
- Run the focused checks after changes.
- Do not edit unrelated files.
Коли використовувати Коли правило стосується лише окремого модуля, шару або glob-патерна.
Коли це поганий вибір Для одного короткого завдання або правила, яке має діяти всюди.
Версійований configuration layer для командних або account-wide defaults, окремий від локальних override.
Де знаходиться {project}/.claude/settings.json (repository; документований приклад) ~/.claude/settings.json (user; документований приклад) Усі поля permissionsconventional — Явно дозволені та заборонені tool patterns.
envoptional — Безпечні non-secret environment defaults для scope.
scoperequired — Рівень застосування: user або project.
version/secret policyconventional — Правила сумісності та заборона зберігати credentials у файлі.
Шаблон settings.json Скопіювати шаблон {
"permissions": {
"allow": ["Bash(npm run check)"],
"deny": ["Read(.env)"]
},
"env": {
"PROJECT_MODE": "<mode>"
}
}
Коли використовувати Для спільних project defaults або user-wide configuration, яку треба відтворювати на визначеному рівні.
Коли це поганий вибір Для machine-specific overrides, секретів або transient session state.
Примітка Доступні ключі та пріоритети треба звіряти з актуальною Claude Code документацією.
Машинний configuration layer, зазвичай поза Git.
Де знаходиться .claude/settings.local.json (repository; документований приклад) Усі поля settingsconventional — Локальні параметри Claude Code або workflow.
ignore policyconventional — Правило виключення локального файла з commit.
Шаблон settings.local.json Скопіювати шаблон {
"permissions": {
"allow": ["Bash(npm run check)"],
"deny": ["Read(.env)"]
}
}
Коли використовувати Для персональних налаштувань, які не повинні змінювати командний workflow.
Коли це поганий вибір Як secret store, заміна permissions або місце для командних правил.
Policy layer, який доповнює permissions, hooks і quality gates.
Де знаходиться {project}/AI_CODING_POLICY.md (repository; документований приклад) Усі поля allowed/review/approvalrequired — Класи дій за рівнем контролю.
data boundariesrequired — Правила для secrets і чутливих даних.
enforcement/ownerrequired — Технічне забезпечення та відповідальний.
Шаблон AI_CODING_POLICY.md Скопіювати шаблон # AI coding policy
## Allowed
- <low-risk use>
## Review required
- <change or capability>
## Human approval required
- <production or destructive action>
## Data boundaries
- Never include secrets, PII, or customer data without approved controls.
## Enforcement
- <settings, hooks, gates, and owner>
Коли використовувати Коли команді потрібне єдине трактування AI-дій і людських approvals.
Коли це поганий вибір Як заміна конкретним permissions, security standard, task spec або incident procedure.
Repository ownership rule для автоматизації review routing.
Де знаходиться .github/CODEOWNERS (repository; документований приклад) CODEOWNERS (repository; варіант назви або шляху) Усі поля patternsrequired — Шляхи або glob-патерни ownership.
ownersrequired — Команди або ролі, що мають review.
sensitive areasoptional — Окремі правила для критичних шляхів.
Шаблон CODEOWNERS Скопіювати шаблон # CODEOWNERS
# Default owner
* @<team-or-role>
# Sensitive area
/src/<area>/** @<approved-owner>
# Configuration
/.claude/** @<workflow-owner>
Коли використовувати Коли ownership і required review треба застосувати послідовно через repository tooling.
Коли це поганий вибір Для одноразового погодження або як заміна human decision gate.
Категорія
Постановка задачі 9 артефактів
Визначає межі роботи до реалізації та зменшує scope drift.
Де знаходиться {project}/TASK_SPEC.md (repository; документований приклад) archive/task-specs/TASK_SPEC.md (repository; є в цьому repository) Усі поля goal/problemrequired — Яку проблему вирішуємо і навіщо.
current/desired behaviorrequired — Поточний і очікуваний стан.
scope/non-goalsrequired — Що входить і що свідомо не входить у роботу.
constraintsrequired — Технічні, часові або policy-обмеження.
acceptance criteriarequired — Умови, за якими результат приймається.
verification planrequired — Як перевірити результат.
risks/open questionsoptional — Невизначеності, ризики та рішення, які ще потрібні.
Шаблон TASK_SPEC.md Скопіювати шаблон # Task spec — <short task name>
## Goal
- <problem and desired outcome>
## Scope
- <files or behavior included>
## Non-goals
- <explicitly excluded work>
## Acceptance criteria
- <verifiable condition>
## Verification
- <command or manual check>
Коли використовувати Перед реалізацією feature, bugfix або refactor і щоразу, коли змінюється scope.
Коли це поганий вибір Для стабільних repository rules, фактичного evidence log або довгого raw transcript.
Довгоживуча специфікація проєкту або capstone.
Де знаходиться SPEC.md (repository; документований приклад) docs/SPEC.md (repository; варіант назви або шляху) Усі поля project/problemrequired — Контекст проєкту й проблема.
audiencerequired — Для кого створюється результат.
scope/non-goalsrequired — Межі та виключення.
constraintsrequired — Обмеження реалізації.
acceptance criteriarequired — Перевірювані умови готовності.
verificationrequired — План перевірки.
Шаблон SPEC.md Скопіювати шаблон # Project specification
## Problem
<problem statement>
## Audience
<primary users>
## Scope
- <included capability>
## Non-goals
- <excluded capability>
## Acceptance criteria
- <measurable result>
Коли використовувати Для project contract, який живе довше за одну задачу.
Коли це поганий вибір Для короткої одноразової нотатки, поточного evidence або детального implementation plan.
Аліаси та варіанти docs/SPEC.md
Надзадачний brief, який відрізняється від конкретного SPEC.md.
Де знаходиться {project}/CAPSTONE_BRIEF.md (repository; документований приклад) Усі поля shared expectationsrequired — Спільні правила capstone.
guardrailsrequired — Межі та критерії безпечної роботи.
Шаблон CAPSTONE_BRIEF.md Скопіювати шаблон # Capstone brief
## Shared expectations
- Deliver one complete core flow.
- Keep the scope reviewable.
## Guardrails
- No secrets in the repository.
- Record checks and remaining risks.
Коли використовувати На старті capstone або іншої спільної навчальної ініціативи.
Коли це поганий вибір Для task-specific requirements або журналу фактичних перевірок.
Послідовність delivery та evaluation steps.
Де знаходиться project backlog or roadmap (repository; документований приклад) Усі поля milestonesrequired — Ключові етапи роботи.
core flowrequired — Пріоритетний наскрізний сценарій.
evaluationoptional — Як оцінюється готовність етапу.
Шаблон Backlog / roadmap Скопіювати шаблон # Roadmap
## Milestones
1. Discovery — map the current behavior.
2. Implementation — deliver the core flow.
3. Verification — run checks and prepare evidence.
## Evaluation
- <criterion for milestone completion>
Коли використовувати Для довгих задач із кількома етапами та залежностями.
Коли це поганий вибір Для маленької одноразової зміни або заміни acceptance criteria.
Shared interface contract із входами, виходами та інваріантами.
Де знаходиться {project}/CONTRACT.md (repository; документований приклад) Усі поля partiesrequired — Хто або що взаємодіє.
input/outputrequired — Формат і зміст передачі.
invariants/failuresrequired — Незмінні умови та stop conditions.
Шаблон CONTRACT.md Скопіювати шаблон # CONTRACT.md
## Parties
- Producer: <role/component>
- Consumer: <role/component>
## Input
- <required input>
## Output
- <expected output>
## Invariants
- <must remain true>
## Failure/stop conditions
- <condition>
Коли використовувати Коли кілька ролей або етапів мають працювати незалежно через стабільну межу.
Коли це поганий вибір Для простої одноетапної правки або як заміна domain/API specification.
Короткий execution plan перед редагуванням.
Де знаходиться {project}/PLAN.md (repository; документований приклад) Усі поля goal/scoperequired — Результат і дозволена зона роботи.
stepsrequired — Послідовність малих дій.
risks/stop conditionrequired — Ризики та умова зупинки.
Шаблон PLAN.md Скопіювати шаблон # PLAN.md
## Goal
<desired outcome>
## Scope
- <included paths or behavior>
## Steps
1. <inspect>
2. <change>
3. <verify>
## Risks
- <risk or none>
## Stop condition
- <when to pause and ask>
Коли використовувати Перед multi-file, ризиковою або делегованою зміною.
Коли це поганий вибір Для стабільних правил, фактичного звіту або плану без acceptance criteria.
Execution contract для structural зміни без змішування feature work або bugfix.
Де знаходиться {project}/REFACTORING_PLAN.md (repository; документований приклад) Усі поля goal/scoperequired — Одна structural мета та дозволена область.
preserve/non-goalsrequired — Інваріанти й явно виключена робота.
steps/checksrequired — Малі кроки та focused verification.
stop/rollbackrequired — Умова зупинки й точка повернення.
Шаблон REFACTORING_PLAN.md Скопіювати шаблон # REFACTORING_PLAN.md
## Goal
<one structural improvement>
## Allowed scope
- <paths, symbols, or seam>
## Preserve
- <public behavior and invariants>
## Non-goals
- <feature, dependency, or unrelated cleanup>
## Steps
1. <inspect>
2. <change>
3. <check and review>
## Stop and rollback
- <condition and checkpoint>
Коли використовувати Перед одним інкрементальним refactoring кроком у legacy-модулі.
Коли це поганий вибір Для повної modernization roadmap, feature specification або необмеженого cleanup.
Risk-aware delivery roadmap, яка дозволяє proceed, narrow, hold або rollback.
Де знаходиться {project}/MODERNIZATION_ROADMAP.md (repository; документований приклад) Усі поля outcome/constraintsrequired — Мета modernization та обмеження scope.
milestones/ownersrequired — Послідовні slices і відповідальні ролі.
dependencies/evidence gatesrequired — Передумови та перевірки переходу.
exit/rollback/risksrequired — Exit criteria, hold/rollback і відкриті ризики.
Шаблон MODERNIZATION_ROADMAP.md Скопіювати шаблон # MODERNIZATION_ROADMAP.md
## Outcome and constraints
<why modernization matters and what is out of scope>
## Milestones
| Slice | Owner | Dependency | Evidence gate | Exit criteria | Rollback/hold |
| --- | --- | --- | --- | --- | --- |
| <slice> | <role> | <dependency> | <check> | <observable result> | <action> |
## Retirement plan
- <legacy removal condition>
## Open risks
- <risk and next decision>
Коли використовувати Для modernization, що складається з кількох залежних slices та risk decisions.
Коли це поганий вибір Для списку всіх бажаних refactors, календаря без gates або заміни поточного baseline.
Execution contract для переходу від source до target без неявного production або completion claim.
Де знаходиться {project}/MIGRATION_PLAN.md (repository; документований приклад) Усі поля outcome/scope/non-goalsrequired — Source, target, bounded slice та виключена робота.
phases/ownersrequired — Discovery, analysis, pilot та наступні фази з ownership.
evidence gates/exit criteriarequired — Перевірки переходу і спостережувані умови завершення.
rollback/hold decisionrequired — Практична дія повернення, HOLD або звуження scope.
open risksrequired — Невирішені compatibility, behavior або operational risks.
Шаблон MIGRATION_PLAN.md Скопіювати шаблон # MIGRATION_PLAN.md
## Outcome and boundaries
- Source: <current state>
- Target: <target state>
- Scope: <bounded slice>
- Non-goals: <excluded changes>
## Phases
| Phase | Scope | Owner | Evidence gate | Exit criteria | Rollback/HOLD |
| --- | --- | --- | --- | --- | --- |
| Discovery | <facts and unknowns> | <role> | <anchor> | <result> | <hold action> |
| Analysis | <compatibility work> | <role> | <anchor> | <result> | <narrow action> |
| Pilot | <small slice> | <role> | <behavior check> | <result> | <rollback> |
## GO / HOLD decision
- Decision: <GO | HOLD | NARROW | ROLLBACK>
- Evidence: <facts>
- Open risks: <items>
Коли використовувати Після discovery та compatibility analysis, коли потрібна керована послідовність pilot, verification, expand або retirement.
Коли це поганий вибір Для modernization roadmap без source/target transition, календаря без evidence gates або твердження про виконаний rollout.
Категорія
Докази й доставка 10 артефактів
Стислий audit trail, який дозволяє відрізнити виконану перевірку від припущення.
Де знаходиться EVIDENCE.md (repository; є в цьому repository) docs/EVIDENCE.md (repository; варіант назви або шляху) Усі поля assignment/resultrequired — Що перевірялося та який результат отримано.
decisionsrequired — Прийняті рішення та їх обґрунтування.
verificationrequired — Команди, тести й фактичні результати.
risks/open questionsoptional — Неперевірені частини та наступні питання.
Шаблон EVIDENCE.md Скопіювати шаблон # Evidence
## Result
<what was checked and what happened>
## Decisions
- <decision and rationale>
## Verification
- `<command>` — <result>
## Open risks
- <unresolved item or none>
Коли використовувати Після аналізу, review або implementation, коли потрібен короткий фактичний trace.
Коли це поганий вибір Для вимог, raw logs без висновків або повного діалогу сесії.
Аліаси та варіанти EVIDENCE_LOG.md · docs/EVIDENCE.md
Примітка У навчальних матеріалах назва EVIDENCE_LOG.md використовується як legacy/concept variant; canonical filename треба узгодити.
Milestone transfer artifact.
Де знаходиться {project}/HANDOFF_NOTE.md (repository; документований приклад) Усі поля goal/scoperequired — Мета та межі переданої роботи.
changed filesrequired — Що було змінено.
decisions/assumptionsrequired — Рішення та припущення.
evidence/checksrequired — Команди й результати перевірок.
risks/next steprequired — Ризики та одна найближча дія.
Шаблон HANDOFF_NOTE.md Скопіювати шаблон # Handoff note
## Goal and scope
<what this work covers>
## Changed files
- `<path>` — <change>
## Decisions
- <decision>
## Checks
- `<command>` — <result>
## Next step
<one concrete next action>
Коли використовувати На межі milestone, передачею роботи або залученням свіжого reviewer.
Коли це поганий вибір Як PR description, commit message або changelog.
Delivery packet із контекстом, diff summary та checks.
Де знаходиться pull request description (external; операційний або зовнішній артефакт) Усі поля summaryrequired — Що змінилося.
scoperequired — Межі зміни та non-goals.
tests/checksrequired — Перевірки та їх результати.
risks/review notesoptional — Ризики та питання reviewer.
Шаблон PR description Скопіювати шаблон ## Summary
<what changed>
## Scope
- Included: <area>
- Not included: <non-goal>
## Checks
- `<command>` — <result>
## Risks
- <risk or none>
Коли використовувати Перед merge, коли зміни мають пройти review.
Коли це поганий вибір Як довготривалий project spec або заміна handoff між milestone.
Короткий trace у version control history.
Де знаходиться Git commit metadata (generated; операційний або зовнішній артефакт) Усі поля intentrequired — Логічна мета коміту.
scoperequired — Межі цього кроку.
Шаблон Commit message Скопіювати шаблон <type>(<scope>): <short imperative summary>
Explain why the change is needed and mention verification when useful.
Коли використовувати Для атомарного логічного кроку, який треба відтворити або відкотити.
Коли це поганий вибір Як місце для повного test report, вимог або довгого design decision.
Комунікаційний release artifact.
Де знаходиться CHANGELOG.md or release notes (repository; операційний або зовнішній артефакт) Усі поля release/versionrequired — До якого релізу належить запис.
user-visible changesrequired — Зміни, важливі для користувача.
migration notesoptional — Несумісності та інструкції переходу.
Шаблон Changelog Скопіювати шаблон # Changelog
## [Unreleased]
### Added
- <user-visible capability>
### Fixed
- <user-visible bug fix>
### Migration notes
- <required action or none>
Коли використовувати Під час release або публікації user-visible змін.
Коли це поганий вибір Як технічний task contract, raw evidence або список кожного внутрішнього коміту.
Review checkpoint поверх базового HANDOFF_NOTE.md.
Де знаходиться {project}/HANDOFF_REVIEW.md (repository; документований приклад) Усі поля source/scoperequired — Який handoff і межі перевірено.
confirmed/findingsrequired — Підтвердження та зауваження з evidence.
next decisionrequired — Наступна дія і відповідальна роль.
Шаблон HANDOFF_REVIEW.md Скопіювати шаблон # HANDOFF_REVIEW.md
## Reviewed handoff
- Source: <handoff path>
- Scope: <reviewed scope>
## Confirmed
- <evidence-backed item>
## Findings
- <finding or none>
## Next decision
- <action and owner>
Коли використовувати Перед передачею milestone або залученням fresh reviewer.
Коли це поганий вибір Для повторення повного handoff, PR summary або неперевіреного статусу.
Blameless improvement record для повторюваних проблем.
Де знаходиться docs/postmortems/<incident>.md (repository; документований приклад) Усі поля impact/timelinerequired — Фактичний вплив і послідовність подій.
cause/controlsrequired — Підтверджені причини та оцінка controls.
actions/verificationrequired — Дії з owner і спосіб перевірки.
Шаблон Postmortem Скопіювати шаблон # Postmortem: <incident or failure>
## Impact
<observable impact and duration>
## Timeline
- <time> — <event>
## Root cause and contributing factors
- <verified cause>
## What worked / failed
- <control> — <result>
## Actions
- [ ] <owner> — <preventive or corrective action>
## Verification
- <how the fix will be checked>
Коли використовувати Після значного збою або повторюваної проблеми, щоб змінити процес, а не лише код.
Коли це поганий вибір Для пошуку гіпотези до збору evidence або для персонального звинувачення.
Curated review output між diff і фінальним рішенням.
Де знаходиться {project}/REVIEW_NOTES.md (repository; документований приклад) Усі поля scope/findingsrequired — Межі review та evidence-backed findings.
checksrequired — Фактично виконані перевірки.
questions/verdictrequired — Відкриті питання та обережний висновок.
Шаблон REVIEW_NOTES.md Скопіювати шаблон # REVIEW_NOTES.md
## Scope reviewed
- <paths or behavior>
## Findings
- <severity> — <file:line> — <finding>
## Checks
- `<command>` — <result>
## Open questions
- <question or none>
## Verdict
<APPROVE | REWORK | HOLD>
Коли використовувати Для окремого self-review, fresh-context review або quality gate.
Коли це поганий вибір Для PR summary без findings, raw transcript або автоматичного approval.
Внутрішній delivery history та repeatable handoff reference, а не production audit log.
Де знаходиться RUNBOOK.md (repository; є в цьому repository) Усі поля task/daterequired — Назва задачі та дата або порядок виконання.
statusrequired — Чесний стан: implemented, reviewed, partially verified або not performed.
scope/filesrequired — Межі задачі та змінені або перевірені шляхи.
resultrequired — Підтверджений результат без вигаданих claims.
verification/limitationsrequired — Фактичні перевірки та залишкові обмеження.
Шаблон RUNBOOK.md Скопіювати шаблон # Project delivery runbook
**Дата актуалізації:** <YYYY-MM-DD>
## Task log
### <task name> — `<implemented|reviewed|partially verified|not performed>`
- Goal and scope: <what was requested>
- Changed or reviewed files: `<paths>`
- Result: <confirmed outcome>
- Verification: `<command or manual check>` — <actual result>
- Limitations: <known gap or none>
## Open limitations
- <unverified item or none>
Коли використовувати Після серії повʼязаних milestone або перед handoff, коли потрібно відновити фактичну послідовність delivery.
Коли це поганий вибір Для raw transcript, майбутнього task plan, user-visible changelog, конкретного review evidence, secret storage або вигаданого production record.
Review checklist для виявлення big-bang, scope mixing, відсутності baseline та rollback.
Де знаходиться {project}/MODERNIZATION_ANTI_PATTERNS.md (repository; документований приклад) Усі поля anti-pattern/signalrequired — Назва небезпечного патерну та його спостережуваний сигнал.
impactrequired — Можливий вплив без перебільшення certainty.
safer alternativerequired — Обмежена практика, яка зменшує ризик.
stop condition/evidencerequired — Умова паузи та evidence anchor.
Шаблон MODERNIZATION_ANTI_PATTERNS.md Скопіювати шаблон # MODERNIZATION_ANTI_PATTERNS.md
## Anti-pattern: <name>
- Signal: <observable warning>
- Impact: <possible consequence>
- Safer alternative: <bounded practice>
- Stop condition: <when to pause>
- Evidence: <anchor>
Коли використовувати Під час review modernization plan або перед risk gate для наступного slice.
Коли це поганий вибір Для blame list, автоматичного verdict або заміни фактичного baseline і risk map.
Категорія
Розуміння codebase 16 артефактів
Discovery та handoff artifact для швидкого орієнтування.
Де знаходиться {project}/CODEBASE_INVENTORY.md (repository; документований приклад) Усі поля stackrequired — Мови, framework та інструменти.
system partsrequired — Основні модулі й межі.
entry pointsrequired — Де починається виконання.
run/check commandsrequired — Як запустити та перевірити систему.
runtime flowsoptional — Ключові потоки даних або control flow.
risk areas/open questionsoptional — Зони ризику й непідтверджені питання.
Шаблон CODEBASE_INVENTORY.md Скопіювати шаблон # Codebase inventory
## Stack
- Language: <language>
- Framework: <framework>
## Entry points
- <path> — <purpose>
## Commands
- Run: `<command>`
- Check: `<command>`
## Risk areas
- <area and reason>
Коли використовувати Після discovery, перед handoff або коли codebase складний для нового учасника.
Коли це поганий вибір Як копію коду, chat transcript або джерело неперевірених припущень.
Карта трасування інтеграцій.
Де знаходиться {project}/API_MAP.md (repository; документований приклад) Усі поля route/handlerrequired — Вхідна точка та обробник.
integration/data boundaryrequired — DB, queue або зовнішній client.
tests/envoptional — Перевірки та configuration dependencies.
Шаблон API_MAP.md Скопіювати шаблон # API map
| Route | Handler | Boundary | Checks |
| --- | --- | --- | --- |
| `GET /<resource>` | `<handler>` | `<DB or service>` | `<test>` |
## Environment
- `<ENV_NAME>` — <purpose>
Коли використовувати Коли треба простежити endpoint або integration boundary.
Коли це поганий вибір У проєкті без API чи зовнішніх інтеграцій або для загальної карти всього репозиторію.
Curated knowledge record, відділений від сирих transcript-ів.
Де знаходиться .claude/knowledge/CLAWD-Wisdom.md (repository; документований приклад) Усі поля contextrequired — Сценарій, у якому висновок справедливий.
evidencerequired — Доказ, на якому ґрунтується висновок.
limitationrequired — Межі застосування та version-sensitive застереження.
Шаблон CLAWD Wisdom Скопіювати шаблон # CLAWD Wisdom
## <lesson>
- Context: <where this applies>
- Evidence: <file, command, or source>
- Insight: <verified reusable conclusion>
- Limitation: <where it does not apply>
- Reviewed: <date or version>
Коли використовувати Для стислих перевірених lessons learned, які корисні в наступних задачах.
Коли це поганий вибір Для неперевірених припущень, особистого щоденника або повного логу сесії.
Curated read-only research output.
Де знаходиться sources/research-digest.md (repository; документований приклад) Усі поля questionrequired — Питання або гіпотеза дослідження.
sources/findingsrequired — Джерела та підтверджені висновки.
unknowns/recommendationrequired — Невідоме та безпечний наступний крок.
Шаблон research-digest.md Скопіювати шаблон # Research digest
## Question
<question>
## Sources
- <source> — <what it supports>
## Findings
- <confirmed finding>
## Unknowns
- <unverified item>
## Recommendation
<next safe step>
Коли використовувати Після широкого discovery, external research або read-only subagent роботи.
Коли це поганий вибір Для сирих нотаток, implementation plan або висновку без посилань на джерела.
Discovery log для пріоритизації подальшої перевірки, а не автоматичний список дефектів.
Де знаходиться {project}/DEBT_SIGNALS.md (repository; документований приклад) Усі поля scope/daterequired — Область і revision context discovery.
area/evidencerequired — Одна зона та конкретний evidence anchor.
riskrequired — Можливий наслідок без перебільшення certainty.
next step/limitationrequired — Одна перевірка та межа висновку.
Шаблон DEBT_SIGNALS.md Скопіювати шаблон # DEBT_SIGNALS.md
## Scope and date
- Area: <module or flow>
- Reviewed: <date or revision>
## Signals
| Area | Evidence | Risk | Next step |
| --- | --- | --- | --- |
| <area> | <path, command, report, or commit> | <possible impact> | <one concrete check> |
## Limitations
- A signal is an indicator, not proof of a defect.
Коли використовувати Коли потрібно звести максимум пʼять найсильніших static signals перед risk review.
Коли це поганий вибір Для повного списку TODO, автоматичного defect report або заміни runtime і domain verification.
Decision map для визначення: змінювати, звузити scope, збирати evidence або hold.
Де знаходиться {project}/RISK_MAP.md (repository; документований приклад) Усі поля area/criticalityrequired — Зона та business impact.
change risk/categoriesrequired — Ризик зміни та категорії впливу.
evidence/missing checksrequired — Докази й те, що ще не перевірено.
recommended actionrequired — Конкретне рішення, owner або stop condition.
Шаблон RISK_MAP.md Скопіювати шаблон # RISK_MAP.md
## Risk entries
| Area | Business criticality | Change risk | Categories | Evidence | Missing checks | Recommended action |
| --- | --- | --- | --- | --- | --- | --- |
| <area> | <low|medium|high> | <low|medium|high> | <categories> | <anchors> | <checks> | <decision> |
## Unknowns
- <unknown and owner or verification step>
Коли використовувати Після legacy discovery, коли потрібно перетворити факти та unknowns на operational decisions.
Коли це поганий вибір Для єдиного quality score, generic backlog або висновку без evidence і missing checks.
Стабільна карта today, яка відділяє facts, assumptions, manual verification і historical discrepancies.
Де знаходиться {project}/ARCHITECTURE_CURRENT.md (repository; документований приклад) Усі поля purpose/revisionrequired — Межі документа та актуальний revision context.
subsystems/flowsrequired — Підсистеми, boundaries та critical runtime flows.
facts/assumptionsrequired — Розділені confirmed facts та inferred assumptions.
manual checks/discrepanciesrequired — Неперевірене та конфлікти з historical docs.
Шаблон ARCHITECTURE_CURRENT.md Скопіювати шаблон # ARCHITECTURE_CURRENT.md
## Що це за документ
<actual current behavior, not desired architecture>
## Підсистеми
## Критичні потоки
## Підтверджені факти
## Припущення
## Що потрібно перевірити вручну
## Розбіжності з історичною документацією
Коли використовувати Коли legacy-система потребує опису того, як вона працює сьогодні, до зміни або refactor.
Коли це поганий вибір Для desired architecture, product roadmap, списку файлів або бездоказового переписування історичних docs.
Behavior-first baseline перед змінами в legacy або критичному домені.
Де знаходиться {project}/BEHAVIOR_INVENTORY.md (repository; документований приклад) Усі поля flow/current behaviorrequired — Бізнес-потік і фактична поведінка.
inputs/outputsrequired — Відтворювані входи та observable outputs.
tests/missing checksrequired — Існуюче покриття та конкретні прогалини.
characterization candidaterequired — Явне yes/no з обґрунтуванням.
evidencerequired — Якорі source, tests, config, logs або reports.
Шаблон BEHAVIOR_INVENTORY.md Скопіювати шаблон # BEHAVIOR_INVENTORY.md
## Flow: <business flow>
- Поточна поведінка: <confirmed facts and confidence>
- Входи: <reproducible inputs>
- Виходи: <observable outputs>
- Існуючі тести: <paths and level>
- Бракує перевірок: <gaps>
- Кандидат на characterization: <yes|no> — <reason>
- Докази: <anchors>
Коли використовувати Перед змінами, коли потрібно зберегти observable business behavior і вибрати сильні characterization candidates.
Коли це поганий вибір Для переліку класів, бажаної архітектури, коду тестів або списку кожної малозначущої умови.
Карта трасування від trigger та input до side effects, output і failure path.
Де знаходиться {project}/CRITICAL_FLOWS.md (repository; документований приклад) Усі поля trigger/inputsrequired — Умова запуску та вхідний стан.
steps/boundariesrequired — Послідовність компонентів і integration boundaries.
side effects/outputrequired — Зміни стану та observable result.
failure path/evidencerequired — Обробка помилки та доказові якорі.
Шаблон CRITICAL_FLOWS.md Скопіювати шаблон # CRITICAL_FLOWS.md
## Flow: <name>
- Trigger: <event or entry point>
- Inputs: <state and data>
- Steps: <ordered components>
- Side effects: <writes, integrations, notifications>
- Output: <observable result>
- Failure path: <error, retry, rollback, or escalation>
- Evidence: <anchors>
Коли використовувати Для потоків, де зміна одного модуля може вплинути на гроші, дані, інтеграції або користувацький результат.
Коли це поганий вибір Для повної dependency graph, кожного trivial helper або опису без failure path.
Деталізований discovery index між загальним codebase inventory та runtime flow map.
Де знаходиться {project}/MODULE_INVENTORY.md (repository; документований приклад) Усі поля module/pathrequired — Назва модуля та фактичний шлях.
responsibility/entry pointsrequired — Спостережувана роль і точки входу.
dependencies/testsrequired — Залежності та наявні перевірки.
owner/risksrequired — Підтверджений або inferred owner і ризики.
evidencerequired — Anchors для кожного суттєвого твердження.
Шаблон MODULE_INVENTORY.md Скопіювати шаблон # MODULE_INVENTORY.md
## Module: <name>
- Path: <path>
- Responsibility: <observed responsibility>
- Entry points: <symbols or routes>
- Dependencies: <internal and external>
- Tests: <paths and coverage signal>
- Owner: <confirmed or inferred>
- Risks and unknowns: <items>
- Evidence: <anchors>
Коли використовувати Під час legacy discovery, коли потрібно розкласти system-level карту на reviewable module records.
Коли це поганий вибір Для business behavior inventory, повної call graph або тверджень про ownership без evidence.
Before-state contract для порівняння результатів малих змін і контрольованого rollback.
Де знаходиться {project}/MODERNIZATION_BASELINE.md (repository; документований приклад) Усі поля scope/revisionrequired — Межі модуля або flow та revision context.
observable behaviorrequired — Inputs, outputs, side effects і failure paths.
invariantsrequired — Контракти, які не можна змінити в structural slice.
checks/rollbackrequired — Фактичні checks, checkpoint і невідомі питання.
Шаблон MODERNIZATION_BASELINE.md Скопіювати шаблон # MODERNIZATION_BASELINE.md
## Scope and revision
- Module/flow: <area>
- Revision: <commit or date>
## Observable behavior
- Inputs: <inputs>
- Outputs: <outputs>
- Side effects: <effects>
- Failure paths: <errors and recovery>
## Invariants
- <contract that must remain true>
## Checks and observability
- `<command or scenario>` — <actual result>
## Rollback point and unknowns
- Checkpoint: <reference>
- Unknowns: <items>
Коли використовувати Перед modernization або великим refactoring, коли потрібно мати перевірювану точку відліку.
Коли це поганий вибір Для бажаної архітектури, повного тестового звіту або припущень без observable evidence.
Boundary decision record для вибору testable та rollback-friendly seam.
Де знаходиться {project}/SEAM_MAP.md (repository; документований приклад) Усі поля flow/current pathrequired — Flow, caller, callee та фактичний dependency path.
candidate seamrequired — Boundary, adapter або routing point для підміни.
dependency/test directionrequired — Напрям залежності та спосіб спостерігати seam.
risk/next checkrequired — Міграційний ризик і конкретна наступна перевірка.
Шаблон SEAM_MAP.md Скопіювати шаблон # SEAM_MAP.md
## Flow and boundary
- Flow: <business or runtime flow>
- Entry point: <caller>
## Current path
- Caller: <component>
- Legacy callee: <component>
- Side effects: <effects>
## Candidate seam
- Interface/adapter/event/routing: <boundary>
- Dependency direction: <producer -> consumer>
- Test seam: <how to observe it>
## Migration risk and next slice
- Risk: <risk>
- Next check: <one verification>
Коли використовувати Коли legacy-модуль потрібно розділити на незалежні reviewable modernization slices.
Коли це поганий вибір Для повної call graph, декоративної abstraction або seam без перевірюваного output.
Read-only discovery record для визначення, чи готовий bounded migration slice до compatibility analysis.
Де знаходиться {project}/MIGRATION_DISCOVERY.md (repository; документований приклад) Усі поля source/target scoperequired — Source state, target intent і bounded migration area.
evidencerequired — Repository, runtime, deployment, integration або official-doc anchors.
knowns/assumptions/unknownsrequired — Розділені факти, припущення, невідомі питання та owners.
starting checkpointrequired — Revision/environment і відтворюваний baseline.
stop conditionsrequired — Умови, що блокують analysis або pilot.
Шаблон MIGRATION_DISCOVERY.md Скопіювати шаблон # MIGRATION_DISCOVERY.md
## Source and target
- Source state: <runtime, framework, platform, or version>
- Target state: <runtime, framework, platform, or version>
- Migration slice: <bounded area>
## Evidence
- <repository, build, deployment, integration or official-doc anchor>
## Known, assumed, unknown
- Known: <confirmed fact>
- Assumption: <assumption and owner>
- Unknown: <question and next check>
## Starting checkpoint
- Revision/environment: <reference>
- Baseline check: <command or scenario>
## Stop conditions
- <condition that blocks analysis or pilot>
Коли використовувати Перед migration analysis, коли потрібно відділити read-only facts від target assumptions і визначити точку старту.
Коли це поганий вибір Для загальної карти repository, виконаного migration report або списку dependencies без source-to-target scope.
Evidence-backed research record для breaking changes, deprecations і behavior changes перед migration pilot.
Де знаходиться {project}/CHANGELOG_RESEARCH.md (repository; документований приклад) Усі поля version windowrequired — Source і target versions та межі changelog search.
official evidencerequired — Версія, розділ, URL або repository anchor для finding.
change and impactrequired — Тип зміни, affected area та можливий вплив.
confidence/next checkrequired — Рівень підтвердження і конкретна follow-up перевірка.
limitsrequired — Недоступні, неоднозначні або неперевірені факти.
Шаблон CHANGELOG_RESEARCH.md Скопіювати шаблон # CHANGELOG_RESEARCH.md
## Version window
- Source: <version>
- Target: <version>
## Findings
| Version | Official section | Change type | Affected area | Impact | Confidence | Next check |
| --- | --- | --- | --- | --- | --- | --- |
| <version> | <URL or section> | <breaking/deprecated/behavior/config> | <path or component> | <possible impact> | <confirmed/needs verification/Unknown> | <check> |
## Limits
- <release or repository fact not verified>
Коли використовувати Коли migration проходить між версіями й потрібно перетворити офіційні release notes на перевірювані repository findings.
Коли це поганий вибір Для загального release changelog, повного transcript або впевнених висновків без official source і affected-area check.
Карта впливу для визначення порядку compatibility checks та bounded migration slices.
Де знаходиться {project}/DEPENDENCY_GRAPH.md (repository; документований приклад) Усі поля nodes/source-targetrequired — Компоненти graph і їхні source/target states.
directed edgesrequired — Напрям залежності, contract або version constraint.
affected flowsrequired — Runtime flows, entry points і side effects під впливом.
evidence/unknownsrequired — Anchors, high-impact hubs і непідтверджені edges.
Шаблон DEPENDENCY_GRAPH.md Скопіювати шаблон # DEPENDENCY_GRAPH.md
## Nodes
| Node | Source | Target | Type | Evidence |
| --- | --- | --- | --- | --- |
| <component> | <source state> | <target state> | <runtime/framework/plugin/integration> | <anchor> |
## Directed edges
- <producer> -> <consumer>: <contract or version constraint>
## Affected flows
- <flow>: <entry point, path and side effects>
## Hubs and unknowns
- High-impact hub: <node and reason>
- Unknown: <edge or constraint and next check>
Коли використовувати Перед migration sequencing, коли version changes можуть зачепити direct/transitive dependencies або integration paths.
Коли це поганий вибір Для простого списку модулів, повної call graph без migration scope або декоративної схеми без evidence.
Decision matrix для розділення compatible, blocking, Unknown і requires-verification items.
Де знаходиться {project}/COMPATIBILITY_MATRIX.md (repository; документований приклад) Усі поля source/target scoperequired — Пара станів, для якої приймається compatibility decision.
technical dimensionsrequired — API, configuration, ABI, runtime, data, protocol і operations.
status/evidencerequired — Compatible, blocking, Unknown або requires verification з anchor.
owner/next actionrequired — Відповідальна роль і перевірка для невизначених items.
Шаблон COMPATIBILITY_MATRIX.md Скопіювати шаблон # COMPATIBILITY_MATRIX.md
## Scope
- Source: <version or platform>
- Target: <version or platform>
## Decisions
| Component/edge | API | Config | ABI | Runtime | Data format | Protocol | Operations | Status | Evidence | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| <item> | <status> | <status> | <status> | <status> | <status> | <status> | <status> | <compatible/blocking/Unknown> | <anchor> | <role> |
## Blocking and unknown items
- <item> — <next check or hold decision>
Коли використовувати Коли потрібно прийняти окремі технічні рішення про сумісність, а не звести ризики до одного score.
Коли це поганий вибір Для загальної risk map, vendor claim без перевірки або compatibility verdict без component-level dimensions.
Категорія
Повторювані workflow 7 артефактів
Версіонований workflow contract.
Де знаходиться {project}/.claude/skills/{skill-name}/SKILL.md (repository; документований приклад) ~/.claude/skills/{skill-name}/SKILL.md (user; документований приклад) Усі поля namerequired — Стабільний ідентифікатор workflow. Приклад: issue-analysis
descriptionrequired — Що робить skill і який результат повертає.
argument-hintoptional — Підказка щодо аргументів slash-команди. Приклад: [input-path] [focus]
when_to_useconventional — Умови запуску.
allowed_toolsconventional — Мінімальний набір дозволених інструментів. Приклад: read, grep
instructions/templatesrequired — Основна процедура та допоміжні шаблони.
Шаблон SKILL.md Скопіювати шаблон ---
name: <skill-name>
description: <what this workflow does>
argument-hint: "[input-path] [focus]"
---
# <Skill title>
## When to use
Use when <trigger>.
## Steps
1. Inspect the input.
2. Perform the focused workflow.
3. Return evidence and remaining risks.
## Constraints
- Do not modify files outside the declared scope.
Коли використовувати Коли одна процедура повторюється і має стабільний контракт.
Коли це поганий вибір Для одноразової думки, нестабільного експерименту або permission enforcement.
Примітка Поля з прикладу TASK_SPEC є project convention; точний frontmatter залежить від актуальної версії Claude Code.
Контрольований role contract із межами Read/Run/Write/Stop.
Де знаходиться {project}/.claude/agents/reviewer.md (repository; документований приклад) ~/.claude/agents/{name}.md (user; документований приклад) Усі поля namerequired — Назва ролі.
descriptionrequired — Коли та для чого викликати.
toolsconventional — Дозволені інструменти.
role/prohibitionsrequired — Роль і заборонені дії.
result formatrequired — Структура findings із доказами.
Шаблон Custom subagent Скопіювати шаблон ---
name: <reviewer>
description: Reviews <area> and returns evidence-backed findings.
tools: Read, Grep
---
# Role
Inspect only the assigned scope.
# Output
- Finding
- File and line
- Evidence
- Confidence
# Prohibitions
Do not edit files or broaden the scope.
Коли використовувати Для вузької повторюваної ролі з підготовленим входом і визначеним звітом.
Коли це поганий вибір Для необмеженої реалізації або як заміну permissions і human approval.
Локальна event-driven automation.
Де знаходиться {project}/.claude/hooks/ (repository; документований приклад) Усі поля eventrequired — Момент, коли automation запускається.
matcherrequired — Умова або шлях, що звужує область.
handlerrequired — Одна передбачувана дія або команда.
mode/kill switchconventional — Режим blocking/non-blocking та спосіб вимкнення.
Шаблон Hook configuration Скопіювати шаблон event: <lifecycle-event>
matcher: <path-or-condition>
handler: <command-or-script>
mode: non-blocking
kill_switch: <how-to-disable>
Коли використовувати Для вузької, передбачуваної й легко вимкненої локальної автоматизації.
Коли це поганий вибір Для orchestration, бізнес-рішень, повного CI або прихованого task spec.
Примітка Назви подій і matcher треба звіряти з актуальною CLI-документацією.
Distribution unit для перевіреного командного розширення.
Де знаходиться Plugin package (external; документований приклад) Усі поля manifestrequired — Ідентичність і склад пакета.
workflow assetsrequired — Skills, agents або commands.
versionrequired — Версія для відтворюваної доставки.
permissions/integration notesconventional — Потрібні доступи й обмеження.
Шаблон Plugin Скопіювати шаблон name: <plugin-name>
version: 0.1.0
manifest:
skills:
- <skill-name>
agents:
- <agent-name>
permissions:
- <required-access>
Коли використовувати Для стабільного workflow, який треба повторно доставляти команді.
Коли це поганий вибір Для one-off experiment або неперевіреного automation.
Discoverable command reference для команди або skill.
Де знаходиться {project}/commands.md (repository; документований приклад) Усі поля workflowrequired — Процес або сценарій, якому належить команда.
run contextrequired — Каталог, середовище та передумови запуску.
expected resultrequired — Спостережуваний результат і stop condition.
Шаблон commands.md Скопіювати шаблон # Commands
## <workflow>
- Purpose: <what it verifies or changes>
- Run from: <directory>
- Command: `<command>`
- Expected result: <observable output>
- Stop if: <failure or unsafe condition>
Коли використовувати Коли команди повторюються й коротка довідка зменшує помилки запуску.
Коли це поганий вибір Як заміна task spec, повного README або прихований automation script.
Risk-bounded fast-path contract, а не дозвіл на необмежені дії.
Де знаходиться .claude/workflows/CLAWD-YOLO.md (repository; документований приклад) Усі поля allowed scoperequired — Точні шляхи, дії та середовище.
guardrailsrequired — Заборонені дії та обмеження ризику.
human checkpointrequired — Момент обовʼязкового людського рішення.
Шаблон CLAWD YOLO Скопіювати шаблон # CLAWD YOLO
## Allowed scope
- Paths: <narrow paths>
- Actions: <allowed actions>
## Guardrails
- No secrets or destructive operations.
- Stop on: <failure signal>
- Human checkpoint: <before merge or release>
Коли використовувати Для низькоризикової повторюваної роботи з коротким feedback loop.
Коли це поганий вибір Для production, auth, secrets, платежів, destructive commands або невизначеного scope.
Людиночитний workflow contract із ролями та failure path.
Де знаходиться {project}/workflow.md (repository; документований приклад) Усі поля trigger/inputsrequired — Умови запуску та вхідні дані.
stages/ownersrequired — Етапи й відповідальність.
evidence/failure pathrequired — Вихідні артефакти та обробка збою.
Шаблон workflow.md Скопіювати шаблон # Workflow: <name>
## Trigger
<when to use>
## Inputs
- <input>
## Stages
1. <stage and owner>
2. <stage and owner>
## Evidence
- <output artifact>
## Failure path
<how to stop, retry, rollback, or escalate>
Коли використовувати Коли процес повторюється і його потрібно передати або відтворити.
Коли це поганий вибір Для одноразового prompt, низькорівневого script або policy-only правила.
Integration boundary із transport, scope та auth.
Де знаходиться {project}/.claude/mcp/ (repository; документований приклад) Усі поля transportrequired — Як підключається server.
scoperequired — Де та для кого доступна інтеграція.
authrequired — Як надаються credentials без витоку секретів.
status/healthconventional — Як перевірити доступність і стан.
Шаблон MCP Скопіювати шаблон server: <server-name>
transport: <stdio|http>
command: <command>
scope: project
auth: REDACTED
healthcheck: <status command>
Коли використовувати Коли дані або дії живуть у зовнішній issue tracker, DB, docs чи browser service.
Коли це поганий вибір Коли потрібні дані вже локальні або credential/side-effect/prompt-injection ризики не контрольовані.
Примітка Конкретна конфігурація version-sensitive.
Категорія
Виконання і якість 8 артефактів
Операційний набір контрольованої реалізації.
Де знаходиться .git/ (generated; операційний або зовнішній артефакт) worktree/ (generated; операційний або зовнішній артефакт) working diff (generated; операційний або зовнішній артефакт) Усі поля baselinerequired — Стан, від якого почалася робота.
scoperequired — Файли та межі зміни.
diffrequired — Фактична різниця змін.
checkpointoptional — Точка повернення або review.
Шаблон Git branch / worktree / diff Скопіювати шаблон git switch -c <branch-name>
git status
git diff -- <path>
# Review the diff, run checks, then create a checkpoint.
Коли використовувати Для довгої, паралельної, ризикової або такої, що потребує review, роботи.
Коли це поганий вибір Для крихітної незалежної зміни або worktree без плану cleanup.
Operational execution record для локального або CI runner.
Де знаходиться .claude/runs/<run-id>.md (generated; документований приклад) Усі поля inputrequired — Вхідні дані або ідентифікатор задачі.
command/environmentrequired — Що і де було запущено.
status/outputrequired — Фактичний стан і посилання на результат.
Шаблон CLAWD Runner Скопіювати шаблон # CLAWD Runner
run: <human-readable name>
input: <path or task id>
command: `<command>`
environment: <local|ci|staging>
status: <planned|running|passed|failed|stopped>
output: <artifact path or summary>
Коли використовувати Коли запуск треба повторити, перевірити або передати іншому учаснику.
Коли це поганий вибір Для довільного raw log без висновку або як заміна CI provider record.
Machine-readable locale contract для UI, API і тестів.
Де знаходиться {project}/locales.json (repository; документований приклад) Усі поля defaultLocalerequired — Локаль за замовчуванням.
supportedLocalesrequired — Які локалі реально підтримуються.
fallbackLocale/namespacesrequired — Fallback і групи перекладів.
Шаблон locales.json Скопіювати шаблон {
"defaultLocale": "<locale>",
"supportedLocales": ["<locale>"],
"fallbackLocale": "<locale>",
"namespaces": ["<namespace>"]
}
Коли використовувати Коли locale behavior має бути єдиним контрактом для кількох шарів системи.
Коли це поганий вибір Для одного текстового перекладу або як заміна локалізаційним файлам і тестам.
Cross-layer delivery bundle для перевірки узгодженості перекладів.
Де знаходиться locale API/UI/test change set (repository; документований приклад) Усі поля locale/keysrequired — Локаль і змінені translation keys.
layersrequired — Повʼязані API, UI та test paths.
verificationrequired — Перевірка fallback, rendering і тестів.
Шаблон Locale API/UI/test bundle Скопіювати шаблон # Locale bundle
## Contract
- Locale: <locale>
- Keys added/changed: <keys>
## Layers
- API: <paths>
- UI: <paths>
- Tests: <paths>
## Verification
- `<command>` — <result>
Коли використовувати Для змін, де одна локаль повинна узгоджено пройти кілька шарів.
Коли це поганий вибір Для зміни лише одного тексту без cross-layer поведінки.
Structured status surface для локального runner або CI.
Де знаходиться .claude/runs/run-status.yaml (generated; документований приклад) Усі поля workflow/statusrequired — Workflow і загальний стан запуску.
stagesrequired — Стани окремих етапів та evidence.
run_id/updated_atconventional — Trace identifier і час оновлення.
Шаблон run-status.yaml Скопіювати шаблон run_id: <opaque-id>
workflow: <name>
status: <planned|running|passed|failed|stopped>
stages:
- name: <stage>
status: <status>
evidence: <path-or-summary>
updated_at: <timestamp>
Коли використовувати Для статусу довгого або багатостадійного локального/CI запуску.
Коли це поганий вибір Для людиночитного postmortem або одноразової команди без етапів.
Deterministic diagnosis output для CI або bounded analyzer.
Де знаходиться .claude/diagnosis/diagnosis.json (generated; документований приклад) Усі поля status/classrequired — Загальний стан і категорія проблеми.
evidencerequired — Мінімальні очищені докази.
confidence/nextActionrequired — Впевненість і безпечна наступна дія.
Шаблон diagnosis.json Скопіювати шаблон {
"status": "<failure|healthy|unknown>",
"class": "<test|build|environment|flaky|contract>",
"evidence": ["<redacted-log-line>"],
"confidence": "<high|medium|low>",
"nextAction": "<safe next step>"
}
Коли використовувати Коли failure треба відрізнити від flaky, environment або contract проблеми.
Коли це поганий вибір Для автоматичного виправлення без human review або публікації сирих секретних логів.
Regression safety net для observable behavior, а не набір тестів «на всяк випадок».
Де знаходиться {project}/CHARACTERIZATION_TESTS.md (repository; документований приклад) Усі поля scope/baselinerequired — Межі модуля, flow і revision, для якого зафіксовано поведінку.
cases/inputsrequired — Відтворювані сценарії та їхні вхідні дані.
observable outputs/side effectsrequired — Очікувані результати, помилки та side effects.
invariants/evidencerequired — Поведінкові інваріанти й конкретні докази.
run/limitsrequired — Команда запуску, baseline result і межі покриття.
Шаблон CHARACTERIZATION_TESTS.md Скопіювати шаблон # CHARACTERIZATION_TESTS.md
## Scope and baseline
- Module/flow: <area>
- Revision: <commit or date>
- Behavior under test: <observable contract>
## Cases
| Case | Inputs | Expected observable output | Side effects | Evidence |
| --- | --- | --- | --- | --- |
| <case> | <reproducible input> | <status, value, event, or error> | <effect or none> | <test/log/source> |
## Invariants
- <behavior that must remain unchanged>
## Run and interpretation
- Command: `<focused test command>`
- Baseline result: <actual result>
- Stop if: <unexpected behavior or missing evidence>
## Limits
- <unknown behavior or scenario not covered>
Коли використовувати Коли перед legacy refactoring потрібно закріпити критичну фактичну поведінку focused тестами.
Коли це поганий вибір Для повного unit-test плану, тестування кожного implementation detail або заміни business requirements.
Migration contract для поступової підміни фрагмента без big-bang rewrite.
Де знаходиться {project}/STRANGLER_SLICE.md (repository; документований приклад) Усі поля fragment/pathsrequired — Межа fragment та legacy/new paths.
routing/compatibilityrequired — Правило вибору path і збереження contract.
side effects/observabilityrequired — Coexistence, idempotency та сигнали результату.
rollback/retirementrequired — Повернення і докази для видалення legacy.
Шаблон STRANGLER_SLICE.md Скопіювати шаблон # STRANGLER_SLICE.md
## Fragment and boundary
<bounded behavior being replaced>
## Paths
- Legacy: <old path>
- New: <new path>
- Router: <explicit selection rule>
## Compatibility and side effects
- Contract: <preserved behavior>
- Side effects: <single-write/idempotency rule>
- Observability: <signals>
## Rollout and rollback
- Rollout: <small expansion>
- Rollback: <switch and state recovery>
## Retirement criteria
- <evidence required before removing legacy>
Коли використовувати Для поступової підміни ізольованого legacy-фрагмента з контрольованим coexistence.
Коли це поганий вибір Для повного rewrite, непомітного dual-write або міграції без rollback і observability.
Категорія
Артефакти цього сайту 1 артефактів
Публічний entry point для розробника проєкту.
Де знаходиться README.md (repository; є в цьому repository) Усі поля setuprequired — Вимоги та команди запуску.
scoperequired — Що входить у поточну ітерацію.
structurerequired — Де знаходяться ключові частини.
status/review notesoptional — Поточні результати та обмеження.
Шаблон README.md Скопіювати шаблон # Project name
## Setup
```bash
npm install
npm run dev
```
## Scope
<what this project contains>
## Verification
- `npm run check`
Коли використовувати На вході в repository або коли змінюється setup і scope.
Коли це поганий вибір Для детального task contract, evidence log або внутрішніх секретів.