@synapta/skills 0.1.2 → 0.2.1
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/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@synapta/skills",
|
|
3
|
-
"version": "0.1
|
|
3
|
+
"version": "0.2.1",
|
|
4
4
|
"description": "Agent Skills loader + bundled default skill pack",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"type": "module",
|
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
"dependencies": {
|
|
27
27
|
"yaml": "^2.5.0",
|
|
28
28
|
"zod": "^3.23.0",
|
|
29
|
-
"@synapta/schemas": "0.
|
|
29
|
+
"@synapta/schemas": "0.2.1"
|
|
30
30
|
},
|
|
31
31
|
"devDependencies": {
|
|
32
32
|
"tsup": "^8.3.0",
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: concept-deepener
|
|
3
|
+
description: Adaptive interview helper. When an ArchitectureBrief leaves planning decisions ambiguous, emit a small list of open questions for the user instead of guessing.
|
|
4
|
+
triggers:
|
|
5
|
+
- new
|
|
6
|
+
- planning
|
|
7
|
+
- clarify
|
|
8
|
+
- open-questions
|
|
9
|
+
requires:
|
|
10
|
+
capability: text
|
|
11
|
+
network: off
|
|
12
|
+
tools: []
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
# Concept deepener — when to ask vs when to decide
|
|
16
|
+
|
|
17
|
+
You are operating inside Synapta's `synapta new` flow. The user has just answered a 12-question concept interview captured as an `ArchitectureBrief`. Your job in this round is to produce an `architecture-doc` JSON **and** an explicit set of `openQuestions[]` for anything you cannot confidently decide from the brief alone.
|
|
18
|
+
|
|
19
|
+
## Output contract
|
|
20
|
+
|
|
21
|
+
Emit two fenced code blocks tagged exactly as shown — Synapta's `engine-claude` adapter parses them out of your text and persists them as artifacts:
|
|
22
|
+
|
|
23
|
+
```architecture-doc
|
|
24
|
+
{
|
|
25
|
+
"summary": "1-paragraph plain-English summary of the architecture you'd pick",
|
|
26
|
+
"pattern": "modular-monolith | microservices | serverless | event-driven | hybrid",
|
|
27
|
+
"modules": [ { "name": "...", "responsibility": "...", "depends_on": [] } ],
|
|
28
|
+
"dataFlows": [ "user → web → api → db" ],
|
|
29
|
+
"adrs": [
|
|
30
|
+
{ "id": "ADR-0001", "title": "...", "status": "accepted",
|
|
31
|
+
"context": "...", "decision": "...", "consequences": "..." }
|
|
32
|
+
],
|
|
33
|
+
"assumptions": [ "Stripe is acceptable for payments", "..." ],
|
|
34
|
+
"openQuestions": [
|
|
35
|
+
{
|
|
36
|
+
"id": "q-auth-provider",
|
|
37
|
+
"question": "Magic-link only, or also OAuth?",
|
|
38
|
+
"why": "Pricing and user-management complexity differ materially.",
|
|
39
|
+
"kind": "choice",
|
|
40
|
+
"choices": ["magic link only", "magic link + OAuth (Google/GitHub)", "OAuth only"]
|
|
41
|
+
}
|
|
42
|
+
]
|
|
43
|
+
}
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
```backlog
|
|
47
|
+
[
|
|
48
|
+
{ "id": "AUTH-001", "epic": "auth", "title": "...",
|
|
49
|
+
"acceptance": ["..."], "dependencies": [], "estimate": "S", "status": "planned" }
|
|
50
|
+
]
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## How to decide what's an `openQuestion`
|
|
54
|
+
|
|
55
|
+
Emit a question (rather than picking) when:
|
|
56
|
+
|
|
57
|
+
- A decision **materially affects scope** (e.g. multi-tenancy, billing model, compliance posture, on-prem requirement, real-time vs batch) and the brief is silent on it.
|
|
58
|
+
- A decision **affects cost** by ≥ 2× (e.g. self-hosted DB vs managed; serverless vs always-on container; per-region replication).
|
|
59
|
+
- A decision is **regulatory** (HIPAA / PCI / GDPR strictness) and the brief is "decide for me" on integrations or data sensitivity.
|
|
60
|
+
- The brief has an obviously **stub answer** ("worldwide", "decide for me", "0 engineers") that needs a follow-up.
|
|
61
|
+
|
|
62
|
+
Decide silently (and capture in `assumptions[]`) when:
|
|
63
|
+
|
|
64
|
+
- The brief gives explicit constraints (`tenancy: 'single'`, `offlineCapable: false`).
|
|
65
|
+
- The choice is low-blast-radius and reversible (e.g. logger library, ORM choice).
|
|
66
|
+
- An industry default is overwhelmingly the right call given the stated team size + scale.
|
|
67
|
+
|
|
68
|
+
## Rules of thumb
|
|
69
|
+
|
|
70
|
+
- **≤ 5 open questions per round.** More than 5 means you're over-asking. Prioritise the highest-impact ones.
|
|
71
|
+
- **Each question stands alone** — don't ask three sub-questions in one bullet.
|
|
72
|
+
- **Suggest concrete choices** when possible. `kind: 'choice'` with `choices: [...]` beats `kind: 'clarify'` with a freeform answer.
|
|
73
|
+
- **Explain the `why`** in one sentence per question. The user shouldn't have to guess why you're asking.
|
|
74
|
+
- **Always emit a partial `architecture-doc`** — even when you have open questions, give your best current plan. The user will reject or refine it, not approve a blank.
|
|
75
|
+
- **Default to `pattern: 'modular-monolith'`** unless the brief surfaces explicit reasons for distributed services (team size > 8, multi-region active-active, > 10k QPS at year 1, etc.).
|
|
76
|
+
- **Default to Twelve-Factor practices** for any chosen stack.
|
|
77
|
+
|
|
78
|
+
## Re-running on a refined brief
|
|
79
|
+
|
|
80
|
+
If you receive an updated brief with the user's answers folded in (Synapta will mark it with `(round 2)` or `(round 3)` in the prompt), keep the same `architecture-doc` shape but:
|
|
81
|
+
|
|
82
|
+
- Move answered questions out of `openQuestions[]` and into `assumptions[]`.
|
|
83
|
+
- Tighten the `modules` and `dataFlows` based on what you now know.
|
|
84
|
+
- Only emit new `openQuestions[]` for things the previous round revealed (don't repeat).
|
|
85
|
+
|
|
86
|
+
Stop emitting questions once you have enough to ship a complete plan. Round 3 should ideally have an empty `openQuestions[]`.
|