create-issflow 1.0.2 → 1.1.0

package/template/.claude/skills/caveman/SKILL.md

@@ -1,39 +1,39 @@
----
-name: caveman
-description: >
-  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
-  filler, articles, and pleasantries while keeping full technical accuracy.
-  Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
----
-
-Respond terse like smart caveman. All technical substance stay. Only fluff die.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
-
-## Rules
-
-Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
-
-Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
-
-Pattern: `[thing] [action] [reason]. [next step].`
-
-Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
-Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
-
-### Examples
-
-**"Why React component re-render?"**
-
-> Inline obj prop -> new ref -> re-render. `useMemo`.
-
-**"Explain database connection pooling."**
-
-> Pool = reuse DB conn. Skip handshake -> fast under load.
-
-## Auto-Clarity Exception
-
-Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after.
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
+  filler, articles, and pleasantries while keeping full technical accuracy.
+  Use when user says "caveman mode", "talk like caveman", "use caveman",
+  "less tokens", "be brief", or invokes /caveman.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
+
+Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### Examples
+
+**"Why React component re-render?"**
+
+> Inline obj prop -> new ref -> re-render. `useMemo`.
+
+**"Explain database connection pooling."**
+
+> Pool = reuse DB conn. Skip handshake -> fast under load.
+
+## Auto-Clarity Exception
+
+Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after.

package/template/.claude/skills/code-standards/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: code-standards
+description: Code conventions & architecture cookbook — naming follows each language's OWN idiom (camelCase / snake_case / PascalCase as the language dictates, not one-size-fits-all), plus project structure and the architecture pattern (Feature-Based by default; layered / hexagonal / modular when they fit). Use when scaffolding a project, choosing an architecture, naming things, or reviewing code structure. Keywords: naming, convention, camelCase, snake_case, PascalCase, style guide, lint, format, prettier, eslint, architecture, feature-based, layered, hexagonal, clean architecture, folder structure, project structure, conventions.
+---
+
+# code-standards — conventions & architecture cookbook
+
+Caveman ULTRA mode. Consistency beats personal preference. Match the LANGUAGE'S
+idiom, not a favourite style. Read on demand: `references/naming.md`,
+`references/architecture.md`.
+
+## 1. Naming — follow the language, not a habit
+
+Use each language's OWN convention. Do NOT force `camelCase` everywhere.
+
+| Language | vars / functions | types / classes | constants | files |
+|----------|------------------|-----------------|-----------|-------|
+| JS / TS | `camelCase` | `PascalCase` | `UPPER_SNAKE` | `kebab-case` (or per framework) |
+| Python | `snake_case` | `PascalCase` | `UPPER_SNAKE` | `snake_case` |
+| Go | `camelCase`; exported → `PascalCase` | `PascalCase` | `MixedCaps` | `lowercase` / `snake` |
+| Rust | `snake_case` | `PascalCase` | `UPPER_SNAKE` | `snake_case` |
+| Java / Kotlin | `camelCase` | `PascalCase` | `UPPER_SNAKE` | `PascalCase` |
+| C# | `camelCase` locals, `PascalCase` members | `PascalCase` | `PascalCase` | `PascalCase` |
+| Ruby | `snake_case` | `PascalCase` | `SCREAMING_SNAKE` | `snake_case` |
+| SQL | `snake_case` | — | — | — |
+
+Names say what a thing IS; no non-standard abbreviations; booleans read as
+predicates (`isActive`, `has_items`). The project's declared style guide (PEP 8,
+Effective Go, Airbnb JS/TS, Rust style, Google Java…) is the tie-breaker.
+Details + edge cases → `references/naming.md`.
+
+## 2. Architecture — Feature-Based by default
+
+Default: **Feature-Based** (feature-sliced / vertical) — group code by FEATURE, not
+by technical layer. It matches the kit's vertical-slice loop: one slice ≈ one
+feature folder, front-to-back. Alternatives (declare the choice in OVERVIEW):
+
+- **Layered (n-tier)** — simple CRUD; controllers / services / repositories.
+- **Hexagonal / Clean** — domain-centric, dependencies point inward; complex domains.
+- **Modular monolith / DDD bounded contexts** — large apps trending toward services.
+
+Pick the SIMPLEST that fits; don't import enterprise patterns into a small app.
+Patterns, trade-offs, and folder layouts → `references/architecture.md`.
+
+## 3. Structure & enforcement
+
+- One consistent project structure that reflects the chosen architecture; declare it.
+- A formatter + linter is NOT optional and NOT a bikeshed: use the language's
+  STANDARD tool and let it decide — prettier/eslint, black/ruff, gofmt/golangci-lint,
+  rustfmt/clippy. CI fails on lint/format errors.
+
+## RETURN FORMAT
+
+```
+CODE-STANDARDS CHECK: <change>
+- naming: PASS | FAIL (<names that break the language idiom>)
+- architecture: conforms to <pattern> | DRIFT (<what drifted>)
+- structure: PASS | FAIL
+- lint / format: clean | <errors>
+- VERDICT: PASS | BLOCK
+```

