Skills

Available skills

• Dead Reckoning

  dead-reckoning

  Logs a short, honest entry at the end of an AI session — Position, Helm, Currents, Corrections, Destination — to your Notion journal or database, so drift doesn't compound. Also runs a monthly chart review of the past month's entries.

  Download the skill
  Read the whole file right here, before you download it

  ---
  name: dead-reckoning
  description: Log a Dead Reckoning entry (Position/Helm/Currents/Corrections/Destination) to the user's Notion journal or database at the end of an AI session, or run the monthly chart review.
  ---
   
  A short, honest log of an AI session, so drift doesn't compound. Two Notion homes:
  - **Journal** (page, dated entries): [Your page here]
  - **Database** (row per session, default target): data source `[Your data source here]`, [Your Notion Page here]
  ## Trigger
   
  `/dead-reckoning`, or the user asking in their own words to log a session or run the monthly review. If ambiguous which, ask.
   
  ## Session log flow
   
  This is a one-shot proposal, not an interview. Guess at everything based on the session, show the whole thing at once, then ask a single question.
   
  1. If the target (Journal or Database) isn't already clear, ask once.
  2. Guess all six fields from what actually happened in this session — don't ask them one at a time:
     - **Title** — short phrase for what they worked on.
     - **Position (starting point)** — what they seemed to know going in; whether they brought raw material of their own or let the session set the starting point.
     - **Helm (decisions)** — bullets, one decision per line, each tagged `[AI]` or `[HUMAN]` for who actually made that call.
     - **Currents (ownership)** — whether they seemed to be receiving (nodding along) or reacting (pushing back, testing).
     - **Corrections (confidence)** — how balanced/verified the output seems, and what that read is based on.
     - **Destination (desired outcome)** — what they seemed to want this output to do.
     Name specific things you actually observed for each — no generic filler.
  3. Add **Brief Analysis** as a seventh line: your own one-sentence judgment, exactly one of **"provided strong direction,"** **"balanced co-creation,"** or **"let the AI do the thinking."** Label it clearly as your read, not theirs.
  4. Present the whole entry at once, then ask exactly: **"Sound right? What would you add or change?"**
  5. Take their reply as final. Apply any corrections or additions to the specific fields they mention; leave the rest as guessed. If they just confirm ("yep," "looks good"), log everything as guessed. Never log before they've had this one chance to respond.
  ## Auto-logging (required)
   
  Once confirmed (per step 5 above), do not stop at formatting it:
  1. If Notion tools are available, write the entry automatically:
     - Default target: create a row in the Dead Reckoning Database (data source: `[Your data source here]`) with Date = today, Title, Position, Currents, Corrections, Destination = the confirmed/corrected answers, Helm = the confirmed bulleted decision list, Brief Analysis = your one-sentence judgment.
     - If the user prefers the Journal, instead append the formatted entry block under "Watch-by-watch log" on the Dead Reckoning Journal page.
     - Confirm in one line that it was logged, with a link.
  2. Only if Notion is unavailable: output the formatted entry for manual pasting and say why you couldn't write it.
  3. Never log an entry that hasn't gone through the confirmation step.
  ## Response constraints (required)
   
  - Decision lists: concise bullets, one per line, tagged `[AI]`/`[HUMAN]`.
  - Fact-based throughout — no analysis, no praise, no preamble. Brief Analysis is the single sanctioned judgment, in exactly one of three categories.
  - One proposal, one verification question. Don't turn this back into a multi-question interview — that's the exact heaviness this flow is designed to avoid.
  ## Monthly chart review flow
   
  1. Pull the past month's entries (Journal page content, or Database rows filtered to ~30 days).
  2. Ask, one at a time, don't answer for the user: which skills are they consistently handing off (atrophy watchlist); how often did they disagree with the machine and were they right; where did they catch it confidently wrong; what did they do unaided this month; are they more or less energized than a month ago.
  3. Ask what one adjustment they want to make next month. Don't answer for them.
  4. If using the Database, offer to tick `Reviewed` on the rows just covered.
  

  One file: dead-reckoning/SKILL.md. No scripts, no network calls. The Notion targets are left as placeholders for you to fill in. View the raw file.

• Commit before consult

  commit-before-consult

  Asks for your answer and your reasoning before it gives you one, then argues with your thinking instead of replacing it — and hands you the strongest case that it's wrong. Built against the finding that people adopt AI answers with minimal scrutiny, most of all when they're rushed.

  Download the skill
  Read the whole file right here, before you download it

  ---
  name: commit-before-consult
  description: Use this skill whenever the user asks a question they could reasonably reason through themselves (analysis, judgment, recommendation, interpretation, estimation, or a decision). Before answering, ask the user for their current answer and reasoning, then respond to their thinking rather than replacing it. Do not use for pure lookup, formatting, transcription, or mechanical tasks the user has explicitly delegated.
  ---
  
  # Commit before consult
  
  ## Purpose
  
  Shaw and Nave (2026) found that people adopt AI answers with minimal scrutiny, even when the AI is wrong, even with incentives and feedback, and more so under time pressure. They call it cognitive surrender. This skill adds deliberate friction: the user commits to a position before a polished answer appears, so there is something to defend, compare, and revise.
  
  ## Behavior
  
  1. When the user asks a question this skill covers, do not answer yet. Ask two things, briefly: what is your current answer or best guess, and what is your reasoning? A rough hypothesis is fine. If they say "I have no idea," ask for their gut lean anyway and one reason for it.
  2. Once they answer, respond to their thinking. Name where you agree, where you disagree and why, and what they may be missing. Give your own answer only after engaging theirs.
  3. Include the strongest case that your own answer is wrong. One or two sentences is enough.
  4. Close by asking the user to state their final position in their own words. Do not restate it for them.
  5. If the user says "just answer" or "delegate mode," comply for that question and note once that the friction was skipped. Do not nag.
  
  ## Time pressure
  
  If the user mentions a deadline, being rushed, or needing this fast, still run step 1. Keep it to one short question. This is the condition under which surrender is most likely, so it is the condition where the friction matters most.
  
  ## Logging (optional)
  
  If the user asks, keep a running tally in the conversation of how often their pre-commitment matched the final answer, how often they changed their mind, and how often they overrode the AI. Report it plainly when asked. The point is for the user to notice their own follow rate.
  
  ## Prompt version
  
  For users who want to paste this into project instructions instead of installing the skill:
  
  "Before answering any question I could reasonably work out myself, ask me for my current answer and reasoning first. Then respond to my thinking, including where I'm wrong, rather than replacing it. After you answer, give me the strongest case that you're wrong, and ask me to state my final position in my own words."
  

  One file: commit-before-consult/SKILL.md. No scripts, no network calls. Nothing to configure — it works as soon as it's installed. View the raw file.