opencodekit 0.21.10 → 0.22.0

package/dist/template/.opencode/skill/security-threat-model/references/prompt-template.md

@@ -1,255 +0,0 @@
-# Threat Modeling Prompt Template for LLMs
-
-This reference provides a disciplined, repo-grounded prompt that produces AppSec-usable threat models. Use it when you need a reliable output contract and a consistent process to assemble the threat model output
-
-## System prompt
-
-Use this as a stable system prompt:
-
-````text
-You are a senior application security engineer producing a threat model that will be read by other AppSec engineers.
-
-Primary objective:
-- Generate a threat model that is specific to THIS repository and its real-world usage.
-- Prefer concrete, evidence-backed findings over generic vulnerability checklists.
-
-Evidence and grounding rules:
-- Do not invent components, data stores, endpoints, flows, or controls.
-- Every architectural claim must be backed by at least one "Evidence anchor" referencing a repo path
-  (and a symbol name, config key, or a short quoted snippet if available).
-- If information is missing, state assumptions explicitly and list the open questions needed to validate them.
-
-Security hygiene:
-- Never output secrets. If you encounter tokens/keys/passwords, redact them and only describe their presence and location.
-
-Threat modeling approach:
-- Model the system using data flows and trust boundaries.
-- Enumerate threats and produce attack goals and abuse paths
-- Prioritize threats using explicit likelihood and impact reasoning (qualitative is acceptable: low/medium/high).
-
-Scope discipline:
-- Clearly separate: production/runtime behavior vs CI/build/dev tooling vs tests/examples.
-- Clearly separate attacker-controlled inputs vs operator-controlled inputs vs developer-controlled inputs.
-- If a vulnerability class requires attacker control that likely does not exist for this repo's real usage, say so and downgrade severity.
-
-Communication quality:
-- Write for AppSec engineers: concise but specific.
-- Use precise terminology. Include mitigations and residual risks.
-- Avoid restating large blocks of README/spec; summarize and point to evidence.
-
-Diagram requirements:
-- Produce a single compact Mermaid flowchart showing primary components and trust boundaries.
-- Mermaid must render cleanly. Use a conservative subset:
-  - Use `flowchart TD` or `flowchart LR` and only `-->` arrows.
-  - Use simple node IDs (letters/numbers/underscores only) and quoted labels (e.g., `A["Label"]`); avoid `A(Label)` shape syntax.
-  - Do not use Mermaid `title` lines or `style` directives.
-  - Keep edge labels to plain words/spaces only via `-->|label|`; avoid `{}`, `[]`, `()`, or quotes in edge labels (if needed, drop the label).
-  - Keep node labels short and readable: do not include file paths, URLs, or socket paths (put those details in prose outside the diagram).
-- Wrap the diagram in a Markdown fenced block:
-  ```mermaid
-  <mermaid syntax here>
-  ```
-````
-
-## Repository summary prompt
-
-```
-We have a codebase located at {repo_directory/path}, currently on branch {branch_name}.
-
-Please produce a security-oriented summary of the repository (or the specified sub-path) with the goal of helping a follow-on security engineer quickly understand the system well enough to build an initial threat model and investigate potential security hypotheses.
-
-Objectives
-1.	Project overview
-	•	Identify the primary programming languages, frameworks, and build system.
-	•	Summarize the project’s core purpose and high-level architecture.
-	•	Describe major components, services, or modules and how they interact.
-2.	Security posture and entry points
-	•	Identify likely user entry points and trust boundaries.
-	•	Describe existing security layers (e.g., authentication, authorization, validation, sandboxing, isolation, privilege boundaries).
-	•	Call out security-critical components and assumptions that must hold for the system to remain secure.
-
-Guidance for Security Analysis
-
-Structure the summary so an application security engineer can quickly answer questions such as:
-	•	Where does user input originate?
-	•	How is untrusted data parsed, validated, and handled?
-	•	What security assumptions should not be violated?
-	•	Where are the most likely choke points for security bugs?
-
-Adapt the analysis to the project type. For example:
-	•	Web applications: where requests enter, how user data is parsed, routed, authenticated, and stored.
-	•	Command-line tools: supported inputs (arguments, files, environment variables, stdin) and how they are processed.
-	•	Network daemons: exposed ports, supported protocols, message formats, and request handling paths.
-	•	Operating system or low-level components: common vulnerability classes (e.g., memory corruption, logic flaws) that could lead to LPE or RCE.
-
-Be thorough but pragmatic: the goal is to help a security engineer quickly determine whether a discovered bug is security-relevant and where deeper investigation should focus.
-
-Tooling Notes
-
-If Ripgrep (rg) is available, use it to explore the codebase. When using grep or rg, always include the -I flag to avoid searching through binary files.
-```
-
-
-
-## User prompt template
-
-Use this as the task prompt, filling in what you know and marking the rest as assumptions:
-
-```text
-# Inputs
-Context (fill as available; otherwise infer and mark assumptions):
-- intended_usage: {intended_usage}
-- deployment_model: {deployment_model}
-- data_sensitivity: {data_sensitivity}
-- internet_exposure: {internet_exposure}
-- authn_authz_expectations: {authn_authz_expectations}
-- out_of_scope: {out_of_scope}
-
-Provided summaries (may be incomplete):
-- repository_summary: {repository_summary}
-
-
-In-scope code locations (if known):
-- in_scope_paths: {in_scope_paths}
-
-# Task
-Construct a repo-centric threat model that helps AppSec engineers understand the most important security risks and where to focus manual review.
-
-You MUST follow this process and reflect outputs in the final document:
-
-## Process
-1) Repo discovery (evidence collection)
-   a. Identify the repo shape:
-      - languages and frameworks
-      - how it runs (server/cli/library), entrypoints, build artifacts
-   b. Identify security-relevant surfaces and controls by searching for evidences, such as:
-      - network listeners/routes/endpoints; RPC handlers; message consumers
-      - authentication, session/token handling, authorization checks, RBAC/ACL logic
-      - parsing/serialization/deserialization (JSON/YAML/XML/protobuf), template rendering, eval/dynamic code
-      - file upload/read paths, archive extraction, image/document parsing
-      - database/queue/cache clients and query construction
-      - secrets/config loading, environment variables, key management
-      - SSRF-capable HTTP clients, webhooks, URL fetchers
-      - sandboxing/isolation, privilege boundaries, subprocess execution
-      - logging/auditing and error handling paths
-      - CI/build/release: pipelines, dependency management, artifact publishing
-   
-2) System model
-   a. Summarize the primary components (runtime plus critical build/CI components when relevant).
-   b. Enumerate data flows and trust boundaries.
-      - For each trust boundary, specify:
-        * source to destination
-        * data types crossing (e.g., credentials, PII, files, tokens, prompts)
-        * channel/protocol (HTTP/gRPC/IPC/file/db)
-        * security guarantees and validation (auth, mTLS, origin checks, schema validation, rate limits)
-   c. Provide a compact Mermaid diagram showing components and trust boundaries.
-
-3) Assets and security objectives
-   - List assets (data, credentials, integrity-critical state, availability-critical components, build artifacts).
-   - For each asset, state why it matters (confidentiality/integrity/availability, compliance, user harm).
-
-4) Attacker model
-   - Capabilities: realistic remote attacker assumptions based on intended usage and exposure.
-   - Non-capabilities: things attacker cannot plausibly do (unless explicitly in scope), to avoid inflated severity.
-
-5) Threat enumeration (concrete, system-specific)
-   - Generate threats as attacker stories tied to:
-     * entry points
-     * trust boundaries
-     * privileged components
-   - Prefer abuse paths (multi-step sequences) over single-line generic threats.
-
-6) Risk prioritization
-   - For each threat:
-     * Likelihood: low/medium/high with a 1 to 2 sentence justification
-     * Impact: low/medium/high with a 1 to 2 sentence justification
-     * Overall priority: critical/high/medium/low (based on likelihood x impact, adjusted for existing controls)
-   - Explicitly state which assumptions most affect risk.
-
-7) Validate assumptions and service context with the user (required before final report)
-   - Summarize key assumptions that materially affect scope or risk ranking.
-   - Ask 1 to 3 targeted questions to resolve missing service meta-context (service owner/environment, scale/users, deployment model, authn/authz, internet exposure, data sensitivity, multi-tenancy).
-   - Pause and wait for user feedback before producing the final report.
-   - If the user cannot answer, proceed with explicit assumptions and mark any conditional conclusions.
-
-8) Mitigations and recommendations
-   - For each high/critical threat:
-     * Existing mitigations (with evidence anchors)
-     * Gaps/weaknesses
-     * Recommended mitigations (code/config/process)
-     * Detection/monitoring ideas (logging, metrics, alerts)
-
-9) Focus paths for manual security review
-   - Output 2 to 30 repo-relative paths (files or directories) that merit deeper review.
-   - For each path, give a one-sentence reason tied to the threat model.
-
-10) Quality check
-   - Provide a short checklist confirming you covered:
-     * all entry points you discovered
-     * each trust boundary at least once in threats
-     * runtime vs CI/dev separation
-     * user clarifications (or explicit non-responses)
-     * assumptions and open questions
-
-## Required output format (exact)
-Before producing the final Markdown report, first provide an assumption-validation check-in:
-- List the key assumptions in 3 to 6 bullets.
-- Ask 1 to 3 targeted context questions.
-- Wait for the user response, then produce the final report below using the clarified context.
-
-Produce valid Markdown with these sections in this order:
-
-## Executive summary
-- 1 short paragraph on the top risk themes and highest-risk areas.
-
-## Scope and assumptions
-- In-scope paths, out-of-scope items, and explicit assumptions.
-- A short list of open questions that would materially change the risk ranking.
-
-
-## System model
-### Primary components
-### Data flows and trust boundaries
-Represent the system as a sequence of arrow-style bullets (e.g., Internet → API Server, User Input -> Application Logic, etc). For each boundary, document:
-	•	the primary data types crossing the boundary,
-	•	the communication channel or protocol,
-	•	the security guarantees (e.g., authentication, origin checks, encryption, rate limiting), and
-	•	any input validation, normalization, or schema enforcement performed.
-
-#### Diagram
-- Include a single, compact Mermaid diagram (`flowchart TD` or `flowchart LR`) showing primary components and trust boundaries (e.g., separate trust zones via subgraphs). Keep it compact, use only `-->`, avoid `title`/`style`, keep node labels short (no paths/URLs), and keep edge labels to plain words only (avoid `{}`, `[]`, `()`, or quotes).
-
-
-## Assets and security objectives
-- A table: Asset | Why it matters | Security objective (C/I/A)
-
-## Attacker model
-### Capabilities
-### Non-capabilities
-
-## Entry points and attack surfaces
-- A table: Surface | How reached | Trust boundary | Notes | Evidence (repo path / symbol)
-
-## Top abuse paths
-- 5 to 10 short abuse paths, each as a numbered sequence of steps (attacker goal -> steps -> impact).
-
-## Threat model table
-- A Markdown table with columns:
-  Threat ID | Threat source | Prerequisites | Threat action | Impact | Impacted assets | Existing controls (evidence) | Gaps | Recommended mitigations | Detection ideas | Likelihood | Impact severity | Priority
-
-Rules:
-- Threat IDs must be stable and formatted: TM-001, TM-002, ...
-- Priority must be one of: critical, high, medium, low.
-- Keep prerequisites to 1 to 2 sentences. Keep recommended mitigations concrete.
-
-## Criticality calibration
-- Define what counts as critical/high/medium/low for THIS repo and context.
-- Include 2 to 3 examples per level (tailored to the repo's assets and exposure).
-
-## Focus paths for security review
-- A table: Path | Why it matters | Related Threat IDs
-
-## Notes on use
-
-- Fill in known context, but allow the model to infer and mark assumptions.
-- Include 1–2 repo-path anchors per major claim; do not dump every match.

package/dist/template/.opencode/skill/security-threat-model/references/security-controls-and-assets.md

@@ -1,32 +0,0 @@
-# Security Controls and Asset Categories
-
-Use this as a lightweight checklist to keep outputs consistent across teams. Prefer concrete, system-specific items over generic text.
-
-## Asset categories (pick only what applies)
-- User data (PII, content, uploads)
-- Authentication artifacts (passwords, tokens, sessions, cookies)
-- Authorization state (roles, policies, ACLs)
-- Secrets and keys (API keys, signing keys, encryption keys)
-- Configuration and feature flags
-- Models and weights (if ML systems)
-- Source code and build artifacts
-- Audit logs and telemetry
-- Availability-critical resources (queues, caches, rate limits, compute budgets)
-- Tenant isolation boundaries and metadata
-
-## Security control categories
-- Identity and access: authN, authZ, session handling, mTLS, key rotation
-- Input protection: schema validation, parsing hardening, upload scanning, sandboxing
-- Network safeguards: TLS, network policies, WAF, rate limiting, DoS controls
-- Data protection: encryption at rest/in transit, tokenization, redaction
-- Isolation: process sandboxing, container boundaries, tenant isolation, seccomp
-- Observability: audit logs, alerting, anomaly detection, tamper resistance
-- Supply chain: dependency pinning, SBOMs, provenance, signing
-- Change control: CI checks, deployment approvals, config guardrails
-
-## Mitigation phrasing patterns
-- "Enforce schema at <boundary> for <payload> before <component>."
-- "Require authZ check for <action> on <resource> in <service>."
-- "Isolate <parser/component> in a sandbox with <resource limits>."
-- "Rate limit <endpoint> by <key> and apply burst caps."
-- "Encrypt <data> at rest using <key management> and rotate <keys>."

package/dist/template/.opencode/skill/sharing-skills/SKILL.md

@@ -1,214 +0,0 @@
----
-name: sharing-skills
-description: Use when you've developed a broadly useful skill and want to contribute it upstream via pull request - guides process of branching, committing, pushing, and creating PR to contribute skills back to upstream repository
-version: 1.0.0
-tags: [workflow, git]
-dependencies: []
----
-
-# Sharing Skills
-
-## When to Use
-
-- When a skill is broadly useful and ready to be contributed upstream via pull request.
-
-## When NOT to Use
-
-- When the skill is project-specific, experimental, or contains sensitive information.
-
-## Overview
-
-Contribute skills from your local branch back to the upstream repository.
-
-**Workflow:** Branch → Edit/Create skill → Commit → Push → PR
-
-## When to Share
-
-**Share when:**
-
-- Skill applies broadly (not project-specific)
-- Pattern/technique others would benefit from
-- Well-tested and documented
-- Follows writing-skills guidelines
-
-**Keep personal when:**
-
-- Project-specific or organization-specific
-- Experimental or unstable
-- Contains sensitive information
-- Too narrow/niche for general use
-
-## Prerequisites
-
-- `gh` CLI installed and authenticated
-- Working directory is `.opencode/skill/` (your project skills)
-- **REQUIRED:** Skill has been tested using writing-skills TDD process
-
-## Sharing Workflow
-
-### 1. Ensure You're on Main and Synced
-
-```bash
-cd .opencode/skill/
-git checkout main
-git pull upstream main
-git push origin main  # Push to your fork
-```
-
-### 2. Create Feature Branch
-
-```bash
-# Branch name: add-skillname-skill
-skill_name="your-skill-name"
-git checkout -b "add-${skill_name}-skill"
-```
-
-### 3. Create or Edit Skill
-
-```bash
-# Work on your skill in skills/
-# Create new skill or edit existing one
-# Skill should be in skills/category/skill-name/SKILL.md
-```
-
-### 4. Commit Changes
-
-```bash
-# Add and commit
-git add skills/your-skill-name/
-git commit -m "Add ${skill_name} skill
-
-$(cat <<'EOF'
-Brief description of what this skill does and why it's useful.
-
-Tested with: [describe testing approach]
-EOF
-)"
-```
-
-### 5. Push to Your Fork
-
-```bash
-git push -u origin "add-${skill_name}-skill"
-```
-
-### 6. Create Pull Request
-
-```bash
-# Create PR to upstream using gh CLI
-gh pr create \
-  --repo upstream-org/upstream-repo \
-  --title "Add ${skill_name} skill" \
-  --body "$(cat <<'EOF'
-## Summary
-Brief description of the skill and what problem it solves.
-
-## Testing
-Describe how you tested this skill (pressure scenarios, baseline tests, etc.).
-
-## Context
-Any additional context about why this skill is needed and how it should be used.
-EOF
-)"
-```
-
-## Complete Example
-
-Here's a complete example of sharing a skill called "async-patterns":
-
-```bash
-# 1. Sync with upstream
-cd .opencode/skill/
-git checkout main
-git pull upstream main
-git push origin main
-
-# 2. Create branch
-git checkout -b "add-async-patterns-skill"
-
-# 3. Create/edit the skill
-# (Work on skills/async-patterns/SKILL.md)
-
-# 4. Commit
-git add skills/async-patterns/
-git commit -m "Add async-patterns skill
-
-Patterns for handling asynchronous operations in tests and application code.
-
-Tested with: Multiple pressure scenarios testing agent compliance."
-
-# 5. Push
-git push -u origin "add-async-patterns-skill"
-
-# 6. Create PR
-gh pr create \
-  --repo upstream-org/upstream-repo \
-  --title "Add async-patterns skill" \
-  --body "## Summary
-Patterns for handling asynchronous operations correctly in tests and application code.
-
-## Testing
-Tested with multiple application scenarios. Agents successfully apply patterns to new code.
-
-## Context
-Addresses common async pitfalls like race conditions, improper error handling, and timing issues."
-```
-
-## After PR is Merged
-
-Once your PR is merged:
-
-1. Sync your local main branch:
-
-```bash
-cd .opencode/skill/
-git checkout main
-git pull upstream main
-git push origin main
-```
-
-2. Delete the feature branch:
-
-```bash
-git branch -d "add-${skill_name}-skill"
-git push origin --delete "add-${skill_name}-skill"
-```
-
-## Troubleshooting
-
-**"gh: command not found"**
-
-- Install GitHub CLI: https://cli.github.com/
-- Authenticate: `gh auth login`
-
-**"Permission denied (publickey)"**
-
-- Check SSH keys: `gh auth status`
-- Set up SSH: https://docs.github.com/en/authentication
-
-**"Skill already exists"**
-
-- You're creating a modified version
-- Consider different skill name or coordinate with the skill's maintainer
-
-**PR merge conflicts**
-
-- Rebase on latest upstream: `git fetch upstream && git rebase upstream/main`
-- Resolve conflicts
-- Force push: `git push -f origin your-branch`
-
-## Multi-Skill Contributions
-
-**Do NOT batch multiple skills in one PR.**
-
-Each skill should:
-
-- Have its own feature branch
-- Have its own PR
-- Be independently reviewable
-
-**Why?** Individual skills can be reviewed, iterated, and merged independently.
-
-## Related Skills
-
-- **writing-skills** - REQUIRED: How to create well-tested skills before sharing

package/dist/template/.opencode/skill/skill-creator/SKILL.md

@@ -1,181 +0,0 @@
----
-name: skill-creator
-description: Guide for creating effective skills. Use when creating a new skill or updating an existing skill that extends an agent's capabilities with specialized knowledge, workflows, or tool integrations.
-version: 1.0.0
-tags: [documentation, workflow]
-dependencies: []
----
-
-# Skill Creator
-
-## When to Use
-
-- When creating a new skill or updating an existing skill with specialized workflows or tool integrations.
-
-## When NOT to Use
-
-- When making routine project changes that don't require a reusable skill.
-
-
-
-## What Skills Provide
-
-1. **Specialized workflows** - Multi-step procedures for specific domains
-2. **Tool integrations** - Instructions for working with specific file formats or APIs
-3. **Domain expertise** - Company-specific knowledge, schemas, business logic
-4. **Bundled resources** - Scripts, references, and assets for complex tasks
-
-## Skill Structure
-
-```
-skill-name/
-├── SKILL.md (required)
-│   ├── YAML frontmatter (name, description)
-│   └── Markdown instructions
-└── Bundled Resources (optional)
-    ├── scripts/          - Executable code (Python/Bash/etc.)
-    ├── references/       - Documentation loaded as needed
-    └── assets/           - Files used in output (templates, icons)
-```
-
-## Requirements
-
-- `SKILL.md` should be **less than 200 lines**
-- Use `references/` for detailed documentation
-- Each script or reference file also **less than 200 lines**
-- Descriptions must be specific about WHEN to use the skill
-
-## SKILL.md Format
-
-**REQUIRED - DO NOT SKIP**
-
-```yaml
----
-name: skill-name
-description: What this skill does and when to use it. Use third-person.
----
-```
-
-**Required fields:**
-
-- `name` — hyphen-case identifier matching directory name
-- `description` — activation trigger; be specific about WHEN to use
-
-**Optional fields:**
-
-```yaml
----
-name: skill-name
-description: What this skill does and when to use it.
-references:
-  - references/guide.md
-  - references/api.md
-license: Apache-2.0
----
-```
-
-**INVALID - Do NOT use:**
-
-- XML-style tags (`<purpose>`, `<references>`)
-- Missing `---` delimiters
-- Frontmatter that doesn't start at line 1
-
-## Bundled Resources
-
-### Scripts (`scripts/`)
-
-- When the same code is being rewritten repeatedly
-- When deterministic reliability is needed
-- Prefer Node.js or Python over Bash (Windows support)
-
-### References (`references/`)
-
-- Documentation that agent should reference while working
-- Database schemas, API docs, domain knowledge
-- If files are large (>10k words), include grep patterns in SKILL.md
-
-### Assets (`assets/`)
-
-- Files used in the final output (not loaded into context)
-- Templates, images, icons, boilerplate code
-
-## Progressive Disclosure
-
-Skills use three-level loading:
-
-1. **Metadata (name + description)** - Always in context (~100 words)
-2. **SKILL.md body** - When skill triggers (<5k words)
-3. **Bundled resources** - As needed by agent (Unlimited)
-
-## Skill Creation Process
-
-### Step 1: Understand with Examples
-
-- "What functionality should the skill support?"
-- "Can you give examples of how this would be used?"
-- "What would a user say that should trigger this skill?"
-
-### Step 2: Plan Reusable Contents
-
-For each example, identify:
-
-- What scripts would be helpful to store?
-- What references/documentation needed?
-- What assets/templates needed?
-
-### Step 3: Create the Skill
-
-```bash
-mkdir -p .opencode/skill/my-skill
-touch .opencode/skill/my-skill/SKILL.md
-```
-
-### Step 4: Edit SKILL.md
-
-Answer these questions:
-
-1. What is the purpose of the skill?
-2. When should it be used?
-3. How should the agent use it?
-
-### Step 5: Iterate
-
-1. Use the skill on real tasks
-2. Notice struggles or inefficiencies
-3. Update SKILL.md or bundled resources
-4. Test again
-
-## Pre-Submission Checklist
-
-- [ ] **SKILL.md starts with `---`** (YAML frontmatter, line 1)
-- [ ] **`name:` field present** and matches directory name
-- [ ] **`description:` field present** with specific activation triggers
-- [ ] **Closing `---`** after frontmatter
-- [ ] **No XML-style tags**
-- [ ] **SKILL.md under 200 lines**
-- [ ] **All referenced files exist**
-
-## Recommended Sections for SKILL.md
-
-Beyond the required structure, include these sections when applicable:
-
-### `## Gotchas`
-
-Every skill should accumulate a Gotchas section over time. This is **failure-driven documentation** — each entry should trace to a specific failure encountered during real use.
-
-```markdown
-## Gotchas
-
-- **[Short description of what went wrong]** — [What the agent did wrong, why, and the fix]. Discovered [date or session reference].
-- **[Another failure]** — [Details]. Discovered [date].
-```
-
-**Rules for Gotchas:**
-
-1. Every entry must trace to an actual failure, not a hypothetical risk
-2. Include what the agent did, why it failed, and how to avoid it
-3. New entries are added when a skill causes a failure — the fix PR should include a gotcha entry
-4. Keep entries concise (1-3 sentences each)
-5. This section grows over time and is never cleared — it's the skill's scar tissue
-
-**Why this matters:** Skills without gotchas are untested skills. A skill with 5 gotchas has been battle-tested through 5 real failures and is structurally better than a pristine skill with zero. When a skill causes a failure, always ask: "Should this become a gotcha entry?"