Harden code against vulnerabilities. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

MITAuto-check: notesSecurity

Install Security Hardening

skills CLI
$ npx skills add BlackBeltTechnology/pi-agent-dashboard --skill security-hardening -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install BlackBeltTechnology/pi-agent-dashboard security-hardening --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/BlackBeltTechnology/pi-agent-dashboard.git skills-src && mkdir -p .claude/skills && cp -r skills-src/packages/eng-disciplines/.pi/skills/security-hardening .claude/skills/security-hardening && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
security-hardening
GitHub stars
315
Token cost
~4.7k tokens
SKILL.md length
1,376 words
Files
2
Skills in repo
70
Repo updated
First seen
Licence
MIT

At a glance

Harden code against vulnerabilities. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

  • Works in 3 steps: Map the trust boundaries. Where does… → Name the assets. What's worth stealing… → Run STRIDE over each boundary — a quick…
  • Like security audit
  • SKILL.md covers Overview, When to Use, Process: Threat Model First and The Three-Tier Boundary System, plus 11 more sections
  • Calls npm and git; needs API_KEY and STRIPE_API_KEY

What it does

Security Hardening is an agent skill from BlackBeltTechnology/pi-agent-dashboard. Harden code against vulnerabilities. Use on triggers like "security audit", "harden this", "threat model", "is this safe", or when touching untrusted input, auth, sessions, secrets, data storage, or third-party integrations. Fills a security gap not covered by existing project skills. Not a generic review or ship workflow.

Its SKILL.md is about 4.7k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `SKILL.agent.md`).

It sits in Security, covering Security review, Threat modeling and Web application vulnerabilities. The repository describes itself as: Real-time web dashboard for pi coding-agent sessions. Multi-session view, live chat mirroring, integrated terminal, diff viewer, pi-flows execution, and mobile-first remote… The licence is MIT.

When your agent uses it

  • Like security audit
  • Touching untrusted input
  • Third-party integrations

Example prompts

  • “security audit”
  • “harden this”
  • “threat model”
  • “/security-hardening”

Requirements

  • Node.js
  • A credential in SESSION_SECRET
  • A credential in API_KEY

Workflow steps

3 steps, taken from the first numbered list in SKILL.md.

  1. Map the trust boundaries. Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks…
  2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
  3. Run STRIDE over each boundary — a quick lens, not a ceremony

What it can do on your machine

Read from SKILL.md and the folder at commit 7a2d171. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npm
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • genai.owasp.org

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • API_KEY
    • STRIPE_API_KEY
    • SESSION_SECRET

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Security Hardening loads about 4.7k tokens when it runs. Until then it costs about 86 tokens; SKILL.md has 1,376 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~86
When it runs · the whole SKILL.md, loaded when a task matches
~4.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NoteMentions a .env fileSKILL.md:331
    .env files:
  • NoteMentions a .env fileSKILL.md:333
    ├── .env          → NOT committed (contains real secrets)
  • NoteMentions a .env fileSKILL.md:334
    └── .env.local    → NOT committed (local overrides)
  • NoteMentions a .env fileSKILL.md:337
    .env
  • NoteMentions a .env fileSKILL.md:338
    .env.local
  • NoteMentions a .env fileSKILL.md:339
    .env.*.local

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from BlackBeltTechnology/pi-agent-dashboard at commit 7a2d171, republished under its MIT licence (© BlackBeltTechnology). 1,376 words, ~4,699 tokens.

Download SKILL.mdSave it as .claude/skills/security-hardening/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
security-hardening
description
Harden code against vulnerabilities. Use on triggers like "security audit", "harden this", "threat model", "is this safe", or when touching untrusted input, auth, sessions, secrets, data storage, or third-party integrations. Fills a security gap not covered by existing project skills. Not a generic review or ship workflow.

Security and Hardening

Overview

