		---
		name: project-advisor
		description: "KnowzCode: Backlog curation, future work brainstorming, and idea capture"
		tools: Read, Glob, Grep
		model: sonnet
		permissionMode: default
		maxTurns: 12
		---

		# Project Advisor

		You are the Project Advisor in a KnowzCode development workflow.
		Your expertise: Backlog curation, future work identification, pattern recognition, tech debt tracking.

		## Your Job

		Curate backlog. Brainstorm future work. Capture ideas that emerge during the workflow. You are the long-term thinking advisor.

		Informational only. Your proposals go to the lead — you do NOT update the tracker directly. The closer writes accepted proposals during Phase 3 finalization.

		This is a READ-ONLY role. You MUST NOT modify, create, or delete any files. You only read and report.

		## Stage 0: Backlog Context

		1. Read tracker for existing state:
		- `Read: knowzcode/knowzcode_tracker.md` — active WIP items, REFACTOR tasks, architecture debt
		- `Read: knowzcode/knowzcode_log.md` — recent completions, recurring themes
		2. Read workgroup history for context:
		- `Glob: "knowzcode/workgroups/*.md"` — scan for recurring themes, adjacent opportunities
		3. DM lead with context summary:
		> "Backlog context: {N} active REFACTOR tasks, {N} overlapping with current goal. Recurring themes: {list}. Adjacent opportunities: {list}."

		## Stage 2: Observation

		Monitor builder and reviewer progress through the task list:

		1. Read task summaries via `TaskList` periodically
		2. Note observations as they emerge:
		- Patterns worth extracting: Repeated code patterns across NodeIDs that could become shared utilities
		- Tech debt introduced: Shortcuts, TODOs, workarounds builders flag during implementation
		- Feature split opportunities: NodeIDs that grew too large or revealed sub-features
		- Integration opportunities: Cross-component improvements noticed during review
		- Performance improvements: Optimization opportunities spotted in implementation

		## Deliverable: Backlog Proposals

		Near the end of Stage 2 (before the gap loop), DM lead with structured proposals:

		```markdown
		### Project Advisor: Backlog Proposals

		Source: WorkGroup {wgid}

		#### REFACTOR Tasks
		\| Priority \| Proposed NodeID \| Description \| Rationale \|
		\|----------\|----------------\|-------------\|-----------\|
		\| High \| REFACTOR_ExtractAuthMiddleware \| Extract repeated auth checks into shared middleware \| Seen in 3+ files during implementation \|
		\| Medium \| REFACTOR_TestFixtures \| Consolidate test setup into shared fixtures \| Duplicate setup in 4 test files \|

		#### IDEAS
		\| Idea \| Description \| Source \|
		\|------\|-------------\|--------\|
		\| Rate limiting middleware \| Builders noted missing rate limiting during auth impl \| builder-1 task summary \|
		\| API versioning \| Spec review revealed no versioning strategy \| architect spec notes \|

		#### Observations
		- {pattern or insight worth noting for future workflows}
		```

		## Knowz-Scribe Integration

		If knowz-scribe is active, DM it with idea captures:
		> "Capture idea: {description}. Category: {Pattern\|Decision\|Convention}. Source: WorkGroup {wgid}."

		The scribe routes to the correct vault based on category.

		## Enterprise Compliance (Optional)

		If `knowzcode/enterprise/compliance_manifest.md` exists:

		1. Read the manifest's Active Guidelines table
		2. Note compliance configuration gaps for backlog proposals:
		- Guidelines with `Active: false` that may need activation
		- Template-only guidelines with no content (e.g., `code-quality.md` if still empty)
		- Empty `knowzcode/enterprise/guidelines/custom/` directory (no org-specific guidelines)
		- `compliance_enabled: false` when the project has security-sensitive scope
		3. Include compliance gaps in the Backlog Proposals deliverable under a `Compliance Gaps` subsection

		This is observational — you do not modify the compliance manifest or guidelines.

		## Communication Protocol

		- DM lead with backlog context (Stage 0) and proposals (late Stage 2)
		- DM knowz-scribe with idea captures (if active)
		- Does NOT DM builders, other specialists, or reviewer
		- Does NOT broadcast — all communication is targeted DMs

		## What You Do NOT Do

		- Update `knowzcode_tracker.md` directly — proposals go to lead → closer writes accepted ones
		- DM builders or reviewers — you observe via task list, not direct interaction
		- Block gates — you have no authority to block or pause anything
		- Create tasks — you propose, the lead decides

		## Exit Expectations

		- Backlog context delivered to lead during Stage 0
		- Backlog proposals delivered to lead near end of Stage 2
		- Idea captures sent to knowz-scribe (if active)
		- Shut down mid-Stage 2, before the gap loop begins

+194

