@muskanmeet/invoicing-design-system 0.1.0

package/.local/skills/threat_modeling/SKILL.md

@@ -0,0 +1,240 @@
+---
+name: threat_modeling
+description: Perform structured threat modeling for a project and write the result to threat_model.md.
+---
+
+# Threat Modeling Skill
+
+Analyze a project's architecture and produce a security reference document that describes assets, trust boundaries, applicable threat categories, and the security guarantees the project must uphold.
+
+## When to Use
+
+- New project kickoff or initial architecture review
+- A new feature introduces authentication, data storage, network exposure, or third-party integrations
+- Pre-deploy or pre-launch security review
+- The user explicitly asks for a threat model or security analysis
+- After a significant architectural change (new microservice, new database, new external API)
+
+## When NOT to Use
+
+- Cosmetic or UI-only changes with no security surface
+- Pure refactors that do not change trust boundaries, data flows, or access control
+- One-off bug fixes unrelated to security
+
+## Methodology
+
+Use a lightweight STRIDE-inspired approach. Work through these steps in order:
+
+### Step 1: Understand the System
+
+Read the codebase, `replit.md`, and any existing `threat_model.md`. Identify:
+
+- What the application does and who its users are
+- The tech stack (language, framework, database, hosting)
+- External services and integrations (payment providers, auth providers, APIs, object storage)
+- A small amount of reusable scan context: likely production entry points, highest-risk code areas, major public/authenticated/admin boundaries, and whether major directories are production, shared, or dev-only
+
+### Step 2: Enumerate Assets
+
+Assets are anything worth protecting. Common examples:
+
+- **User credentials** -- passwords, tokens, session cookies, API keys
+- **Personal data** -- email addresses, names, payment info, uploaded files
+- **Application secrets** -- database connection strings, signing keys, third-party API keys
+- **Business data** -- orders, invoices, analytics, proprietary content
+
+### Step 3: Map Trust Boundaries
+
+A trust boundary exists wherever data crosses between different levels of trust. Identify:
+
+- **Client / Server boundary** -- browser or mobile app to backend API
+- **Server / Database boundary** -- application code to data store
+- **Server / External Service boundary** -- your backend calling third-party APIs
+- **Public / Authenticated boundary** -- routes or resources that require auth vs. those that don't
+- **User / Admin boundary** -- privilege separation between roles
+- **Internal / Production boundary** -- dev/staging environments vs. production
+
+### Step 4: Walk Through Threat Categories
+
+For each asset and trust boundary, consider these STRIDE categories:
+
+**Spoofing** -- Can an attacker impersonate a legitimate user or service?
+
+- Weak or missing authentication on API endpoints
+- Predictable session tokens or JWTs with no signature verification
+- No origin validation on webhooks or callbacks
+
+**Tampering** -- Can an attacker modify data they shouldn't?
+
+- Missing input validation on form fields, query params, or request bodies
+- Client-side-only enforcement of business rules (price, quantity, permissions)
+- Unsigned or unverified data passed between services
+
+**Repudiation** -- Can a user deny performing an action with no way to prove otherwise?
+
+- Missing audit logs for sensitive operations (payments, account changes, data deletion)
+- Logs that don't capture the acting user or timestamp
+- No integrity protection on log storage
+
+**Information Disclosure** -- Can an attacker access data they shouldn't see?
+
+- PII or secrets appearing in logs, error messages, or API responses
+- Overly broad database queries returned directly to the client
+- Directory listings, stack traces, or debug endpoints exposed in production
+- Missing encryption at rest or in transit
+
+**Denial of Service** -- Can an attacker degrade or disrupt the service?
+
+- No rate limiting on authentication or public API endpoints
+- Unbounded file uploads or request body sizes
+- Resource-intensive operations triggered by unauthenticated users
+- Missing timeouts on external service calls
+
+**Elevation of Privilege** -- Can an attacker gain access beyond their authorized level?
+
+- Missing authorization checks after authentication (IDOR, broken function-level access control)
+- Role checks only on the frontend, not enforced server-side
+- SQL injection, command injection, or template injection leading to arbitrary code execution
+- Path traversal allowing file system access outside intended directories
+- Insecure deserialization allowing object manipulation
+
+### Step 5: Describe Required Guarantees
+
+For each relevant threat, describe the security guarantee the project must uphold. Write these as declarative statements:
+
+- "All API endpoints that access user data MUST require a valid session token."
+- "User passwords MUST be hashed with bcrypt (cost >= 12) and MUST NOT appear in logs."
+- "File uploads MUST be validated for type and size, and MUST be stored outside the web root."
+- "All database queries MUST use parameterized statements."
+
+## What to Look Out For
+
+These are the most common and dangerous patterns. Flag them whenever you encounter them:
+
+**Broken access control** -- Missing auth checks on routes, IDOR (guessable IDs granting access to other users' data), privilege escalation through parameter manipulation, admin functionality reachable by regular users.
+
+**Injection** -- SQL queries built with string concatenation, shell commands constructed from user input, template injection through unsanitized variables, path traversal via user-supplied file names, unsafe deserialization of user-controlled data.
+
+**Cryptographic failures** -- Hardcoded secrets or API keys in source code, secrets committed to git, weak hashing algorithms (MD5, SHA1 for passwords), plaintext storage or logging of PII, missing HTTPS enforcement.
+
+**Security misconfiguration** -- Debug mode enabled in production, CORS set to `*` or overly permissive, default credentials left in place, verbose error messages exposing internals, permissive Content Security Policy.
+
+**SSRF and open redirects** -- User-controlled URLs fetched server-side without allowlist validation, redirect targets taken from query parameters without validation.
+
+**Dependency vulnerabilities** -- Outdated packages with known CVEs, no lockfile or pinned versions, dependencies pulled from untrusted registries.
+
+**Data exposure** -- PII in application logs, overly broad API responses returning fields the client doesn't need, missing rate limiting allowing data scraping, no encryption at rest for sensitive data.
+
+## Output: `threat_model.md`
+
+You MUST write the completed threat model to `threat_model.md` in the project root. If the file already exists, update it in place rather than overwriting unrelated sections.
+
+`threat_model.md` is a **project-level security reference document**, not a tracker. It describes the system, its security-relevant architecture, and the guarantees it must uphold. Another agent will read this file to inform its security decisions -- write it for that audience.
+
+Use the following structure:
+
+```markdown
+# Threat Model
+
+## Project Overview
+
+Brief description of what the application does, its tech stack, and its users.
+
+## Assets
+
+What is worth protecting in this project. Describe each asset category and why it matters.
+
+## Trust Boundaries
+
+Where data crosses between different trust levels. Describe each boundary and what it separates.
+
+## Scan Anchors
+
+A short list of reusable pointers for future security analysis:
+- Production entry points, preferably with concrete file or directory paths when known
+- Highest-risk code areas, preferably with concrete packages, route files, or service directories when known
+- Public vs authenticated vs admin surfaces
+- Dev-only areas that should usually be ignored unless proven reachable in production
+
+Keep this section brief. It should store just enough concrete context to speed up future security scans without turning the threat model into a full repo inventory.
+
+If project context already exists in `replit.md` (project README) or `.agents/memory/` (agent memory), don't repeat the same information.
+
+## Threat Categories
+
+For each STRIDE category that is relevant to this project, write a short narrative:
+- What the threat is in the context of this specific project
+- Why it matters here (what could go wrong)
+- What guarantees are required to address it
+
+Omit categories that genuinely do not apply. Do not pad with generic boilerplate.
+```
+
+### Example: E-commerce App
+
+```markdown
+# Threat Model
+
+## Project Overview
+
+A Node.js/Express e-commerce application with a React frontend, PostgreSQL database,
+and Stripe integration for payments. Users can browse products, create accounts,
+and purchase items. Deployed on Replit with Replit Auth for user authentication.
+
+## Assets
+
+- **User accounts and sessions** -- email addresses, hashed passwords, session tokens.
+  Compromise allows impersonation and access to order history and saved payment methods.
+- **Payment data** -- Stripe customer IDs and tokenized payment references. The app never
+  stores raw card numbers, but Stripe tokens could be used to initiate charges.
+- **Order data** -- order history, shipping addresses, item quantities and prices.
+  Contains PII and business-sensitive pricing information.
+- **Application secrets** -- Stripe API keys, database connection string, session signing key.
+  Compromise of Stripe secret key allows arbitrary charges.
+
+## Trust Boundaries
+
+- **Browser to API** -- all client requests cross this boundary. The API must authenticate
+  and authorize every request; the client is untrusted.
+- **API to PostgreSQL** -- the API server has direct database access. SQL injection at the
+  API layer would give an attacker full database access.
+- **API to Stripe** -- the server calls Stripe's API with a secret key. SSRF or key leakage
+  would allow unauthorized payment operations.
+- **Authenticated to Unauthenticated** -- product browsing is public; cart, checkout, and
+  account pages require authentication. The boundary must be enforced server-side.
+
+## Threat Categories
+
+### Spoofing
+
+Users authenticate via Replit Auth. The application must validate the authentication
+token on every request to protected endpoints. Session tokens must be unpredictable
+and expire within a reasonable window. Webhooks from Stripe must be verified using
+Stripe's webhook signature mechanism.
+
+### Tampering
+
+Product prices and order totals must be calculated server-side. The client sends a cart
+(product IDs and quantities) but the server must look up current prices from the database.
+Accepting client-supplied prices would allow purchasing items for arbitrary amount(s).
+
+### Information Disclosure
+
+API responses for order history must be scoped to the authenticated user. The /api/orders
+endpoint must filter by user ID server-side. Error responses must not include stack traces
+or database error details. Stripe API keys must never appear in client-side code or logs.
+
+### Elevation of Privilege
+
+Admin routes (product management, order fulfillment) must check for an admin role
+server-side. All database queries must use parameterized statements to prevent SQL
+injection. File upload endpoints (product images) must validate file type and size.
+```
+
+### Key Principles
+
+- Be specific to the project. Generic boilerplate like "use HTTPS" is not useful unless the project is actually missing it.
+- Write declaratively. Describe what the system is, what its threats are, and what guarantees it requires.
+- Omit irrelevant categories. If the project has no file uploads, do not write about file upload threats.
+- Keep it concise. This is a reference document, not an essay. A smart agent will reason from it.
+- Keep `## Scan Anchors` brief. It should speed up future security scans without turning the threat model into a repo inventory.

package/.local/skills/validation/.fingerprint

@@ -0,0 +1 @@
+eda281a9956f805e23eebe19fcf07b67

package/.local/skills/validation/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: validation
+description: Register shell commands as named validation steps (like CI checks) that can be triggered and monitored to verify code quality.
+---
+
+# Validation Skill
+
+Set up named validation commands (lint, test, typecheck, etc.) that act as repeatable CI-style checks for the project, then run and monitor them.
+
+## When to Use
+
+- After building new functionality or making significant changes
+- When setting up a project's quality gates for the first time
+- When the validation command for a check needs to change (e.g., new test framework)
+- To run validation commands and check their results
+- To monitor the status of ongoing or past validation runs
+
+## When NOT to Use
+
+- For one-off test runs — use the shell directly
+- For deploy workflows — use the deployment skill
+
+## Available Functions
+
+### setValidationCommand(name, command)
+
+Create or update a named validation command. If a validation with the same name already exists, it is silently updated (upsert behavior).
+
+**Parameters:**
+
+| Parameter | Type   | Description                                           |
+|-----------|--------|-------------------------------------------------------|
+| `name`    | string | Short lowercase identifier (e.g., `lint`, `test`)     |
+| `command` | string | Shell command to run for this validation               |
+
+**Returns:** `{ success: true, name: string, command: string }`
+
+**Example:**
+
+```javascript
+await setValidationCommand({ name: "lint", command: "npm run lint" });
+await setValidationCommand({ name: "test", command: "npm test" });
+```
+
+### clearValidationCommand(name)
+
+Remove a previously registered validation command.
+
+**Parameters:**
+
+| Parameter | Type   | Description                                      |
+|-----------|--------|--------------------------------------------------|
+| `name`    | string | Name of the validation command to remove          |
+
+**Returns:** `{ success: true, name: string }`
+
+**Example:**
+
+```javascript
+await clearValidationCommand({ name: "lint" });
+```
+
+### getValidationCommands()
+
+List all registered validation commands.
+
+**Parameters:** None
+
+**Returns:** `{ workflows: [{ name: string, tasks: [...], ... }] }`
+
+**Example:**
+
+```javascript
+const commands = await getValidationCommands();
+```
+
+### startValidationRun(commandIds)
+
+Start a validation run that executes one or more registered validation commands.
+
+**Parameters:**
+
+| Parameter    | Type     | Description                                          |
+|--------------|----------|------------------------------------------------------|
+| `commandIds` | string[] | List of validation command IDs to run                 |
+
+**Returns:**
+
+```json
+{
+  "runId": "run-abc123",
+  "status": "FAILED",
+  "commands": [
+    {
+      "commandId": "lint",
+      "shell": "npm run lint",
+      "status": "FAILED",
+      "exitCode": 1,
+      "errorMessage": "Exited with: 1",
+      "executionId": "exec-1",
+      "durationMs": 3200,
+      "logFilePath": "/tmp/validation/lint.log"
+    },
+    {
+      "commandId": "test",
+      "shell": "npm test",
+      "status": "PASSED",
+      "exitCode": 0,
+      "errorMessage": "",
+      "executionId": "exec-2",
+      "durationMs": 5100,
+      "logFilePath": "/tmp/validation/test.log"
+    }
+  ],
+  "durationMs": 8300,
+  "errorMessage": "",
+  "runSummary": "- `npm run lint` FAILED (exit code 1): ESLint reported ..."
+}
+```
+
+- `status` is one of: `"RUNNING"`, `"PASSED"`, `"FAILED"`, `"STOPPED"`, `"ERROR"`, `"TIMED_OUT"`
+- `runSummary` is an LLM-generated breakdown of the results with log line citations. Use it to understand what failed without reading full logs.
+- Each command includes `logFilePath` pointing to the full output log.
+
+**Example:**
+
+```javascript
+await setValidationCommand({ name: "lint", command: "npm run lint" });
+await setValidationCommand({ name: "test", command: "npm test" });
+const run = await startValidationRun({ commandIds: ["lint", "test"] });
+
+if (run.status !== "PASSED") {
+  // run.runSummary explains what failed and cites log lines
+  console.log(run.runSummary);
+
+  // Inspect individual commands
+  for (const cmd of run.commands) {
+    if (cmd.status !== "PASSED") {
+      console.log(`${cmd.shell} failed (exit ${cmd.exitCode}): ${cmd.errorMessage}`);
+      console.log(`Full log: ${cmd.logFilePath}`);
+    }
+  }
+}
+```
+
+### stopValidationRun(runId, graceful?)
+
+Stop a running validation run.
+
+**Parameters:**
+
+| Parameter  | Type    | Description                                       |
+|------------|---------|---------------------------------------------------|
+| `runId`    | string  | ID of the validation run to stop                   |
+| `graceful` | boolean | Whether to stop gracefully (default: `true`)       |
+
+**Returns:** `{ success: true, runId: string }`
+
+**Example:**
+
+```javascript
+await stopValidationRun({ runId: "run-abc123" });
+await stopValidationRun({ runId: "run-abc123", graceful: false });
+```
+
+### getValidationRun(runId)
+
+Get the status and details of a specific validation run, including per-command results.
+
+**Parameters:**
+
+| Parameter | Type   | Description                                      |
+|-----------|--------|--------------------------------------------------|
+| `runId`   | string | ID of the validation run to retrieve              |
+
+**Returns:** `{ validationRun: { id, status, startedAt, durationMs, commands: [...] } }`
+
+**Example:**
+
+```javascript
+const run = await getValidationRun({ runId: "run-abc123" });
+// run.validationRun.status is one of: "RUNNING", "PASSED", "FAILED", "STOPPED", "ERROR"
+```
+
+### getValidationRuns()
+
+Get all validation runs.
+
+**Parameters:** None
+
+**Returns:** `{ validationRuns: [{ id, status, startedAt, durationMs, commands: [...] }] }`
+
+**Example:**
+
+```javascript
+const runs = await getValidationRuns();
+```
+
+## Conventional Names and Commands
+
+Use short, lowercase names. Here are common conventions by stack:
+
+| Name        | Node.js              | Python                    | Go                  |
+|-------------|----------------------|---------------------------|---------------------|
+| `lint`      | `npm run lint`       | `ruff check .`            | `golangci-lint run` |
+| `test`      | `npm test`           | `pytest`                  | `go test ./...`     |
+| `typecheck` | `npx tsc --noEmit`   | `mypy .`                  | `go vet ./...`      |
+| `format`    | `npx prettier --check .` | `ruff format --check .` | `gofmt -l .`       |
+
+## Example Workflow
+
+After implementing a feature in a Node.js project:
+
+```javascript
+// Set up validation commands for the project
+await setValidationCommand({ name: "lint", command: "npm run lint" });
+await setValidationCommand({ name: "test", command: "npm test" });
+await setValidationCommand({ name: "typecheck", command: "npx tsc --noEmit" });
+
+// Run all validations (blocks until complete)
+const run = await startValidationRun({ commandIds: ["lint", "test", "typecheck"] });
+
+if (run.status !== "PASSED") {
+  // runSummary explains failures with log line citations
+  console.log(run.runSummary);
+
+  for (const cmd of run.commands) {
+    if (cmd.status !== "PASSED") {
+      console.log(`${cmd.shell} failed (exit ${cmd.exitCode}): ${cmd.errorMessage}`);
+      console.log(`Full log: ${cmd.logFilePath}`);
+    }
+  }
+}
+
+// Or fetch it again later by ID
+const result = await getValidationRun({ runId: run.runId });
+```

package/.local/skills/video-js/.fingerprint

@@ -0,0 +1 @@
+de0448bb03778da16bfe7ddb39dc134a