Artifact-first навігація

Каталог артефактів

59 описів · 8 категорій

Це curated registry артефактів, згаданих у гайді та присутніх у цьому repository. Статус «документований приклад» означає, що матеріали описують форму артефакта, але файла в цьому repository немає.

Приклад організації в проекті
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 артефактів

CLAUDE.md

Фіксує стабільні правила роботи агента з конкретним проєктом.

Є в цьому repository

Спільний контекст для більшості сесій і точка входу в 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.local.md

Зберігає локальні переваги та машинні налаштування, які не мають потрапити до team contract.

Документований приклад

Персональний шар контексту поверх спільних правил.

Де знаходиться
  • .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, секретів чи вимог, які має бачити команда.

.claude/rules/

Організовує правила, scoped до окремої області або типу файлів.

Документований приклад

Зменшує шум глобального контексту та наближає правило до 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-патерна.

Коли це поганий вибір

Для одного короткого завдання або правила, яке має діяти всюди.

settings.json

Визначає спільні або користувацькі налаштування Claude Code.

Документований приклад

Версійований 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 документацією.

settings.local.json

Зберігає локальні налаштування середовища.

Документований приклад

Машинний 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 або місце для командних правил.

AI_CODING_POLICY.md

Задає командний baseline безпечного використання AI у розробці.

Документований приклад

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.

CODEOWNERS

Визначає відповідальних reviewer-ів для шляхів або компонентів.

Документований приклад

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 артефактів

TASK_SPEC.md

Перетворює issue або ідею на перевірюваний task contract.

Є в цьому repository

Визначає межі роботи до реалізації та зменшує 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.

SPEC.md

Описує project-level contract: проблему, аудиторію, scope і критерії результату.

Варіант назви або шляху

Довгоживуча специфікація проєкту або 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

CAPSTONE_BRIEF.md

Фіксує спільні правила й очікування capstone.

Документований приклад

Надзадачний 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 або журналу фактичних перевірок.

Backlog / roadmap

Розкладає capstone або довгу роботу на milestones.

Документований приклад

Послідовність 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.

CONTRACT.md

Фіксує межу взаємодії між компонентами, ролями або workflow stages.

Документований приклад

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.

PLAN.md

Перекладає task contract у послідовність перевірюваних implementation steps.

Документований приклад

Короткий 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.

REFACTORING_PLAN.md

Обмежує один incremental refactoring slice його метою, non-goals, checks і stop condition.

Документований приклад

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.

MODERNIZATION_ROADMAP.md

Розкладає modernization на milestones з owner, evidence gates, dependencies та exit criteria.

Документований приклад

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.

MIGRATION_PLAN.md

Розкладає migration на bounded phases із evidence gates, owners, rollback і exit criteria.

Документований приклад

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 артефактів

EVIDENCE.md

Фіксує факти, рішення, перевірки та залишкові ризики.

Варіант назви або шляху

Стислий 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 треба узгодити.

HANDOFF_NOTE.md

Передає контекст, стан і наступний крок іншому виконавцю або reviewer.

Документований приклад

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.

PR description

Пакує зміни для pre-merge review.

Операційний або зовнішній артефакт

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.

Commit message

Описує один логічний крок історії змін.

Операційний або зовнішній артефакт

Короткий 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.

Changelog

Пояснює release- та user-visible зміни.

Операційний або зовнішній артефакт

Комунікаційний 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 або список кожного внутрішнього коміту.

HANDOFF_REVIEW.md

Передає reviewer-у перевірений стан handoff-пакета та відкриті питання.

Документований приклад

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 або неперевіреного статусу.

Postmortem

Фіксує, що сталося після збою, які controls не спрацювали і що змінити.

Документований приклад

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 або для персонального звинувачення.

REVIEW_NOTES.md

Зберігає findings, перевірені області та невирішені питання reviewer.

Документований приклад

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.

RUNBOOK.md

Фіксує хронологію реально виконаних project tasks, їхній scope, результат і verification.

Є в цьому repository

Внутрішній 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.

MODERNIZATION_ANTI_PATTERNS.md

Збирає сигнали небезпечних modernization-практик і безпечніші альтернативи.

Документований приклад

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 артефактів

CODEBASE_INVENTORY.md

Створює компактну карту репозиторію та його ризиків.

Документований приклад

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 або джерело неперевірених припущень.

API_MAP.md

Показує зв’язки між routes, handlers, integrations, DB, env і tests.

Документований приклад

Карта трасування інтеграцій.

