@jakerdy/agentica 0.0.2 → 0.0.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # Agentica
2
2
 
3
- [![Version](https://img.shields.io/badge/version-0.1.0-blue)](https://github.com/jakerdy/agentica/releases/tag/v0.1.0)
3
+ [![Version](https://img.shields.io/badge/version-0.0.4-blue)](https://github.com/jakerdy/agentica/releases/tag/v0.0.4)
4
4
  [![License: MIT](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE)
5
5
  [![Bun Build](https://img.shields.io/badge/build-bun-orange)](https://bun.sh)
6
6
 
@@ -13,26 +13,23 @@
13
13
 
14
14
  ## Prerequisites
15
15
 
16
- - VSCode 1.109.0+
16
+ - [VSCode](https://code.visualstudio.com/) 1.109.0+
17
17
  - GitHub Copilot
18
- - Bun 1.3+ / Node.js 18+ (для запуска CLI)
19
- - Context7 (`Upstash.context7-mcp`) — опционально
18
+ - [Bun](https://bun.com/docs/installation) 1.3+ или [Node.js](https://nodejs.org/en/download) 18+ (для запуска CLI)
19
+ - Расширение Context7 (`Upstash.context7-mcp`) — опционально
20
20
 
21
21
  ## Quick Start
22
22
 
23
23
  ```bash
24
- # Установка глобально
25
- bun install -g @jakerdy/agentica
24
+ # Запускаем без установки
25
+ bunx @jakerdy/agentica init typescript/cli MyProject
26
26
 
27
- # Инициализация (работает и в пустой папке, и в существующем проекте)
28
- agentica init typescript/cli MyProject
29
-
30
- # Открытие в VSCode
31
- cd MyProject
32
- code .
27
+ # Открываем в VSCode
28
+ cd MyProject && code .
33
29
  ```
34
30
  После `init` Agentica автоматически:
35
31
  - копирует в проект `.agentica/prompts`, `.agentica/templates` и `.agentica/skills`;
32
+ - создаёт директории спецификаций `.agentica/architecture`, `.agentica/changes`, `.agentica/features`, `.agentica/release`;
36
33
  - обновляет `.vscode/settings.json`, добавляя пути в `chat.promptFilesLocations` и `chat.agentSkillsLocations`.
37
34
  - добавит context7 в рекомендованные расширения, чтобы агенты сами могли искать документацию по библиотекам
38
35
 
@@ -47,6 +44,35 @@ code .
47
44
  - Прочие важные детали
48
45
  ```
49
46
 
47
+ ## CLI
48
+
49
+ Чтобы было проще интегрировать Agentica в ваш проект, был создан небольшой, но удобный CLI.
50
+
51
+ Agentica CLI поддерживает два формата запуска `init`:
52
+ - **Позиционный (основной):** `agentica init <stack> [targetPath]`
53
+ - **Через опции (совместимость):** `agentica init --stack <type> [--out <path>]`
54
+
55
+ ### Основные команды
56
+
57
+ ```bash
58
+ # Инициализация Agentica в текущей папке
59
+ agentica init typescript/cli
60
+
61
+ # Инициализация с созданием новой папки проекта
62
+ agentica init typescript/spa MyProject
63
+
64
+ # То же через опции (режим совместимости)
65
+ agentica init --stack typescript/spa --out MyProject
66
+
67
+ # Показать доступные шаблоны стеков
68
+ agentica stacks
69
+
70
+ # Справка по CLI
71
+ agentica --help
72
+ agentica init --help
73
+ ```
74
+
75
+
50
76
  ## Мотивация
51
77
 
52
78
  Agentica был создан в ходе мучительного поиска "идеального" инструмента для работы с агентными системами.
@@ -78,9 +104,9 @@ Agentica - это конструктор таких спек. Она запол
78
104
 
79
105
  ## Философия подхода
80
106
 
81
- ### 0. Вся ответственность за принятые решения лежит на тебе
107
+ ### 0. Вся ответственность за принятые решения лежит на вас
82
108
 
83
- Прелесть агентов заключается в том, что они мультиплицируют твои возможности по написанию кода в разы, а то и в десятки раз. Но не весь тот код, что написал агент, следует сразу лить в прод.
109
+ Прелесть агентов заключается в том, что они мультиплицируют ваши возможности по написанию кода в разы, а то и в десятки раз. Но не весь тот код, что написал агент, следует сразу лить в прод.
84
110
 
85
111
  В идеале, вся та работа по "продумыванию" проекта должна быть сделана человеком. И только после того, как человек удостоверился в том что:
86
112
  - Все структуры данных и интерфейсы правильные
@@ -134,8 +160,8 @@ Agentica строго разделяет уровни ответственнос
134
160
  ```text
135
161
  .
136
162
  ├── .agentica/ # GLOBAL SCOPE (Конфигурация и общие знания)
137
- │ ├── templates/ # Шаблоны (feature, arch, change)
138
- │ ├── prompts/ # Промпты (init, create, implement...)
163
+ │ ├── templates/ # Шаблоны (feature, arch, change, release)
164
+ │ ├── prompts/ # Промпты (init, create, implement, commit, release...)
139
165
  │ ├── skills/ # Skills для Copilot Agent (например frontend-design)
140
166
  │ ├── product.md # Глобальный продукт
141
167
  │ ├── structure.md # Структура репозитория
@@ -147,6 +173,7 @@ Agentica строго разделяет уровни ответственнос
147
173
  │ │ │ ├── architecture/ # AR-XXXX (Архитектурные решения)
148
174
  │ │ │ ├── changes/ # CH-XXXX (Изменения существующего)
149
175
  │ │ │ ├── features/ # FT-XXXX (Новые фичи)
176
+ │ │ │ ├── release/ # REL-XXXX (Подготовка и выпуск релизов)
150
177
  │ │ │ ├── product.md # Контекст пакета
151
178
  │ │ │ ├── structure.md # Структура пакета
152
179
  │ │ │ ├── tech.md # Стек пакета
@@ -163,18 +190,20 @@ Agentica строго разделяет уровни ответственнос
163
190
 
164
191
  Все команды вызываются через `/agentica.<command>`. Аргументы опциональны - агент постарается вывести их из контекста, но явное указание надежнее.
165
192
 
166
- | Команда | Аргументы | Назначение |
167
- | :---------- | :-------- | :---------------------------------------------------- |
168
- | `init` | `--lang`, | Инициализация и настройка проекта |
169
- | `architect` | `--name` | Архитектурная спецификация (`AR-XXXX`) |
170
- | `reverse` | `--name` | Reverse Engineering по существующему коду (`AR-XXXX`) |
171
- | `create` | `--name` | Спецификация новой фичи (`FT-XXXX`) |
172
- | `change` | `--name` | Спецификация изменений (`CH-XXXX`) |
173
- | `tasks` | `--id` | Декомпозиция спеки на задачи |
174
- | `implement` | `--id` | Написание кода по задачам |
175
- | `validate` | `--id` | Семантическая и техническая приемка |
176
- | `readme` | `--id` | Генерация документации |
177
- | `refactor` | --- | Улучшение кода без смены API |
193
+ | Команда | Аргументы | Назначение |
194
+ | :---------- | :-------------- | :---------------------------------------------------- |
195
+ | `init` | `--lang`, | Инициализация и настройка проекта |
196
+ | `architect` | `--name` | Архитектурная спецификация (`AR-XXXX`) |
197
+ | `reverse` | `--name` | Reverse Engineering по существующему коду (`AR-XXXX`) |
198
+ | `create` | `--name` | Спецификация новой фичи (`FT-XXXX`) |
199
+ | `change` | `--name` | Спецификация изменений (`CH-XXXX`) |
200
+ | `tasks` | `--id` | Декомпозиция спеки на задачи |
201
+ | `implement` | `--id` | Написание кода по задачам |
202
+ | `validate` | `--id` | Семантическая и техническая приемка |
203
+ | `commit` | `--skip-checks` | Коммит с проверками безопасности |
204
+ | `release` | `--type` | Подготовка релиза (`REL-XXXX`) и черновика changelog |
205
+ | `readme` | `--id` | Генерация документации |
206
+ | `refactor` | --- | Улучшение кода без смены API |
178
207
 
179
208
  ---
180
209
 
@@ -193,8 +222,10 @@ Agentica строго разделяет уровни ответственнос
193
222
 
194
223
  ```text
195
224
  /agentica.init --lang TypeScript
196
- Сделай CLI для импорта CSV. Нужны команды import, validate.
197
- Используй commander и chalk.
225
+
226
+ Проект посвящён разработке CLI-инструментов для управления задачами. Основные функции включают создание, обновление и удаление задач, а также интеграцию с календарём. Важно обеспечить поддержку плагинов и расширений в будущем.
227
+
228
+ Оснвной стек: TypeScript, Node.js, Commander.js для CLI
198
229
  ```
199
230
  *Что происходит:* Агент создает структуру `.agentica/`, заполняет `tech.md` и `structure.md` под ваш запрос, готовит промпты.
200
231
 
@@ -254,38 +285,40 @@ Agentica строго разделяет уровни ответственнос
254
285
  Восстанови карту модулей, просканируй entry-points.
255
286
  Найди циклические зависимости и узкие места в текущей реализации.
256
287
  ```
257
- *Агент просканирует кодовую базу и создаст описание системы "As-Is", подсветив зоны риска и архитектурный долг.*
288
+ *Агент просканирует кодовую базу и создаст описание системы "As-Is" в отдельном `AR-XXXX` документе, подсветив зоны риска и архитектурный долг.*
258
289
 
259
290
  ### 6. Документация
291
+
292
+ Когда работа над фичей закончена, и нужно быстро сгенерировать понятную документацию:
293
+
260
294
  ```text
261
295
  /agentica.readme --id FT-0012
262
- Сделай короткую доку для разработчиков с примерами.
296
+ Сделай короткую доку для разработчиков с примерами и описанием архитектуры нового решения.
263
297
  ```
264
298
 
265
- ## CLI
299
+ ### 7. Коммит "по богатому"
266
300
 
267
- Чтобы было проще интегрировать Agentica в ваш проект, был создан небольшой, но удобный CLI.
301
+ Используйте, когда нужно автоматически собрать staged-изменения, проверить их на мусор/секреты и создать качественное сообщение коммита.
268
302
 
269
- Agentica CLI поддерживает два формата запуска `init`:
270
- - **Позиционный (основной):** `agentica init <stack> [targetPath]`
271
- - **Через опции (совместимость):** `agentica init --stack <type> [--out <path>]`
303
+ Или просто используйте его всегда, когда собираетесь коммитить. Это просто, довольно быстро, а плюсы огромныe:
304
+ - Детальные сообщения которые муторно и лениво писать руками
305
+ - Гарантия, что в коммит не попадет мусор или секреты
306
+ - На основе истории можно будет делать качественные changelog'и и релизы, а не "misc updates" и "fixes"
272
307
 
273
- ### Основные команды
308
+ ```text
309
+ /agentica.commit
310
+ Подготовь commit для текущих изменений.
311
+ ```
312
+ *Агент добавит изменения в stage, предупредит о потенциальных артефактах (`.exe`, `.dll`, `.tgz` и т.п.), предложит обновить `.gitignore`, сформирует сообщение в формате `<change_type>: <Short Change Description>` + детальное описание и выполнит `git commit`.*
274
313
 
275
- ```bash
276
- # Инициализация Agentica в текущей папке
277
- agentica init typescript/cli
314
+ ### 8. Подготовка релиза
278
315
 
279
- # Инициализация с созданием новой папки проекта
280
- agentica init typescript/spa MyProject
316
+ Используйте, когда нужно пройти предрелизный аудит, собрать changelog из коммитов и подготовить план публикации.
281
317
 
282
- # То же через опции (режим совместимости)
283
- agentica init --stack typescript/spa --out MyProject
318
+ ```text
319
+ /agentica.release --type minor
320
+ Собери релиз для текущего состояния main и подготовь команды публикации.
321
+ ```
322
+ *Агент проверит ветку (`main/master`), рассчитает новую версию (patch/minor/major), соберёт черновик changelog с последнего тега, пройдёт предрелизный checklist и создаст `REL-XXXX` документ.*
284
323
 
285
- # Показать доступные шаблоны стеков
286
- agentica stacks
287
324
 
288
- # Справка по CLI
289
- agentica --help
290
- agentica init --help
291
- ```
package/dist/cli.js CHANGED
@@ -32,14 +32,14 @@ Expecting one of '${J.join("', '")}'`);let Z=`${q}Help`;return this.on(Z,($)=>{l
32
32
 
33
33
  ---
34
34
 
35
- `,Tz="globals",jz="anti-spaghetti.md",Nz="use-agentica.md";function hq(q,z,J){let Z=E(z,".agentica"),$=E(Z,Vz),Q=E(Z,Rz);if(D($))Lz($,Q);let X=E(q,Tz),Y=`lang-${J}.md`,U=o(E(X,Y),"utf-8"),B=o(E(X,jz),"utf-8"),H=o(E(X,Nz),"utf-8"),G=[U,B,H].join(Pz);Mz($,G,"utf-8")}var __dirname="E:\\Dev\\2026-02-15 - Agentica\\src\\commands",Dz=".agentica",uq="prompts",gq="templates",mq="skills",Ez="stacks",Fz="status.md",dq=1,wz=["prompts","templates","architecture","changes","features"],Sz=["product.md","structure.md","tech.md"];async function lq(q){console.log(W.blue(`
35
+ `,Tz="globals",jz="anti-spaghetti.md",Nz="use-agentica.md";function hq(q,z,J){let Z=E(z,".agentica"),$=E(Z,Vz),Q=E(Z,Rz);if(D($))Lz($,Q);let X=E(q,Tz),Y=`lang-${J}.md`,U=o(E(X,Y),"utf-8"),B=o(E(X,jz),"utf-8"),H=o(E(X,Nz),"utf-8"),G=[U,B,H].join(Pz);Mz($,G,"utf-8")}var __dirname="E:\\Dev\\2026-02-15 - Agentica\\src\\commands",Dz=".agentica",uq="prompts",gq="templates",mq="skills",Ez="stacks",Fz="status.md",dq=1,wz=["prompts","templates","architecture","changes","features","release"],Sz=["product.md","structure.md","tech.md"];async function lq(q){console.log(W.blue(`
36
36
  \uD83D\uDE80 Инициализация Agentica...
37
37
  `));let z=Az(q.stack);if(!z)_z(q.stack);await new pq(q,z).execute()}class pq{options;stack;repoRoot;targetDir;stackDir;agenticaDir;constructor(q,z){this.options=q;this.stack=z;this.repoRoot=Oz(),this.targetDir=this.options.name?cq(process.cwd(),this.options.name):process.cwd(),this.stackDir=R(this.repoRoot,Ez,this.stack.lang,this.stack.type),this.agenticaDir=R(this.targetDir,Dz)}async execute(){this.ensureStackExists(),this.createProjectDirIfNeeded(),this.createAgenticaDirectories(),this.copyPrompts(),this.copyTemplates(),this.copySkills(),this.copyStackTemplateFiles(),this.createStatusFile(),this.composeAgentsFile(),this.updateVSCodeConfiguration(),this.printSuccessMessage()}ensureStackExists(){if(D(this.stackDir))return;console.error(W.red(`❌ Стек не найден: ${this.stack.lang}/${this.stack.type}`)),console.error(W.yellow(` Путь проверки: ${this.stackDir}`)),process.exit(dq)}createProjectDirIfNeeded(){if(!this.options.name)return;j(this.targetDir),console.log(W.green(`✓ Создана директория: ${this.options.name}`))}createAgenticaDirectories(){j(this.agenticaDir),console.log(W.green("✓ Создана .agentica/"));for(let q of wz)j(R(this.agenticaDir,q))}copyPrompts(){let q=R(this.repoRoot,uq),z=R(this.agenticaDir,uq);k(q,z),console.log(W.green("✓ Скопирована prompts/"))}copyTemplates(){let q=R(this.repoRoot,gq),z=R(this.agenticaDir,gq);k(q,z),console.log(W.green("✓ Скопирована templates/"))}copySkills(){let q=R(this.repoRoot,mq),z=R(this.agenticaDir,mq);k(q,z),console.log(W.green("✓ Скопирована skills/"))}copyStackTemplateFiles(){for(let q of Sz){let z=R(this.stackDir,q),J=R(this.agenticaDir,q);t(z,J)}console.log(W.green(`✓ Скопирован шаблон стека: ${this.stack.lang}/${this.stack.type}`))}createStatusFile(){let q=xz(this.stack),z=R(this.agenticaDir,Fz);Iz(z,q,"utf-8"),console.log(W.green("✓ Создан status.md"))}composeAgentsFile(){hq(this.repoRoot,this.targetDir,this.stack.lang),console.log(W.green("✓ Сформирован AGENTS.md"))}updateVSCodeConfiguration(){try{fq(this.targetDir),vq(this.targetDir),console.log(W.green("✓ Обновлён .vscode/settings.json")),console.log(W.green("✓ Обновлён .vscode/extensions.json"))}catch(q){console.warn(W.yellow(`⚠ Предупреждение: не удалось обновить настройки VSCode: ${q}`))}}printSuccessMessage(){if(console.log(W.green.bold(`
38
38
  ✨ Agentica успешно инициализирована!
39
- `)),console.log(W.cyan("Следующие шаги:")),this.options.name)console.log(W.white(` 1. cd ${this.options.name}`));console.log(W.white(" 2. Открой проект в VSCode: code .")),console.log(W.white(` 3. Начни с промпта /agentica.init d чате Copilot:
39
+ `)),console.log(W.cyan("Следующие шаги:")),this.options.name)console.log(W.white(` 1. cd ${this.options.name}`));console.log(W.white(" 2. Открой проект в VSCode: code .")),console.log(W.white(` 3. Начни с промпта /agentica.init в чате Copilot:
40
40
  - Опиши свой проект, и стек технологий (после команды)
41
41
  - Agentica подстроится под твои нужды
42
- - А дальще можно запускать /agentica.create или /agentica.change
42
+ - А дальше можно запускать /agentica.create, /agentica.change, /agentica.commit или /agentica.release
43
43
  - И обязательно прочитай и донастрой AGENTS.md
44
44
  `))}}function _z(q){console.error(W.red(`❌ Неверный формат стека: ${q}`)),console.error(W.yellow(" Ожидаемый формат: <lang>/<type>")),console.error(W.yellow(" Примеры: typescript/cli, python/gui")),process.exit(dq)}function Az(q){let z=q.split("/");if(z.length!==2)return null;let[J,Z]=z;if(!J||!Z)return null;return{lang:J,type:Z}}function Oz(){return cq(__dirname,"../..")}function xz(q){return`# Статус Agentica
45
45
 
@@ -13,8 +13,8 @@
13
13
  **Корневой уровень** (`.agentica/` в корне проекта):
14
14
  ```
15
15
  .agentica/
16
- ├── prompts/ # Воркфлоу агентов (init, create, implement, validate)
17
- ├── templates/ # Шаблоны спек (feature, change, architecture)
16
+ ├── prompts/ # Воркфлоу агентов (init, create, tasks, implement, validate, commit, release)
17
+ ├── templates/ # Шаблоны спек (feature, change, architecture, release)
18
18
  ├── product.md # Глобальное продуктовое видение
19
19
  ├── structure.md # Структура и организация репозитория
20
20
  ├── tech.md # Глобальный тех-стек и стандарты
@@ -27,6 +27,7 @@ packages/my-package/.agentica/
27
27
  ├── features/ # Спеки FT-XXXX (новая функциональность)
28
28
  ├── changes/ # Спеки CH-XXXX (изменения существующего кода)
29
29
  ├── architecture/ # Спеки AR-XXXX (архитектурные решения и паттерны)
30
+ ├── release/ # Спеки REL-XXXX (подготовка и выпуск релизов)
30
31
  ├── product.md # Назначение и домен пакета
31
32
  ├── structure.md # Файловая структура пакета
32
33
  ├── tech.md # Стек и паттерны конкретного пакета
@@ -86,7 +87,7 @@ IDE автоматически предоставляет доступ к фак
86
87
  - Консистентность > новизна
87
88
 
88
89
  **4. Следуй процессу**
89
- Каждый воркфлоу Agentica имеет определённые шаги (init → create → tasks → implement → validate). Если пользователь просит сделать что-то масштабное:
90
+ Каждый воркфлоу Agentica имеет определённые шаги (init → create/change → tasks → implement → validate → commit → release). Если пользователь просит сделать что-то масштабное:
90
91
  - Проверь, существует ли связанная спека
91
92
  - Если спеки нет - рекомендуй сначала использовать `/agentica.create`
92
93
  - Не пиши большие фичи "фристайлом" без спеки
@@ -101,6 +102,8 @@ IDE автоматически предоставляет доступ к фак
101
102
  2. Распланируй задачи: `/agentica.tasks --id FT-XXXX`
102
103
  3. Реализуй: `/agentica.implement --id FT-XXXX`
103
104
  4. Валидируй: `/agentica.validate --id FT-XXXX`
105
+ 5. Подготовь коммит: `/agentica.commit`
106
+ 6. Подготовь релиз: `/agentica.release --type patch|minor|major`
104
107
 
105
108
  Это обеспечит:
106
109
  - Правильное планирование архитектуры
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@jakerdy/agentica",
3
- "version": "0.0.2",
3
+ "version": "0.0.4",
4
4
  "description": "Spec-driven framework for agent coding with developer-first approach",
5
5
  "keywords": [
6
6
  "ai",
@@ -39,14 +39,16 @@
39
39
  ],
40
40
  "scripts": {
41
41
  "build": "bun run build.ts",
42
- "prepublishOnly": "bun run build"
42
+ "prepublishOnly": "bun run build",
43
+ "typecheck": "tsc --noEmit"
43
44
  },
44
45
  "engines": {
45
46
  "node": ">=18.0.0"
46
47
  },
47
48
  "devDependencies": {
48
- "typescript": "^5",
49
- "@types/bun": "latest"
49
+ "@biomejs/biome": "^2.4.2",
50
+ "@types/bun": "latest",
51
+ "typescript": "^5"
50
52
  },
51
53
  "dependencies": {
52
54
  "chalk": "^5.6.2",
@@ -0,0 +1,134 @@
1
+ ---
2
+ name: agentica.commit
3
+ description: Безопасная подготовка staged-изменений и создание семантического commit message
4
+ ---
5
+
6
+ ## Ввод пользователя
7
+
8
+ ```text
9
+ $ARGUMENTS
10
+ ```
11
+
12
+ Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
13
+
14
+ ## Цель и принцип работы
15
+
16
+ Твоя задача — подготовить и выполнить коммит в безопасном режиме:
17
+ 1. Добавить изменения в stage.
18
+ 2. Проверить, что в stage нет лишних файлов, секретов и бинарного мусора.
19
+ 3. Сформировать корректный commit message.
20
+ 4. Выполнить `git commit`.
21
+
22
+ Работай строго линейно: **Диагностика → Stage → Проверка содержимого stage → Генерация commit message → Commit → Отчёт**.
23
+
24
+ ## Глобальные запреты (Safety Guards)
25
+
26
+ Останови выполнение и не коммить, если:
27
+ 1. Текущая директория не является git-репозиторием.
28
+ 2. После staging обнаружены потенциальные секреты, и пользователь не подтвердил продолжение.
29
+ 3. В stage есть нежелательные бинарные/сборочные артефакты, и пользователь не подтвердил продолжение.
30
+ 4. В stage нет изменений (пустой коммит не запрошен явно).
31
+
32
+ В случае остановки: объясни причину и покажи, как исправить ситуацию.
33
+
34
+ ## Фаза 1: Диагностика git-контекста
35
+
36
+ 1. Проверь git-контекст:
37
+ - `git rev-parse --is-inside-work-tree`
38
+ 2. Собери текущее состояние:
39
+ - `git status --short`
40
+
41
+ ## Фаза 2: Stage всех изменений
42
+
43
+ 1. Добавь все изменения в stage:
44
+ - `git add -A`
45
+ 2. Проверь staged-список:
46
+ - `git diff --cached --name-status`
47
+
48
+ ## Фаза 3: Проверка stage на риски
49
+
50
+ Если пользователь указал ключ `--skip-checks`, пропусти эту фазу и перейди к генерации commit message.
51
+
52
+ ### 3.1 Поиск мусорных/артефактных файлов
53
+
54
+ Проверь staged-файлы на признаки артефактов и мусора (например):
55
+ - `*.exe`, `*.dll`, `*.dylib`, `*.so`, `*.a`, `*.o`, `*.obj`
56
+ - `*.tgz`, `*.zip`, `*.tar`, `*.gz`, `*.7z`
57
+ - <другие типы не похожие на исходники>
58
+ - фалйы большого размера (например, >5MB), если это не типичные для проекта ассеты.
59
+ - build-output и временные директории (`dist/`, `build/`, `.cache/`, `coverage/`, и т.д.), если они не должны коммититься по правилам проекта.
60
+
61
+ Если найдено:
62
+ 1. Покажи пользователю список подозрительных файлов.
63
+ 2. Предупреди, что эти файлы выглядят как мусор/артефакты/temp.
64
+ 3. Предложи обновить `.gitignore` и убрать лишнее из stage.
65
+ 4. Через `ask_questions` попроси выбрать действие:
66
+ - убрать артефакты из stage и продолжить;
67
+ - убрать и обновить `.gitignore`, затем продолжить;
68
+ - продолжить как есть (только при явном подтверждении пользователя).
69
+
70
+ ### 3.2 Поиск потенциальных секретов
71
+
72
+ Проверь staged-изменения на явные признаки секретов:
73
+ - API keys / tokens / private keys / passwords / connection strings.
74
+ - Паттерны вида `AKIA...`, `ghp_...`, `-----BEGIN PRIVATE KEY-----`, `password=`, `secret=`, `token=`.
75
+
76
+ Если найдено:
77
+ 1. Покажи только безопасный контекст (без полного вывода секрета).
78
+ 2. Останови авто-коммит.
79
+ 3. Через `ask_questions` предложи:
80
+ - удалить/замаскировать секреты и продолжить;
81
+ - если это .env создать .env.example и обновить .gitignore;
82
+ - исключить файл из stage;
83
+ - отменить операцию.
84
+
85
+ ### 3.3 Поиск неуместных фраз и матершины в коде
86
+
87
+ Иногда так бывает, что у разработчика здают нервы, и он пишет в коде нецензурные выражения. Это может быть проблемой, если такие изменения попадут в историю. Поэтому стоит проверять staged-изменения на наличие таких фраз и предупреждать пользователя, сразу предлагая более нейтральные формулировки.
88
+
89
+ По этому:
90
+ - Проверь изменения на матершину и прочие NSFW вещи в коментариях, именах переменных и прочих текстовых изменениях.
91
+ - Если это часть локализации или "ассетов" - ок, пропускаем.
92
+
93
+ ## Фаза 4: Формирование commit message
94
+
95
+ Сформируй сообщение в формате:
96
+
97
+ ```text
98
+ <change_type>: <Short Change Description>
99
+
100
+ Detailed semantic description of changes
101
+ ```
102
+
103
+ Где:
104
+ - `<change_type>` — один из: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `build`, `ci`, `perf`, `revert`.
105
+ - `Short Change Description` — коротко, по сути, в одну строку.
106
+ - `Detailed semantic description` — 2+ строк с ключевыми изменениями (списоком, не файлы, а семантика), мотивацией и влиянием.
107
+
108
+ Правила качества commit message:
109
+ 1. Заголовок до ~72 символов.
110
+ 2. Без абстрактных формулировок вроде "misc updates".
111
+ 3. Опираться только на реально staged изменения.
112
+ 4. Семантические описания вместо конкретных файлов/строк.
113
+ 4. Если staged содержит несколько несвязанных изменений — предложить пользователю разбить на несколько коммитов.
114
+
115
+ ## Фаза 5: Выполнение commit
116
+
117
+ 1. Выполни:
118
+ - `git commit -m "<title>" -m "<body>"`
119
+ 2. Если commit не выполнен (hook/validation failed) — покажи ошибку и предложи шаги исправления.
120
+
121
+ ## Фаза 6: Отчёт пользователю
122
+
123
+ Выдай краткий отчёт:
124
+ 1. Что было добавлено в stage.
125
+ 2. Были ли найдены мусорные файлы/секреты и как решено.
126
+ 3. Итоговый commit message.
127
+ 4. Результат `git commit` (хеш и краткая сводка файлов).
128
+
129
+ ## Требования к качеству
130
+
131
+ 1. Не выводи секреты в открытом виде.
132
+ 2. Не коммить без проверки staged-содержимого.
133
+ 3. Если есть сомнения в корректности набора изменений — спроси пользователя через `ask_questions` перед commit.
134
+ 4. Всегда явно предупреждай о рисках загрязнения истории бинарными артефактами и предлагай обновить `.gitignore`.
@@ -19,7 +19,7 @@ $ARGUMENTS
19
19
  ### Глобальные запреты (Safety Guards)
20
20
 
21
21
  Останови выполнение и не вноси изменения, если:
22
- 1. Запрос требует другого пайплайна (task, implement, refactor, readme), а не инициализации/настройки.
22
+ 1. Запрос требует другого пайплайна (tasks, implement, refactor, readme, commit, release), а не инициализации/настройки.
23
23
  2. Пользователь просит изменить узкую реализацию, несвязанную с настройкой Agentica.
24
24
  3. Входные данные противоречивы.
25
25
  4. Проект **уже инициализирован** (есть `.agentica/` и ключевые файлы), и пользователь не выбрал явный режим обновления.
@@ -33,7 +33,7 @@ $ARGUMENTS
33
33
  ### Группы артефактов
34
34
  1. **[Context]:** `product.md`, `structure.md`, `tech.md`, `status.md`. (Обязательны для любого активного скоупа).
35
35
  2. **[Config]:** Директории `prompts/`, `templates/`. (Только в корне проекта/репозитория).
36
- 3. **[Specs]:** Директории `architecture/`, `changes/`, `features/`. (Только там, где лежит код/пакет).
36
+ 3. **[Specs]:** Директории `architecture/`, `changes/`, `features/`, `release/`. (Только там, где лежит код/пакет).
37
37
 
38
38
  ### Матрица размещения
39
39
 
@@ -87,6 +87,7 @@ $ARGUMENTS
87
87
  5. Обнови **[Config]** в root `.agentica/`:
88
88
  - синхронизируй все файлы в `.agentica/prompts/` с новым набором инструментов;
89
89
  - обязательно проверь `refactor.prompt.md` и `validate.prompt.md` на конкретные команды;
90
+ - обязательно адаптируй `release.prompt.md` под стек и реальные команды релизного пайплайна;
90
91
  - выполни семантический поиск по запуску инструментов и regex-поиск упоминаний legacy-команд (`bun`, `tsc` и т.п.), затем замени их на актуальные.
91
92
  6. Обнови шаблоны в `.agentica/templates/`, чтобы формулировки по сборке, тестам, линтингу и валидации соответствовали реальному техстеку.
92
93
  7. Проверь консистентность: одинаковые команды и правила должны использоваться в `tech.md`, промптах и шаблонах без противоречий.
@@ -110,7 +111,7 @@ $ARGUMENTS
110
111
 
111
112
  Перед выдачей ответа проверь:
112
113
  1. Все файлы из групп **[Context]**, **[Config]**, **[Specs]** существуют на своих местах согласно матрице размещения.
113
- 2. В корне Monorepo **нет** папок `architecture`, `changes`, `features`.
114
+ 2. В корне Monorepo **нет** папок `architecture`, `changes`, `features`, `release`.
114
115
  3. В `status.md` записан актуальный статус.
115
116
  4. Файлы `product/structure/tech` не противоречат друг другу.
116
117
 
@@ -0,0 +1,127 @@
1
+ ---
2
+ name: agentica.release
3
+ description: Подготовка релиза, сборка черновика changelog и предрелизный аудит
4
+ ---
5
+
6
+ ## Ввод пользователя
7
+
8
+ ```text
9
+ $ARGUMENTS
10
+ ```
11
+
12
+ Ты **ОБЯЗАН** учесть ввод пользователя (аргументы и контекст) перед тем как продолжить.
13
+
14
+ ## Цель и принцип работы
15
+
16
+ Твоя задача — подготовить релизный пакет в формате `REL-XXXX`:
17
+ 1. Проверить готовность репозитория к релизу.
18
+ 2. Вычислить новую версию и собрать черновик `Changelog`.
19
+ 3. Сформировать документ релиза по шаблону.
20
+ 4. Выдать отчёт о рисках и командах публикации.
21
+
22
+ Работай строго линейно: **Проверка ветки → Выбор версии → Сбор коммитов → Предрелизный аудит → Генерация REL-документа → Отчёт**.
23
+
24
+ ## Глобальные запреты (Safety Guards)
25
+
26
+ Останови выполнение и не вноси изменения, если:
27
+ 1. Текущая ветка не `main` и не `master`.
28
+ 2. Невозможно определить предыдущий релиз (нет тегов и нет версии в манифестах).
29
+ 3. Репозиторий не является git-репозиторием.
30
+
31
+ В случае остановки: объясни причину, покажи минимальные шаги для исправления и предложи перезапустить `agentica.release`.
32
+
33
+ ## Топология и размещение файлов
34
+
35
+ Документ релиза хранится в:
36
+ - `.agentica/release/REL-XXXX - <Release Name>.md`
37
+
38
+ Шаблон релиза:
39
+ - `.agentica/templates/release/REL-0000 - Release Name.md`
40
+
41
+ ## Фаза 1: Проверка git-контекста
42
+
43
+ 1. Проверь, что репозиторий git и текущая ветка через `run_in_terminal`:
44
+ - `git rev-parse --is-inside-work-tree`
45
+ - `git branch --show-current`
46
+ 2. Если ветка не `main`/`master` — **STOP**.
47
+ 3. Найди предыдущую версию:
48
+ - сначала `git describe --tags --abbrev=0`
49
+ - если тега нет, попробуй получить текущую версию из манифестов (`package.json`, `pyproject.toml`, `Cargo.toml`, и т.д. — по стеку проекта).
50
+
51
+ ## Фаза 2: Вычисление новой версии
52
+
53
+ 1. Спроси пользователя через `ask_questions` тип увеличения версии:
54
+ - `patch`
55
+ - `minor`
56
+ - `major`
57
+ 2. На основе предыдущей версии вычисли новую семантическую версию (`X.Y.Z`).
58
+ 3. Определи новый release id:
59
+ - Найди существующие документы `REL-XXXX` в `.agentica/release/`.
60
+ - Новый ID = max + 1.
61
+
62
+ ## Фаза 3: Сбор changelog по коммитам
63
+
64
+ 1. Собери коммиты с последнего тега до `HEAD`:
65
+ - `git log <prev_tag>..HEAD --pretty=format:"%h|%s|%an|%ad" --date=short`
66
+ - если тега нет: используй разумный диапазон (например, все коммиты текущей ветки).
67
+ 2. Сгруппируй коммиты в черновик changelog:
68
+ - Features
69
+ - Fixes
70
+ - Refactor/Chore
71
+ - Docs/Test/Build
72
+ 3. Пройдись по каждому коммиту и убери шум:
73
+ - merge-коммиты
74
+ - технические коммиты без продуктовой ценности (оставляй в отдельном блоке при необходимости).
75
+
76
+ ## Фаза 4: Предрелизный аудит
77
+
78
+ Проверь и явно зафиксируй статус каждого пункта:
79
+
80
+ 1. Версии в манифестах пакетов совпадают с вычисленной версией.
81
+ 2. Все изменения закоммичены (`git status --porcelain` пустой).
82
+ 3. Код форматируется, линтится, компилируется и собирается (команды брать из `tech.md`, `README.md`, `package.json`/`pyproject.toml`).
83
+ 4. Dry-run публикации работает (если применимо стеку):
84
+ - npm: `npm publish --dry-run`
85
+ - bun: `bun publish --dry-run`
86
+ - python: `python -m build` + `twine check dist/*` (или эквивалент)
87
+ 5. Окружение для публикации настроено корректно:
88
+ - наличие токенов/credentials (без вывода секретов)
89
+ - корректный registry/repository endpoint
90
+
91
+ Если проверка неприменима к стеку — отмечай как `N/A` с коротким объяснением.
92
+
93
+ ## Фаза 5: Генерация REL-документа
94
+
95
+ 1. Создай новый файл по шаблону:
96
+ - `.agentica/release/REL-XXXX - <Release Name>.md`
97
+ 2. Заполни:
98
+ - версию (`previous` → `next`)
99
+ - дату
100
+ - pre-release checklist
101
+ - changelog draft
102
+ - stack-oriented release plan
103
+ - блок рисков и блокеров
104
+
105
+ ## Фаза 6: Отчёт пользователю
106
+
107
+ Выдай короткий отчёт:
108
+ 1. Какая версия рассчитана (`from` → `to`).
109
+ 2. Где создан REL-документ.
110
+ 3. Какие проверки пройдены/провалены/неприменимы.
111
+ 4. Точный список команд, которые пользователь должен выполнить для публикации релиза.
112
+
113
+ ## Фаза 7: Помощь в публикации (по запросу)
114
+
115
+ Предложи пользователю помощь в публикации релиза. Если он согласится, выполни все необходимые действия перед публикацией:
116
+ 1. Апнуть версии в манифестах.
117
+ 2. Закоммитить изменения с сообщением `chore(release): prepare vX.Y.Z`.
118
+ 3. Создать тег `vX.Y.Z` и отправить его в origin.
119
+ 4. Обновить Badges в `README.md` (если есть).
120
+ 5. Написать финальную команду для публикации релиза и дать краткие инструкции по её запуску.
121
+
122
+ ## Требования к качеству
123
+
124
+ 1. Версия должна быть semver-валидной и согласованной между документом и манифестами.
125
+ 2. Changelog должен строиться только из реальных коммитов диапазона релиза.
126
+ 3. Если есть блокеры, команды публикации всё равно показать, но пометить как «не запускать до устранения блокеров».
127
+ 4. Никакие секреты не выводить в отчёт.
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич (требования, UX, acceptance)
10
10
  │ ├── changes/ # Журнал изменений, миграции, заметки по релизам
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR), схемы, компромиссы
12
13
  │ ├── product.md # Описание проекта с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич и UX сценариев
10
10
  │ ├── changes/ # Журнал изменений и миграции
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание проекта с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич (контракты, примеры, UX)
10
10
  │ ├── changes/ # Изменения, миграции, заметки по версиям
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание проекта с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -13,6 +13,7 @@
13
13
  ├── packages/ # Набор Python пакетов (каждый со своим `pyproject.toml`)
14
14
  │ ├── package1/ # Пример пакета
15
15
  │ │ ├── .agentica/ # Документы Agentica, относящиеся к этому пакету
16
+ │ │ │ ├── release/ # Релизные документы пакета (REL-XXXX)
16
17
  │ │ ├── <package_name>/ # Исходный код пакета
17
18
  │ │ ├── tests/ # Тесты пакета
18
19
  │ │ └── pyproject.toml # Зависимости и конфигурация инструментов пакета
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич (команды, UX, контракты)
10
10
  │ ├── changes/ # Журнал изменений (breaking changes, миграции)
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание CLI с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич (контракты API, примеры)
10
10
  │ ├── changes/ # Изменения, миграции, заметки по версиям
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание библиотеки с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -13,6 +13,7 @@
13
13
  ├── packages/ # Пакеты монорепозитория
14
14
  │ ├── package1/ # Пример пакета
15
15
  │ │ ├── .agentica/ # Документы Agentica, относящиеся к пакету
16
+ │ │ │ ├── release/ # Релизные документы пакета (REL-XXXX)
16
17
  │ │ ├── src/ # Исходный код пакета
17
18
  │ │ ├── tests/ # Тесты пакета
18
19
  │ │ └── ... # Прочие файлы пакета (конфиги, assets)
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания фич и контрактов API
10
10
  │ ├── changes/ # Изменения и миграции
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание сервиса с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -8,6 +8,7 @@
8
8
  │ ├── templates/ # Шаблоны для фич/изменений/архитектурных решений
9
9
  │ ├── features/ # Описания UI/UX фич и сценариев
10
10
  │ ├── changes/ # Изменения, миграции, заметки по релизам
11
+ │ ├── release/ # Релизные документы (REL-XXXX)
11
12
  │ ├── architecture/ # Архитектурные решения (ADR)
12
13
  │ ├── product.md # Описание SPA с продуктовой точки зрения
13
14
  │ ├── structure.md # Этот файл: структура репозитория
@@ -0,0 +1,81 @@
1
+ # REL-0000 - Release Name
2
+
3
+ ## Сводка релиза
4
+
5
+ - **Дата:** YYYY-MM-DD
6
+ - **Предыдущая версия:** vX.Y.Z
7
+ - **Новая версия:** vX.Y.Z
8
+ - **Тип релиза:** patch | minor | major
9
+ - **Тег:** vX.Y.Z
10
+
11
+ ## Чеклист предрелизных работ
12
+
13
+ - [ ] Активная ветка: `main` или `master`
14
+ - [ ] Все изменения закоммичены (`git status` чистый)
15
+ - [ ] Версии в манифестах синхронизированы с тегом релиза
16
+ - [ ] Форматирование проходит успешно
17
+ - [ ] Линт проходит успешно
18
+ - [ ] Компиляция/типизация проходит успешно
19
+ - [ ] Сборка проходит успешно
20
+ - [ ] Dry-run публикации прошёл успешно (если применимо)
21
+ - [ ] Публикационное окружение и credentials проверены
22
+
23
+ ## Черновик Changelog для текущей версии
24
+
25
+ ### Features
26
+
27
+ - ...
28
+
29
+ ### Fixes
30
+
31
+ - ...
32
+
33
+ ### Refactor / Chore
34
+
35
+ - ...
36
+
37
+ ### Docs / Tests / Build
38
+
39
+ - ...
40
+
41
+ ### Breaking Changes (если есть)
42
+
43
+ - ...
44
+
45
+ ## План действий (стеко-ориентированный)
46
+
47
+ ### TypeScript / Node / Bun
48
+
49
+ 1. Обновить версии в `package.json` (и package-манифестах, если monorepo).
50
+ 2. Выполнить quality gate (`format`, `lint`, `typecheck`, `test`, `build`).
51
+ 3. Проверить dry-run публикации (`npm publish --dry-run` или `bun publish --dry-run`).
52
+ 4. Создать тег релиза и отправить его в origin.
53
+ 5. Выполнить реальную публикацию в registry.
54
+
55
+ ### Python
56
+
57
+ 1. Обновить версию в `pyproject.toml` (и пакетах monorepo).
58
+ 2. Выполнить quality gate (`format`, `lint`, `typecheck`, `test`).
59
+ 3. Собрать артефакты (`python -m build`) и проверить (`twine check dist/*`).
60
+ 4. Создать тег релиза и отправить его в origin.
61
+ 5. Опубликовать пакет (`twine upload dist/*` или эквивалент).
62
+
63
+ ### Другое / Custom
64
+
65
+ 1. Зафиксировать команды из `tech.md` и `README.md`.
66
+ 2. Проверить dry-run и каналы публикации, применимые к стеку.
67
+ 3. Выполнить публикацию по внутреннему release pipeline.
68
+
69
+ ## Блокеры и риски
70
+
71
+ - [ ] Блокер 1: ...
72
+ - [ ] Блокер 2: ...
73
+
74
+ ## Команды для публикации (заполняется по результатам аудита)
75
+
76
+ ```bash
77
+ # Пример (адаптируется под стек проекта)
78
+ # git tag vX.Y.Z
79
+ # git push origin vX.Y.Z
80
+ # npm publish
81
+ ```