claude-code-session-manager 0.87.0 → 0.88.0

package/src/seed/prompts/debugging/reproduce-then-diagnose.md

@@ -1,8 +0,0 @@
----
-id: debugging/reproduce-then-diagnose
-title: Reproduce-then-diagnose this bug
-category: Debugging
-sendMode: paste
-description: Engages systematic-debugging skill — reliable repro first, then hypothesis-test, then fix.
----
-Engage the `systematic-debugging` skill on this bug: [paste symptom, stack trace, or repro steps]. Phase 1: get a reliable reproduction — the bug must trigger on demand, not "sometimes." Capture the minimum input that triggers it. Phase 2: state your hypothesis in one sentence and describe the observation that would refute it. Phase 3: run the observation. Phase 4: only after the hypothesis survives, propose a fix. Do not patch code until phase 4. If three hypotheses fail, stop and re-examine your assumptions from scratch.

package/src/seed/prompts/documentation/adr-from-change.md

@@ -1,8 +0,0 @@
----
-id: documentation/adr-from-change
-title: Architecture decision record from a recent change
-category: Documentation
-sendMode: paste
-description: Standard ADR (Context / Decision / Consequences) for a commit or PR; 200-400 words.
----
-Write an ADR (Architecture Decision Record) for the change in [commit hash / PR / file]. Use the standard ADR shape: Title, Status (Accepted), Context (what was the problem and the forces in play), Decision (what we chose and why, including the load-bearing constraints), Consequences (what gets easier, what gets harder, what we are now committed to). Cite specific file paths. Length target: 200-400 words. Place it in `docs/adr/NNNN-kebab-slug.md`.

package/src/seed/prompts/documentation/module-readme.md

@@ -1,8 +0,0 @@
----
-id: documentation/module-readme
-title: Write the README for this module
-category: Documentation
-sendMode: paste
-description: What+why, install snippet, 3 usage examples, full API table, limitations — under 300 lines.
----
-Generate a README for this module: [path]. Sections (in this order): one-paragraph what+why, install/import snippet, three usage examples covering the most common cases, the full public API as a table (name, signature, one-line description), configuration options if any, known limitations, and a link to deeper docs if they exist. Read the module to derive everything — do not invent features. Keep it under 300 lines.

package/src/seed/prompts/documentation/onboarding-plan.md

@@ -1,8 +0,0 @@
----
-id: documentation/onboarding-plan
-title: Onboarding plan for a new engineer
-category: Documentation
-sendMode: paste
-description: 30-min onboarding doc — load-bearing files, canonical commands, 3 non-obvious conventions, 3 footguns.
----
-A new engineer is joining this project tomorrow. Read the repo and produce a 30-minute onboarding doc: (1) what the system does in two paragraphs, (2) the 5-10 load-bearing files they must read first with one sentence each explaining why, (3) the canonical commands (build, test, dev, lint, typecheck) with one-line descriptions, (4) the 3 conventions that aren't obvious from the code (e.g., naming, error handling, IPC patterns), (5) the 3 footguns to avoid. No fluff.

package/src/seed/prompts/documentation/refresh-claude-md.md

@@ -1,8 +0,0 @@
----
-id: documentation/refresh-claude-md
-title: Refresh CLAUDE.md against current repo state
-category: Documentation
-sendMode: auto-fire
-description: Updates commands, paths, conventions, architecture notes; splits files past ~300 lines.
----
-Invoke the `refresh-claude-md` skill. Diff the current `CLAUDE.md` against the actual state of the repo: read `package.json` scripts, look for new top-level directories, check `git log --since="30 days ago"` for architectural shifts, scan for new tooling configs (eslint, vitest, playwright, etc.). Update commands, file paths, conventions, and architecture notes that have drifted. Split the file if it has grown past ~300 lines. Do not add filler; remove anything stale.

package/src/seed/prompts/documentation/tsdoc-public-exports.md

@@ -1,8 +0,0 @@
----
-id: documentation/tsdoc-public-exports
-title: TSDoc/JSDoc pass on public exports
-category: Documentation
-sendMode: auto-fire
-description: @param + @returns + @throws + @example for every exported symbol in src/.
----
-For every exported function, class, type, and constant in the `src/` public surface, add or update TSDoc comments. Required tags: one-line summary, `@param` per parameter with type semantics (not just "the name"), `@returns` describing the return shape including null/undefined cases, `@throws` for documented exceptions, `@example` for non-trivial APIs. Do NOT document trivial getters, internal helpers, or anything not exported. Match the project's existing TSDoc style if one exists.

