Documentation
Prompt library
Copy-paste prompts for building tools — start, shape, build, and ship. Peacae optional.
Copy a full brief into any coding agent to design and build a tool. Swap bracketed placeholders before you paste. Use Peacae for board tracking if you want — these prompts work either way.
Start a tool
Turn an idea into a clear problem, stack choice, and first scaffold.
- Clarify the tool idea prompt (read-only)
You are helping me design a software tool.
Idea (fill in): [TOOL_IDEA]
Do the following:
1. Restate the problem in one sentence.
2. Name the primary user and the job they are hiring this tool for.
3. List 3–5 must-have outcomes for an MVP (not features — outcomes).
4. List explicit non-goals for v1.
5. Call out the riskiest assumption we should validate first.
6. Ask me at most 5 clarifying questions if something critical is missing. Otherwise proceed with reasonable defaults and label them as assumptions.
Do not write implementation code yet. End with a short “recommended next step” (usually: scope MVP or scaffold the repo).
- Recommend a stack prompt (read-only)
Help me choose a pragmatic stack for this tool.
Context:
- Tool: [TOOL_NAME_OR_IDEA]
- Constraints: [TIME_BUDGET / TEAM_SIZE / HOSTING / MUST_USE_TECH]
- I care about: [e.g. speed to ship, maintainability, offline, mobile, etc.]
Do the following:
1. Propose one default stack (language, framework, data store, hosting) and why it fits.
2. Offer one alternative stack and when I should pick it instead.
3. Call out what we should deliberately avoid for an MVP.
4. Outline a minimal folder/architecture sketch (high level only).
5. List setup steps to get a blank project running locally.
Do not generate a full app yet — recommendation + bootstrap plan only.
- Scaffold the project prompt (read-only)
Scaffold a working starting point for this tool.
Tool: [TOOL_NAME]
Stack preference (or recommend one): [STACK]
MVP outcome: [ONE_SENTENCE_OUTCOME]
Do the following:
1. Create a clean project structure with sensible defaults (lint/format/scripts as appropriate).
2. Add a minimal runnable “hello” path so I can verify the app starts.
3. Add a short README: what this is, how to run, and how to develop.
4. Do not build the full product yet — only the scaffold and empty seams where features will land.
5. Call out any secrets/env vars I must provide (use placeholders, never invent real credentials).
6. When finished, summarize what you created and the exact commands to run.
Commit only if I ask.
- Explore an existing codebase prompt (read-only)
Explore this repository before we change anything.
Goal of the tool (my words): [GOAL]
Do the following:
1. Map the architecture: entry points, main modules, data flow.
2. Identify how to run tests and the app locally.
3. Note conventions (naming, folder layout, patterns) I should follow.
4. List the top risks for a newcomer editing this code.
5. Propose the smallest first change that would prove we understand the system.
Do not refactor or “clean up” unrelated code. End with a short orientation I can reuse in later prompts.