Де знаходиться
  • {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 чи зовнішніх інтеграцій або для загальної карти всього репозиторію.

CLAWD Wisdom

Зберігає перевірені короткі висновки, які варто повторно використовувати в workflow.

Документований приклад

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, які корисні в наступних задачах.

Коли це поганий вибір

Для неперевірених припущень, особистого щоденника або повного логу сесії.

research-digest.md

Стискає результати дослідження з джерелами, висновками та невизначеністю.

Документований приклад

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 або висновку без посилань на джерела.

DEBT_SIGNALS.md

Фіксує обмежений набір evidence-backed static signals технічного боргу.

Документований приклад

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.

RISK_MAP.md

Поєднує business criticality, change risk, unknowns і конкретні дії.

Документований приклад

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.

ARCHITECTURE_CURRENT.md

Описує фактичну current-state architecture та її підтверджені межі.

Документований приклад

Стабільна карта 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_INVENTORY.md

Інвентаризує бізнес-потоки, їхні inputs/outputs, тести та characterization candidates.

Документований приклад

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.

Коли це поганий вибір

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

CRITICAL_FLOWS.md

Описує наскрізні runtime-потоки, які мають високий вплив або високу ціну помилки.

Документований приклад

Карта трасування від 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.

MODULE_INVENTORY.md

Фіксує межі модулів, entry points, залежності, ownership і відкриті питання.

Документований приклад

Деталізований 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.

MODERNIZATION_BASELINE.md

Фіксує спостережувану поведінку, інваріанти та safety checks legacy-модуля до modernization.

Документований приклад

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.

SEAM_MAP.md

Картує точки розділення між callers, legacy implementation і майбутнім replacement.

Документований приклад

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.

MIGRATION_DISCOVERY.md

Фіксує source-to-target межі міграції, стартову точку, evidence та невідомі питання.

Документований приклад

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.

CHANGELOG_RESEARCH.md

Зіставляє зміни у version window з affected code, configuration, runtime та integration surfaces.

Документований приклад

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.

DEPENDENCY_GRAPH.md

Показує migration-impact nodes, напрямлені звʼязки, target constraints і affected flows.

Документований приклад

Карта впливу для визначення порядку 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.

COMPATIBILITY_MATRIX.md

Фіксує source-to-target compatibility decisions за технічними вимірами та їхніми evidence anchors.

Документований приклад

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 артефактів

SKILL.md

Описує стабільну повторювану процедуру з її trigger, інструкціями й обмеженнями.

Документований приклад

Версіонований 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.

Custom subagent

Фіксує вузьку роль агента для повторюваного discovery, review або дослідження.

Документований приклад

Контрольований 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.

Hook configuration

Автоматично реагує на вузьку подію життєвого циклу.

Документований приклад

Локальна 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-документацією.

Plugin

Постачає версіонований пакет workflow, skills, agents або інтеграцій.

Документований приклад

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.

commands.md

Фіксує короткі повторювані команди та їхній безпечний контекст запуску.

Документований приклад

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.

CLAWD YOLO

Описує свідомий швидкий режим із явно звуженими межами та умовами зупинки.

Документований приклад

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.md

Описує повторюваний процес від trigger до перевіреного результату.

Документований приклад

Людиночитний 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 правила.

Категорія

Інтеграції

1 артефактів

MCP

Підключає зовнішнє джерело даних або дій до workflow.

Документований приклад

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 branch / worktree / diff

Ізолює роботу, показує зміни та підтримує review/rollback.

Операційний або зовнішній артефакт

Операційний набір контрольованої реалізації.

Де знаходиться
  • .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.

CLAWD Runner

Описує відтворюваний запуск workflow з входом, статусом, логом і результатом.

Документований приклад

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.

locales.json

Описує доступні локалі та правила їхнього вибору.

Документований приклад

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 має бути єдиним контрактом для кількох шарів системи.

Коли це поганий вибір

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

Locale API/UI/test bundle

Поєднує зміни локалі в API, UI та тестах в один reviewable output.

Документований приклад

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 поведінки.

run-status.yaml

Машинночитано фіксує стан етапів workflow та їхні результати.

Документований приклад

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 або одноразової команди без етапів.

diagnosis.json

Структуровано зберігає класифікацію failure, evidence та наступну дію.

Документований приклад

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 або публікації сирих секретних логів.

CHARACTERIZATION_TESTS.md

Фіксує перевірки фактичної поведінки legacy-модуля до та під час modernization.

Документований приклад

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.

STRANGLER_SLICE.md

Описує bounded Strangler Fig slice зі старим і новим шляхом, coexistence та rollback.

Документований приклад

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 артефактів

README.md

Пояснює запуск, scope, структуру та поточний стан repository.

Є в цьому repository

Публічний 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 або внутрішніх секретів.

На початок