knowzcode 0.1.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/.claude-plugin/marketplace.json +55 -0
- package/.claude-plugin/plugin.json +8 -0
- package/LICENSE +121 -0
- package/README.md +223 -0
- package/agents/analyst.md +121 -0
- package/agents/architect.md +121 -0
- package/agents/builder.md +155 -0
- package/agents/closer.md +148 -0
- package/agents/knowledge-migrator.md +349 -0
- package/agents/microfix-specialist.md +140 -0
- package/agents/reviewer.md +220 -0
- package/agents/update-coordinator.md +405 -0
- package/bin/knowzcode.mjs +869 -0
- package/commands/audit.md +108 -0
- package/commands/connect-mcp.md +507 -0
- package/commands/fix.md +107 -0
- package/commands/init.md +320 -0
- package/commands/learn.md +308 -0
- package/commands/plan.md +125 -0
- package/commands/register.md +724 -0
- package/commands/status.md +291 -0
- package/commands/telemetry-setup.md +368 -0
- package/commands/telemetry.md +188 -0
- package/commands/work.md +390 -0
- package/knowzcode/automation_manifest.md +59 -0
- package/knowzcode/claude_code_execution.md +133 -0
- package/knowzcode/enterprise/compliance_manifest.md +132 -0
- package/knowzcode/enterprise/compliance_status.md +30 -0
- package/knowzcode/enterprise/guidelines/code-quality.md +67 -0
- package/knowzcode/enterprise/guidelines/custom/.gitkeep +0 -0
- package/knowzcode/enterprise/guidelines/security.md +355 -0
- package/knowzcode/enterprise/reports/.gitkeep +0 -0
- package/knowzcode/enterprise/templates/guideline-template.md +55 -0
- package/knowzcode/gitignore.template +13 -0
- package/knowzcode/knowzcode_architecture.md +51 -0
- package/knowzcode/knowzcode_log.md +142 -0
- package/knowzcode/knowzcode_loop.md +515 -0
- package/knowzcode/knowzcode_project.md +233 -0
- package/knowzcode/knowzcode_tracker.md +40 -0
- package/knowzcode/knowzcode_vaults.md +104 -0
- package/knowzcode/mcp_config.md +166 -0
- package/knowzcode/planning/Readme.md +6 -0
- package/knowzcode/platform_adapters.md +388 -0
- package/knowzcode/prompts/Execute_Micro_Fix.md +57 -0
- package/knowzcode/prompts/Investigate_Codebase.md +227 -0
- package/knowzcode/prompts/Migrate_Knowledge.md +301 -0
- package/knowzcode/prompts/Refactor_Node.md +72 -0
- package/knowzcode/prompts/Spec_Verification_Checkpoint.md +59 -0
- package/knowzcode/prompts/[LOOP_1A]__Propose_Change_Set.md +52 -0
- package/knowzcode/prompts/[LOOP_1B]__Draft_Specs.md +75 -0
- package/knowzcode/prompts/[LOOP_2A]__Implement_Change_Set.md +55 -0
- package/knowzcode/prompts/[LOOP_2B]__Verify_Implementation.md +72 -0
- package/knowzcode/prompts/[LOOP_3]__Finalize_And_Commit.md +67 -0
- package/knowzcode/specs/Readme.md +10 -0
- package/knowzcode/telemetry_config.md +89 -0
- package/knowzcode/user_preferences.md +120 -0
- package/package.json +53 -0
- package/skills/alias-resolver.json +15 -0
- package/skills/architecture-diff.json +12 -0
- package/skills/check-installation-status.json +14 -0
- package/skills/continue.md +105 -0
- package/skills/environment-guard.json +12 -0
- package/skills/generate-workgroup-id.json +25 -0
- package/skills/install-knowzcode.json +21 -0
- package/skills/load-core-context.json +18 -0
- package/skills/log-entry-builder.json +15 -0
- package/skills/spec-quality-check.json +14 -0
- package/skills/spec-template.json +15 -0
- package/skills/spec-validator.json +25 -0
- package/skills/start-work.md +224 -0
- package/skills/tracker-scan.json +12 -0
- package/skills/tracker-update.json +28 -0
- package/skills/validate-installation.json +14 -0
|
@@ -0,0 +1,388 @@
|
|
|
1
|
+
# KnowzCode Platform Adapters
|
|
2
|
+
|
|
3
|
+
This file contains adapter templates for integrating KnowzCode with different AI coding platforms. Each adapter teaches the platform's AI how to follow the KnowzCode methodology with full phase walkthroughs, quality gates, and TDD enforcement.
|
|
4
|
+
|
|
5
|
+
Generated by `/kc:init`. Adapters should be placed in the project root (or platform-specific location).
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Claude Code (CLAUDE.md section)
|
|
10
|
+
|
|
11
|
+
Append to or create `CLAUDE.md` in project root:
|
|
12
|
+
|
|
13
|
+
```markdown
|
|
14
|
+
# KnowzCode Integration
|
|
15
|
+
|
|
16
|
+
This project uses KnowzCode for structured TDD development with multi-agent orchestration.
|
|
17
|
+
|
|
18
|
+
## Required Reading
|
|
19
|
+
- `knowzcode/knowzcode_loop.md` — Development methodology (TDD, quality gates, phases)
|
|
20
|
+
- `knowzcode/knowzcode_project.md` — Project context and tech stack
|
|
21
|
+
- `knowzcode/knowzcode_tracker.md` — Current WorkGroup status
|
|
22
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture documentation
|
|
23
|
+
|
|
24
|
+
## Workflow Phases
|
|
25
|
+
Follow the phases in `knowzcode_loop.md` for all feature work:
|
|
26
|
+
1. **Phase 1A: Impact Analysis** — Identify affected components, propose Change Set. PAUSE for user approval.
|
|
27
|
+
2. **Phase 1B: Specification** — Draft specs for all NodeIDs. PAUSE for user approval. Commit specs.
|
|
28
|
+
3. **Phase 2A: Implementation** — Strict TDD (Red-Green-Refactor). No production code without a failing test.
|
|
29
|
+
4. **Phase 2B: Completeness Audit** — Independent READ-ONLY audit. PAUSE for user decision on gaps.
|
|
30
|
+
5. **Phase 3: Finalization** — Update specs to as-built, update tracker, log entry, final commit.
|
|
31
|
+
|
|
32
|
+
## Quality Gates
|
|
33
|
+
Never skip phases. PAUSE for user approval at each gate:
|
|
34
|
+
- After Change Set proposal (1A)
|
|
35
|
+
- After spec drafts (1B)
|
|
36
|
+
- After implementation (2A — awaiting audit)
|
|
37
|
+
- After audit results (2B — user decides on gaps)
|
|
38
|
+
|
|
39
|
+
## TDD Enforcement
|
|
40
|
+
TDD is mandatory — no production code without a failing test first.
|
|
41
|
+
Red-Green-Refactor cycle for every feature/criterion in the spec.
|
|
42
|
+
|
|
43
|
+
## Agents
|
|
44
|
+
Specialized agents handle each phase when using Agent Teams or subagent execution:
|
|
45
|
+
- `analyst` (1A), `architect` (1B), `builder` (2A), `reviewer` (2B), `closer` (3)
|
|
46
|
+
- Agent Teams is the preferred execution model when enabled (experimental, requires `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` env var)
|
|
47
|
+
- Subagent fallback for environments without Agent Teams
|
|
48
|
+
|
|
49
|
+
## Commands
|
|
50
|
+
- `/kc:work "goal"` — Start feature workflow
|
|
51
|
+
- `/kc:plan "topic"` — Research before implementing
|
|
52
|
+
- `/kc:audit [type]` — Run quality audits (spec, architecture, security, integration)
|
|
53
|
+
- `/kc:fix "target" "summary"` — Quick targeted fix
|
|
54
|
+
- `/kc:learn "insight"` — Capture learning to vault
|
|
55
|
+
- `/kc:status` — Check MCP connection and vault status
|
|
56
|
+
|
|
57
|
+
## MCP Integration (Optional)
|
|
58
|
+
If configured, agents use `search_knowledge`, `ask_question`, and `create_knowledge` for enhanced context.
|
|
59
|
+
All commands work without MCP — it enhances but never blocks.
|
|
60
|
+
|
|
61
|
+
## WorkGroup Files
|
|
62
|
+
- Created in `knowzcode/workgroups/` (gitignored)
|
|
63
|
+
- Every todo must start with `KnowzCode:` prefix
|
|
64
|
+
- Track phase history, Change Set, and outstanding work
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## OpenAI Codex (AGENTS.md)
|
|
70
|
+
|
|
71
|
+
Create `AGENTS.md` in project root. Notes: `AGENTS.override.md` can be used for user-local overrides. 32KB file size limit. Plain text format (no YAML frontmatter).
|
|
72
|
+
|
|
73
|
+
```markdown
|
|
74
|
+
# KnowzCode Development Methodology
|
|
75
|
+
|
|
76
|
+
This project uses KnowzCode for structured TDD development.
|
|
77
|
+
Read `knowzcode/knowzcode_loop.md` before starting any feature work.
|
|
78
|
+
|
|
79
|
+
## Phase Walkthrough
|
|
80
|
+
|
|
81
|
+
### Before Starting
|
|
82
|
+
1. Read `knowzcode/knowzcode_tracker.md` — check for active WorkGroups
|
|
83
|
+
2. Read `knowzcode/knowzcode_project.md` — understand project context
|
|
84
|
+
3. Read `knowzcode/knowzcode_architecture.md` — understand current architecture
|
|
85
|
+
|
|
86
|
+
### Phase 1A: Impact Analysis
|
|
87
|
+
- Analyze what needs to change for the given goal
|
|
88
|
+
- Create NodeIDs for NEW capabilities only (not per-file)
|
|
89
|
+
- Check `knowzcode/specs/` for existing specs in the same domain
|
|
90
|
+
- Propose a Change Set with NodeIDs, affected files, and risk assessment
|
|
91
|
+
- **STOP**: Present Change Set for user approval before continuing
|
|
92
|
+
|
|
93
|
+
### Phase 1B: Specification
|
|
94
|
+
- Draft specs for each NodeID using the 4-section format:
|
|
95
|
+
- Rules & Decisions, Interfaces, Verification Criteria, Debt & Gaps
|
|
96
|
+
- Minimum: 1+ Rules, 1+ Interface, 2+ VERIFY statements per spec
|
|
97
|
+
- Save to `knowzcode/specs/{NodeID}.md`
|
|
98
|
+
- **STOP**: Present specs for user approval
|
|
99
|
+
- After approval: `git commit` the specs as a checkpoint
|
|
100
|
+
|
|
101
|
+
### Phase 2A: Implementation (TDD MANDATORY)
|
|
102
|
+
- For EACH feature/criterion in the spec:
|
|
103
|
+
1. RED: Write a failing test first
|
|
104
|
+
2. GREEN: Write minimal code to make the test pass
|
|
105
|
+
3. REFACTOR: Clean up while keeping tests green
|
|
106
|
+
- Run full test suite + static analysis + build after all features
|
|
107
|
+
- Maximum 10 verification iterations before pausing
|
|
108
|
+
- **STOP**: Report implementation results
|
|
109
|
+
|
|
110
|
+
### Phase 2B: Completeness Audit
|
|
111
|
+
- READ-ONLY audit — do NOT modify source files
|
|
112
|
+
- Compare implementation against all VERIFY statements in specs
|
|
113
|
+
- Calculate completion percentage
|
|
114
|
+
- Report gaps, security concerns, integration issues
|
|
115
|
+
- **STOP**: Present audit results for user decision
|
|
116
|
+
|
|
117
|
+
### Phase 3: Finalization
|
|
118
|
+
- Update specs to "As-Built" status
|
|
119
|
+
- Check architecture doc for drift
|
|
120
|
+
- Prepend log entry to `knowzcode/knowzcode_log.md`
|
|
121
|
+
- Update tracker statuses to `[VERIFIED]`
|
|
122
|
+
- Create final commit with all changes
|
|
123
|
+
|
|
124
|
+
## Key Rules
|
|
125
|
+
- Always propose a Change Set before implementing
|
|
126
|
+
- Get user approval at every quality gate (STOP points above)
|
|
127
|
+
- TDD is mandatory — no production code without failing tests
|
|
128
|
+
- Log all completions in `knowzcode/knowzcode_log.md`
|
|
129
|
+
- Track work in `knowzcode/knowzcode_tracker.md`
|
|
130
|
+
- Every WorkGroup todo must start with `KnowzCode:` prefix
|
|
131
|
+
- Target <20 specs per project — consolidate when domains overlap
|
|
132
|
+
|
|
133
|
+
## Quick Fix (Micro-Fix)
|
|
134
|
+
For single-file, <50 line, no-ripple-effect changes:
|
|
135
|
+
1. Implement the fix
|
|
136
|
+
2. Run targeted tests
|
|
137
|
+
3. Log a MicroFix entry
|
|
138
|
+
4. Commit with `fix:` prefix
|
|
139
|
+
|
|
140
|
+
## Key Files
|
|
141
|
+
- `knowzcode/knowzcode_loop.md` — Complete methodology
|
|
142
|
+
- `knowzcode/knowzcode_project.md` — Project context
|
|
143
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture docs
|
|
144
|
+
- `knowzcode/knowzcode_tracker.md` — WorkGroup tracking
|
|
145
|
+
- `knowzcode/specs/` — Component specifications
|
|
146
|
+
- `knowzcode/workgroups/` — Active session data (gitignored)
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
---
|
|
150
|
+
|
|
151
|
+
## Google Gemini CLI (GEMINI.md)
|
|
152
|
+
|
|
153
|
+
Create `GEMINI.md` in project root. Notes: Gemini CLI supports `@file.md` imports for pulling in methodology files (e.g., `@knowzcode/knowzcode_loop.md`). User-global preferences can be placed in `~/.gemini/GEMINI.md`.
|
|
154
|
+
|
|
155
|
+
```markdown
|
|
156
|
+
# KnowzCode Development Methodology
|
|
157
|
+
|
|
158
|
+
This project uses KnowzCode for structured TDD development.
|
|
159
|
+
|
|
160
|
+
## Required Reading
|
|
161
|
+
Read these files before starting any feature work (use @import syntax for direct inclusion):
|
|
162
|
+
- `knowzcode/knowzcode_loop.md` — Complete workflow methodology
|
|
163
|
+
- `knowzcode/knowzcode_project.md` — Project context and tech stack
|
|
164
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture documentation
|
|
165
|
+
- `knowzcode/knowzcode_tracker.md` — Active WorkGroups
|
|
166
|
+
|
|
167
|
+
## Phase Walkthrough
|
|
168
|
+
|
|
169
|
+
### Phase 1A: Impact Analysis
|
|
170
|
+
- Identify components affected by the goal
|
|
171
|
+
- Create NodeIDs for new capabilities (PascalCase domain concepts)
|
|
172
|
+
- Check existing specs for domain overlap before creating new ones
|
|
173
|
+
- Present Change Set for user approval — STOP until approved
|
|
174
|
+
|
|
175
|
+
### Phase 1B: Specification
|
|
176
|
+
- Draft specs using 4-section format (Rules, Interfaces, Verification Criteria, Debt)
|
|
177
|
+
- Each spec needs 2+ VERIFY statements
|
|
178
|
+
- Present for approval — STOP until approved
|
|
179
|
+
- Commit specs as a pre-implementation checkpoint
|
|
180
|
+
|
|
181
|
+
### Phase 2A: Implementation (TDD Required)
|
|
182
|
+
- Follow Red-Green-Refactor for every feature
|
|
183
|
+
- Write failing test FIRST, then minimal code to pass, then refactor
|
|
184
|
+
- Run full test suite + linter + build when all features done
|
|
185
|
+
- STOP and report results
|
|
186
|
+
|
|
187
|
+
### Phase 2B: Completeness Audit
|
|
188
|
+
- READ-ONLY comparison of implementation vs specs
|
|
189
|
+
- Calculate completion percentage
|
|
190
|
+
- Report gaps and security concerns
|
|
191
|
+
- STOP for user decision
|
|
192
|
+
|
|
193
|
+
### Phase 3: Finalization
|
|
194
|
+
- Update specs to As-Built, update tracker, write log entry
|
|
195
|
+
- Check architecture doc for drift
|
|
196
|
+
- Final commit
|
|
197
|
+
|
|
198
|
+
## Rules
|
|
199
|
+
- Follow quality gates strictly — STOP at each gate for user approval
|
|
200
|
+
- TDD is mandatory for all feature work
|
|
201
|
+
- Propose Change Sets before implementing
|
|
202
|
+
- Update specs and tracker after implementation
|
|
203
|
+
- Log completions in `knowzcode/knowzcode_log.md`
|
|
204
|
+
- Target <20 specs — consolidate when domains overlap >50%
|
|
205
|
+
|
|
206
|
+
## Micro-Fix (for small changes)
|
|
207
|
+
Single file, <50 lines, no ripple effects:
|
|
208
|
+
1. Implement fix → 2. Run tests → 3. Log MicroFix → 4. Commit with `fix:`
|
|
209
|
+
```
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
## Cursor (`.cursor/rules/knowzcode.mdc`)
|
|
214
|
+
|
|
215
|
+
Create `.cursor/rules/knowzcode.mdc` with YAML frontmatter. Notes: Modern Cursor uses `.cursor/rules/*.mdc` files instead of the deprecated `.cursorrules`. Scoped rules can target specific file patterns using the `globs` frontmatter field.
|
|
216
|
+
|
|
217
|
+
```markdown
|
|
218
|
+
---
|
|
219
|
+
description: KnowzCode TDD development methodology
|
|
220
|
+
alwaysApply: true
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
# KnowzCode Rules
|
|
224
|
+
|
|
225
|
+
This project uses KnowzCode for structured TDD development.
|
|
226
|
+
|
|
227
|
+
## Required Reading
|
|
228
|
+
Before any feature work, read:
|
|
229
|
+
- `knowzcode/knowzcode_loop.md` — Complete methodology
|
|
230
|
+
- `knowzcode/knowzcode_project.md` — Project context
|
|
231
|
+
- `knowzcode/knowzcode_tracker.md` — Active WorkGroups
|
|
232
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture docs
|
|
233
|
+
|
|
234
|
+
## Phase Rules
|
|
235
|
+
|
|
236
|
+
### Phase 1A: Impact Analysis
|
|
237
|
+
- Identify affected components and propose a Change Set
|
|
238
|
+
- NodeIDs are domain concepts (PascalCase), not tasks
|
|
239
|
+
- Check `knowzcode/specs/` before creating new specs
|
|
240
|
+
- PAUSE for user approval before proceeding
|
|
241
|
+
|
|
242
|
+
### Phase 1B: Specification
|
|
243
|
+
- Use 4-section format: Rules & Decisions, Interfaces, Verification Criteria, Debt & Gaps
|
|
244
|
+
- Minimum: 2+ VERIFY statements per spec
|
|
245
|
+
- PAUSE for user approval, then commit specs
|
|
246
|
+
|
|
247
|
+
### Phase 2A: Implementation
|
|
248
|
+
- TDD is mandatory: write failing test FIRST, then minimal code, then refactor
|
|
249
|
+
- Use Composer for multi-file edits when implementing across components
|
|
250
|
+
- Run full test suite before reporting complete
|
|
251
|
+
- PAUSE after implementation
|
|
252
|
+
|
|
253
|
+
### Phase 2B: Audit
|
|
254
|
+
- READ-ONLY — do not modify source files
|
|
255
|
+
- Compare implementation vs spec VERIFY statements
|
|
256
|
+
- Report completion percentage and gaps
|
|
257
|
+
- PAUSE for user decision
|
|
258
|
+
|
|
259
|
+
### Phase 3: Finalization
|
|
260
|
+
- Update specs to As-Built status
|
|
261
|
+
- Update tracker and log
|
|
262
|
+
- Check architecture for drift
|
|
263
|
+
- Final commit
|
|
264
|
+
|
|
265
|
+
## Enforcement
|
|
266
|
+
- Never skip phases or quality gates
|
|
267
|
+
- TDD is mandatory — no production code without a failing test
|
|
268
|
+
- Every WorkGroup todo starts with `KnowzCode:` prefix
|
|
269
|
+
- Consolidate specs when domains overlap >50%
|
|
270
|
+
- Target <20 specs per project
|
|
271
|
+
- Read `knowzcode/knowzcode_tracker.md` for active work
|
|
272
|
+
- Log completions in `knowzcode/knowzcode_log.md`
|
|
273
|
+
```
|
|
274
|
+
|
|
275
|
+
---
|
|
276
|
+
|
|
277
|
+
## GitHub Copilot (.github/copilot-instructions.md)
|
|
278
|
+
|
|
279
|
+
Create `.github/copilot-instructions.md` for repository-level instructions. Notes: GitHub Copilot also supports scoped instructions via `*.instructions.md` files with `applyTo` YAML frontmatter (e.g., `knowzcode.instructions.md` with `applyTo: "knowzcode/**"` to scope KnowzCode methodology to the framework directory).
|
|
280
|
+
|
|
281
|
+
```markdown
|
|
282
|
+
# KnowzCode Development Methodology
|
|
283
|
+
|
|
284
|
+
This repository uses KnowzCode for structured TDD development.
|
|
285
|
+
|
|
286
|
+
## Key Constraint: TDD is Mandatory
|
|
287
|
+
- Write failing tests BEFORE implementation code
|
|
288
|
+
- Follow Red-Green-Refactor cycle for every feature
|
|
289
|
+
- No production code without corresponding test coverage
|
|
290
|
+
|
|
291
|
+
## Workflow
|
|
292
|
+
Reference `knowzcode/knowzcode_loop.md` for the complete development workflow.
|
|
293
|
+
Follow these phases for all feature work:
|
|
294
|
+
|
|
295
|
+
1. **Impact Analysis** — Propose a Change Set, get user approval
|
|
296
|
+
2. **Specification** — Draft specs with VERIFY statements, get user approval
|
|
297
|
+
3. **Implementation** — Strict TDD, verification loop
|
|
298
|
+
4. **Audit** — READ-ONLY comparison against specs
|
|
299
|
+
5. **Finalization** — Update docs, tracker, log, commit
|
|
300
|
+
|
|
301
|
+
## Quality Gates
|
|
302
|
+
STOP and get user approval:
|
|
303
|
+
- After Change Set proposal
|
|
304
|
+
- After spec drafts
|
|
305
|
+
- After implementation (awaiting audit)
|
|
306
|
+
- After audit results (user decides on gaps)
|
|
307
|
+
|
|
308
|
+
## Key Files
|
|
309
|
+
- `knowzcode/knowzcode_loop.md` — Methodology (read first)
|
|
310
|
+
- `knowzcode/knowzcode_project.md` — Project context
|
|
311
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture docs
|
|
312
|
+
- `knowzcode/knowzcode_tracker.md` — WorkGroup tracking
|
|
313
|
+
- `knowzcode/specs/` — Component specifications
|
|
314
|
+
|
|
315
|
+
## Rules
|
|
316
|
+
- NodeIDs are domain concepts (PascalCase), not tasks
|
|
317
|
+
- Consolidate specs when domains overlap >50%
|
|
318
|
+
- Every WorkGroup todo starts with `KnowzCode:` prefix
|
|
319
|
+
- Log completions in `knowzcode/knowzcode_log.md`
|
|
320
|
+
```
|
|
321
|
+
|
|
322
|
+
---
|
|
323
|
+
|
|
324
|
+
## Windsurf (`.windsurf/rules/knowzcode.md`)
|
|
325
|
+
|
|
326
|
+
Create `.windsurf/rules/knowzcode.md`. Notes: Modern Windsurf uses the `.windsurf/rules/` directory instead of the deprecated `.windsurfrules` file. Cascade multi-file editing works well with KnowzCode's cross-component implementation phases.
|
|
327
|
+
|
|
328
|
+
```markdown
|
|
329
|
+
# KnowzCode Development Methodology
|
|
330
|
+
|
|
331
|
+
This project uses KnowzCode for structured TDD development.
|
|
332
|
+
Follow `knowzcode/knowzcode_loop.md` for all feature development.
|
|
333
|
+
|
|
334
|
+
## Required Reading
|
|
335
|
+
- `knowzcode/knowzcode_loop.md` — Complete methodology
|
|
336
|
+
- `knowzcode/knowzcode_project.md` — Project context
|
|
337
|
+
- `knowzcode/knowzcode_tracker.md` — Active WorkGroups
|
|
338
|
+
- `knowzcode/knowzcode_architecture.md` — Architecture docs
|
|
339
|
+
|
|
340
|
+
## Phase Walkthrough
|
|
341
|
+
|
|
342
|
+
### Phase 1A: Impact Analysis
|
|
343
|
+
- Identify affected components, propose Change Set with NodeIDs
|
|
344
|
+
- Check existing specs before creating new ones
|
|
345
|
+
- PAUSE for user approval
|
|
346
|
+
|
|
347
|
+
### Phase 1B: Specification
|
|
348
|
+
- Draft specs with 4-section format and 2+ VERIFY statements
|
|
349
|
+
- PAUSE for approval, then commit specs
|
|
350
|
+
|
|
351
|
+
### Phase 2A: Implementation (TDD Mandatory)
|
|
352
|
+
- Write failing test FIRST, then minimal code, then refactor
|
|
353
|
+
- Use Cascade for multi-file edits across components
|
|
354
|
+
- Run full verification loop (tests + linter + build)
|
|
355
|
+
- PAUSE after implementation
|
|
356
|
+
|
|
357
|
+
### Phase 2B: Audit
|
|
358
|
+
- READ-ONLY audit against spec VERIFY statements
|
|
359
|
+
- Report completion %, gaps, security concerns
|
|
360
|
+
- PAUSE for user decision
|
|
361
|
+
|
|
362
|
+
### Phase 3: Finalization
|
|
363
|
+
- Update specs to As-Built, tracker, log, architecture
|
|
364
|
+
- Final commit
|
|
365
|
+
|
|
366
|
+
## Enforcement Rules
|
|
367
|
+
- TDD is mandatory — write failing tests before implementation code
|
|
368
|
+
- Respect quality gates between phases — PAUSE at each gate
|
|
369
|
+
- Update `knowzcode/knowzcode_tracker.md` when completing work
|
|
370
|
+
- Log completions in `knowzcode/knowzcode_log.md`
|
|
371
|
+
- Consolidate specs when domains overlap >50%
|
|
372
|
+
- Target <20 specs per project
|
|
373
|
+
- Every WorkGroup todo starts with `KnowzCode:` prefix
|
|
374
|
+
|
|
375
|
+
## Micro-Fix (for small changes)
|
|
376
|
+
Single file, <50 lines, no ripple effects:
|
|
377
|
+
Implement → Test → Log MicroFix → Commit with `fix:` prefix
|
|
378
|
+
```
|
|
379
|
+
|
|
380
|
+
---
|
|
381
|
+
|
|
382
|
+
## OpenAI Codex Agents SDK (Python)
|
|
383
|
+
|
|
384
|
+
For teams building custom orchestration with the OpenAI Agents SDK,
|
|
385
|
+
map KnowzCode's 5 phase agents to SDK Agent definitions. The AGENTS.md
|
|
386
|
+
file above provides all instructions each agent needs. See the
|
|
387
|
+
[Agents SDK documentation](https://openai.github.io/openai-agents-python/)
|
|
388
|
+
for implementation details.
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# KnowzCode: Execute Micro-Fix
|
|
2
|
+
|
|
3
|
+
**Target:** [NodeID or specific file path]
|
|
4
|
+
**Issue:** [Brief, one-line description of the small change needed]
|
|
5
|
+
|
|
6
|
+
Remember to log follow-up tasks in `knowzcode/workgroups/<WorkGroupID>.md` with the `KnowzCode:` prefix.
|
|
7
|
+
|
|
8
|
+
> **Automation Path:** Prefer invoking `/kc-microfix target=<NodeID> summary="..."` to delegate to the `microfix-specialist` subagent while keeping scope under the 50-line threshold.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Your Mission
|
|
13
|
+
You have been instructed to perform a "Micro-Fix." This protocol is for small, localized changes that do not alter system architecture or component interfaces.
|
|
14
|
+
|
|
15
|
+
**CRITICAL RULE: Before proceeding, confirm this task qualifies as a Micro-Fix.** It must be a small change (e.g., < 50 lines), have no ripple effects, and require no spec updates. If it does not qualify, **STOP** and inform the Orchestrator that the full KnowzCode loop is required.
|
|
16
|
+
|
|
17
|
+
**Reference:** Your actions are governed by the "Micro-Fix Protocol" in `knowzcode_loop.md`.
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
### Execution Protocol
|
|
22
|
+
|
|
23
|
+
1. **Implement Fix:**
|
|
24
|
+
* Make the small, targeted change precisely as requested.
|
|
25
|
+
|
|
26
|
+
2. **Quick Verification:**
|
|
27
|
+
* Perform a focused check to confirm the fix resolves the described issue and introduces no regressions in the immediate vicinity of the change.
|
|
28
|
+
|
|
29
|
+
3. **Log Operation (Ref: `knowzcode_loop.md` - Step 4.3):**
|
|
30
|
+
* Prepend a `MicroFix` entry to `knowzcode_log.md`. The entry **MUST** use the following format and an environment-sourced timestamp:
|
|
31
|
+
```markdown
|
|
32
|
+
---
|
|
33
|
+
**Type:** MicroFix
|
|
34
|
+
**Timestamp:** [Generated Timestamp]
|
|
35
|
+
**NodeID(s)/File:** [TargetNodeID or file_path]
|
|
36
|
+
**Logged By:** AI-Agent
|
|
37
|
+
**Details:**
|
|
38
|
+
- **User Request:** [Orchestrator's brief issue description].
|
|
39
|
+
- **Action Taken:** [Brief description of change made].
|
|
40
|
+
- **Verification:** [Brief verification method/outcome].
|
|
41
|
+
---
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
4. **Commit Fix (Ref: `knowzcode_loop.md` - Step 4.4):**
|
|
45
|
+
* Commit the change to version control with a descriptive `fix:` message (e.g., `fix: correct label on login button`). Use the `git` command specified in your `environment_context.md`.
|
|
46
|
+
|
|
47
|
+
### Final Report
|
|
48
|
+
|
|
49
|
+
* Once all steps are complete, provide a concise confirmation report.
|
|
50
|
+
|
|
51
|
+
**Example Response:**
|
|
52
|
+
> "✓ Micro-Fix completed for `[Target]`.
|
|
53
|
+
> * **Change:** Corrected the CSS padding on the main header.
|
|
54
|
+
> * **Verification:** Visually confirmed the alignment is now correct.
|
|
55
|
+
> * **Documentation:** Log entry added and a `fix:` commit has been made.
|
|
56
|
+
>
|
|
57
|
+
> Awaiting next `PrimaryGoal`."
|
|
@@ -0,0 +1,227 @@
|
|
|
1
|
+
# KnowzCode: Investigate Codebase
|
|
2
|
+
|
|
3
|
+
> **Automation Path:** On Claude Code, run `/kc:plan "your question"` to orchestrate this automatically.
|
|
4
|
+
|
|
5
|
+
## Your Mission
|
|
6
|
+
|
|
7
|
+
You are performing a focused investigation of the codebase to answer a specific question. You will conduct 1-3 research passes (based on question relevance) to gather evidence, then synthesize findings into actionable recommendations.
|
|
8
|
+
|
|
9
|
+
**Investigation Question**: $ARGUMENTS
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Phase 1: Context Loading (Do Once)
|
|
14
|
+
|
|
15
|
+
Read these files ONCE at the start:
|
|
16
|
+
- `knowzcode/knowzcode_project.md` - project context
|
|
17
|
+
- `knowzcode/knowzcode_architecture.md` - architecture overview
|
|
18
|
+
- `knowzcode/knowzcode_tracker.md` - existing NodeIDs
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Phase 2: Selective Investigation Passes
|
|
23
|
+
|
|
24
|
+
Conduct ONLY investigation passes that are relevant to the question.
|
|
25
|
+
|
|
26
|
+
### Step 1: Determine Which Passes Are Needed
|
|
27
|
+
|
|
28
|
+
Analyze the question and select investigation passes based on relevance:
|
|
29
|
+
|
|
30
|
+
| Pass | When to Include | Skip When |
|
|
31
|
+
|------|-----------------|-----------|
|
|
32
|
+
| **Code Exploration** | ALWAYS (provides code evidence) | Never skip - always needed |
|
|
33
|
+
| **Architecture & Patterns** | Question involves patterns, design, structure, consistency, layers | Simple lookup questions, bug hunts, "where is X?" |
|
|
34
|
+
| **Security & Performance** | Question involves auth, security, performance, data handling, risk | Code organization questions, refactoring questions |
|
|
35
|
+
|
|
36
|
+
**Question Type -> Pass Selection Guide:**
|
|
37
|
+
|
|
38
|
+
| Question Type | Example | Passes |
|
|
39
|
+
|---------------|---------|--------|
|
|
40
|
+
| Code location | "Where is user auth handled?" | Code Exploration only |
|
|
41
|
+
| Implementation check | "How is error handling done?" | Code Exploration + Architecture |
|
|
42
|
+
| Security concern | "Is the API properly secured?" | Code Exploration + Security |
|
|
43
|
+
| Full assessment | "Is the auth system well designed and secure?" | All 3 passes |
|
|
44
|
+
| Pattern consistency | "Are we consistent in how we handle dates?" | Code Exploration + Architecture |
|
|
45
|
+
|
|
46
|
+
### Step 2: Execute Investigation Passes
|
|
47
|
+
|
|
48
|
+
On platforms with agent orchestration, run these in parallel. Otherwise, execute sequentially.
|
|
49
|
+
|
|
50
|
+
**Pass 1: Code Exploration (ALWAYS INCLUDE)**
|
|
51
|
+
- Find code evidence to answer the question
|
|
52
|
+
- Constraints: Max 10 tool calls. Focus on 5 most relevant files
|
|
53
|
+
- Output: Code evidence with file paths and line numbers
|
|
54
|
+
|
|
55
|
+
**Pass 2: Architecture & Pattern Analysis (IF RELEVANT)**
|
|
56
|
+
- Evaluate patterns and design for this question
|
|
57
|
+
- Constraints: Max 8 tool calls. Focus on pattern consistency
|
|
58
|
+
- Output: Pattern observations with examples
|
|
59
|
+
|
|
60
|
+
**Pass 3: Security & Performance (IF RELEVANT)**
|
|
61
|
+
- Check security/performance aspects for this question
|
|
62
|
+
- Constraints: Max 8 tool calls. Only check relevant OWASP categories
|
|
63
|
+
- Output: Risk observations with severity levels
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## Phase 3: Synthesize Findings
|
|
68
|
+
|
|
69
|
+
**When ALL spawned agents return:**
|
|
70
|
+
|
|
71
|
+
1. Merge results into unified investigation report
|
|
72
|
+
2. Cross-reference findings from agents consulted
|
|
73
|
+
3. Identify agreements and conflicts (if multiple agents)
|
|
74
|
+
4. Formulate direct answer to the original question
|
|
75
|
+
5. Generate actionable recommendations
|
|
76
|
+
|
|
77
|
+
### Save Investigation Report
|
|
78
|
+
|
|
79
|
+
Save findings to `knowzcode/planning/investigation-{timestamp}.md`:
|
|
80
|
+
|
|
81
|
+
```markdown
|
|
82
|
+
# Investigation: {question summary}
|
|
83
|
+
|
|
84
|
+
**Question**: {$ARGUMENTS}
|
|
85
|
+
**Timestamp**: {timestamp}
|
|
86
|
+
**Agents Consulted**: {list agents actually spawned}
|
|
87
|
+
|
|
88
|
+
## Executive Summary
|
|
89
|
+
|
|
90
|
+
{Direct 2-3 sentence answer to the question}
|
|
91
|
+
|
|
92
|
+
## Detailed Findings
|
|
93
|
+
|
|
94
|
+
### Code Exploration (analyst)
|
|
95
|
+
{findings}
|
|
96
|
+
|
|
97
|
+
### Pattern Analysis (architect)
|
|
98
|
+
{findings}
|
|
99
|
+
|
|
100
|
+
### Security/Performance Assessment (reviewer)
|
|
101
|
+
{findings}
|
|
102
|
+
|
|
103
|
+
## Synthesis
|
|
104
|
+
|
|
105
|
+
**Key Findings**:
|
|
106
|
+
{consolidated bullet points}
|
|
107
|
+
|
|
108
|
+
**Cross-Agent Agreements**:
|
|
109
|
+
{where agents agree}
|
|
110
|
+
|
|
111
|
+
**Areas of Concern**:
|
|
112
|
+
{issues identified}
|
|
113
|
+
|
|
114
|
+
## Recommendations
|
|
115
|
+
|
|
116
|
+
| # | Action | Priority | Effort |
|
|
117
|
+
|---|--------|----------|--------|
|
|
118
|
+
| 1 | {action} | HIGH/MED/LOW | S/M/L |
|
|
119
|
+
| 2 | {action} | HIGH/MED/LOW | S/M/L |
|
|
120
|
+
| 3 | {action} | HIGH/MED/LOW | S/M/L |
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
## Phase 4: Present Findings
|
|
126
|
+
|
|
127
|
+
Present investigation results to user:
|
|
128
|
+
|
|
129
|
+
```markdown
|
|
130
|
+
## KnowzCode Investigation Complete
|
|
131
|
+
|
|
132
|
+
**Question**: {$ARGUMENTS}
|
|
133
|
+
**Agents Consulted**: {N} (in parallel)
|
|
134
|
+
|
|
135
|
+
### Summary
|
|
136
|
+
|
|
137
|
+
{Direct answer to the question}
|
|
138
|
+
|
|
139
|
+
### Key Findings
|
|
140
|
+
|
|
141
|
+
{3-5 bullet points summarizing discoveries}
|
|
142
|
+
|
|
143
|
+
### Recommendations
|
|
144
|
+
|
|
145
|
+
{numbered list of actionable improvements}
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
**Implementation Options:**
|
|
150
|
+
|
|
151
|
+
1. {First recommendation action}
|
|
152
|
+
2. {Second recommendation action}
|
|
153
|
+
3. {Third recommendation action}
|
|
154
|
+
|
|
155
|
+
Say "implement", "do it", or select an option (e.g., "option 1") to proceed with implementation.
|
|
156
|
+
Or say "that's all" if you just needed the information.
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## Phase 5: Action Listening Mode
|
|
162
|
+
|
|
163
|
+
**After presenting findings, enter Action Listening Mode.**
|
|
164
|
+
|
|
165
|
+
Monitor subsequent user messages for implementation triggers:
|
|
166
|
+
|
|
167
|
+
### Implementation Triggers (Transition to Phase 1A)
|
|
168
|
+
|
|
169
|
+
Detect these patterns in user's next message:
|
|
170
|
+
|
|
171
|
+
| Pattern | Example | Action |
|
|
172
|
+
|---------|---------|--------|
|
|
173
|
+
| Imperative verbs | "implement", "fix", "build", "add", "create" | Extract goal, proceed to Phase 1A |
|
|
174
|
+
| Confirmation words | "do it", "go ahead", "proceed", "yes", "let's do it" | Use top recommendation |
|
|
175
|
+
| Option selection | "option 1", "the first one", "#2", "do number 2" | Use selected recommendation |
|
|
176
|
+
| "Fix it" / "Make it work" | "fix it", "make it work", "just do it" | Use top recommendation |
|
|
177
|
+
|
|
178
|
+
### When Trigger Detected:
|
|
179
|
+
|
|
180
|
+
1. Extract implementation goal from:
|
|
181
|
+
- User's specific request (if provided)
|
|
182
|
+
- Selected option (if option number given)
|
|
183
|
+
- Top recommendation (if generic "do it")
|
|
184
|
+
|
|
185
|
+
2. Log investigation context for handoff:
|
|
186
|
+
```
|
|
187
|
+
Investigation findings available at: knowzcode/planning/investigation-{timestamp}.md
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
3. Transition to Phase 1A:
|
|
191
|
+
```markdown
|
|
192
|
+
**Transitioning to implementation...**
|
|
193
|
+
|
|
194
|
+
Goal extracted: "{extracted goal}"
|
|
195
|
+
Investigation context: Pre-loaded from investigation findings
|
|
196
|
+
|
|
197
|
+
Proceeding to Phase 1A (Impact Analysis)...
|
|
198
|
+
```
|
|
199
|
+
|
|
200
|
+
4. Pass investigation findings to Phase 1A:
|
|
201
|
+
- NodeIDs already identified -> pre-populate Change Set
|
|
202
|
+
- Security concerns -> carry forward as annotations
|
|
203
|
+
- Architecture observations -> carry forward as annotations
|
|
204
|
+
- Skip redundant discovery -> focus Phase 1A on validation
|
|
205
|
+
|
|
206
|
+
### Non-Trigger Responses
|
|
207
|
+
|
|
208
|
+
If user message does NOT contain implementation trigger:
|
|
209
|
+
- "ok thanks" -> End gracefully: "Investigation complete. Start Phase 1A when ready to implement."
|
|
210
|
+
- "tell me more about X" -> Provide additional detail from findings
|
|
211
|
+
- "what about Y?" -> Follow-up investigation (run additional passes)
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
## Logging
|
|
216
|
+
|
|
217
|
+
After investigation, log to `knowzcode/knowzcode_log.md`:
|
|
218
|
+
|
|
219
|
+
```markdown
|
|
220
|
+
---
|
|
221
|
+
**Type:** Investigation
|
|
222
|
+
**Timestamp:** {timestamp}
|
|
223
|
+
**Question:** {$ARGUMENTS}
|
|
224
|
+
**Finding:** {one-line summary}
|
|
225
|
+
**Status:** {Complete | Handoff to Phase 1A}
|
|
226
|
+
---
|
|
227
|
+
```
|