alexei-led/coding

<!-- generated by scripts/build/generate-skills.py — edits to this file will be overwritten by `make build`. Edit the canonical SKILL.md (or add a SKILL.codex.md / SKILL.pi.md sidecar to diverge). --> <!-- Pi platform guidance --> <!-- Use Pi tool names exactly: read, bash, edit, write, ask_user_question, structured_output, todo, Agent, get_subagent_result, steer_subagent, web_search, web_answer, web_research. --> <!-- Use Agent, get_subagent_result, and steer_subagent for delegated work. --> <!-- Use ctx7 or npx ctx7@latest through bash when Context7 documentation lookup is required. -->

Coding Process Discipline

Before Writing Code

State assumptions. Do not pick an interpretation silently.

• Ambiguous request → name the interpretations and ask one clarifying question.
• Simpler approach exists → say so before coding.
• Existing project glossary or ADRs exist → read them before naming concepts or changing architecture:
  • CONTEXT.md
  • CONTEXT-MAP.md
  • docs/adr/
  • nearest */CONTEXT.md or */docs/adr/

Define Success Criteria First

Transform the task into verifiable goals.

| Vague | Verifiable | | ---------------- | --------------------------------------------------- | | "Add validation" | Write invalid-input tests, then make them pass | | "Fix the bug" | Reproduce with a test or script, then make it pass | | "Refactor X" | Tests pass before and after, diff stays minimal |

For multi-step work, state a brief plan. Every step must include its own verification check; do not write unverified plan steps. In first responses to ambiguous feature work, every numbered plan item must include → verify:; a single final "run tests" step is not enough.

1. Read domain docs and ADRs → verify: list concepts/constraints found or say none exist
2. Define export behavior and privacy rules → verify: user confirms success criteria
3. Add CSV/JSON behavior tests → verify: targeted tests fail for missing behavior
4. Implement export path → verify: targeted tests pass and broader suite still passes

Test-First Mode

Use this when the user asks for TDD, test-first, or red-green-refactor.

• Test behavior through public interfaces. Do not test private helpers.
• Write one failing test for one behavior.
• Add only enough code to pass that test.
• Repeat one vertical slice at a time. Do not write all tests first.
• Refactor only when green.
• Mock only system boundaries: network, time, randomness, filesystem, external services.

Cycle:

RED: one behavior test fails
GREEN: minimal implementation passes
REFACTOR: simplify without changing behavior

During Implementation

Every changed line must trace to the request.

When done, check the diff:

• Extra feature? Remove it.
• Speculative abstraction? Delete it.
• Name conflicts with CONTEXT.md vocabulary? Rename to match the domain language.
• Decision is hard to reverse, surprising, and a real trade-off? Offer an ADR.