Guided, stateful provisioning of a product's production stack — deep-links, key-format validation, a secrets backend (fnox recommended, or user-touched .env.local), a resumable ledger, CLI automation after signup, and a blocking A1–A10 live gate. Hands off to /security-check → /ship. The walked version of SETUP.md.
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
Compress a month of market research into 3 hours, evidence first. Use before positioning, pricing, GTM, or betting on a new idea — harvests competitor sites, incumbent filings, reviews, and complaint threads into a local corpus, then interrogates it with every claim cited to a source file or flagged as speculation.
Clear a product/brand name BEFORE buying a domain or branding anything. Runs same-industry collision, trademark signal, domain availability, and distinctiveness checks. Returns RED/YELLOW/GREEN verdicts with evidence. Use whenever a new product is being named, a domain is about to be bought, or a user proposes a name.
End-to-end product naming pipeline — brief → competitor scan → theme-by-theme generation → clearance → selection → TLD/budget → lock. Embeds the operator's default iterative shortlist-by-theme selection method. Use to name a new product or rename an existing one. Composes competitor-research and name-clearance.
Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.
Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
Assess an external GitHub repo for Hamzaish — verify health, clone read-only, run a facts-only deep-dive, and land a references-grammar draft in the scout backlog for operator review. Use when the operator drops a repo URL to evaluate, asks "can we leverage X repo," or on a trending sweep (--trending). Drafts only …
Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.
Ship the SEO + AEO foundation (Google/Bing/Yandex + ChatGPT/Claude/Perplexity) into a Hamzaish product. Adds llms.txt, AI-bot-friendly robots.txt, FAQPage/SoftwareApplication JSON-LD, sitemap, and the meta head block.
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.
Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea.
Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
The cleanup stage. When a build hits a milestone (pre-launch, end of a sprint, "let's tidy this up"), scan a repo — or 100+ repos at once — for rot, see the extent at a glance, then clean it with confirmation. Report-first, never silently edits. Works on any git repo, Hamzaish-built or not.
Find and fix prose in a repo that only makes sense from inside the session that wrote it — dead references to a conversation, change narration ("used to", "no longer"), reviewer-addressed asides, and pointers to work that never landed. Use before a PR, before publishing docs, and when a repo has been written largely…
Turn a rough ambition into a measurable, REACHABLE goal — a capability statement, a precisely-named metric, ≥2 numeric evals, an acceptance rule, and non-goals — with a feasibility check that catches impossible or game-able targets before you chase them. Pair with /goal (which pursues a goal autonomously).
MCP server "payments" as configured in hamza-ali-shahjahan/hamzaish. Runs locally from the @example/payments-mcp npm package. Needs 1 environment variable to run.
MCP server "docs", hosted remotely at mcp.example-docs.dev, as configured in hamza-ali-shahjahan/hamzaish.
★not rated 8 todayA
tokens not measured
AGPL-3.0
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: