@minhduydev/mdpi 0.3.0

package/dist/template/.pi/skills/security-and-hardening/SKILL.md

@@ -0,0 +1,293 @@
+---
+name: security-and-hardening
+description: Use when auditing for security vulnerabilities, implementing auth/authz, handling secrets, or hardening against OWASP Top 10 — covers input validation, authentication, dependency auditing, and secure defaults
+---
+
+# Security & Hardening
+
+> **Replaces** "we'll add security later" with security-by-default patterns applied from the start
+
+## When to Use
+
+- Implementing authentication or authorization
+- Handling user input that touches databases, file systems, or external services
+- Reviewing code for security vulnerabilities
+- Running dependency audits or responding to CVE alerts
+- Deploying to production for the first time
+
+## When NOT to Use
+
+- Local-only developer tools with no network exposure
+- Throwaway prototypes that will never see user data
+- Performance optimization (that's a different skill)
+
+## Overview
+
+Security is a constraint, not a feature. It should be present by default and requires explicit justification to relax.
+
+**Core principle:** Validate all input. Authenticate all access. Encrypt all secrets. Audit all dependencies. Trust nothing from outside your process boundary.
+
+## Security Boundaries
+
+### Always
+
+- Validate and sanitize all user input at the boundary
+- Use parameterized queries (never string interpolation for SQL)
+- Hash passwords with bcrypt/scrypt/argon2 (never MD5/SHA for passwords)
+- Use HTTPS for all external communication
+- Store secrets in environment variables, never in code
+- Set secure defaults (CORS restrictive, CSP strict, cookies httpOnly+secure)
+
+### Ask First
+
+- Changing authentication mechanism or session handling
+- Adding new API endpoints that accept user data
+- Modifying CORS policy or CSP headers
+- Adding new third-party dependencies with network access
+- Storing new types of PII or sensitive data
+
+### Never
+
+- Commit secrets, API keys, or credentials to git
+- Disable CSRF protection
+- Use `eval()` or `Function()` with user input
+- Trust client-side validation as the only validation
+- Log sensitive data (passwords, tokens, PII)
+
+## OWASP Top 10 Patterns
+
+### 1. Injection (SQL, NoSQL, Command)
+
+```typescript
+// [ ] SQL Injection
+const user = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);
+
+// [x] Parameterized query
+const user = await db.query("SELECT * FROM users WHERE id = $1", [userId]);
+```
+
+```typescript
+// [ ] Command injection
+exec(`convert ${filename} output.png`);
+
+// [x] Safe argument passing
+execFile("convert", [filename, "output.png"]);
+```
+
+### 2. Broken Authentication
+
+```typescript
+// [x] Password hashing
+import bcrypt from "bcrypt";
+const hash = await bcrypt.hash(password, 12); // cost factor 12
+const valid = await bcrypt.compare(input, hash);
+
+// [x] Session management
+const session = {
+  httpOnly: true, // No JS access
+  secure: true, // HTTPS only
+  sameSite: "lax", // CSRF protection
+  maxAge: 3600, // 1 hour expiry
+};
+```
+
+### 3. Sensitive Data Exposure
+
+```typescript
+// [ ] Logging sensitive data
+console.log("User login:", { email, password });
+
+// [x] Redact sensitive fields
+console.log("User login:", { email, password: "[REDACTED]" });
+
+// [x] API response excludes internal fields
+function toPublicUser(user: DbUser): PublicUser {
+  const { passwordHash, internalId, ...publicFields } = user;
+  return publicFields;
+}
+```
+
+### 4. Broken Access Control
+
+```typescript
+// [ ] No authorization check
+app.get("/api/users/:id", async (req, res) => {
+  const user = await getUser(req.params.id);
+  res.json(user); // Any authenticated user can access any profile
+});
+
+// [x] Authorization check
+app.get("/api/users/:id", async (req, res) => {
+  const user = await getUser(req.params.id);
+  if (user.id !== req.auth.userId && !req.auth.isAdmin) {
+    return res.status(403).json({ error: "Forbidden" });
+  }
+  res.json(user);
+});
+```
+
+### 5. Security Misconfiguration
+
+```typescript
+// [x] Secure headers (use helmet for Express)
+import helmet from "helmet";
+app.use(helmet());
+
+// [x] CORS — restrictive by default
+app.use(
+  cors({
+    origin: ["https://myapp.com"], // Not '*'
+    methods: ["GET", "POST"],
+    credentials: true,
+  }),
+);
+
+// [x] CSP
+app.use(
+  helmet.contentSecurityPolicy({
+    directives: {
+      defaultSrc: ["'self'"],
+      scriptSrc: ["'self'"], // No 'unsafe-inline'
+      styleSrc: ["'self'", "'unsafe-inline'"], // Only if needed
+    },
+  }),
+);
+```
+
+## Input Validation Patterns
+
+```typescript
+import { z } from "zod";
+
+// [x] Validate at the boundary
+const createUserSchema = z.object({
+  name: z.string().min(1).max(100).trim(),
+  email: z.string().email().max(254),
+  age: z.number().int().min(0).max(150).optional(),
+});
+
+// [x] Reject unknown fields
+const input = createUserSchema.strict().parse(req.body);
+```
+
+| Input Type  | Validation                                   |
+| ----------- | -------------------------------------------- |
+| String      | Min/max length, regex pattern, trim          |
+| Number      | Min/max range, integer check                 |
+| Email       | Format validation, max 254 chars             |
+| URL         | Protocol whitelist (https only)              |
+| File upload | Type whitelist, max size, content validation |
+| Array       | Max length, item validation                  |
+
+## Dependency Audit
+
+### npm Audit Triage
+
+```bash
+# Run audit
+npm audit
+
+# Decision tree per vulnerability:
+# 1. Is it in production dependencies? (devDeps are lower priority)
+# 2. Is the vulnerability reachable in our usage?
+# 3. Is a patch available? → Update
+# 4. No patch? → Find alternative or add compensating control
+```
+
+| Severity | Action                | Timeline               |
+| -------- | --------------------- | ---------------------- |
+| Critical | Fix immediately       | Same day               |
+| High     | Fix in current sprint | Within 1 week          |
+| Medium   | Plan fix              | Within 1 month         |
+| Low      | Track and monitor     | Next convenient update |
+
+### Supply Chain Security
+
+- [ ] Use lockfile (`package-lock.json` / `pnpm-lock.yaml`) — commit it
+- [ ] Pin major versions in production dependencies
+- [ ] Review new dependencies before adding (check maintainers, download count, last update)
+- [ ] Enable Dependabot or Renovate for automated updates
+- [ ] Use `npm audit` or `pnpm audit` in CI pipeline
+
+## Secrets Management
+
+| Rule                      | Implementation                                   |
+| ------------------------- | ------------------------------------------------ |
+| Never in code             | Use `.env` files (gitignored) or secret managers |
+| Never in logs             | Redact before logging                            |
+| Never in URLs             | Use headers or body for tokens                   |
+| Rotate on exposure        | Immediate rotation + audit trail                 |
+| Different per environment | Staging keys ≠ production keys                   |
+| Least privilege           | Each secret grants minimum required access       |
+
+```bash
+# [x] .gitignore
+.env
+.env.local
+.env.*.local
+*.key
+*.pem
+```
+
+## Rate Limiting
+
+```typescript
+// [x] Basic rate limiting
+import rateLimit from "express-rate-limit";
+
+const limiter = rateLimit({
+  windowMs: 15 * 60 * 1000, // 15 minutes
+  max: 100, // 100 requests per window
+  standardHeaders: true,
+  legacyHeaders: false,
+  message: { error: "Too many requests, try again later" },
+});
+
+app.use("/api/", limiter);
+
+// [x] Stricter limit for auth endpoints
+const authLimiter = rateLimit({
+  windowMs: 15 * 60 * 1000,
+  max: 5, // 5 login attempts per 15 minutes
+});
+app.use("/api/auth/", authLimiter);
+```
+
+## Common Rationalizations
+
+| Excuse                             | Rebuttal                                                                      |
+| ---------------------------------- | ----------------------------------------------------------------------------- |
+| "It's an internal app"             | Internal apps get compromised too. Validate all input regardless.             |
+| "We'll add security before launch" | Security retrofit is 10x harder than building it in. Start now.               |
+| "Nobody will find this endpoint"   | Security through obscurity isn't security. Assume everything is discoverable. |
+| "The framework handles it"         | Frameworks have defaults, not guarantees. Verify your specific configuration. |
+| "This is just a prototype"         | Prototypes become production. Build secure habits from day one.               |
+| "The audit has too many warnings"  | Triage by severity. Critical/High first, Low can wait.                        |
+
+## Red Flags — STOP
+
+- String concatenation in SQL queries
+- Passwords stored in plaintext or MD5/SHA
+- API keys or secrets in source code
+- CORS set to `*` in production
+- No rate limiting on authentication endpoints
+- User input passed directly to `exec()`, `eval()`, or file system operations
+- Dependencies with known critical CVEs
+- No input validation at API boundaries
+
+## Verification
+
+- [ ] All user input validated with schemas at API boundaries
+- [ ] SQL queries use parameterized statements
+- [ ] Passwords hashed with bcrypt/scrypt/argon2 (cost ≥ 12)
+- [ ] No secrets in source code or logs
+- [ ] CORS, CSP, and security headers configured
+- [ ] `npm audit` shows no critical/high vulnerabilities
+- [ ] Rate limiting on authentication and sensitive endpoints
+- [ ] Authorization checks on all protected resources
+
+## See Also
+
+- **defense-in-depth** — Validation at every layer, not just the boundary
+- **api-and-interface-design** — Error responses that don't leak internals
+- **ci-cd-and-automation** — Running security checks in CI pipeline

package/dist/template/.pi/skills/security-and-hardening/references/security-checklist.md

@@ -0,0 +1,105 @@
+# Security Checklist
+
+Quick reference for web application security. Use alongside the `security-and-hardening` skill.
+
+## Threat Modeling (Start Here)
+
+Before reaching for controls, spend five minutes thinking like an attacker:
+
+- [ ] Trust boundaries mapped (requests, uploads, webhooks, third-party APIs, LLM output)
+- [ ] Assets named (credentials, PII, payment data, admin actions, money movement)
+- [ ] STRIDE run per boundary (Spoofing, Tampering, Repudiation, Info disclosure, DoS, Elevation)
+- [ ] Abuse cases written next to use cases ("how would I misuse this?")
+
+## Pre-Commit Checks
+
+- [ ] No secrets in code (`git diff --cached | grep -i "password\|secret\|api_key\|token"`)
+- [ ] `.gitignore` covers: `.env`, `.env.local`, `*.pem`, `*.key`
+- [ ] `.env.example` uses placeholder values (not real secrets)
+
+## Authentication
+
+- [ ] Passwords hashed with bcrypt (≥12 rounds), scrypt, or argon2
+- [ ] Session cookies: `httpOnly`, `secure`, `sameSite: 'lax'`
+- [ ] Session expiration configured
+- [ ] Rate limiting on login endpoint (≤10 attempts per 15 minutes)
+- [ ] Password reset tokens: time-limited (≤1 hour), single-use
+- [ ] Account lockout after repeated failures (optional, with notification)
+- [ ] MFA supported for sensitive operations
+
+## Authorization
+
+- [ ] Every protected endpoint checks authentication
+- [ ] Every resource access checks ownership/role (prevents IDOR)
+- [ ] Admin endpoints require admin role verification
+- [ ] API keys scoped to minimum necessary permissions
+- [ ] JWT tokens validated (signature, expiration, issuer)
+
+## Input Validation
+
+- [ ] All user input validated at system boundaries
+- [ ] Validation uses allowlists (not denylists)
+- [ ] String lengths constrained, numeric ranges validated
+- [ ] File uploads: type restricted, size limited, content verified
+- [ ] SQL queries parameterized (no string concatenation)
+- [ ] HTML output encoded (use framework auto-escaping)
+- [ ] URLs validated before redirect (prevent open redirect)
+- [ ] Server-side URL fetches allowlisted; private/reserved IPs blocked (prevent SSRF)
+
+## Security Headers
+
+```
+Content-Security-Policy: default-src 'self'; script-src 'self'
+Strict-Transport-Security: max-age=31536000; includeSubDomains
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: camera=(), microphone=(), geolocation=()
+```
+
+## CORS Configuration
+
+```typescript
+cors({
+  origin: ['https://yourdomain.com'],
+  credentials: true,
+  methods: ['GET', 'POST', 'PUT', 'PATCH', 'DELETE'],
+  allowedHeaders: ['Content-Type', 'Authorization'],
+})
+// NEVER: cors({ origin: '*' })
+```
+
+## AI / LLM Security
+
+- [ ] Model output treated as untrusted — never into `eval`/SQL/shell/`innerHTML`/file paths
+- [ ] Prompt injection assumed; permissions enforced in code, not in the system prompt
+- [ ] Secrets, cross-tenant data, and full system prompts kept out of context window
+- [ ] Tool/agent permissions scoped; destructive actions require confirmation
+- [ ] Token, rate, and recursion/loop limits set
+
+## OWASP Top 10 Quick Reference
+
+| # | Vulnerability | Prevention |
+|---|---|---|
+| 1 | Broken Access Control | Auth checks on every endpoint, ownership verification |
+| 2 | Cryptographic Failures | HTTPS, strong hashing, no secrets in code |
+| 3 | Injection | Parameterized queries, input validation |
+| 4 | Insecure Design | Threat modeling, spec-driven development |
+| 5 | Security Misconfiguration | Security headers, minimal permissions, audit deps |
+| 6 | Vulnerable Components | `npm audit`, keep deps updated |
+| 7 | Auth Failures | Strong passwords, rate limiting, session management |
+| 8 | Data Integrity Failures | Verify updates/dependencies, signed artifacts |
+| 9 | Logging Failures | Log security events, don't log secrets |
+| 10 | SSRF | Validate/allowlist URLs, restrict outbound requests |
+
+## OWASP Top 10 for LLMs
+
+| ID | Risk | Prevention |
+|---|---|---|
+| LLM01 | Prompt Injection | Enforce permissions in code, not system prompt |
+| LLM02 | Sensitive Info Disclosure | Keep secrets/PII out of prompts; filter outputs |
+| LLM03 | Supply Chain | Vet models, datasets, and plugins |
+| LLM05 | Improper Output Handling | Treat model output as untrusted |
+| LLM06 | Excessive Agency | Scope tool permissions; confirm destructive actions |
+| LLM07 | System Prompt Leakage | Assume prompt can leak; put no secrets in it |
+| LLM10 | Unbounded Consumption | Cap tokens, request rate, and loop depth |

package/dist/template/.pi/skills/shipping-and-launch/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: shipping-and-launch
+description: Guides final readiness checks, rollback planning, documentation, and release handoff. Use when preparing to merge, deploy, release, or declare a development branch complete.
+---
+
+# Shipping & Launch
+
+## Overview
+
+Shipping should be boring because risk was removed earlier. The ship phase verifies readiness, documents what changed, and makes rollback possible.
+
+Core principle: do not ship work that cannot be verified, explained, or rolled back.
+
+## When to Use
+
+- User says ship, merge, deploy, release, or finish.
+- Before closing tracked work as complete.
+- Before creating a PR or release notes.
+- After build/review/QA phases pass.
+
+## When NOT to Use
+
+- Work is still being implemented.
+- Critical review findings are open.
+- Verification cannot run and no user-approved exception exists.
+
+## Workflow
+
+1. Check worktree state and identify intended changes.
+2. Confirm spec/plan acceptance criteria are met.
+3. Run required verification or use a fresh valid verification stamp.
+4. Run phantom completion checks for stubs, placeholders, and disconnected wiring.
+5. Review security/secrets/configuration risk in the diff.
+6. Confirm docs/ADRs/changelog updates are sufficient.
+7. Define rollback path: revert commit, feature flag, migration rollback, or manual procedure.
+8. Present ship options when action is irreversible: PR, merge, deploy, hold.
+9. Record handoff/memory when useful.
+
+## Pre-Ship Checklist
+
+- Tests relevant to changed behavior pass.
+- Build/typecheck/lint pass or exceptions are documented.
+- No high-severity review findings remain.
+- No secrets or local-only paths in diff.
+- User-facing/API behavior is documented.
+- Rollback path is clear.
+- User approval exists for irreversible actions.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "Tests passed earlier" | Fresh changes require fresh evidence or a valid unchanged-state stamp. |
+| "Rollback is just git revert" | Migrations, flags, queues, and external state may need more. |
+| "Docs can wait" | Shipped behavior without docs becomes support debt. |
+| "Small release, no checklist" | Small releases still leak secrets and break config. |
+
+## Red Flags
+
+- Completion claim without verification evidence.
+- Unresolved P0/P1 findings.
+- No rollback plan for data or API changes.
+- Changelog omits user-visible behavior changes.
+- Deployment/merge attempted without explicit user approval.
+- Placeholder/stub patterns remain in modified code.
+
+## Verification
+
+- Verification commands and outputs are recorded.
+- Acceptance criteria are checked line-by-line.
+- Phantom completion scan is clean or exceptions are explained.
+- Rollback plan is documented.
+- Final action is approved when irreversible.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>shipping-and-launch</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Verification commands, acceptance audit, review status, rollback plan</evidence>
+  <artifacts>Changelog, PR, release notes, handoff, or none</artifacts>
+  <risks>Open findings, skipped checks, deployment risk, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Branch Completion
+
+`finishing-a-development-branch` was removed as a separate optional skill. Keep merge/PR/cleanup choices, release handoff, rollback planning, and completion evidence in this canonical shipping workflow.
+
+## Verification
+
+Before shipping:
+
+- [ ] Rollback procedure is documented and tested
+- [ ] Feature flags have kill switches configured
+- [ ] Monitoring dashboards show real-time data
+- [ ] Launch checklist items all have verification evidence
+- [ ] On-call team is briefed on the deployment
+- [ ] Staged rollout plan is documented (percentage, duration, abort criteria)

package/dist/template/.pi/skills/source-driven-development/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: source-driven-development
+description: Grounds implementation decisions in official docs, source code, and cited references. Use when using unfamiliar libraries, external APIs, framework behavior, or current ecosystem guidance.
+---
+
+# Source-Driven Development
+
+## Overview
+
+Framework guesses become bugs. Source-driven work verifies behavior against authoritative references before implementation.
+
+Core principle: cite the source for non-trivial external API decisions, or mark the decision as unverified.
+
+## When to Use
+
+- New or unfamiliar library/framework/API.
+- Version-specific behavior matters.
+- Choosing between packages or integration patterns.
+- Error suggests external API misuse.
+- User asks to research current best practice.
+
+## When NOT to Use
+
+- Pure local codebase questions; use code search/explore.
+- Stable project conventions already cover the behavior.
+- Trivial syntax you can verify from existing code.
+
+## Source Hierarchy
+
+1. Official docs, specs, release notes.
+2. Maintained source code and examples.
+3. Maintainer-authored articles.
+4. Community posts only when higher sources are absent.
+
+Higher-ranked sources win on conflicts.
+
+## Workflow
+
+1. State the question precisely.
+2. Check memory/local docs for prior decisions.
+3. Retrieve authoritative sources.
+4. Verify version compatibility with the project.
+5. Compare sources if guidance conflicts.
+6. Extract only the implementation-relevant facts.
+7. Cite URLs or source refs in the recommendation.
+8. Mark unresolved uncertainty explicitly.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "I know this API" | APIs change; verify version-specific behavior. |
+| "A blog said so" | Blogs lose to official docs/source. |
+| "The package name is obvious" | Similar packages differ in security and maintenance. |
+| "Citations slow us down" | A bad integration costs more than a source check. |
+
+## Red Flags
+
+- Unfamiliar API used without citation or local precedent.
+- Community answer conflicts with official docs.
+- Version in docs differs from package version.
+- Agent invents options, flags, or imports.
+- Research dump has no recommendation.
+
+## Verification
+
+- Key claims cite authoritative sources.
+- Project/library versions are considered.
+- Implementation recommendation is specific.
+- Unverified assumptions are labeled.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>source-driven-development</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Sources consulted and version checks</evidence>
+  <artifacts>Research notes, citations, implementation recommendation</artifacts>
+  <risks>Unverified claims, stale docs, conflicting sources, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Research Workflow
+
+This is the canonical active source-grounding skill. It absorbs deep-research and source-code-research for normal work. Use opensrc, webclaw, context7, grepsearch, or gemini-large-context as tool-specific companions only when the source demands them.
+
+Evidence hierarchy:
+1. local code and tests;
+2. official docs and source;
+3. maintained examples from reputable repos;
+4. blog posts or issues with dates and caveats.
+
+
+## Removed Optional Companion
+
+`v1-run` was removed as an optional package-health skill. Use source-grounded package evaluation, official advisories, lockfile inspection, and package-manager audit commands instead.
+
+## Verification
+
+After source-driven implementation:
+
+- [ ] Every framework API usage is verified against the installed version's docs
+- [ ] Documentation links are included in code comments for non-obvious patterns
+- [ ] Any unverified assumptions are explicitly flagged in the output
+- [ ] Third-party code (SO, LLM-generated) is cross-referenced with official docs
+- [ ] Version-specific behavior is noted (e.g., "Added in React 18.2")