feat: add new skills for build-and-compile, code review, data formats, environment discovery, git workflow, performant code, refactor, skill creator, systematic debugging, test writer, and verification strategy

backend/Dockerfile

@@ -37,6 +37,7 @@ COPY --from=builder /app/.venv ./.venv
 # Copy application code
 COPY backend/ ./backend/
 COPY pyproject.toml .
+COPY skills/ ./skills/
 
 # Ensure the .venv/bin is in PATH
 ENV PATH="/app/.venv/bin:$PATH"

frontend/nginx.conf

@@ -16,8 +16,8 @@ server {
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_connect_timeout 30s;
-        proxy_read_timeout 200s;
-        proxy_send_timeout 200s;
+        proxy_read_timeout 400s;
+        proxy_send_timeout 400s;
     }
 
     # ── Static files ──────────────────────────────────────────────

skills/build-and-compile/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: build-and-compile
+description: "Building, compiling, and resolving dependency issues across languages"
+tags: [build, compile, dependencies, benchmark]
+version: "1.0.0"
+---
+
+# Build & Compile
+
+Strategies for building code and resolving dependency issues.
+
+## Build System Detection
+
+Check for build files in order:
+- `Makefile` → `make` (read it first to understand targets)
+- `CMakeLists.txt` → `cmake -B build && cmake --build build`
+- `pyproject.toml` / `setup.py` → `pip install -e .`
+- `package.json` → `npm install && npm run build`
+- `Cargo.toml` → `cargo build --release`
+- `go.mod` → `go build ./...`
+- No build system → compile directly (`gcc`, `g++`, `rustc`, etc.)
+
+## Compilation Strategies
+
+### C/C++
+- Always read the Makefile/CMakeLists first
+- Common flags: `-O2 -Wall -lm -lpthread`
+- Missing headers → `apt-get install lib<name>-dev`
+- Linking errors → check library order (dependencies last: `-lfoo -lbar -lm`)
+
+### Python
+- Use virtual environments when possible
+- `pip install -e .` for editable installs
+- Missing modules → check `requirements.txt`, `pyproject.toml`
+- Version conflicts → read the actual error, pin versions
+
+### Multi-language projects
+- Build dependencies first (C libraries before Python bindings)
+- Check for Cython, SWIG, or FFI bridges
+- Environment variables often needed: `LD_LIBRARY_PATH`, `PYTHONPATH`
+
+## Dependency Resolution
+
+1. Read the FULL error message — the missing dependency is usually named
+2. Search for the package: `apt-cache search <name>`, `pip search <name>`
+3. Install the minimum needed — don't install everything
+4. If a package is unavailable, check for alternatives or build from source
+
+## Common Build Failures
+
+| Error | Likely Cause | Fix |
+|-------|-------------|-----|
+| `fatal error: foo.h: No such file` | Missing dev headers | `apt-get install libfoo-dev` |
+| `undefined reference to` | Missing library at link time | Add `-lfoo` flag |
+| `No module named 'foo'` | Missing Python package | `pip install foo` |
+| `command not found: make` | Build tools missing | `apt-get install build-essential` |
+| `version 'GLIBC_X.Y' not found` | Binary built for newer system | Rebuild from source |

skills/code-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: code-review
+description: "Systematic code review for bugs, security, style, and performance"
+tags: [code-quality, review]
+version: "1.0.0"
+---
+
+# Code Review
+
+Perform a systematic code review covering these categories:
+
+## Review Checklist
+
+### 1. Correctness
+- Logic errors, off-by-one, null/None handling
+- Edge cases: empty inputs, large inputs, concurrent access
+- Error handling: are exceptions caught and handled properly?
+
+### 2. Security
+- Input validation and sanitization
+- SQL injection, XSS, command injection
+- Secrets in code, hardcoded credentials
+- Authentication and authorization checks
+
+### 3. Performance
+- Unnecessary loops, N+1 queries
+- Missing indexes for database queries
+- Large memory allocations, unbounded collections
+- Blocking calls in async code
+
+### 4. Style & Maintainability
+- Naming clarity (variables, functions, classes)
+- Function length — split if >30 lines
+- Dead code, commented-out code
+- Missing type annotations
+
+### 5. Testing
+- Are new code paths covered by tests?
+- Are edge cases tested?
+- Are error paths tested?
+
+## Output Format
+
+For each issue found:
+- **File:line** — category — description — suggested fix
+- Severity: critical / warning / suggestion

