Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

tinybrain-code-review

Étoiles3

Forks1

Mis à jour12 juin 2026 à 21:20

Run a security-focused code review while recording findings in TinyBrain so they form a navigable, deduplicated, standards-mapped knowledge base instead of a one-off report. Use this skill when the TinyBrain MCP tools are available AND you are reviewing code for security issues, doing a secure code audit, triaging a vulnerability in a codebase, or the user asks you to "review this for security", "audit this code", "find vulnerabilities in", or map findings to CWE/CVE/OWASP. Builds on the using-tinybrain skill.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

rainmana

rainmana/tinybrain

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en sécurité de l'informationProfessions informatiques et mathématiques·SOC 15-1212

SKILL.md

readonly

name

tinybrain-code-review

description

Security code review with TinyBrain

This is defensive, authorized review work: finding weaknesses in code so they can be fixed. TinyBrain turns a review from a throwaway pass into durable, structured knowledge — every finding categorized, linked to its evidence and its fix, mapped to CWE/CVE, and reusable in the next review of the same codebase.

Read the using-tinybrain skill first for the core capture/connect/retrieve loop. This skill layers a review-specific workflow on top.

Workflow

Orient and open a session. Check list_sessions for prior reviews of this codebase; if one exists, get_context_summary to recall known issues before re-reading anything. Otherwise create_session with task_type: "security_review", naming it for the codebase or PR under review.
Record findings as you read. Each issue is a create_memory with:
- category: "vulnerability" for a confirmed weakness, hypothesis for something that looks suspicious but you haven't confirmed, finding for a noteworthy observation.
- title naming the issue and location: "SQLi in UserRepo.findByName — string-concat query".
- content with the vulnerable code, the data flow (source → sink), and why it's exploitable.
- priority from impact × exploitability; confidence from how sure you are it's real.
- tags: the file, the component, and the CWE id (e.g. CWE-89) — this is what lets you map to CVEs later and correlate across the review.
- source: the file path and line range.
Capture evidence separately and link it. Store the proof — the exact sink, a PoC request, a failing test — as a category: "evidence" memory, then create_relationship with supports from the evidence to the vulnerability. Evidence that travels with the finding is what makes a report credible and a fix verifiable.
Record the fix as a recommendation and link it. When you propose remediation, store it as category: "recommendation" and link it mitigates → the vulnerability. Now the finding, its proof, and its fix are one traversable cluster.
Map to standards. For confirmed weaknesses, use map_to_cve with the CWE id to pull related CVEs, and map_to_compliance with the relevant standard (e.g. OWASP, PCI-DSS) to show coverage and gaps. Store notable results as reference memories linked to the finding.
Correlate before reporting. Run analyze_risk_correlation on the session to surface chains where individually-medium issues combine into something worse (e.g. an IDOR plus a verbose error becomes account enumeration). check_high_priority_memories gives you the lede for the writeup.

Before you re-read code, search

If you're about to re-examine a function or revisit a pattern, search_memories (by file, CWE, or component tag) first — you may have already reviewed it. check_duplicates before storing a finding in a large review so the same issue across call sites doesn't get logged five times; if it's genuinely the same root cause at multiple sites, store once and note the sites in content, or link the instances with related_to.

Producing the report

When asked for the writeup, retrieve rather than recall: get_context_summary for the overview, check_high_priority_memories for the criticals, and walk each finding's relationships (get_related_entries) to assemble finding → evidence → recommendation as a unit. The memory graph is the report's structure.

Calibration reminders specific to review

A reachable, exploitable sink with attacker-controlled input is high priority (8–10). An issue gated behind auth or requiring an unlikely precondition is lower — say so in content.
Don't inflate confidence on findings you haven't traced end-to-end. A hypothesis at 0.4 ("this looks like it might be injectable, haven't confirmed the source is tainted") is an honest, useful record — and a reminder to go confirm it.

Plus depuis ce dépôt

même dépôt

tinybrain-ctf

rainmana/tinybrain