package/src/seed/prompts/git-pr/conventional-commit.md

@@ -1,8 +0,0 @@
----
-id: git-pr/conventional-commit
-title: Write a Conventional Commit message for the staged diff
-category: Git / PR
-sendMode: auto-fire
-description: Picks correct type + scope from the diff; rejects multi-type diffs as a signal to split.
----
-Read the staged diff. Write a single Conventional Commit message with: type from {feat, fix, docs, style, refactor, perf, test, build, ci, chore}, optional scope in parens (the affected module or area), `!` before the colon if there is a breaking change, a ≤72-char subject in imperative mood, a blank line, and a body explaining the WHY (not the what — the diff shows the what). If the diff spans multiple types, that is a signal to split — tell me to split it rather than picking a wrong type.

package/src/seed/prompts/git-pr/draft-pr-title-body.md

@@ -1,8 +0,0 @@
----
-id: git-pr/draft-pr-title-body
-title: Draft a PR title + description from the branch
-category: Git / PR
-sendMode: auto-fire
-description: Reads main..HEAD; produces title + summary bullets + verifiable test plan checklist + risks.
----
-Run `git log main..HEAD` and `git diff main...HEAD`. Draft: (1) a Conventional-Commits-shaped PR title under 70 chars, (2) a Summary section with 2-4 bullets explaining what changed and why, (3) a Test plan section as a markdown checklist of items a reviewer can actually verify, (4) a "Risks / rollback" section if the diff touches anything load-bearing. Do not invent test coverage that does not exist — only list tests that are actually in the diff.

package/src/seed/prompts/git-pr/pre-commit-safety-sweep.md

@@ -1,8 +0,0 @@
----
-id: git-pr/pre-commit-safety-sweep
-title: Pre-commit safety sweep
-category: Git / PR
-sendMode: auto-fire
-description: Checks staged diff for secrets, debug code, commented-out blocks, unrelated changes — surface only, no auto-strip.
----
-Before committing, sweep the staged diff for: secrets (API keys, tokens, passwords, `.env` content), unrelated changes that should be in a different commit, debug code (`console.log`, `print`, `debugger`, `dbg!`), commented-out code blocks, TODO/FIXME added without an issue link, and any file over ~500 lines that should be split. Report each finding with `file:line — category — action (remove / move / keep with justification)`. Do not auto-strip — surface them and let me decide.

package/src/seed/prompts/git-pr/release-notes-block.md

@@ -1,8 +0,0 @@
----
-id: git-pr/release-notes-block
-title: Generate a release-notes block from commits
-category: Git / PR
-sendMode: auto-fire
-description: Groups commits since last tag by Conventional Commits type; rewrites subjects in user-facing past tense.
----
-Read `git log` since the previous tag. Group commits by Conventional-Commits type into sections: Features (feat), Fixes (fix), Performance (perf), Refactors (refactor), Docs (docs), Tests (test), Build/CI (build, ci, chore). One bullet per commit, rewritten from imperative-mood subject into past-tense user-facing language. Surface BREAKING CHANGES at the top in a dedicated section. Only emit emojis if the project's previous releases used them — otherwise plain section headers.

package/src/seed/prompts/git-pr/split-large-pr.md

@@ -1,8 +0,0 @@
----
-id: git-pr/split-large-pr
-title: Split a too-large PR into reviewable chunks
-category: Git / PR
-sendMode: paste
-description: Proposes 2-5 sequential PRs with scope, dependencies, and the git ops to create each branch.
----
-This branch is too big to review well. Read `git diff main...HEAD` and propose a split into 2-5 sequential PRs, each independently reviewable and independently shippable. For each proposed PR: title, scope (files), dependencies on prior PRs in the chain, and a one-sentence rationale. Then walk me through the actual git operations (cherry-pick or interactive-rebase plan) to create each branch. Do not execute destructive git commands — just produce the plan.

package/src/seed/prompts/performance/bundle-startup-audit.md

