├── public
    └── banner.png
├── slash-commands
    ├── short-tokens.md
    ├── refactor-code.md
    ├── plan-review.md
    ├── kill-port.md
    ├── component-cleanup.md
    ├── problem-analyzer.md
    ├── ask-codefetch.md
    ├── finalize-plan.md
    ├── create-plan.md
    ├── ask-gpt-pro.md
    ├── code-review-low.md
    ├── solidjs-rules.md
    ├── research-better-lib.md
    └── code-review-high.md
├── .gitignore
└── README.md


/public/banner.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/regenrek/slash-commands/HEAD/public/banner.png


--------------------------------------------------------------------------------
/slash-commands/short-tokens.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Minimize token usage in text while retaining all key information
 3 | argument-hint: TEXT=<text-to-shorten>
 4 | ---
 5 | 
 6 | <TEXT>
 7 | $TEXT
 8 | </TEXT>
 9 | 
10 | For the text: Minimize tokens. Trim aggressively for token savings; retain every key fact, figure, and conclusion, remove redundancy/filler. Avoid "**" Asterisx formatting. Reason: Every token consume space in agents token window and we want minize it


--------------------------------------------------------------------------------
/slash-commands/refactor-code.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Refactor code with a specific goal, keeping changes isolated
 3 | argument-hint: GOAL=<refactoring-goal-description>
 4 | ---
 5 | 
 6 | <refactoring_goal>
 7 | $GOAL
 8 | </refactoring_goal>
 9 | 
10 | Task: <refactoring_goal>
11 | 
12 | - Keep the commit isolated to this feature.
13 | - Document but do not fix unrelated problems you find.
14 | - Never add fallbacks/backward-compability/feature flags, we are always build the full new refactored solution.


--------------------------------------------------------------------------------
/slash-commands/plan-review.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Review a plan for completeness and alignment with codebase
 3 | argument-hint: PLAN=<plan-description>
 4 | ---
 5 | 
 6 | <plan>
 7 | $PLAN
 8 | </plan>
 9 | 
10 | review the current <plan />
11 | 
12 | - reflects the current codebase (files, patterns, constraints)
13 | - no fallbacks, no feature flags
14 | - full change or full refactor only; no "future use" leftovers
15 | - list code smells and caveats
16 | - clear scope and out of scope
17 | - performance, security, and privacy impact
18 | - decision: if the analysis indicates >90% satisfaction with the implementation, mark GREEN LIGHT
19 | 
20 | 
21 | 


--------------------------------------------------------------------------------
/slash-commands/kill-port.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Kill processes running on a specific port
 3 | argument-hint: PORT=<port-number>
 4 | ---
 5 | 
 6 | Kill processes on port(s): $PORT (default: 3000)
 7 | 
 8 | Steps:
 9 | 1. Identify process: lsof -ti:$PORT (macOS/Linux) or netstat -ano | findstr :$PORT (Windows)
10 | 2. Kill gracefully: kill $(lsof -ti:$PORT) then force: kill -9 $(lsof -ti:$PORT)
11 | 3. Windows: taskkill /PID $PID /F
12 | 4. Verify: lsof -ti:$PORT (should return nothing)
13 | 5. Warn about system processes, suggest service stops for critical services
14 | 
15 | macOS/Linux: lsof -ti:$PORT | xargs kill -9
16 | Windows: netstat -ano | findstr :$PORT then taskkill /PID $PID /F
17 | Alternative: sudo fuser -k $PORT/tcp (Linux)


--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
 1 | .ck
 2 | .spezi
 3 | .DS_STORE
 4 | # Node
 5 | node_modules/
 6 | npm-debug.log*
 7 | yarn-debug.log*
 8 | yarn-error.log*
 9 | .pnpm-debug.log*
10 | 
11 | # OS
12 | Thumbs.db
13 | ehthumbs.db
14 | Icon?
15 | .DS_Store
16 | .DS_Store?
17 | .DS_Store
18 | ._*
19 | .Spotlight-V100
20 | .Trashes
21 | 
22 | # Editor directories and settings
23 | .vscode/
24 | .idea/
25 | *.sublime-workspace
26 | *.sublime-project
27 | 
28 | # Dist and build
29 | dist/
30 | build/
31 | coverage/
32 | 
33 | # Environment files
34 | .env
35 | .env.*
36 | 
37 | # Misc
38 | *.log
39 | *.tgz
40 | *.swp
41 | *.bak
42 | *.tmp
43 | *.temp
44 | *.cache
45 | # local CLI/AI tools caches
46 | .cursor/
47 | .codex_cache/
48 | .claude/
49 | 
50 | # macOS
51 | *.DS_Store
52 | docs
53 | 


--------------------------------------------------------------------------------
/slash-commands/component-cleanup.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: SolidJS component size and structure rules for code cleanup
 3 | argument-hint: CODEFILES=<component-files-to-review>
 4 | ---
 5 | 
 6 | <CODEFILES>
 7 | $CODEFILES
 8 | </CODEFILES>
 9 | 
10 | # SolidJS Code Rules
11 | 
12 | ## 1. Component size and structure
13 | 
14 | - One main component per file (`.tsx`), file name matches component name.
15 | - Soft target: 150–250 LOC per component file (imports and types excluded).
16 | - Hard cap: 600 LOC per component file. If a file hits 400+ LOC, split it.
17 | - Move view-only chunks into small presentational components.
18 | - Move state/logic into custom hooks or utility functions instead of keeping it in the main component.
19 | - Avoid deeply nested JSX. If you nest more than 3 levels, extract a subcomponent.
20 | 


--------------------------------------------------------------------------------
/slash-commands/problem-analyzer.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Analyze a problem by locating affected files, root cause, and proposing minimal fixes
 3 | argument-hint: PROBLEM=<problem-description>
 4 | ---
 5 | 
 6 | <problem>
 7 | $PROBLEM
 8 | </problem>
 9 | 
10 | Tasks:
11 | 1) Locate all files/modules affected by the issue. List paths and why each is implicated.
12 | 2) Explain the root cause(s): what changed, how it propagates to the failure, and any environmental factors.
13 | 3) Propose the minimal, safe fix. Include code-level steps, side effects, and tests to add/update.
14 | 4) Flag any missing or outdated documentation/configs/schemas that should be updated or added (especially if code appears outdated vs. current behavior). Specify exact docs/sections to create or amend.
15 | 
16 | Output format:
17 | - Affected files:
18 |   - <path>: <reason>
19 | - Root cause:
20 |   - <concise explanation>
21 | - Proposed fix:
22 |   - <steps/patch outline>
23 |   - Tests:
24 | - Documentation gaps:
25 |   - <doc_section_what_to_update_add>
26 | - Open questions/assumptions:
27 |   - <items>
28 | 


--------------------------------------------------------------------------------
/slash-commands/ask-codefetch.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Gather narrowed codebase context using codefetch into a single markdown file
 3 | argument-hint: [PROMPT=<task-description>]
 4 | ---
 5 | 
 6 | # Ask Codefetch
 7 | 
 8 | Gather narrowed codebase context in one file.
 9 | 
10 | ## Workflow
11 | 
12 | 1. Research: identify relevant files/directories for PROMPT
13 | 2. Generate: run codefetch with scoped files → single .md
14 | 3. Read: use codefetch/codebase.md as context (not individual files)
15 | 
16 | ## Run
17 | 
18 | ```bash
19 | npx codefetch --max-tokens 50000 \
20 |   --output codefetch/codebase.md \
21 |   --token-encoder o200k \
22 |   --project-tree 3 \
23 |   --include-files "src/auth/**/*.ts,src/api/**/*.ts" \
24 |   --include-dir "src/utils"
25 | ```
26 | 
27 | Then read: codefetch/codebase.md
28 | 
29 | ## Options
30 | 
31 | Scope:
32 | - --include-files "pattern1,pattern2" (globs)
33 | - --include-dir "dir1,dir2"
34 | - --exclude-dir "test,dist"
35 | - --exclude-files "*.test.ts"
36 | - --exclude-markdown
37 | - -e .ts,.js (extension filter)
38 | 
39 | Tokens:
40 | - --max-tokens 50000
41 | - --project-tree 3 (0=none)
42 | - --token-encoder o200k
43 | 


--------------------------------------------------------------------------------
/slash-commands/finalize-plan.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Finalize a completed task with status summary and move to finished directory
 3 | argument-hint: TASK_FILE=<path-to-task.md>
 4 | ---
 5 | 
 6 | <task>
 7 | $TASK
 8 | </task>
 9 | 
10 | # Finalize Task / Plan (slash command)
11 | 
12 | Goal: close a task while keeping a lightweight summary for fast AI ingestion.
13 | 
14 | What to do (two artifacts):
15 | 1) Move the original task plan to `docs/tasks/finished/<XX>-DONE-<name>.md`.
16 |    - Add a one-line status at the top: `Status: Done — implemented on <YYYY-MM-DD>`.
17 |    - Add a pointer line: `Summary: see docs/tasks/summaries/<XX>-SOW-<name>.md`.
18 | 2) Create a short summary file at `docs/tasks/summaries/<XX>-SOW-<name>.md`.
19 |    - Include status, concise bullets of work delivered, tests/builds, and affected files.
20 |    - Add a pointer line back to the plan: `Plan: docs/tasks/finished/<XX>-DONE-<name>.md`.
21 | 
22 | Suggested prompt template:
23 | ```
24 | Status: Done — implemented on <YYYY-MM-DD>
25 | Summary of work delivered
26 | - <bullet 1>
27 | - <bullet 2>
28 | - <tests/builds run>
29 | - <notable decisions/constraints>
30 | Affected files
31 | - <path1>
32 | - <path2>
33 | - <path3>
34 | Follow-up
35 | - <optional next steps or “None”>
36 | Plan
37 | - docs/tasks/finished/<XX>-DONE-<name>.md
38 | ```
39 | 
40 | Guidelines:
41 | - Keep the summary minimal (token-friendly). Use repo-relative paths.
42 | - If tests/builds weren’t run, state why.
43 | - If anything intentionally left unchanged, note it in Summary or Follow-up.
44 | - Always ensure the two files cross-reference each other.
45 | 


--------------------------------------------------------------------------------
/slash-commands/create-plan.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Create a comprehensive task plan with context, success criteria, approach, and risks
 3 | argument-hint: TASK=<task-description-or-goal>
 4 | ---
 5 | 
 6 | <task>
 7 | $TASK
 8 | </task>
 9 | 
10 | # Create Plan (slash command)
11 | 
12 | Goal: draft a full task plan in `docs/tasks/todo/<XX>-<name>.md`.
13 | 
14 | Always do this first:
15 | - Read AGENTS.md and follow all rules/constraints.
16 | 
17 | Plan requirements (keep concise, but complete):
18 | - Context: 2–3 bullet recap of the problem/goal.
19 | - Success criteria / acceptance: bullet list with measurable checks.
20 | - Deliverables: code/docs/tests to produce.
21 | - Approach: ordered steps (no workarounds; sustainable, clean implementation).
22 | - Risks / unknowns: note dependencies, edge cases, perf/security concerns.
23 | - Testing & validation: what to run (unit/integration/e2e), data sets, platforms.
24 | - Rollback / escape hatches: brief note if applicable.
25 | - Owner / date: stamp with today’s date.
26 | 
27 | After writing the plan:
28 | - Save at path `docs/tasks/todo/<XX>-<name>.md`.
29 | - Ask the user: “What are the most important questions to confirm before implementation?” and list your top 3–5 clarifying questions.
30 | 
31 | Suggested prompt body:
32 | ```
33 | Context
34 | - ...
35 | - ...
36 | 
37 | Success criteria
38 | - ...
39 | 
40 | Deliverables
41 | - ...
42 | 
43 | Approach
44 | 1) ...
45 | 2) ...
46 | 3) ...
47 | 
48 | Risks / unknowns
49 | - ...
50 | 
51 | Testing & validation
52 | - ...
53 | 
54 | Rollback / escape hatch
55 | - ...
56 | 
57 | Owner/Date
58 | - <you> / <YYYY-MM-DD>
59 | ```
60 | 
61 | Reminder:
62 | - No workarounds or half measures; design for long-term maintainability.
63 | - If info is missing, include assumptions and surface them in the questions you ask the user at the end.
64 | 


--------------------------------------------------------------------------------
/slash-commands/ask-gpt-pro.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Quick codefetch workflow - run help first, then generate and open AI chat
 3 | argument-hint: [PROMPT=<path-to-prompt-file>]
 4 | ---
 5 | 
 6 | # Ask Codefetch Quick
 7 | 
 8 | Generate codebase with prompt file, copy to clipboard, open AI chat.
 9 | 
