developing-featureslisted

# Developing Features Production code. Secure by default, structured by responsibility, simple until proven otherwise. ## Read first (always) List `learnings/` and read every file relevant to the current task. Project-specific conventions, banned patterns, or security constraints live there and override the defaults in this SKILL.md. If a learning conflicts with this file, **the learning wins** — mention it to the user. ## Tradeoff — when to apply, when to lighten up Apply the full discipline when the code is **production-bound, multi-user, or persists state**. Lighten the formality (still keep security and naming) when the code is a one-off script, a throwaway exploration, or a sample under 50 lines. Don't impose SRP/DIP/file-structure ceremony on a 10-line CLI helper. ## Pre-implementation check (mandatory) Before writing any code, answer these six questions: 1. **What am I trusting here that I haven't verified?** External inputs, tokens, signatures, IDs, flags, headers — anything from outside. 2. **What is the blast radius if this goes wrong?** Can an attacker read other users' data? Forge events? Execute arbitrary operations? Exhaust resources? 3. **Am I implementing this from the authoritative source?** Official docs, official SDK, official spec — not a tutorial, not a copy-paste. 4. **What happens in the failure path?** Does a failed check silently succeed? Does an exception get swallowed? Does the error leak internals? 5. **Who controls this value, and can they