@@ -1,8 +0,0 @@
----
-id: performance/bundle-startup-audit
-title: Bundle size / startup time audit
-category: Performance
-sendMode: auto-fire
-description: Lists top 20 modules by size, duplicated deps, dev-only leaks, and synchronous imports over 50KB.
----
-Analyze the production bundle. Report: total gzipped size, top 20 modules by size with their import paths, any duplicated dependency versions, any dev-only dependency leaking into the prod bundle, and any synchronously-imported module over 50 KB that could be lazy-loaded. Suggest concrete `import()` boundaries and tree-shaking opportunities. Cite the entry file:line that pulls each heavy module.

package/src/seed/prompts/performance/complexity-audit.md

@@ -1,8 +0,0 @@
----
-id: performance/complexity-audit
-title: Complexity audit on hot data structures
-category: Performance
-sendMode: paste
-description: Flags every loop over user-scaled data with big-O analysis; proposes O(n) rewrites or justifies n.
----
-Identify every loop in this module that iterates over user-scaled data (collections whose size grows with user count, request count, or document size). For each, state the time and space complexity in big-O, flag any nested loop over user-scaled data as a complexity hazard, and propose either an O(n) rewrite, an index/Map lookup, or a justification that n is provably bounded. Do not touch loops over constant-sized data (e.g., HTTP methods, weekdays).

package/src/seed/prompts/performance/cpu-profile-hot-path.md

@@ -1,8 +0,0 @@
----
-id: performance/cpu-profile-hot-path
-title: Find the real hot path with a CPU profile
-category: Performance
-sendMode: paste
-description: Runs a sampling profiler, builds a flame graph, lists top 5 self-time + top 5 inclusive-time functions.
----
-Hand off to the `perf-profiler` subagent. Run the app under a sampling CPU profiler (`node --cpu-prof`, `0x`, or `clinic flame` depending on stack) while reproducing the slow scenario I describe: [scenario]. Produce a flame graph and report the top 5 functions by self-time and the top 5 by inclusive time. For each, cite file:line, explain why it is hot (algorithmic, I/O, serialization, etc.), and propose a fix. Do not optimize anything that is not in the top 10 — that is premature.

package/src/seed/prompts/performance/db-query-plan-review.md

@@ -1,8 +0,0 @@
----
-id: performance/db-query-plan-review
-title: Database query plan review
-category: Performance
-sendMode: paste
-description: Runs EXPLAIN ANALYZE on hot-path queries; flags missing indexes, N+1, and over-fetching.
----
-Find every SQL query or ORM call on the hot path I describe: [path]. For each, run `EXPLAIN ANALYZE` (or the ORM equivalent) and report: rows scanned vs rows returned, missing indexes (sequential scans on large tables), N+1 patterns where one query in a loop should be a single join or batched lookup, and queries returning more columns than the caller uses. Output as a table sorted by estimated cost.

package/src/seed/prompts/performance/memory-leak-hunt.md

@@ -1,8 +0,0 @@
----
-id: performance/memory-leak-hunt
-title: Memory leak hunt
-category: Performance
-sendMode: paste
-description: Snapshot-diffs after 100 iterations to find retained-size growers; pins fix with a regression test.
----
-Run the app, take a heap snapshot, exercise the suspected leak path 100 times, take a second snapshot, diff them. Report retained-size growers: type, count delta, top retainers in the dominator tree. For each candidate leak cite the file:line that allocates and the file:line that fails to release (missing `removeListener`, unbounded cache, closure capturing a large object, timer not cleared, etc.). Propose a fix and a regression test that snapshot-diffs over N iterations and asserts bounded growth.

package/src/seed/prompts/qa/api-contract-tests.md

@@ -1,8 +0,0 @@
----
-id: qa/api-contract-tests
-title: API contract test suite
-category: QA
-sendMode: paste
-description: Exercises happy path, 4xx, auth boundaries, rate limits, idempotency, and pagination for each endpoint.
----
-Engage the `playwright-api-testing` skill. For each public endpoint, write a request-context test that exercises: 200 happy path with schema validation, 4xx invalid input, 401/403 auth boundaries, 429 rate limit (if applicable), idempotency key replay returns identical body, and pagination correctness. Mock no internals — hit the real test server. Validate response bodies against the OpenAPI schema if one exists; otherwise pin the shape with a snapshot.

package/src/seed/prompts/qa/e2e-critical-path.md