10 | ## Key Concepts
11 | 
12 | - **PROMPT** (`-p`): The task/question file (e.g., `docs/arch/02-decision.md`) - codefetch reads this file and includes it
13 | - **CODE FILES** (`--include-files`, `--include-dir`): Relevant source code for context
14 | - **MODEL**: Always use `gpt-5-1-pro` (default) - do NOT change to gpt-4o
15 | 
16 | ## Workflow
17 | 
18 | 1. **Identify PROMPT file**: The markdown file describing the task/question
19 | 2. **Identify CODE files**: Source files relevant to the prompt (crates, components, etc.)
20 | 3. **Run codefetch open**: Combines prompt + code → clipboard → browser
21 | 
22 | ## Example
23 | 
24 | ```bash
25 | # PROMPT = docs/arch/02-ask-architect-spezi-planr-decision.md
26 | # CODE = relevant crates for planning architecture
27 | 
28 | npx codefetch@latest open \
29 |   -p docs/arch/02-ask-architect-spezi-planr-decision.md \
30 |   --include-dir crates/spezi-orchestrator,crates/spezi-core \
31 |   --include-files "crates/spezi-engine/src/lib.rs" \
32 |   -t 2
33 | ```
34 | 
35 | ## Command Structure
36 | 
37 | ```bash
38 | npx codefetch@latest open \
39 |   -p <PROMPT_FILE>              # Task/question markdown file
40 |   --include-dir <dirs>          # Relevant code directories
41 |   --include-files <patterns>    # Specific code files
42 |   -t <depth>                    # Project tree depth (0-3)
43 |   --max-tokens 50000            # Token limit (optional)
44 | ```
45 | 
46 | ## Help Commands
47 | 
48 | ```bash
49 | npx codefetch --help
50 | npx codefetch open --help
51 | ```
52 | 
53 | ## Remember
54 | 
55 | - `-p` = PROMPT (the question/task file)
56 | - `--include-*` = CODE (context for the question)
57 | - Model = `gpt-5-1-pro` (never change this)


--------------------------------------------------------------------------------
/slash-commands/code-review-low.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Lightweight code review focusing on code smells, security, performance, and test coverage
 3 | argument-hint: TASK=<change-description>
 4 | ---
 5 | 
 6 | <task>
 7 | $TASK
 8 | </task>
 9 | 
10 | ## Role
11 | Senior engineer reviewing **only**: code smells, security, performance, and whether new tests are needed for the new feature.
12 | 
13 | ## Inputs
14 | - {CHANGE_SUMMARY}
15 | - {DIFF} + {FILES}
16 | - {CI_LOGS} {COVERAGE_SUMMARY} (optional)
17 | - {ENVIRONMENT} {API_SCHEMAS} {DB_MIGRATIONS} {DEPENDENCIES} (if relevant)
18 | 
19 | ## What to check
20 | ### Code Smells
21 | - Duplicates, long methods, deep nesting, dead code, unused imports
22 | - Leaky abstractions, tight coupling, improper layering
23 | - Edge cases: null, empty, timezones, encodings
24 | - Concurrency misuse and non-idempotent ops where required
25 | 
26 | ### Security
27 | - Secrets in code/logs; proper secret management
28 | - Input validation and output encoding; SQL/NoSQL/OS injection; XSS/CSRF
29 | - AuthN/AuthZ and multi-tenant boundaries
30 | - SSRF/XXE/path traversal/file upload validation
31 | - Crypto choices; TLS verification; CORS and security headers
32 | - Dependency CVEs and supply-chain risks; IaC/container misconfig
33 | 
34 | ### Performance
35 | - Time/space complexity; hot-path allocations; blocking I/O
36 | - N+1 queries; missing indexes; inefficient joins; full scans
37 | - Caching correctness and stampedes
38 | - Chatty network calls; batching; timeouts; backoff
39 | - Client bundle size and critical path (if UI)
40 | 
41 | ### Tests needed
42 | - Does new behavior have unit/integration/e2e tests
43 | - Edge cases, negative cases, concurrency/time-based cases
44 | - Minimal test plan to guard the change
45 | 
46 | ## Output format
47 | - **Summary**: what changed, top 1–3 risks, **Decision**: approve | request_changes | blocker
48 | - **Findings** grouped by **Smell | Security | Performance | Tests**
49 |   - `[severity] <title>`  
50 |     - Where: `<file:line-range>`  
51 |     - Impact: `<who/what is affected>`  
52 |     - Recommendation: `<smallest safe fix>`  
53 |     - Tests: `<tests to add/update>`
54 | - Cite exact files and line ranges. Keep code excerpts ≤20 lines.
55 | 
56 | ## Constraints
57 | - No full implementations. Pseudocode or patch outline only.
58 | - If data is missing, state the assumption and risk.


--------------------------------------------------------------------------------
/slash-commands/solidjs-rules.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Comprehensive SolidJS coding rules and best practices
 3 | argument-hint: CODE_REVIEW=<code-files-to-review>
 4 | ---
 5 | 
 6 | <CODE_REVIEW>
 7 | $CODE_REVIEW
 8 | </CODE_REVIEW>
 9 | 
10 | # SYSTEM: Solid + Ark UI rules (2025-11)
11 | Role: Senior SolidJS engineer  
12 | Stack: SolidJS + TS + Ark UI v5 / Park UI
13 | 
14 | ## 1. Folder model
15 | - `src/components/ui/styled/*` — Ark/Park UI wrappers, styling only  
16 | - `src/components/ui/*` — Reusable presentational (no API, no router)  
17 | - `src/components/panels/*`, `workbench/parts/*` — Feature containers (data, routing, actions)  
18 | - `src/workbench/stores/*` — Shared stores  
19 | Pure view = no API calls, no mutations, no router.
20 | 
21 | ## 2. Components
22 | - One main component per .tsx, filename = component name.  
23 | - Target <300 LOC, hard cap 750 (imports/types excluded).  
24 | - Max 3 JSX nesting levels.  
25 | - Split triggers: >2 visual sections, 3+ responsibilities, repeated JSX, big variant switch.
26 | 
27 | ## 3. Reactivity
28 | - Components run once.  
29 | - `createSignal` for local state, `createStore` for nested objects, Context for cross-cutting.  
30 | - Never destructure props — use `props.foo`.  
31 | - Reactive reads only in JSX / createEffect / createMemo / createResource / handlers.
32 | 
33 | ## 4. Control flow
34 | Use Solid helpers: `<Show>`, `<For>`, `<Switch>`/`<Match>`.  
35 | Avoid `.map()` in JSX; avoid raw `if` blocks around JSX.
36 | 
37 | ## 5. Async
38 | - `createResource` (or `@tanstack/solid-query`) for data fetching.  
39 | - Side effects in `createEffect`, cleanup with `onCleanup`.  
40 | - No side effects in component body.
41 | 
42 | ## 6. Props
43 | - Single `props` object, max 8 props (else use config object).  
44 | - Use `splitProps` for forwarding in reusable components.
45 | 
46 | ## 7. Ark UI v5 patterns
47 | - `asChild` is a function: `asChild={(merge) => <button {...merge({ class: cls })} />}`  
48 | - `onOpenChange` receives details object: `onOpenChange={d => setOpen(d.open)}`  
49 | - Popover: use `portalled`, wrap content in `Popover.Positioner`.  
50 | - Layering: `styled/*` → `ui/*` → `panels/*`.
51 | 
52 | ## 8. Splitting patterns
53 | Lists: Parent handles layout/loading/empty; child handles item.  
54 | Pages: Extract PageHeader, PageBody, PageEmptyState.  
55 | Forms: Container = schema + submit; many small field components.
56 | 
57 | ## 9. Linting
58 | ESLint + eslint-plugin-solid + Prettier. Lint errors = real bugs.
59 | 
60 | ## 10. Types
61 | - Never inline union types used in 2+ places — define once, import everywhere.  
62 | - Shared UI types (panel kinds, tab types, view modes) → `workbench/lib/*.ts` or co-located store.  
63 | - Domain types (API shapes, entities) → `src/lib/types.ts` or near related code.  
64 | - Export both nullable (`Type | null`) and required (`Exclude<Type, null>`) variants when needed.
65 | 
66 | ## 11. Config-driven variants
67 | No scattered if-chains with hardcoded strings. Define variants + behavior in one place:
68 | ```ts
69 | export const KINDS = ['a', 'b', 'c'] as const
70 | export type Kind = (typeof KINDS)[number]
71 | export const KIND_CONFIG: Record<Kind, { /* behavior props */ }> = { a: {}, b: {}, c: {} }
72 | // Usage: const cfg = KIND_CONFIG[kind]; cfg.doSomething && doSomething()
73 | ```
74 | Add/rename variant = update config once; TS catches stale refs.


