knowzcode 0.1.0 → 0.2.1

package/knowzcode/knowzcode_vaults.md

@@ -1,63 +1,189 @@
 # KnowzCode Vault Configuration
 
-Multi-vault routing configuration for intelligent vault selection based on query intent.
+Multi-vault routing configuration for intelligent vault selection based on query intent and write conditions.
 
 ---
 
 ## Connected Vaults
 
-> **No vaults configured yet.**
->
-> Run `/kc:register` to set up your account and auto-configure your first vault,
-> or `/kc:connect-mcp --configure-vaults` to add vaults interactively.
+### (not created)
+- **Name**: Code Patterns
+- **ID**:
+- **Type**: code
+- **Description**: Key learnings, gotchas, takeaways, and architecture insights from the codebase.
+- **Write Conditions**:
+  - After Phase 2A: implementation patterns and workarounds from TDD cycles
+  - After Phase 3: Pattern/Workaround/Performance learnings from WorkGroup scan
+- **Content Filter**: Pattern:, Workaround:, Performance:
+
+### (not created)
+- **Name**: Ecosystem Knowledge
+- **ID**:
+- **Type**: ecosystem
+- **Description**: Business rules, platform logic, conventions, decisions, and cross-system details. Used for lookups of details beyond scope of current codebase, including how other systems interact.
+- **Write Conditions**:
+  - After Phase 1A: scope decisions, risk assessment
+  - After Phase 2B: security findings, quality decisions
+  - After Phase 3: Decision/Convention/Security/Integration learnings
+- **Content Filter**: Decision:, Convention:, Security:, Integration:, Scope:
+
+### (not created)
+- **Name**: Finalizations
+- **ID**:
+- **Type**: finalizations
+- **Description**: Final summaries at WorkGroup completion. All finalization details documenting complete execution and outcomes. Written only when work is verified and WorkGroup is marked completed.
+- **Write Conditions**:
+  - After Phase 3: full WorkGroup summary with goal, NodeIDs, audit score, decisions, outcomes
+- **Content Filter**: (completion records)
 
-<!--
-When vaults are configured, they appear here in this format:
+---
 
-### vault-abc123-def456
-- **Name**: Project Codebase
-- **ID**: vault-abc123-def456
-- **Type**: code
-- **Description**: Questions about the actual source code, current file structure, implementations, and how things work today. Use for "where is X defined?", "how does Y work?", "find implementations of Z".
+## Vault Types
+
+| Type | Purpose | Read By | Written By | Example Queries |
+|------|---------|---------|------------|-----------------|
+| **code** | Implementation patterns, workarounds, performance | knowz-scout, knowz-scribe, agents | knowz-scribe | "Find auth middleware pattern", "Retry logic workaround" |
+| **ecosystem** | Decisions, conventions, security, integrations, business rules | knowz-scout, knowz-scribe, agents | knowz-scribe | "Error handling conventions", "Why Redis over Memcached?" |
+| **finalizations** | WorkGroup completion summaries, outcome records | knowz-scout, knowz-scribe | knowz-scribe | "What happened in WG-feat-auth?", "Recent completions" |
 
-### vault-xyz789-ghi012
-- **Name**: Engineering Knowledge
-- **ID**: vault-xyz789-ghi012
-- **Type**: research
-- **Description**: Organizational decisions, architectural patterns, team conventions, and learnings. Use for "why did we choose X?", "what's our convention for Y?", "best practices for Z".
--->
+> **Types are user-configurable labels, not framework constants.** Users can add, rename, or create custom vault types freely. The 3 defaults above cover common needs. For example, teams needing compliance tracking can add an `enterprise` type.
+>
+> **Backwards compatibility**: `research`, `domain`, and `platform` are aliases for `ecosystem`. `sessions` is an alias for `finalizations`. Existing vaults configured with these types continue to work — agents treat aliases identically when resolving vault targets.
 
 ---
 
 ## Vault Routing Rules
 
-Routing rules determine which vault to query based on the type of question or operation.
-
-### Default Rules (when vaults are configured)
+### Read Routing (knowz-scout + agents)
 
 | Query Type | Description | Target Vault Type |
 |------------|-------------|-------------------|