skills/data-formats/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: data-formats
+description: "Working with diverse data formats: binary, text, structured, and custom"
+tags: [data, parsing, formats, benchmark]
+version: "1.0.0"
+---
+
+# Data Formats
+
+How to work with diverse and unknown data formats.
+
+## Format Detection
+
+Always inspect before parsing:
+
+```bash
+file <filename>                    # MIME type detection
+xxd <filename> | head -5           # hex dump (first bytes)
+head -3 <filename>                 # text preview
+python3 -c "
+with open('<filename>', 'rb') as f:
+    h = f.read(16)
+    print(h, h.hex())
+"
+```
+
+## Common Formats
+
+### Binary
+- **Magic bytes**: Most binary formats start with a signature (ELF: `\x7fELF`, PNG: `\x89PNG`)
+- **Endianness**: Check if little-endian or big-endian (`struct.unpack('<I', ...)` vs `'>I'`)
+- **Alignment**: Fields are often aligned to 4 or 8 bytes
+- **Offsets**: Binary headers often contain offsets to other sections
+
+### Structured text
+- **CSV/TSV**: Check delimiter (comma, tab, pipe), quoting, header row
+- **JSON**: `python3 -c "import json; json.load(open('f'))"`
+- **YAML**: Check indentation, anchors/aliases
+- **TOML**: `python3 -c "import tomllib; ..."`
+- **XML**: Check encoding declaration, namespaces
+
+### Checkpoints / Model files
+- **PyTorch**: `.pt`, `.pth` → `torch.load(f, map_location='cpu')`
+- **TensorFlow**: `.ckpt` → index + data files, use `tf.train.load_checkpoint()`
+- **NumPy**: `.npy`, `.npz` → `numpy.load()`
+- **HuggingFace**: `config.json` + `model.safetensors`
+- **ONNX**: `onnx.load()`
+
+### Database files
+- **SQLite**: `file` says "SQLite 3.x database" → `sqlite3 <file> ".tables"`
+- **WAL files**: SQLite write-ahead log — recover with `sqlite3` PRAGMA
+- **CSV dumps**: Often need schema inference
+
+## Parsing Strategies
+
+### Unknown binary format
+1. Hex dump first 256 bytes: `xxd file | head -16`
+2. Look for magic bytes, version numbers, string tables
+3. Check file size — does it suggest a pattern? (e.g., N * record_size)
+4. Look for documentation of the format online
+5. Write a minimal parser, test on known values
+
+### Large structured files
+1. Never load entirely — sample first: `head`, `tail`, `shuf -n 10`
+2. Check consistency: are all lines the same format?
+3. Count fields: `head -1 file | awk -F',' '{print NF}'`
+4. Watch for: mixed types, missing values, encoding issues
+
+### Multi-file datasets
+1. List all files and sizes
+2. Look for manifest/index files (often JSON or CSV)
+3. Check naming patterns — timestamps, sequence numbers, shards
+4. Process one file first, then generalize
+
+## Common Pitfalls
+
+- Assuming UTF-8 when the file is Latin-1 or binary
+- Assuming CSV when it's TSV (or vice versa)
+- Ignoring the header row
+- Not handling quoted fields with embedded delimiters
+- Reading binary files as text (corrupts data)
+- Endianness mismatch (x86 is little-endian, network byte order is big-endian)

skills/environment-discovery/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: environment-discovery
+description: "Systematic exploration of unknown environments before starting work"
+tags: [exploration, setup, benchmark]
+version: "1.0.0"
+---
+
+# Environment Discovery
+
+When dropped into an unfamiliar environment, ALWAYS explore before acting.
+
+## Step 1: Understand the workspace
+
+```
+ls -la /app/          # or the working directory
+find . -type f | head -50
+```
+
+- What files exist? What are their sizes?
+- Are there READMEs, Makefiles, config files?
+- What languages/frameworks are involved?
+
+## Step 2: Inspect data files
+
+Before writing any code that reads data, understand the format:
+
+- `file <filename>` — detect file type (binary, text, encoding)
+- `head -20 <file>` — first lines of text files
+- `xxd <file> | head -20` — hex dump for binary files
+- `wc -l <file>` — line count for text files
+- `stat <file>` — exact file size in bytes
+- `python3 -c "import struct; ..."` — parse binary headers
+
+## Step 3: Check available tools
+
+```
+which python3 gcc g++ make cmake node npm cargo rustc java go
+pip list 2>/dev/null | head -20
+```
+
+- What compilers/interpreters are installed?
+- What libraries are available?
+- What package managers can you use?
+
+## Step 4: Read existing code
+
+If there are existing source files:
+- Read them FULLY before modifying
+- Understand the build system (Makefile, CMakeLists.txt, pyproject.toml)
+- Check for existing tests
+
+## Key Principles
+
+- NEVER assume file formats — always inspect first
+- NEVER assume tools are installed — always check
+- A 500MB file is NOT a "small file" — plan for it
+- Binary files need byte-level inspection, not `cat`
+- Spend 30 seconds exploring to save 5 minutes debugging