Security-first development practices for web applications. Treat every external input as hostile, every secret as sacred, and every authorization check as mandatory. Security isn't a phase — it's a constraint on every line of code that touches user data, authentication, or external systems.

When to Use

  • Building anything that accepts user input
  • Implementing authentication or authorization
  • Storing or transmitting sensitive data
  • Integrating with external APIs or services
  • Adding file uploads, webhooks, or callbacks
  • Handling payment or PII data

Process: Threat Model First

Controls bolted on without a threat model are guesses. Before hardening, spend five minutes thinking like an attacker:

  1. Map the trust boundaries. Where does untrusted data cross into your system? HTTP requests, form fields, file uploads, webhooks, third-party APIs, message queues, and LLM output. Every boundary is attack surface.
  2. Name the assets. What's worth stealing or breaking? Credentials, PII, payment data, admin actions, money movement.
  3. Run STRIDE over each boundary — a quick lens, not a ceremony:
ThreatAskTypical mitigation
SpoofingCan someone impersonate a user/service?Authentication, signature verification
TamperingCan data be altered in transit or at rest?Integrity checks, parameterized queries, HTTPS
RepudiationCan an action be denied later?Audit logging of security events
Information disclosureCan data leak?Encryption, field allowlists, generic errors
Denial of serviceCan it be overwhelmed?Rate limiting, input size caps, timeouts
Elevation of privilegeCan a user gain rights they shouldn't?Authorization checks, least privilege
  1. Write abuse cases next to use cases. For each feature, ask "how would I misuse this?" — then make that your first test.

If you can't name the trust boundaries for a feature, you're not ready to secure it. This is OWASP A04: Insecure Design — most breaches begin in design, not code.

The Three-Tier Boundary System

Always Do (No Exceptions)
  • Validate all external input at the system boundary (API routes, form handlers)
  • Parameterize all database queries — never concatenate user input into SQL
  • Encode output to prevent XSS (use framework auto-escaping, don't bypass it)
  • Use HTTPS for all external communication
  • Hash passwords with bcrypt/scrypt/argon2 (never store plaintext)
  • Set security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
  • Use httpOnly, secure, sameSite cookies for sessions
  • Run npm audit (or equivalent) before every release
Ask First (Requires Human Approval)
  • Adding new authentication flows or changing auth logic
  • Storing new categories of sensitive data (PII, payment info)
  • Adding new external service integrations
  • Changing CORS configuration
  • Adding file upload handlers
  • Modifying rate limiting or throttling
  • Granting elevated permissions or roles
Never Do
  • Never commit secrets to version control (API keys, passwords, tokens)
  • Never log sensitive data (passwords, tokens, full credit card numbers)
  • Never trust client-side validation as a security boundary
  • Never disable security headers for convenience
  • Never use eval() or innerHTML with user-provided data
  • Never store sessions in client-accessible storage (localStorage for auth tokens)
  • Never expose stack traces or internal error details to users

OWASP Top 10 Prevention Patterns

These are prevention patterns, not a ranking. For the 2021 ordering, see the quick-reference table in references/security-checklist.md.

Injection (SQL, NoSQL, OS Command)
typescript
// BAD: SQL injection via string concatenation
const query = `SELECT * FROM users WHERE id = '${userId}'`;

// GOOD: Parameterized query
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

// GOOD: ORM with parameterized input
const user = await prisma.user.findUnique({ where: { id: userId } });
Broken Authentication
typescript
// Password hashing
import { hash, compare } from 'bcrypt';

const SALT_ROUNDS = 12;
const hashedPassword = await hash(plaintext, SALT_ROUNDS);
const isValid = await compare(plaintext, hashedPassword);

// Session management
app.use(session({
  secret: process.env.SESSION_SECRET,  // From environment, not code
  resave: false,
  saveUninitialized: false,
  cookie: {
    httpOnly: true,     // Not accessible via JavaScript
    secure: true,       // HTTPS only
    sameSite: 'lax',    // CSRF protection
    maxAge: 24 * 60 * 60 * 1000,  // 24 hours
  },
}));
Cross-Site Scripting (XSS)
typescript
// BAD: Rendering user input as HTML
element.innerHTML = userInput;

// GOOD: Use framework auto-escaping (React does this by default)
return <div>{userInput}</div>;

// If you MUST render HTML, sanitize first
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userInput);
Broken Access Control
typescript
// Always check authorization, not just authentication
app.patch('/api/tasks/:id', authenticate, async (req, res) => {
  const task = await taskService.findById(req.params.id);

  // Check that the authenticated user owns this resource
  if (task.ownerId !== req.user.id) {
    return res.status(403).json({
      error: { code: 'FORBIDDEN', message: 'Not authorized to modify this task' }
    });
  }

  // Proceed with update
  const updated = await taskService.update(req.params.id, req.body);
  return res.json(updated);
});
Security Misconfiguration
typescript
// Security headers (use helmet for Express)
import helmet from 'helmet';
app.use(helmet());