-| **Code questions** | Implementations, files, structure, "where is X?" | `code` |
-| **Convention questions** | Patterns, decisions, best practices, "why did we?" | `research` |
-| **Learning capture** | Saving new insights, patterns, decisions | `research` (prompt if multiple) |
-| **Standards queries** | Team standards, compliance rules, requirements | `enterprise` |
-| **Audit trail push** | Completion records, audit results | `enterprise` |
+| **Code patterns** | Implementations, patterns, "how did we build X?" | `code` |
+| **Decisions / conventions** | Past decisions, best practices, "why did we?" | `ecosystem` |
+| **Integration questions** | Third-party APIs, platform behaviors | `ecosystem` |
+| **Standards / compliance** | Team standards, audit results | user's enterprise vault (if configured) |
+| **Session history** | Past WorkGroups, outcomes | `finalizations` |
+
+### Write Routing (knowz-scribe)
+
+| Learning Category | Target Vault Type | Title Prefix |
+|-------------------|-------------------|--------------|
+| Pattern | `code` | `Pattern:` |
+| Workaround | `code` | `Workaround:` |
+| Performance | `code` | `Performance:` |
+| Decision | `ecosystem` | `Decision:` |
+| Convention | `ecosystem` | `Convention:` |
+| Security | `ecosystem` | `Security:` |
+| Integration | `ecosystem` | `Integration:` |
+| Scope | `ecosystem` | `Scope:` |
+| Completion record | `finalizations` | `Completion:` |
+| Audit trail (enterprise) | user's enterprise vault | `Audit:` |
 
 ### How Routing Works
 
-1. **For queries**: Agent reads vault descriptions and matches query intent
-2. **For writes**: If one research vault exists, use it; if multiple, prompt user
-3. **Fallback**: If no match found, query the default research vault
+1. **For reads**: Agent reads vault descriptions and matches query intent to vault type
+2. **For writes**: Knowz-scribe matches learning category to vault type using the write routing table, then applies the vault's content filter to format the payload
+3. **Fallback**: If no specific match, use the first vault of type `ecosystem`. If only one vault exists, use it for everything
 
 ---
 
-## Vault Types
+## Uncreated Vault Detection
+
+Default vault entries ship with an empty **ID** field (null GUID), indicating "not yet created on server."
+
+### Detection Points
+
+Uncreated vaults are detected at multiple points in the workflow:
+
+1. **`/kc:register` and `/kc:connect-mcp`** — detect empty IDs during initial setup and prompt to create vaults
+2. **`/kc:work`, `/kc:plan`, and `/kc:audit`** — detect empty IDs during the MCP Probe at workflow start. These commands always call `list_vaults()` regardless of whether vault IDs exist, then present a Vault Setup table showing each uncreated vault's name, type, description, and which phases write to it. The user can create all, select specific vaults, or skip (proceeding without knowledge capture).
+
+### Creation Flow
+
+When uncreated vaults are detected, the user sees:
+
+```markdown
+## Vault Setup
+
+Your Knowz API key is valid and MCP is connected, but {N} default vault(s) haven't been created yet.
+Creating vaults enables knowledge capture throughout the workflow:
+
+| Vault | Type | Description | Written During |
+|-------|------|-------------|----------------|
+```
+
+Table rows are built dynamically from uncreated entries — only showing vaults that haven't been created. The "Written During" column is derived from each vault's Write Conditions field.
+
+Options: **A) Create all** (recommended), **B) Select which to create**, **C) Skip**.
+
+On confirmation, each vault is created via the MCP `create_vault(name, description)` tool. If `create_vault` is not available, the command falls back to matching by name against `list_vaults()` results. The entry's **ID** field is updated with the server-returned vault ID. The H3 heading is updated from `(not created)` to the vault ID.
+
+---
+
+## Write Conditions and Content Filters
+
+Each vault type defines when it accepts writes (Write Conditions) and how content should be formatted (Content Filter).
+
+### code
+
+**Write Conditions**: Learning category is Pattern, Workaround, or Performance.
+
+**Content Filter**:
+```
+[CONTEXT] {where the pattern/workaround was encountered}
+[PATTERN] {what was built or discovered}
+[EXAMPLE] {code snippet or usage example}
+[TAGS] {learning category, domain, language}
+```
+
+### ecosystem
+
+**Write Conditions**: Learning category is Decision, Convention, Security, Scope, or Integration.
+
+**Content Filter**:
+```
+[CONTEXT] {what prompted the decision or convention}
+[INSIGHT] {the decision, convention, security finding, or integration detail}
+[RATIONALE] {why this approach was chosen}
+[TAGS] {learning category, domain}
+```
+
+### finalizations
+
+**Write Conditions**: Phase 3 finalization — WorkGroup completion record.
 
