Run any Skill in Manus with one click

security-review

Stars25

Forks0

UpdatedApril 14, 2026 at 18:26

Perform a thorough security review of the project, starting from a randomly selected file. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check the codebase for security issues. Also trigger when the user mentions "check for vulnerabilities", "find security bugs", "OWASP", or any request related to assessing the security posture of the project.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

maragudk

maragudk/fabrik

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Information Security AnalystsComputer and Mathematical Occupations·SOC 15-1212

File Explorer

2 files

SKILL.md

readonly

name	security-review
description	Perform a thorough security review of the project, starting from a randomly selected file. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check the codebase for security issues. Also trigger when the user mentions "check for vulnerabilities", "find security bugs", "OWASP", or any request related to assessing the security posture of the project.
license	MIT

Security review

Getting started

Pick a random starting point by running the bundled script:

bash scripts/random-file.sh

The scripts/ directory is part of this skill, not the project repository.

The random entry point is intentional: it forces exploration of parts of the codebase that might otherwise be overlooked. The idea is to run this skill multiple times over the life of a project, each time pulling one thread from a different starting point.

Read the file the script returned. From there, follow one promising path -- a single thread of connections (imports, callers, callees, data flow) that looks like it could harbor a security issue. Go deep on that one path rather than trying to survey everything.

Reporting

Report exactly one finding -- the single most significant security issue you discovered along the path. Not two, not a list, just one. If nothing concerning was found, say so -- that's a valid outcome. Resist the temptation to pad the report with minor observations or informational notes.

Starting point: which file the review began from
Path followed: the chain of files you traced and why you chose that direction
Finding: severity, file and line number, description, and suggested fix

More from this repository

same repository

maragudk/fabrik

ALWAYS invoke this skill as your FIRST action — before any Read, Write, Edit, or Bash — whenever a task involves Go in any way — creating or editing any `.go` file, `go.mod`, or `go test`; adding or changing handlers, structs, methods, interfaces, error handling, goroutines, channels, sqlc/database code, or gomponents views; or refactoring, reviewing, debugging, or testing Go. This is a hard requirement, not a suggestion — the user develops all Go through this skill, which encodes project-specific conventions (structure, error handling, testing, naming) that default Go habits violate. Do not start editing Go and consult it later — load it first. Skip only when no Go code is read or written (pure Python, shell, SQL, Dockerfiles, CI config, or conceptual Go questions with no code).

2026-06-2625

writing-clearly-and-concisely

maragudk/fabrik

Use when you write or revise a long-form document an audience will read—documentation, a README, a how-to or user guide, a spec, a design or decision doc, a blog post, a proposal, an announcement, or a standalone report or summary written for a person. Such writing should be clear, concrete, and tight, so draft it from the start by Strunk's Elements of Style (active voice; definite, specific, concrete words; omit needless words) instead of first-draft sprawl. Do NOT fire for short or code-adjacent text—commit messages, PR descriptions, release notes or changelogs, error messages, UI strings, code comments, config, version bumps, quick internal scratch notes, or the implementation diary. These exclusions win even when the text reaches an audience: a release note, changelog, or PR description is a working artifact, not a document drafted for readers.

2026-06-2525

git

maragudk/fabrik

Guide for using git with specific preferences -- branch names without `feat/`/`hotfix/` prefixes, backticks around code identifiers in commit messages, asking about GitHub issues to reference before committing. Use this whenever you branch, commit, or write a commit message -- not just when explicitly asked to "commit". These conventions aren't in your default knowledge and you'll get them wrong without consulting this skill.

2026-06-2225

one-at-a-time

maragudk/fabrik

Present output one unit at a time instead of dumping a list or wall of text. Use when the user says "one at a time", "/one-at-a-time", "one thing at a time", "go one at a time", asks you to slow down, to stop the wall of text, or to stop dumping everything at once -- either to redo output you just gave, or to pace the rest of a task.

2026-06-1825

observability

maragudk/fabrik

Guide for instrumenting and operating observable software systems. Use this skill whenever the user is adding or reviewing telemetry, instrumenting code with OpenTelemetry, working with traces/spans/metrics/logs/structured events, debugging production behavior, designing SLOs or alerts, setting up sampling or telemetry pipelines, choosing observability storage, or making code observable for humans or AI agents -- even if they don't say the word "observability". Triggers include "add tracing", "instrument this", "OTel/OpenTelemetry", "why is this slow in prod", "set up an SLO", "alert fatigue", "high cardinality", "structured logging", "wide events", and observability for LLM/agent applications.

2026-06-1825

gomponents

maragudk/fabrik

Building, rendering, or editing any HTML or UI in a Go application means using gomponents — ALWAYS invoke this skill as your FIRST action, before any Read, Write, Edit, or Bash. This fires for any view, page, layout, component, form, table, navbar, footer, or list that renders to HTML; any function returning a `Node`; anything in the `html` package; and converting HTML or templates into Go. It is a hard requirement — the user writes all HTML through gomponents, a pure-Go component library whose conventions (dot imports, `Node` composition, `Map`/`If`/`Iff`, `Group`, HTML5 documents) ordinary Go and HTML habits get wrong. Load it even when the Go skill also applies. Skip only when no HTML or view code is touched (pure database, handler, or business logic; plain `.css`/`.js`/`.html` files; conceptual questions with no code).

2026-06-1825

name	security-review
description	Perform a thorough security review of the project, starting from a randomly selected file. Use this skill when the user asks for a security review, security audit, vulnerability scan, or wants to check the codebase for security issues. Also trigger when the user mentions "check for vulnerabilities", "find security bugs", "OWASP", or any request related to assessing the security posture of the project.
license	MIT

Security review

Getting started

Pick a random starting point by running the bundled script:

bash scripts/random-file.sh

The scripts/ directory is part of this skill, not the project repository.

Reporting

Starting point: which file the review began from
Path followed: the chain of files you traced and why you chose that direction
Finding: severity, file and line number, description, and suggested fix