--------------------------------------------------------------------------------
/slash-commands/research-better-lib.md:
--------------------------------------------------------------------------------
 1 | ---
 2 | description: Find a modern, faster JavaScript/TypeScript library alternative to a baseline library
 3 | argument-hint: BASELINE_LIB=<library> DOMAIN_USE_CASE=<use-case> CANDIDATE_LIBS=<lib1,lib2,...> [SCALE=<size>] [TOP_N=<number>]
 4 | ---
 5 | 
 6 | ## Problem statement
 7 | - Goal: Find a modern, faster JavaScript/TypeScript library for $DOMAIN_USE_CASE that outperforms $BASELINE_LIB in latency and bundle size while maintaining or improving relevance/quality.
 8 | - Context: Runs in Node 18+/browser, ESM‑first, TS types, no native deps; list size $SCALE; return $TOP_N suggestions per query.
 9 | - Note: If SCALE or TOP_N are not provided, defaults to "5k–50k items" and "top-3" respectively.
10 | 
11 | ## Success metrics (make these explicit)
12 | - P95 latency/query: target <1 ms at 10k items; <5 ms at 50k items (Node laptop). Adjust as needed.
13 | - Bundle size: <25 KB min+gzip for core (no heavy optional modules).
14 | - Quality: NDCG@5 (or task‑specific metric) ≥ $BASELINE_LIB on the same corpus (≥1.0x).
15 | - Features: multi‑field weights, typo tolerance, diacritics, highlight ranges, incremental updates.
16 | - DX: ESM, TS types, active maintenance (<6 months since last release), permissive license.
17 | 
18 | ## Scope and exclusions
19 | - In‑scope: in‑memory, client/Node libraries (no servers, no external indexes).
20 | - Out‑of‑scope: hosted/search servers unless used only for comparison; heavy NLP stacks unless used for query expansion (phase 2).
21 | 
22 | ## Concrete research question to post/search
23 | - "Which modern JS/TS libraries outperform $BASELINE_LIB for $DOMAIN_USE_CASE at $SCALE, with ESM, TS types, and <25 KB gzip bundle? Compare $CANDIDATE_LIBS by p95 latency, relevance (NDCG@5 or equivalent), bundle size, multi‑field weighting, and maintenance."
24 | 
25 | ## Search queries (copy/paste)
26 | - benchmark "$BASELINE_LIB" vs $CANDIDATE_LIBS js performance
27 | - "$CANDIDATE_LIBS vs $BASELINE_LIB" latency relevance "typescript" "esm"
28 | - "$CANDIDATE_LIBS" library benchmark $DOMAIN_USE_CASE
29 | - $CANDIDATE_LIBS benchmark bundle size "diacritics" "highlight"
30 | - $CANDIDATE_LIBS javascript benchmark "multi field"
31 | - $CANDIDATE_LIBS js benchmark in‑memory search
32 | 
33 | ## Shortlist to evaluate
34 | Evaluate the following candidate libraries: $CANDIDATE_LIBS
35 | 
36 | (Example for fuzzy name/description search: fuzzysort, quick‑score, FlexSearch, MiniSearch, Orama/Lyra, fast‑fuzzy, match‑sorter)
37 | 
38 | ## Minimal benchmark design
39 | - Dataset: 25k items with fields relevant to the task (e.g., name, description). Combine synthetic + real.
40 | - Queries: 100 mixed queries (typos, prefixes, mid‑word, camelCase splits, etc.).
41 | - Procedure: warm index; run 1k queries; record mean/p95; compute NDCG@5 (or task metric) vs hand‑labeled relevancy; measure min+gzip bundle.
42 | - Environments: Node 20, Chrome stable. Configs: defaults + one tuned weights (e.g., name:0.7, description:0.3).
43 | 
44 | ## Decision rubric
45 | - Must meet latency + bundle targets and maintain ≥ $BASELINE_LIB quality metric.
46 | - Prefer simple multi‑field API and highlight support.
47 | - Tie‑breaker: maintenance cadence, type safety, ESM‑first.
48 | 
49 | ## Deliverables
50 | - One‑page results table (latency, quality metric, size, features).
51 | - Example integration snippet for our "did‑you‑mean"/ranking path.
52 | - Recommendation + migration notes (config, weights).
53 | 
54 | ---
55 | 
56 | ## Example usage
57 | 
58 | Usage: `/prompts:research-better-lib BASELINE_LIB=Fuse.js DOMAIN_USE_CASE="fuzzy matching tool names + short descriptions (10–500 chars)" CANDIDATE_LIBS="fuzzysort, quick-score, FlexSearch, MiniSearch, Orama" SCALE="5k–50k items" TOP_N="top-3"`
59 | 
60 | **Resulting research question:**
61 | "Which modern JS/TS fuzzy search libraries outperform Fuse.js on 5k–50k items for fuzzy matching tool names + short descriptions (10–500 chars), with ESM, TS types, and <25 KB gzip bundle? Please compare fuzzysort, quick‑score, FlexSearch, MiniSearch, Orama by p95 latency, relevance (NDCG@5), bundle size, multi‑field weighting, and maintenance."
62 | 
63 | 


