pasta
This skill should be used when the user asks to "run PASTA analysis", "PASTA threat model", "risk-centric threat analysis", or invokes /appsec:pasta. Dispatches 7 stages SEQUENTIALLY -- each stage's output feeds the next. This is the ONLY framework that runs sequentially.
What this skill does
# PASTA Threat Model Dispatcher (Sequential)
Dispatch 7 PASTA stages in strict sequential order. Unlike all other
framework dispatchers, PASTA runs each stage as a Task, waits for its
output, and passes that output into the next stage's prompt. This is
because PASTA is a risk-centric process where business objectives
(Stage 1) constrain technical scope (Stage 2), which constrains
decomposition (Stage 3), and so on through risk analysis (Stage 7).
**Do NOT run stages in parallel. Do NOT skip stages. Do NOT reorder stages.**
### Stage Failure Handling
If a stage fails (returns empty output, errors, or times out):
1. **Record the failure**: stage number, error details, partial output if any.
2. **Check if remaining stages can proceed**:
- Stages 1–3 are foundational. If any fails, STOP the pipeline and report partial results from completed stages.
- Stages 4–7 can run with degraded input from prior stages. Note the gap explicitly in their output.
3. **Present completed stage outputs** to the user with clear status markers:
- `Stage 3: COMPLETED (12 components identified)`
- `Stage 4: FAILED — [reason]. Stages 5–7 ran with reduced context.`
4. **NEVER discard completed stage outputs** due to a later stage failure.
## Supported Flags
Read [`../../shared/schemas/flags.md`](../../shared/schemas/flags.md) for the
full flag specification. This dispatcher supports all cross-cutting flags.
| Flag | Dispatcher-Specific Behavior |
|------|------------------------------|
| `--scope` | Propagated to all stages. Default `changed`. Stages 2-3 may expand scope to trace architecture. |
| `--depth` | Propagated to all stages. Default `standard`. |
| `--severity` | Applied to final Stage 7 output to filter the risk-ranked findings. |
| `--format` | Applied to final consolidated output after Stage 7. |
| `--only 1,4,7` | Run only the listed stages (by number 1-7). Prior stages still run if their output is needed. E.g., `--only 5` implicitly runs 1-4 first. |
| `--fix` | Propagated to Stage 5 (vulnerability analysis) and Stage 7 (risk mitigation). |
| `--quiet` | Propagated to all stages; suppress explanations. |
| `--explain` | Propagated to all stages; add learning material per finding. |
## Framework Reference
Read [`../../shared/frameworks/pasta.md`](../../shared/frameworks/pasta.md) for
the full PASTA framework specification including all 7 stage definitions,
cross-framework mappings to OWASP/STRIDE/CWE, and compliance mapping templates.
## Stage Pipeline
The 7 stages execute strictly in order. Each stage is launched as a single
Task tool call, and you MUST wait for it to complete before launching the
next stage.
| Stage | Skill | Output | Feeds Into |
|-------|-------|--------|------------|
| 1. Business Objectives | `skills/pasta-objectives/SKILL.md` | Business context, risk tolerance, compliance requirements | Stage 2 |
| 2. Technical Scope | `skills/pasta-scope/SKILL.md` | Attack surface inventory, entry points, tech stack, DFD | Stage 3 |
| 3. Application Decomposition | `skills/pasta-decompose/SKILL.md` | Component inventory, trust boundaries, role-permission matrix | Stage 4 |
| 4. Threat Analysis | `skills/pasta-threats/SKILL.md` | Threat catalog, MITRE ATT&CK mappings, attack trees | Stage 5 |
| 5. Vulnerability Analysis | `skills/pasta-vulns/SKILL.md` | Vulnerability inventory with CWE mappings, exploitability scores | Stage 6 |
| 6. Attack Simulation | `skills/pasta-attack-sim/SKILL.md` | Exploit chains, DREAD scores, detection gap analysis | Stage 7 |
| 7. Risk & Impact Analysis | `skills/pasta-risk/SKILL.md` | Risk-ranked findings, mitigation roadmap, executive summary | Final output |
## Sequential Dispatch Workflow
### Step 1: Resolve Scope
Parse flags and resolve the target file list per the flags spec. Build the
initial file list that will be passed to Stage 1.
### Step 2: Execute Stages Sequentially
For EACH stage (1 through 7), follow this pattern:
1. **Build the subagent prompt** with all prior stage outputs embedded.
2. **Launch a single Task tool call** for this stage.
3. **Wait for the Task to complete** and capture its full output.
4. **Store the output** for inclusion in subsequent stage prompts.
5. **Proceed to the next stage.**
Do NOT launch the next stage until the current stage has returned.
### Subagent Prompt Template
Each stage gets a FULLY self-contained prompt including all prior outputs:
```
Execute PASTA Stage {N}: {STAGE_NAME}
STEP 1: Read the skill definition at:
{ABSOLUTE_PATH_TO_PLUGIN}/skills/{SKILL_NAME}/SKILL.md
STEP 2: Read the PASTA framework reference at:
{ABSOLUTE_PATH_TO_PLUGIN}/shared/frameworks/pasta.md
Focus on the "Stage {N}" section for guidance.
STEP 3: Read the findings schema at:
{ABSOLUTE_PATH_TO_PLUGIN}/shared/schemas/findings.md
PRIOR STAGE OUTPUTS (use these as input for your analysis):
--- Stage 1 Output ---
{STAGE_1_OUTPUT or "N/A - this is Stage 1"}
--- Stage 2 Output ---
{STAGE_2_OUTPUT or "Not yet executed"}
[... include all prior stage outputs ...]
FILES TO ANALYZE:
{FILE_LIST}
FLAGS: --scope {SCOPE} --depth {DEPTH} --severity {SEVERITY}
IMPORTANT: Your output will be passed to Stage {N+1} as input. Structure
your output clearly with headers and sections so the next stage can parse
it. Return your stage-specific output only -- do NOT attempt to execute
later stages.
```
### Stage Execution Details
**Stage 1 -- Business Objectives**: Receives only the file list. Infers
business context from code artifacts (payment processing, PII handling,
authentication flows, admin interfaces). Outputs business context
statement, risk tolerance, and compliance requirements.
**Stage 2 -- Technical Scope**: Receives Stage 1 output plus file list.
Maps entry points, protocols, external dependencies, and tech stack.
May request expanded file scanning to find architecture artifacts
(Dockerfiles, K8s manifests, API gateway configs).
**Stage 3 -- Application Decomposition**: Receives Stages 1-2 output.
Decomposes into components, maps trust boundaries, classifies data
sensitivity, documents auth/authz flows per component.
**Stage 4 -- Threat Analysis**: Receives Stages 1-3 output. Identifies
threats using real-world intelligence, maps to MITRE ATT&CK techniques,
builds attack trees for high-value targets identified in Stage 1.
**Stage 5 -- Vulnerability Analysis**: Receives Stages 1-4 output. Core
code analysis stage. Finds specific weaknesses that enable the threats
from Stage 4. Maps to CWE identifiers. Prioritizes vulnerabilities that
directly enable identified threats over theoretical weaknesses.
**Stage 6 -- Attack Simulation**: Receives Stages 1-5 output. Constructs
multi-step exploit chains combining threats (Stage 4) with vulnerabilities
(Stage 5). Scores each chain with DREAD. Identifies which attacks reach
business-critical assets from Stage 1.
**Stage 7 -- Risk & Impact Analysis**: Receives Stages 1-6 output.
Calculates business-weighted risk scores (Likelihood x Business Impact).
Produces risk-ranked finding list, mitigation roadmap (quick wins / short
term / long term), compliance gap report, and executive summary.
## Consolidation
After Stage 7 completes, the dispatcher:
### 1. Collect All Findings
Gather the final risk-ranked finding list from Stage 7 output. Stage 7
already incorporates context from all prior stages.
### 2. Format Output
Apply the `--format` flag to produce the final output. The Stage 7 output
should already contain:
- Executive summary (non-technical stakeholder audience)
- Risk-ranked finding list with business impact justification
- Mitigation roadmap with effort estimates
- Compliance gap report (if regulatory requirements identified in Stage 1)
- Residual risk assessment
### 3. Apply Severity Filter
If `--severity` is set, filter the finding list to show only findings at
or above the specified severity threshold.
### 4. Cross-Reference
Populate cross-framework references on all findings:
- `references.owasp`: Map to OWASP Top Related in Security
mac-ops
IncludedComprehensive macOS workstation operations — diagnose kernel panics, identify failing drives, audit launchd startup items, decode wake reasons, triage TCC permission denials, manage APFS snapshots, recover from no-boot. Use for: Mac is slow, slow bootup, won't boot, kernel panic, kernel_task hot, mds_stores CPU, photoanalysisd, cloudd, login loop, gray screen, sleep wake failure, drive failing, IO errors, APFS snapshots eating space, Time Machine local snapshots, Spotlight indexing, launchd, LaunchAgent, LaunchDaemon, login items, TCC permissions, Full Disk Access, Screen Recording denied, Gatekeeper, quarantine, com.apple.quarantine, app is damaged, helper tool, /Library/PrivilegedHelperTools, pmset, wake reasons, dark wake, sysdiagnose, panic.ips, DiagnosticReports, configuration profile, MDM profile, remote diagnostics over SSH.
a11y-audit
IncludedRun accessibility audits on web projects combining automated scanning (axe-core, Lighthouse) with WCAG 2.1 AA compliance mapping, manual check guidance, and structured reporting. Output is configurable: markdown report only, markdown plus machine-readable JSON, or markdown plus issue tracker integration. Use this skill whenever the user mentions "accessibility audit", "a11y audit", "WCAG audit", "accessibility check", "compliance scan", or asks to check a web project for accessibility issues. Also trigger when the user wants to verify WCAG conformance or map findings to a specific standard (CAN-ASC-6.2, EN 301 549, ADA/AODA).
erpclaw
IncludedAI-native ERP system with self-extending OS. Full accounting, invoicing, inventory, purchasing, tax, billing, HR, payroll, advanced accounting (ASC 606/842, intercompany, consolidation), and financial reporting. 413 actions across 14 domains, 43 expansion modules. Constitutional guardrails, adversarial audit, schema migration. Double-entry GL, immutable audit trail, US GAAP.
assess
IncludedAssesses and rates quality 0-10 across multiple dimensions (correctness, maintainability, security, performance, testability, simplicity) with pros/cons analysis. Compares against project conventions and prior decisions from memory. Produces structured evaluation reports with actionable improvement suggestions. Use when evaluating code, designs, architectures, or comparing alternative approaches.
spring-boot-security-jwt
IncludedProvides JWT authentication and authorization patterns for Spring Boot 3.5.x covering token generation with JJWT, Bearer/cookie authentication, database/OAuth2 integration, and RBAC/permission-based access control using Spring Security 6.x. Use when implementing authentication or authorization in Spring Boot applications.
code-hardcode-audit
IncludedDetect hardcoded values, magic numbers, and leaked secrets. TRIGGERS - hardcode audit, magic numbers, PLR2004, secret scanning.