Software Engineer

--- name: Software Engineer slug: software-engineer version: 1.0.0 homepage: https://clawic.com/skills/software-engineer description: Write production-ready code with clean architecture, proper error handling, and pragmatic trade-offs between shipping fast and building right. metadata: {"clawdbot":{"emoji":"👨‍💻","requires":{"bins":[]},"os":["linux","darwin","win32"]}} ---

When to Use

Agent needs to write, review, or refactor code. Handles implementation decisions, architecture trade-offs, and code quality across any language or framework.

Quick Reference

| Topic | File | |-------|------| | Code patterns | patterns.md | | Architecture decisions | architecture.md | | Testing practices | testing.md |

Core Rules

1. Read Before Write

• Check existing code style, patterns, and conventions before writing new code
• Respect the current stack — never swap libraries without explicit request
• Match naming conventions, formatting, and project structure already in place

2. Code That Compiles

Every code block must:

• Have correct imports for the actual library versions in use
• Use APIs that exist in the project's dependency versions
• Pass basic syntax checks — no placeholder // TODO: implement

3. Minimal First

• Solve the specific problem, not hypothetical future problems
• One abstraction when you have three concrete cases, not before
• Features that might be needed → skip. Features that are needed → implement

4. Errors as First-Class Citizens

❌ catch (e) {}
❌ catch (e) { console.log(e) }
✅ catch (e) { logger.error('context', { error: e, input }); throw new DomainError(...) }

• Typed errors over generic strings
• Include context: what operation failed, with what input
• Distinguish recoverable vs fatal errors

5. Boundaries and Separation

| Layer | Contains | Never Contains | |-------|----------|----------------| | Handler/Controller | HTTP/CLI parsing, validation | Business logic, SQL | | Service/Domain | Business rules, orchestration | Infrastructure details | | Repository/Adapter | Data access, external APIs | Business decisions |

6. Explicit Trade-offs

When making architectural choices, state:

• What you chose and why
• What you traded away
• When to revisit the decision

Example: "Using SQLite for simplicity. Trade-off: no concurrent writes. Revisit if >1 write/sec needed."

7. PR-Ready Code

Before delivering any code:

• [ ] No dead code, commented blocks, or debug statements
• [ ] Functions under 30 lines
• [ ] No magic numbers — use named constants
• [ ] Early returns over nested conditionals
• [ ] Edge cases handled: null, empty, error states

Code Quality Signals

Senior code reads like prose:

• Names explain "what" and "why", not "how"
• A junior understands it in 30 seconds
• No cleverness that requires comments to explain

The best code is boring:

• Predictable patterns
• Standard library over dependencies when reasonable
• Explicit over implicit

Common Traps

| Trap | Consequence | Prevention | |------|-------------|------------| | Inventing APIs | Code doesn't compile | Verify method exists in docs first | | Over-engineering | 3 hours instead of 30 min | Ask: "Do I have 3 concrete cases?" | | Ignoring context | Suggests wrong stack | Read existing files before suggesting | | Copy-paste without understanding | Hidden bugs surface later | Explain what the code does | | Empty error handling | Silent failures in production | Always log + type + rethrow | | Premature abstraction | Complexity without benefit | YAGNI until proven otherwise |

Pragmatic Shipping

Critical paths (do it right):

• Authentication, authorization
• Payment processing
• Data integrity, migrations
• Secrets management

Experimental paths (ship fast, iterate):

• UI/UX features
• Admin panels
• Analytics
• Anything unvalidated with users

Test for critical path: "Can this wake me at 3am or lose money?"

Security & Privacy

This skill does NOT:

• Store any data externally
• Make network requests
• Access files outside the current project

All code suggestions are generated in context of the conversation.