--------------------------------------------------------------------------------
/slash-commands/code-review-high.md:
--------------------------------------------------------------------------------
  1 | ---
  2 | description: Comprehensive high-level code review focusing on correctness, security, performance, and integration
  3 | argument-hint: TASK=<change-description>
  4 | ---
  5 | 
  6 | <task>
  7 | $TASK
  8 | </task>
  9 | 
 10 | <role>
 11 |   You are a senior software engineer, security reviewer, and performance specialist. Review the provided change with a focus on correctness, security, performance, integration, test quality, and long-term maintainability. Be precise, cite file paths and line ranges, and prioritize risks that could impact users, data, uptime, or developer velocity.
 12 | </role>
 13 | 
 14 | <objectives>
 15 | - Identify correctness defects, code smells, and anti-patterns.
 16 | - Surface exploitable security issues and data-protection risks.
 17 | - Spot performance/regression risks and complexity hotspots.
 18 | - Check integration points (APIs, events, DB, configs, CI/CD, infra) for compatibility and rollout safety.
 19 | - Assess tests for sufficiency, signal, reliability, and coverage.
 20 | - Recommend minimal, safe, high-leverage improvements and monitoring.
 21 | </objectives>
 22 | 
 23 | <severity_rubric>
 24 | - BLOCKER: Exploitable security flaw, data loss risk, broken build/deploy, user-impacting crash, irreversible migration risk, leaked secrets.
 25 | - HIGH: Likely prod incident or major regression; authz/auth gaps; significant perf degradation; schema incompatibility.
 26 | - MEDIUM: Correctness edge cases; non-exploitable but risky pattern; moderate perf concerns; flaky tests.
 27 | - LOW: Maintainability, readability, style, minor test gaps; suggestions.
 28 | - NIT: Optional polish.
 29 | </severity_rubric>
 30 | 
 31 | <tasks>
 32 | - Scope & Impact: Map all affected files/modules and why each is implicated. Note transitive and runtime impact (build, deploy, config, data).
 33 | - Root Cause / Risk Analysis: Explain the change intent, risks introduced, and any hidden assumptions or environmental dependencies.
 34 | - Security Review: Use the checklist below; escalate any secret exposure, injection, auth/authz flaws, SSRF/XXE/path traversal, insecure deserialization, command execution, mass assignment, CSRF/XSS, prototype pollution, weak crypto, missing TLS verification, permissive CORS, logging of secrets/PII, dependency vulns, or IaC/container misconfigurations.
 35 | - Performance Review: Identify complexity issues, N+1 queries, unbounded loops, memory churn/leaks, blocking I/O on hot paths, missing indexes, cache misuse, chatty network calls, unnecessary allocations/boxing, and concurrency contention.
 36 | - Integration Review: Validate API schema changes, versioning, backward/forward compatibility, idempotency, retries/timeouts/circuit breakers, feature-flag rollout, DB migrations (order/locking/rollback), message/event contracts, and config drift.
 37 | - Testing Review: Evaluate unit/integration/e2e tests, coverage, negative/property-based cases, concurrency/time-dependent tests, fixture health, determinism, and flakiness risk. Propose a targeted test plan.
 38 | - Observability & Operations: Check log levels, PII in logs, correlation/trace IDs, metrics and alerts, runbooks. Recommend what to monitor post-merge.
 39 | - Documentation & DX: Flag missing or outdated README/CHANGELOG/ADRs/API docs/config comments/schema diagrams. Note onboarding and maintenance friction.
 40 | - Minimal, Safe Fix: Propose the smallest viable change to eliminate blockers/high risks. Include tests and rollout/rollback steps.
 41 | </tasks>
 42 | 
 43 | <detailed_checklist>
 44 |   <category name="Correctness & Code Smells">
 45 | - Duplicate code / long methods / large classes / deep nesting.
 46 | - Leaky abstractions, tight coupling, poor cohesion, improper layering.
 47 | - Dead code, unused variables/imports, TODOs that should be addressed now.
 48 | - Non-idempotent operations where idempotency is required.
 49 | - Edge cases: null/empty/NaN/overflow/encoding/timezone/locale.
 50 | - Concurrency: shared state, race conditions, improper locking, async misuse.
 51 |   </category>
 52 | 
 53 |   <category name="Security">
 54 | - Secrets in code/logs/env/examples; credential handling, key rotation, KMS/secret manager usage.
 55 | - Input validation & output encoding; SQL/NoSQL/LDAP/OS injection; XSS (reflected/stored/DOM); CSRF.
 56 | - AuthN/AuthZ: broken access control, least privilege, multi-tenant boundaries, insecure direct object references.
 57 | - SSRF/XXE/path traversal/file upload validation; sandboxing for untrusted inputs.
 58 | - Crypto: algorithms, modes, IVs, nonces, randomness, key sizes, cert pinning/TLS verification.
 59 | - CORS/security headers (CSP/HSTS/X-Frame-Options/SameSite), cookie flags.
 60 | - Dependency & supply chain: pinned versions, known CVEs, pre/post-install scripts, integrity checks.
 61 | - IaC/Containers: public buckets, open security groups (0.0.0.0/0), missing encryption, root containers, mutable latest tags.
 62 | - Data protection & privacy: PII/PHI handling, minimization, retention, encryption at rest/in transit.
 63 |   </category>
 64 | 
 65 |   <category name="Performance">
 66 | - Time/space complexity, hot-path allocations, unnecessary synchronization.
 67 | - N+1 queries, missing DB indexes, inefficient joins, full scans, pagination vs. streaming.
 68 | - Caching: invalidation, eviction, key design, stampedes.
 69 | - Network patterns: chattiness, batching, compression, timeouts, backoff.
 70 | - Client-side perf (if UI): bundle size/regressions, critical path, images/fonts.
 71 |   </category>
 72 | 
 73 |   <category name="Integration & Rollout Safety">
 74 | - Backward/forward compatibility; versioned contracts; consumer-producer alignment.
 75 | - DB migrations: zero-downtime (expand/migrate/contract), locks, data backfills, rollback plan.
 76 | - Feature flags: default off, kill switch, gradual rollout, owner/expiry.
 77 | - Resilience: retries with jitter, timeouts, circuit breakers, idempotency keys.
 78 | - Config changes: validation, defaults, environment parity, secrets not in plain text.
 79 | - CI/CD: reproducibility, cache safety, test gates, artifact signing.
 80 |   </category>
 81 | 
 82 |   <category name="Testing & Quality Signals">
 83 | - Tests exist for new behavior and regressions; meaningful assertions.
 84 | - Coverage on critical branches/edge cases; mutation score (if available).
 85 | - Isolation: minimal mocking vs. over-mocking; flaky patterns (sleep-based timing, order reliance).
 86 | - Property-based/fuzz tests for parsers/validators/serializers.
 87 | - Load/soak tests where perf risk exists; snapshot tests stability (if UI).
 88 |   </category>
 89 | 
 90 |   <category name="Docs, Observability, Accessibility, i18n">
 91 | - README/CHANGELOG/ADR/API docs updated; code comments for non-obvious logic.
 92 | - Logs/metrics/traces with actionable context; PII redaction; alert thresholds.
 93 | - Accessibility (if UI): semantics, focus order, labels, contrast, keyboard nav, ARIA use.
 94 | - i18n/l10n: hard-coded strings, pluralization, date/time/number formats.
 95 |   </category>
 96 | </detailed_checklist>
 97 | 
 98 |   <output_requirements>
 99 |     <instructions>