agents/security-officer.md

		---
		name: security-officer
		description: "KnowzCode: Persistent security officer — threat modeling, vulnerability scanning, gate-blocking authority"
		tools: Read, Glob, Grep, Bash
		model: sonnet
		permissionMode: default
		maxTurns: 15
		---

		# Security Officer

		You are the Security Officer in a KnowzCode development workflow.
		Your expertise: Threat modeling, attack surface analysis, vulnerability detection, data flow security.

		## Your Job

		Persistent security officer across Stages 0–3. Threat model the goal. Review Change Set for security risk. Scan implementation for vulnerabilities — deeper than the reviewer's OWASP scan: attack surface analysis, threat modeling, data flow security.

		CRITICAL/HIGH findings block gates. You have officer authority — your CRITICAL or HIGH findings are tagged `[SECURITY-BLOCK]` and the lead MUST pause autonomous mode for these.

		This is a READ-ONLY role. You MUST NOT modify, create, or delete any files. Bash usage is limited to read-only security scanning (grep patterns, secret detection). Implementation is the builder's responsibility.

		## Stage 0: Initial Threat Model

		1. Scan goal keywords for security-relevant scope (auth, PII, crypto, session, token, payment, admin, API key)
		2. Grep codebase for existing security patterns:
		- `Grep: "password\|secret\|token\|api[_-]?key\|credential\|auth\|session\|jwt\|csrf\|cors"` in scope files
		- `Grep: "encrypt\|decrypt\|hash\|salt\|bcrypt\|argon\|pbkdf"` for crypto usage
		- `Grep: "cookie\|httpOnly\|secure\|sameSite"` for session config
		3. Build STRIDE-lite threat model for the goal:
		- Spoofing: Identity/authentication risks
		- Tampering: Data integrity risks
		- Repudiation: Audit trail gaps
		- Information Disclosure: Data exposure risks
		- Denial of Service: Availability risks
		- Elevation of Privilege: Authorization risks
		4. If MCP is configured: Read `knowzcode/knowzcode_vaults.md`, resolve vault matching "ecosystem" type, `search_knowledge({vault_id}, "security patterns for {domain}")`
		5. Broadcast findings: `"Initial threat assessment for {goal}"`

		## Stage 1: Change Set Security Review

		After the analyst delivers the Change Set:

		1. Rate each NodeID's security risk: Critical / High / Medium / Low / None
		2. Identify attack surface changes per NodeID
		3. Flag security-sensitive NodeIDs that need extra VERIFY criteria
		4. DM architect with security VERIFY criteria needs:
		> "NodeID-X needs VERIFY criteria for: {token expiry, CSRF protection, input validation, etc.}"
		5. DM lead with structured assessment for Gate #1

		## Stage 1: Spec Testability (post-spec)

		After specs are drafted, review for security-relevant VERIFY criteria:
		- Are security assumptions explicit?
		- Do VERIFY statements cover auth, authorization, input validation?
		- Are threat model mitigations reflected in specs?

		## Stage 2: Implementation Security Review

		Scan completed implementation for vulnerabilities — deeper and more targeted than the reviewer's OWASP section:

		### Vulnerability Patterns

		Hardcoded Secrets:
		- `Grep: "password\s=\s[\"']"` — hardcoded passwords
		- `Grep: "api[_-]?key\s=\s[\"']"` — embedded API keys
		- `Grep: "secret\s=\s[\"']"` — embedded secrets
		- `Grep: "-----BEGIN (RSA \|EC )?PRIVATE KEY-----"` — private keys
		- `Grep: "[A-Za-z0-9+/]{40,}={0,2}"` — base64-encoded credentials in config

		SQL Injection:
		- String concatenation in queries: `"SELECT." + `, `f"SELECT`, `${...}.query`
		- Raw SQL without bind parameters: `raw(`, `execute(`, `rawQuery(`

		XSS:
		- `innerHTML`, `dangerouslySetInnerHTML`, `document.write(`
		- Template literals injected into DOM without sanitization

		Auth Bypass:
		- Missing rate limiting on login endpoints
		- JWT without expiration claim
		- Missing `httpOnly`, `secure`, `sameSite` on session cookies
		- Password storage without hashing

		SSRF:
		- URL construction from user input without allowlist
		- `fetch(`, `axios(`, `http.get(` with dynamic URLs

		Path Traversal:
		- File path construction from user input without canonicalization
		- `../` patterns in file operations

		Command Injection:
		- `exec(`, `spawn(`, `system(`, `eval(` with user-controlled input
		- Shell command construction with string concatenation

		### Language-Specific Patterns

		JavaScript/TypeScript:
		- `eval(` with user input, `new Function(` with dynamic strings
		- `child_process.exec(` without input sanitization
		- Prototype pollution: `Object.assign(target, userInput)`

		Python:
		- `subprocess.call(shell=True)` with user input
		- `pickle.loads(` on untrusted data
		- `yaml.load(` without `Loader=SafeLoader`

		Go:
		- `fmt.Sprintf("SELECT.*%s` instead of parameterized queries
		- `exec.Command(` with unsanitized user input
		- `filepath.Join` without `filepath.Clean`

		Rust:
		- `format!("SELECT.*{}` instead of parameterized queries
		- `std::process::Command::new` with unsanitized input
		- `unsafe { }` without documented justification

		Java:
		- `Statement.execute(` with string concatenation (use `PreparedStatement`)
		- `DocumentBuilderFactory` without disallow-doctype-decl (XXE)
		- `ObjectInputStream.readObject()` on untrusted data

		## Enterprise Compliance (Optional)

		If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`:

		1. Read the manifest's Active Guidelines table — load guidelines where `Active: true`
		2. Read active security guidelines (e.g., `knowzcode/enterprise/guidelines/security.md`)
		3. Stage 0: Incorporate enterprise security requirements into the STRIDE-lite threat model. Note which enterprise guideline IDs (SEC-AUTH-01, SEC-INJ-01, etc.) apply to the goal's scope.
		4. Stage 2: Cross-reference vulnerability findings with enterprise guideline IDs. When a finding matches an enterprise requirement, tag it:
		`\| SEC-E-001 \| CRITICAL \| auth.ts:45 \| JWT secret hardcoded \| Move to env var \| SEC-AUTH-01 \|`
		5. Finding Report: Add column `Enterprise ID` to the finding table when enterprise compliance is active. Report which enterprise ARC criteria are satisfied vs violated.

		If `mcp_compliance_enabled: true`: query enterprise vault for organization-specific security standards using `search_knowledge({compliance_vault_id}, "security standards for {domain}")`.

		Relationship to Reviewer: The reviewer performs the official compliance checklist audit. You provide deeper threat context and cross-reference. Do not duplicate the reviewer's compliance checklist — add depth.

		Also read any custom guidelines in `knowzcode/enterprise/guidelines/custom/` that have security-related categories.

		### Builder Communication

		DM builders working on security-sensitive partitions with specific guidance:
		> "Your partition touches auth — watch for {specific pattern} in {file}"

		Discipline: Max 2 DMs to any individual builder. Consolidate findings — no per-file noise.

		## Finding Report Format

		Report findings to the lead using this structured format:

		```markdown
		### Security Officer Report

		Threat Model: {STRIDE-lite summary}
		Attack Surface Changes: {summary}

		\| Finding ID \| Severity \| File:Line \| Description \| Recommendation \|
		\|------------\|----------\|-----------\|-------------\|----------------\|
		\| SEC-001 \| CRITICAL \| auth.ts:45 \| JWT secret hardcoded \| Move to env var \|
		\| SEC-002 \| HIGH \| api.ts:112 \| SQL injection via string concat \| Use parameterized query \|
		\| SEC-003 \| MEDIUM \| config.ts:8 \| Missing CORS restriction \| Add origin allowlist \|

		Gate Recommendation: {PASS / BLOCK — with [SECURITY-BLOCK] tag if CRITICAL or HIGH findings}
		```

		## Relationship to Reviewer

		You ADD depth to the reviewer's security section. The reviewer owns the official ARC security posture. Your findings are supplementary:
		- Flag additional concerns the reviewer's OWASP scan may miss
		- Provide deeper threat modeling context
		- Do NOT contradict the reviewer's findings — escalate disagreements to the lead

		## Communication Protocol

		- DM lead at gates with structured finding report
		- DM architect during Phase 1B with security VERIFY criteria needs
		- DM builders in security-sensitive partitions with specific guidance (max 2 DMs per builder)
		- DM test-advisor if a security-critical path lacks test coverage (max 2 inter-specialist DMs)
		- Use `[SECURITY-BLOCK]` tag on CRITICAL or HIGH findings — lead MUST pause autonomous mode for these

		## Authority

		- CRITICAL or HIGH findings: Report to lead with `[SECURITY-BLOCK]` tag. Lead MUST pause autonomous mode.
		- MEDIUM findings: Report to lead as advisory. Do not block gates.
		- LOW/INFO findings: Include in report for documentation. Do not block gates.

		## Exit Expectations

		- Threat model delivered during Stage 0
		- Security risk assessment per NodeID delivered for Gate #1
		- Implementation vulnerability scan delivered for Gate #3
		- All CRITICAL/HIGH findings tagged `[SECURITY-BLOCK]`
		- Available for follow-up until shut down by lead (after Gate #3)

+162

agents/test-advisor.md

		---
		name: test-advisor
		description: "KnowzCode: TDD enforcement, test quality review, and coverage assessment"
		tools: Read, Glob, Grep, Bash
		model: sonnet
		permissionMode: default
		maxTurns: 15
		---

		# Test Advisor

		You are the Test Advisor in a KnowzCode development workflow.
		Your expertise: TDD compliance verification, test quality assessment, coverage analysis, assertion quality.

		## Your Job

		Enforce TDD rigor. Review test quality. Assess coverage. The builder writes tests; you verify they're good tests.

		Informational only — does not block gates. Your findings are advisory. The lead includes them in gate presentations for transparency but they do not pause autonomous mode.

		This is a READ-ONLY role. You MUST NOT modify, create, or delete any files. Bash usage is limited to read-only operations: coverage reports, `git log` inspection for TDD compliance verification. Implementation is the builder's responsibility.

		## Stage 0: Coverage Baseline

		1. Glob for test files to establish baseline:
		- `Glob: "*/.test.*"` — JS/TS test files
		- `Glob: "*/.spec.*"` — spec-style test files
		- `Glob: "*/test_"` — Python test files
		- `Glob: "/tests/"` — test directories
		- `Glob: "*/_test.go"` — Go test files
		- `Glob: "*/Test.java"` — Java test files
		2. Run coverage command if available (read-only — do NOT modify state):
		- Check for `package.json` scripts: `"test:coverage"`, `"coverage"`
		- Check for `pytest --cov`, `go test -cover`, `cargo tarpaulin`
		- Run coverage report command via Bash (read-only)
		3. Map existing coverage to the goal's affected areas
		4. Broadcast baseline: `"Test coverage baseline for {goal}"`

		## Stage 1: Test Strategy

		After the analyst delivers the Change Set:

		1. Recommend test types per NodeID:
		- Unit tests: Pure logic, transformations, utilities
		- Integration tests: API endpoints, database operations, cross-component
		- E2E tests: User flows, critical paths
		2. Flag NodeIDs needing special test infrastructure (mocking, fixtures, test databases)
		3. DM architect if VERIFY criteria aren't testable as written:
		> "VERIFY criteria for NodeID-X aren't testable as written — {specific issue, suggestion}"
		4. DM lead with test strategy for Gate #1

		## Stage 1: Spec Testability Review (post-spec)

		After specs are drafted, review VERIFY criteria for testability:
		- Can each VERIFY statement be verified with an automated test?
		- Are expected values specific enough? (e.g., "returns 200" vs "returns success")
		- Do VERIFY statements cover error paths, not just happy paths?
		- Flag vague VERIFY criteria that would lead to weak assertions

		## Stage 2: Test Quality Review

		For each completed NodeID, review test files for:

		### TDD Compliance
		Check git log to verify tests were committed before (or with) implementation:
		```bash
		git log --oneline -- {test-file}
		git log --oneline -- {impl-file}
		```
		Compare timestamps — tests should appear at or before implementation commits.

		### Assertion Quality
		- Are assertions specific? (`expect(result).toEqual({id: 1, name: "test"})` vs `expect(result).toBeTruthy()`)
		- Do assertions test behavior, not implementation details?
		- Are error messages descriptive?
		- No `expect(true).toBe(true)` or similar vacuous assertions

		### Edge Case Coverage
		- Happy path: Core functionality tested
		- Error paths: Invalid inputs, network failures, timeouts
		- Boundary conditions: Empty arrays, null values, max/min values, off-by-one
		- Concurrency: Race conditions, parallel execution (if applicable)

		### Test Isolation
		- Proper mocking — no real network calls, database writes, or file system changes in unit tests
		- No test interdependence — tests pass in any order
		- Proper setup/teardown — no leaking state between tests
		- No shared mutable state between test cases

		### Naming Conventions
		- Tests describe behavior: `"should return 404 when user not found"` not `"test1"`
		- Test file names match source files: `auth.ts` → `auth.test.ts`
		- Describe/context blocks organize by feature or scenario

		## Finding Report Format

		Report findings to the lead using this structured format:

		```markdown
		### Test Advisor Report

		Coverage Baseline: {X}% overall, {Y}% in affected areas
		TDD Compliance: {X}/{N} NodeIDs had tests before implementation

		\| NodeID \| Test File \| TDD \| Edge Cases \| Quality \| Issues \|
		\|--------\|-----------\|-----\|------------\|---------\|--------\|
		\| Auth \| auth.test.ts \| Yes \| Covered \| Good \| — \|
		\| UserProfile \| profile.test.ts \| No \| Missing error path \| Adequate \| Weak assertions on line 45 \|
		\| DataExport \| export.test.ts \| Yes \| Missing boundary \| Poor \| No isolation, shared DB state \|

		Recommendations:
		- {specific improvement suggestions}
		```

		## Builder Communication

		DM builders with specific test improvement feedback:
		> "Test for NodeID-X misses error path — add test for {scenario}"
		> "Assertions on line 45 are too weak — test specific return values, not truthiness"

		Discipline: Max 2 DMs to any individual builder. Consolidate findings — no per-file noise.

		## Inter-Specialist Communication

		- DM security-officer if a test gap is in a security-critical path (max 2 inter-specialist DMs):
		> "Auth flow has no test for token expiry — flagging for security review"
		- Respond to security-officer DMs about test coverage for security scenarios

		## Enterprise Compliance (Optional)

		If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`:

		1. Read the manifest's Active Guidelines table — load guidelines where `Active: true`
		2. Read active guidelines and extract all `ARC Verification` criteria (e.g., `ARC_SEC_AUTH_01a`, `ARC_CQ_PATTERN_01a`)
		3. Stage 2: For each enterprise ARC criterion in scope, check if a corresponding test exists:
		- Search test files for references to the ARC ID or the behavior it describes
		- Flag ARC criteria that have no test coverage
		4. Finding Report: Add `Enterprise ARC Coverage` subsection when enterprise compliance is active:
		```
		Enterprise ARC Coverage: {X}/{N} criteria have test coverage
		\| ARC Criterion \| Guideline \| Test File \| Covered \| Notes \|
		```
		5. Check `knowzcode/enterprise/guidelines/code-quality.md` section 5 ("Testing Standards") for enterprise-specific testing requirements — incorporate into test quality assessment if populated.

		## Bash Usage

		Read-only only. Permitted commands:
		- `git log --oneline -- tests/` — TDD compliance verification
		- `git log --oneline -- {file}` — commit history for test-before-code check
		- Coverage report commands (e.g., `npx jest --coverage --reporter=text`, `pytest --cov --cov-report=term`)
		- `git diff --stat {ref}` — change scope assessment

		NOT permitted: Running tests that modify state, executing build commands, writing files.

		## Exit Expectations

		- Coverage baseline broadcast during Stage 0
		- Test strategy per NodeID delivered for Gate #1
		- Spec testability review delivered for Gate #2
		- Test quality report delivered for Gate #3
		- All findings consolidated — no per-file noise
		- Available for follow-up until shut down by lead (after Gate #3)

+231

knowzcode/copilot_execution.md

		# Copilot Execution Model

		Purpose: Defines the execution model for GitHub Copilot users. Copilot operates as a single-agent, sequential platform — users manually transition between phases using prompt files.

		Agents on other platforms should ignore this file — see `knowzcode/platform_adapters.md` for platform-specific instructions, or `knowzcode/claude_code_execution.md` for Claude Code Agent Teams.

		---

		## Execution Model Overview

		Copilot uses a single-agent, user-driven execution model:

		- One AI assistant handles all phases sequentially
		- The user invokes each phase via `#prompt:kc-*` prompt files in VS Code
		- Quality gates are enforced by STOP instructions — the AI pauses and waits for user direction
		- Context carries between phases via WorkGroup files in `knowzcode/workgroups/`
		- No multi-agent orchestration, no inter-agent messaging, no task dependency tracking

		This is equivalent to the "Sequential Execution Protocol" described in `knowzcode/knowzcode_loop.md` Section 8.

		---

		## Prompt File Workflow

		### Phase Sequence

		```
		#prompt:kc-work "goal"
		→ Creates WorkGroup, classifies tier, Phase 1A analysis, proposes Change Set
		→ STOP — await user approval

		#prompt:kc-specify
		→ Reads WorkGroup, drafts specs for approved Change Set
		→ STOP — await user approval, then commits specs

		#prompt:kc-implement
		→ Reads WorkGroup + specs, TDD Red-Green-Refactor
		→ STOP — report implementation results

		#prompt:kc-audit
		→ READ-ONLY audit against VERIFY statements
		→ STOP — report gaps, await user decision

		#prompt:kc-finalize
		→ Updates specs to as-built, tracker, log, architecture check, commits
		```

		### Shortcut Workflows

		\| Prompt \| Use Case \|
		\|--------\|----------\|
		\| `#prompt:kc-fix "description"` \| Single-file, <50 line fixes — skip the full loop \|
		\| `#prompt:kc-plan "topic"` \| Research and investigation before implementing \|
		\| `#prompt:kc-continue` \| Resume interrupted work or advance to next phase \|
		\| `#prompt:kc-analyze` \| Re-run Phase 1A on an existing WorkGroup \|

		### Prompt File Location

		All prompt files live in `.github/prompts/` and are generated by `/kc:init` (or `npx knowzcode`). They use YAML frontmatter with `agent: "agent"` for file editing capability.

		---

		## VS Code Agent Mode

		Copilot prompt files with `agent: "agent"` in their frontmatter enable agent mode, which allows:

		- File creation and editing
		- Terminal command execution (tests, builds, linting)
		- Multi-file changes in a single session

		All KnowzCode prompt files use `agent: "agent"` for TDD implementation, spec writing, and WorkGroup file updates.

		### Using Prompt Files

		In VS Code Copilot Chat:
		1. Type `#prompt:kc-work` to invoke the workflow prompt
		2. Add your goal as the chat message: `#prompt:kc-work "Build JWT authentication"`
		3. Copilot loads the prompt file, pulls in `#file:` referenced context, and executes

		### Adding Extra Context

		You can add files to the prompt context manually:
		- Reference files in chat: `#file:src/auth/login.ts`
		- The prompt files already include `#file:` references for core KnowzCode files

		---

		## Copilot CLI Usage

		The Copilot CLI does not support `#prompt:` syntax. Check the current CLI documentation for the exact file reference syntax — it may differ from VS Code's `#file:` references.

		Alternatively, paste the goal and reference the methodology directly in the CLI prompt. The CLI provides the same AI capabilities but without the `#prompt:` shorthand.

		---

		## Copilot Coding Agent Integration

		The GitHub Copilot Coding Agent (cloud-based, triggered from GitHub Issues) follows `copilot-instructions.md` automatically when working on repository issues.

		### Behavior

		When the Coding Agent picks up an issue:
		1. Reads `.github/copilot-instructions.md` for methodology
		2. Follows Phase 1A→3 workflow for non-trivial changes
		3. Includes the Change Set in the PR description
		4. Uses TDD — failing test before implementation code
		5. Self-audits against spec VERIFY statements

		### Key Differences from Interactive Use

		\| Aspect \| Interactive (VS Code) \| Coding Agent (GitHub) \|
		\|--------\|----------------------\|----------------------\|
		\| Phase transitions \| User invokes each `#prompt:kc-*` \| Agent runs all phases autonomously \|
		\| Quality gates \| STOP and wait for user \| Deferred to PR review \|
		\| Prompt files \| Used via `#prompt:` \| Not used — follows `copilot-instructions.md` \|
		\| Approval \| Interactive at each gate \| PR reviewers approve \|

		### PR Description Format

		The Coding Agent should structure PR descriptions to reflect the KnowzCode workflow:

		```markdown
		## Change Set
		- NodeID: Description
		- Affected files: list

		## Specs
		- Link to spec files created/updated

		## Verification
		- Test results summary
		- Self-audit completion percentage
		```

		---

		## MCP Configuration for VS Code

		To enable vault access in Copilot, configure `.vscode/mcp.json`:

		```json
		{
		"servers": {
		"knowzcode": {
		"type": "http",
		"url": "${input:knowzcode_mcp_url}",
		"headers": {
		"x-api-key": "${input:knowzcode_api_key}"
		}
		}
		},
		"inputs": [
		{
		"id": "knowzcode_mcp_url",
		"description": "KnowzCode MCP server URL",
		"type": "promptString"
		},
		{
		"id": "knowzcode_api_key",
		"description": "KnowzCode API key",
		"type": "promptString",
		"password": true
		}
		]
		}
		```

		MCP provides `search_knowledge`, `ask_question`, and `create_knowledge` tools for vault access. All prompt files work without MCP — it enhances context but never blocks.

		---

		## Model Selection Guidance

		\| Phase \| Recommended Model \| Rationale \|
		\|-------\|------------------\|-----------\|
		\| 1A: Analysis \| Claude Opus / GPT-4o \| Complex reasoning about impact and scope \|
		\| 1B: Specification \| Claude Opus / GPT-4o \| Structured spec drafting requires depth \|
		\| 2A: Implementation \| Any capable model \| Code generation — Sonnet/GPT-4o sufficient \|
		\| 2B: Audit \| Claude Opus / GPT-4o \| Critical evaluation requires strong reasoning \|
		\| 3: Finalization \| Any capable model \| Mostly doc updates and formatting \|
		\| Quick fix \| Any model \| Simple, scoped changes \|

		VS Code allows model selection per chat session. For complex features, prefer stronger models for analysis and audit phases.

		---

		## Limitations and Workarounds

		\| Limitation \| Impact \| Workaround \|
		\|-----------\|--------\|------------\|
		\| No multi-agent orchestration \| Cannot run parallel analysis/implementation \| Sequential phase execution via prompt files \|
		\| No inter-agent messaging \| No scout/scribe delegation \| Single agent reads all context directly \|
		\| No task dependency tracking \| No automated phase progression \| User manually invokes next prompt \|
		\| No persistent agents \| Context reloaded each prompt invocation \| WorkGroup files carry state between invocations \|
		\| No dynamic agent spawning \| Cannot create specialized agents at runtime \| Prompt files encode all phase specialization \|
		\| CLI lacks `#prompt:` support \| Cannot use prompt shorthand in CLI \| Check CLI docs for file reference syntax, or paste prompt content \|

		### What Works Well

		- Agent mode provides full file editing and terminal access
		- `#file:` references efficiently pull in methodology and context
		- WorkGroup files maintain state across sessions
		- Copilot Coding Agent follows `copilot-instructions.md` for autonomous issue resolution
		- MCP tools integrate natively via `.vscode/mcp.json`

		---

		## Continue / Resume Workflow

		When a user invokes `#prompt:kc-continue`:

		1. Find active WorkGroup: Read `knowzcode/knowzcode_tracker.md` for `[WIP]` entries
		2. Determine current phase: Read the WorkGroup file's Phase History table
		3. Resume or advance:
		- If mid-phase (incomplete todos): Resume the current phase
		- If at a quality gate (phase complete, awaiting approval): Present results and await decision
		- If between phases (approved, next not started): Begin the next phase
		4. Guide user: Tell the user which `#prompt:kc-*` to invoke next, or proceed directly if the continue prompt can handle it

		### Phase Detection Logic

		\| WorkGroup State \| Action \|
		\|----------------\|--------\|
		\| Phase 1A complete, no approval recorded \| Present Change Set for approval \|
		\| Phase 1A approved, no specs drafted \| Advise: `#prompt:kc-specify` \|
		\| Phase 1B complete, no approval recorded \| Present specs for approval \|
		\| Phase 1B approved, no implementation started \| Advise: `#prompt:kc-implement` \|
		\| Phase 2A complete \| Advise: `#prompt:kc-audit` \|
		\| Phase 2B complete, gaps found \| Advise: fix gaps then `#prompt:kc-implement`, or `#prompt:kc-finalize` to accept \|
		\| Phase 2B complete, no gaps \| Advise: `#prompt:kc-finalize` \|
		\| No active WorkGroup \| Inform user, suggest `#prompt:kc-work` \|

+66

knowzcode/knowzcode_orchestration.md

		# KnowzCode Orchestration Configuration

		Purpose: Project-level defaults for team sizing and agent orchestration. Read by `/kc:work` and `/kc:audit` at startup. Per-invocation flags override these settings.

		---

		## Builder Configuration

		```yaml
		# Maximum concurrent builders in Parallel Teams mode (default: 5, range: 1-5)
		# Lower values reduce token usage and complexity; higher values increase parallelism.
		# If the dependency map produces fewer partitions, fewer builders spawn regardless.
		max_builders: 5
		```

		---

		## Scout Configuration

		```yaml
		# Scout mode controls context-scout spawning at Stage 0 (default: full)
		# full — 3 scouts: specs, workgroups, backlog (default)
		# minimal — 1 scout: combined scan of all local context
		# none — skip scouts entirely (lead loads context inline)
		scout_mode: full
		```

		---

		## Specialist Defaults

		```yaml
		# Specialists enabled by default for this project (default: none)
		# These activate without needing --specialists on every invocation.
		# Per-invocation --no-specialists overrides this setting.
		# Values: security-officer, test-advisor, project-advisor
		default_specialists: []

		# Examples:
		# default_specialists: [security-officer]
		# default_specialists: [security-officer, test-advisor]
		# default_specialists: [security-officer, test-advisor, project-advisor]
		```

		---

		## MCP Agent Configuration

		```yaml
		# Enable MCP agents (knowz-scout, knowz-scribe) when vaults are configured (default: true)
		# Set to false to skip vault agents even when vaults exist — reduces agent count.
		mcp_agents_enabled: true
		```

		---

		## Override Precedence

		\| Setting \| Config Default \| Flag Override \|
		\|---------\|---------------\|--------------\|
		\| max_builders \| `max_builders:` \| `--max-builders=N` \|
		\| scout_mode \| `scout_mode:` \| `--no-scouts` \|
		\| default_specialists \| `default_specialists:` \| `--specialists`, `--no-specialists` \|
		\| mcp_agents_enabled \| `mcp_agents_enabled:` \| `--no-mcp` \|

		Per-invocation flags always win. `--specialists` adds to defaults; `--no-specialists` clears all.

+6

-3

.claude-plugin/marketplace.json

		@@ -9,3 +9,3 @@ {
		"description": "Official KnowzCode plugin marketplace - Platform-agnostic AI development methodology",
		"version": "0.2.1"
		"version": "0.3.1"
		},
		@@ -17,3 +17,3 @@ "plugins": [
		"description": "KnowzCode - Platform-agnostic AI development methodology with TDD, quality gates, and structured workflows",
		"version": "0.2.1",
		"version": "0.3.1",
		"author": {
		@@ -52,3 +52,6 @@ "name": "Alex Headscarf"
		"./agents/update-coordinator.md",
		"./agents/knowz-scribe.md"
		"./agents/knowz-scribe.md",
		"./agents/security-officer.md",
		"./agents/test-advisor.md",
		"./agents/project-advisor.md"
		],
		@@ -55,0 +58,0 @@ "skills": [

+1

-1

.claude-plugin/plugin.json

		{
		"name": "kc",
		"description": "KnowzCode - Platform-agnostic AI development methodology with TDD, quality gates, and structured workflows",
		"version": "0.2.1",
		"version": "0.3.1",
		"author": {
		@@ -6,0 +6,0 @@ "name": "Alex Headscarf"

+26

-5

agents/architect.md

		@@ -56,12 +56,33 @@ ---

		### Architecture Assessment Output
		### Architecture Health Report

		Provide a structured Architecture Health Report at each quality gate. This is a first-class gate deliverable. When specialists are active, the lead includes your Architecture Health Report in the Specialist Reports section at each gate.

		Gate #1 (Change Set Approval) — Architecture impact assessment:
		```markdown
		Architecture Assessment:
		- Alignment: {HIGH/MEDIUM/LOW}
		Architect — Architecture Health Report (Gate #1):
		- Impact Scope: {layers touched, components affected}
		- Coupling Concerns: {new dependencies, tight coupling risks}
		- Pattern Alignment: {matches existing patterns / introduces new pattern / deviates}
		- Recommendation: {proceed / adjust scope}
		```

		Gate #2 (Specification Approval) — Spec architecture review:
		```markdown
		Architect — Architecture Health Report (Gate #2):
		- Spec-Architecture Alignment: {specs follow documented patterns / drift concerns}
		- Layer Violations: {list or None}
		- Pattern Concerns: {list or None}
		- Drift Detected: {list or None}
		- Consistency: {specs are internally consistent / conflicts between NodeID-X and NodeID-Y}
		- Recommendation: {proceed / revise specs}
		```

		Gate #3 (Audit Results) — Implementation architecture audit:
		```markdown
		Architect — Architecture Health Report (Gate #3):
		- Drift: {Yes/No — implementation matches spec intent}
		- Pattern Violations: {count} — {list or None}
		- Layer Health: {all layers respected / violations in {list}}
		- Recommendation: {proceed / fix drift}
		```

		## During Implementation (Parallel Teams — Consultative Role)
		@@ -68,0 +89,0 @@

+1

-1

agents/context-scout.md

 @@ -23,3 +23,3 @@ ---
 Your spawn prompt assigns your specific focus area from the list below. Read only the files in your assigned focus area.
 Your spawn prompt assigns your specific focus area from the list below. Read only the files in your assigned focus area. If your spawn prompt assigns ALL focus areas (combined scan), read across all file types listed below and deliver consolidated findings covering all five deliverable categories.
 @@ -26,0 +26,0 @@ **Full file landscape** (for reference — your focus area is a subset):

+101

-12

commands/audit.md

		@@ -36,3 +36,19 @@ ---
		- `knowzcode/knowzcode_project.md`
		- `knowzcode/knowzcode_orchestration.md` (if exists)

		## Step 1.1: Parse Orchestration Config (Optional)

		If `knowzcode/knowzcode_orchestration.md` exists, parse its YAML blocks:

		1. `SCOUT_MODE` = `scout_mode` value (default: "full")
		2. `DEFAULT_SPECIALISTS` = `default_specialists` value (default: [])
		3. `MCP_AGENTS_ENABLED` = `mcp_agents_enabled` value (default: true)

		Apply flag overrides (flags win over config):
		- `--no-scouts` in `$ARGUMENTS` → override `SCOUT_MODE = "none"`
		- `--no-specialists` in `$ARGUMENTS` → override `DEFAULT_SPECIALISTS = []`
		- `--no-mcp` in `$ARGUMENTS` → override `MCP_AGENTS_ENABLED = false`

		If the file doesn't exist, use hardcoded defaults (current behavior).

		## Step 2: Set Up Execution Mode
		@@ -159,8 +175,52 @@

		4. If `VAULTS_CONFIGURED = true`, spawn `knowz-scout` for standards lookup in parallel with reviewers:
		4. If `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`, spawn `knowz-scout` for standards lookup in parallel with reviewers:
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> Read `knowzcode/knowzcode_vaults.md` to resolve vault IDs by type. Query for team standards: `ask_question({vault matching "ecosystem" type}, "standards for {project_type}", researchMode=true)`

		Wait for all to complete. Synthesize results in Step 4.
		Wait for all to complete.

		#### Specialist Integration (Optional)

		Initialize `AUDIT_SPECIALISTS = DEFAULT_SPECIALISTS` (from orchestration config, default: []).

		If `$ARGUMENTS` contains `--specialists` (or `--specialists=security`, `--specialists=test`, `--specialists=security,test`):
		- `--specialists` → enable all applicable: `[security-officer, test-advisor]`
		- `--specialists=csv` → enable specified subset
		- `--no-specialists` → clear to `[]` (overrides config defaults)

		If neither `--specialists` nor `--no-specialists` is present, use `DEFAULT_SPECIALISTS` from config.

		Parse which specialists to enable. Then spawn alongside reviewers:

		1. security-officer (if enabled) — spawn alongside `reviewer-sec-int` for deeper security scanning:
		- `TaskCreate("Security officer: deep security audit")` → `TaskUpdate(owner: "security-officer")`
		- Spawn `security-officer` teammate:
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> You are the security-officer running a deep security audit.
		> Read `agents/security-officer.md` for your role definition.
		> Read `knowzcode/claude_code_execution.md` for team conventions.
		>
		> Audit scope: Full codebase security scan — vulnerability patterns, hardcoded secrets, injection vectors, auth bypass, SSRF, path traversal.
		> Context files: knowzcode_tracker.md, knowzcode_architecture.md, knowzcode_project.md
		> Specs directory: knowzcode/specs/
		>
		> Deliverable: Security finding report with severity ratings. Tag CRITICAL/HIGH findings with `[SECURITY-BLOCK]`.
		> If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, also cross-reference findings with enterprise guideline IDs.

		2. test-advisor (if enabled) — spawn alongside reviewers for test quality assessment:
		- `TaskCreate("Test advisor: test quality audit")` → `TaskUpdate(owner: "test-advisor")`
		- Spawn `test-advisor` teammate:
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> You are the test-advisor running a test quality audit.
		> Read `agents/test-advisor.md` for your role definition.
		> Read `knowzcode/claude_code_execution.md` for team conventions.
		>
		> Audit scope: Test coverage, TDD compliance, assertion quality, edge case coverage, test isolation.
		> Context files: knowzcode_tracker.md, knowzcode_project.md
		>
		> Deliverable: Test quality report with coverage metrics, TDD compliance, and improvement recommendations.
		> If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, also check enterprise ARC criteria for test coverage.

		Wait for all reviewers and specialists to complete. Synthesize results in Step 4.

		### Subagent Mode
		@@ -172,8 +232,11 @@

		1. context-scout — Local context (3 parallel instances):
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/specs/*.md — scan existing specifications for relevant NodeIDs, status, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/workgroups/*.md — scan previous WorkGroups for related audit findings. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md — scan for active WIP, prior audit results, architecture health. Max 10 tool calls. Write findings to a concise summary.")`
		1. context-scout — Local context (if `SCOUT_MODE != "none"`):
		- `SCOUT_MODE = "full"` (default): 3 parallel instances:
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/specs/*.md — scan existing specifications for relevant NodeIDs, status, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/workgroups/*.md — scan previous WorkGroups for related audit findings. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research audit scope: {audit_type}. Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md — scan for active WIP, prior audit results, architecture health. Max 10 tool calls. Write findings to a concise summary.")`
		- `SCOUT_MODE = "minimal"`: 1 combined instance:
		- `Task(subagent_type="context-scout", name="context-scout", description="Scout: combined context", prompt="Research audit scope: {audit_type}. Focus: ALL local context — knowzcode/specs/.md, knowzcode/workgroups/.md, knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md. Max 10 tool calls. Write findings to a concise summary.")`

		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true`):
		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`):
		- `Task(subagent_type="knowz-scout", description="Scout: vault standards", prompt="Research audit scope: {audit_type}. Read knowzcode/knowzcode_vaults.md to discover configured vaults. Query for team standards, conventions, and past audit decisions. Max 10 tool calls. Write findings to a concise summary.")`
		@@ -197,8 +260,11 @@

		1. context-scout — Local context (3 parallel instances):
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research for comprehensive audit. Focus: knowzcode/specs/*.md — scan all specifications for quality, completeness, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research for comprehensive audit. Focus: knowzcode/workgroups/*.md — scan all WorkGroups for patterns, recurring issues, audit history. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research for comprehensive audit. Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md — scan for WIP status, prior audit results, architecture health. Max 10 tool calls. Write findings to a concise summary.")`
		1. context-scout — Local context (if `SCOUT_MODE != "none"`):
		- `SCOUT_MODE = "full"` (default): 3 parallel instances:
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research for comprehensive audit. Focus: knowzcode/specs/*.md — scan all specifications for quality, completeness, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research for comprehensive audit. Focus: knowzcode/workgroups/*.md — scan all WorkGroups for patterns, recurring issues, audit history. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research for comprehensive audit. Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md — scan for WIP status, prior audit results, architecture health. Max 10 tool calls. Write findings to a concise summary.")`
		- `SCOUT_MODE = "minimal"`: 1 combined instance:
		- `Task(subagent_type="context-scout", name="context-scout", description="Scout: combined context", prompt="Research for comprehensive audit. Focus: ALL local context — knowzcode/specs/.md, knowzcode/workgroups/.md, knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md. Max 10 tool calls. Write findings to a concise summary.")`

		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true`):
		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`):
		- `Task(subagent_type="knowz-scout", description="Scout: vault standards", prompt="Research for comprehensive audit. Read knowzcode/knowzcode_vaults.md to discover configured vaults. Query for team standards, conventions, security policies, and compliance requirements. Max 10 tool calls. Write findings to a concise summary.")`
		@@ -213,2 +279,21 @@

		#### Specialist Integration (Subagent Mode — Optional)

		Initialize `AUDIT_SPECIALISTS = DEFAULT_SPECIALISTS` (from orchestration config, default: []).

		If `$ARGUMENTS` contains `--specialists` (or `--specialists=security`, `--specialists=test`, `--specialists=security,test`):
		- `--specialists` → enable all applicable
		- `--specialists=csv` → enable specified subset
		- `--no-specialists` → clear to `[]`

		If `AUDIT_SPECIALISTS` is non-empty, launch specialist `Task()` calls in parallel with reviewers:

		1. security-officer (if enabled):
		- `Task(subagent_type="security-officer", description="Security officer: deep security audit", prompt="Audit scope: Full codebase security scan. Context files: knowzcode_tracker.md, knowzcode_architecture.md. Specs: knowzcode/specs/. Deliverable: Security finding report with severity ratings. Tag CRITICAL/HIGH with [SECURITY-BLOCK]. If knowzcode/enterprise/compliance_manifest.md exists and compliance_enabled: true, also cross-reference findings with enterprise guideline IDs.")`

		2. test-advisor (if enabled):
		- `Task(subagent_type="test-advisor", description="Test advisor: test quality audit", prompt="Audit scope: Test coverage, TDD compliance, assertion quality, edge cases. Context files: knowzcode_tracker.md. Deliverable: Test quality report with coverage metrics and recommendations. If knowzcode/enterprise/compliance_manifest.md exists and compliance_enabled: true, also check enterprise ARC criteria for test coverage.")`

		Synthesize specialist findings alongside reviewer results.

		## Step 4: Present Results
		@@ -235,2 +320,6 @@
		{prioritized action items}

		### Specialist Reports [only when --specialists active]
		Security Officer: {finding count, severity breakdown, SECURITY-BLOCK tags}
		Test Advisor: {coverage %, TDD compliance, quality assessment}
		```
		@@ -237,0 +326,0 @@

+116

-1

commands/init.md

		@@ -36,2 +36,3 @@ ---
		├── knowzcode_loop.md
		├── knowzcode_orchestration.md
		├── platform_adapters.md
		@@ -63,2 +64,16 @@ ├── environment_context.md

		### 5.5. Configure orchestration defaults (optional)

		Ask: "Would you like to configure agent orchestration defaults? (optional — can be changed later in knowzcode/knowzcode_orchestration.md)"

		If yes: prompt for:
		- Max concurrent builders (1-5, default: 5)
		- Scout mode (full/minimal/none, default: full)
		- Default specialists (checkboxes: security-officer, test-advisor, project-advisor)
		- MCP agents enabled (yes/no, default: yes)

		If no: generate with all defaults.

		Generate `knowzcode/knowzcode_orchestration.md` from the template (always — it's part of the standard file set).

		### 6. Create .gitignore
		@@ -85,3 +100,3 @@
		- .cursor/rules/ or .cursorrules (deprecated) → offer Cursor adapter (.cursor/rules/knowzcode.mdc)
		- .github/copilot-instructions.md → offer Copilot adapter
		- .github/copilot-instructions.md OR .github/ directory → offer Copilot adapter (full prompt files)
		- .windsurf/rules/ or .windsurfrules (deprecated) → offer Windsurf adapter (.windsurf/rules/knowzcode.md)
		@@ -125,2 +140,49 @@ ```

		Step 7e: Copilot-specific generation

		When Copilot is selected, generate the full prompt file suite in addition to the instructions file:

		```
		1. Create .github/ directory if it doesn't exist
		2. Create .github/copilot-instructions.md from platform_adapters.md template Section A
		3. Create .github/prompts/ directory
		4. Generate all 9 prompt files from platform_adapters.md template Section B:
		- .github/prompts/kc-work.prompt.md
		- .github/prompts/kc-analyze.prompt.md
		- .github/prompts/kc-specify.prompt.md
		- .github/prompts/kc-implement.prompt.md
		- .github/prompts/kc-audit.prompt.md
		- .github/prompts/kc-finalize.prompt.md
		- .github/prompts/kc-fix.prompt.md
		- .github/prompts/kc-plan.prompt.md
		- .github/prompts/kc-continue.prompt.md
		5. Replace "vX.Y.Z" in generated files with the current KnowzCode version
		6. Optionally create .vscode/mcp.json skeleton from template Section C
		(ask user: "Would you like to generate MCP configuration for VS Code?")
		```

		Skip Agent Teams enablement for Copilot — Copilot uses single-agent sequential execution.

		Copilot success message:
		```
		GitHub Copilot adapter generated:
		.github/copilot-instructions.md (repository-level instructions)
		.github/prompts/kc-work.prompt.md (start workflow: #prompt:kc-work)
		.github/prompts/kc-analyze.prompt.md
		.github/prompts/kc-specify.prompt.md
		.github/prompts/kc-implement.prompt.md
		.github/prompts/kc-audit.prompt.md
		.github/prompts/kc-finalize.prompt.md
		.github/prompts/kc-fix.prompt.md (quick fix: #prompt:kc-fix)
		.github/prompts/kc-plan.prompt.md (research: #prompt:kc-plan)
		.github/prompts/kc-continue.prompt.md (resume: #prompt:kc-continue)

		Usage in VS Code:
		#prompt:kc-work "Build user authentication" — Start a feature
		#prompt:kc-fix "Fix login redirect bug" — Quick fix
		#prompt:kc-continue — Resume where you left off

		See knowzcode/copilot_execution.md for the full execution guide.
		```

		### 7.5. Enable Agent Teams (Claude Code only)
		@@ -199,2 +261,3 @@
		knowzcode/knowzcode_loop.md
		knowzcode/knowzcode_orchestration.md
		knowzcode/platform_adapters.md
		@@ -319,4 +382,56 @@ knowzcode/.gitignore

		### knowzcode_orchestration.md
		```markdown
		# KnowzCode Orchestration Configuration

		Purpose: Project-level defaults for team sizing and agent orchestration. Read by `/kc:work` and `/kc:audit` at startup. Per-invocation flags override these settings.

		---

		## Builder Configuration

		```yaml
		max_builders: 5
		```

		---

		## Scout Configuration

		```yaml
		scout_mode: full
		```

		---

		## Specialist Defaults

		```yaml
		default_specialists: []
		```

		---

		## MCP Agent Configuration

		```yaml
		mcp_agents_enabled: true
		```

		---

		## Override Precedence

		\| Setting \| Config Default \| Flag Override \|
		\|---------\|---------------\|--------------\|
		\| max_builders \| `max_builders:` \| `--max-builders=N` \|
		\| scout_mode \| `scout_mode:` \| `--no-scouts` \|
		\| default_specialists \| `default_specialists:` \| `--specialists`, `--no-specialists` \|
		\| mcp_agents_enabled \| `mcp_agents_enabled:` \| `--no-mcp` \|

		Per-invocation flags always win. `--specialists` adds to defaults; `--no-specialists` clears all.
		```

		---

		## Error Handling
		@@ -323,0 +438,0 @@

+23

-10

commands/plan.md

		@@ -43,2 +43,12 @@ ---

		## Step 3.5: Load Orchestration Config (Optional)

		If `knowzcode/knowzcode_orchestration.md` exists, parse:
		1. `SCOUT_MODE` = `scout_mode` value (default: "full")
		2. `MCP_AGENTS_ENABLED` = `mcp_agents_enabled` value (default: true)

		Flag overrides: `--no-scouts` → `SCOUT_MODE = "none"`, `--no-mcp` → `MCP_AGENTS_ENABLED = false`

		If file doesn't exist, use defaults. Other config settings (`max_builders`, `default_specialists`) are not applicable to `/kc:plan`.

		## Step 4: Launch Parallel Investigation
		@@ -87,4 +97,4 @@

		1. `TaskCreate("Scout: local context for {topic}")` → `TaskUpdate(owner: "context-scout")`
		2. `TaskCreate("Scout: vault knowledge for {topic}")` → `TaskUpdate(owner: "knowz-scout")` (if `VAULTS_CONFIGURED = true`)
		1. If `SCOUT_MODE != "none"`: `TaskCreate("Scout: local context for {topic}")` → `TaskUpdate(owner: "context-scout")`
		2. `TaskCreate("Scout: vault knowledge for {topic}")` → `TaskUpdate(owner: "knowz-scout")` (if `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`)
		3. `TaskCreate("Research: code exploration")` → `TaskUpdate(owner: "analyst")`
		@@ -94,5 +104,5 @@ 4. `TaskCreate("Research: architecture")` → `TaskUpdate(owner: "architect")`

		Spawn up to five teammates with their task IDs:
		Spawn teammates with their task IDs (count depends on SCOUT_MODE and MCP settings):

		1. Spawn `context-scout` teammate:
		1. If `SCOUT_MODE != "none"`, spawn `context-scout` teammate:
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		@@ -105,3 +115,3 @@ > You are researching "{topic}" from a knowzcode history angle.

		2. If `VAULTS_CONFIGURED = true`, spawn `knowz-scout` teammate:
		2. If `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`, spawn `knowz-scout` teammate:
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		@@ -145,8 +155,11 @@ > You are researching "{topic}" from a vault knowledge angle.

		1. context-scout — Local context (3 parallel instances):
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research \"{topic}\". Focus: knowzcode/specs/*.md — scan existing specifications for relevant NodeIDs, status, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research \"{topic}\". Focus: knowzcode/workgroups/*.md — scan previous WorkGroups for similar goals, what was tried, what succeeded/failed. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research \"{topic}\". Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md, knowzcode/knowzcode_project.md — scan for active WIP, REFACTOR tasks, architecture summary, recent log patterns. Max 10 tool calls. Write findings to a concise summary.")`
		1. context-scout — Local context (if `SCOUT_MODE != "none"`):
		- `SCOUT_MODE = "full"` (default): 3 parallel instances:
		- `Task(subagent_type="context-scout", name="context-scout-specs", description="Scout: specs context", prompt="Research \"{topic}\". Focus: knowzcode/specs/*.md — scan existing specifications for relevant NodeIDs, status, VERIFY criteria. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-workgroups", description="Scout: workgroups context", prompt="Research \"{topic}\". Focus: knowzcode/workgroups/*.md — scan previous WorkGroups for similar goals, what was tried, what succeeded/failed. Max 10 tool calls. Write findings to a concise summary.")`
		- `Task(subagent_type="context-scout", name="context-scout-backlog", description="Scout: backlog context", prompt="Research \"{topic}\". Focus: knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md, knowzcode/knowzcode_project.md — scan for active WIP, REFACTOR tasks, architecture summary, recent log patterns. Max 10 tool calls. Write findings to a concise summary.")`
		- `SCOUT_MODE = "minimal"`: 1 combined instance:
		- `Task(subagent_type="context-scout", name="context-scout", description="Scout: combined context", prompt="Research \"{topic}\". Focus: ALL local context — knowzcode/specs/.md, knowzcode/workgroups/.md, knowzcode/knowzcode_tracker.md, knowzcode/knowzcode_log.md, knowzcode/knowzcode_architecture.md, knowzcode/knowzcode_project.md. Max 10 tool calls. Write findings to a concise summary.")`

		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true`):
		2. knowz-scout — MCP knowledge (if `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`):
		- `Task(subagent_type="knowz-scout", description="Scout: vault knowledge", prompt="Research \"{topic}\". Read knowzcode/knowzcode_vaults.md to discover configured vaults. Query each for relevant knowledge: team conventions, past decisions, similar implementations. Max 10 tool calls. Write findings to a concise summary.")`
		@@ -153,0 +166,0 @@

+233

-46

commands/work.md

		@@ -61,2 +61,18 @@ ---

		## Step 2.4: Load Orchestration Config (Optional)

		If `knowzcode/knowzcode_orchestration.md` exists, parse its YAML blocks:

		1. `MAX_BUILDERS` = `max_builders` value (default: 5, clamp to 1-5)
		2. `SCOUT_MODE` = `scout_mode` value (default: "full")
		3. `DEFAULT_SPECIALISTS` = `default_specialists` value (default: [])
		4. `MCP_AGENTS_ENABLED` = `mcp_agents_enabled` value (default: true)

		Apply flag overrides (flags win over config):
		- `--max-builders=N` in `$ARGUMENTS` → override `MAX_BUILDERS`
		- `--no-scouts` in `$ARGUMENTS` → override `SCOUT_MODE = "none"`
		- `--no-mcp` in `$ARGUMENTS` → override `MCP_AGENTS_ENABLED = false`

		If the file doesn't exist, use hardcoded defaults (current behavior).

		## Step 2.5: Autonomous Mode Detection
		@@ -82,2 +98,33 @@

		## Step 2.6: Specialist Detection

		Set `SPECIALISTS_ENABLED = []` (empty list).

		If `DEFAULT_SPECIALISTS` is non-empty (from Step 2.4), initialize:
		`SPECIALISTS_ENABLED = DEFAULT_SPECIALISTS`

		Determine which specialists to activate (flags and natural language add to or override the baseline):
		- `--specialists` → enable all 3: `[security-officer, test-advisor, project-advisor]`
		- `--specialists=csv` → enable specific subset (comma-separated, e.g., `--specialists=security,test`):
		- `security` → `security-officer`
		- `test` → `test-advisor`
		- `project` → `project-advisor`
		- `--no-specialists` → explicit opt-out, `SPECIALISTS_ENABLED = []`

		Natural language detection (case-insensitive match in `$ARGUMENTS` OR the user's preceding conversation message):
		- All specialists: "with specialists", "with officers", "full specialist panel"
		- security-officer: "security review", "threat model", "vulnerability scan", "pentest"
		- test-advisor: "test quality", "TDD enforcement", "test coverage", "test rigor"
		- project-advisor: "backlog", "future work", "brainstorm", "ideas"

		Mode constraints:
		- Tier 3 Parallel Teams: Full support (Group C)
		- Tier 3 Subagent Delegation: Supported via parallel `Task()` calls
		- Sequential Teams / Tier 2: Not supported — if specialists were detected, announce: `> Specialists: SKIPPED — not supported in {Sequential Teams / Tier 2} mode.`

		Default: `SPECIALISTS_ENABLED = []` (specialists are opt-in).

		If `SPECIALISTS_ENABLED` is non-empty, announce after the autonomous mode announcement (or after the execution mode announcement if autonomous is not active):
		> Specialists: ACTIVE — {comma-separated list of enabled specialists}

		## Step 3: Load Context Files (ONCE)
		@@ -141,2 +188,5 @@
		### Tier 2: Light (2-phase workflow)

		> Note: Light mode does not use orchestration config — single builder, no scouts, no specialists.

		ALL must be true:
		@@ -299,11 +349,16 @@ - ≤3 files touched
		- Announce: `MCP Status: Connected — N vault(s) available` or `MCP Status: Connected — no vaults configured (knowledge capture disabled)`
		4. Spawn Group A (always — 5 agents):
		4. Spawn Group A:
		Create tasks first, pre-assign, then spawn with task IDs:
		- `TaskCreate("Scout: specs context")` → `TaskUpdate(owner: "context-scout-specs")`
		- `TaskCreate("Scout: workgroups context")` → `TaskUpdate(owner: "context-scout-workgroups")`
		- `TaskCreate("Scout: backlog context")` → `TaskUpdate(owner: "context-scout-backlog")`
		- `TaskCreate("Phase 1A: Impact analysis for {goal}")` → `TaskUpdate(owner: "analyst")`
		- `TaskCreate("Pre-load architecture context")` → `TaskUpdate(owner: "architect")`
		Spawn all 5 agents with their `{task-id}` in the spawn prompt (use spawn prompts from Phase Prompt Reference below).
		5. Spawn Group B (MCP agents — same turn as Group A): If `VAULTS_CONFIGURED = true`:
		- If `SCOUT_MODE = "full"` (default): spawn 3 context scouts (specs, workgroups, backlog) + analyst + architect (5 agents):
		- `TaskCreate("Scout: specs context")` → `TaskUpdate(owner: "context-scout-specs")`
		- `TaskCreate("Scout: workgroups context")` → `TaskUpdate(owner: "context-scout-workgroups")`
		- `TaskCreate("Scout: backlog context")` → `TaskUpdate(owner: "context-scout-backlog")`
		- If `SCOUT_MODE = "minimal"`: spawn 1 context-scout (combined scan) + analyst + architect (3 agents):
		- `TaskCreate("Scout: combined context")` → `TaskUpdate(owner: "context-scout")`
		- If `SCOUT_MODE = "none"`: spawn analyst + architect only (2 agents). Analyst and architect scan the codebase independently without pre-loaded scout context.
		- Always:
		- `TaskCreate("Phase 1A: Impact analysis for {goal}")` → `TaskUpdate(owner: "analyst")`
		- `TaskCreate("Pre-load architecture context")` → `TaskUpdate(owner: "architect")`
		Spawn all Group A agents with their `{task-id}` in the spawn prompt (use spawn prompts from Phase Prompt Reference below).
		5. Spawn Group B (MCP agents — same turn as Group A): If `VAULTS_CONFIGURED = true` AND `MCP_AGENTS_ENABLED = true`:
		Create tasks first, pre-assign, then spawn with task IDs:
		@@ -313,8 +368,15 @@ - `TaskCreate("Knowz-scout: vault queries")` → `TaskUpdate(owner: "knowz-scout")`
		Spawn both agents with their `{task-id}` in the spawn prompt.
		If `VAULTS_CONFIGURED = false`, skip Group B and log: `Vault agents skipped — no vaults configured.`
		6. Roster confirmation — lead lists every spawned agent by name to the user. If `VAULTS_CONFIGURED` was true but knowz-scout or knowz-scribe is missing from the roster, STOP and re-spawn the missing agent(s) before continuing.
		7. All 5-7 agents work immediately in parallel (3 context scouts are cheap Sonnet read-only agents; knowz-scribe is a cheap Haiku agent)
		8. Scouts broadcast findings → analyst and architect consume as messages
		If `VAULTS_CONFIGURED = false` or `MCP_AGENTS_ENABLED = false`, skip Group B and log: `Vault agents skipped — no vaults configured` or `Vault agents skipped — MCP agents disabled in orchestration config.`
		6. Spawn Group C (specialist agents — same turn as Groups A and B): If `SPECIALISTS_ENABLED` is non-empty:
		Create tasks first, pre-assign, then spawn with task IDs:
		- If `security-officer` in list: `TaskCreate("Security officer: initial threat scan")` → `TaskUpdate(owner: "security-officer")`
		- If `test-advisor` in list: `TaskCreate("Test advisor: coverage baseline")` → `TaskUpdate(owner: "test-advisor")`
		- If `project-advisor` in list: `TaskCreate("Project advisor: backlog context")` → `TaskUpdate(owner: "project-advisor")`
		Spawn each enabled specialist with its `{task-id}` in the spawn prompt (use spawn prompts from Specialist Spawn Prompts section below).
		If `SPECIALISTS_ENABLED` is empty, skip Group C.
		7. Roster confirmation — lead lists every spawned agent by name to the user. Include Group C specialists if active. If `VAULTS_CONFIGURED` was true but knowz-scout or knowz-scribe is missing from the roster, STOP and re-spawn the missing agent(s) before continuing.
		8. All spawned agents work immediately in parallel (context scouts are cheap Sonnet read-only agents; knowz-scribe is a cheap Haiku agent; specialists are Sonnet read-only agents). Agent count depends on orchestration config: 2-10 agents at Stage 0.
		9. Scouts broadcast findings → analyst and architect consume as messages. Specialists work independently on their Stage 0 tasks.

		Key: The analyst does NOT wait for scouts to finish. It starts scanning the codebase immediately. Scout findings arrive as messages and enrich the analyst's work as they arrive.
		Key: The analyst does NOT wait for scouts or specialists to finish. It starts scanning the codebase immediately. Scout findings arrive as messages and enrich the analyst's work as they arrive. Specialist findings are consumed by the lead at gates.

		@@ -325,9 +387,13 @@ ### Stage 1: Analysis + Specification
		2. Lead reads analyst's task summary
		3. Lead presents Quality Gate #1 to user:
		3. Specialist Change Set reviews (if `SPECIALISTS_ENABLED` non-empty): Create review tasks blocked on analysis:
		- If `security-officer` active: `TaskCreate("Security officer: Change Set review", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "security-officer")`. DM security-officer: `"New Task: #{task-id} — Review Change Set for security risk. Rate each NodeID."`
		- If `test-advisor` active: `TaskCreate("Test advisor: Change Set test strategy", addBlockedBy: [analysis-task-id])` → `TaskUpdate(owner: "test-advisor")`. DM test-advisor: `"New Task: #{task-id} — Recommend test types per NodeID."`
		4. Lead presents Quality Gate #1 to user:
		- Change Set with NodeIDs, descriptions, affected files
		- Dependency map showing which NodeIDs can be implemented in parallel
		- Risk assessment
		4. User approves (or rejects → re-run analyst with feedback)
		5. Lead sends DM to architect with the approved Change Set
		6. Lead creates spec-drafting tasks for architect (1 task per NodeID, `addBlockedBy: [analysis-task-id]`):
		- Specialist Reports (if active — see gate template below)
		5. User approves (or rejects → re-run analyst with feedback)
		6. Lead sends DM to architect with the approved Change Set
		7. Lead creates spec-drafting tasks for architect (1 task per NodeID, `addBlockedBy: [analysis-task-id]`):
		- `TaskCreate("Spec: NodeID-X")` → `TaskUpdate(taskId, owner: "architect")`
		@@ -337,10 +403,14 @@ - DM architect with task IDs: `"New Tasks: #{id-1} Spec: NodeID-A, #{id-2} Spec: NodeID-B. Approved Change Set: {summary}"`
		- If Gate #1 rejected: shut down architect, re-run analyst with feedback, re-spawn architect after
		7. Architect completes specs
		8. Lead presents Quality Gate #2 to user:
		- Spec summaries with VERIFY criteria
		9. User approves (or rejects → architect revises)
		10. Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Specs approved for {wgid}"`
		11. Shut down context-scouts (no longer needed after specs approved). Keep knowz-scout alive for vault queries during implementation.
		12. Keep analyst alive briefly (available for scope questions during early implementation)
		13. Keep architect alive through Stage 2 (consultative role — spec clarifications for builders, no code or spec edits)
		8. Architect completes specs
		9. Test-advisor spec review (if `test-advisor` in `SPECIALISTS_ENABLED`): After specs drafted, create spec testability review task:
		- `TaskCreate("Test advisor: spec testability review", addBlockedBy: [spec-task-id])` → `TaskUpdate(owner: "test-advisor")`
		- DM test-advisor: `"New Task: #{task-id} — Review specs for testability. Check VERIFY criteria are automatable."`
		10. Lead presents Quality Gate #2 to user:
		- Spec summaries with VERIFY criteria
		- Specialist Reports (if active — see gate template below)
		11. User approves (or rejects → architect revises)
		12. Pre-implementation commit: `git add knowzcode/ && git commit -m "KnowzCode: Specs approved for {wgid}"`
		13. Shut down context-scouts (no longer needed after specs approved). Keep knowz-scout alive for vault queries during implementation.
		14. Keep analyst alive briefly (available for scope questions during early implementation)
		15. Keep architect alive through Stage 2 (consultative role — spec clarifications for builders, no code or spec edits)

		@@ -351,3 +421,3 @@ ### Stage 2: Parallel Implementation + Incremental Review
		- Group NodeIDs into independent partitions (no shared files between groups)
		- Determine builder count: 1 builder per independent group, max 5
		- Determine builder count: 1 builder per independent group, max `MAX_BUILDERS` (default 5, configurable in `knowzcode_orchestration.md`)

		@@ -378,3 +448,16 @@ 2. Create builder tasks and spawn:

		6. Gap flow (per-partition, parallel — persistent agents, DM messaging):
		6. Specialist implementation reviews (if `SPECIALISTS_ENABLED` non-empty): Create specialist review tasks alongside reviewer audit tasks, same `addBlockedBy`:
		- If `security-officer` active — one task per partition (runs parallel to reviewer):
		`TaskCreate("Security officer: review partition {N}", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "security-officer")`
		DM security-officer: `"New Task: #{task-id} — Vulnerability scan for partition {N}. NodeIDs: {list}."`
		- If `test-advisor` active — one task per partition:
		`TaskCreate("Test advisor: review partition {N} tests", addBlockedBy: [implement-X-task-id])` → `TaskUpdate(owner: "test-advisor")`
		DM test-advisor: `"New Task: #{task-id} — Test quality review for partition {N}. NodeIDs: {list}."`
		- If `project-advisor` active — one observation task (not per-partition):
		`TaskCreate("Project advisor: observe implementation")` → `TaskUpdate(owner: "project-advisor")`
		DM project-advisor: `"New Task: #{task-id} — Observe builder progress, note patterns and ideas. Deliver backlog proposals before gap loop."`
		Gate #3 is NOT blocked by specialists. If a specialist hasn't finished, gate shows `[Pending: {specialist}]`. Lead proceeds.
		Project-advisor early shutdown: After project-advisor delivers backlog proposals, shut it down (before the gap loop begins).

		7. Gap flow (per-partition, parallel — persistent agents, DM messaging):
		a. Each reviewer marks audit task complete with structured gap report in summary
		@@ -394,3 +477,3 @@ b. Lead creates fix task and pre-assigns:

		7. Enterprise compliance (if enabled):
		8. Enterprise compliance (if enabled):
		- Lead creates parallel compliance task for each reviewer (scoped to their partition)
		@@ -400,3 +483,3 @@ - Reviewer checks compliance requirements from knowz-scout findings

		8. Inter-agent communication during Stage 2:
		9. Inter-agent communication during Stage 2:
		- builder → architect: Spec clarification requests (direct messages)
		@@ -409,19 +492,27 @@ - architect → builder: Design guidance and spec intent responses (direct messages)
		- lead → reviewer: Re-audit requests (via task creation + DM)
		- security-officer → builder-N: Security guidance for sensitive partitions (max 2 DMs per builder)
		- test-advisor → builder-N: Test improvement feedback (max 2 DMs per builder)
		- security-officer ↔ test-advisor: Cross-cutting test gaps in security paths (max 2 inter-specialist DMs)
		- project-advisor → knowz-scribe: Idea captures for vault storage
		- project-advisor → lead: Backlog proposals (before gap loop)

		9. After all NodeIDs implemented + audited across all partitions:
		- Lead consolidates audit results from all reviewers
		- Lead presents Quality Gate #3:
		- Per-NodeID ARC completion % (from each partition's reviewer)
		- Combined security posture
		- Combined integration health
		- Enterprise compliance (if applicable)
		- User decides: proceed / fix gaps / modify specs / cancel
		10. After all NodeIDs implemented + audited across all partitions:
		- Lead consolidates audit results from all reviewers
		- Lead consolidates specialist reports (if `SPECIALISTS_ENABLED` non-empty — include even if some specialist tasks are still pending, noting `[Pending: {specialist}]`)
		- Lead presents Quality Gate #3:
		- Per-NodeID ARC completion % (from each partition's reviewer)
		- Combined security posture
		- Combined integration health
		- Enterprise compliance (if applicable)
		- Specialist Reports (if active — see gate template below)
		- User decides: proceed / fix gaps / modify specs / cancel

		10. Shut down analyst, architect, all builders, and all reviewers
		11. Shut down analyst, architect, all builders, and all reviewers

		### Stage 3: Finalization

		1. `TaskCreate("Phase 3: Finalize {wgid}", addBlockedBy: [last-audit-task-id])` → `TaskUpdate(owner: "closer")`
		1. Shut down remaining specialists (security-officer, test-advisor) if still active. Project-advisor should already be shut down from mid-Stage 2.
		2. `TaskCreate("Phase 3: Finalize {wgid}", addBlockedBy: [last-audit-task-id])` → `TaskUpdate(owner: "closer")`
		Spawn `closer` with `{task-id}` in spawn prompt.
		2. Closer tasks (can be parallel subtasks):
		3. Closer tasks (can be parallel subtasks):
		- Update all specs to FINAL as-built
		@@ -434,5 +525,5 @@ - Update `knowzcode_tracker.md`: all NodeIDs `[WIP]` → `[VERIFIED]`
		- Create final atomic commit
		3. Lead presents completion summary
		4. Shut down knowz-scout, knowz-scribe (after Phase 3 capture completes), closer, and all remaining agents
		5. Delete team
		4. Lead presents completion summary
		5. Shut down knowz-scout, knowz-scribe (after Phase 3 capture completes), closer, and all remaining agents
		6. Delete team

		@@ -471,5 +562,14 @@ ### WorkGroup File Format (Parallel Mode)
		\| Architect pre-load \| (none) \| architect \|
		\| Security officer: initial threat scan \| (none — Group C) \| security-officer \|
		\| Test advisor: coverage baseline \| (none — Group C) \| test-advisor \|
		\| Project advisor: backlog context \| (none — Group C) \| project-advisor \|
		\| Security officer: Change Set review \| Phase 1A analysis \| security-officer \|
		\| Test advisor: Change Set test strategy \| Phase 1A analysis \| test-advisor \|
		\| Spec: NodeID-X \| Phase 1A (gate approval) \| architect \|
		\| Test advisor: spec testability review \| Spec: NodeID-X \| test-advisor \|
		\| Implement: NodeID-X \| Spec: NodeID-X \| builder-N \|
		\| Audit: NodeID-X \| Implement: NodeID-X \| reviewer-N \|
		\| Security officer: review partition N \| Implement: NodeID-X \| security-officer \|
		\| Test advisor: review partition N tests \| Implement: NodeID-X \| test-advisor \|
		\| Project advisor: observe implementation \| (none) \| project-advisor \|
		\| Fix gaps: NodeID-X round N \| Audit: NodeID-X (or re-audit N-1) \| builder-N \|
		@@ -483,2 +583,4 @@ \| Re-audit: NodeID-X round N \| Fix gaps round N \| reviewer-N \|

		> Note: Sequential Teams does not use orchestration config settings except `MCP_AGENTS_ENABLED`.

		When using Sequential Teams (`--sequential`) or Subagent Delegation, follow the traditional one-agent-per-phase flow. For each phase below: spawn the agent, create a task, wait for completion, present quality gate, shut down agent, proceed to next phase.
		@@ -525,6 +627,21 @@

		context-scout (combined) spawn prompt (used when `SCOUT_MODE = "minimal"`):
		> You are `context-scout` for WorkGroup `{wgid}`.
		> Read `agents/context-scout.md` for your full role definition.
		> Your Task: #{task-id} — claim immediately. Mark completed with summary when done.
		> Focus area: ALL local context — `knowzcode/specs/.md`, `knowzcode/workgroups/.md`, `knowzcode/knowzcode_tracker.md`, `knowzcode/knowzcode_log.md`, `knowzcode/knowzcode_architecture.md`, `knowzcode/knowzcode_project.md`
		> Goal: {goal}
		> READ-ONLY. Do NOT modify any files.
		> Deliverable: Broadcast consolidated findings covering specs, prior workgroups, active WIP, REFACTOR tasks, and architecture context.

		Dispatch:
		- Parallel Teams: All 3 context scouts spawned at Stage 0, no blockedBy. Shut down after Gate #2 (specs approved).
		- Parallel Teams:
		- `SCOUT_MODE = "full"`: 3 context scouts spawned at Stage 0. Shut down after Gate #2.
		- `SCOUT_MODE = "minimal"`: 1 context-scout (combined) spawned at Stage 0. Shut down after Gate #2.
		- `SCOUT_MODE = "none"`: No scouts spawned.
		- Sequential Teams: Not applicable (scouts are Parallel Teams only).
		- Subagent: `Task(subagent_type="context-scout", name="context-scout-specs", ...)`, `Task(subagent_type="context-scout", name="context-scout-workgroups", ...)`, `Task(subagent_type="context-scout", name="context-scout-backlog", ...)`
		- Subagent:
		- `SCOUT_MODE = "full"`: 3 parallel `Task()` calls (specs, workgroups, backlog).
		- `SCOUT_MODE = "minimal"`: 1 `Task()` call with combined prompt.
		- `SCOUT_MODE = "none"`: Skip scout tasks.

		@@ -573,2 +690,57 @@ ---

		## Specialist Spawn Prompts (Group C — opt-in via `--specialists`)

		The spawn prompts below are used when `SPECIALISTS_ENABLED` is non-empty. Specialists are spawned at Stage 0 alongside Groups A and B.

		Dispatch (all specialists):
		- Parallel Teams: Group C — spawned at Stage 0 if `SPECIALISTS_ENABLED` non-empty, no blockedBy. Security-officer and test-advisor persist through Gate #3. Project-advisor shuts down mid-Stage 2.
		- Sequential Teams: Not supported — announce skip reason.
		- Subagent: `Task()` calls with spawn prompts below.

		### Security Officer

		Agent: `security-officer` \| Officer — CRITICAL/HIGH findings block gates

		Spawn prompt:
		> You are the security-officer for WorkGroup `{wgid}`.
		> Read `agents/security-officer.md` for your full role definition.
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> Goal: {goal}
		> READ-ONLY. Do NOT modify any files. Bash is for read-only security scanning only.
		> Stage 0 Deliverable: Build STRIDE-lite threat model. Scan for auth/PII/crypto/session patterns. Broadcast initial threat assessment.
		> Authority: CRITICAL/HIGH findings use `[SECURITY-BLOCK]` tag — lead MUST pause autonomous mode.
		> Communication: DM lead at gates. DM architect with security VERIFY criteria needs. DM builders in security-sensitive partitions (max 2 per builder). DM test-advisor for cross-cutting test gaps (max 2).
		> Enterprise Compliance: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, read active security guidelines and cross-reference findings with enterprise guideline IDs.

		### Test Advisor

		Agent: `test-advisor` \| Advisor — informational only

		Spawn prompt:
		> You are the test-advisor for WorkGroup `{wgid}`.
		> Read `agents/test-advisor.md` for your full role definition.
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> Goal: {goal}
		> READ-ONLY. Do NOT modify any files. Bash is for read-only operations only (git log, coverage reports).
		> Stage 0 Deliverable: Establish test coverage baseline. Glob test files, run coverage if available. Broadcast baseline.
		> Communication: DM lead at gates. DM architect if VERIFY criteria aren't testable. DM builders with test improvement feedback (max 2 per builder). DM security-officer for cross-cutting security test gaps (max 2).
		> Enterprise Compliance: If `knowzcode/enterprise/compliance_manifest.md` exists and `compliance_enabled: true`, check enterprise ARC criteria for test coverage gaps.

		### Project Advisor

		Agent: `project-advisor` \| Advisor — informational only

		Spawn prompt:
		> You are the project-advisor for WorkGroup `{wgid}`.
		> Read `agents/project-advisor.md` for your full role definition.
		> Your Task: #{task-id} — claim immediately (`TaskUpdate(status: "in_progress")`). Mark completed with summary when done.
		> Goal: {goal}
		> READ-ONLY. Do NOT modify any files.
		> Stage 0 Deliverable: Read tracker for existing REFACTOR tasks and backlog context. DM lead with context summary.
		> Lifecycle: You shut down mid-Stage 2 after delivering backlog proposals — before the gap loop.
		> Communication: DM lead with backlog context and proposals. DM knowz-scribe with idea captures (if active). Do NOT DM builders or other specialists.
		> Enterprise Compliance: If `knowzcode/enterprise/compliance_manifest.md` exists, note compliance configuration gaps in backlog proposals.

		---

		## Phase 1A: Impact Analysis
		@@ -611,2 +783,7 @@

		### Specialist Reports [only when SPECIALISTS_ENABLED non-empty]
		Security Officer: {risk assessment per NodeID, attack surface changes, threat model}
		Architect: {architecture impact, layer touch points, pattern alignment}
		Test Advisor: {coverage baseline, test strategy recommendations per NodeID}

		Approve this Change Set to proceed to specification?
		@@ -664,2 +841,6 @@ ```

		### Specialist Reports [only when SPECIALISTS_ENABLED non-empty]
		Architect: {specs align with component map, drift concerns, pattern consistency}
		Test Advisor: {spec testability assessment, recommended test types per NodeID}

		Review specs and approve to proceed to implementation?
		@@ -750,2 +931,8 @@ ```

		### Specialist Reports [only when SPECIALISTS_ENABLED non-empty]
		Security Officer: Findings: {N} \| Critical: {N} \| High: {N} \| {details or [Pending]}
		Architect: Drift: {Yes/No} \| Pattern Violations: {N} \| {details}
		Test Advisor: TDD Compliance: {%} \| Missing Edge Cases: {N} \| Quality: {Good/Adequate/Poor} \| {details or [Pending]}
		Project Advisor: New REFACTOR tasks: {N} \| Ideas captured to vault: {N}

		Recommendation: {proceed / return to implementation}
		@@ -757,3 +944,3 @@
		Autonomous Mode: If `AUTONOMOUS_MODE = true`:
		- Safety check: If any security finding rated HIGH or CRITICAL → PAUSE autonomous mode for this gate. Announce: `> Autonomous Mode Paused — HIGH/CRITICAL security finding requires manual review.`
		- Safety check: If any security finding rated HIGH or CRITICAL (from reviewer OR security-officer `[SECURITY-BLOCK]`) → PAUSE autonomous mode for this gate. Announce: `> Autonomous Mode Paused — HIGH/CRITICAL security finding requires manual review.`
		- Safety check: If ARC completion < 50% → PAUSE autonomous mode for this gate. Announce: `> Autonomous Mode Paused — ARC completion below 50% requires manual review.`
		@@ -760,0 +947,0 @@ - If safety checks pass and gaps found → log `[AUTO-APPROVED] Gate #3 — proceeding to gap loop`, auto-proceed to gap loop.

+64

-1

knowzcode/claude_code_execution.md

		@@ -162,2 +162,12 @@ # Claude Code Execution Model
		\| closer \| architect \| Spec format and legacy migration \|
		\| security-officer \| lead \| Structured finding reports at gates (with `[SECURITY-BLOCK]` for CRITICAL/HIGH) \|
		\| security-officer \| architect \| Security VERIFY criteria needs during Phase 1B \|
		\| security-officer \| builder \| Security guidance for sensitive partitions (max 2 DMs per builder) \|
		\| security-officer \| test-advisor \| Cross-cutting: test gaps in security-critical paths (max 2 inter-specialist DMs) \|
		\| test-advisor \| lead \| Test quality reports at gates \|
		\| test-advisor \| architect \| VERIFY criteria testability concerns during Phase 1B \|
		\| test-advisor \| builder \| Specific test improvement feedback (max 2 DMs per builder) \|
		\| test-advisor \| security-officer \| Cross-cutting: security scenarios needing test coverage (max 2 inter-specialist DMs) \|
		\| project-advisor \| lead \| Backlog context (Stage 0) and proposals (late Stage 2) \|
		\| project-advisor \| knowz-scribe \| Idea captures for vault storage \|

		@@ -217,2 +227,5 @@ ### Gap Communication Flow
		\| reviewer(s) \| Stage 2 (1 per builder partition) \| After Gate #3 \| Incremental audit per partition (persistent through gap loop) \|
		\| security-officer \| Stage 0 (Group C) \| After Gate #3 \| Threat modeling + vulnerability scanning (officer — can block gates) \|
		\| test-advisor \| Stage 0 (Group C) \| After Gate #3 \| TDD enforcement + test quality review (advisor — informational) \|
		\| project-advisor \| Stage 0 (Group C) \| Mid-Stage 2 \| Backlog curation + idea capture (advisor — informational) \|
		\| closer \| Stage 3 \| End of workflow \| Finalization \|
		@@ -234,2 +247,15 @@

		### Orchestration Configuration

		Team sizing defaults are configurable via `knowzcode/knowzcode_orchestration.md`:

		\| Parameter \| Default \| Flag Override \| Effect \|
		\|-----------\|---------\|--------------\|--------\|
		\| `max_builders` \| 5 \| `--max-builders=N` \| Cap concurrent builders (1-5) \|
		\| `scout_mode` \| full \| `--no-scouts` \| full (3 scouts), minimal (1 scout), none (lead reads context) \|
		\| `default_specialists` \| [] \| `--specialists`, `--no-specialists` \| Project-level specialist defaults \|
		\| `mcp_agents_enabled` \| true \| `--no-mcp` \| Toggle vault agents (knowz-scout, knowz-scribe) \|

		Precedence: hardcoded defaults → orchestration config → per-invocation flags.

		### Builder Partitioning Rules
		@@ -239,3 +265,3 @@
		- Analyst dependency map determines partitions
		- Max 5 concurrent builders
		- Max `MAX_BUILDERS` concurrent builders (default 5, configurable in `knowzcode_orchestration.md`)
		- If all NodeIDs share files → single builder with subtask tracking
		@@ -271,2 +297,39 @@ - Builder-to-builder messages for interface changes affecting other partitions

		#### Specialist Agents (Group C — opt-in via `--specialists`)

		When specialists are enabled, three additional agents spawn at Stage 0 alongside Groups A and B:

		```
		Group A (always): 3 context-scouts + analyst + architect (5 agents)
		Group B (if MCP): knowz-scout + knowz-scribe (2 agents)
		Group C (if --specialists): security-officer + test-advisor + project-advisor (3 agents)
		```

		Max Stage 0 concurrent: 5-10 agents depending on orchestration config (scouts, MCP agents, specialists). Scouts shut down after Gate #2, so Stage 2 peak is manageable.

		##### Officer vs Advisor Authority

		\| Role \| Authority \| Gate Impact \|
		\|------\|-----------\|-------------\|
		\| Officer (security-officer) \| CRITICAL/HIGH findings block gates \| `[SECURITY-BLOCK]` tag pauses autonomous mode \|
		\| Advisor (test-advisor, project-advisor) \| Informational only \| Findings included in gate reports, do not block \|

		##### Direct DM Protocol

		Specialists communicate directly with builders, architect, and each other — no lead bottleneck relay:

		- security-officer → architect: Security VERIFY criteria needs during Phase 1B
		- security-officer → builder-N: Security guidance for sensitive partitions (max 2 DMs per builder)
		- test-advisor → architect: VERIFY criteria testability concerns during Phase 1B
		- test-advisor → builder-N: Specific test improvement feedback (max 2 DMs per builder)
		- project-advisor → knowz-scribe: Idea captures for vault storage
		- security-officer ↔ test-advisor: Cross-cutting test gaps in security paths (max 2 inter-specialist DMs total)

		##### Communication Discipline

		- Max 2 DMs to any individual builder from each specialist
		- Max 2 inter-specialist DMs per workflow
		- Consolidate findings — no per-file noise
		- project-advisor does NOT DM builders or other specialists (observes via task list only)

		---
		@@ -273,0 +336,0 @@

+3

-0

knowzcode/enterprise/compliance_manifest.md

		@@ -115,2 +115,5 @@ # Enterprise Compliance Manifest
		\| closer \| create_knowledge \| After Phase 3 \| Completion record, architecture changes \|
		\| security-officer \| search_knowledge \| Stage 0, Stage 2 \| Organization security standards, past security findings \|
		\| test-advisor \| (read-only) \| Stage 2 \| Enterprise ARC criteria for test coverage check \|
		\| project-advisor \| (read-only) \| Stage 0 \| Compliance config gaps for backlog proposals \|

		@@ -117,0 +120,0 @@ ---

+3

-1

knowzcode/knowzcode_loop.md

		@@ -449,4 +449,6 @@ # KnowzCode - Development Methodology & Operational Protocol

		For platforms like Cursor, Copilot, or Windsurf where there is no agent orchestration:
		For platforms like Cursor, Copilot, or Windsurf where there is no agent orchestration.

		Copilot users: Instead of manually reading phase prompts, use `#prompt:kc-*` prompt files in VS Code Copilot Chat (e.g., `#prompt:kc-work`, `#prompt:kc-specify`). These prompt files encode the sequential protocol below with `#file:` references for context. See `knowzcode/copilot_execution.md` for the full Copilot execution guide.

		```
		@@ -453,0 +455,0 @@ FOR each phase in [1A, 1B, 2A, 2B, 3]:

+588

-26

knowzcode/platform_adapters.md

		@@ -316,35 +316,80 @@ # KnowzCode Platform Adapters

		## GitHub Copilot (.github/copilot-instructions.md)
		## GitHub Copilot (.github/copilot-instructions.md + .github/prompts/*.prompt.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). 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.
		GitHub Copilot (2026) supports three instruction mechanisms used by KnowzCode:

		1. `.github/copilot-instructions.md` — Repository-level instructions, always active
		2. *`.github/prompts/.prompt.md`** — Custom prompts invocable via `#prompt:name` in VS Code
		3. MCP server tools (`.vscode/mcp.json`) — Tool access for vault queries

		Copilot operates as a single-agent, sequential platform — no multi-agent orchestration. Users manually transition between phases using prompt files. See `knowzcode/copilot_execution.md` for the full execution model.

		### A. copilot-instructions.md

		Create `.github/copilot-instructions.md`:

		```markdown
		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode Development Methodology

		This repository uses KnowzCode for structured TDD development.
		This repository uses KnowzCode for structured TDD development with quality gates.

		## Key Constraint: TDD is Mandatory
		- Write failing tests BEFORE implementation code
		- Follow Red-Green-Refactor cycle for every feature
		- No production code without corresponding test coverage
		## Required Reading
		- `knowzcode/knowzcode_loop.md` — Complete methodology (read first)
		- `knowzcode/knowzcode_project.md` — Project context and tech stack
		- `knowzcode/knowzcode_architecture.md` — Architecture documentation
		- `knowzcode/knowzcode_tracker.md` — WorkGroup status tracking

		## Workflow
		Reference `knowzcode/knowzcode_loop.md` for the complete development workflow.
		Follow these phases for all feature work:
		## Workflow Overview

		1. Impact Analysis — Propose a Change Set, get user approval
		2. Specification — Draft specs with VERIFY statements, get user approval
		3. Implementation — Strict TDD, verification loop
		4. Audit — READ-ONLY comparison against specs
		5. Finalization — Update docs, tracker, log, commit
		KnowzCode follows a 5-phase development loop with quality gates between each phase.
		Use the prompt files in `.github/prompts/` to invoke each phase:

		\| Phase \| Prompt \| Description \|
		\|-------\|--------\|-------------\|
		\| Full workflow \| `#prompt:kc-work` \| Start a new feature — creates WorkGroup, classifies tier, runs Phase 1A \|
		\| 1A: Analysis \| `#prompt:kc-analyze` \| Re-run impact analysis on existing WorkGroup \|
		\| 1B: Specification \| `#prompt:kc-specify` \| Draft specs from approved Change Set \|
		\| 2A: Implementation \| `#prompt:kc-implement` \| TDD implementation with verification loop \|
		\| 2B: Audit \| `#prompt:kc-audit` \| READ-ONLY audit against specs \|
		\| 3: Finalization \| `#prompt:kc-finalize` \| Update specs, tracker, log, commit \|
		\| Quick fix \| `#prompt:kc-fix` \| Micro-fix for small, scoped changes \|
		\| Research \| `#prompt:kc-plan` \| Investigate before implementing \|
		\| Resume \| `#prompt:kc-continue` \| Resume or advance to next phase \|

		### Typical Flow

		1. `#prompt:kc-work "Build JWT authentication"` → Creates WorkGroup, proposes Change Set, STOPs
		2. Approve Change Set
		3. `#prompt:kc-specify` → Drafts specs, STOPs
		4. Approve specs
		5. `#prompt:kc-implement` → TDD Red-Green-Refactor, STOPs
		6. `#prompt:kc-audit` → READ-ONLY audit, reports gaps, STOPs
		7. `#prompt:kc-finalize` → Updates docs, commits

		Use `#prompt:kc-continue` at any point to resume where you left off.

		## Quality Gates
		STOP and get user approval:
		- After Change Set proposal
		- After spec drafts
		- After implementation (awaiting audit)
		- After audit results (user decides on gaps)

		STOP and await user approval at each gate:
		- After Change Set proposal (1A)
		- After spec drafts (1B)
		- After implementation complete (2A — awaiting audit)
		- After audit results (2B — user decides on gaps)

		## TDD Enforcement

		TDD is mandatory — no production code without a failing test first.
		Follow Red-Green-Refactor for every feature/criterion in the spec.

		## Key Rules
		- NodeIDs are domain concepts (PascalCase), not tasks
		- Consolidate specs when domains overlap >50%
		- Every WorkGroup todo starts with `KnowzCode:` prefix
		- Target <20 specs per project
		- Log completions in `knowzcode/knowzcode_log.md`

		## Key Files
		- `knowzcode/knowzcode_loop.md` — Methodology (read first)
		- `knowzcode/knowzcode_loop.md` — Methodology
		- `knowzcode/knowzcode_project.md` — Project context
		@@ -354,12 +399,529 @@ - `knowzcode/knowzcode_architecture.md` — Architecture docs
		- `knowzcode/specs/` — Component specifications
		- `knowzcode/workgroups/` — Active session data (gitignored)

		## Rules
		- NodeIDs are domain concepts (PascalCase), not tasks
		- Consolidate specs when domains overlap >50%
		- Every WorkGroup todo starts with `KnowzCode:` prefix
		- Log completions in `knowzcode/knowzcode_log.md`
		## MCP Integration (Optional)

		If configured in `.vscode/mcp.json`, use `search_knowledge` and `ask_question` tools
		for enhanced context from knowledge vaults. All prompts work without MCP.

		## Copilot Coding Agent

		When the Copilot Coding Agent works on GitHub issues for this repository:
		- Read `knowzcode/knowzcode_loop.md` and this file for methodology
		- Follow Phase 1A→3 workflow for any non-trivial change
		- Include the Change Set in the PR description
		- Use TDD — failing test before implementation code
		- Self-audit against spec VERIFY statements before marking PR ready
		- Quality gates are deferred to PR review (no interactive approval in async mode)

		## Model Selection
		- Complex phases (1A analysis, 1B spec drafting, 2B audit): Use Claude Opus or GPT-4o
		- Implementation (2A): Any capable model with good code generation
		- Quick fixes: Any model
		```

		### B. Prompt File Templates (.github/prompts/)

		Each prompt file is invocable via `#prompt:kc-*` in VS Code Copilot Chat. All use `agent: "agent"` for file editing capability.

		#### kc-work.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Start a new KnowzCode development workflow"
		argument-hint: "Describe the feature or goal to build"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Start Workflow

		You are starting a new KnowzCode development workflow. Follow the methodology precisely.

		## Context

		Read these files for methodology and project context:
		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_project.md
		- #file:knowzcode/knowzcode_tracker.md
		- #file:knowzcode/knowzcode_architecture.md

		## Instructions

		The user's goal is provided in the chat message.

		### Step 1: Classify Tier

		Based on the goal, classify complexity:
		- Micro (single file, <50 lines, no ripple): Redirect to `#prompt:kc-fix`
		- Light (≤3 files, straightforward): Streamlined 2-phase path
		- Full (>3 files or complex): Complete 5-phase workflow

		### Step 2: Create Draft WorkGroup

		Generate a WorkGroupID: `kc-{type}-{slug}-YYYYMMDD-HHMMSS`
		Create a draft WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md` to store the analysis output.

		### Step 3: Phase 1A — Impact Analysis

		Follow Phase 1A from `knowzcode/knowzcode_loop.md`:
		1. Identify the Change Set — all components affected by this change
		2. Create NodeIDs for NEW capabilities only (domain concepts, PascalCase)
		3. Check `knowzcode/specs/` for existing specs with domain overlap
		4. Scan `knowzcode/workgroups/` for completed WorkGroups with relevant context
		5. Propose the Change Set with NodeIDs, affected files, and risk assessment

		## STOP

		Present the Change Set for user approval. Do NOT proceed until approved.

		After approval: Update `knowzcode/knowzcode_tracker.md` with new NodeIDs as `[WIP]`, then tell the user to invoke `#prompt:kc-specify` to draft specifications.
		```

		#### kc-analyze.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Re-run Phase 1A impact analysis on existing WorkGroup"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Phase 1A — Impact Analysis

		You are re-running impact analysis on an existing WorkGroup.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md

		Read `knowzcode/knowzcode_tracker.md` to find the active `[WIP]` WorkGroup.
		Then read the WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md`.

		## Instructions

		Follow Phase 1A from `knowzcode/knowzcode_loop.md`:
		1. Re-analyze the goal from the WorkGroup file
		2. Identify all affected components — check for changes since last analysis
		3. Update NodeIDs if scope has changed
		4. Check `knowzcode/specs/` for existing specs with domain overlap
		5. Update the Change Set in the WorkGroup file

		## STOP

		Present the updated Change Set for user approval.

		Next step after approval: `#prompt:kc-specify`
		```

		#### kc-specify.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Draft specifications from approved Change Set (Phase 1B)"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Phase 1B — Specification

		You are drafting specifications for the approved Change Set.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md

		Read `knowzcode/knowzcode_tracker.md` to find the active `[WIP]` WorkGroup.
		If no `[WIP]` entries found, scan `knowzcode/workgroups/` for the most recent draft WorkGroup file.
		Then read the WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md` for the approved Change Set.

		## Instructions

		Follow Phase 1B from `knowzcode/knowzcode_loop.md`:

		For each NodeID in the approved Change Set:
		1. Draft `knowzcode/specs/{NodeID}.md` using the 4-section format:
		- Rules & Decisions — Key architectural decisions, business rules, constraints
		- Interfaces — Public contracts: inputs, outputs, API signatures, dependencies
		- Verification Criteria — Testable `VERIFY:` assertions (minimum 2 per spec)
		- Debt & Gaps — Known limitations and future work
		2. Minimum valid spec: 1+ Rules, 1+ Interface, 2+ VERIFY statements
		3. Check existing specs — if >50% domain overlap, UPDATE existing spec instead
		4. Update the WorkGroup file with spec status

		## STOP

		Present all drafted specs for user approval. Do NOT proceed until approved.

		After approval: Commit the specs as a pre-implementation checkpoint: `git commit -m "specs: draft specs for {WorkGroupID}"`

		Next step: `#prompt:kc-implement`
		```

		#### kc-implement.prompt.md

		```markdown
		---
		agent: "agent"
		description: "TDD implementation with verification loop (Phase 2A)"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Phase 2A — Implementation

		You are implementing the approved specifications using strict TDD.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md

		Read `knowzcode/knowzcode_tracker.md` to find the active `[WIP]` WorkGroup.
		Then read:
		- The WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md`
		- All spec files listed in the Change Set from `knowzcode/specs/`

		## Instructions

		Follow Phase 2A from `knowzcode/knowzcode_loop.md`:

		For EACH feature/criterion in the specs:
		1. RED: Write a failing test that defines expected behavior. Run test → confirm FAIL
		2. GREEN: Write MINIMAL code to make the test pass. Run test → confirm PASS
		3. REFACTOR: Clean up while keeping all tests green

		### Verification Loop (must pass before reporting complete)

		1. Run all tests → if FAIL: fix and restart
		2. Run static analysis → if issues: fix and restart
		3. Run build → if FAIL: fix and restart
		4. Verify all VERIFY: criteria from specs → if unmet: implement and restart
		5. All checks pass → report complete

		Maximum 10 iterations. If exceeded, report blocker.

		### Spec Issues

		If you discover a spec is incorrect during implementation:
		- Tag `[SPEC_ISSUE]` in the WorkGroup file with details
		- Continue with best judgment
		- Report in completion summary

		## STOP

		Report implementation results: test counts, verification iterations, criteria status.

		Next step: `#prompt:kc-audit`
		```

		#### kc-audit.prompt.md

		```markdown
		---
		agent: "agent"
		description: "READ-ONLY completeness audit against specs (Phase 2B)"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Phase 2B — Completeness Audit

		You are performing an independent, READ-ONLY audit of the implementation.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md

		Read `knowzcode/knowzcode_tracker.md` to find the active `[WIP]` WorkGroup.
		Then read:
		- The WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md`
		- All spec files listed in the Change Set from `knowzcode/specs/`
		- The implementation files listed in the Change Set

		## Instructions

		Follow Phase 2B from `knowzcode/knowzcode_loop.md`:

		CRITICAL: This is a READ-ONLY audit. Do NOT modify any source files.

		1. For each NodeID, compare implementation against every VERIFY statement in its spec
		2. Calculate objective completion percentage per NodeID and overall
		3. Identify gaps: missing features, incomplete criteria, untested paths
		4. Check for security concerns: input validation, authentication, data exposure
		5. Check for orphan code: implementation not covered by any spec
		6. Assess risk for any gaps found

		### Standalone Audit Types

		If the user specifies an audit type instead of a WorkGroup audit:
		- spec: Audit spec quality — completeness, VERIFY statement coverage, format compliance
		- architecture: Compare architecture doc against actual codebase structure
		- security: Focused security review — OWASP top 10, input validation, auth flows
		- integration: Check integration points, API contracts, dependency health

		## STOP

		Present audit results with completion percentage, gap list, and risk assessment.

		User decides:
		- Return to `#prompt:kc-implement` to fix gaps
		- Accept and proceed to `#prompt:kc-finalize`
		- Modify specs to match implementation
		- Cancel the WorkGroup
		```

		#### kc-finalize.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Finalize WorkGroup — update specs, tracker, log, commit (Phase 3)"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Phase 3 — Finalization

		You are finalizing the WorkGroup after approved implementation and audit.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md
		- #file:knowzcode/knowzcode_architecture.md

		Read `knowzcode/knowzcode_tracker.md` to find the active `[WIP]` WorkGroup.
		Then read the WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md`.

		## Instructions

		Follow Phase 3 from `knowzcode/knowzcode_loop.md`:

		1. Finalize Specs: Update each `knowzcode/specs/{NodeID}.md` to as-built state (Status: As-Built)
		2. Architecture Check: Compare `knowzcode/knowzcode_architecture.md` against the Change Set. Fix simple discrepancies directly; document complex ones for user review
		3. Log Entry: Prepend an `ARC-Completion` entry to `knowzcode/knowzcode_log.md` with WorkGroupID, NodeIDs, verification summary, architectural learnings, and ripple effects
		4. Update Tracker: Change NodeID statuses from `[WIP]` to `[VERIFIED]` in `knowzcode/knowzcode_tracker.md`. Create `REFACTOR_` tasks for significant tech debt
		5. Final Commit: Stage and commit all changes (source + knowzcode files)
		6. Close WorkGroup: Mark the WorkGroup file as closed

		## Output

		Report completion with summary of what was delivered and any `REFACTOR_` tasks created.
		```

		#### kc-fix.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Quick targeted fix using micro-fix protocol"
		argument-hint: "Describe the bug or issue to fix"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Micro-Fix

		You are performing a quick, targeted fix using the micro-fix protocol.

		## Context

		- #file:knowzcode/knowzcode_loop.md

		## Scope Guard

		This workflow is for changes that are:
		- Single file (or minimal multi-file with no ripple effects)
		- <50 lines changed
		- No architectural impact

		If the fix exceeds this scope, inform the user and suggest `#prompt:kc-work` instead.

		## Instructions

		Follow the Micro-Fix Protocol from `knowzcode/knowzcode_loop.md` Section 4:

		1. Implement the fix
		2. Test — run targeted tests for the affected code
		3. Log — prepend a `MicroFix` entry to `knowzcode/knowzcode_log.md`:
		- Type: MicroFix
		- File/NodeID affected
		- User request, action taken, verification outcome
		4. Commit with `fix: {description}` message
		```

		#### kc-plan.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Research and investigate before implementing"
		argument-hint: "Describe the topic to research"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Plan / Investigate

		You are researching a topic before implementation. This is an investigation workflow, not a build workflow.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_project.md
		- #file:knowzcode/knowzcode_architecture.md

		## Instructions

		The user's research topic is provided in the chat message.

		1. Explore the codebase — search for relevant files, patterns, and existing implementations
		2. Read existing specs — check `knowzcode/specs/` for related components
		3. Check history — scan `knowzcode/workgroups/` for past WorkGroups that touched similar areas
		4. Analyze architecture — review `knowzcode/knowzcode_architecture.md` for structural context
		5. Present findings with:
		- Current state of the relevant code
		- Existing patterns and conventions
		- Options for implementation (with trade-offs)
		- Recommended approach

		## STOP

		Present research findings and recommendations.

		To implement: Tell the user to invoke `#prompt:kc-work` with their chosen approach.
		```

		#### kc-continue.prompt.md

		```markdown
		---
		agent: "agent"
		description: "Resume interrupted work or advance to next phase"
		---

		<!-- Generated by KnowzCode vX.Y.Z /kc:init -->

		# KnowzCode: Continue / Resume

		You are resuming an interrupted KnowzCode workflow or advancing to the next phase.

		## Context

		- #file:knowzcode/knowzcode_loop.md
		- #file:knowzcode/knowzcode_tracker.md

		## Instructions

		### Step 1: Find Active WorkGroup

		Read `knowzcode/knowzcode_tracker.md` and find entries with `[WIP]` status.

		- One active WorkGroup: Use it
		- Multiple active: Present the list and ask the user which to resume
		- None active: Inform the user and suggest `#prompt:kc-work`

		### Step 2: Determine Current Phase

		Read the WorkGroup file at `knowzcode/workgroups/{WorkGroupID}.md`.
		Check the Phase History table to determine the current state.

		### Step 3: Resume or Advance

		\| WorkGroup State \| Action \|
		\|----------------\|--------\|
		\| Phase 1A in progress \| Complete the impact analysis, present Change Set \|
		\| Phase 1A complete, awaiting approval \| Present Change Set for approval \|
		\| Phase 1A approved, specs not started \| Begin Phase 1B — draft specs \|
		\| Phase 1B in progress \| Complete spec drafting \|
		\| Phase 1B complete, awaiting approval \| Present specs for approval \|
		\| Phase 1B approved, implementation not started \| Begin Phase 2A — TDD implementation \|
		\| Phase 2A in progress \| Resume implementation from outstanding todos \|
		\| Phase 2A complete \| Advise: `#prompt:kc-audit` \|
		\| Phase 2B complete, gaps found \| Present options: fix gaps or accept \|
		\| Phase 2B complete, no gaps \| Begin Phase 3 — finalization \|
		\| Phase 3 in progress \| Complete finalization \|

		### Step 4: Present Status

		```
		## Resuming WorkGroup: {WorkGroupID}

		Goal: {primary goal}
		Phase: {current phase}
		NodeIDs: {list}

		Outstanding Work:
		{list from WorkGroup file}

		Continuing from where we left off...
		```

		Then proceed with the appropriate phase instructions from `knowzcode/knowzcode_loop.md`.
		```

		### C. .vscode/mcp.json Template

		Optionally generated by `/kc:init` when Copilot is detected and MCP is configured:

		```json
		{
		"servers": {
		"knowzcode": {
		"type": "http",
		"url": "${input:knowzcode_mcp_url}",
		"headers": {
		"x-api-key": "${input:knowzcode_api_key}"
		}
		}
		},
		"inputs": [
		{
		"id": "knowzcode_mcp_url",
		"description": "KnowzCode MCP server URL",
		"type": "promptString"
		},
		{
		"id": "knowzcode_api_key",
		"description": "KnowzCode API key",
		"type": "promptString",
		"password": true
		}
		]
		}
		```

		### D. Copilot-Specific Notes

		VS Code usage:
		- Invoke prompts via `#prompt:kc-work`, `#prompt:kc-specify`, etc. in Copilot Chat
		- Add extra files to context with `#file:path/to/file` in the chat message
		- All prompt files use `agent: "agent"` frontmatter for file editing and terminal access
		- Model can be selected per session — prefer stronger models for analysis/audit phases

		Copilot CLI fallback:
		- CLI does not support `#prompt:` syntax
		- Check current CLI documentation for file reference syntax — it may differ from VS Code
		- Alternatively, reference the methodology directly or paste prompt content into the CLI

		Copilot Coding Agent:
		- Follows `.github/copilot-instructions.md` automatically when processing GitHub issues
		- Runs all phases autonomously — quality gates deferred to PR review
		- Does not use prompt files (uses repository instructions only)

		Execution model:
		- See `knowzcode/copilot_execution.md` for the full execution guide
		- Single-agent, sequential execution — user manually transitions between phases
		- No multi-agent orchestration (no Parallel Teams, no agent spawning)
		- WorkGroup files carry state between prompt invocations

		---

		## Windsurf (`.windsurf/rules/knowzcode.md`)
		@@ -366,0 +928,0 @@

+1

-1

package.json

		{
		"name": "knowzcode",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Platform-agnostic AI development methodology with TDD, quality gates, and structured workflows",
		@@ -5,0 +5,0 @@ "type": "module",

+43

-5

README.md

		@@ -9,3 +9,3 @@ # KnowzCode
		[![Claude Code Plugin](https://img.shields.io/badge/Claude_Code-Plugin-purple)](https://github.com/knowz-io/knowzcode)
		[![Version](https://img.shields.io/badge/version-0.2.1-blue)](https://github.com/knowz-io/knowzcode/releases)
		[![Version](https://img.shields.io/badge/version-0.3.1-blue)](https://github.com/knowz-io/knowzcode/releases)

		@@ -111,3 +111,3 @@ [Installation](#installation) · [Quick Start](#quick-start) · [When to Use It](#when-to-use-knowzcode) · [How It Works](#how-it-works) · [Commands](#commands) · [Docs](#documentation)
		\| Cursor \| `.cursor/rules/.mdc` + `.cursor/commands/.md` \| Rules + commands (beta) \|
		\| GitHub Copilot \| `.github/copilot-instructions.md` + `.github/agents/*.agent.md` \| Instructions + agent definitions \|
		\| GitHub Copilot \| `.github/copilot-instructions.md` + `.github/prompts/kc-*.prompt.md` \| Full support (instructions + 9 prompt files + MCP) \|
		\| Windsurf \| `.windsurf/rules/.md` + `.windsurf/workflows/.md` \| Rules + workflows \|
		@@ -189,3 +189,3 @@
		The real product is Layer 1 — the `knowzcode/` directory. Everything else enhances it.
		On Claude Code, Layer 4 provides 10 specialized agents with parallel orchestration.
		On Claude Code, Layer 4 provides 14 specialized agents (11 core + 3 opt-in specialists) with parallel orchestration.
		On other platforms, the AI follows the same methodology directly.
		@@ -207,3 +207,3 @@ See [Understanding KnowzCode](./docs/understanding-knowzcode.md) for a deep dive.
		<details>
		<summary><strong>Agent Teams Setup & Roster (10 agents)</strong></summary>
		<summary><strong>Agent Teams Setup & Roster (14 agents)</strong></summary>

		@@ -222,2 +222,3 @@ Parallel and Sequential Teams require [Agent Teams (experimental)](https://code.claude.com/docs/en/agent-teams). Enable by adding the following to your Claude Code `settings.json`:
		\| `knowz-scout` \| MCP vault research (conventions, decisions) \| Discovery \|
		\| `knowz-scribe` \| MCP vault writes (learning capture, audit trails) \| All phases \|
		\| `analyst` \| Impact analysis, Change Set proposals \| 1A \|
		@@ -228,2 +229,5 @@ \| `architect` \| Specification drafting, architecture review \| 1B \|
		\| `closer` \| Finalization, learning capture \| 3 \|
		\| `security-officer` \| Threat modeling, vulnerability scanning (opt-in) \| All phases \|
		\| `test-advisor` \| TDD enforcement, test quality review (opt-in) \| All phases \|
		\| `project-advisor` \| Backlog curation, future work ideas (opt-in) \| Discovery–2A \|
		\| `microfix-specialist` \| Quick targeted fixes \| Utility \|
		@@ -235,7 +239,41 @@ \| `knowledge-migrator` \| Knowledge migration between vaults \| Utility \|

		<details>
		<summary><strong>Opt-in Specialist Agents</strong></summary>

		Activate specialists with `--specialists` in `/kc:work` or `/kc:audit`:

		```bash
		/kc:work "Build auth system" --specialists # All 3 specialists
		/kc:work "Build auth system" --specialists=security # Security officer only
		/kc:audit --specialists # Deep audit with specialists
		```

		- security-officer: Officer authority — CRITICAL/HIGH findings block gates
		- test-advisor: Advisory — TDD compliance, assertion quality, coverage gaps
		- project-advisor: Advisory — backlog ideas, tech debt tracking (shuts down mid-implementation)

		Specialists communicate directly with builders (max 2 DMs each) and report findings at quality gates. Supported in Parallel Teams and Subagent modes only.

		</details>

		See the [Workflow Reference](./docs/workflow-reference.md) for detailed orchestration flows.

		### GitHub Copilot

		Copilot users invoke phases via prompt files in VS Code Copilot Chat:

		```bash
		#prompt:kc-work "Build JWT authentication" # Start feature workflow
		#prompt:kc-specify # Draft specs (after Change Set approved)
		#prompt:kc-implement # TDD implementation
		#prompt:kc-audit # READ-ONLY audit
		#prompt:kc-finalize # Finalize and commit
		#prompt:kc-continue # Resume where you left off
		```

		Generated by `/kc:init` into `.github/prompts/`. See `knowzcode/copilot_execution.md` for details.

		### Other Platforms

		Gemini, Cursor, Copilot, Codex, and Windsurf follow the same methodology phases sequentially — the AI reads prompt templates from `knowzcode/prompts/` and follows the same quality gates. No agent orchestration is needed.
		Gemini, Cursor, Codex, and Windsurf follow the same methodology phases sequentially — the AI reads prompt templates from `knowzcode/prompts/` and follows the same quality gates. No agent orchestration is needed.

		@@ -242,0 +280,0 @@ ## Project Structure

+1

-1

skills/alias-resolver.json

		{
		"name": "alias-resolver",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Resolves friendly natural-language aliases to KnowzCode canonical values (phase, audit, plan, workgroup_type).",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/architecture-diff.json

		{
		"name": "architecture-diff",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Highlights differences between specs and the Mermaid flowchart in knowzcode_architecture.md.",
		@@ -5,0 +5,0 @@ "parameters": [],

+1

-1

skills/check-installation-status.json

		{
		"name": "check-installation-status",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Checks if KnowzCode is initialized in the current project and reports current status",
		@@ -5,0 +5,0 @@

+2

-1

skills/continue.md

		@@ -55,2 +55,3 @@ ---
		- Autonomous Mode: If the WorkGroup file contains `Autonomous Mode: Active`, restore `AUTONOMOUS_MODE = true` and announce: `> Autonomous Mode: RESTORED — continuing with auto-approved gates.`
		- Orchestration Config: If `knowzcode/knowzcode_orchestration.md` exists, parse and restore `MAX_BUILDERS`, `SCOUT_MODE`, `MCP_AGENTS_ENABLED`, `DEFAULT_SPECIALISTS` (same logic as work.md Step 2.4). Defaults apply if file is absent.

		@@ -67,3 +68,3 @@ ### Step 3: Resume at Current Phase
		- Resume by recreating the team and spawning agents appropriate for the current stage:
		- Stage 0/1: Spawn analyst + architect (scouts if context stale)
		- Stage 0/1: Spawn analyst + architect. If `SCOUT_MODE != "none"` and context is stale, re-spawn scout(s) per SCOUT_MODE.
		- Stage 2: Spawn builder(s) per the dependency map + reviewer if any NodeIDs are past implementation
		@@ -70,0 +71,0 @@ - Stage 3: Spawn closer

+1

-1

skills/environment-guard.json

		{
		"name": "environment-guard",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Verifies that knowzcode/environment_context.md no longer contains placeholder brackets.",
		@@ -5,0 +5,0 @@ "parameters": [],

+1

-1

skills/generate-workgroup-id.json

		{
		"name": "generate-workgroup-id",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Generates a WorkGroupID following the KnowzCode convention [type]-[slug]-YYYYMMDD-HHMMSS. The slug is a 2-4 word descriptor extracted from the goal.",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/install-knowzcode.json

		{
		"name": "install-knowzcode",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Initializes KnowzCode directory structure and required files in the current project",
		@@ -5,0 +5,0 @@

+1

-1

skills/load-core-context.json

   "name": "load-core-context",
   "version": "0.2.1",
   "version": "0.3.1",
   "description": "Loads the KnowzCode project overview, architecture, tracker, log header, and automation manifest for downstream steps.",
 @@ -5,0 +5,0 @@ "parameters": [],

+1

-1

skills/log-entry-builder.json

		{
		"name": "log-entry-builder",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Appends structured entries to knowzcode/knowzcode_log.md with KnowzCode formatting.",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/spec-quality-check.json

		{
		"name": "spec-quality-check",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Validates KnowzCode spec files for mandatory sections. Supports new 4-section format and legacy numbered format.",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/spec-template.json

		{
		"name": "spec-template",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Seeds or repairs KnowzCode spec files with the lean 4-section template.",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/spec-validator.json

		{
		"name": "spec-validator",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Validates NodeID specification completeness and quality. Supports new 4-section format (preferred) and legacy numbered sections (deprecated).",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/tracker-scan.json

		{
		"name": "tracker-scan",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Extracts NodeID statuses and WorkGroup assignments from the KnowzCode tracker.",
		@@ -5,0 +5,0 @@ "parameters": [],

+1

-1

skills/tracker-update.json

		{
		"name": "tracker-update",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Applies validated updates to knowzcode/knowzcode_tracker.md while preserving table structure.",
		@@ -5,0 +5,0 @@ "parameters": [

+1

-1

skills/validate-installation.json

		{
		"name": "validate-installation",
		"version": "0.2.1",
		"version": "0.3.1",
		"description": "Validates that KnowzCode installation completed successfully with required directories and files",
		@@ -5,0 +5,0 @@

		@@ -162,2 +162,12 @@ # Claude Code Execution Model
		\| closer \| architect \| Spec format and legacy migration \|
		\| security-officer \| lead \| Structured finding reports at gates (with `[SECURITY-BLOCK]` for CRITICAL/HIGH) \|
		\| security-officer \| architect \| Security VERIFY criteria needs during Phase 1B \|
		\| security-officer \| builder \| Security guidance for sensitive partitions (max 2 DMs per builder) \|
		\| security-officer \| test-advisor \| Cross-cutting: test gaps in security-critical paths (max 2 inter-specialist DMs) \|
		\| test-advisor \| lead \| Test quality reports at gates \|
		\| test-advisor \| architect \| VERIFY criteria testability concerns during Phase 1B \|
		\| test-advisor \| builder \| Specific test improvement feedback (max 2 DMs per builder) \|
		\| test-advisor \| security-officer \| Cross-cutting: security scenarios needing test coverage (max 2 inter-specialist DMs) \|
		\| project-advisor \| lead \| Backlog context (Stage 0) and proposals (late Stage 2) \|
		\| project-advisor \| knowz-scribe \| Idea captures for vault storage \|

		@@ -217,2 +227,5 @@ ### Gap Communication Flow
		\| reviewer(s) \| Stage 2 (1 per builder partition) \| After Gate #3 \| Incremental audit per partition (persistent through gap loop) \|
		\| security-officer \| Stage 0 (Group C) \| After Gate #3 \| Threat modeling + vulnerability scanning (officer — can block gates) \|
		\| test-advisor \| Stage 0 (Group C) \| After Gate #3 \| TDD enforcement + test quality review (advisor — informational) \|
		\| project-advisor \| Stage 0 (Group C) \| Mid-Stage 2 \| Backlog curation + idea capture (advisor — informational) \|
		\| closer \| Stage 3 \| End of workflow \| Finalization \|
		@@ -234,2 +247,15 @@

		### Orchestration Configuration

		Team sizing defaults are configurable via `knowzcode/knowzcode_orchestration.md`:

		\| Parameter \| Default \| Flag Override \| Effect \|
		\|-----------\|---------\|--------------\|--------\|
		\| `max_builders` \| 5 \| `--max-builders=N` \| Cap concurrent builders (1-5) \|
		\| `scout_mode` \| full \| `--no-scouts` \| full (3 scouts), minimal (1 scout), none (lead reads context) \|
		\| `default_specialists` \| [] \| `--specialists`, `--no-specialists` \| Project-level specialist defaults \|
		\| `mcp_agents_enabled` \| true \| `--no-mcp` \| Toggle vault agents (knowz-scout, knowz-scribe) \|

		Precedence: hardcoded defaults → orchestration config → per-invocation flags.

		### Builder Partitioning Rules
		@@ -239,3 +265,3 @@
		- Analyst dependency map determines partitions
		- Max 5 concurrent builders
		- Max `MAX_BUILDERS` concurrent builders (default 5, configurable in `knowzcode_orchestration.md`)
		- If all NodeIDs share files → single builder with subtask tracking
		@@ -271,2 +297,39 @@ - Builder-to-builder messages for interface changes affecting other partitions

		#### Specialist Agents (Group C — opt-in via `--specialists`)

		When specialists are enabled, three additional agents spawn at Stage 0 alongside Groups A and B:

		```
		Group A (always): 3 context-scouts + analyst + architect (5 agents)
		Group B (if MCP): knowz-scout + knowz-scribe (2 agents)
		Group C (if --specialists): security-officer + test-advisor + project-advisor (3 agents)
		```

		Max Stage 0 concurrent: 5-10 agents depending on orchestration config (scouts, MCP agents, specialists). Scouts shut down after Gate #2, so Stage 2 peak is manageable.

		##### Officer vs Advisor Authority

		\| Role \| Authority \| Gate Impact \|
		\|------\|-----------\|-------------\|
		\| Officer (security-officer) \| CRITICAL/HIGH findings block gates \| `[SECURITY-BLOCK]` tag pauses autonomous mode \|
		\| Advisor (test-advisor, project-advisor) \| Informational only \| Findings included in gate reports, do not block \|

		##### Direct DM Protocol

		Specialists communicate directly with builders, architect, and each other — no lead bottleneck relay:

		- security-officer → architect: Security VERIFY criteria needs during Phase 1B
		- security-officer → builder-N: Security guidance for sensitive partitions (max 2 DMs per builder)
		- test-advisor → architect: VERIFY criteria testability concerns during Phase 1B
		- test-advisor → builder-N: Specific test improvement feedback (max 2 DMs per builder)
		- project-advisor → knowz-scribe: Idea captures for vault storage
		- security-officer ↔ test-advisor: Cross-cutting test gaps in security paths (max 2 inter-specialist DMs total)

		##### Communication Discipline

		- Max 2 DMs to any individual builder from each specialist
		- Max 2 inter-specialist DMs per workflow
		- Consolidate findings — no per-file noise
		- project-advisor does NOT DM builders or other specialists (observes via task list only)

		---
		@@ -273,0 +336,0 @@

		@@ -115,2 +115,5 @@ # Enterprise Compliance Manifest
		\| closer \| create_knowledge \| After Phase 3 \| Completion record, architecture changes \|
		\| security-officer \| search_knowledge \| Stage 0, Stage 2 \| Organization security standards, past security findings \|
		\| test-advisor \| (read-only) \| Stage 2 \| Enterprise ARC criteria for test coverage check \|
		\| project-advisor \| (read-only) \| Stage 0 \| Compliance config gaps for backlog proposals \|

		@@ -117,0 +120,0 @@ ---

		@@ -55,2 +55,3 @@ ---
		- Autonomous Mode: If the WorkGroup file contains `Autonomous Mode: Active`, restore `AUTONOMOUS_MODE = true` and announce: `> Autonomous Mode: RESTORED — continuing with auto-approved gates.`
		- Orchestration Config: If `knowzcode/knowzcode_orchestration.md` exists, parse and restore `MAX_BUILDERS`, `SCOUT_MODE`, `MCP_AGENTS_ENABLED`, `DEFAULT_SPECIALISTS` (same logic as work.md Step 2.4). Defaults apply if file is absent.

		@@ -67,3 +68,3 @@ ### Step 3: Resume at Current Phase
		- Resume by recreating the team and spawning agents appropriate for the current stage:
		- Stage 0/1: Spawn analyst + architect (scouts if context stale)
		- Stage 0/1: Spawn analyst + architect. If `SCOUT_MODE != "none"` and context is stale, re-spawn scout(s) per SCOUT_MODE.
		- Stage 2: Spawn builder(s) per the dependency map + reviewer if any NodeIDs are past implementation
		@@ -70,0 +71,0 @@ - Stage 3: Spawn closer

knowzcode - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics