| --- | |
| name: to-design | |
| description: Turn a PRD, plan, or feature conversation into an implementation-ready software design focused on deep modules, clear seams, and testable interfaces. Use between `to-prd` and `to-issues`, or when the user asks for software, architecture, technical, or implementation design. | |
| --- | |
| # To Design | |
| Create the technical design that `to-issues` can later slice. Do not draft the | |
| issue breakdown here. |
Improve code quality only where it directly supports the assigned change.
Evolve the codebase toward higher quality, but let the assigned task set the boundary. Do not chase unrelated cleanup.
Required:
name: tufte-viz description: | Ideate and critique data visualizations using Edward Tufte's principles from "The Visual Display of Quantitative Information." Use this skill when: (1) Designing new data visualizations or charts (2) Critiquing or improving existing visualizations (3) Reviewing dashboards or reports for graphical integrity (4) Deciding between visualization approaches (5) Reducing chartjunk or improving data-ink ratio (6) Planning small multiples or high-density displays
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
| #!/usr/bin/env bash | |
| set -euo pipefail | |
| bold() { printf "\033[1m%s\033[0m\n" "$*"; } | |
| info() { printf "• %s\n" "$*"; } | |
| warn() { printf "\033[33m! %s\033[0m\n" "$*"; } | |
| err() { printf "\033[31m✗ %s\033[0m\n" "$*" >&2; } | |
| ok() { printf "\033[32m✓ %s\033[0m\n" "$*"; } | |
| require_macos() { |
| import android.content.SharedPreferences | |
| import com.google.crypto.tink.Aead | |
| import com.google.crypto.tink.KeysetHandle | |
| import com.google.crypto.tink.RegistryConfiguration | |
| import com.google.crypto.tink.TinkProtoKeysetFormat | |
| import com.google.crypto.tink.aead.AeadConfig | |
| import com.google.crypto.tink.aead.PredefinedAeadParameters | |
| import com.google.crypto.tink.integration.android.AndroidKeystore | |
| import com.google.crypto.tink.subtle.Base64 | |
| import com.google.crypto.tink.subtle.Hex |
| Begin by enclosing all thoughts within <thinking> tags, exploring multiple angles and approaches. | |
| Break down the solution into clear steps within <step> tags. Start with a 20-step budget, requesting more for complex problems if needed. | |
| Use <count> tags after each step to show the remaining budget. Stop when reaching 0. | |
| Continuously adjust your reasoning based on intermediate results and reflections, adapting your strategy as you progress. | |
| Regularly evaluate progress using <reflection> tags. Be critical and honest about your reasoning process. | |
| Assign a quality score between 0.0 and 1.0 using <reward> tags after each reflection. Use this to guide your approach: | |
| 0.8+: Continue current approach | |
| 0.5-0.7: Consider minor adjustments | |
| Below 0.5: Seriously consider backtracking and trying a different approach |
| Begin by enclosing all thoughts within <thinking> tags, exploring multiple angles and approaches. | |
| Break down the solution into clear steps within <step> tags. Start with a 20-step budget, requesting more for complex problems if needed. | |
| Use <count> tags after each step to show the remaining budget. Stop when reaching 0. | |
| Continuously adjust your reasoning based on intermediate results and reflections, adapting your strategy as you progress. | |
| Regularly evaluate progress using <reflection> tags. Be critical and honest about your reasoning process. | |
| Assign a quality score between 0.0 and 1.0 using <reward> tags after each reflection. Use this to guide your approach: | |
| 0.8+: Continue current approach | |
| 0.5-0.7: Consider minor adjustments | |
| Below 0.5: Seriously consider backtracking and trying a different approach |
| package pro.respawn.app.feature.account.thirdparty | |
| import androidx.compose.runtime.Composable | |
| import co.touchlab.kermit.Logger | |
| import kotlinx.cinterop.ExperimentalForeignApi | |
| import kotlinx.cinterop.cstr | |
| import kotlinx.cinterop.memScoped | |
| import kotlinx.cinterop.reinterpret | |
| import kotlinx.coroutines.CancellationException | |
| import kotlinx.coroutines.suspendCancellableCoroutine |
| import androidx.compose.animation.core.animateDpAsState | |
| import androidx.compose.animation.fadeIn | |
| import androidx.compose.animation.fadeOut | |
| import androidx.compose.foundation.layout.Box | |
| import androidx.compose.foundation.layout.WindowInsets | |
| import androidx.compose.foundation.layout.consumeWindowInsets | |
| import androidx.compose.foundation.layout.fillMaxSize | |
| import androidx.compose.foundation.layout.navigationBars | |
| import androidx.compose.foundation.layout.padding | |
| import androidx.compose.foundation.layout.windowInsetsPadding |