// Content Security Policy
app.use(helmet.contentSecurityPolicy({
  directives: {
    defaultSrc: ["'self'"],
    scriptSrc: ["'self'"],
    styleSrc: ["'self'", "'unsafe-inline'"],  // Tighten if possible
    imgSrc: ["'self'", 'data:', 'https:'],
    connectSrc: ["'self'"],
  },
}));

// CORS — restrict to known origins
app.use(cors({
  origin: process.env.ALLOWED_ORIGINS?.split(',') || 'http://localhost:3000',
  credentials: true,
}));
Sensitive Data Exposure
typescript
// Never return sensitive fields in API responses
function sanitizeUser(user: UserRecord): PublicUser {
  const { passwordHash, resetToken, ...publicFields } = user;
  return publicFields;
}

// Use environment variables for secrets
const API_KEY = process.env.STRIPE_API_KEY;
if (!API_KEY) throw new Error('STRIPE_API_KEY not configured');
Server-Side Request Forgery (SSRF)

Any time the server fetches a URL the user influenced — webhooks, "import from URL", image proxies, link previews — an attacker can aim it at internal services (cloud metadata, localhost, private IPs).

typescript
// BAD: fetch whatever the user gives you
await fetch(req.body.webhookUrl);

// GOOD: allowlist scheme + host, reject if ANY resolved IP is private, forbid redirects
import { lookup } from 'node:dns/promises';
import ipaddr from 'ipaddr.js';

const ALLOWED_HOSTS = new Set(['hooks.example.com']);

async function assertSafeUrl(raw: string): Promise<URL> {
  const url = new URL(raw);
  if (url.protocol !== 'https:') throw new Error('https only');
  if (!ALLOWED_HOSTS.has(url.hostname)) throw new Error('host not allowed');
  // Resolve ALL records; a single private/reserved address fails the check.
  const addrs = await lookup(url.hostname, { all: true });
  if (addrs.some((a) => ipaddr.parse(a.address).range() !== 'unicast')) {
    throw new Error('private/reserved IP');
  }
  return url;
}

await fetch(await assertSafeUrl(req.body.webhookUrl), { redirect: 'error' });

The range() !== 'unicast' check covers loopback, link-local 169.254.169.254 (cloud metadata, the #1 SSRF target), private, and unique-local ranges across IPv4 and IPv6.

Caveat — this still has a TOCTOU gap. fetch resolves DNS again after the check, so an attacker using a short-TTL record can rebind to an internal IP between validation and connection. For high-risk surfaces, resolve once and connect to the pinned IP, or put a filtering agent in front (request-filtering-agent / ssrf-req-filter).

Input Validation Patterns

Schema Validation at Boundaries
typescript
import { z } from 'zod';

const CreateTaskSchema = z.object({
  title: z.string().min(1).max(200).trim(),
  description: z.string().max(2000).optional(),
  priority: z.enum(['low', 'medium', 'high']).default('medium'),
  dueDate: z.string().datetime().optional(),
});

// Validate at the route handler
app.post('/api/tasks', async (req, res) => {
  const result = CreateTaskSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Invalid input',
        details: result.error.flatten(),
      },
    });
  }
  // result.data is now typed and validated
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});
File Upload Safety
typescript
// Restrict file types and sizes
const ALLOWED_TYPES = ['image/jpeg', 'image/png', 'image/webp'];
const MAX_SIZE = 5 * 1024 * 1024; // 5MB

function validateUpload(file: UploadedFile) {
  if (!ALLOWED_TYPES.includes(file.mimetype)) {
    throw new ValidationError('File type not allowed');
  }
  if (file.size > MAX_SIZE) {
    throw new ValidationError('File too large (max 5MB)');
  }
  // Don't trust the file extension — check magic bytes if critical
}

Triaging npm audit Results

Not all audit findings require immediate action. Use this decision tree:

npm audit reports a vulnerability
├── Severity: critical or high
│   ├── Is the vulnerable code reachable in your app?
│   │   ├── YES --> Fix immediately (update, patch, or replace the dependency)
│   │   └── NO (dev-only dep, unused code path) --> Fix soon, but not a blocker
│   └── Is a fix available?
│       ├── YES --> Update to the patched version
│       └── NO --> Check for workarounds, consider replacing the dependency, or add to allowlist with a review date
├── Severity: moderate
│   ├── Reachable in production? --> Fix in the next release cycle
│   └── Dev-only? --> Fix when convenient, track in backlog
└── Severity: low
    └── Track and fix during regular dependency updates

Key questions:

  • Is the vulnerable function actually called in your code path?
  • Is the dependency a runtime dependency or dev-only?
  • Is the vulnerability exploitable given your deployment context (e.g., a server-side vulnerability in a client-only app)?

When you defer a fix, document the reason and set a review date.

Supply-Chain Hygiene

npm audit catches known CVEs; it won't catch a malicious or typosquatted package. Also:

  • Commit the lockfile and install with npm ci (not npm install) in CI — reproducible builds, no silent version drift.
  • Review new dependencies before adding them — maintenance, download counts, and whether they truly earn their place. Every dependency is attack surface (OWASP A06: Vulnerable Components, LLM03: Supply Chain).
  • Be wary of postinstall scripts in unfamiliar packages — they run arbitrary code at install time.
  • Watch for typosquats — cross-env vs crossenv, react-dom vs reactdom.

Rate Limiting

typescript
import rateLimit from 'express-rate-limit';

// General API rate limit
app.use('/api/', rateLimit({
  windowMs: 15 * 60 * 1000, // 15 minutes
  max: 100,                   // 100 requests per window
  standardHeaders: true,
  legacyHeaders: false,
}));

// Stricter limit for auth endpoints
app.use('/api/auth/', rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 10,  // 10 attempts per 15 minutes
}));

Secrets Management

.env files:
  ├── .env.example  → Committed (template with placeholder values)
  ├── .env          → NOT committed (contains real secrets)
  └── .env.local    → NOT committed (local overrides)

.gitignore must include:
  .env
  .env.local
  .env.*.local
  *.pem
  *.key

Always check before committing:

bash
# Check for accidentally staged secrets
git diff --cached | grep -i "password\|secret\|api_key\|token"

If a secret is ever committed, rotate it. Deleting the line or rewriting history is not enough — assume it's compromised the moment it reaches a remote. Revoke and reissue the key first, then purge it from history.

Show full SKILL.md (545 more words)Show less

Securing AI / LLM Features

