know-thy-build 0.3.1 → 0.3.2

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
@@ -136,6 +136,45 @@ Supported shortcuts: `en`, `ko`, `ja`, `zh`, `es`, `fr`, `de`, `pt` — or pass
136
136
 
137
137
  All conversation and generated documents use the chosen language. Technical terms stay in English.
138
138
 
139
+ ## Foundations
140
+
141
+ know-thy-build draws on established techniques from philosophy, software engineering, and AI research.
142
+
143
+ ### Core method: Socratic Prompting
144
+
145
+ The tool applies the [Socratic method](https://en.wikipedia.org/wiki/Socratic_method) — questioning to surface latent knowledge rather than providing answers directly. In Plato's *Meno*, Socrates demonstrates that learning is **recollection** (anamnesis): the right questions draw out what the learner already knows. know-thy-build operates on the same premise — you already know what you want to build, you just haven't articulated it yet.
146
+
147
+ - Chang, ["Prompting Large Language Models With the Socratic Method"](https://arxiv.org/abs/2303.08769) (2023) — adapts Socratic strategies into LLM prompting templates
148
+ - Princeton NLP, ["The Socratic Method for Self-Discovery in Large Language Models"](https://princeton-nlp.github.io/SocraticAI/) — explicitly connects Socratic dialogue to self-discovery in LLMs
149
+ - [SocraticLM](https://proceedings.neurips.cc/paper_files/paper/2024/hash/9bae399d1f34b8650351c1bd3692aeae-Abstract-Conference.html) (NeurIPS 2024 Spotlight) — Socratic teaching paradigm outperforming GPT-4 by >12%
150
+
151
+ ### Dialectical reasoning
152
+
153
+ Each exchange follows a thesis-antithesis-synthesis cycle: the user states what they want (thesis), the tool challenges it (antithesis), and a refined understanding emerges (synthesis). This is [Hegelian dialectic](https://en.wikipedia.org/wiki/Dialectic#Hegelian_dialectic) applied to project definition.
154
+
155
+ - ["Self-reflecting LLMs: A Hegelian Dialectical Approach"](https://arxiv.org/abs/2501.14917) (2025)
156
+
157
+ ### Requirements elicitation
158
+
159
+ In software engineering, [requirements elicitation](https://en.wikipedia.org/wiki/Requirements_elicitation) is the process of discovering what stakeholders actually need — a discipline that recognizes requirements are *discovered*, not merely captured.
160
+
161
+ - Zave & Jackson, "Four Dark Corners of Requirements Engineering" (1997, ACM TOSEM)
162
+ - ["AI-based Multiagent Approach for Requirements Elicitation and Analysis"](https://arxiv.org/abs/2409.00038) (2024)
163
+
164
+ ### Design Thinking (Define phase)
165
+
166
+ know-thy-build's output maps to the **Define** phase of [Design Thinking](https://web.stanford.edu/~mshanks/MichaelShanks/files/509554.pdf) (Stanford d.school) — synthesizing fuzzy intuitions into a structured problem statement that guides everything that follows.
167
+
168
+ ### The Rubber Duck, upgraded
169
+
170
+ [Rubber duck debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging) works because articulating forces clarity. know-thy-build is a rubber duck that talks back — one that not only forces articulation but actively probes weak spots and challenges surface-level answers.
171
+
172
+ ### Multi-Agent Debate
173
+
174
+ Even within a single facilitator, know-thy-build adopts multiple perspectives — questioning like a PM, challenging like an architect, probing edge cases like QA. The principle that opposing viewpoints produce better outcomes is well-established.
175
+
176
+ - Liang et al., ["Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate"](https://arxiv.org/abs/2305.19118) (EMNLP 2024)
177
+
139
178
  ## License
140
179
 
141
180
  MIT
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "know-thy-build",
3
- "version": "0.3.1",
3
+ "version": "0.3.2",
4
4
  "description": "Socratic project definition tool for Claude Code",
5
5
  "bin": {
6
6
  "know-thy-build": "./bin/cli.js"
@@ -67,21 +67,29 @@ Find the highest existing number and increment by 1. Zero-pad to 3 digits. If `f
67
67
 
68
68
  These are NOT a rigid sequence. Follow the conversation. Most features only need 2-3 of these to be clear.
69
69
 
70
- #### What — What are we building?
70
+ #### Problem — What's broken or missing?
71
71
 
72
- > Discover: The concrete thing to implement.
72
+ > Discover: The specific pain this feature addresses. This is not the project-level problem (that's in PROJECT.md) — this is the concrete gap or friction that triggered "we need this feature."
73
73
 
74
- - What does this feature do, in one sentence?
75
- - What does the user see/experience when it's working?
76
- - Is there an existing pattern in the codebase this builds on?
74
+ - What's not working right now? What's the user struggling with?
75
+ - What happens today without this feature? (workaround, manual step, error, confusion...)
76
+ - Who hits this problem and how often?
77
77
 
78
- #### Why — Why does this matter?
78
+ #### Value — Why is this worth building?
79
79
 
80
- > Discover: The motivation. Link to PROJECT.md if relevant.
80
+ > Discover: The value this feature delivers and how it connects to the bigger picture.
81
81
 
82
- - What problem does this solve or what value does it add?
83
- - What happens if we don't build it?
84
- - Does this connect to a principle or vision in PROJECT.md?
82
+ - What changes for the user when this exists?
83
+ - How does this connect to the project's vision or principles in PROJECT.md?
84
+ - What happens if we don't build it? Is there a cost of inaction?
85
+
86
+ #### Solution — How does this solve it?
87
+
88
+ > Discover: The concrete thing to implement. Not implementation details, but the user-facing shape of the solution.
89
+
90
+ - What does this feature do, in one sentence?
91
+ - What does the user see/experience when it's working?
92
+ - Is there an existing pattern in the codebase this builds on?
85
93
 
86
94
  #### Scope — Where are the edges?
87
95
 
@@ -148,13 +156,17 @@ During conversation, use `status: drafting`. On finalization, set to `complete`.
148
156
 
149
157
  <!-- One-liner: what this feature does -->
150
158
 
151
- ## What
159
+ ## Problem
160
+
161
+ <!-- What's broken or missing today. The specific pain this feature addresses. -->
162
+
163
+ ## Value
152
164
 
153
- <!-- Concrete description of what gets built -->
165
+ <!-- What changes when this exists. Link to PROJECT.md vision/principles if relevant. -->
154
166
 
155
- ## Why
167
+ ## Solution
156
168
 
157
- <!-- Motivation. Reference PROJECT.md if relevant -->
169
+ <!-- Concrete description of what gets built and how the user experiences it -->
158
170
 
159
171
  ## Scope
160
172