surajkuushwaha
- 5 skills
- 0 followers
- 1 day ago last updated
- ▌ Cx Pr Review · surajkuushwaha bundleUse when asked to review or re-review a PR, audit changes, check the diff on the current branch, verify a fix, or check what's still pending before merge in a CultureX repo. Universal TypeScript/JavaScript review framework (lenses, router, framework-agnostic traps) plus per-repo supplements loaded by fingerprint — saas-server.md (Express+Sequelize+MySQL, RBAC, agencyId tenancy), creator-services.md (Mongoose autoIndex:false, Qdrant, AI pipeline, Elastic Beanstalk), and analytics-backend.md (stateless provider gateway, no DB, no auth, allSettled fan-out, 3-way symmetric provider paths); more repos get their own supplement over time. Trap library covers bugs that actually shipped — paranoid+CASCADE, MySQL partial index, agencyId scoping, cross-store refs, sync-LLM-in-handler, side-effect gating, backfill normalization, symmetric-fix gaps, stuck background tasks.
- ▌ Cx Database Schema · surajkuushwahaUse when writing a database migration or Sequelize model in the cx-saas-server repo — covers column naming (camelCase FKs vs snake_case data), the standard trailing block, foreign keys, ENUMs, paranoid soft delete, associations, indexes, and registering the model. Keeps migration columns and model init() in 1:1 lockstep.
- ▌ Modular Architecture · surajkuushwahaScaffold backend features using a modular layered architecture (route → controller → service → repository) where each feature is a self-contained module. Use when creating a new API/backend feature, refactoring into a clean structure, or enforcing separation of concerns.
- ▌ Feature Plan · surajkuushwaha bundleWrite a stakeholder-friendly feature/project plan document covering problem, solution, components, phased implementation, scope boundaries, and open questions. Use when user wants to draft a plan, PRD-lite, project brief, or feature plan; or asks to "write a plan", "plan this feature", "create a project plan".
- ▌ Feature Spec · surajkuushwaha bundleWrite a technical spec document (architecture diagrams, request lifecycle, module breakdown, data models, implementation steps, testing plan, risks) that follows a stakeholder-facing feature plan. Use when user has a plan and wants to deepen it into a developer-ready spec, or asks to "write a spec", "create technical design", "design doc for this feature".