If your app calls an LLM — chatbots, summarizers, agents, RAG — it inherits a new attack surface. Map it to the OWASP Top 10 for LLM Applications (2025):

  • Treat all model output as untrusted input (LLM05: Improper Output Handling). Never pass LLM output straight into eval, SQL, a shell, innerHTML, or a file path. Validate and encode it exactly as you would raw user input.
  • Assume prompts can be hijacked (LLM01: Prompt Injection). Untrusted text in the context window — a user message, a fetched web page, a PDF — can carry instructions. The system prompt is not a security boundary; enforce permissions in code, not in the prompt.
  • Keep secrets and other users' data out of prompts (LLM02 / LLM07). Anything in the context can be echoed back. Don't put API keys, cross-tenant data, or the full system prompt where the model can repeat it.
  • Constrain tool and agent permissions (LLM06: Excessive Agency). Scope tools to the minimum, require confirmation for destructive or irreversible actions, and validate every tool argument.
  • Bound consumption (LLM10: Unbounded Consumption). Cap tokens, request rate, and loop/recursion depth so a crafted input can't run up cost or hang the system.
  • Isolate retrieval data (LLM08: Vector and Embedding Weaknesses). In RAG, treat the vector store as a trust boundary: partition embeddings per tenant so one user can't retrieve another's data, and validate documents before indexing so poisoned content can't steer answers.
typescript
// BAD: trusting model output as a command or as markup
const sql = await llm.generate(`Write SQL for: ${userQuestion}`);
await db.query(sql);                                   // arbitrary query execution
container.innerHTML = await llm.reply(userMessage);   // stored XSS, via the model

// GOOD: model output is data — parse defensively, then validate, then encode
let intent;
try {
  intent = CommandSchema.parse(JSON.parse(await llm.replyJson(userMessage)));
} catch {
  throw new ValidationError('unexpected model output'); // JSON.parse or schema failed
}
await runAllowlistedAction(intent.action, intent.params);
container.textContent = await llm.reply(userMessage);

Security Review Checklist

markdown
### Authentication
- [ ] Passwords hashed with bcrypt/scrypt/argon2 (salt rounds ≥ 12)
- [ ] Session tokens are httpOnly, secure, sameSite
- [ ] Login has rate limiting
- [ ] Password reset tokens expire

### Authorization
- [ ] Every endpoint checks user permissions
- [ ] Users can only access their own resources
- [ ] Admin actions require admin role verification

### Input
- [ ] All user input validated at the boundary
- [ ] SQL queries are parameterized
- [ ] HTML output is encoded/escaped
- [ ] Server-side URL fetches are allowlisted (no SSRF to internal services)

### Data
- [ ] No secrets in code or version control
- [ ] Sensitive fields excluded from API responses
- [ ] PII encrypted at rest (if applicable)

### Infrastructure
- [ ] Security headers configured (CSP, HSTS, etc.)
- [ ] CORS restricted to known origins
- [ ] Dependencies audited for vulnerabilities
- [ ] Error messages don't expose internals

### Supply Chain
- [ ] Lockfile committed; CI installs with `npm ci`
- [ ] New dependencies reviewed (maintenance, downloads, postinstall scripts)

### AI / LLM (if used)
- [ ] Model output treated as untrusted (no eval/SQL/innerHTML/shell)
- [ ] Secrets and other users' data kept out of prompts
- [ ] Tool/agent permissions scoped; destructive actions require confirmation

See Also

For detailed security checklists and pre-commit verification steps, see references/security-checklist.md.

Common Rationalizations

RationalizationReality
"This is an internal tool, security doesn't matter"Internal tools get compromised. Attackers target the weakest link.
"We'll add security later"Security retrofitting is 10x harder than building it in. Add it now.
"No one would try to exploit this"Automated scanners will find it. Security by obscurity is not security.
"The framework handles security"Frameworks provide tools, not guarantees. You still need to use them correctly.
"It's just a prototype"Prototypes become production. Security habits from day one.
"Threat modeling is overkill here"Five minutes of "how would I attack this?" prevents the design flaws no control can patch later.
"It's just LLM output, it's only text"That "text" can be a SQL statement, a script tag, or a shell command. Treat it like any untrusted input.