-| Type | Purpose | Example Queries |
-|------|---------|-----------------|
-| **code** | Indexed source code (AST-chunked) | "Find auth middleware", "Where is PaymentService?" |
-| **research** | Architecture, conventions, learnings | "Error handling conventions", "Why Redis over Memcached?" |
-| **enterprise** | Team standards, audit trails, compliance | "Team standards for React", "Audit trail for kc-feat-auth" |
+**Content Filter**:
+```
+[GOAL] {original goal from WorkGroup}
+[OUTCOME] {success | partial | abandoned}
+[NODES] {NodeIDs changed}
+[DURATION] {phases completed, e.g. "1A-3"}
+[TAGS] {finalization, domain, outcome}
+```
+
+---
+
+## Single Vault Model
+
+KnowzCode works with a single vault. If only one vault is configured (regardless of its declared type), all reads and writes route to it. This is the recommended starting point:
+
+```
+┌──────────────────────────────────────────────────────┐
+│                   KnowzCode Vault                    │
+│                                                      │
+│  Purpose: All learnings, decisions, patterns, etc.   │
+│  Read by: knowz-scout, knowz-scribe, all agents       │
+│  Written by: knowz-scribe, /kc:learn                  │
+│  Code search: Uses local grep/glob (no code vault)   │
+│                                                      │
+└──────────────────────────────────────────────────────┘
+```
+
+**Why start with one vault?**
+- Simpler onboarding — no vault type decisions needed
+- Code search works with grep/glob for most projects
+- MCP vault is optimized for organizational knowledge
+- Add specialized vaults later via `/kc:connect-mcp --configure-vaults`
 
 ---
 
@@ -69,36 +195,39 @@ You can manually add vaults by editing this file. Use this format:
 ### {vault-id}
 - **Name**: {Display Name}
 - **ID**: {vault-id}
-- **Type**: code | research
+- **Type**: code | ecosystem | finalizations | {custom}
 - **Description**: {Detailed description of what this vault contains. Be specific about what types of questions should be routed here. Include example queries.}
