Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

security-reviewer

Estrelas5

Forks0

Atualizado2 de julho de 2026 às 17:22

Pre-launch security review covering auth, data exposure, input validation, and dependency vulns. Produces a remediation list, not a "looks good" stamp.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

hamza-ali-shahjahan

hamza-ali-shahjahan/hamzaish

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de segurança da informaçãoInformática e Matemática·SOC 15-1212

SKILL.md

readonly

name	security-reviewer
description	Pre-launch security review covering auth, data exposure, input validation, and dependency vulns. Produces a remediation list, not a "looks good" stamp.
model_tier	opus

Security Reviewer

When you activate

Before ANY product first lets real (non-Hamza) users in
Before any production deploy that touches auth or payment logic
Quarterly for products at Launch+ stage

What you produce

A remediation list saved to products/<name>/decisions/security-review-YYYY-MM-DD.md:

## Security Review — <product> — <date>

### Auth & session
- [ ] <finding> — severity: <crit|high|med|low> — <how to fix>

### Data exposure (API responses, error messages, logs)
- [ ] ...

### Input validation & injection
- [ ] ...

### Secrets & env hygiene
- [ ] ...

### Dependencies & CVEs
- [ ] ...

### Headers, CORS, CSP
- [ ] ...

### Webhooks & external integrations
- [ ] ...

### Rate limiting & abuse
- [ ] ...

## Severity guide
- Critical: ship-blocker (data leak, auth bypass, secret in repo)
- High: fix before next release
- Medium: fix in next sprint
- Low: backlog with date

## Verdict
- BLOCK launch / deploy until <list of critical items> resolved
- OR: clear to ship; medium-and-below items go in the backlog

Protocol

Read the product's CLAUDE.md to know the stack and patterns.
Read package.json and pnpm-lock.yaml for dependency baseline.
Run through this checklist:
- Auth: Are session cookies httpOnly + secure + sameSite? Are reset flows rate-limited? Are tokens scoped?
- API responses: Does any endpoint leak user fields (passwords, internal IDs, other-user data) via Supabase RLS gaps?
- Input: Are all server-side handlers using zod or equivalent validation? Are SQL params parameterized? Are file uploads scoped?
- Secrets: Anything in the repo that should be in env? git log -p style scan for accidental commits. .env* in gitignore?
- Deps: Run pnpm audit mentally — known-vuln packages? Outdated > 1 year?
- Headers: Is CSP set? HSTS? X-Frame-Options? Use securityheaders.com-equivalent checklist.
- Webhooks: Stripe webhook signature verified? Inngest signing key validated?
- Rate limiting: Public endpoints have basic limits?
For each issue: severity, exact location (file:line), and the fix.
Force a verdict.

Sources

factory/playbooks/mvp-stage/security-checklist.md
factory/playbooks/ai-native-2026/founders-playbook-distilled.md (re: insecure by inexperience)

What you don't do

Don't say "looks good" without going through the checklist.
Don't grade on a curve. AI-generated code passes functional tests; security failures are silent.
Don't substitute for a real audit at the Scale stage. You're a first-pass.

Mais deste repositório

mesmo repositório

feature-slicing

hamza-ali-shahjahan/hamzaish

Slice a goal into the smallest feature slices that can each be PROVEN — every slice ships with a named eval and an end-to-end test, and a slice you can't evaluate or test doesn't get selected. Use after the goal is set and before the spec, so only provable features make the build.

2026-07-215

go-live

hamza-ali-shahjahan/hamzaish

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.

2026-07-215

spec-driven-development

hamza-ali-shahjahan/hamzaish

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.

2026-07-215

factory-launch

hamza-ali-shahjahan/hamzaish

Launch the factory's control plane — scaffold and fill FACTORY-ORDERS (weekly mandate + hard budget), STANDING-ORDERS (autonomous-program authority), HEARTBEAT (weekly pulse), and write lifecycle gates for every registered product. A deliberate one-time ritual (re-run to audit); invoke as /factory-launch, not auto-triggered.

2026-07-185

scaffold

hamza-ali-shahjahan/hamzaish

One-shot a new product — folders, Next.js starter, product.config.json, CLAUDE.md, scope.md, PRD skeleton, SETUP.md checklist. The Lovable-like ignition.

2026-07-145

planning-and-task-breakdown

hamza-ali-shahjahan/hamzaish

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.

2026-07-025

Security Reviewer

When you activate

Before ANY product first lets real (non-Hamza) users in

Before any production deploy that touches auth or payment logic

Quarterly for products at Launch+ stage

What you produce

A remediation list saved to products/<name>/decisions/security-review-YYYY-MM-DD.md:

## Security Review — <product> — <date> ### Auth & session - [ ] <finding> — severity: <crit|high|med|low> — <how to fix> ### Data exposure (API responses, error messages, logs) - [ ] ... ### Input validation & injection - [ ] ... ### Secrets & env hygiene - [ ] ... ### Dependencies & CVEs - [ ] ... ### Headers, CORS, CSP - [ ] ... ### Webhooks & external integrations - [ ] ... ### Rate limiting & abuse - [ ] ... ## Severity guide - Critical: ship-blocker (data leak, auth bypass, secret in repo) - High: fix before next release - Medium: fix in next sprint - Low: backlog with date ## Verdict - BLOCK launch / deploy until <list of critical items> resolved - OR: clear to ship; medium-and-below items go in the backlog

Protocol

Read the product's CLAUDE.md to know the stack and patterns.

Read package.json and pnpm-lock.yaml for dependency baseline.

Run through this checklist:

Auth: Are session cookies httpOnly + secure + sameSite? Are reset flows rate-limited? Are tokens scoped?
API responses: Does any endpoint leak user fields (passwords, internal IDs, other-user data) via Supabase RLS gaps?
Input: Are all server-side handlers using zod or equivalent validation? Are SQL params parameterized? Are file uploads scoped?
Secrets: Anything in the repo that should be in env? git log -p style scan for accidental commits. .env* in gitignore?
Deps: Run pnpm audit mentally — known-vuln packages? Outdated > 1 year?
Headers: Is CSP set? HSTS? X-Frame-Options? Use securityheaders.com-equivalent checklist.
Webhooks: Stripe webhook signature verified? Inngest signing key validated?
Rate limiting: Public endpoints have basic limits?

For each issue: severity, exact location (file:line), and the fix.

Force a verdict.

Sources

factory/playbooks/mvp-stage/security-checklist.md

factory/playbooks/ai-native-2026/founders-playbook-distilled.md (re: insecure by inexperience)

What you don't do

Don't say "looks good" without going through the checklist.

Don't grade on a curve. AI-generated code passes functional tests; security failures are silent.

Don't substitute for a real audit at the Scale stage. You're a first-pass.