@@ -1,8 +0,0 @@
----
-id: qa/e2e-critical-path
-title: E2E test for the critical user path
-category: QA
-sendMode: paste
-description: Writes a Playwright test using role/label locators with web-first assertions and no manual sleeps.
----
-Use the `playwright-e2e` skill to write a Playwright test for this user flow: [describe path]. Use role/label locators (`getByRole`, `getByLabel`, `getByTestId`) — no XPath, no long CSS chains. Rely on Playwright's auto-wait; do not insert `waitForTimeout` or manual sleeps. Use web-first assertions (`expect(locator).toBeVisible()`, etc.) so retries happen automatically. Each test must own its data setup and teardown — no shared state across tests.

package/src/seed/prompts/qa/failing-test-for-bug.md

@@ -1,8 +0,0 @@
----
-id: qa/failing-test-for-bug
-title: Generate a failing test that reproduces this bug
-category: QA
-sendMode: paste
-description: Pins the exact wrong behavior in a test before any fix, using the project's existing test runner.
----
-I have a bug: [describe symptom + steps to reproduce]. Before any fix, write a failing test that pins the exact wrong behavior. The test must fail today on `main` and pass once the bug is fixed. Use the project's existing test runner and the same file/folder convention as the nearest sibling tests. Run the test and paste the failure output so I can verify it reproduces.

package/src/seed/prompts/qa/find-missing-test-coverage.md

@@ -1,8 +0,0 @@
----
-id: qa/find-missing-test-coverage
-title: Find missing test coverage on the diff
-category: QA
-sendMode: auto-fire
-description: Lists untested error paths, branches, and public APIs in the staged diff, ranked by risk.
----
-Look at the staged diff. For every new or changed function, branch, and error path, check whether at least one test exercises it. List untested behaviors as a checklist with `file:line — behavior — suggested test name`. Prioritize: untested error paths and untested public API > untested branches > untested happy paths. Do not propose tests for trivial getters or for code that is purely delegating.

package/src/seed/prompts/qa/stabilize-flaky-test.md

@@ -1,8 +0,0 @@
----
-id: qa/stabilize-flaky-test
-title: Convert a Playwright test failure into a stable fix
-category: QA
-sendMode: paste
-description: Diagnoses a flaky test as real-bug / locator-timing / test-data-leak, then patches and re-runs 10x.
----
-This Playwright test is flaky / failing: [paste test name or path]. Use the `playwright-debug` skill — pull the trace, identify whether the failure is (a) a real bug, (b) a timing/locator issue, or (c) a test-data leak from another test. For (a) write a smaller reproducer and patch the app; for (b) replace the locator with a role/label/testid locator and rely on auto-wait; for (c) isolate the test's setup/teardown. Re-run 10 times in headed mode to confirm stability.

package/src/seed/prompts/qa/tdd-red-first.md

@@ -1,8 +0,0 @@
----
-id: qa/tdd-red-first
-title: TDD this feature, RED first
-category: QA
-sendMode: paste
-description: Forces the RED-GREEN-REFACTOR loop; stops after a confirmed failing test before any implementation.
----
-Engage the `test-driven-development` skill. We are adding the following feature: [describe behavior here]. Start in RED: write the smallest failing test that captures one observable behavior, run it, confirm it fails for the right reason (assertion failure, not setup error), and stop. Do not write implementation. Once I confirm RED, you will write the minimum implementation to reach GREEN, then refactor with the test still green. Never skip RED.

package/src/seed/prompts/qa/visual-regression-review.md

@@ -1,8 +0,0 @@
----
-id: qa/visual-regression-review
-title: Visual regression baseline + diff review
-category: QA
-sendMode: auto-fire
-description: Refreshes screenshot baselines, classifies diffs as intentional / flake / real regression.
----
-Use the `playwright-visual-testing` skill. Capture or refresh `toHaveScreenshot()` baselines for the primary routes, then run the suite. For any diff, classify as: (1) intentional UI change — update baseline, (2) flake — mask the dynamic region or wait for stable font load, (3) real regression — leave failing and open an issue. Disable animations and wait for `networkidle` before capture. Do not blindly update all baselines on a diff.

package/src/seed/prompts/qa/wcag-axe-scan.md

@@ -1,8 +0,0 @@
----
-id: qa/wcag-axe-scan
-title: WCAG 2.2 accessibility scan with axe-core
-category: QA
-sendMode: auto-fire
-description: Runs axe-core against every route, reports violations by WCAG criterion at A/AA levels.
----
-Invoke the `playwright-accessibility` skill. Run an axe-core scan against every route in the app, configured for WCAG 2.0/2.1/2.2 levels A and AA. Report findings as a table: severity, WCAG criterion (e.g., 1.4.3 Contrast, 2.4.7 Focus Visible, 2.5.8 Target Size which is new in 2.2), selector, fix. For "incomplete" items where axe could not be certain, list them separately and propose a manual check. Skip AAA unless the project explicitly targets it.

package/src/seed/prompts/refactoring/dead-code-sweep.md

@@ -1,8 +0,0 @@
----
-id: refactoring/dead-code-sweep
-title: Dead code sweep
-category: Refactoring
-sendMode: auto-fire
-description: Audits for unused exports/files/deps; verifies absence of dynamic references before proposing deletes.
----
-Audit the repo for unused exports, unused functions, unused files, unused dependencies, and unreachable branches. Use static analysis (`ts-prune`, `knip`, `depcheck`, or grep + import-graph). For each finding cite file:line and confirm it is genuinely unused by checking for: dynamic imports, string-based references, framework-magic auto-discovery, and re-exports through barrel files. Output a delete-list, then on my go-ahead remove them in a single commit titled `chore: remove dead code`.

package/src/seed/prompts/refactoring/extract-duplicated-pattern.md

@@ -1,8 +0,0 @@
----
-id: refactoring/extract-duplicated-pattern
-title: Extract a duplicated pattern into one place
-category: Refactoring
-sendMode: paste
-description: Consolidates 3+ implementations of the same idea; no speculative generality beyond current callers.
----
-Three or more sites in this repo implement [pattern, e.g., "is path inside $HOME", "atomic file write", "exponential backoff retry"]. Find every implementation with grep, compare them, identify the union of behaviors needed, and consolidate to one canonical implementation in a sensible location. Migrate all callers. Keep test coverage equivalent or better. Do not introduce a generic abstraction beyond what the existing call sites need — concrete duplication is fine; speculative generality is not.

package/src/seed/prompts/refactoring/modernize-legacy-file.md

@@ -1,8 +0,0 @@
----
-id: refactoring/modernize-legacy-file
-title: Modernize a legacy file without changing behavior
-category: Refactoring
-sendMode: paste
-description: callbacks→async/await, var→const, magic numbers, narrowed types — observable behavior unchanged.
----
-Refactor this file to current project conventions: [file path]. Constraints: do NOT change observable behavior, do NOT change the public API, do NOT change the test assertions. You MAY: replace callbacks with async/await, replace `var` with `const`/`let`, replace string concatenation with template literals, extract magic numbers, narrow types, replace try/catch with explicit error returns where the project does that elsewhere. After each commit, run the full test suite and confirm green before continuing.

package/src/seed/prompts/refactoring/reduce-cyclomatic-complexity.md

@@ -1,8 +0,0 @@
----
-id: refactoring/reduce-cyclomatic-complexity
-title: Reduce cyclomatic complexity on a hot function
-category: Refactoring
-sendMode: paste
-description: Early returns, guard clauses, small extractions — no new abstractions; preserves signature + tests.
----
-Hand off to the `refactorer` subagent. This function has too many nested conditionals: [name file:function]. Reduce cyclomatic complexity using early returns, guard clauses, lookup tables, and small extracted helpers — no new abstractions, no design patterns unless the situation actually calls for one. Keep the public signature identical and keep the existing test assertions passing unchanged. Report before/after complexity and line count.

package/src/seed/prompts/refactoring/tighten-module-boundaries.md

@@ -1,8 +0,0 @@
----
-id: refactoring/tighten-module-boundaries
-title: Tighten module boundaries
-category: Refactoring
-sendMode: paste
-description: Demotes single-use exports to module-private; moves test-only helpers to __test__.
----
-This module's public surface has grown organically: [name the module]. List every exported symbol. For each, classify: (a) used by 3+ external callers — keep public, (b) used by 1-2 external callers — consider inlining at the call site, (c) only used inside this module — make it module-private, (d) only used in tests — move to a `__test__` helper. Apply the demotions. Re-run typecheck and tests after each commit.