+- **Write Conditions**: {When knowz-scribe should write to this vault}
+- **Content Filter**: {Format template for create_knowledge content}
 ```
 
 **Tips for good descriptions:**
-- Be specific about content type (source code vs documentation)
+- Be specific about content type (patterns vs decisions vs integrations)
 - Include example queries that should route to this vault
 - Mention key topics or domains covered
-- Describe the time period or version if relevant
+- Write conditions should reference learning categories from the routing table
 
 ---
 
-## Configuration Commands
+## Integration with Agents
 
-- `/kc:register` - Create account and auto-configure first vault
-- `/kc:connect-mcp --configure-vaults` - Interactive vault setup
-- `/kc:status` - Check vault connection status
+| Agent | Vault Interaction | Purpose |
+|-------|-------------------|---------|
+| `knowz-scout` | Read all configured vaults | Find past decisions, conventions, patterns |
+| `knowz-scribe` | Read and write to matching vaults | Route and capture learnings |
+| `analyst` | Read via knowz-scout | Past decisions + affected code patterns |
+| `architect` | Read via knowz-scout | Conventions + implementation examples |
+| `builder` | Read via knowz-scout | Best practices + similar patterns |
+| `reviewer` | Read via knowz-scout | Standards + precedent checks |
+| `closer` | Triggers knowz-scribe captures | Finalization learnings |
 
----
+**Fallback behavior**: If vault routing cannot determine the best vault, agents use the first `ecosystem`-type vault or prompt the user.
 
-## Integration with Agents
-
-When configured, agents automatically route queries to the appropriate vault:
+---
 
-| Agent | Uses Vault Routing For |
-|-------|------------------------|
-| `analyst` | Finding affected code + past decisions |
-| `architect` | Implementation examples + conventions |
-| `builder` | Similar patterns + best practices |
-| `reviewer` | Standards + precedent checks |
-| `closer` | Duplicate checking + learning capture |
+## Configuration Commands
 
-**Fallback behavior**: If vault routing cannot determine the best vault, agents use the first matching vault of the required type or prompt the user.
+- `/kc:register` - Create account and auto-configure first vault
+- `/kc:connect-mcp --configure-vaults` - Interactive vault setup
+- `/kc:status` - Check vault connection status
+- `/kc:learn "insight"` - Manually create learning (routes via knowz-scribe if available, direct write otherwise)

package/knowzcode/mcp_config.md

@@ -12,10 +12,10 @@
 
 ## Vaults
 
-### Research Vault (Primary)
+### Ecosystem Vault (Primary)
 - **Vault ID**: (not configured)
 - **Vault Name**: (not configured)
-- **Purpose**: Learnings, conventions, decisions, patterns
+- **Purpose**: Decisions, conventions, security practices, integrations, business rules, domain knowledge
 - **Auto-configured**: No
 
 **Query Patterns (when configured):**
@@ -23,36 +23,36 @@
 - "What patterns for API versioning?"
 - "Security best practices we use"
 - "Why did we choose Redis cache?"
+- "Stripe webhook setup"
+
+> **Backwards compatibility**: Vaults previously configured as type `research`, `domain`, or `platform` are treated identically to `ecosystem`. No migration needed.
 
 ### Code Vault (Optional)
 - **Vault ID**: (not configured)
 - **Vault Name**: (not configured)
-- **Purpose**: Indexed source code for semantic search (AST-chunked)
+- **Purpose**: Implementation patterns, workarounds, performance optimizations
 
 **Note**: Code search works well with local grep/glob for most projects.
-Configure a code vault for large codebases (50k+ LOC) where semantic search
-provides significant benefit.
+Configure a code vault for teams that want semantic search over implementation patterns and reusable utilities.
 
 **Query Patterns (when configured):**
-- "Find all auth middleware"
-- "Where is PaymentService?"
-- "Show database migrations"
-- "JWT validation code"
+- "Retry logic pattern"
+- "Workaround for rate limiting"
+- "Performance optimization for bulk inserts"
+- "JWT validation pattern"
 
-### Enterprise Vault (Optional)
+### Finalizations Vault (Optional)
 - **Vault ID**: (not configured)
 - **Vault Name**: (not configured)
-- **Purpose**: Team-wide standards, audit trails, compliance records
-- **Auto-configured**: No
+- **Purpose**: WorkGroup completion summaries, outcome records, finalization details
 
-**Note**: Enterprise vault is for organizations that want centralized standards
-and audit trails across projects. Configure via `knowzcode/enterprise/compliance_manifest.md`
-with `mcp_compliance_enabled: true`.
+**Note**: Finalizations vault provides a searchable history of completed work.
+Useful for teams that want to review past work patterns and outcomes.
 
 **Query Patterns (when configured):**
-- "Team standards for React projects"
-- "Security requirements for API endpoints"
-- "Audit trail for WorkGroup kc-feat-auth"
+- "What happened in WG-feat-auth?"
+- "Recent completion outcomes"
+- "Goals we worked on last week"
 
 ---
 
@@ -61,53 +61,56 @@ with `mcp_compliance_enabled: true`.
 KnowzCode recommends starting with a **single "KnowzCode" vault** for simplicity:
 
 ```