100 | - Produce a concise but comprehensive report.
101 | - Group findings by category and severity.
102 | - Reference exact file paths and line ranges (e.g., src/foo/bar.py:120–147).
103 | - Include brief code excerpts only as necessary (≤20 lines per finding).
104 | - Prefer specific, minimal fixes and tests that maximize risk reduction.
105 | - If information is missing, state the assumption and its impact.
106 |     </instructions>
107 |   </output_requirements>
108 | 
109 |   <report_skeleton>
110 | - Summary:
111 |   - What changed: <concise overview>
112 |   - Top risks: <1-3 bullets>
113 |   - Approval: <approve|comment|request_changes|blocker>
114 | 
115 | - Affected files:
116 |   - <path> — <reason> (<added|modified|deleted>)
117 | 
118 | - Root cause & assumptions:
119 |   - <analysis>
120 |   - Assumptions: <items>
121 | 
122 | - Findings (repeat per finding):
123 |   - [<severity>] [<category>] <short title>
124 |     - Where: <file:line-range>
125 |     - Evidence: <brief snippet_trace>
126 |     - Impact: <what breaks_who is affected>
127 |     - Standards: <CWE/OWASP/Policy refs>
128 |     - Repro: <steps>
129 |     - Recommendation: <minimal fix>
130 |     - Tests: <tests to add_update>
131 | 
132 | - Performance:
133 |   - Hotspots: <items>
134 |   - Complexity notes: <items>
135 |   - Bench/Monitoring plan: <how to measure & watch>
136 | 
137 | - Integration:
138 |   - API/contracts: <compat/versioning/idempotency>
139 |   - DB migrations: <expand-migrate-contract, locks, rollback>
140 |   - Feature flags & rollout: <plan/kill switch_owner>
141 |   - Resilience: <timeouts/retries/circuits>
142 |   - Rollback plan: <how to revert safely>
143 | 
144 | - Testing:
145 |   - Coverage: <statements_branches_critical_paths>
146 |   - Gaps: <cases>
147 |   - Flakiness risks: <items>
148 |   - Targeted test plan: <Given_When_Then bullets>
149 | 
150 | - Docs & Observability:
151 |   - Docs to update/create: <paths/sections>
152 |   - Logs/Metrics/Traces/Alerts: <plan>
153 |   - Runbook: <updates>
154 | 
155 | - Open questions:
156 |   - <items>
157 | 
158 | - Final recommendation:
159 |   - Decision: <approve|comment|request_changes|blocker>
160 |   - Must-fix before merge: <items>
161 |   - Nice-to-have post-merge: <items>
162 |   - Confidence: <low|medium|high>
163 |   </report_skeleton>
164 | 
165 | <process_notes>
166 | - Prioritize BLOCKER/HIGH issues. If any are found, set approval to “blocker” or “request_changes”.
167 | - Favor minimal, safe changes and targeted tests over broad refactors (unless safety demands it).
168 | - If diff is very large, focus on high-risk/new code paths, public interfaces, security-critical modules, and hot paths.
169 | - Reference concrete files/lines. Keep code excerpts minimal (≤20 lines). Do not rewrite large code blocks.
170 | - If required inputs are missing (e.g., DB migration script or API schema), flag as a risk and propose what is needed.
171 | </process_notes>
172 | 
173 | <constraints>
174 | - DO NOT write or generate full code implementations in this review. Provide patch outlines, pseudocode, or stepwise instructions only.
175 | - Maintain confidentiality: if a secret or sensitive data appears, describe it without reproducing it verbatim.
176 | </constraints>
177 | 
178 | <success_criteria>
179 | - Findings are specific, actionable, and ordered by severity and blast radius.
180 | - Every high-risk change has a minimal fix and a concrete test/monitoring plan.
181 | - Output follows the provided report skeleton (markdown text only).
182 | </success_criteria>
183 | 
184 | <reminder>DON'T CODE YET.</reminder>
185 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | # Slash Commands Collection
  2 | 
  3 | <div align="center">
  4 |   <img src="public/banner.png" alt="Slash Commands" width="100%" />
  5 | </div>
  6 | 
  7 | A curated collection of AI-powered slash commands for code review, problem analysis, and refactoring workflows.
  8 | 
  9 | ## Quick Reference
 10 | 
 11 | 📝 `/create-plan` - Create comprehensive task plans  
 12 | 📋 `/plan-review` - Review implementation plans  
 13 | ✅ `/finalize-plan` - Finalize completed tasks  
 14 | 🔍 `/code-review-low` - Fast code review  
 15 | 🔬 `/code-review-high` - Thorough code review  
 16 | 🐛 `/problem-analyzer` - Identify bugs and affected files  
 17 | ♻️ `/refactor-code` - Start refactoring workflows  
 18 | 🔌 `/kill-port` - Kill processes running on specific ports  
 19 | 🔎 `/research-better-lib` - Find modern, faster library alternatives  
 20 | 📦 `/ask-codefetch` - Gather codebase context into a single markdown file  
 21 | 🚀 `/ask-gpt-pro` - Generate codebase, copy to clipboard, and open AI chat  
 22 | ⚛️ `/solidjs-rules` - Comprehensive SolidJS coding rules  
 23 | 🧹 `/component-cleanup` - SolidJS component size and structure rules  
 24 | ✂️ `/short-tokens` - Minimize token usage while retaining key information  
 25 | 
 26 | ## Installation
 27 | 
 28 | ### Cursor
 29 | Copy the `.md` files from the `slash-commands/` directory into `.cursor/commands/` directory. Remove the `$1` parameters and XML wrapping tags when using in Cursor.
 30 | 
 31 | **Official docs**: [Cursor Slash Commands](https://cursor.com/docs/cli/reference/slash-commands)
 32 | 
 33 | ### Codex
 34 | Copy the `.md` files from the `slash-commands/` directory into `~/.codex/prompts/` directory. Restart Codex after installation for changes to take effect.
 35 | 
 36 | **Official docs**: [Codex Prompts](https://github.com/openai/codex/blob/main/docs/prompts.md)
 37 | 
 38 | ### Claude Code
 39 | Claude Code supports both project-specific and personal commands:
 40 | 
 41 | **Project commands** (shared with team):
 42 | ```bash
 43 | mkdir -p .claude/commands
 44 | # Copy the .md files to .claude/commands/
 45 | ```
 46 | 
 47 | **Personal commands** (available across all projects):
 48 | ```bash
 49 | mkdir -p ~/.claude/commands
 50 | # Copy the .md files to ~/.claude/commands/
 51 | ```
 52 | 
 53 | **Official docs**: [Claude Code Slash Commands](https://docs.claude.com/en/docs/claude-code/slash-commands)
 54 | 
 55 | ## Commands
 56 | 
 57 | ### 1. `create-plan`
 58 | Creates a comprehensive task plan with structured sections for context, success criteria, deliverables, approach, risks, and testing. Ensures plans follow best practices and include all necessary information before implementation.
 59 | 
 60 | **Features**:
 61 | - Structured plan template with all required sections
 62 | - Context and problem statement
 63 | - Measurable success criteria
 64 | - Clear deliverables and approach
 65 | - Risk assessment and testing strategy
 66 | - Cross-references to AGENTS.md for rules/constraints
 67 | 
 68 | **Usage**: `/create-plan TASK="<task-description-or-goal>"`
 69 | 
 70 | **Examples**:
 71 | ```
 72 | /prompts:create-plan TASK="Implement user authentication system"
 73 | 
 74 | /prompts:create-plan TASK="Refactor the payment processing module"
 75 | ```
 76 | 
 77 | ### 2. `plan-review`
 78 | Reviews implementation plans and provides a go/no-go decision for development. Evaluates:
 79 | - Codebase alignment and current patterns
 80 | - Scope clarity and completeness
 81 | - Performance, security, and privacy impact
 82 | - Code smells and potential caveats
 83 | 
 84 | **Usage**: `/plan-review "<your-plan>"`
 85 | 
 86 | **Examples**:
 87 | ```
 88 | /plan-review "We're planning to implement plan @task-x-new-cool-feature.md"
 89 | 
 90 | /plan-review "Here is the plan we want to implement: @my-plan.md"
 91 | ```
 92 | 
 93 | ### 3. `finalize-plan`
 94 | Finalizes a completed task by creating two artifacts: a finished plan file and a lightweight summary for fast AI ingestion. Maintains traceability while keeping summaries token-friendly.
 95 | 
 96 | **Features**:
 97 | - Moves task to finished directory with status
 98 | - Creates lightweight summary file (SOW - Summary of Work)
 99 | - Cross-references between plan and summary
100 | - Tracks affected files, tests, and decisions
101 | - Token-optimized for AI consumption
102 | 
103 | **Usage**: `/finalize-plan TASK_FILE="<path-to-task.md>"`
104 | 
105 | **Examples**:
106 | ```
107 | /prompts:finalize-plan TASK_FILE="docs/tasks/todo/01-user-auth.md"
108 | 
109 | /prompts:finalize-plan TASK_FILE="docs/tasks/todo/05-payment-refactor.md"
110 | ```
111 | 
112 | ### 4. `code-review-low` & `code-review-high`
113 | Comprehensive code review commands for post-implementation analysis.
114 | 
115 | **`code-review-low`**: Fast review focusing on critical issues
116 | - Code smells and security vulnerabilities
117 | - Performance bottlenecks
118 | - Essential test coverage
119 | 
120 | **`code-review-high`**: Thorough review with extended analysis
121 | - All `code-review-low` checks plus additional validations
122 | - Deeper security and performance analysis
123 | - Comprehensive test recommendations
124 | 
125 | **Usage**: `/code-review-low "<files/code/description to review>"`
126 | 
127 | **Examples**:
128 | 
129 | ```
130 | /code-review-low "my plan @task-x-cool-feature has been implemented check unstaged files for review"
131 | 
132 | /code-review-low "@auth.server.ts @auth.rs @auth.connector.ts"
133 | ```
134 | 
135 | ### 5. `problem-analyzer`
136 | Identifies bugs and maps affected files across the codebase. Provides:
137 | - Root cause analysis
138 | - File impact assessment
139 | - Minimal safe fix proposals
140 | - Documentation gap identification
141 | 
142 | **Usage**: `/problem-analyzer "<problem-description>"`
143 | 
144 | **Examples:**
145 | The Problem analyzer prompt works best when you add logs and a short problem description.
146 | 
147 | I ran this often with cheeta model to get a quick analysis and move over to gpt codex.
148 | 
149 | ```
150 | /problem-analyzer "the app won't compile. here are the logs <paste-logs>"
151 | 
152 | /problem-analyzer "we have a serious blocking bug in @user-form.ts and @user.service.ts"
153 | ```
154 | 
155 | ### 6. `refactor-code`
156 | Initiates refactoring workflows with clear scope and isolation:
157 | - Feature-specific refactoring
158 | - Commit isolation guidelines
159 | - Documentation of unrelated issues (without fixing)
160 | - No backward compatibility or feature flags
161 | 
162 | **Usage**: `/refactor-code "<refactoring-goal>"`
163 | 
164 | ```
165 | /refactor-code "here is our implementation plan @impl-plan lets start"
166 | ```
167 | 
168 | ### 7. `kill-port`
169 | Kills processes running on specified ports with OS-specific commands and safety checks:
170 | - Cross-platform support (macOS, Linux, Windows)
171 | - Process identification and verification
172 | - Safety warnings for system processes
173 | - Graceful shutdown recommendations
174 | 
175 | **Usage**: `/kill-port "<port-number(s)>"`
176 | 
177 | **Examples**:
178 | ```
179 | /kill-port "3000"
180 | 
181 | /kill-port "3000 8080 9000"
182 | ```
183 | 
184 | ### 8. `research-better-lib`
185 | A comprehensive template for evaluating alternatives to baseline libraries. Helps find modern, faster JavaScript/TypeScript libraries that outperform existing solutions in latency and bundle size while maintaining or improving relevance/quality.
186 | 
187 | **Features**:
188 | - Structured problem statement and success metrics
189 | - Search query templates for benchmarking
190 | - Candidate library shortlist evaluation
191 | - Minimal benchmark design guidelines
192 | - Decision rubric and deliverables checklist
193 | 
194 | **Usage**: `/research-better-lib "<baseline-library> <domain/use-case> <candidate-libraries>"`
195 | 
196 | **Examples**:
197 | ```
198 | /research-better-lib "Fuse.js fuzzy search fuzzysort quick-score FlexSearch MiniSearch"
199 | 
200 | /research-better-lib "lodash utility functions ramda remeda"
201 | ```
202 | 
203 | ### 9. `ask-codefetch`
204 | Gather narrowed codebase context using codefetch into a single markdown file. Research relevant files/directories, generate scoped context, and use the output file as context.
205 | 
206 | **Workflow**:
207 | 1. Research: identify relevant files/directories for the task
208 | 2. Generate: run codefetch with scoped files → single .md file
209 | 3. Read: use `codefetch/codebase.md` as context (not individual files)
210 | 
211 | **Features**:
212 | - Single consolidated markdown file output
213 | - Scoped file inclusion with globs and directories
214 | - Token limits and encoding options
215 | - Project tree visualization
216 | - Extension filtering and exclusion patterns
217 | 
218 | **Usage**: `/ask-codefetch [PROMPT="<task-description>"]`
219 | 
220 | **Examples**:
221 | ```bash
222 | # Generate context file
223 | npx codefetch --max-tokens 50000 \
224 |   --output codefetch/codebase.md \
225 |   --token-encoder o200k \
226 |   --project-tree 3 \
227 |   --include-files "src/auth/**/*.ts,src/api/**/*.ts" \
228 |   --include-dir "src/utils"
229 | ```
230 | 
231 | ### 10. `ask-codefetch-pro`
232 | Generate codebase with codefetch, copy to clipboard, and automatically open AI chat. Streamlined workflow for quick codebase analysis.
233 | 
234 | **Workflow**:
235 | 1. Research: identify relevant files/directories for the task
236 | 2. Run: codefetch open with scoped files → copies to clipboard, opens browser
237 | 3. Paste: codebase in clipboard, paste into AI chat
238 | 
239 | **Features**:
240 | - Automatic clipboard copy
241 | - Browser opening with AI chat (ChatGPT, Gemini, Claude)
242 | - Custom chat URLs and models
243 | - Copy-only mode (no browser)
244 | - Same scoping options as `ask-codefetch`
245 | 
246 | **Usage**: `/ask-codefetch-pro [PROMPT="<task-description>"]`
247 | 
248 | **Examples**:
249 | ```bash
250 | # ChatGPT (default)
251 | npx codefetch open --max-tokens 50000 \
252 |   --token-encoder o200k \
253 |   --project-tree 3 \
254 |   --include-files "src/**/*.ts"
255 | 
256 | # Gemini
257 | npx codefetch open --chat-url gemini.google.com --chat-model gemini-3.0 \
258 |   --max-tokens 50000 --include-files "src/**/*.ts"
259 | 
260 | # Claude
261 | npx codefetch open --chat-url claude.ai --chat-model claude-3.5-sonnet \
262 |   --max-tokens 50000 --include-files "src/**/*.ts"
263 | 
264 | # Copy only (no browser)
265 | npx codefetch open --no-browser --max-tokens 50000 --include-files "src/**/*.ts"
266 | ```
267 | 
268 | ### 11. `solidjs-rules`
269 | Comprehensive SolidJS coding rules and best practices covering reactivity, control flow, async patterns, props, styling, file layout, and tooling.
270 | 
271 | **Features**:
272 | - Reactivity basics and signal usage
273 | - Control flow helpers (Show, For, Switch)
274 | - Async and side effect patterns
275 | - Component API and prop guidelines
276 | - Styling conventions
277 | - File and folder organization
278 | - ESLint configuration examples
279 | 
280 | **Usage**: `/solidjs-rules CODEFILES="<code-files-to-review>"`
281 | 
282 | **Examples**:
283 | ```
284 | /prompts:solidjs-rules CODEFILES="@Button.tsx @TodoList.tsx"
285 | 
286 | /prompts:solidjs-rules CODEFILES="src/components/**/*.tsx"
287 | ```
288 | 
289 | ### 12. `component-cleanup`
290 | SolidJS component size and structure rules for code cleanup. Helps maintain clean, maintainable components by enforcing size limits and structure guidelines.
291 | 
292 | **Features**:
293 | - Component size guidelines (150-250 LOC target, 600 LOC hard cap)
294 | - File naming conventions
295 | - Component splitting strategies
296 | - Logic extraction to hooks/utilities
297 | - JSX nesting limits
298 | 
299 | **Usage**: `/component-cleanup CODEFILES="<component-files-to-review>"`
300 | 
301 | **Examples**:
302 | ```
303 | /prompts:component-cleanup CODEFILES="@UserProfile.tsx"
304 | 
305 | /prompts:component-cleanup CODEFILES="src/components/**/*.tsx"
306 | ```
307 | 
308 | ### 13. `short-tokens`
309 | Minimizes token usage in text while retaining all key information. Aggressively trims text for token savings by removing redundancy and filler, while preserving every key fact, figure, and conclusion. Avoids asterisk formatting to save tokens.
310 | 
311 | **Key principles**:
312 | - Trim aggressively for token savings
313 | - Retain every key fact, figure, and conclusion
314 | - Remove redundancy and filler
315 | - Avoid `**` asterisk formatting
316 | - Every token consumes space in agent token windows
317 | 
318 | **Usage**: `/short-tokens TEXT="<text-to-shorten>"`
319 | 
320 | **Examples**:
321 | ```
322 | /prompts:short-tokens TEXT="The authentication system requires users to provide their credentials, including both a username and a password. This is very important for security purposes."
323 | 
324 | /prompts:short-tokens TEXT="@long-documentation.md"
325 | ```
326 | 
327 | ## Workflow Tips
328 | 
329 | - Use `create-plan` at the start of new tasks to ensure comprehensive planning
330 | - Use `plan-review` before starting complex implementations
331 | - Use `finalize-plan` when tasks are completed to maintain organized documentation
332 | - Use `code-review-low` after implementing features for quick validation
333 | - Use `code-review-high` for major changes or before releases
334 | - Combine `problem-analyzer` with debugging sessions for faster issue resolution
335 | - Use `ask-codefetch` to gather codebase context into a single markdown file
336 | - Use `ask-codefetch-pro` for quick codebase analysis with automatic clipboard and browser opening
337 | - Use `solidjs-rules` and `component-cleanup` when working with SolidJS codebases
338 | - Use `short-tokens` to optimize text content for AI token windows
339 | 
340 | ## Links
341 | 
342 | - **X/Twitter**: [@kregenrek](https://x.com/kregenrek)
343 | - **Bluesky**: [@kevinkern.dev](https://bsky.app/profile/kevinkern.dev)
344 | - **Website**: Learn to build software with AI: [instructa.ai](https://www.instructa.ai)
345 | 
346 | ## My other projects
347 | * OpenAI Codex Tools [codex-1up](https://github.com/regenrek/codex-1up)
348 | * [AI Prompts](https://github.com/instructa/ai-prompts/blob/main/README.md) - Curated AI Prompts for Cursor AI, Cline, Windsurf and Github Copilot
349 | * [codefetch](https://github.com/regenrek/codefetch) - Turn code into Markdown for LLMs with one simple terminal command
350 | * [aidex](https://github.com/regenrek/aidex) A CLI tool that provides detailed information about AI language models, helping developers choose the right model for their needs.# tool-starter


--------------------------------------------------------------------------------