Red Flags

  • User input passed directly to database queries, shell commands, or HTML rendering
  • Secrets in source code or commit history
  • API endpoints without authentication or authorization checks
  • Missing CORS configuration or wildcard (*) origins
  • No rate limiting on authentication endpoints
  • Stack traces or internal errors exposed to users
  • Dependencies with known critical vulnerabilities
  • Server fetches user-supplied URLs without an allowlist (SSRF)
  • LLM/model output passed into a query, the DOM, a shell, or eval
  • Secrets, PII, or the full system prompt placed inside an LLM context window

Verification

After implementing security-relevant code:

  • npm audit shows no critical or high vulnerabilities
  • No secrets in source code or git history
  • All user input validated at system boundaries
  • Authentication and authorization checked on every protected endpoint
  • Security headers present in response (check with browser DevTools)
  • Error responses don't expose internal details
  • Rate limiting active on auth endpoints
  • Server-side URL fetches validated against an allowlist (no SSRF)
  • LLM/model output validated and encoded before use (if AI features present)

© BlackBeltTechnology, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in packages/eng-disciplines/.pi/skills/security-hardening of BlackBeltTechnology/pi-agent-dashboard.

  • SKILL.md
  • SKILL.agent.md

Open the folder on GitHubat commit 7a2d171

Compare with similar skills

Security Hardening next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Security Hardening compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Security Hardening this skillBlackBeltTechnology/pi-agent-dashboard315—~4.7kAutomated safety check: NotesMIT
Security Audit Scannerruvnet/ruflo74k2 repos~823Automated safety check: PassMIT
CybersecurityAgriciDaniel/claude-cybersecurity228—~11kAutomated safety check: WarnMIT
Securitygaragon/nanostack207—~3.7kAutomated safety check: NotesApache-2.0
Csono-session/pstack136—~12kAutomated safety check: NotesMIT
007sickn33/agentic-awesome-skills47k2 repos~410Automated safety check: PassMIT

Similar skills

  • Runs claude-flow CLI security scans for input validation, path traversal, SQL injection, XSS, hardcoded secrets and known CVEs, and writes an audit report.

    74k GitHub starsUsed in 2 repos~823 tokens
    SecurityAuto-check passed
  • Cybersecurity

    AgriciDaniel/claude-cybersecurity

    Ultimate AI-powered cybersecurity code review skill. An agent skill from AgriciDaniel/claude-cybersecurity.

    228 GitHub stars~11k tokensUpdated 5 mo ago
    SecurityAuto-check: warnings
  • Security

    garagon/nanostack

    Use before shipping to production. An agent skill from garagon/nanostack.

    207 GitHub stars~3.7k tokensUpdated 1 mo ago
    SecurityAuto-check: notes
  • Cso

    no-session/pstack

    Chief Security Officer mode. An agent skill from no-session/pstack.

    136 GitHub stars~12k tokensUpdated 6 mo ago
    SecurityAuto-check: notes
  • 007

    sickn33/agentic-awesome-skills

    Security audit, hardening, threat modeling (STRIDE/PASTA), Red/Blue Team, OWASP checks, code review, incident response, and infrastructure security for any project.

    47k GitHub starsUsed in 2 repos~410 tokens
    SecurityAuto-check passed
  • Security Audit

    fossasia/eventyay-interpretation

    A skill your agent uses for security reviews of VoxBento code.

    1.6k GitHub stars~1.3k tokensUpdated 5 days ago
    SecurityAuto-check passed

More from BlackBeltTechnology/pi-agent-dashboard