-┌─────────────────────────────────────────────────────────┐
-│                    KnowzCode Vault                       │
-│                                                         │
-│  Purpose: Learnings, conventions, decisions, patterns   │
-│  Used by: /kc:learn, closer, agents                     │
-│  Code search: Uses local grep/glob (no code vault)      │
-│                                                         │
-└─────────────────────────────────────────────────────────┘
+┌──────────────────────────────────────────────────────┐
+│                   KnowzCode Vault                    │
+│                                                      │
+│  Purpose: All learnings, decisions, patterns, etc.   │
+│  Read by: knowz-scout, knowz-scribe, all agents       │
+│  Written by: knowz-scribe, knowz-scout, /kc:learn    │
+│  Code search: Uses local grep/glob (no code vault)   │
+│                                                      │
+└──────────────────────────────────────────────────────┘
 ```
 
 **Why single vault?**
-- Simpler onboarding (no "what's code vault vs research vault?")
+- Simpler onboarding (no vault type decisions needed)
 - Code search works fine with grep/glob for most projects
 - MCP vault is optimized for organizational knowledge, not code indexing
-- Advanced users can add code vault later via `/kc:connect-mcp --configure-vaults`
+- Advanced users can add specialized vaults later via `/kc:connect-mcp --configure-vaults`
 
 ---
 
 ## Usage in Agents
 
-| Agent | Research Vault | Code Vault | Purpose |
-|-------|----------------|------------|---------|
-| analyst | Query | Query (if configured) | Find past decisions + affected code |
-| architect | Query | Query (if configured) | Conventions + implementation examples |
-| builder | Query | Query (if configured) | Best practices + similar patterns |
-| reviewer | Query | Query (if configured) | Standards + precedent check |
-| closer | **Write** | - | Capture learnings |
+| Agent | Vault Interaction | Purpose |
+|-------|-------------------|---------|
+| knowz-scout | Read all configured vaults | Find past decisions, conventions, patterns |
+| knowz-scribe | Read and write to matching vaults | Route learnings per write conditions |
+| analyst | Read via knowz-scout | Past decisions + affected code patterns |
+| architect | Read via knowz-scout | Conventions + implementation examples |
+| builder | Read via knowz-scout | Best practices + similar patterns |
+| reviewer | Read via knowz-scout | Standards + precedent check |
+| closer | Triggers knowz-scribe captures | Finalization learnings |
 
-**Fallback behavior**: When Code Vault is not configured, agents use local grep/glob
-for code search. This works well for most projects.
+**Fallback behavior**: When specialized vaults are not configured, agents use local grep/glob
+for code search and the single vault for all knowledge queries.
 
 ---
 
 ## MCP Tools Reference
 
-### Query Tools (Read)
+### Query Tools (Read — used by knowz-scout)
 
 **search_knowledge(query, vaultId, limit)**
 - Vector similarity search across indexed content
 - Use for: finding code patterns or documentation
-- Example: `search_knowledge("authentication logic", research_vault_id, 10)`
+- Example: `search_knowledge("authentication logic", ecosystem_vault_id, 10)`
 
 **ask_question(question, vaultId, researchMode)**
 - AI-powered question answering with document synthesis
 - `researchMode: false` - Quick answer (faster)
 - `researchMode: true` - Comprehensive answer (8000+ tokens, multi-document)
-- Example: `ask_question("What are our error handling conventions?", research_vault_id, true)`
+- Example: `ask_question("What are our error handling conventions?", ecosystem_vault_id, true)`
 
 **find_entities(entityType, query, limit)**
 - Find people, locations, or events extracted from knowledge base
@@ -121,7 +124,7 @@ for code search. This works well for most projects.
 **list_vaults(includeStats)**
 - List all accessible vaults with optional statistics
 
-### Write Tools (Learning Capture)
+### Write Tools (used by knowz-scribe and /kc:learn)
 
 **create_knowledge(content, title, knowledgeType, vaultId, tags, source)**
 - Create new knowledge item in vault
@@ -129,22 +132,30 @@ for code search. This works well for most projects.
 - Example:
   ```json
   {
-    "content": "[CONTEXT]...\n[INSIGHT]...\n[EXAMPLE]...",
-    "title": "Pattern: JWT Refresh Flow",
+    "content": "[CONTEXT]...\n[INSIGHT]...\n[RATIONALE]...",
+    "title": "Decision: JWT Refresh Flow",
     "knowledgeType": "Note",
-    "vaultId": "{research_vault_id}",
-    "tags": ["security", "jwt", "patterns"],
+    "vaultId": "{ecosystem_vault_id}",
+    "tags": ["security", "jwt", "decision"],
     "source": "KnowzCode WorkGroup WG-feat-auth-20260128"
   }
   ```
 
+**create_vault(name, description)**
+- Create a new vault on the Knowz server
+- `name`: Display name for the vault (e.g., "Code Patterns")
+- `description`: Description of the vault's purpose and content
+- Returns the created vault's ID
+- Used during vault setup when default entries have empty IDs
+- **Note**: Availability depends on MCP server version. If not available, fall back to matching by name against `list_vaults()` results.
+
 ---
 
 ## Auto-Learning Configuration
 
 - **Enabled**: Yes
 - **Prompt on Detection**: Yes
-- **Learning Categories**: Pattern, Decision, Workaround, Performance, Security, Convention
+- **Learning Categories**: Pattern, Decision, Workaround, Performance, Security, Convention, Integration
 
 ### Detection Signals
 
@@ -154,6 +165,20 @@ Learnings are auto-detected when WorkGroup contains:
 - **Workaround signals**: "workaround", "limitation", "temporary"
 - **Performance signals**: "optimized", "reduced from X to Y"
 - **Security signals**: "security", "vulnerability", "sanitize"
+- **Integration signals**: "integrated with", "API behavior", "third-party"
+
+### Learning Category Routing
+
+| Category | Target Vault Type |
+|----------|-------------------|
+| Pattern | `code` |
+| Workaround | `code` |
+| Performance | `code` |
+| Decision | `ecosystem` |
+| Convention | `ecosystem` |
+| Security | `ecosystem` |
+| Integration | `ecosystem` |
+| Completion record | `finalizations` |
 
 ---
 
@@ -163,4 +188,4 @@ Learnings are auto-detected when WorkGroup contains:
 - `/kc:connect-mcp` - Configure MCP server (use existing API key)
 - `/kc:connect-mcp --configure-vaults` - Reconfigure vault IDs
 - `/kc:status` - Check connection status and vault info
-- `/kc:learn "insight"` - Manually create learning in research vault
+- `/kc:learn "insight"` - Manually create learning (routes via knowz-scribe if available)

package/knowzcode/platform_adapters.md

@@ -68,7 +68,7 @@ All commands work without MCP — it enhances but never blocks.
 
 ## OpenAI Codex (AGENTS.md)
 
-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).
+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). Codex (2026) also supports `SKILL.md` files for discoverable skills — these appear as available commands in the Codex UI. `AGENTS.md` remains the primary instruction mechanism for KnowzCode methodology.
 
 ```markdown
 # KnowzCode Development Methodology
