techfleetworks
OrganizationPortable, vendor-neutral engineering agent skills (SKILL.md) for AI coding agents: architecture, OWASP security, test strategy, release safety, SRE, compliance. MIT.
Categories
Indexed Skills (12)
architectural-decision-records
The single source of truth for capturing architectural decisions. Use for EVERY feature, service, endpoint, schema change, framework/library choice, integration, infrastructure change, or refactor an agent builds or modifies — no such change is "done" until an Architectural Decision Record (ADR) is written and committed alongside the code. Produces MADR-format records by default (Nygard lightweight for trivial decisions), auto-detecting or establishing the repo's ADR directory and sequential numbering. Trigger PROACTIVELY whenever the user asks to build, add, implement, design, choose, adopt, migrate, refactor, or change anything architectural — a new service, "which database should we use," "let's switch to gRPC," "add caching," "split this into microservices," a new API contract, an auth model — even when they never say the words "ADR," "decision record," "documentation," or "why." If a change would make a future engineer ask "why was it built this way?", it needs an ADR, and this skill governs how.
comprehensive-test-strategy
Use for EVERY feature, service, or system to decide and implement the FULL testing strategy beyond behavioral BDD — the test pyramid (unit, integration, end-to-end), consumer-driven contract testing between services, load/performance/stress testing, chaos/resilience testing, coverage and mutation-testing quality gates, property-based testing, and flaky-test management. Complements bdd-comprehensive-testing (which owns Gherkin behavioral scenarios) by covering the other ~70% of a real test strategy. Trigger proactively on "tests," "testing," "coverage," "load test," "performance test," "contract test," "integration test," "e2e," "chaos," "flaky," "test strategy," or any code that other code or services depend on — even without those words.
enterprise-architecture-standards
Use for EVERY non-trivial piece of code, service, database schema, or integration the agent builds — new services, new endpoints, schema changes, refactors, and anything described as "production," "enterprise," "scalable," or "for a large team." Applies technical/system architecture, database architecture, sound algorithmic and coding principles, microservices and integration patterns, resilience/reliability patterns, and performance/scalability practices at the standard expected from senior engineering teams at large companies. Trigger proactively whenever the user asks to design, architect, build, scale, or refactor a system, service, database, or API, or asks how "properly built" or "enterprise-grade" software should look — even without those exact words, e.g. "add a new service," "design the schema for X," "how should these services talk to each other," "this needs to handle more load."
owasp-secure-coding-bdd
Use for EVERY feature touching user input, auth, sessions, data storage, files, APIs, external requests, permissions, dependencies, or infra config — most features. Run a threat-modeling pass against the FULL OWASP Cheat Sheet Series (bundled locally in reference files, no web lookup needed), apply matching secure-coding measures, write results as @security Gherkin scenarios, and ALWAYS run the lockout/accidental-deletion safety check before any permission, access, credential, or deletion change. Trigger on login, passwords, sessions, tokens, forms, uploads, DB queries, outbound HTTP, deserialization, admin/role checks, permissions, firewall/IAM rules, keys, dependencies, or AI/LLM/agent/RAG/MCP code — even without the words "security" or "OWASP." All 120 OWASP cheat sheets are bundled locally in references/owasp-full-index.md.
release-deployment-safety
Use whenever code will be deployed, released, rolled out, or migrated — new services, new versions, schema/data migrations, config or feature changes, or any change to how software reaches production. Enforces how elite engineering teams ship at scale WITHOUT outages: zero-downtime deploys, progressive delivery (canary/blue-green/rolling), feature flags, instant rollback, and backward-compatible database migrations (expand/contract). Trigger proactively on "deploy," "release," "ship," "roll out," "migration," "cutover," "hotfix," "rollback," "feature flag," "blue-green," "canary," or any change that alters what runs in production — even without those words. Pairs with bdd-comprehensive-testing (tests gate the release) and enterprise-architecture-standards (system shape).
sre-operational-readiness
Use whenever building, launching, or operating a service that runs in production — new services, endpoints, or any system that must stay up and be debuggable. Applies Google-style Site Reliability Engineering: define SLIs/SLOs and error budgets, instrument the four golden signals, write symptom-based alerts that don't page on noise, and prepare incident response, blameless postmortems, runbooks, and a production-readiness review BEFORE launch. Trigger proactively on "SLO," "SLA," "uptime," "reliability," "monitoring," "alerting," "on-call," "incident," "postmortem," "runbook," "observability," "metrics," "dashboards," "goes down," "how do we know if it breaks," or any production launch — even without those words. Pairs with enterprise-architecture-standards (observability), release-deployment-safety (canary signals), and bdd-comprehensive-testing.
universal-accessibility-wcag
Use for ANY UI change — every component, page, form, image, color choice, interaction, or content block — to make it conform to WCAG 2.2 Level AA (and AAA where feasible) so it is usable by people with visual, motor, auditory, cognitive, and speech disabilities, using a keyboard, screen reader, magnifier, or voice. Covers semantic HTML first, ARIA done correctly, keyboard and focus management, color/contrast, accessible forms and error handling, media alternatives, and automated + manual accessibility testing wired into CI. Trigger proactively on forms, inputs, labels, images, alt text, icons, buttons, modals/dialogs, menus, tabs, color, contrast, focus, keyboard, tab order, ARIA, roles, screen reader, "a11y," accessible, WCAG, Section 508, ADA — even without those words, on any code that renders UI.
universal-browser-device-support
Use for ANY frontend/UI change — HTML, CSS, JavaScript, components, layouts — to make it work correctly and bug-free across every supported browser and device, not just the one it was written on. Covers defining a support matrix, feature detection and progressive enhancement (never user-agent sniffing), responsive layout, input modalities (touch/mouse/keyboard/stylus), cross-browser CSS/JS quirks and fallbacks, low-end-device performance, and automated cross-browser/device testing wired into CI. Trigger proactively on "works on my machine," "broken in Safari/Firefox/Edge," CSS layout, responsive, mobile, tablet, touch, viewport, breakpoint, polyfill, vendor prefix, "looks different in," or any code that renders in a browser — even without those words.
usability-ux-universal-design
Use for ANY user-facing feature, flow, screen, form, navigation, empty/loading/error state, or piece of UI copy to make it user-friendly, intuitive, and approachable for the widest possible range of people — universal and inclusive design for anyone, across any ability, context, language level, and situation. Covers the universal-design principles, established usability heuristics, reducing cognitive load, plain-language content, error prevention and forgiving recovery, and lightweight usability testing/research. Trigger proactively on new UI or flows, redesigns, navigation/IA, onboarding, wizards, forms, empty/loading/error/success states, microcopy/labels/tooltips, confirmations, "is this intuitive/confusing," "hard to use," UX, usability, user-friendly — even without those words, whenever a human will interact with what you're building.
arch-encode
Turn an architectural mistake into a durable, enforceable rule. Use right after catching drift, a repeated bad pattern, or a review finding you want to stop recurring — or whenever someone says "add a rule so this never happens again." Writes the rule as a specific negative code example in the correct file (the nearest scoped AGENTS.md, or the repo's decisions.md), wires it into the mechanical gate when it is mechanically checkable, then proves the rule holds by reverting the bad change, clearing context, and re-running the original task. Also prunes bloated or contradictory rule files.
judge-arch
Architectural critic and the review half of a blocking architecture gate. Use before calling any non-trivial code or schema change done, before opening a pull request, or when asked to review a diff, branch, or area of an application for architectural drift. Reviews the change in a fresh context against the repository's decisions.md and the four questions — boundary placement, data ownership, dependency direction, error handling — plus a grep-test for leaked web or UI concerns in domain code. Reports each violation with where it lives, what breaks if ignored, and the smallest fix. Findings only — it never edits code, and it returns PASS and stops when nothing is wrong rather than inventing problems.
verifiable-quality-gates
When you write, review, or rely on an automated check — a CI guard, custom lint rule, schema/config validator, or architecture fitness function: make it provably detect what it claims. Every check gets a committed test that FAILS when the check is neutralized (proven mechanically by a mutation gate), fails closed, and proves each invariant at the layer that owns it. Triggers on: adding/changing a CI check or guard, a check that 'passes' but might not be catching anything, a green build you don't fully trust, making quality gates self-proving.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.