skills/git-workflow/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: git-workflow
+description: "Git operations: commits, branches, PRs, and conflict resolution"
+tags: [git, workflow]
+version: "1.0.0"
+---
+
+# Git Workflow
+
+## Commit Messages
+
+Format: `<type>: <description>`
+
+Types: feat, fix, refactor, test, docs, style, chore
+
+- Description starts with lowercase verb
+- Max 72 characters for first line
+- Add body for complex changes
+
+## Branch Workflow
+
+1. Create feature branch from main: `git checkout -b feat/description`
+2. Make changes in small, focused commits
+3. Push and create PR
+4. After review, squash-merge to main
+
+## Conflict Resolution
+
+1. `git fetch origin`
+2. `git rebase origin/main` (or merge if team prefers)
+3. For each conflict:
+   - Read both versions carefully
+   - Understand the intent of each change
+   - Resolve preserving both intents
+   - Test after resolving
+4. `git rebase --continue`
+
+## Safety Rules
+
+- Never force-push to main/master
+- Never commit secrets, credentials, or .env files
+- Always check `git diff` before committing
+- Use `git stash` before switching branches with uncommitted changes

skills/performant-code/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: performant-code
+description: "Writing efficient code that handles large data and tight constraints"
+tags: [performance, optimization, benchmark]
+version: "1.0.0"
+---
+
+# Performant Code
+
+How to write code that won't timeout on large inputs.
+
+## Think About Scale First
+
+Before writing code, ask: how big is the data?
+
+| Data size | Approach |
+|-----------|----------|
+| < 1 MB | Load into memory, any approach works |
+| 1-100 MB | Load into memory, but use efficient algorithms |
+| 100 MB - 1 GB | Stream/mmap, avoid loading entirely into memory |
+| > 1 GB | Streaming only, chunk-based processing |
+
+## I/O Optimization
+
+### Large files
+- **mmap** (C: `mmap()`, Python: `mmap.mmap()`) — map file into memory, OS handles paging
+- **Buffered binary reads** — `fread()` in C, `open(f, 'rb').read(chunk)` in Python
+- **NEVER** read a 500MB file line-by-line with `fgets()` when you need random access
+
+### Writing output
+- Buffer writes — don't call `write()` for every byte
+- Use `fwrite()` or `sys.stdout.buffer.write()` for binary output
+- Flush only when needed
+
+## Algorithm Complexity
+
+- **O(n)** beats **O(n log n)** beats **O(n²)** — always
+- Nested loops on large data = timeout. Restructure to single pass + hash map
+- Sorting is O(n log n) — only sort if you need to
+- Use hash maps/sets for lookup instead of linear search
+- Pre-compute what you can outside loops
+
+## Language-Specific Tips
+
+### C
+- Use `mmap()` for large file access
+- `-O2` or `-O3` for compiler optimizations
+- Avoid `malloc()`/`free()` in tight loops — pre-allocate
+- Use `memcpy()` instead of byte-by-byte copying
+- Integer arithmetic > floating point when possible
+
+### Python
+- Use `numpy` for numerical work (100x faster than pure Python loops)
+- `collections.Counter`, `defaultdict` — avoid manual counting
+- List comprehensions > explicit loops
+- `struct.unpack()` for binary parsing
+- `subprocess.run()` > `os.system()`
+- For heavy computation: consider writing a small C program instead
+
+### General
+- Profile before optimizing — find the actual bottleneck
+- If a program hangs, it's likely: infinite loop, deadlock, or I/O bound on huge data
+- If a program is slow, check: algorithm complexity, I/O pattern, memory allocation
+
+## Constraints Awareness
+
+- If the task says "< 5000 bytes" — count your bytes, use `wc -c`
+- If there's a time limit — test with actual data, not toy inputs
+- If there's a memory limit — don't load everything into RAM
+- Always verify constraints BEFORE declaring done

