Menu
ALWAYS use this skill when writing or refactoring code. Includes context-dependent sub-skills to empower different coding styles across languages and runtimes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when analyzing a large corpus of text, code, or data that exceeds a single agent's effective context - orchestrates parallel Worker subagents, Critic review subagents, and a final Summarizer subagent with task tracking and failure recovery
Use to decide what kind of basic agent you should use
Use when creating a new opencode plugin or setting up plugin structure - provides complete file organization, manifest format, and component definitions for commands, agents, skills, hooks, and MCP servers
Use when creating specialized subagents for opencode or the task tool - covers description writing for auto-delegation, tool selection, prompt structure, and testing agents
Use when creating, releasing, or maintaining an opencode Plugin Marketplace - covers marketplace.json schema, version management, release checklists, changelog conventions, and validation to prevent sync drift between plugin.json and marketplace.json
Use when completing development phases or branches to identify and update AGENTS.md files that may have become stale - analyzes what changed, determines affected contracts and documentation, and coordinates updates
| name | coding-effectively |
| description | ALWAYS use this skill when writing or refactoring code. Includes context-dependent sub-skills to empower different coding styles across languages and runtimes. |
ALWAYS REQUIRED:
howto-functional-vs-imperative - Separate pure logic from side effectsdefense-in-depth - Validate at every layer data passes throughCONDITIONAL: Use these sub-skills when applicable:
howto-code-in-typescript - TypeScript codehowto-code-in-rust - Rust codehowto-develop-with-postgres - PostgreSQL database codeprogramming-in-react - React frontend codewriting-good-tests - Writing or reviewing testsproperty-based-testing - Tests for serialization, validation, normalization, pure functionsWhen designing features, think about properties upfront. This surfaces design gaps early.
Discovery questions:
| Question | Property Type | Example |
|---|---|---|
| Does it have an inverse operation? | Roundtrip | decode(encode(x)) == x |
| Is applying it twice the same as once? | Idempotence | f(f(x)) == f(x) |
| What quantities are preserved? | Invariants | Length, sum, count unchanged |
| Is order of arguments irrelevant? | Commutativity | f(a, b) == f(b, a) |
| Can operations be regrouped? | Associativity | f(f(a,b), c) == f(a, f(b,c)) |
| Is there a neutral element? | Identity | f(x, 0) == x |
| Is there a reference implementation? | Oracle | new(x) == old(x) |
| Can output be easily verified? | Easy to verify | is_sorted(sort(x)) |
Common design questions these reveal:
Surface these during design, not during debugging.
Model the full error space. No shortcuts.
Don't:
any or equivalent to bypass type checkingTwo-tier model:
Error message format: Lowercase sentence fragments for "failed to {message}".
Good: failed to connect to database: connection refused
Bad: Failed to Connect to Database: Connection Refused
Good: invalid configuration: missing required field 'apiKey'
Bad: Invalid Configuration: Missing Required Field 'apiKey'
Lowercase fragments compose naturally: "operation failed: " + error.message reads correctly.
The rule of three applies to abstraction: Don't abstract until you've seen the pattern three times. Three similar lines of code is better than a premature abstraction.
Name files by what they contain, not by generic categories.
Don't create:
utils.ts - Becomes a dumping ground for unrelated functionshelpers.ts - Same problemcommon.ts - What isn't common?misc.ts - Actively unhelpfulDo create:
string-formatting.ts - String manipulation utilitiesdate-arithmetic.ts - Date calculationsapi-error-handling.ts - API error utilitiesuser-validation.ts - User input validationWhy this matters:
string-formatting.tsimport { formatDate } from './date-arithmetic' is self-documentingWhen you're tempted to create utils.ts: Stop. Ask what the functions have in common. Name the file after that commonality.
unix.ts, windows.ts, posix.tsDon't emulate Unix on Windows or vice versa. Use each platform's native patterns.
Bad: Trying to make Windows paths behave like Unix paths everywhere.
Good: Accept platform differences, handle them explicitly.
// Platform-specific behavior
if (process.platform === 'win32') {
// Windows-native approach
} else {
// POSIX approach
}
When platform differences are significant, use separate files:
process-spawn.ts // Shared interface and logic
process-spawn-unix.ts // Unix-specific implementation
process-spawn-windows.ts // Windows-specific implementation
When behavior differs by platform, document it in comments:
// On Windows, this returns CRLF line endings.
// On Unix, this returns LF line endings.
// Callers should normalize if consistent output is needed.
function readTextFile(path: string): string { ... }
Don't assume Unix behavior works on Windows. Test explicitly:
| Mistake | Reality | Fix |
|---|---|---|
| "Just put it in utils for now" | utils.ts becomes 2000 lines of unrelated code | Name files by purpose from the start |
| "Edge cases are rare" | Edge cases cause production incidents | Handle them. Model the full error space. |
| "We might need this abstraction later" | Premature abstraction is harder to remove than add | Wait for the third use case |
| "It works on my Mac" | It may not work on Windows or Linux | Test on target platforms |
| "The type system is too strict" | Strictness catches bugs at compile time | Fix the type error, don't bypass it |
Stop and refactor when you see:
utils.ts or helpers.ts file growing beyond 200 linesas any) to bypass the type systemApplies to all languages. Commits are the unit of review and bisect; treat them with the same care as the code they contain.