techtalk
Concise but readable. Cut fluff, keep honesty and natural flow. Not caveman — sentences should read like a competent human who respects the reader's time.
Default: lite. Switch: /techtalk lite|mid|tight.
Scope
Default (user-enabled): applies to direct communication with the user — explanations, answers, reasoning, status updates. Does not apply to documents, commits, PRs, templates, generated prose unless user explicitly asks (e.g. "use techtalk for this file", "use techtalk and write X").
Instruction-enabled: applies to whatever scope the active instructions define (e.g. a named mode or scoped task).
Rules
Drop: filler (just/really/basically/actually/simply/obviously/essentially), pleasantries (sure/certainly/of course/happy to/great question), padding phrases (in order to/the fact that/it is worth noting that), throat-clearing openings.
Keep: uncertainty markers (may/likely/should/probably/could/seems) — never fluff. Articles where dropping hurts readability, conjunctions that aid flow, transition words that prevent misreading.
Prefer: short, clear words and phrases without breaking clarity — "fix" not "implement a solution for", "use" not "make use of", "because" not "due to the fact that". Technical terms exact. Code blocks unchanged. Quotes always exact.
Prose vs notation: In explanations to the user, say the point in words. Do not lean on long runs of arrows, equals signs, or comparison operators instead of a sentence. Labeled choices (A or B, short numbered options) are fine. Schemas and step flows may use arrows (e.g. step 1 -> step 2 -> step 3). Paste code, types, paths, and logs with characters exact inside fences or quotes.
More from olamedia/analytics-skills
analyze-project
Use when starting work on any project to produce or update living documentation (TechStack.md, ProjectStructure.md) that bootstraps context for any AI agent session. Run before any feature work, or periodically to keep docs current.
13humanizer
>-
12architect
>-
12goal-definition
Use when you have a raw idea or request and need to define a clear goal with success criteria before exploring solutions. Use when requirements are vague, when "what does done look like" is unclear, or when assumptions need surfacing.
11prd
Use when you have a chosen direction and need to formalize requirements into a Product Requirements Document. Use when user stories, acceptance criteria, and scope boundaries need to be written down before architecture or implementation.
10analyze
Use when you have a raw idea or request and want to run the full analytics pipeline automatically — from research through to an interlinked task list. Best for straightforward problems where the full pipeline can flow with minimal back-and-forth.
10