skills/refactor/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: refactor
+description: "Refactor code to improve structure and maintainability"
+tags: [code-quality, refactoring]
+version: "1.0.0"
+---
+
+# Refactor
+
+Improve code structure without changing external behavior.
+
+## Process
+
+1. **Understand** — Read all related code, run existing tests
+2. **Plan** — Identify what to change and why
+3. **Execute** — Make changes incrementally
+4. **Verify** — Run tests after each change
+
+## Common Refactoring Patterns
+
+### Extract
+- Long function → smaller focused functions
+- Repeated code → shared helper
+- Magic numbers → named constants
+
+### Simplify
+- Deep nesting → early returns / guard clauses
+- Complex conditionals → descriptive functions
+- Large classes → smaller focused classes
+
+### Rename
+- Unclear names → descriptive names
+- Inconsistent naming → consistent conventions
+
+### Reorganize
+- Related functions scattered → grouped in modules
+- Circular dependencies → dependency inversion
+
+## Rules
+
+- Never change behavior — tests must pass before and after
+- One refactoring type per commit
+- If tests don't exist, write them first
+- Don't refactor and add features in the same change

skills/skill-creator/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: skill-creator
+description: "Create new reusable skills from conversation context"
+tags: [meta, productivity]
+version: "1.0.0"
+---
+
+# Skill Creator
+
+Create a new skill by generating a SKILL.md file with YAML frontmatter.
+
+## Steps
+
+1. Identify the task pattern the user wants to capture as a skill
+2. Write clear, specific instructions that an AI agent can follow
+3. Create a directory with this structure:
+
+```
+my-skill/
+├── SKILL.md          # Instructions + frontmatter
+├── template.md       # (optional) Template files
+└── example.py        # (optional) Example scripts
+```
+
+4. The SKILL.md must have this format:
+
+```markdown
+---
+name: skill-name
+description: "Brief description of what this skill does"
+tags: [category1, category2]
+version: "1.0.0"
+---
+
+# Skill Name
+
+## Purpose
+What this skill accomplishes.
+
+## Instructions
+Step-by-step instructions for the agent.
+
+## Examples
+Concrete examples of input/output.
+```
+
+## Guidelines
+
+- **Name**: lowercase with hyphens (e.g., `api-client-generator`)
+- **Description**: one sentence, starts with a verb
+- **Instructions**: specific enough that another agent can execute without context
+- Include edge cases and error handling guidance
+- Add examples showing expected input and output
+- Place resources (templates, schemas) as separate files next to SKILL.md

skills/systematic-debugging/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: systematic-debugging
+description: "Systematic approach to diagnosing and fixing errors"
+tags: [debugging, errors, benchmark]
+version: "1.0.0"
+---
+
+# Systematic Debugging
+
+A structured approach to finding and fixing bugs.
+
+## The Debugging Loop
+
+```
+1. REPRODUCE → 2. ISOLATE → 3. DIAGNOSE → 4. FIX → 5. VERIFY
+```
+
+Never skip steps. Never guess-and-check repeatedly.
+
+## Step 1: Reproduce
+
+- Run the exact command that fails
+- Capture FULL output (stdout AND stderr)
+- Note: exit code, error message, stack trace
+- If intermittent, identify what changes between runs
+
+## Step 2: Isolate
+
+- What's the MINIMAL input that triggers the error?
+- Which specific line/function fails? (read the traceback bottom-up)
+- Is it a compile error, runtime error, or wrong output?
+- Does it fail on all inputs or specific ones?
+
+## Step 3: Diagnose
+
+### Read the error message carefully
+
+| Error type | Where to look |
+|-----------|---------------|
+| Compile error | The FIRST error (later ones are often cascading) |
+| Segfault | Last function in the stack trace, check array bounds and null pointers |
+| Python traceback | The innermost frame (bottom), but also check the middle for context |
+| Wrong output | Diff expected vs actual: `diff <(expected) <(actual)` |
+| Timeout/hang | Is it an infinite loop? Deadlock? I/O bound? Add a timer or counter |
+
+### Add minimal instrumentation
+
+- C: `fprintf(stderr, "reached checkpoint %d\n", __LINE__);`
+- Python: `print(f"DEBUG: {var=}", file=sys.stderr)`
+- Check intermediate values, not just final output
+- Remove debug prints after fixing
+
+## Step 4: Fix
+
+- Change ONE thing at a time
+- If the same approach fails 3 times → completely different strategy
+- Don't add workarounds — fix the root cause
+- Common root causes:
+  - Off-by-one errors (loop bounds, array indexing)
+  - Type mismatches (int vs float, signed vs unsigned)
+  - Encoding issues (UTF-8 vs bytes)
+  - Path errors (relative vs absolute, missing trailing slash)
+  - Race conditions (file not written yet, process not started)
+
+## Step 5: Verify
+
+- Run the same command that failed before
+- Test with multiple inputs, not just the one that was failing
+- Check edge cases: empty input, single element, very large input
+- Run any existing test suite
+
+## Common Failure Patterns
+
+### "It compiles but gives wrong output"
+1. Print all intermediate values
+2. Compare with a known-correct reference implementation
+3. Check: integer overflow, floating point precision, endianness
+
+### "It works on small input but times out on large"
+1. Check algorithm complexity — O(n²) on 1M items = timeout
+2. Profile: which loop/function takes the most time?
+3. Restructure: hash maps, sorting, streaming
+
+### "It works locally but fails in the test"
+1. Check: absolute vs relative paths
+2. Check: different working directory
+3. Check: different input format than expected
+4. Read the test script to understand what it actually checks

