Coding
WHEN TO USE THIS
- Writing new code: functions, components, modules, services, endpoints
- Modifying existing code to change behavior
- Refactoring local implementation details while preserving behavior
NEVER DO
- Write code before understanding what it needs to accomplish
- Skip error handling because the happy path works
- Create an abstraction for fewer than 3 concrete cases
- Optimize before profiling proves there is a bottleneck
- Leave commented-out code, debug statements, or unused imports
- Write clever/compressed code that trades clarity for brevity
- Proceed when architecture is unresolved — flag it first
IMPLEMENTATION PRIORITIES (in order)
- Readability — Can a new engineer understand this without asking? If the code requires a comment explaining WHAT it does, rename until the name makes it obvious.
- Correctness — Handle null, empty, malformed, extremely large, concurrent, and failed-dependency cases. Write happy path first, then add each failure mode.
- Maintainability — Small focused functions, explicit dependencies, no global state, pure logic separated from side effects.
- Convention compliance — Match the existing codebase's naming, layering, and patterns. Consistency beats local brilliance.
- Performance — Only after profiling proves a bottleneck. Optimize surgically behind a clean interface.
- Testability — Isolate side effects. Favor pure functions for logic. Design seams where tests can inject fakes.
CODING LENSES
Run these before and during implementation:
| Lens |
Question |
| Intent |
Is business intent obvious from names alone — without reading the body? |
| Scope |
Does this function/module have exactly one job? |
| Abstraction |
Is this layer necessary now, or am I abstracting for imagined futures? |
| Boundaries |
Are inputs validated at entry points? Are outputs intentional? |
| Error behavior |
What happens on failure, timeout, malformed input? Handled or swallowed? |
| State/side effects |
Where exactly does state change? Is the order obvious? |
| Testability |
Can important behavior be verified without heroic setup? |
| Consistency |
Does this match the surrounding codebase's patterns? |
| Simplicity |
Is there a simpler version that satisfies the same requirements? |
| Change safety |
What will break when someone edits this? Are dependencies explicit? |
EXECUTION SEQUENCE
New code
- Define the interface first — inputs, outputs, errors, side effects
- Write the most readable, obvious solution (no optimization yet)
- Use names that reflect domain/business meaning, not vague mechanical detail
- Add error handling for each failure mode before moving on
Modifying existing code
- Read surrounding code until you understand the local design intent
- Identify what behavior must stay unchanged before touching anything
- Make the smallest change that achieves the goal
- Check sibling functions — if one had the bug, the twin probably does too
When unclear
- State the ambiguity explicitly
- Ask if it materially affects implementation
- If architecture is unresolved, flag it — don't code around it
ANTI-PATTERNS
| Anti-Pattern |
What It Is |
Fix |
| Cleverness trap |
Nested ternaries, bitwise tricks, compressed chains |
Write the obvious version. Lines are free. |
| Premature abstraction |
Interface with 1 implementation, factory for 2 classes |
Wait for 3 concrete cases (Rule of Three) |
| Premature optimization |
Complex data structures for theoretical perf gains |
Write simple. Profile. Optimize the measured bottleneck only. |
| God function |
200-line function doing validation, logic, DB, API, logging |
Extract: orchestrating function reads like a table of contents |
| Shallow module |
Wrapper that adds nothing over the underlying call |
Only wrap when adding error handling, retry, logging, or domain adaptation |
| Silent failure |
Empty catch, returning null instead of throwing, ignoring 500s |
Fail fast. Log with context. Force callers to handle failure cases. |
| Copy-paste programming |
Same 15 lines across 8 files with minor variations |
Extract after 3+ concrete cases. Patch all copies immediately in the meantime. |
| Context ignorance |
Solves the local request but violates surrounding architecture |
Read the architecture before implementing. Match layer, naming, responsibility. |
MANDATORY VERIFICATION TRACE
Before declaring done, follow data from origin → through every transformation → to final consumer.
Example: "Color injected at line X → sanitizeCandleBar at line Y returns {time, open, high, low, close, color} → series.update() at line Z receives all required fields. Confirmed."
If a parallel function exists (sanitizeTickPoint ↔ sanitizeCandleBar): verify BOTH.
NON-NEGOTIABLE CHECKLIST
OUTPUT SHAPE
Simple implementation: Brief statement of what was built → Code → What to verify
Moderate implementation: Objective restatement → Approach and rationale → Code → Assumptions made → Edge cases and error handling → What to verify
Complex implementation: All of the above + Key design decisions explained + Testing recommendations + Security/performance considerations if relevant + Next steps
1---2name: coding3description: Use this skill when writing, modifying, or generating code of any kind. Activated when the user asks to build features, implement functions, create components, write endpoints, set up forms, wire things together, or produce any working implementation. Trigger phrases: "build this", "implement", "write the code for", "create a function that", "add this endpoint", "make it work", "update this code to", "wire this together". Do NOT use for: pure architectural decisions before implementation starts (use architecture skill), root-cause debugging of existing broken code (use debugging skill).4---56# Coding78## WHEN TO USE THIS910- Writing new code: functions, components, modules, services, endpoints11- Modifying existing code to change behavior12- Refactoring local implementation details while preserving behavior1314## NEVER DO1516- Write code before understanding what it needs to accomplish17- Skip error handling because the happy path works18- Create an abstraction for fewer than 3 concrete cases19- Optimize before profiling proves there is a bottleneck20- Leave commented-out code, debug statements, or unused imports21- Write clever/compressed code that trades clarity for brevity22- Proceed when architecture is unresolved — flag it first2324---2526## IMPLEMENTATION PRIORITIES (in order)27281. **Readability** — Can a new engineer understand this without asking? If the code requires a comment explaining WHAT it does, rename until the name makes it obvious.292. **Correctness** — Handle null, empty, malformed, extremely large, concurrent, and failed-dependency cases. Write happy path first, then add each failure mode.303. **Maintainability** — Small focused functions, explicit dependencies, no global state, pure logic separated from side effects.314. **Convention compliance** — Match the existing codebase's naming, layering, and patterns. Consistency beats local brilliance.325. **Performance** — Only after profiling proves a bottleneck. Optimize surgically behind a clean interface.336. **Testability** — Isolate side effects. Favor pure functions for logic. Design seams where tests can inject fakes.3435---3637## CODING LENSES3839Run these before and during implementation:4041| Lens | Question |42| --- | --- |43| Intent | Is business intent obvious from names alone — without reading the body? |44| Scope | Does this function/module have exactly one job? |45| Abstraction | Is this layer necessary now, or am I abstracting for imagined futures? |46| Boundaries | Are inputs validated at entry points? Are outputs intentional? |47| Error behavior | What happens on failure, timeout, malformed input? Handled or swallowed? |48| State/side effects | Where exactly does state change? Is the order obvious? |49| Testability | Can important behavior be verified without heroic setup? |50| Consistency | Does this match the surrounding codebase's patterns? |51| Simplicity | Is there a simpler version that satisfies the same requirements? |52| Change safety | What will break when someone edits this? Are dependencies explicit? |5354---5556## EXECUTION SEQUENCE5758### New code59601. Define the interface first — inputs, outputs, errors, side effects612. Write the most readable, obvious solution (no optimization yet)623. Use names that reflect domain/business meaning, not vague mechanical detail634. Add error handling for each failure mode before moving on6465### Modifying existing code66671. Read surrounding code until you understand the local design intent682. Identify what behavior must stay unchanged before touching anything693. Make the smallest change that achieves the goal704. Check sibling functions — if one had the bug, the twin probably does too7172### When unclear73741. State the ambiguity explicitly752. Ask if it materially affects implementation763. If architecture is unresolved, flag it — don't code around it7778---7980## ANTI-PATTERNS8182| Anti-Pattern | What It Is | Fix |83| --- | --- | --- |84| Cleverness trap | Nested ternaries, bitwise tricks, compressed chains | Write the obvious version. Lines are free. |85| Premature abstraction | Interface with 1 implementation, factory for 2 classes | Wait for 3 concrete cases (Rule of Three) |86| Premature optimization | Complex data structures for theoretical perf gains | Write simple. Profile. Optimize the measured bottleneck only. |87| God function | 200-line function doing validation, logic, DB, API, logging | Extract: orchestrating function reads like a table of contents |88| Shallow module | Wrapper that adds nothing over the underlying call | Only wrap when adding error handling, retry, logging, or domain adaptation |89| Silent failure | Empty catch, returning null instead of throwing, ignoring 500s | Fail fast. Log with context. Force callers to handle failure cases. |90| Copy-paste programming | Same 15 lines across 8 files with minor variations | Extract after 3+ concrete cases. Patch all copies immediately in the meantime. |91| Context ignorance | Solves the local request but violates surrounding architecture | Read the architecture before implementing. Match layer, naming, responsibility. |9293---9495## MANDATORY VERIFICATION TRACE9697Before declaring done, follow data from origin → through every transformation → to final consumer.9899**Example:** "Color injected at line X → sanitizeCandleBar at line Y returns `{time, open, high, low, close, color}` → series.update() at line Z receives all required fields. Confirmed."100101If a parallel function exists (`sanitizeTickPoint` ↔ `sanitizeCandleBar`): verify BOTH.102103---104105## NON-NEGOTIABLE CHECKLIST106107- [ ] All variables and functions are named for business/domain intent (not `data`, `flag`, `process`, `check`)108- [ ] Functions have one clear responsibility and ≤3 parameters (use options object if more needed)109- [ ] All foreseeable error paths are handled — no empty catch blocks without documented justification110- [ ] No external dependency failures are silently ignored111- [ ] No commented-out code, debug statements, or unused imports remain112- [ ] Code follows existing project naming, layering, and style113- [ ] Structural verification trace completed before delivery114115---116117## OUTPUT SHAPE118119**Simple implementation:** Brief statement of what was built → Code → What to verify120121**Moderate implementation:** Objective restatement → Approach and rationale → Code → Assumptions made → Edge cases and error handling → What to verify122123**Complex implementation:** All of the above + Key design decisions explained + Testing recommendations + Security/performance considerations if relevant + Next steps
Bilal140202