All 70 skills in this repo
  • Browser

    BlackBeltTechnology/pi-agent-dashboard

    Browser automation via the agent-browser CLI. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

    315 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • CI Troubleshoot

    BlackBeltTechnology/pi-agent-dashboard

    Diagnose failed GitHub Actions runs for pi-agent-dashboard: the 11-file workflow taxonomy, affected-test selection, the release pipeline, known failure modes, and how to read gh run logs and…

    315 GitHub stars~3.5k tokensUpdated today
    Auto-check passed
  • Debug Dashboard

    BlackBeltTechnology/pi-agent-dashboard

    Diagnose problems in the running pi-agent-dashboard system: server.log, /api/health, bridge WebSocket connectivity, vitest triage, known-issue FAQ entries.

    315 GitHub stars~1.6k tokensUpdated today
    Auto-check passed
  • Implement

    BlackBeltTechnology/pi-agent-dashboard

    Disciplined implementation in pi-agent-dashboard: the rebuild matrix (extension→reload, server→restart, client→build+restart, openspec-apply→full rebuild) plus the project's code discipline rules.

    315 GitHub stars~2k tokensUpdated today
    Auto-check passed
  • Pi Dashboard

    BlackBeltTechnology/pi-agent-dashboard

    Monitor and control the pi-dashboard server. An agent skill from BlackBeltTechnology/pi-agent-dashboard.

    315 GitHub stars~2.2k tokensUpdated today
    Auto-check passed
  • Session To Guideline

    BlackBeltTechnology/pi-agent-dashboard

    Turn a pi session into a Markdown "how-we-did-it" collaboration guideline: reads the session's JSONL transcript and synthesizes a reusable playbook of which prompts worked, what had to be steered…

    315 GitHub stars~3.2k tokensUpdated today
    Auto-check passed

Categories

Questions about Security Hardening

What does Security Hardening do?

Harden code against vulnerabilities. An agent skill from BlackBeltTechnology/pi-agent-dashboard. Security Hardening is an agent skill from BlackBeltTechnology/pi-agent-dashboard. Harden code against vulnerabilities.

When should I use Security Hardening?

Security Hardening fits situations like: like security audit; touching untrusted input; third-party integrations.

How do I install Security Hardening in Claude Code?

Run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill security-hardening -a claude-code`. Or copy the skill folder (packages/eng-disciplines/.pi/skills/security-hardening in BlackBeltTechnology/pi-agent-dashboard) into .claude/skills/security-hardening in your project. Claude Code loads it when a task matches its description.

How do I install Security Hardening in Codex?

Run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill security-hardening -a codex`. Or copy the skill folder (packages/eng-disciplines/.pi/skills/security-hardening in BlackBeltTechnology/pi-agent-dashboard) into .agents/skills/security-hardening in your project. Codex loads it when a task matches its description.

Can I use Security Hardening in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add BlackBeltTechnology/pi-agent-dashboard --skill security-hardening -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/security-hardening, .gemini/skills/security-hardening, .github/skills/security-hardening and .opencode/skills/security-hardening in your project.

What does Security Hardening need to run?

Going by SKILL.md and its folder, Security Hardening needs the command-line tools its instructions call (npm and git) and credentials named API_KEY, STRIPE_API_KEY and SESSION_SECRET. Our summary lists: Node.js; A credential in SESSION_SECRET; A credential in API_KEY.

Does Security Hardening access the network?

SKILL.md names 1 domain. As links in the text: genai.owasp.org. This is read from the text; nothing was executed.

Is Security Hardening safe to install?

Our automated static check of SKILL.md found notes only (mentions a .env file), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Security Hardening use?

Security Hardening is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Security Hardening use?

About 4.7k tokens (SKILL.md is roughly 19k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Security Hardening?

Skills that share tags, products or a category with Security Hardening: Security Audit Scanner (ruvnet/ruflo, 74k stars), Cybersecurity (AgriciDaniel/claude-cybersecurity, 228 stars), Security (garagon/nanostack, 207 stars) and Cso (no-session/pstack, 136 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Security Hardening?

BlackBeltTechnology (a GitHub organization) maintains it in BlackBeltTechnology/pi-agent-dashboard, which has 315 GitHub stars. The repository holds 70 skills in this directory. The repository was last updated on October 10, 2026.

Source: BlackBeltTechnology/pi-agent-dashboard on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.