docs: add documentation phase to release workflow

Sync from CLCrawford-dev/keep-protocol.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Author: nTEG-dev

docs/release-workflow-template.md

@@ -7,7 +7,8 @@ How to structure Linear issues for any keep-protocol release. This ensures we ne
 1. **Every release is a Linear project** with step-by-step issues
 2. **Issues are chained with blockers** — can't skip ahead
 3. **Staging before production** — always test before going live
-4. **Pick up where you left off** — find first unblocked issue
+4. **Documentation before tagging** — docs are part of the release, not afterthought
+5. **Pick up where you left off** — find first unblocked issue
 
 ## The Three Remotes
 
@@ -19,6 +20,30 @@ How to structure Linear issues for any keep-protocol release. This ensures we ne
 
 **Flow:** staging → origin → nteg
 
+## Documentation Files
+
+Every release should consider updating these files:
+
+| File | Purpose | Update When |
+|------|---------|-------------|
+| **CHANGELOG.md** | Version history | Every release (required) |
+| **README.md** | Human quick-start | API changes, new features |
+| **AGENTS.md** | AI coding assistants | Protocol/SDK changes |
+| **SKILL.md** | ClawHub marketplace | Feature changes, new tags |
+
+### Documentation Checklist
+
+Before tagging any release, verify:
+
+```
+□ CHANGELOG.md — New version section added with all changes
+□ README.md — Version references updated (e.g., "v0.3.0+")
+□ README.md — New features documented if user-facing
+□ AGENTS.md — Updated if protocol, SDK methods, or wire format changed
+□ SKILL.md — Updated if features or tags changed for ClawHub
+□ Version string — Updated in pyproject.toml and/or go.mod
+```
+
 ## Release Issue Template
 
 For each release (e.g., v0.3.2), create these issues in order. Each blocks the next.
@@ -33,11 +58,23 @@ KP-XX: Implement [feature name]
 └── Push to: STAGING only
 ```
 
-### Phase 2: Staging Verification
+### Phase 2: Documentation (NEW)
+
+```
+KP-XX: Update documentation for [feature/version]
+├── Blocked by: Implementation issue(s)
+├── CHANGELOG.md: Add version entry with all changes
+├── README.md: Update if API/usage changes
+├── AGENTS.md: Update if protocol/SDK changes
+├── SKILL.md: Update if features/tags change
+└── Acceptance: All docs accurate and consistent
+```
+
+### Phase 3: Staging Verification
 
 ```
 KP-XX: Test [feature] on staging
-├── Blocked by: Implementation issue
+├── Blocked by: Documentation issue
 ├── Test plan: Unit tests, integration tests, manual tests
 ├── Branch: Same feature branch on staging
 └── Acceptance: All tests pass
@@ -50,7 +87,7 @@ KP-XX: Merge to staging main
 └── Verification: Code on staging/main
 ```
 
-### Phase 3: Production
+### Phase 4: Production
 
 ```
 KP-XX: Push to origin (production)
@@ -74,7 +111,7 @@ KP-XX: Test vX.Y.Z in clean sandbox
 └── Verification: New user experience works
 ```
 
-### Phase 4: Public Release
+### Phase 5: Public Release
 
 ```
 KP-XX: Publish vX.Y.Z to ClawHub
@@ -96,7 +133,10 @@ KP-XX: Sync vX.Y.Z to nteg mirror
 Implementation
      │
      ▼
-Test on Staging ←── YOU ARE HERE (find first unblocked)
+Documentation Update        ← NEW STEP
+     │
+     ▼
+Test on Staging
      │
      ▼
 Merge to Staging Main
@@ -143,42 +183,46 @@ Example: keep-protocol v0.4.0 — Public Relays
 
 Copy the issue structure above. For each feature in the release:
 - One implementation issue
-- One test issue (blocked by implementation)
+- One documentation issue (blocked by implementation)
+- One test issue (blocked by documentation)
 - Share the remaining release issues (merge, push, tag, sandbox, clawhub, sync)
 
 ### 3. Set up blockers
 
 Each issue should be blocked by the previous one:
 ```
-Implementation → Test → Merge → Push → Tag → Sandbox → ClawHub → Sync
+Implementation → Documentation → Test → Merge → Push → Tag → Sandbox → ClawHub → Sync
 ```
 
 ### 4. Start work
 
 Begin with the implementation issue. The chain guides you through.
 
-## Example: v0.3.2 Release (ensure_server)
+## Example: v0.5.0 Release (with docs)
 
 | Issue | Title | Blocked By |
 |-------|-------|------------|
-| KP-11 | Implement ensure_server() | — |
-| KP-16 | Test on staging | KP-11 |
-| KP-17 | Merge to staging main | KP-16 |
-| KP-18 | Push to origin | KP-17 |
-| KP-19 | Tag v0.3.2 + CI | KP-18 |
-| KP-20 | Clean sandbox test | KP-19 |
-| KP-21 | Publish ClawHub | KP-20 |
-| KP-22 | Sync nteg mirror | KP-21 |
+| KP-30 | Implement semantic routing | — |
+| KP-31 | Update docs for semantic routing | KP-30 |
+| KP-32 | Test on staging | KP-31 |
+| KP-33 | Merge to staging main | KP-32 |
+| KP-34 | Push to origin | KP-33 |
+| KP-35 | Tag v0.5.0 + CI | KP-34 |
+| KP-36 | Clean sandbox test | KP-35 |
+| KP-37 | Publish ClawHub | KP-36 |
+| KP-38 | Sync nteg mirror | KP-37 |
 
 ## Anti-Patterns (Don't Do These)
 
 | Wrong | Right |
 |-------|-------|
 | Push feature branch to origin | Push to staging first |
 | Skip staging tests | Always test on staging |
+| Tag before updating docs | Docs are part of the release |
 | Publish to ClawHub before CI green | Wait for ALL jobs green |
 | Forget to sync nteg mirror | Always sync after ClawHub |
 | Create issues without blockers | Chain every issue |
+| Update CHANGELOG after release | CHANGELOG before tagging |
 
 ## Session Handoff
 
@@ -195,4 +239,5 @@ When starting a session:
 ---
 
 *Template established: Feb 3, 2026*
+*Updated: Feb 3, 2026 — Added documentation phase to release workflow*
 *Based on KP-11 release workflow lessons learned*