harsh817
- 80 skills
- 0 followers
- 10 hours ago last updated
- ▌ Reliability Failure Audit · harsh817 bundleAudit reliability and failure readiness before production. Use when testing dependency failures, retries, timeouts, duplicate requests, concurrency, partial failures, idempotency, recovery behavior, and error handling.
- ▌ Feature Scope Definition · harsh817 bundleDefine or audit the exact scope of one feature, including included behavior, excluded behavior, dependencies, and layer impact. Use before designing or implementing a feature to keep the slice small and strategic.
- ▌ Implementation Planning · harsh817 bundlePlan a small strategic implementation slice for one feature after repository inspection. Use when deciding files, order of work, tests, verification, risks, and how to keep the change understandable before coding.
- ▌ Plan To Code Comparison · harsh817 bundleCompare implemented code against the feature plan, delivery document, and project constraints. Use after implementation to find missing acceptance criteria, plan drift, stale documents, and unintended behavior.
- ▌ Performance Capacity Audit · harsh817 bundleAudit performance and capacity before production. Use when measuring latency, throughput, resource use, database queries, critical paths, expected load, and capacity risks with evidence rather than guesses.
- ▌ Design Complexity Review · harsh817 bundleReview feature code for design quality and complexity using Ousterhout-style principles. Use after implementation to find tactical patches, shallow modules, information leakage, vague names, pass-through methods, duplicated rules, avoidable special cases, and nonobvious code.
- ▌ Production Readiness Router · harsh817 bundleAutomatically invoke the Phase 4 Audit production-readiness skills one by one by exact skill name, compare evidence against the project, create or continuously update PRODUCTION_READINESS.md, and produce a final READY, READY WITH ACCEPTED RISKS, or NOT READY decision.
- ▌ Error And Edge Case Design · harsh817 bundleDesign error handling and edge cases for one feature across frontend, API, backend, database, and tests. Use when deciding which failures to prevent, define away, recover from, or expose to users.
- ▌ Feature Outcome Definition · harsh817 bundleDefine or audit the specific outcome of one feature before designing frontend, API, backend, data, and tests. Use when a feature idea is vague, too broad, disconnected from the product outcome, or needs a precise success target.
- ▌ Module And Boundary Design · harsh817 bundleDesign module ownership and boundaries for one feature. Use when deciding where feature behavior, rules, data access, API handling, and UI responsibilities belong.
- ▌ Coding Agent Instructions · harsh817 bundleWrite precise coding-agent instructions for implementing one feature. Use when converting a plan into actionable agent guidance with scope boundaries, project comparisons, tests, stop conditions, documentation updates, and expected outcomes.
- ▌ Run Behavior Verification · harsh817 bundleVerify implemented feature behavior by running relevant commands, manual checks, screenshots, smoke tests, logs, or API checks. Use after coding and before review to prove the user-visible behavior works.
- ▌ Acceptance Criteria Writing · harsh817 bundleWrite or audit acceptance criteria for one feature across success, validation, permissions, state changes, and visible results. Use when a feature needs clear done criteria before implementation or tests.
- ▌ Small Slice Implementation · harsh817 bundleImplement one feature in small vertical slices. Use when editing code to deliver behavior while preserving project patterns, owner modules, information hiding, tests, user changes, and the delivery document.
- ▌ Architecture Complexity Audit · harsh817 bundleAudit architecture and complexity before production. Use when reviewing module boundaries, deep interfaces, information hiding, information leakage, pass-through layers, repetition, vague names, nonobvious code, and Ousterhout-style red flags.
- ▌ Production Readiness Decision · harsh817 bundleMake the final production readiness decision from audit evidence. Use when combining requirements, architecture, code quality, tests, security, data, performance, reliability, deployment, observability, and adversarial findings into READY, READY WITH ACCEPTED RISKS, or NOT READY.
- ▌ Architecture Style · harsh817Define or audit the project's architecture style, module shape, dependency direction, and layer boundaries. Use when establishing a modular monolith, reviewing cross-layer imports, deciding service boundaries, or simplifying architecture that has become shallow or tangled.
- ▌ Full System Adversarial Review · harsh817 bundleRun a full-system adversarial production review. Use when actively searching for hidden assumptions, unknown dependencies, missing errors, unsafe interactions, cross-area failures, and readiness blind spots after focused audits.
- ▌ Observability Operations Audit · harsh817 bundleAudit observability and operations readiness before production. Use when checking logs, metrics, traces, dashboards, alerts, health checks, runbooks, ownership, on-call readiness, and operational evidence.
- ▌ Strategic Fixing Refactoring · harsh817 bundleFix feature defects and refactor strategically after review or verification. Use when tests, behavior checks, plan comparison, or design review reveal issues that should be corrected without expanding scope or hiding unrelated cleanup.
- ▌ Requirements Completeness Audit · harsh817 bundleAudit production requirements completeness for a release, feature set, or system. Use when confirming every must-have user journey, acceptance condition, non-goal boundary, and documented requirement works before production readiness.
- ▌ Git And Change Rules · harsh817Define or audit branch rules, commit scope, diff review, ignored files, push conditions, and change hygiene. Use before committing, opening a PR, reviewing local changes, or preventing unrelated tactical edits from accumulating.
- ▌ Code Quality Documentation Audit · harsh817 bundleAudit code quality and documentation before production. Use when checking consistency, readability, interface comments, design notes, stale comments, TODOs, debug code, naming, and nonobvious implementation choices.
- ▌ Functional Regression Test Audit · harsh817 bundleAudit functional and regression test readiness before production. Use when confirming unit, integration, system, edge-case, smoke, and regression tests pass and adequately support safe refactoring.
- ▌ Module Ownership Rules · harsh817Define or audit which module owns each business rule, data concept, policy, and design decision. Use when assigning responsibility, removing duplicated rules, fixing information leakage, or deciding where new behavior belongs.
- ▌ Project Goal And Scope · harsh817Define or audit a project's goal, users, success boundary, and explicit out-of-scope work. Use when starting a project, writing a PRD, clarifying scope, rejecting feature creep, or checking whether a proposed change increases complexity without serving the core purpose.
- ▌ Technology Stack Rules · harsh817Define or audit the approved language, framework, database, test tools, and libraries for a project. Use when creating project standards, choosing dependencies, reviewing new packages, or preventing stack drift that increases cognitive load and hidden coupling.
- ▌ Interface And API Rules · harsh817Define or audit how modules, layers, services, and external clients communicate. Use when designing APIs, reviewing public interfaces, preventing implementation leakage, or simplifying contracts between modules.
- ▌ Backend And Business Logic Design · harsh817 bundleDesign backend flow and business logic for one feature. Use when deciding commands, transactions, domain rules, permissions, side effects, jobs, and module ownership before coding backend behavior.
- ▌ AI Agent Operating Rules · harsh817Define or audit how AI agents plan, ask questions, limit scope, preserve user work, verify changes, and report deviations. Use when setting agent instructions, reviewing autonomous work, or creating guardrails for coding assistants.
- ▌ Data And Migration Rules · harsh817Define or audit schema ownership, constraints, transactions, data access boundaries, and safe migration practices. Use when adding tables, changing fields, writing migrations, or preventing persistence details from leaking through the system.
- ▌ Folder And File Structure · harsh817Define or audit where features, shared code, tests, migrations, configuration, and documentation belong. Use when creating a repository layout, adding files, reorganizing folders, or reducing navigation complexity and misplaced ownership.
- ▌ Project Guardrails Router · harsh817 bundleAutomatically invoke the twelve Project Foundation and Guardrails skills one by one, then create or update the canonical AGENT_GUARDRAILS.md project operating document that coding agents must read from project start through final delivery. Use when the user wants one router skill to cover all foundation and guardrail decisions without manually invoking each skill.
- ▌ Security And Safety Rules · harsh817Define or audit authentication, authorization, validation, secrets, sensitive data handling, and prohibited unsafe actions. Use when adding user access, handling private data, reviewing external inputs, or creating safety guardrails for agents and developers.
- ▌ Naming And Coding Conventions · harsh817Define or audit naming, formatting, comments, file patterns, and coding consistency rules. Use when creating conventions, reviewing unclear names, writing comments, choosing formats, or reducing obscurity in code.
- ▌ Product Goal Intake · harsh817Define the product, offer, audience, business goal, desired viewer action, proof, and constraints before any marketing video creative work begins.
- ▌ Editing Style Director · harsh817 bundleExtract, choose, and apply a reusable editing style language for videos, including pacing, typography, overlays, transitions, shot grammar, and style-pack routing.
- ▌ Comfyui Video Generation · harsh817Generate controlled short video clips through local ComfyUI workflows such as MiniMax H3 or LTX, then collect outputs for final editing.
- ▌ Fashion Visual Direction · harsh817Direct fashion, outfit, dress, and styling videos with clear visual logic, flattering garment explanations, and viewer-friendly callouts.
- ▌ Production Quality Gates · harsh817 bundleManage approval gates for AI video production so product goal, creative direction, style, storyboard, assets, clips, edit, and final review are explicitly accepted before moving forward.
- ▌ Reference Video Analysis · harsh817Analyze a reference or draft video frame-by-frame to extract story beats, timing, visual logic, problems, and elements to preserve.
- ▌ Video Quality Review Fix · harsh817Review rendered AI-assisted videos for production quality, identify exact failures, and decide whether to regenerate clips or fix them in edit.
- ▌ Video Storyboard Planner · harsh817Convert a reference analysis or concept into a timed storyboard for a coherent short video with shots, prompts, transitions, captions, and review checkpoints.
- ▌ Hyperframes Video Editing · harsh817Assemble AI-generated clips into polished short videos using Hyperframes, including captions, overlays, callouts, transitions, audio sync, validation, render, and proof sheets.
- ▌ Production Video Pipeline · harsh817Run a full production video workflow from reference analysis to storyboard, ComfyUI clip generation, Hyperframes editing, quality review, and final proof.
- ▌ Marketing Creative Director · harsh817Direct marketing creative production from brief or reference to final video, defining audience, concept, hook, visual proof, asset strategy, production plan, and quality bar before generation or editing.
- ▌ Feature Grouping · harsh817 bundleGroup discovered features into coherent capabilities, modules, milestones, or user journey areas. Use when organizing a feature map, reducing duplicate work, or aligning features with ownership and deep abstractions.
- ▌ Outcome Definition · harsh817 bundleDefine or audit the concrete app outcome before breaking work into features. Use when starting a product, clarifying an existing project, turning a vague idea into a buildable target, or checking whether proposed features serve the real user outcome.
- ▌ Clarify Knowns · harsh817 bundleAsk question-first prompts to capture known knowns before software work. Use for any domain when establishing the outcome, existing facts, decisions, constraints, project state, references, and user context before planning, designing, debugging, building, or auditing.
- ▌ User Identification · harsh817 bundleIdentify primary, secondary, and supporting users for an app outcome. Use when discovering whose journeys, permissions, pains, and decisions should shape the feature map or when an existing project has unclear user roles.
- ▌ Design It Twice · harsh817 bundleGenerate and compare at least two viable designs for one feature before choosing an implementation plan. Use when a feature affects multiple layers, module boundaries, interfaces, data, or error handling.
- ▌ Find Blindspots · harsh817 bundleAsk question-first prompts to uncover unknown unknowns before or during software work. Use for any domain when hidden assumptions, missing failure modes, unseen dependencies, security risks, data risks, edge cases, or expert concerns could change the plan.
- ▌ Unknowns Router · harsh817 bundleOrchestrate the Unknowns Toolkit question-first skills for any software work, including frontend, backend, debugging, database design, agent frameworks, docs, deployments, and audits. Use to create or update UNKNOWNS.md, ask focused user questions, classify unknowns, and recommend the next workflow phase without implementing the work.
- ▌ Feature Map Document · harsh817 bundleCreate, update, and maintain the canonical FEATURE_MAP.md from outcome, users, journeys, actions, rules, failures, groups, priorities, and vertical slices. Use when the feature discovery flow needs a comprehensive document that coding agents read before implementation and update whenever feature decisions change.
- ▌ User Journey Mapping · harsh817 bundleMap the steps a user takes to reach the desired app outcome. Use when turning users and outcomes into workflows, auditing existing screens, or finding missing transitions before feature breakdown.
- ▌ Test Plan Design · harsh817 bundleDesign the test plan for one feature across unit, integration, API, UI, end-to-end, migration, and regression tests. Use before implementation to align tests with acceptance criteria and module interfaces.
- ▌ Commit And Push · harsh817 bundleCommit and push one completed feature after verification and final diff review. Use when preparing a focused git commit, preserving unrelated user changes, writing a clear message, pushing to GitHub, and recording the result.
- ▌ Data Model Design · harsh817 bundleDesign or audit the data model for one feature, including entities, fields, constraints, indexes, ownership, migrations, and persistence boundaries. Use before implementing database or schema changes.
- ▌ Surface Questions · harsh817 bundleAsk question-first prompts to expose known unknowns before software work. Use for any domain when open decisions, ambiguities, missing requirements, uncertain architecture, debugging hypotheses, data choices, UX flows, or risky assumptions could change the next step.
- ▌ Failure Case Discovery · harsh817 bundleDiscover failure cases, edge cases, invalid states, and recoverable errors for planned features. Use when designing resilient workflows, reducing hidden unknowns, or deciding which errors can be defined out of existence.
- ▌ Feature Prioritization · harsh817 bundlePrioritize features by outcome value, learning value, dependency order, risk, and complexity. Use when turning a feature map into a build order or reviewing whether a backlog is tactical and too feature-first.
- ▌ Final Diff Review · harsh817 bundleReview the final local diff before delivery, commit, or push. Use when checking changed files for accidental edits, unrelated changes, secrets, generated artifacts, missing tests, stale docs, design regressions, and user-work preservation.
- ▌ Data Migration Audit · harsh817 bundleAudit data and migration readiness before production. Use when checking schema constraints, transactions, migration safety, compatibility, backups, restore tests, data-loss risks, and rollback implications.
- ▌ Make Tacit Visible · harsh817 bundleAsk question-first prompts to turn tacit preferences and unknown knowns into examples, references, criteria, prototypes, or reaction loops. Use for frontend design, architecture taste, developer experience, agent frameworks, workflows, documentation quality, and any work where the user knows what good looks like when they see it.
- ▌ Business Rule Discovery · harsh817 bundleDiscover business rules, invariants, policies, limits, and decisions hidden inside outcomes, journeys, actions, or existing code. Use when feature maps need domain rules before implementation or when rules appear duplicated across a project.
- ▌ Vertical Slice Creation · harsh817 bundleCreate small vertical slices that cut through UI, application logic, domain rules, data, and tests. Use when converting prioritized features into buildable increments or avoiding broad horizontal implementation plans.
- ▌ API Contract Design · harsh817 bundleDesign the API contract for one feature, including endpoint or procedure shape, request and response data, status/error semantics, validation, permissions, and versioning concerns.
- ▌ Feature Breakdown Router · harsh817 bundleAutomatically invoke the Phase 1 Features breakdown skills one by one by exact skill name, compare against the project when available, and create or continuously update FEATURE_MAP.md as the comprehensive outcome-to-build-plan document. Use when the user wants one router skill to cover everything needed to achieve the app outcome and keep the feature plan current as changes happen.
- ▌ Frontend Flow Design · harsh817 bundleDesign the frontend flow for one feature, including screens, states, user actions, loading, validation, errors, accessibility, and connection to API behavior.
- ▌ Feature Ship Router · harsh817 bundleAutomatically invoke the Phase 3 Ship skills one by one by exact skill name, compare the implementation against the project and feature plan, create or continuously update FEATURE_DELIVERY.md, then commit and push one working tested understandable feature when requested.
- ▌ Test Implementation · harsh817 bundleAdd or update tests for one implemented feature. Use when deciding unit, integration, system, regression, or smoke tests that prove behavior while respecting existing project test style and avoiding brittle implementation coupling.
- ▌ Feature Design Router · harsh817 bundleAutomatically invoke the Phase 2 EndToEnd feature-design skills one by one by exact skill name, compare against the project when available, and create or continuously update FEATURE_DESIGN.md as the comprehensive frontend/API/backend/database/test plan for one feature.
- ▌ Documentation Review · harsh817 bundleReview and update documentation for an implemented feature. Use when checking README files, API docs, comments, design documents, changelogs, examples, and delivery notes after code changes.
- ▌ Interface First Design · harsh817 bundleDesign the module interface for one feature before implementation. Use when defining commands, services, hooks, repositories, or public methods so callers see intent rather than implementation details.
- ▌ Repository Inspection · harsh817 bundleInspect an existing repository before implementing a feature. Use when a coding agent needs to understand project structure, current behavior, owner modules, tests, documentation, git state, and risk before planning code changes.
- ▌ Security Readiness Audit · harsh817 bundleAudit security readiness before production. Use when reviewing authentication, authorization, input validation, secrets, dependency risks, data exposure, privacy, abuse paths, and unsafe interactions for a release or system.
- ▌ Testing Rules · harsh817Define or audit required tests, test locations, behavioral seams, fixtures, and verification expectations. Use when adding features, fixing bugs, planning coverage, or preventing tests from coupling to implementation details.
- ▌ Action To Feature Breakdown · harsh817 bundleConvert actions into small buildable features with clear boundaries. Use when turning workflow actions into backlog items, reviewing feature size, or separating user-facing behavior from internal implementation tasks.
- ▌ Journey To Action Breakdown · harsh817 bundleBreak each user journey step into concrete user and system actions. Use when converting journeys into implementable behavior, comparing workflows to existing code, or exposing hidden actions before feature design.
- ▌ Deployment Rollback Audit · harsh817 bundleAudit deployment and rollback readiness before production. Use when verifying build pipeline, staging deployment, environment configuration, migrations, smoke tests, release controls, rollback plan, and deploy safety.