skills/test-writer/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: test-writer
+description: "Generate comprehensive test suites for existing code"
+tags: [testing, code-quality]
+version: "1.0.0"
+---
+
+# Test Writer
+
+Generate comprehensive tests for the target code.
+
+## Process
+
+1. Read the source code to understand all public functions/methods
+2. Identify the testing framework already used in the project (pytest, unittest, etc.)
+3. Follow existing test patterns and conventions in the project
+4. Write tests covering all categories below
+
+## Coverage Strategy
+
+### Happy Path
+- Normal inputs with expected outputs
+- All public methods/functions
+
+### Edge Cases
+- Empty inputs (empty string, empty list, None)
+- Boundary values (0, -1, max int)
+- Single element collections
+
+### Error Cases
+- Invalid input types
+- Missing required arguments
+- Network/IO failures (mock external calls)
+
+### Integration
+- Multiple functions working together
+- State changes across calls
+
+## Guidelines
+
+- One test function per behavior, not per method
+- Descriptive test names: `test_<what>_<condition>_<expected>`
+- Use fixtures for shared setup
+- Mock external dependencies (APIs, databases, filesystem)
+- Assert specific values, not just truthiness
+- Test both return values and side effects

skills/verification-strategy/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: verification-strategy
+description: "Thorough verification of completed work before declaring done"
+tags: [testing, verification, benchmark]
+version: "1.0.0"
+---
+
+# Verification Strategy
+
+How to verify your work is correct before declaring a task complete.
+
+## The Verification Checklist
+
+After implementing a solution, go through ALL of these:
+
+### 1. Re-read the original task
+- Re-read the EXACT wording of the task instruction
+- Check every requirement — file paths, names, formats, constraints
+- Are there implicit requirements? ("compile with gcc -O3 -lm" means exact flags)
+
+### 2. Check file outputs
+- Do all required files exist at the exact paths specified?
+- Are file sizes within any stated limits?
+- Is the file format correct? (binary vs text, encoding, line endings)
+
+```bash
+ls -la /path/to/expected/output
+wc -c /path/to/output    # byte count
+file /path/to/output      # format detection
+head -5 /path/to/output   # content preview
+```
+
+### 3. Compile and run
+- Compile with the EXACT flags specified in the task
+- Run with the EXACT command and arguments specified
+- Check exit code: `echo $?` (should be 0 for success)
+- Check both stdout AND stderr
+
+### 4. Validate output
+- Compare output against expected format
+- Check exact field names, delimiters, number formatting
+- If the task specifies output format, match it exactly:
+  - JSON: valid JSON? correct schema?
+  - CSV: correct headers? correct delimiter?
+  - Plain text: correct line endings? trailing newline?
+
+### 5. Test edge cases
+- Empty input (if applicable)
+- The specific test inputs mentioned in the task
+- Large inputs (if the task involves performance)
+
+### 6. Check constraints
+- Size limits (file size, code length)
+- Time limits (does it finish in reasonable time?)
+- Memory limits (does it stay within bounds?)
+- No external dependencies that aren't available
+
+## Reading Test Scripts
+
+If you can find the test script, READ IT:
+- What exact assertions does it make?
+- What inputs does it use?
+- What output format does it expect?
+- What timeouts are set?
+
+Tests often check things you didn't expect:
+- Exact string matching (whitespace matters!)
+- Specific numeric precision
+- File permissions
+- Process exit codes
+
+## Common Verification Failures
+
+| What you think is right | What the test actually checks |
+|------------------------|-------------------------------|
+| Output on stdout | Output in a specific file |
+| Human-readable numbers | Exact decimal precision |
+| Relative file paths | Absolute file paths |
+| "Close enough" answer | Exact match |
+| Code that runs | Code under a specific size limit |
+
+## Final Check
+
+Before declaring done, ask yourself:
+1. Did I create/modify ALL the files the task asks for?
+2. Did I use the EXACT paths, names, and formats specified?
+3. Does my code compile/run WITHOUT errors?
+4. Does my output match what automated tests would expect?
+5. Have I cleaned up any debug output or temporary files?