Profile My skills Saved Collections Edit profile Submit a skill

← all publishers

stevenfackley

@stevenfackley source repo

11 published skills

  1. ▌
    Brainstorming · stevenfackley
    Use BEFORE any creative or build work — new features, components, behavior changes. Explore intent, requirements, and design with the user before writing a line of code. Prevents a constrained model from confidently building the wrong thing.
    0
    installs
  2. ▌
    Deep Analysis · stevenfackley
    Use when orchestrating /deep-design, /deep-debug, /deep-review, /deep-read, or /council — packet assembly and artifact discipline for fresh-context worker fan-out
    0
    installs
  3. ▌
    Creative Naming · stevenfackley
    Use when naming a product, app, feature, or company. Generates distinctive, memorable names and bans generic AI naming patterns (-ly/-ify, Smart-/AI-/Get-, generic Hub/Cloud tails). Includes evaluation criteria and availability checks.
    0
    installs
  4. ▌
    Accessibility 508 · stevenfackley
    Use when building or reviewing any user-facing UI (SwiftUI or MAUI) that must meet Section 508 / WCAG 2.1 AA — a legal mandate for federal/defense software. Covers names, roles, values, Dynamic Type, contrast, focus, touch targets, and the platform-specific screen-reader traps weak models get wrong.
    0
    installs
  5. ▌
    Distinctive UI Design · stevenfackley
    Use when building ANY UI — a page, component, or app. Forces a bold, intentional aesthetic direction and bans the generic "AI slop" look (Inter + purple-gradient-on-white + centered hero + equal cards). Constrained models default hard to that mean; this makes them choose.
    0
    installs
  6. ▌
    Reviewing Others Code · stevenfackley
    Use when reviewing someone else's code or pull request (you are the reviewer). Staff-level review discipline — prioritize by severity, separate blocking from non-blocking, review design not just lines, and give kind, specific, actionable feedback that also mentors. Distinct from auto-reviewing your own generated code.
    0
    installs
  7. ▌
    Test Driven Development · stevenfackley
    Use when implementing any feature or bugfix. Write a failing test first (RED), the minimal code to pass it (GREEN), then refactor. With constrained models the test is an executable spec the model cannot drift from — and it structurally prevents verification gaming.
    0
    installs
  8. ▌
    Porting Angular To Mobile · stevenfackley
    Use when reproducing a developed Angular web app/feature as a native mobile screen (Swift/SwiftUI or MAUI). You are READING Angular to extract behavior, state, API calls, and validation — not writing Angular. Includes an Angular→mobile concept map.
    0
    installs
  9. ▌
    Consuming Shared Libraries · stevenfackley
    Use when your (greenfield) project must depend on another team's shared library or API — especially across stacks (e.g. a Swift mobile team consuming a .NET/Angular team's backend). Consume the contract not their internals, isolate their model behind an anti-corruption layer, pin versions, never fork.
    0
    installs
  10. ▌
    Dotnet Standard 2 0 Compat · stevenfackley
    Use when writing or contributing to .NET code that must target .NET Standard 2.0 — often multi-targeted with .NET 10 in shared libraries. Lists what is NOT available on the ns2.0 floor so you don't put .NET 10-only APIs in code that must compile for both.
    0
    installs
  11. ▌
    Verification Before Completion · stevenfackley
    Use before claiming ANY task or step is done. Forces real evidence — run the build/tests, show output, and confirm the plan's invariants are actually present. Constrained models declare success without checking; this is the gate that stops it.
    0
    installs