@@ -152,6 +152,45 @@ For single-file, <50 line, no-ripple-effect changes:
 
 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`.
 
+### Native Commands (`.gemini/commands/kc/*.toml`)
+
+Gemini CLI (2026) supports native custom commands via TOML files in `.gemini/commands/`. Subdirectory namespacing gives the `/kc:` prefix automatically:
+
+```toml
+# .gemini/commands/kc/work.toml
+description = "Start a new KnowzCode development workflow"
+prompt = """Read knowzcode/knowzcode_loop.md. Follow Phase 1A→3 workflow for:
+<ARGS/>
+Read knowzcode/knowzcode_project.md for project context.
+Read knowzcode/knowzcode_tracker.md for active work."""
+```
+
+```toml
+# .gemini/commands/kc/plan.toml
+description = "Research before implementing"
+prompt = """Read knowzcode/knowzcode_loop.md and knowzcode/knowzcode_project.md.
+Investigate the codebase for: <ARGS/>
+Present findings with options. Say 'implement' to transition to /kc:work."""
+```
+
+```toml
+# .gemini/commands/kc/fix.toml
+description = "Quick targeted fix (micro-fix workflow)"
+prompt = """Read knowzcode/knowzcode_loop.md section on Micro-Fix.
+Apply a targeted fix for: <ARGS/>
+Run tests, log a MicroFix entry, commit with fix: prefix."""
+```
+
+```toml
+# .gemini/commands/kc/audit.toml
+description = "Run quality audit against specs"
+prompt = """Read knowzcode/knowzcode_loop.md Phase 2B.
+Perform a READ-ONLY audit comparing implementation against specs in knowzcode/specs/.
+Report completion percentage, gaps, and security concerns for: <ARGS/>"""
+```
+
+Gemini also supports extensions (`gemini-extension.json`) for tool integration and `@file.md` imports for including methodology files directly in prompts.
+
 ```markdown
 # KnowzCode Development Methodology
 
@@ -212,7 +251,7 @@ Single file, <50 lines, no ripple effects:
 
 ## Cursor (`.cursor/rules/knowzcode.mdc`)
 
-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.
+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. Cursor 1.6+ (2026) also supports `.cursor/commands/*.md` for custom slash commands (beta) and reads `AGENTS.md` for agent instructions.
 
 ```markdown
 ---
@@ -276,7 +315,7 @@ Before any feature work, read:
 
 ## GitHub Copilot (.github/copilot-instructions.md)
 
-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).
+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). Copilot (2026) now supports `.github/agents/*.agent.md` files with YAML frontmatter including `tools`, `handoffs`, `agents` (subagents), and `model` fields. KnowzCode phases map well to handoff chains between agent definitions.
 
 ```markdown
 # KnowzCode Development Methodology
@@ -323,7 +362,7 @@ STOP and get user approval:
 
 ## Windsurf (`.windsurf/rules/knowzcode.md`)
 
-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.
+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. Windsurf also supports `.windsurf/workflows/*.md` for custom commands invoked as `/workflow-name` — KnowzCode workflows can be defined as individual workflow files for each phase.
 
 ```markdown
 # KnowzCode Development Methodology