package/src/seed/prompts/security/authz-audit.md

@@ -1,8 +0,0 @@
----
-id: security/authz-audit
-title: Auth + authorization audit
-category: Security
-sendMode: paste
-description: Audits every authenticated route/middleware/IPC handler for broken access control (OWASP A01) and IDOR.
----
-Audit every authenticated route, middleware, and IPC handler in this repo for broken access control (OWASP A01) and identification/authentication failures (OWASP A07). For each endpoint or handler, state: who can call it, what authz check protects it, whether that check happens before any side effect, and whether the user-supplied identifier is ever trusted without rebinding to the session subject. Flag any TOCTOU windows, missing authorization on object IDs (IDOR), or auth checks that happen after a database write.

package/src/seed/prompts/security/crypto-correctness.md

@@ -1,8 +0,0 @@
----
-id: security/crypto-correctness
-title: Crypto + secret-handling correctness pass
-category: Security
-sendMode: paste
-description: Reviews crypto primitives, password hashing, JWT signing, and TLS config against OWASP A02.
----
-Find every use of crypto primitives, password hashing, JWT signing/verification, and TLS configuration in this repo. Check against OWASP A02 Cryptographic Failures: no MD5/SHA-1 for security, no ECB mode, no PBKDF2 with iteration counts under 600k, bcrypt cost factor ≥ 12, argon2id preferred over bcrypt for new code, JWTs verified with the algorithm pinned (no `alg: none` accepted), nonces never reused with AES-GCM, randomness from `crypto.randomBytes` not `Math.random`. Report file:line + category + suggested fix.

package/src/seed/prompts/security/cwe-top-25-hunt.md

@@ -1,8 +0,0 @@
----
-id: security/cwe-top-25-hunt
-title: Hunt for the CWE Top 25 in this directory
-category: Security
-sendMode: paste
-description: Sweeps the open directory against the 2024 CWE Top 25; adversarial self-verification before reporting.
----
-Hand this off to the `security-auditor` subagent. Sweep the directory I have open against the 2024 CWE Top 25 — prioritize CWE-79 (XSS), CWE-787 (out-of-bounds write), CWE-89 (SQL injection), CWE-352 (CSRF), CWE-22 (path traversal), CWE-78 (OS command injection), CWE-94 (code injection), CWE-918 (SSRF), and CWE-77 (command injection). For each hit, cite file:line, name the CWE, show a minimal reproducer or the exact attack input, and propose a patch. Do an adversarial verification pass on your own findings before reporting — drop any you cannot defend.

package/src/seed/prompts/security/dependency-audit.md

@@ -1,8 +0,0 @@
----
-id: security/dependency-audit
-title: Dependency audit with exploitability triage
-category: Security
-sendMode: auto-fire
-description: Runs npm audit and triages each advisory by whether the vulnerable path is actually reachable here.
----
-Run the `dependency-auditor` subagent. Execute `npm audit --json` (or the equivalent for this stack), then for every high/critical advisory determine whether the vulnerable code path is actually reachable from this application's entrypoints — most transitive advisories are not exploitable here. Group output as: (1) exploitable + needs immediate patch, (2) exploitable but mitigated by configuration, (3) not reachable, low priority, (4) needs human investigation. Cite the advisory ID, the dependent path (`npm ls`), and the proposed remediation (upgrade, override, or replace).

package/src/seed/prompts/security/ipc-boundary-hardening.md

@@ -1,8 +0,0 @@
----
-id: security/ipc-boundary-hardening
-title: IPC / cross-process boundary hardening
-category: Security
-sendMode: paste
-description: Audits every IPC handler for schema validation, path allowlists, URL scheme checks, and shell-safe argv.
----
-Audit every IPC handler, message-port listener, and main-to-renderer boundary in this repo. For each handler, verify: payload is validated by a schema before use; file paths are validated against an allowlist of roots (no `..` escapes, no symlink follows into denied dirs); URLs are scheme-checked before fetch; shell commands never pass user input through `shell: true`. Output a checklist per handler with PASS/FAIL/UNCLEAR and a one-line patch suggestion for each FAIL.

package/src/seed/prompts/security/owasp-top-10-staged-diff.md