Work a CTF challenge or other authorized security-learning exercise while tracking reconnaissance, hypotheses, payloads, and the path to the flag in TinyBrain — so you never lose a working payload, repeat a dead end, or forget what you already enumerated. Use this skill when the TinyBrain MCP tools are available AND you are solving a CTF, working a practice/retired box (HTB, picoCTF, a crackme, a deliberately-vulnerable app like Juice Shop or DVWA), or the user says "let's do this CTF", "solve this challenge", "capture the flag", or "work this box". Builds on the using-tinybrain skill.

2026-06-123

tinybrain-threat-intel

rainmana/tinybrain

Collect, structure, and correlate threat intelligence in TinyBrain — indicators, threat actors, campaigns, and TTPs — mapped to MITRE ATT&CK so the picture builds across sources and sessions instead of living in scattered notes. Use this skill when the TinyBrain MCP tools are available AND you are doing intelligence analysis, threat modeling, OSINT collection, IOC tracking, actor/campaign profiling, or the user mentions threat intel, MITRE ATT&CK mapping, IOCs, "track this threat actor", or "model the threats against". Builds on the using-tinybrain skill.

2026-06-123

using-tinybrain

rainmana/tinybrain

Use TinyBrain (the security-focused memory MCP server) to capture findings, build a knowledge graph of an engagement, and recall it across sessions. Invoke this skill whenever the TinyBrain MCP tools are available AND you are doing multi-step security work — code review, vulnerability analysis, CTFs, threat modeling, intelligence analysis, malware/binary analysis, or any task where findings accumulate and you'll want them later. Also use it whenever the user mentions TinyBrain, "store this finding", "remember this for the assessment", "what did we find", or asks you to track an investigation. Reach for it proactively — the whole point of TinyBrain is that you record as you go rather than scrambling to reconstruct context at the end.

2026-06-123

name

tinybrain-code-review

description

Security code review with TinyBrain

Read the using-tinybrain skill first for the core capture/connect/retrieve loop. This skill layers a review-specific workflow on top.

Workflow

Orient and open a session. Check list_sessions for prior reviews of this codebase; if one exists, get_context_summary to recall known issues before re-reading anything. Otherwise create_session with task_type: "security_review", naming it for the codebase or PR under review.
Record findings as you read. Each issue is a create_memory with:
- category: "vulnerability" for a confirmed weakness, hypothesis for something that looks suspicious but you haven't confirmed, finding for a noteworthy observation.
- title naming the issue and location: "SQLi in UserRepo.findByName — string-concat query".
- content with the vulnerable code, the data flow (source → sink), and why it's exploitable.
- priority from impact × exploitability; confidence from how sure you are it's real.
- tags: the file, the component, and the CWE id (e.g. CWE-89) — this is what lets you map to CVEs later and correlate across the review.
- source: the file path and line range.
Capture evidence separately and link it. Store the proof — the exact sink, a PoC request, a failing test — as a category: "evidence" memory, then create_relationship with supports from the evidence to the vulnerability. Evidence that travels with the finding is what makes a report credible and a fix verifiable.
Record the fix as a recommendation and link it. When you propose remediation, store it as category: "recommendation" and link it mitigates → the vulnerability. Now the finding, its proof, and its fix are one traversable cluster.
Map to standards. For confirmed weaknesses, use map_to_cve with the CWE id to pull related CVEs, and map_to_compliance with the relevant standard (e.g. OWASP, PCI-DSS) to show coverage and gaps. Store notable results as reference memories linked to the finding.
Correlate before reporting. Run analyze_risk_correlation on the session to surface chains where individually-medium issues combine into something worse (e.g. an IDOR plus a verbose error becomes account enumeration). check_high_priority_memories gives you the lede for the writeup.

Before you re-read code, search

Producing the report

Calibration reminders specific to review

A reachable, exploitable sink with attacker-controlled input is high priority (8–10). An issue gated behind auth or requiring an unlikely precondition is lower — say so in content.
Don't inflate confidence on findings you haven't traced end-to-end. A hypothesis at 0.4 ("this looks like it might be injectable, haven't confirmed the source is tainted") is an honest, useful record — and a reminder to go confirm it.