package/template/.claude/skills/code-standards/references/architecture.md

@@ -0,0 +1,61 @@
+# Architecture patterns (pick the simplest that fits)
+
+Declare the chosen pattern in OVERVIEW. Default = **Feature-Based**. Don't import
+enterprise patterns into a small app; don't ship a big app as one flat folder.
+
+## Feature-Based (feature-sliced / vertical) — DEFAULT
+
+Group by FEATURE, not by technical layer. Each feature owns its UI, logic, data
+access, and tests — front-to-back. Matches the kit's vertical-slice loop (one slice
+≈ one feature).
+
+```
+src/
+  features/
+    auth/        { ui, api, model, hooks, auth.test }
+    billing/     { ui, api, model, billing.test }
+    dashboard/   { ... }
+  shared/        # cross-feature primitives (ui kit, lib, config)
+  app/           # composition root, routing, providers
+```
+- **Pros:** high cohesion, easy to find/change/delete a feature, scales with team.
+- **Watch:** keep `shared/` thin; features must not import each other's internals
+  (go through a public entry or `shared/`).
+- Frontend flavour: "Feature-Sliced Design". Backend flavour: a module per feature.
+
+## Layered (n-tier)
+
+```
+controllers/ → services/ → repositories/ → db
+```
+- **Use when:** straightforward CRUD, small team, shallow domain.
+- **Watch:** grows into a "fat service" tangle as features multiply; layers cut
+  ACROSS features so a change touches every layer.
+
+## Hexagonal / Ports & Adapters / Clean
+
+Domain at the centre; dependencies point INWARD. The domain knows nothing about the
+DB, framework, or transport — those are adapters behind ports (interfaces).
+- **Use when:** complex/long-lived business rules, many integrations, high testability
+  needs (domain tested with no infra).
+- **Watch:** ceremony/indirection — overkill for CRUD.
+
+## Modular monolith / DDD bounded contexts
+
+Independent modules with explicit boundaries + their own data ownership, in one
+deployable. Each bounded context is feature-based inside.
+- **Use when:** large app likely to split into services later; multiple teams.
+- **Watch:** enforce boundaries (no reaching into another module's tables/internals).
+
+## Choosing
+
+| Signal | Lean toward |
+|--------|-------------|
+| small CRUD, 1–2 devs | Layered or Feature-Based |
+| product app, growing features | **Feature-Based** |
+| rich domain rules, many integrations | Hexagonal / Clean |
+| large, multi-team, future services | Modular monolith / DDD |
+
+Cross-cutting (auth, logging, errors, config) lives in `shared/` regardless. The
+architecture is a phase-0 / planning decision — record it and the folder layout in
+OVERVIEW so every phase builds the same way.

package/template/.claude/skills/code-standards/references/naming.md

@@ -0,0 +1,60 @@
+# Naming conventions (per language)
+
+The golden rule: **follow the language's official style guide.** Below is the
+idiom + the canonical guide to defer to. When in doubt, run the language's
+formatter/linter — it encodes most of this.
+
+## Per language
+
+### JavaScript / TypeScript — Airbnb / Google / TS handbook
+- vars, functions, methods, object keys → `camelCase`
+- classes, types, interfaces, enums, React components → `PascalCase`
+- module-level constants / enum members → `UPPER_SNAKE_CASE`
+- files → `kebab-case` (or framework rule: React often `PascalCase.tsx`)
+- private (convention) → leading `_` only if the codebase already does; prefer `#private`
+- no Hungarian notation; interfaces are NOT prefixed with `I` in modern TS.
+
+### Python — PEP 8
+- vars, functions, methods, modules, packages → `snake_case`
+- classes, exceptions → `PascalCase`
+- constants → `UPPER_SNAKE_CASE`
+- "internal" → single leading `_`; name-mangled → `__` ; dunder reserved for Python.
+
+### Go — Effective Go
+- identifiers → `MixedCaps` / `camelCase`; **exported = capitalised** (`PascalCase`),
+  unexported = lowercase first letter. NO underscores in names.
+- acronyms stay all-caps: `userID`, `httpServer` → `HTTPServer`, `userURL`.
+- short, local names for short scopes (`i`, `r`, `buf`); longer for package API.
+
+### Rust — Rust style / rustfmt
+- vars, functions, modules, files → `snake_case`
+- types, traits, enums, enum variants → `PascalCase`
+- constants, statics → `UPPER_SNAKE_CASE`
+
+### Java / Kotlin — Google Java Style
+- vars, methods, params → `camelCase`; classes → `PascalCase`;
+  constants (`static final`) → `UPPER_SNAKE`; packages → `lowercase`.
+
+### C# — Microsoft guidelines
+- public members, methods, properties, types → `PascalCase`
+- locals + parameters → `camelCase`; interfaces prefixed `I` (`IService`);
+  private fields → `_camelCase` (common).
+
+### Ruby — Ruby Style Guide
+- methods, vars, symbols, files → `snake_case`; classes/modules → `PascalCase`;
+  constants → `SCREAMING_SNAKE_CASE`.
+
+### SQL
+- tables, columns → `snake_case`; tables usually plural (`users`); keywords UPPER (style).
+
+## Cross-language rules
+
+- **Say what it IS.** `userList` not `ul`; `elapsedMs` not `t`. No mystery abbreviations.
+- **Booleans are predicates** — `isActive`, `hasAccess`, `canEdit`, `should_retry`.
+- **Functions are verbs** (`fetchUser`, `parse_config`); **values are nouns**.
+- **Units in the name** when ambiguous — `timeoutMs`, `widthPx`, `priceCents`.
+- **Acronyms** — follow the language (Go: `ID`/`URL` all caps; TS: usually `Id`/`Url`
+  in camelCase members). Be consistent within the codebase.
+- **No type in the name** unless the language culture does it (avoid `strName`).
+
+The declared style guide in OVERVIEW wins any tie. Let the formatter enforce mechanics.

package/template/.claude/skills/grill-me/SKILL.md

@@ -1,10 +1,31 @@
----
-name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree.
----
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
+---
+name: grill-me
+description: Interviews the user relentlessly about a plan or design — one question at a time, resolving each branch of the decision tree — until you reach shared understanding. Use before committing to a plan or spec, when the user says "grill me", "grill this plan", "interrogate the design", "poke holes", "pressure-test this", or invokes /grill-me; or whenever a plan is ambiguous and needs hardening before work starts.
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+## Language
+
+Grill in the USER'S language. If they write Thai, ask in **natural Thai** — real
+spoken business/dev Thai, not stiff word-for-word translations of English questions.
+Keep technical terms in English where a Thai team naturally would (API, deploy,
+auth, token, schema…). Mix is fine. The goal is that a Thai founder feels they are
+talking to a sharp Thai tech lead, not a translated bot. Capture the answers
+faithfully (the nuance often lives in the Thai phrasing).
+
+## Depth & stop condition
+
+- **Stop on CONVERGENCE, not a fixed count.** Keep going until a full pass surfaces
+  no new material question or unresolved decision. Don't pad; don't cut early.
+- **5-whys depth, per branch.** When an answer is a symptom or a "what" with no
+  "why", drill that branch — ask "why" down it (up to ~5 levels) until you hit the
+  real need or constraint. This is per-answer depth, not a number of rounds.
+- **Two structured passes is the default** (used by `/overview`): round 1 = scope →
+  design-research → round 2 = research-informed re-grill. Research surfaces questions
+  round 1 couldn't. A *third* pass still finding material unknowns is a signal the
+  project is under-defined — flag that, don't loop. Configurable per project.

package/template/.claude/skills/karpathy-guidelines/SKILL.md

@@ -1,34 +1,34 @@
----
-name: karpathy-guidelines
-description: Coding and debugging discipline. Apply on every coding and debug task.
----
-
-# karpathy-guidelines
-
-Apply on every coding + debug task. Caveman ULTRA mode.
-
-## Coding
-- Smallest change that works. No speculative abstraction. No "while I'm here".
-- Make it run, then make it right, then make it fast — in that order.
-- One concern per change. If the diff does two things, split it.
-- Read before write — understand the existing code path before editing.
-- Name things for what they are. Delete dead code, don't comment it out.
-- Prefer boring, obvious solutions over clever ones.
-
-## Debugging
-- Reproduce first.
-- One hypothesis at a time. State it before changing anything.
-- Change one variable, observe, conclude. No shotgun edits.
-- Read the actual error and stack — top to bottom — before theorizing.
-- When stuck: the bug is somewhere you're sure it isn't. Check assumptions.
-- 3 failed attempts -> stop poking, go research.
-
-## Honesty
-- Don't claim it works until you ran it.
-- "I don't know yet" is valid — say it instead of guessing.
-- A failing test is information. Don't edit the test to hide it.
-- Surface uncertainty to the orchestrator; don't paper over it.
-
-## Verification
-- Every change gets run. Lint/typecheck/smoke at minimum.
-- The real test is written blind by test-author — your own run is just sanity.
+---
+name: karpathy-guidelines
+description: Engineering discipline for writing and debugging code — smallest change that works, one hypothesis at a time, no shotgun edits, run before claiming done. Use on every coding or debugging task: implementing a feature, fixing a bug, refactoring, or chasing a failing test. Keywords: code, implement, debug, fix, refactor, test failure, stack trace, error.
+---
+
+# karpathy-guidelines
+
+Apply on every coding + debug task. Caveman ULTRA mode.
+
+## Coding
+- Smallest change that works. No speculative abstraction. No "while I'm here".
+- Make it run, then make it right, then make it fast — in that order.
+- One concern per change. If the diff does two things, split it.
+- Read before write — understand the existing code path before editing.
+- Name things for what they are. Delete dead code, don't comment it out.
+- Prefer boring, obvious solutions over clever ones.
+
+## Debugging
+- Reproduce first.
+- One hypothesis at a time. State it before changing anything.
+- Change one variable, observe, conclude. No shotgun edits.
+- Read the actual error and stack — top to bottom — before theorizing.
+- When stuck: the bug is somewhere you're sure it isn't. Check assumptions.
+- 3 failed attempts -> stop poking, go research.
+
+## Honesty
+- Don't claim it works until you ran it.
+- "I don't know yet" is valid — say it instead of guessing.
+- A failing test is information. Don't edit the test to hide it.
+- Surface uncertainty to the orchestrator; don't paper over it.
+
+## Verification
+- Every change gets run. Lint/typecheck/smoke at minimum.
+- The real test is written blind by test-author — your own run is just sanity.

package/template/.claude/skills/security/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: security
+description: Secure SDLC cookbook — weaves security through the whole lifecycle: threat modeling at design, secure coding while building, SAST/SCA/secrets at build, DAST + pentest before deploy, and vulnerability management + security review after. Grounded in OWASP Top 10 (2025), OWASP ASVS 5.0 / WSTG, ISO/IEC 27001 & 25010, and SLSA. Use on any security-sensitive change (auth, authorization, secrets, crypto, input handling, file upload, external input), at design when threat-modeling a feature, and as the gate before a deploy phase closes. Keywords: security, secure sdlc, devsecops, threat model, STRIDE, auth, login, token, jwt, secret, password, crypto, encryption, injection, xss, sqli, ssrf, csrf, permission, authorization, vulnerability, CVE, dependency, SAST, DAST, SCA, pentest, deploy, audit, security review.
+---
+
+# security — Secure SDLC cookbook
+
+Caveman ULTRA mode. Security is not a phase — it runs through the WHOLE lifecycle
+(shift-left). It is a HARD gate (METHODOLOGY rule 11). A `BLOCK` verdict stops the phase.
+
+Read on demand: `references/threat-modeling.md` (design stage),
+`references/secure-coding.md` (implement stage), `references/pentest-checklist.md`
+(deploy stage), `references/standards.md` (ISO 27001 / 25010 / SLSA mapping).
+
+## Secure SDLC — security at every stage of the loop
+
+| Loop stage | Security practice | Output / gate |
+|------------|-------------------|----------------|
+| **design-research / plan** | **Threat modeling** (STRIDE), abuse cases, pick the **ASVS level** (L1/L2/L3) | threats + security acceptance criteria in PLAN |
+| **implement** | **Secure coding** — OWASP Top 10 rules, input validation, authz, crypto, secret handling | code that obeys `references/secure-coding.md` |
+| **build (CLOSE, every phase)** | **SAST** + **SCA** (dependency CVEs) + **secrets scan** | no high/critical → else BLOCK |
+| **test** | **DAST** + security/abuse test cases (test-author writes them blind) | no high/critical |
+| **pre-deploy** | **Pentest gate** (OWASP WSTG run) + **security review** of the diff | zero open high/critical → else BLOCK |
+| **operate** | **Vulnerability management** — SBOM + continuous CVE/SCA monitoring, re-research stale advisories | tracked; new criticals → new phase |
+
+## Per-stage checklist
+
+### Design — threat model first
+- STRIDE the feature (Spoofing, Tampering, Repudiation, Info disclosure, DoS,
+  Elevation). Mark trust boundaries + untrusted inputs. Write abuse cases as
+  negative acceptance criteria. Set the ASVS target (default **L2**).
+  → `references/threat-modeling.md`
+
+### Implement — secure coding (OWASP Top 10 2025)
+- A01 access control server-side, deny-by-default, no IDOR · A04 TLS + strong crypto,
+  no secrets in code · A05 parameterized queries + output encoding + allow-list input
+  · A07 safe auth/session/token · A09 log security events (no secrets) · A10 fail
+  safe, handle every error path. → `references/secure-coding.md`
+
+### Build — automated gates (run at every phase CLOSE)
+- **Secrets scan** clean · **SCA** no unpatched critical/high CVE (emit SBOM) ·
+  **SAST** no high/critical on changed code.
+
+### Test — dynamic + abuse
+- **DAST** on staging · security/abuse test cases asserted blind.
+
+### Pre-deploy — pentest gate + review (A03 supply chain, SLSA L2+)
+- Run the WSTG checklist; security-review the diff; sign artifacts (SLSA L2+).
+  → `references/pentest-checklist.md`
+
+### Operate — vulnerability management
+- Keep an SBOM; monitor dependencies for new CVEs; a new critical → open a
+  remediation phase. Promote findings to the shared KB (`/store-wisdom`).
+
+## RETURN FORMAT
+
+```
+SECURE SDLC CHECK: <change / phase / deploy>
+- stage: design | implement | build | test | pre-deploy | operate
+- threat model (design): done | n/a — top risks: <STRIDE hits>
+- secure coding: PASS | FAIL (<A0x gap>)
+- build gates: SCA <clean/CVEs> · secrets <clean/found> · SAST <clean/findings>
+- DAST/pentest (deploy): PASS | findings <high/critical count>
+- ASVS target: L1 | L2 | L3 -> PASS | gaps: <chapters>
+- VERDICT: PASS | BLOCK (phase cannot close)
+```
+
+Standards (current): OWASP Top 10 2025 · ASVS 5.0 · WSTG v4.2 · ISO/IEC 27001:2022 ·
+ISO/IEC 25010:2023 · SLSA v1.1. Sourced from
+`docs/research/design-security-standards-cookbook.md`.

package/template/.claude/skills/security/references/pentest-checklist.md

@@ -0,0 +1,46 @@
+# Pre-deploy pentest checklist (OWASP WSTG)
+
+Run before a deploy phase closes. Walk the WSTG categories below; for each finding,
+classify severity and map it back to an OWASP Top 10 2025 risk (A01–A10). Gate the
+deploy on zero open HIGH/CRITICAL findings. Methodology: PTES (7 phases) for depth,
+NIST SP 800-115 (5 phases) for the compliance artifact.
+
+> Scope first. Only test systems you are authorized to test. For a managed-infra app
+> this is your own app + your own staging environment — never third-party services.
+
+## Phases (NIST SP 800-115 / PTES condensed)
+1. **Plan / pre-engagement** — scope, rules of engagement, target = staging.
+2. **Information gathering** — tech stack, endpoints, headers, exposed config.
+3. **Vulnerability analysis** — run the WSTG categories below + automated DAST.
+4. **Exploitation (PoC)** — prove impact for each suspected issue (no destruction).
+5. **Reporting** — findings + severity + remediation; attach to the release record.
+
+## WSTG categories (check each → maps to Top 10)
+
+- **WSTG-INFO** Information Gathering — no version/debug/source leakage. (A02)
+- **WSTG-CONF** Configuration & Deployment — TLS config, HTTP methods, no debug
+  endpoints, security headers (CSP, HSTS, X-Content-Type-Options), CORS scoped. (A02)
+- **WSTG-IDNT** Identity Management — no account enumeration; safe registration/recovery. (A07)
+- **WSTG-AUTH** Authentication — credential transport over TLS, no default creds,
+  lockout / rate-limit, MFA where it matters. (A07)
+- **WSTG-AZON** Authorization — no privilege escalation, no IDOR; deny-by-default. (A01)
+- **WSTG-SESS** Session Management — secure/HttpOnly/SameSite cookies, fixation
+  resistance, CSRF protection, real logout. (A01/A07)
+- **WSTG-INPV** Input Validation — XSS, SQLi, SSRF, command injection, SSTI,
+  deserialization. (A05/A01)
+- **WSTG-BUSL** Business Logic — workflow abuse, race conditions, replay, upload
+  abuse, value/price tampering. (A06)
+- **WSTG-CLNT** Client-Side — DOM XSS, postMessage, clickjacking, CORS, web storage. (A05)
+- **WSTG-APIT** API Testing — authz per endpoint, rate limiting, mass assignment,
+  schema/pagination abuse (REST/GraphQL). (A01/A04)
+
+## Automated gates to run alongside
+- **Secrets scan** (e.g. TruffleHog/GitGuardian) — clean.
+- **SCA** (e.g. Snyk/Dependabot) — no unpatched critical/high CVE; SBOM emitted.
+- **SAST** (e.g. Semgrep/SonarQube) — no high/critical on changed code.
+- **DAST** (e.g. OWASP ZAP) against staging — no high/critical.
+
+## Gate
+Deploy proceeds only when every HIGH/CRITICAL finding is remediated OR explicitly
+risk-accepted (documented) AND a human security sign-off is recorded (this is a
+hard-stop — see METHODOLOGY → Autonomy).

package/template/.claude/skills/security/references/secure-coding.md

@@ -0,0 +1,50 @@
+# Secure coding (implement stage)
+
+Concrete rules the implementer follows while writing code. Grouped by OWASP Top 10
+2025 risk. Language-agnostic — apply the equivalent in your stack.
+
+## Input & injection (A05)
+- Parameterized queries / prepared statements — NEVER string-concatenate SQL.
+- Output-encode for the sink (HTML, attribute, JS, URL, shell) to stop XSS.
+- Allow-list validate every external input (type, length, range, format).
+- No `eval` / dynamic template from user input (SSTI); no unsafe deserialization.
+- Guard SSRF: validate/allow-list outbound URLs; block internal ranges.
+
+## Access control (A01)
+- Enforce authorization SERVER-SIDE on every route and every object access.
+- Deny-by-default; check ownership (no IDOR — don't trust an id from the client).
+- Never rely on hidden UI / client checks for security.
+
+## Auth, sessions, tokens (A07)
+- Hash passwords with argon2id / bcrypt (never plaintext / fast hashes).
+- Secure session cookies: `HttpOnly`, `Secure`, `SameSite`; rotate on login;
+  real server-side logout. Validate JWT signature + exp + aud; short-lived.
+- Rate-limit / lock out credential endpoints; MFA where it matters.
+
+## Crypto & secrets (A04)
+- TLS for all transport. Use vetted libraries + current algorithms (AES-GCM,
+  SHA-256+); no home-rolled crypto, no ECB, no MD5/SHA1 for security.
+- Secrets ONLY from env / a secret manager — never in code, config-in-repo,
+  prompts, or logs. Separate per environment; least privilege; rotate.
+
+## Errors, logging, exceptions (A09, A10)
+- Fail safe / closed; handle EVERY error path; never leak stack traces or
+  internal detail to the client.
+- Log security-relevant events (authn/authz failures, input rejections) WITHOUT
+  secrets or PII. Make logs tamper-evident where it matters.
+
+## Supply chain & integrity (A03, A08)
+- Pin dependency versions; pull from trusted registries; keep an SBOM.
+- Verify integrity of updates / CI artifacts; no insecure deserialization of
+  untrusted data.
+
+## Config (A02)
+- No debug endpoints, default credentials, or verbose errors in prod.
+- Set security headers (CSP, HSTS, X-Content-Type-Options); scope CORS tightly.
+
+## Self-check before handing off
+Map each touched area to its risk above; anything unmet → fix or flag to the
+`security` cookbook gate. The blind security/abuse tests will assert these.
+
+Reference: OWASP Top 10 2025, OWASP ASVS 5.0 (V2/V6/V7/V8/V11/V12/V14/V16),
+OWASP Cheat Sheet Series.

package/template/.claude/skills/security/references/standards.md

@@ -0,0 +1,60 @@
+# Standards mapping — ISO 27001 · ISO 25010 · SLSA
+
+Read on demand. The day-to-day gate is the OWASP cookbook in SKILL.md; this file is
+for when a project must speak in ISO / supply-chain terms (audits, compliance,
+regulated domains). Apply the depth your project actually needs — these are not all
+mandatory for every app.
+
+## ISO/IEC 27001:2022 — information security controls (Annex A)
+
+93 controls in 4 themes. For a software dev kit, the **Technological (A.8)** theme
+is the code/deploy-facing one; map your security work to it.
+
+| Theme | Controls | What it covers for us |
+|-------|----------|------------------------|
+| Organizational (A.5) | 37 | policies, supplier/cloud management, access policy, incident process |
+| People (A.6) | 8 | awareness, responsibilities, the human sign-off chain |
+| Physical (A.7) | 14 | facilities (mostly N/A for managed/cloud infra) |
+| **Technological (A.8)** | 34 | access control, crypto, secure dev, logging, monitoring, vuln mgmt, backup |
+
+Selection is risk-driven via a Statement of Applicability — pick the controls your
+risk profile warrants; document the choice. Map OWASP ASVS chapters → A.8 controls
+for dual compliance.
+
+## ISO/IEC 25010:2023 — product quality model (the "definition of done")
+
+9 characteristics. Use as a quality cookbook beyond just security — a phase is
+"done" when the relevant ones hold:
+
+1. **Functional Suitability** — correct, complete, appropriate (your acceptance tests).
+2. **Performance Efficiency** — time behavior, resource use, capacity.
+3. **Compatibility** — interoperability, coexistence.
+4. **Interaction Capability** — learnability, accessibility, UI quality (→ `ux-design`).
+5. **Reliability** — availability, fault tolerance, recoverability (→ OWASP A10).
+6. **Security** — confidentiality, integrity, authenticity, accountability,
+   non-repudiation (→ the OWASP cookbook + ASVS).
+7. **Maintainability** — modularity, reusability, analyzability, modifiability
+   (→ `karpathy-guidelines`).
+8. **Flexibility** — installability, adaptability, replaceability.
+9. **Safety** — operational constraint, fail-safe, hazard warning.
+
+> Note: 2023 renamed Usability → Interaction Capability and Portability → Flexibility,
+> and added Safety. The kit's other skills already cover #4, #6, #7.
+
+## SLSA v1.1 — supply-chain provenance (Build Track)
+
+| Level | Requirement |
+|-------|-------------|
+| L0 | no provenance (baseline) |
+| L1 | document how the artifact was built (provenance generated) |
+| **L2** | hosted, auditable build + signed, tamper-evident provenance |
+| L3 | isolated, hardened build; cryptographically signed; full chain of custody |
+
+Target **L2+** for production releases: signed build + SBOM + provenance attached to
+the release record. Pairs with OWASP A03 (Software Supply Chain Failures) and the
+SCA gate.
+
+## Sources
+OWASP Top 10 2025 · ASVS 5.0 · WSTG v4.2 — owasp.org · ISO/IEC 25010:2023 /
+27001:2022 — iso.org · NIST SP 800-115 / 800-204D — nist.gov · SLSA v1.1 — slsa.dev.
+Full detail: `docs/research/design-security-standards-cookbook.md`.

package/template/.claude/skills/security/references/threat-modeling.md

@@ -0,0 +1,36 @@
+# Threat modeling (design stage)
+
+Do this when a phase touches a trust boundary: new input, auth/authz, data store,
+external service, file upload, money, or PII. Output = abuse cases written as
+NEGATIVE acceptance criteria in PLAN, so `test-author` can assert them blind.
+
+## 1. Sketch the data flow
+- Components, data stores, external services, and the **trust boundaries** between
+  them. Mark every place untrusted data crosses a boundary (the attack surface).
+
+## 2. STRIDE each element
+| Threat | Question | Mitigation direction |
+|--------|----------|----------------------|
+| **S**poofing | Can someone pretend to be another identity? | strong auth, MFA, signed tokens |
+| **T**ampering | Can data be altered in transit/at rest? | TLS, integrity checks, input validation |
+| **R**epudiation | Can an actor deny an action? | security logging, audit trail (no secrets) |
+| **I**nfo disclosure | Can data leak? | authz, encryption, least data, safe errors |
+| **D**enial of service | Can it be exhausted? | rate limits, quotas, timeouts |
+| **E**levation of privilege | Can a user gain more rights? | deny-by-default authz, no IDOR |
+
+## 3. Set the assurance level (OWASP ASVS)
+- **L1** baseline · **L2** default for most apps · **L3** finance/health/critical.
+- Record the target in OVERVIEW; the build/test gates verify to that level.
+
+## 4. Write abuse cases as negative acceptance criteria
+For each credible threat, add a criterion the tests must enforce, e.g.:
+- GIVEN a user A token WHEN requesting user B's resource THEN 403 (no IDOR).
+- GIVEN a login endpoint WHEN 10 bad attempts THEN lockout / rate-limit.
+- GIVEN an upload WHEN a non-allowed type/size THEN rejected, not stored.
+
+## 5. Feed it forward
+- Threats → secure-coding focus (`references/secure-coding.md`).
+- Abuse cases → the phase's acceptance criteria (planner) → blind tests.
+- Residual risks → logged; high ones → their own slice.
+
+Reference: OWASP Top 10 2025 (A06 Insecure Design), Microsoft STRIDE, OWASP ASVS 5.0.