kernel-debug-loop
This skill should be used when performing fast iterative kernel debugging, running time-bound kernel sessions to detect specific log signals or test kernel behavior. Use for rapid feedback cycles during kernel development, boot sequence analysis, or feature verification.
What this skill does
# Kernel Debug Loop
Fast iterative kernel debugging with signal detection and time-bounded execution.
## Purpose
This skill provides a rapid feedback loop for kernel development by running the Breenix kernel for short, time-bounded sessions (default 15 seconds) while monitoring logs in real-time for specific signals. The kernel terminates immediately when the expected signal is detected, or when the timeout expires, enabling fast iteration cycles during debugging.
## When to Use This Skill
Use this skill when:
- **Iterative debugging**: Testing kernel changes with quick feedback loops
- **Boot sequence analysis**: Verifying the kernel reaches specific initialization checkpoints
- **Signal detection**: Waiting for specific kernel log messages before proceeding
- **Behavior verification**: Confirming the kernel responds correctly to tests or inputs
- **Fast failure detection**: Identifying boot failures or hangs quickly without waiting for full timeout
- **Checkpoint validation**: Ensuring the kernel reaches expected states during execution
## How to Use
### Basic Usage
The skill provides the `quick_debug.py` script for time-bounded kernel runs with optional signal detection.
**Run kernel with signal detection:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "KERNEL_INITIALIZED"
```
This runs the kernel for up to 15 seconds, terminating immediately when "KERNEL_INITIALIZED" appears in the logs.
**Run kernel with custom timeout:**
```bash
kernel-debug-loop/scripts/quick_debug.py --timeout 30
```
Runs the kernel for up to 30 seconds without specific signal detection.
**Run in BIOS mode:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "Boot complete" --mode bios
```
**Quiet mode (kernel output only):**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "READY" --quiet
```
Suppresses progress messages, showing only kernel output.
### Common Signals to Watch For
Based on Breenix's test infrastructure, common signals include:
- `๐ฏ KERNEL_POST_TESTS_COMPLETE ๐ฏ` - All runtime tests completed
- `KERNEL_INITIALIZED` - Basic kernel initialization complete
- `USER_PROCESS_STARTED` - User process execution began
- `MEMORY_MANAGER_READY` - Memory management subsystem initialized
- Custom checkpoint markers added for specific debugging needs
### Workflow Patterns
#### Pattern 1: Fast Iteration During Development
When making changes to kernel initialization:
1. Make code change
2. Run: `kernel-debug-loop/scripts/quick_debug.py --signal "TARGET_CHECKPOINT" --timeout 10`
3. Verify signal appears or analyze why it didn't
4. Iterate
This provides feedback in ~10-15 seconds instead of waiting for full kernel execution or manual termination.
#### Pattern 2: Boot Sequence Verification
When debugging boot issues:
1. Identify the checkpoint expected to be reached
2. Run with that checkpoint as the signal
3. If timeout occurs, the kernel failed to reach that point
4. Examine the output buffer to see how far boot progressed
5. Add intermediate checkpoints to narrow down the failure point
#### Pattern 3: Regression Testing
When verifying fixes:
1. Run with the signal that was previously failing to appear
2. Success (signal found) confirms the fix worked
3. Failure (timeout) indicates the issue persists
4. The output buffer contains diagnostic information
#### Pattern 4: Performance Checkpoint Analysis
When optimizing boot time:
1. Run with a specific checkpoint signal
2. Note the elapsed time when signal is found
3. Make optimization changes
4. Re-run to measure improvement
5. The script reports exact elapsed time for comparison
### Integration with Claude Workflows
When assisting with kernel debugging:
1. **Suggest checkpoints**: Recommend adding strategic log markers at key points
2. **Run quick tests**: Use this script to verify changes before full test suite
3. **Analyze output**: Parse the output buffer to diagnose issues
4. **Iterate rapidly**: Chain multiple quick debug runs to test hypotheses
5. **Report findings**: Summarize what signals were found and timing information
### Script Output
The script provides:
- **Real-time kernel output**: All kernel logs stream to stdout during execution
- **Status indicators**: Visual feedback on signal detection and timeout
- **Session summary**: Success/failure status, timing, and output statistics
- **Exit code**: 0 if signal found (or no signal specified), 1 if timeout without signal
### Output Buffer Analysis
After a debug session, the entire kernel output is available for analysis:
- Search for error messages or warnings
- Verify initialization sequence order
- Check memory allocation patterns
- Analyze interrupt handling
- Examine test results
### Advanced Usage
**Multiple checkpoint verification:**
Run sequential sessions to verify a series of checkpoints:
```bash
for signal in "PHASE1" "PHASE2" "PHASE3"; do
kernel-debug-loop/scripts/quick_debug.py --signal "$signal" --quiet || break
done
```
**Capture output for analysis:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "READY" > kernel_output.log 2>&1
```
**Integration with test scripts:**
```python
import subprocess
result = subprocess.run(
['kernel-debug-loop/scripts/quick_debug.py', '--signal', 'TEST_COMPLETE'],
capture_output=True,
text=True
)
if result.returncode == 0:
print("Test passed!")
else:
print("Test failed or timed out")
analyze_output(result.stdout)
```
## Best Practices
1. **Add strategic checkpoints**: Insert log markers at key kernel execution points
2. **Use descriptive signals**: Make signal patterns unique and meaningful
3. **Set appropriate timeouts**: Balance between waiting long enough and fast iteration
4. **Check exit codes**: Use return codes in scripts for automation
5. **Save output for analysis**: Redirect output when debugging complex issues
6. **Start broad, narrow down**: If a checkpoint isn't reached, add earlier checkpoints
7. **Combine with full tests**: Use for quick iteration, then validate with full test suite
## Technical Details
- **Timeout**: Default 15 seconds, configurable via `--timeout`
- **Signal detection**: Performs substring matching on each output line
- **Termination**: Graceful SIGTERM followed by SIGKILL if needed
- **Output buffering**: Line-buffered for real-time display
- **Exit codes**: 0 for success (signal found or no signal specified), 1 for timeout/failure
## Examples
**Verify kernel reaches user mode:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "USER_PROCESS_STARTED" --timeout 20
```
**Quick sanity check after changes:**
```bash
kernel-debug-loop/scripts/quick_debug.py --timeout 5
```
**Debug memory initialization:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "MEMORY_MANAGER_READY" --quiet > mem_init.log
```
**Test both UEFI and BIOS modes:**
```bash
kernel-debug-loop/scripts/quick_debug.py --signal "BOOT_COMPLETE" --mode uefi
kernel-debug-loop/scripts/quick_debug.py --signal "BOOT_COMPLETE" --mode bios
```
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.