@@ -1,8 +0,0 @@
----
-id: security/owasp-top-10-staged-diff
-title: Review staged diff for OWASP Top 10 issues
-category: Security
-sendMode: auto-fire
-description: Sweeps the staged diff against OWASP Top 10:2021 categories and reports findings as a severity table.
----
-Invoke the `security-review` skill on the currently staged diff. Walk OWASP Top 10:2021 in order (A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Vulnerable Components, A07 Auth Failures, A08 Software & Data Integrity, A09 Logging Failures, A10 SSRF) and report findings as a markdown table with columns: severity (critical/high/medium/low), OWASP category, file:line, one-sentence description, suggested fix. Skip categories with no findings rather than padding. Do not include style or naming nits — security only.

package/src/seed/prompts/security/secret-credential-scan.md

@@ -1,8 +0,0 @@
----
-id: security/secret-credential-scan
-title: Secret + credential scan with remediation plan
-category: Security
-sendMode: auto-fire
-description: Greps the tree for hardcoded secrets, checks git history, and orders rotate → redact → gitignore.
----
-Grep the working tree for hardcoded secrets — API keys, OAuth tokens, JWTs, private keys, database URLs with embedded passwords, and webhook signing secrets. Use both pattern matching (e.g., `sk-`, `xoxb-`, `AKIA`, `-----BEGIN`, `Bearer `) and entropy heuristics on string literals over 20 chars. For each finding report file:line, the secret type, whether it is in tracked git history (`git log -S`), and a remediation order: rotate first, then redact, then add to `.gitignore`/secret manager. Do not print the secret value in clear — show a masked prefix only.

package/web/README.md

@@ -1,41 +0,0 @@
-# web/ — the WEB PRESENCE partition
-
-This directory collects every producer of content displayed on **bilko.run**. It is one of the
-four partitions described in
-[`session-manager-operations/architecture/project-partition.md`](../session-manager-operations/architecture/project-partition.md)
-— PRD 1184 made this partition PHYSICAL so the boundary is visible in the tree, not just on
-paper.
-
-**The user-facing pages themselves are NOT here.** They live in `~/Projects/Bilko`, a sibling
-repo. This directory only holds the tooling that *produces* what Bilko serves:
-
-- `project-pages/` — renders a project's Home/Marketing/Feature/Architecture/Brief pages from a
-  saved component library + a summary JSON. Consumed by the `project-home-builder` agent
-  persona and by `src/main/lib/projectHomeAdminRoutes.cjs` (an Electron IPC handler that stays
-  in `src/main/` — it's DESKTOP HARNESS runtime that *calls* this WEB PRESENCE toolchain, not
-  part of it).
-- `manual/` — builds and captures figures for the Field Manual, the paid product sold at
-  bilko.run/manual. Source content lives in `session-manager-operations/manual/` (OPERATIONS
-  STATE, unmoved); output lands in `~/Projects/Bilko/data/manual/releases/`.
-- `remote-app/` — the phone-remote PWA, the live source of the bundle published at
-  `bilko.run/projects/session-manager/`.
-
-## Staged for extraction
-
-This directory is staged for a future `git subtree split --prefix=web` into its own repo. That
-split has NOT happened yet — this PRD only collected the partition under one path so the split
-becomes mechanical later. Before actually running it, the human still needs to decide:
-
-- **How the extracted repo reaches `src/main`'s IPC handlers.** `projectHomeAdminRoutes.cjs`
-  currently reads the `project-pages/renderer/dist/` and `project-pages/logic/dist/` bundles by
-  a relative path assuming both live in the same repo checkout. Once `web/` is a separate repo,
-  something has to publish those bundles somewhere the harness can still read them (a build
-  step that vendors them back in, a package dependency, a fetched artifact — undecided).
-- **Who then owns the npm `files` array entries.** `package.json`'s `files` array currently
-  lists `web/project-pages/render.cjs`, `web/project-pages/renderer/dist/`,
-  `web/project-pages/logic/dist/`, and `web/project-pages/validate-summary.cjs` directly. If
-  `web/` moves to its own repo, either the harness repo re-vendors those specific build outputs
-  before packing, or the split repo publishes them and the harness repo depends on that package
-  — undecided.
-- `web-remote/relay/` is dead code that was deliberately NOT moved here — it stays where it is
-  pending a separate decision on whether to delete it.