Completion Marker Optimization
Efficient completion marker generation to prevent timeouts and improve task completion reliability. Eliminates timeout issues and reduces completion time by 10-15 seconds.
⚠️ CRITICAL PROTOCOL - READ FIRST ⚠️
THE COMPLETION MARKER MUST BE OUTPUT AS A SINGLE, ATOMIC STRING. STREAMING CHARACTER-BY-CHARACTER VIOLATES THE PROTOCOL AND CAUSES DETECTION FAILURES.
Protocol Violation Rate: 100% of analyzed tasks show streaming violations despite explicit instructions.
Impact:
- Orchestrator may fail to detect completion
- Potential parsing issues
- Token waste (23 tokens → 1 token for marker)
- Timeout issues (15+ seconds)
CRITICAL RULES:
- Buffer the entire marker before outputting
- Never stream it character-by-character
- Output the complete string in a single response
- The orchestrator expects atomic output - streaming may cause detection failures
- Output
<ralph>COMPLETE</ralph>exactly once. Do not repeat it. Duplicate output is invalid. - Place the marker early in your final response (e.g. immediately after the verification summary) so that if the response is truncated, completion is still detected.
Common mistake: Do not output the marker twice. Invalid example: <ralph>COMPLETE</ralph><ralph>COMPLETE</ralph>.
Overview
Problem: Character-by-character streaming causes timeouts (15+ seconds) and protocol violations
Solution: Atomic completion marker output as single string
Impact: Eliminate timeout issues, reduce completion time by 10-15 seconds, ensure 100% protocol compliance
Output Format
Visual Examples: Correct vs Incorrect
✅ CORRECT: Atomic Output (Single Token)
The marker is output as one complete string in a single response:
## Task Complete
All functionality has been implemented and verified.
<ralph>COMPLETE</ralph>
Token Breakdown (Correct):
- Single token:
<ralph>COMPLETE</ralph> - Output in one response
- Orchestrator detects immediately
❌ INCORRECT: Streaming (Multiple Tokens)
The marker is streamed character-by-character across multiple tokens:
<
ral
ph
>COMPLETE</ralph>
Token Breakdown (Incorrect):
- Token 1:
< - Token 2:
ral - Token 3:
ph - Token 4:
>COMPLETE</ralph> - Result: Orchestrator may not detect completion, parsing issues occur
Why This Fails:
- Orchestrator expects complete marker in single token
- Streaming violates protocol
- Detection may fail or be delayed
- Wastes tokens (4 tokens vs 1 token)
❌ INCORRECT: Incremental Output
# WRONG: Incremental output
<ralph
>COMPLETE
</ralph>
Token Breakdown (Incorrect):
- Token 1:
<ralph - Token 2:
>COMPLETE - Token 3:
</ralph> - Result: Protocol violation, detection failure
❌ INCORRECT: Shell Echo Commands
# WRONG: Don't use echo
echo "<ralph>COMPLETE</ralph>"
Why This Fails:
- Shell commands don't output to orchestrator
- Marker must be in assistant response text
- Orchestrator only reads assistant responses, not shell output
Timing
Output Immediately After Verification
Output completion marker immediately after final verification passes:
## Verification Complete
- [x] TypeScript compilation passes
- [x] Browser testing completed
- [x] All success criteria met
- [x] Progress.txt updated
<ralph>COMPLETE</ralph>
Don't Perform Cleanup After Marker
Signal completion before resource cleanup:
# ✅ CORRECT: Completion before cleanup
<ralph>COMPLETE</ralph>
# Cleanup operations (if needed)
❌ WRONG: Cleanup before completion
# WRONG: Cleanup before completion marker
# Cleanup operations
<ralph>COMPLETE</ralph>
Validation Before Completion
Pre-Completion Validation Checklist
CRITICAL: Complete ALL items before outputting marker. This checklist prevents protocol violations.
Task Completion Verification:
- All success criteria met
- Functional testing completed
- TypeScript compilation passed (if applicable)
- Browser testing completed (if applicable)
- No console errors
- Progress.txt updated (if applicable)
Marker Output Validation:
- All operations are complete (no pending tool calls)
- Marker string is ready:
<ralph>COMPLETE</ralph> - Marker will be output as single atomic string (not streamed)
- Marker will be included in assistant response text (not shell command)
- No intermediate text will appear between marker components
- Complete marker is buffered and ready for atomic output
Orchestrator Compatibility Check:
- Marker is complete string (not partial)
- No streaming will occur (verified in validation step)
- Marker format is correct:
<ralph>COMPLETE</ralph> - Marker will be at end of response after all verification
Only after ALL items above are checked, proceed to output the marker.
Verification Pattern
## Final Verification
1. **TypeScript Compilation**: ✅ Passes
```bash
npx tsc --noEmit
# No errors
Browser Testing: ✅ Completed
- All test cases pass
- No console errors
Success Criteria: ✅ All met
- Criterion 1: ✅
- Criterion 2: ✅
- Criterion 3: ✅
Progress Tracking: ✅ Updated
- progress.txt reflects completion
COMPLETE
## Orchestrator Detection Patterns
### How Orchestrator Detects Completion
The orchestrator scans assistant responses for the completion marker pattern. It expects:
1. **Complete marker in single token**: `<ralph>COMPLETE</ralph>` as one token
2. **In assistant response text**: Not in shell output or tool responses
3. **At end of response**: After all verification and documentation
4. **Atomic output**: No streaming, no partial tokens
### Detection Failure Modes
**Why streaming causes detection failures**:
1. **Token-by-token scanning**: Orchestrator may miss partial tokens
2. **Timing issues**: Incomplete marker may be processed before completion
3. **Parsing errors**: Partial tokens may not match detection pattern
4. **State confusion**: Multiple tokens may confuse detection logic
**Example of detection failure**:
Token 1: "<" → Not recognized as marker
Token 2: "ral" → Not recognized as marker
Token 3: "ph" → Not recognized as marker
Token 4: ">COMPLETE" → Pattern incomplete, detection fails
**Example of successful detection**:
Token 1: "COMPLETE" → Pattern matched, completion detected ✅
### Validation Patterns Before Output
**Pattern 1: Pre-Output Buffer Check**
```markdown
Before outputting:
1. Buffer complete marker: "<ralph>COMPLETE</ralph>"
2. Verify buffer is complete (not partial)
3. Confirm no streaming will occur
4. Output buffered marker atomically
Pattern 2: Response Structure Validation
Response structure (correct):
1. Verification summary
2. Task completion details
3. Atomic marker: <ralph>COMPLETE</ralph>
Response structure (incorrect):
1. Verification summary
2. <ralph (partial token)
3. COMPLETE (partial token)
4. </ralph> (partial token)
Pattern 3: Tool Call Completion Check
Before outputting marker:
1. Verify no pending tool calls
2. All tool calls have completed
3. No async operations in progress
4. All verification steps finished
5. Then output marker atomically
Common Pitfalls
Pitfall 1: Character-by-Character Streaming
Problem: Streaming completion marker character-by-character
Solution: Output as single atomic string
# ❌ WRONG: Streaming
<ralph>COMPLETE</ralph>
# Each character streamed separately
# ✅ CORRECT: Atomic
<ralph>COMPLETE</ralph>
# Single string output
CRITICAL ENFORCEMENT: The completion marker <ralph>COMPLETE</ralph> MUST be output as a SINGLE, ATOMIC STRING in ONE response. Do NOT stream it character-by-character. The orchestrator expects the complete marker in a single token output.
Pitfall 2: Echo Commands
Problem: Using shell echo commands for completion marker
Solution: Include in assistant response text
# ❌ WRONG: Shell command
echo "<ralph>COMPLETE</ralph>"
# ✅ CORRECT: In response
<ralph>COMPLETE</ralph>
Pitfall 3: Delayed Completion
Problem: Delaying completion for cleanup operations
Solution: Output completion before cleanup
# ❌ WRONG: Cleanup before completion
# Cleanup operations
<ralph>COMPLETE</ralph>
# ✅ CORRECT: Completion before cleanup
<ralph>COMPLETE</ralph>
# Cleanup operations (if needed)
Troubleshooting: When Streaming Cannot Be Prevented
System-Level Workarounds
If streaming occurs despite following all guidelines:
Force Atomic Output Pattern:
## Completion Task complete. Marker: <ralph>COMPLETE</ralph>Place marker immediately after short text to reduce streaming risk.
Minimal Context Before Marker:
Complete. <ralph>COMPLETE</ralph>Minimal text before marker reduces chance of streaming.
Single-Line Pattern:
All tasks complete. <ralph>COMPLETE</ralph>Single line reduces token boundary issues.
Detection of Streaming After Output
If you suspect streaming occurred:
- Check response structure: Look for partial marker tokens
- Verify marker completeness: Ensure full
<ralph>COMPLETE</ralph>present - Check for intermediate text: No text between marker components
- Review token boundaries: Marker should be single token
Recovery Strategies
If streaming is detected:
- Output marker again in next response (if task still active)
- Use minimal context: Just the marker with minimal text
- Document issue: Note streaming occurred in progress.txt
- Verify detection: Check if orchestrator detected completion
Common Streaming Scenarios
Scenario 1: Long Response Before Marker
- Problem: Long verification text may cause streaming
- Solution: Keep verification concise, place marker immediately after
Scenario 2: Multiple Tool Calls Before Marker
- Problem: Tool call results may trigger streaming
- Solution: Complete all tool calls, then output marker in separate response
Scenario 3: Code Blocks Before Marker
- Problem: Code blocks may cause token boundary issues
- Solution: Place marker after code blocks, use minimal text
Pre-Output Validation Checklist
Before outputting completion marker, verify ALL of the following:
Task Completion:
- All operations are complete (no pending tool calls)
- All success criteria are met
- TypeScript compilation passed (if applicable)
- Browser testing completed (if applicable)
- No console errors
- Progress.txt updated (if applicable)
Marker Output Validation:
- Marker string is complete:
<ralph>COMPLETE</ralph> - Marker is buffered and ready (not partial)
- Marker will be output as single atomic string
- Marker will be included in assistant response (not shell command)
- No streaming will occur (complete string output)
- No intermediate text between marker components
Orchestrator Compatibility:
- Marker format is correct:
<ralph>COMPLETE</ralph> - Marker will be at end of response
- No tool calls will occur after marker
- Response structure is correct (verification → marker)
Only after ALL items above are checked, output the marker:
<ralph>COMPLETE</ralph>
Best Practices
- Output as atomic string: Single
<ralph>COMPLETE</ralph>string - CRITICAL REQUIREMENT - Include in response: Don't use shell commands
- Output immediately: After final verification passes
- Before cleanup: Signal completion before resource cleanup
- Verify first: All criteria met before completion marker (use checklist above)
- Don't stream: Avoid character-by-character output - PROTOCOL VIOLATION
- Don't delay: Output immediately after verification
- Validate before output: Use pre-output validation checklist
- Orchestrator compatibility: Ensure single token output for orchestrator detection
Integration with Other Skills
- task-verification-workflow: Uses completion marker after verification
- pre-implementation-check: Completes after verification
- testing-fallback-strategies: Completes after fallback verification
Related Skills
task-verification-workflow- Task completion verificationpre-implementation-check- Pre-task verificationtesting-fallback-strategies- Testing verification
Remember
- Output atomically: Single string, not streamed
- Include in response: Not via shell commands
- Output immediately: After verification passes
- Before cleanup: Signal completion first
- Verify first: All criteria met
- Prevent timeouts: Atomic output prevents streaming delays