vdv

Name: vdv
Author: TserenTserenov

42stars122forks

How to install vdv?

tserentserenov/fmt-exocortex-template/vdv

$npx -y skills add TserenTserenov/FMT-exocortex-template --skill vdv

Installs into the current project.

Summary

ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit).

Files · 1

View on GitHub

SKILL.md

1	# ВДВ-скилл (Вход·Действие·Выход)
2
3	> Service Clause: DP.SC.052
4	> Источник принципов: PD.METHOD.008 §174-230 (каскад v9 стратегирования как эталонный тест-кейс)
5
6	Выполни: $ARGUMENTS
7
8	---
9
10	## When to use
11
12	ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit).
13
14	## Принципы ВДВ (эталон проверки)
15
16	Шесть инвариантов, по которым работают оба режима:
17
18	\| # \| Принцип \| Формулировка \| Тест нарушения \|
19	\|---\|---------\|--------------\|----------------\|
20	\| 1 \| Триада на каждой стадии \| У стадии есть Вход, Действие, Выход. Нет одного — неполно. \| Одно из трёх полей отсутствует или пусто \|
21	\| 2 \| Сцепление выход→вход \| Выход стадии должен стать входом одной из следующих. \| Выход стадии N не появляется во Входе ни одной последующей стадии (и не помечен «внешний» / «обещание контура») \|
22	\| 3 \| Инвариант входа \| Вход = выходы предыдущих + стабильные документы + «план для сравнения». Артефакт без производителя и без пометки «внешний» — сигнал пропущенной стадии. \| Во Входе стадии N стоит артефакт, которого нет в Выходе ни одной предыдущей стадии и нет пометки `(внешний)` \|
23	\| 4 \| Двусторонняя трассируемость \| У каждого артефакта есть производитель и потребитель. Без потребителя — лишний. Без производителя и без «внешний» — пропущенная стадия. \| Артефакт в Выходе без потребителя во Входах следующих стадий (и не является обещанием контура) \|
24	\| 5 \| Carry-over \| Незавершённое переносится во Вход следующей итерации того же контура. \| Повторяемый процесс (ритм > 1 итерации): вход первой стадии не включает `carry-over от предыдущей итерации` \|
25	\| 6 \| Антипустышка \| Стадия имеет прямую или косвенную трассировку к обещанию контура. Убрать стадию → нарушится ли обещание? Если нет — кандидат-пустышка. \| Проверка: убери стадию — нарушится ли обещание контура? Нет → ❌ кандидат-пустышка. Стадия не трассируется ни напрямую (выход = обещание), ни косвенно (цепочка выходов ведёт к обещанию) \|
26
27	> Особые случаи принципа 5: одноитерационный процесс (однократный, без цикла) — принцип 5 неприменим, ставь ⏸ с пояснением.
28	> Особые случаи принципа 6: обещание контура неизвестно — ⚠️ + запрос уточнения.
29
30	---
31
32	## Algorithm
33
34	## Режим `/vdv build` — Генерация
35
36	### Алгоритм (подход C)
37
38	### Шаг 1. Понять деятельность
39
40	Прочитать описание деятельности из $ARGUMENTS. Если описание слишком краткое (<1 предложения или нет ни одного результата/выхода) — запросить уточнение:
41
42	> «Опишите деятельность подробнее: что происходит, какой основной результат, есть ли повторяющийся ритм?»
43
44	### Шаг 2. Выделить стадии (быстрый черновик)
45
46	Из описания вывести предположительный набор стадий. Правила:
47	- Каждая стадия = одно смысловое действие с проверяемым артефактом на выходе
48	- Первая стадия: входы помечай как `(внешний)` если они не производятся внутри процесса
49	- Ритм указывать если известен из контекста, иначе `—`
50	- Формат: compact markdown-таблица, колонки строго в порядке: `# \| Стадия \| Ритм \| Вход \| Действие \| Выход`
51
52	### Шаг 3. Self-audit принципы 1-4
53
54	Сразу после черновика прогнать принципы 1-4 по построенной таблице. Показать:
55
56	```
57	Предварительный аудит (принципы 1-4):
58	П1 (триада): ✅ / ⚠️ / ❌ — <что нашёл>
59	П2 (сцепление): ✅ / ⚠️ / ❌ — <что нашёл>
60	П3 (инвариант входа): ✅ / ⚠️ / ❌ — <что нашёл>
61	П4 (трассируемость): ✅ / ⚠️ / ❌ — <что нашёл>
62	П5 (carry-over): ⏸ проверится после утверждения структуры
63	П6 (антипустышка): ⏸ проверится после утверждения обещания контура
64	```
65
66	### Шаг 4. Inline трассируемость
67
68	После таблицы ВДВ вывести компактный блок:
69
70	```
71	\| Артефакт \| Произведён на стадии \| Потребляется на стадиях \|
72	\|----------\|----------------------\|------------------------\|
73	\| Название \| N. Стадия \| M. Стадия / → обещание контура / → carry-over (следующая итерация) \|
74	```
75
76	Висячие артефакты (без потребителя внутри контура) помечать:
77	- `→ обещание контура` — терминальный выход, является обещанием
78	- `→ carry-over (следующая итерация)` — уходит в следующий цикл процесса (П5)
79	- `→ ❌ потребитель не найден` — нарушение П4
80
81	### Шаг 5. Уточнение и финальный аудит
82
83	После правок пользователя — запустить полный аудит (шаги 1-5 ре

People who liked this also viewed

6 picks

Type

vdv

42stars122forks

View on GitHub

How to install vdv?

tserentserenov/fmt-exocortex-template/vdv

$npx -y skills add TserenTserenov/FMT-exocortex-template --skill vdv

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ВДВ-скилл (Вход·Действие·Выход)
2
3	> Service Clause: DP.SC.052
4	> Источник принципов: PD.METHOD.008 §174-230 (каскад v9 стратегирования как эталонный тест-кейс)
5
6	Выполни: $ARGUMENTS
7
8	---
9
10	## When to use
11
12	ВДВ-скилл — генератор и аудитор описания стадийного процесса по 6 принципам Вход·Действие·Выход. Используй для построения описания нового процесса (/vdv build) или проверки готового описания (/vdv audit).
13
14	## Принципы ВДВ (эталон проверки)
15
16	Шесть инвариантов, по которым работают оба режима:
17
18	\| # \| Принцип \| Формулировка \| Тест нарушения \|
19	\|---\|---------\|--------------\|----------------\|
20	\| 1 \| Триада на каждой стадии \| У стадии есть Вход, Действие, Выход. Нет одного — неполно. \| Одно из трёх полей отсутствует или пусто \|
21	\| 2 \| Сцепление выход→вход \| Выход стадии должен стать входом одной из следующих. \| Выход стадии N не появляется во Входе ни одной последующей стадии (и не помечен «внешний» / «обещание контура») \|
22	\| 3 \| Инвариант входа \| Вход = выходы предыдущих + стабильные документы + «план для сравнения». Артефакт без производителя и без пометки «внешний» — сигнал пропущенной стадии. \| Во Входе стадии N стоит артефакт, которого нет в Выходе ни одной предыдущей стадии и нет пометки `(внешний)` \|
23	\| 4 \| Двусторонняя трассируемость \| У каждого артефакта есть производитель и потребитель. Без потребителя — лишний. Без производителя и без «внешний» — пропущенная стадия. \| Артефакт в Выходе без потребителя во Входах следующих стадий (и не является обещанием контура) \|
24	\| 5 \| Carry-over \| Незавершённое переносится во Вход следующей итерации того же контура. \| Повторяемый процесс (ритм > 1 итерации): вход первой стадии не включает `carry-over от предыдущей итерации` \|
25	\| 6 \| Антипустышка \| Стадия имеет прямую или косвенную трассировку к обещанию контура. Убрать стадию → нарушится ли обещание? Если нет — кандидат-пустышка. \| Проверка: убери стадию — нарушится ли обещание контура? Нет → ❌ кандидат-пустышка. Стадия не трассируется ни напрямую (выход = обещание), ни косвенно (цепочка выходов ведёт к обещанию) \|
26
27	> Особые случаи принципа 5: одноитерационный процесс (однократный, без цикла) — принцип 5 неприменим, ставь ⏸ с пояснением.
28	> Особые случаи принципа 6: обещание контура неизвестно — ⚠️ + запрос уточнения.
29
30	---
31
32	## Algorithm
33
34	## Режим `/vdv build` — Генерация
35
36	### Алгоритм (подход C)
37
38	### Шаг 1. Понять деятельность
39
40	Прочитать описание деятельности из $ARGUMENTS. Если описание слишком краткое (<1 предложения или нет ни одного результата/выхода) — запросить уточнение:
41
42	> «Опишите деятельность подробнее: что происходит, какой основной результат, есть ли повторяющийся ритм?»
43
44	### Шаг 2. Выделить стадии (быстрый черновик)
45
46	Из описания вывести предположительный набор стадий. Правила:
47	- Каждая стадия = одно смысловое действие с проверяемым артефактом на выходе
48	- Первая стадия: входы помечай как `(внешний)` если они не производятся внутри процесса
49	- Ритм указывать если известен из контекста, иначе `—`
50	- Формат: compact markdown-таблица, колонки строго в порядке: `# \| Стадия \| Ритм \| Вход \| Действие \| Выход`
51
52	### Шаг 3. Self-audit принципы 1-4
53
54	Сразу после черновика прогнать принципы 1-4 по построенной таблице. Показать:
55
56	```
57	Предварительный аудит (принципы 1-4):
58	П1 (триада): ✅ / ⚠️ / ❌ — <что нашёл>
59	П2 (сцепление): ✅ / ⚠️ / ❌ — <что нашёл>
60	П3 (инвариант входа): ✅ / ⚠️ / ❌ — <что нашёл>
61	П4 (трассируемость): ✅ / ⚠️ / ❌ — <что нашёл>
62	П5 (carry-over): ⏸ проверится после утверждения структуры
63	П6 (антипустышка): ⏸ проверится после утверждения обещания контура
64	```
65
66	### Шаг 4. Inline трассируемость
67
68	После таблицы ВДВ вывести компактный блок:
69
70	```
71	\| Артефакт \| Произведён на стадии \| Потребляется на стадиях \|
72	\|----------\|----------------------\|------------------------\|
73	\| Название \| N. Стадия \| M. Стадия / → обещание контура / → carry-over (следующая итерация) \|
74	```
75
76	Висячие артефакты (без потребителя внутри контура) помечать:
77	- `→ обещание контура` — терминальный выход, является обещанием
78	- `→ carry-over (следующая итерация)` — уходит в следующий цикл процесса (П5)
79	- `→ ❌ потребитель не найден` — нарушение П4
80
81	### Шаг 5. Уточнение и финальный аудит
82
83	После правок пользователя — запустить полный аудит (шаги 1-5 ре

People who liked this also viewed

6 picks

Type