Master Your AI Workflow with our Prompt Library

1. Better Prompts

Make your prompts better before you start. A good prompt means you get the right answer faster. Choose the tool that works best for you and the detail you need.

Optimise LLM Prompts

Provides expert strategies and tactics for optimising Large Language Model prompts, enhancing clarity, relevance, and output quality.

Prompt Optimiser — 4-D Framework

Rebuilds any prompt using the 4-D methodology (Deconstruct, Diagnose, Develop, Deliver): extracts intent, audits clarity gaps, selects the optimal technique (few-shot, chain-of-thought, constraint-based), and outputs a refined prompt with implementation guidance tailored to the target AI platform.

Optimise Prompts

Analyses and refines any given prompt based on clarity, structure, context, and output specifications, providing an improved version and explanation.

Iterative Prompt Co-Engineering

Acts as a dedicated prompt engineer in a conversational refinement loop: each turn produces a revised prompt alongside targeted clarifying questions, continuing until the user confirms the result meets their needs.

2. Writing and Fixing Code

The main part of your work. Use these tools to build new features with tests or to find and fix bugs. Choose the best tool for your task: tests for new features, finding bugs, or quick code for testing ideas.

Test-Driven Development

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Diagnose

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

Prototype

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

3. Keep the Context

AI can get confused during long chats. Use these tools to save the main points and start work in a new chat. Pick the tool that fits your style – saving notes inside the chat or in a new file.

Continue

Hand the current work over to a fresh session: write a compressed checkpoint to a file, then launch a new session seeded with it so work resumes without copy-paste. Falls back to a paste-ready block when no CLI is available. Use when the user says "continue", "handoff", "checkpoint", "resume in a new chat", or when a session is running out of context and the work must survive the break. Records gotcha candidates with their evidence so the next session can file them with `memories`.

handoff

Compact the current conversation into a handoff document for another agent to pick up.

4. Save What You Learn

Save "Gotchas" (small tips) at the end of each chat. When you have many tips, merge them into one list.

Memories

Capture technical gotchas into the JIT `memories/` knowledge base, either from the current conversation or by mining past `.jsonl` transcripts. Accepts only reproducible, monorepo-specific constraints with a concrete root cause. Use when the user says "memories", "save gotchas", "extract gotchas", "mine chat history", "process the backlog", or after a session that uncovered a non-obvious trap worth keeping. For auditing, merging or pruning what is already filed, use `memories-manager` instead.

Memories Manager

Audit every existing `memories/*-gotchas.md` file across the monorepo: merge duplicates, promote workspace rules to the root, prune what no longer applies, and normalise formatting. Preserves wording literally and never beautifies technical detail. Use when the user says "memories manager", "manage memories", "audit memories", "merge memories", "prune memories", or when the knowledge base has drifted, duplicated or gone stale. For filing NEW gotchas, use `memories` instead.

5. Work and Commits

Use these tools while you work to keep your commits clean and your code safe. Pick the tools that match your project and how much safety you want.

Commit

Split staged changes into the smallest valid sequence of Conventional Commits, propose them for approval, and execute them once approved. Verifies the staged fingerprint before committing and never amends, rebases, pushes, or bypasses hooks. Use when the user says "commit", "commit this", "write a commit", "commit message", or asks to split staged work into atomic commits.

Setup Git Guardrails

Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

Setup Pre-Commit Hooks

Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.

6. Release

Create missing files and release the new version of your code.

Generate Missing Changesets

Write the changesets for everything committed since the last release. A script captures the commits mechanically into `.temp/raw-changesets/`, one file per package per severity; you turn that capture into user-facing changesets in `.changeset/`, and a second script run proves nothing was lost. Handles workspace and single-package repositories. Fail-closed: stops and reports instead of fixing forward, and never touches anything outside `.changeset/`. Use when the user says "missing changesets", "generate changesets", or before a release where the changelog would otherwise be incomplete. Run while the individual commit messages still exist — before a squash merge, never after.

Release

Execute a deterministic release cycle: version the pending changesets, restructure the new changelog sections for a reader, add the release summary and commit, behind fail-closed gates. Touches only `CHANGELOG.md`, `package.json`, `pnpm-lock.yaml` and `.changeset/`, never rewrites released history, and never rewrites the wording that came from the changesets. Use when the user says "release", "cut a release", "bump version", or "publish".