@x0rium/devkit-cli 0.5.0 → 0.6.0
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/dist/index.js +4 -1
- package/dist/index.js.map +1 -1
- package/dist/scaffold.d.ts +1 -0
- package/dist/scaffold.d.ts.map +1 -1
- package/dist/scaffold.js +42 -4
- package/dist/scaffold.js.map +1 -1
- package/package.json +3 -2
- package/skills/arch-kit/README.md +195 -0
- package/skills/arch-kit/SKILL.md +128 -0
- package/skills/arch-kit/references/adr.md +25 -0
- package/skills/arch-kit/references/impact.md +13 -0
- package/skills/arch-kit/references/invariants.md +9 -0
- package/skills/arch-kit/references/investigation.md +37 -0
- package/skills/arch-kit/references/rfc.md +36 -0
- package/skills/devkit-init/SKILL.md +99 -0
- package/skills/devkit-init/references/brownfield.md +147 -0
- package/skills/devkit-init/references/greenfield.md +44 -0
- package/skills/devkit-init/references/upgrade.md +103 -0
- package/skills/product-kit/README.md +135 -0
- package/skills/product-kit/SKILL.md +101 -0
- package/skills/product-kit/references/roadmap.md +16 -0
- package/skills/product-kit/references/users.md +14 -0
- package/skills/product-kit/references/ux_invariants.md +8 -0
- package/skills/qa-kit/README.md +188 -0
- package/skills/qa-kit/SKILL.md +113 -0
- package/skills/qa-kit/references/assumption_checks.md +10 -0
- package/skills/qa-kit/references/coverage_map.md +19 -0
- package/skills/qa-kit/references/test_contracts.md +10 -0
- package/skills/research-kit/README.md +139 -0
- package/skills/research-kit/SKILL.md +84 -0
- package/skills/research-kit/references/assumptions.md +9 -0
- package/skills/research-kit/references/feasibility.md +15 -0
- package/skills/research-kit/references/market.md +13 -0
- package/skills/research-kit/references/unknowns.md +9 -0
- package/skills/spec-kit/README.md +139 -0
- package/skills/spec-kit/SKILL.md +108 -0
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# QAKit
|
|
2
|
+
|
|
3
|
+
> Уровень 5. "Работает ли это как мы решили?"
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Ключевая идея
|
|
8
|
+
|
|
9
|
+
Обычный QA проверяет код против спек. QAKit проверяет систему против **всех уровней принятых решений**. Тест который упал — это не просто баг. Это сигнал о том на каком уровне решение было неверным.
|
|
10
|
+
|
|
11
|
+
```
|
|
12
|
+
QAKit проверяет:
|
|
13
|
+
|
|
14
|
+
против SpecKit: код делает что написано в спеке?
|
|
15
|
+
против ArchKit: система соблюдает технические инварианты?
|
|
16
|
+
против ProductKit: продукт решает проблему пользователя?
|
|
17
|
+
против ResearchKit: assumptions оказались верны?
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Входные артефакты
|
|
23
|
+
|
|
24
|
+
```
|
|
25
|
+
.devkit/arch/invariants.md → test_contracts.md
|
|
26
|
+
.devkit/product/ux_invariants.md → ux_test_contracts.md
|
|
27
|
+
.devkit/research/assumptions.md → assumption_checks.md
|
|
28
|
+
.specify/specs/ → spec coverage
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## Фазы
|
|
34
|
+
|
|
35
|
+
### Phase 1: Contract Generation
|
|
36
|
+
```
|
|
37
|
+
Из каждого инварианта генерируется тест-контракт:
|
|
38
|
+
- что проверяем
|
|
39
|
+
- как проверяем
|
|
40
|
+
- что является нарушением
|
|
41
|
+
- критичность нарушения
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
### Phase 2: Coverage Analysis
|
|
45
|
+
```
|
|
46
|
+
Карта покрытия:
|
|
47
|
+
- какие инварианты покрыты тестами
|
|
48
|
+
- какие инварианты не покрыты (технический долг)
|
|
49
|
+
- какие assumptions проверены в реальности
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
### Phase 3: Assumption Validation
|
|
53
|
+
```
|
|
54
|
+
Проверка что assumptions из ResearchKit
|
|
55
|
+
оказались верны в реальной системе.
|
|
56
|
+
|
|
57
|
+
Если assumption отклонён реальностью →
|
|
58
|
+
эскалация в ResearchKit для пересмотра.
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## Эскалация
|
|
64
|
+
|
|
65
|
+
### Логика эскалации упавшего теста
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
Тест упал
|
|
69
|
+
↓
|
|
70
|
+
AI анализирует: что именно нарушено?
|
|
71
|
+
↓
|
|
72
|
+
┌─────────────────────────────────────────────┐
|
|
73
|
+
│ Баг реализации? │
|
|
74
|
+
│ Код не соответствует спеке │
|
|
75
|
+
│ → фикс в SpecKit, не эскалируем │
|
|
76
|
+
└─────────────────────────────────────────────┘
|
|
77
|
+
↓ нет
|
|
78
|
+
┌─────────────────────────────────────────────┐
|
|
79
|
+
│ Нарушен технический инвариант? │
|
|
80
|
+
│ Система не выполняет архитектурную гарантию │
|
|
81
|
+
│ → Investigation в ArchKit │
|
|
82
|
+
└─────────────────────────────────────────────┘
|
|
83
|
+
↓ нет
|
|
84
|
+
┌─────────────────────────────────────────────┐
|
|
85
|
+
│ Нарушен UX инвариант? │
|
|
86
|
+
│ Система работает но неудобна / непонятна │
|
|
87
|
+
│ → Product Blocker в ProductKit │
|
|
88
|
+
└─────────────────────────────────────────────┘
|
|
89
|
+
↓ нет
|
|
90
|
+
┌─────────────────────────────────────────────┐
|
|
91
|
+
│ Отклонён assumption из ResearchKit? │
|
|
92
|
+
│ Реальность не совпала с предположением │
|
|
93
|
+
│ → ResearchKit revision │
|
|
94
|
+
└─────────────────────────────────────────────┘
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Артефакты
|
|
100
|
+
|
|
101
|
+
### test_contracts.md
|
|
102
|
+
```markdown
|
|
103
|
+
# Test Contracts
|
|
104
|
+
|
|
105
|
+
## TC-I1: [название инварианта]
|
|
106
|
+
INVARIANT: I1 из invariants.md
|
|
107
|
+
WHAT: что проверяем
|
|
108
|
+
HOW: метод проверки (unit / integration / e2e / manual)
|
|
109
|
+
VIOLATION: что считается нарушением
|
|
110
|
+
CRITICALITY: blocker / major / minor
|
|
111
|
+
COVERAGE: covered / not-covered
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### ux_test_contracts.md
|
|
115
|
+
```markdown
|
|
116
|
+
# UX Test Contracts
|
|
117
|
+
|
|
118
|
+
## TC-U1: [название UX инварианта]
|
|
119
|
+
INVARIANT: U1 из ux_invariants.md
|
|
120
|
+
SCENARIO: пользовательский сценарий для проверки
|
|
121
|
+
WHAT: что наблюдаем
|
|
122
|
+
VIOLATION: что считается нарушением
|
|
123
|
+
METHOD: usability test / metric / manual review
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
### assumption_checks.md
|
|
127
|
+
```markdown
|
|
128
|
+
# Assumption Validation
|
|
129
|
+
|
|
130
|
+
## AC-A1: [название assumption]
|
|
131
|
+
ASSUMPTION: A1 из assumptions.md
|
|
132
|
+
ORIGINAL_STATEMENT: что предполагали
|
|
133
|
+
VALIDATION_METHOD: как проверили
|
|
134
|
+
RESULT: confirmed / rejected / partially-confirmed
|
|
135
|
+
FINDING: что обнаружили
|
|
136
|
+
ESCALATION: none / ResearchKit revision needed
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
### coverage_map.md
|
|
140
|
+
```markdown
|
|
141
|
+
# Coverage Map
|
|
142
|
+
|
|
143
|
+
## Technical Invariants Coverage
|
|
144
|
+
| Инвариант | Контракт | Статус | Метод |
|
|
145
|
+
|----------|---------|--------|-------|
|
|
146
|
+
| I1 | TC-I1 | ✅ | unit |
|
|
147
|
+
| I2 | TC-I2 | ❌ | - |
|
|
148
|
+
|
|
149
|
+
## UX Invariants Coverage
|
|
150
|
+
...
|
|
151
|
+
|
|
152
|
+
## Assumptions Validation
|
|
153
|
+
...
|
|
154
|
+
|
|
155
|
+
## Uncovered (технический долг)
|
|
156
|
+
...
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
### escalations/
|
|
160
|
+
```
|
|
161
|
+
ESC-XXX.md ← история каждой эскалации
|
|
162
|
+
← что нашли, на какой уровень эскалировали, решение
|
|
163
|
+
```
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## Переход к Production
|
|
168
|
+
|
|
169
|
+
**ALLOWED** когда:
|
|
170
|
+
- все BLOCKER test contracts покрыты
|
|
171
|
+
- нет open эскалаций blocker уровня
|
|
172
|
+
- coverage_map показывает покрытие критических инвариантов
|
|
173
|
+
|
|
174
|
+
**BLOCKED** когда:
|
|
175
|
+
- есть непокрытые BLOCKER контракты
|
|
176
|
+
- есть open эскалации blocker уровня
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Команды
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
/qa init ← генерация контрактов из инвариантов
|
|
184
|
+
/qa coverage ← анализ текущего покрытия
|
|
185
|
+
/qa check-assumptions ← валидация assumptions против реальности
|
|
186
|
+
/qa escalate "описание" ← ручная эскалация
|
|
187
|
+
/qa status ← можно ли в production
|
|
188
|
+
```
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: qa-kit
|
|
3
|
+
description: DevKit Level 5. Use after implementation to verify the system against all levels of decisions: specs, technical invariants, UX invariants, and research assumptions. Generates test contracts from invariants. Escalates failures to the correct DevKit level — not just bug reports, but signals about where a decision was wrong.
|
|
4
|
+
license: MIT
|
|
5
|
+
metadata:
|
|
6
|
+
author: devkit
|
|
7
|
+
version: "1.0"
|
|
8
|
+
layer: "5-of-5"
|
|
9
|
+
prev: spec-kit
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# QAKit — Level 5: "Does it work the way we decided?"
|
|
13
|
+
|
|
14
|
+
You are operating in QAKit phase. Your job is not just to find bugs — it is to verify the system against every level of decisions made in DevKit.
|
|
15
|
+
|
|
16
|
+
## Your Role
|
|
17
|
+
|
|
18
|
+
- Generate test contracts from invariants (not from code)
|
|
19
|
+
- Map coverage: which invariants are tested, which are not
|
|
20
|
+
- Validate that research assumptions held in reality
|
|
21
|
+
- Escalate failures to the correct DevKit level
|
|
22
|
+
- Distinguish between a bug in code and a wrong decision upstream
|
|
23
|
+
|
|
24
|
+
## CRITICAL PRINCIPLE
|
|
25
|
+
|
|
26
|
+
A failing test is a signal, not just an error. The question is not only "what broke" but "at which level was the decision wrong":
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
Code doesn't match spec? → fix in SpecKit (no escalation)
|
|
30
|
+
System violates invariant? → Investigation in ArchKit
|
|
31
|
+
System works but feels wrong? → ProductKit investigation
|
|
32
|
+
Assumption proved false? → ResearchKit revision
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
## Phases
|
|
36
|
+
|
|
37
|
+
### Phase 1: Contract Generation
|
|
38
|
+
Read `.devkit/arch/invariants.md` and `.devkit/product/ux_invariants.md`.
|
|
39
|
+
For each invariant, generate a test contract:
|
|
40
|
+
- What to check
|
|
41
|
+
- How to check it (unit / integration / e2e / manual)
|
|
42
|
+
- What constitutes a violation
|
|
43
|
+
- Criticality: blocker / major / minor
|
|
44
|
+
|
|
45
|
+
Save to `.devkit/qa/test_contracts.md`.
|
|
46
|
+
|
|
47
|
+
### Phase 2: Coverage Analysis
|
|
48
|
+
Map every invariant to its test contract.
|
|
49
|
+
Identify uncovered invariants — these are explicit technical debt.
|
|
50
|
+
Save to `.devkit/qa/coverage_map.md`.
|
|
51
|
+
|
|
52
|
+
### Phase 3: Assumption Validation
|
|
53
|
+
Read `.devkit/research/assumptions.md`.
|
|
54
|
+
For each assumption, check whether reality confirmed or rejected it.
|
|
55
|
+
Rejected assumptions → escalate to ResearchKit.
|
|
56
|
+
Save findings to `.devkit/qa/assumption_checks.md`.
|
|
57
|
+
|
|
58
|
+
## Artifacts to Produce
|
|
59
|
+
|
|
60
|
+
Read templates from:
|
|
61
|
+
- [Test contracts template](references/test_contracts.md)
|
|
62
|
+
- [Coverage map template](references/coverage_map.md)
|
|
63
|
+
- [Assumption checks template](references/assumption_checks.md)
|
|
64
|
+
|
|
65
|
+
Save to `.devkit/qa/`.
|
|
66
|
+
|
|
67
|
+
## Escalation Logic
|
|
68
|
+
|
|
69
|
+
When a test fails or a problem is found:
|
|
70
|
+
|
|
71
|
+
### Step 1: What exactly failed?
|
|
72
|
+
Read the failing test contract. What invariant or spec does it cover?
|
|
73
|
+
|
|
74
|
+
### Step 2: Why did it fail?
|
|
75
|
+
```
|
|
76
|
+
Is this a code bug (code ≠ spec)?
|
|
77
|
+
→ Fix in SpecKit. No escalation needed.
|
|
78
|
+
|
|
79
|
+
Does the code match the spec but the spec violates an invariant?
|
|
80
|
+
→ Investigation in ArchKit. Open INV-XXX.
|
|
81
|
+
|
|
82
|
+
Does everything work technically but the user experience is wrong?
|
|
83
|
+
→ Product Blocker in ProductKit.
|
|
84
|
+
|
|
85
|
+
Did a research assumption prove false in production?
|
|
86
|
+
→ ResearchKit revision.
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
### Step 3: Document the escalation
|
|
90
|
+
Create `.devkit/qa/escalations/ESC-XXX.md`:
|
|
91
|
+
- What was found
|
|
92
|
+
- Which level it escalated to
|
|
93
|
+
- What decision was triggered
|
|
94
|
+
- Resolution
|
|
95
|
+
|
|
96
|
+
## Gate: Ready for Production?
|
|
97
|
+
|
|
98
|
+
ALLOWED when:
|
|
99
|
+
- All BLOCKER test contracts pass
|
|
100
|
+
- No open escalations of blocker severity
|
|
101
|
+
- Coverage map shows all `must` invariants covered
|
|
102
|
+
|
|
103
|
+
BLOCKED when:
|
|
104
|
+
- Any BLOCKER contract fails
|
|
105
|
+
- Open blocker-level escalation exists
|
|
106
|
+
|
|
107
|
+
## Continuous QA
|
|
108
|
+
|
|
109
|
+
QAKit is not a one-time gate. It runs:
|
|
110
|
+
- After each SpecKit implementation batch
|
|
111
|
+
- After each RFC resolution (re-verify affected invariants)
|
|
112
|
+
- After each Investigation resolution
|
|
113
|
+
- Before any production deployment
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Assumption Validation Template
|
|
2
|
+
|
|
3
|
+
## AC-[A_N]: [assumption name]
|
|
4
|
+
SOURCE: [A1 from .devkit/research/assumptions.md]
|
|
5
|
+
ORIGINAL_STATEMENT: what we assumed
|
|
6
|
+
VALIDATION_METHOD: how we checked this
|
|
7
|
+
RESULT: confirmed / rejected / partially-confirmed
|
|
8
|
+
FINDING: what we actually found
|
|
9
|
+
ESCALATION: none / ResearchKit revision needed
|
|
10
|
+
IMPACT_IF_REJECTED: what changes if this assumption was wrong
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Coverage Map Template
|
|
2
|
+
|
|
3
|
+
## Technical Invariants
|
|
4
|
+
| Invariant | Contract | Status | Method | Criticality |
|
|
5
|
+
|----------|---------|--------|--------|-------------|
|
|
6
|
+
| I1 | TC-I1 | ✅ covered | unit | blocker |
|
|
7
|
+
| I2 | TC-I2 | ❌ not covered | — | major |
|
|
8
|
+
|
|
9
|
+
## UX Invariants
|
|
10
|
+
| Invariant | Contract | Status | Method | Criticality |
|
|
11
|
+
|----------|---------|--------|--------|-------------|
|
|
12
|
+
|
|
13
|
+
## Uncovered Invariants (Technical Debt)
|
|
14
|
+
[List invariants with no test contract — explicit debt, not hidden]
|
|
15
|
+
|
|
16
|
+
## Coverage Summary
|
|
17
|
+
BLOCKER invariants covered: N/M
|
|
18
|
+
MAJOR invariants covered: N/M
|
|
19
|
+
OVERALL: [percentage or status]
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Test Contracts Template
|
|
2
|
+
|
|
3
|
+
## TC-[I_N or U_N]: [invariant name]
|
|
4
|
+
SOURCE_INVARIANT: [I1 from invariants.md / U1 from ux_invariants.md]
|
|
5
|
+
WHAT: what we are checking
|
|
6
|
+
HOW: unit / integration / e2e / manual
|
|
7
|
+
VIOLATION: what counts as a failure
|
|
8
|
+
CRITICALITY: blocker / major / minor
|
|
9
|
+
COVERAGE: covered / not-covered
|
|
10
|
+
ESCALATION_LEVEL: SpecKit / ArchKit / ProductKit / ResearchKit
|
|
@@ -0,0 +1,139 @@
|
|
|
1
|
+
# ResearchKit
|
|
2
|
+
|
|
3
|
+
> Уровень 1. "Возможно ли это вообще?"
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Когда использовать
|
|
8
|
+
|
|
9
|
+
- у тебя есть идея которую никто ещё не делал
|
|
10
|
+
- не знаешь существуют ли аналоги
|
|
11
|
+
- не знаешь технически реализуемо ли это
|
|
12
|
+
- не знаешь нужно ли это кому-то кроме тебя
|
|
13
|
+
- хочешь понять риски до инвестиции времени
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Фазы
|
|
18
|
+
|
|
19
|
+
### Phase 1: Market Research
|
|
20
|
+
```
|
|
21
|
+
QUESTIONS:
|
|
22
|
+
- Существуют ли аналоги?
|
|
23
|
+
- Чем они плохи / чего не делают?
|
|
24
|
+
- Есть ли незанятая ниша?
|
|
25
|
+
- Кто потенциальный пользователь?
|
|
26
|
+
|
|
27
|
+
FORBIDDEN:
|
|
28
|
+
- предлагать решения
|
|
29
|
+
- думать об архитектуре
|
|
30
|
+
- оценивать сложность реализации
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### Phase 2: Technical Feasibility
|
|
34
|
+
```
|
|
35
|
+
QUESTIONS:
|
|
36
|
+
- Это реализуемо с текущим state of the art?
|
|
37
|
+
- Какие известные подходы существуют?
|
|
38
|
+
- Где известные тупики и ограничения?
|
|
39
|
+
- Какие технологии близко решают задачу?
|
|
40
|
+
|
|
41
|
+
FORBIDDEN:
|
|
42
|
+
- выбирать конкретный стек
|
|
43
|
+
- писать архитектуру
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
### Phase 3: Unknowns Map
|
|
47
|
+
```
|
|
48
|
+
Главный артефакт ResearchKit.
|
|
49
|
+
Не ответы — карта того что мы не знаем.
|
|
50
|
+
|
|
51
|
+
Каждый unknown классифицируется:
|
|
52
|
+
RISK: high / medium / low
|
|
53
|
+
VALIDATION: как проверить до начала разработки
|
|
54
|
+
BLOCKER: блокирует ли переход к ProductKit
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## Артефакты
|
|
60
|
+
|
|
61
|
+
### market.md
|
|
62
|
+
```markdown
|
|
63
|
+
# Market Research
|
|
64
|
+
|
|
65
|
+
## Аналоги
|
|
66
|
+
| Инструмент | Что делает | Чего не делает | Ниша |
|
|
67
|
+
|-----------|-----------|---------------|------|
|
|
68
|
+
|
|
69
|
+
## Незанятое пространство
|
|
70
|
+
...
|
|
71
|
+
|
|
72
|
+
## Потенциальный пользователь
|
|
73
|
+
...
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
### feasibility.md
|
|
77
|
+
```markdown
|
|
78
|
+
# Technical Feasibility
|
|
79
|
+
|
|
80
|
+
## Известные подходы
|
|
81
|
+
...
|
|
82
|
+
|
|
83
|
+
## Известные ограничения
|
|
84
|
+
...
|
|
85
|
+
|
|
86
|
+
## Вывод
|
|
87
|
+
FEASIBLE: yes / no / conditional
|
|
88
|
+
CONDITIONS: [что должно быть верным чтобы это работало]
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
### unknowns.md
|
|
92
|
+
```markdown
|
|
93
|
+
# Unknowns Map
|
|
94
|
+
|
|
95
|
+
## Unknown: [название]
|
|
96
|
+
DESCRIPTION: что именно не знаем
|
|
97
|
+
RISK: high / medium / low
|
|
98
|
+
VALIDATION: как проверить
|
|
99
|
+
BLOCKER: yes / no
|
|
100
|
+
STATUS: open / validated / invalidated
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
### assumptions.md
|
|
104
|
+
```markdown
|
|
105
|
+
# Assumptions
|
|
106
|
+
|
|
107
|
+
## Assumption: [название]
|
|
108
|
+
STATEMENT: что предполагаем
|
|
109
|
+
BASIS: почему предполагаем
|
|
110
|
+
RISK: high / medium / low
|
|
111
|
+
VALIDATION_METHOD: как проверить
|
|
112
|
+
STATUS: assumed / confirmed / rejected
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Переход к ProductKit
|
|
118
|
+
|
|
119
|
+
**ALLOWED** когда:
|
|
120
|
+
- все HIGH RISK unknowns имеют validation path
|
|
121
|
+
- feasibility = yes или conditional с известными условиями
|
|
122
|
+
- нет BLOCKER unknowns в статусе open
|
|
123
|
+
|
|
124
|
+
**BLOCKED** когда:
|
|
125
|
+
- есть BLOCKER unknown без validation path
|
|
126
|
+
- feasibility = no
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
## Команды
|
|
131
|
+
|
|
132
|
+
```
|
|
133
|
+
/research init "описание идеи"
|
|
134
|
+
/research market
|
|
135
|
+
/research feasibility
|
|
136
|
+
/research unknowns
|
|
137
|
+
/research validate "unknown name" "результат проверки"
|
|
138
|
+
/research status ← можно ли переходить к ProductKit
|
|
139
|
+
```
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: research-kit
|
|
3
|
+
description: DevKit Level 1. Use when developer has a new idea and needs to explore feasibility, find analogues, map unknowns, and validate assumptions before committing to build. Triggers on phrases like "I want to build X", "does this exist", "is this possible", "never been done before", "new idea".
|
|
4
|
+
license: MIT
|
|
5
|
+
metadata:
|
|
6
|
+
author: devkit
|
|
7
|
+
version: "1.0"
|
|
8
|
+
layer: "1-of-5"
|
|
9
|
+
next: product-kit
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# ResearchKit — Level 1: "Is this even possible?"
|
|
13
|
+
|
|
14
|
+
You are operating in ResearchKit phase. Your job is to help the developer explore the idea space before any architecture or implementation decisions are made.
|
|
15
|
+
|
|
16
|
+
## Your Role
|
|
17
|
+
|
|
18
|
+
- Ask questions, explore unknowns, map risks
|
|
19
|
+
- Do NOT suggest technical solutions or architecture
|
|
20
|
+
- Do NOT recommend a tech stack
|
|
21
|
+
- Do NOT write any code
|
|
22
|
+
|
|
23
|
+
## Phases
|
|
24
|
+
|
|
25
|
+
### Phase 1: Market Research
|
|
26
|
+
Explore whether analogues exist. Ask:
|
|
27
|
+
- What problem does this solve?
|
|
28
|
+
- Who has tried this before?
|
|
29
|
+
- What do existing solutions lack?
|
|
30
|
+
- Where is the unoccupied niche?
|
|
31
|
+
|
|
32
|
+
### Phase 2: Technical Feasibility
|
|
33
|
+
Explore whether this is buildable. Ask:
|
|
34
|
+
- Is this achievable with current state of the art?
|
|
35
|
+
- What known approaches exist?
|
|
36
|
+
- What are known dead ends?
|
|
37
|
+
- What are the hard constraints?
|
|
38
|
+
|
|
39
|
+
### Phase 3: Unknowns Map
|
|
40
|
+
This is the PRIMARY deliverable of ResearchKit.
|
|
41
|
+
|
|
42
|
+
For every unknown, classify:
|
|
43
|
+
- RISK: high / medium / low
|
|
44
|
+
- VALIDATION: how to check before building
|
|
45
|
+
- BLOCKER: does this block moving forward?
|
|
46
|
+
|
|
47
|
+
## Artifacts to Produce
|
|
48
|
+
|
|
49
|
+
Read templates from:
|
|
50
|
+
- [Market Research template](references/market.md)
|
|
51
|
+
- [Feasibility template](references/feasibility.md)
|
|
52
|
+
- [Unknowns template](references/unknowns.md)
|
|
53
|
+
- [Assumptions template](references/assumptions.md)
|
|
54
|
+
|
|
55
|
+
Save artifacts to `.devkit/research/`.
|
|
56
|
+
|
|
57
|
+
## Gate: When Can We Move to ProductKit?
|
|
58
|
+
|
|
59
|
+
ALLOWED to proceed when:
|
|
60
|
+
- All HIGH RISK unknowns have a validation path
|
|
61
|
+
- Feasibility is `yes` or `conditional` with known conditions
|
|
62
|
+
- No BLOCKER unknowns remain `open`
|
|
63
|
+
|
|
64
|
+
BLOCKED when:
|
|
65
|
+
- Any BLOCKER unknown has no validation path
|
|
66
|
+
- Feasibility is `no`
|
|
67
|
+
|
|
68
|
+
## Event Detection
|
|
69
|
+
|
|
70
|
+
If developer mentions during ResearchKit:
|
|
71
|
+
- New technical constraint → update feasibility.md
|
|
72
|
+
- New analogue found → update market.md
|
|
73
|
+
- Resolved unknown → update status in unknowns.md
|
|
74
|
+
|
|
75
|
+
## Handoff
|
|
76
|
+
|
|
77
|
+
When gate conditions are met, generate summary:
|
|
78
|
+
```
|
|
79
|
+
RESEARCH COMPLETE
|
|
80
|
+
FEASIBILITY: yes/conditional/no
|
|
81
|
+
KEY UNKNOWNS RESOLVED: N
|
|
82
|
+
REMAINING RISKS: [list with mitigations]
|
|
83
|
+
READY FOR: ProductKit
|
|
84
|
+
```
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Assumptions Template
|
|
2
|
+
|
|
3
|
+
## Assumption: [name]
|
|
4
|
+
STATEMENT: what we assume to be true
|
|
5
|
+
BASIS: why we believe this
|
|
6
|
+
RISK: high / medium / low
|
|
7
|
+
VALIDATION_METHOD: how to confirm or reject
|
|
8
|
+
STATUS: assumed / confirmed / rejected
|
|
9
|
+
FINDING: [fill when validated]
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Technical Feasibility Template
|
|
2
|
+
|
|
3
|
+
## Known Approaches
|
|
4
|
+
[What exists that could be used or adapted]
|
|
5
|
+
|
|
6
|
+
## Known Limitations
|
|
7
|
+
[Where known approaches break down]
|
|
8
|
+
|
|
9
|
+
## Hard Constraints
|
|
10
|
+
[Physical, regulatory, or technical ceilings]
|
|
11
|
+
|
|
12
|
+
## Verdict
|
|
13
|
+
FEASIBLE: yes / no / conditional
|
|
14
|
+
CONDITIONS: [what must be true for this to work]
|
|
15
|
+
CONFIDENCE: high / medium / low
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Market Research Template
|
|
2
|
+
|
|
3
|
+
## Analogues
|
|
4
|
+
| Tool | What it does | What it lacks | Our niche |
|
|
5
|
+
|------|-------------|---------------|-----------|
|
|
6
|
+
|
|
7
|
+
## Unoccupied Space
|
|
8
|
+
[What exists in the space no tool covers]
|
|
9
|
+
|
|
10
|
+
## Potential User
|
|
11
|
+
PROFILE: who they are
|
|
12
|
+
PROBLEM: what they struggle with today
|
|
13
|
+
CURRENT_SOLUTION: how they solve it without us
|