Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
日本語の概要は準備中です。原文の説明を表示しています。
Use when improving prompts for any LLM. Applies proven prompt engineering techniques to boost output quality, reduce hallucinations, and cut token usage.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
This skill transforms weak, vague, or inconsistent prompts into precision-engineered instructions that reliably produce high-quality outputs from any LLM. It applies systematic prompt engineering frameworks — from zero-shot to few-shot, chain-of-thought, and structured output patterns.
Before optimizing, identify which problem pattern applies:
| Problem | Symptom | Fix |
|---|---|---|
| Too vague | Generic, unhelpful answers | Add role + context + constraints |
| No structure | Unformatted, hard-to-parse output | Specify output format explicitly |
| Hallucination | Confident wrong answers | Add "say I don't know if unsure" |
| Inconsistent | Different answers each run | Add few-shot examples |
| Too long | Verbose, padded responses | Add length constraints |
Every optimized prompt should have:
Before (weak prompt):
Explain machine learning.
After (optimized prompt):
You are a senior ML engineer explaining concepts to a junior developer.
Context: The developer has 1 year of Python experience but no ML background.
Task: Explain supervised machine learning in simple terms.
Constraints:
- Use an analogy from everyday life
- Maximum 200 words
- No mathematical formulas
- End with one actionable next step
Format: Plain prose, no bullet points.
For reasoning tasks, instruct the model to think step-by-step:
Solve this problem step by step, showing your work at each stage.
Only provide the final answer after completing all reasoning steps.
Problem: [your problem here]
Thinking process:
Step 1: [identify what's given]
Step 2: [identify what's needed]
Step 3: [apply logic or formula]
Step 4: [verify the answer]
Final Answer:
Provide 2-3 examples to establish the pattern:
Classify the sentiment of customer reviews as POSITIVE, NEGATIVE, or NEUTRAL.
Examples:
Review: "This product exceeded my expectations!" -> POSITIVE
Review: "It arrived broken and support was useless." -> NEGATIVE
Review: "Product works as described, nothing special." -> NEUTRAL
Now classify:
Review: "[your review here]" ->
Extract the following information from the text below and return it as valid JSON only.
Do not include any explanation or markdown — just the raw JSON object.
Schema:
{
"name": string,
"email": string | null,
"company": string | null,
"role": string | null
}
Text: [input text here]
Answer the following question based ONLY on the provided context.
If the answer is not contained in the context, respond with exactly: "I don't have enough information to answer this."
Do not make up or infer information not present in the context.
Context:
[your context here]
Question: [your question here]
Reduce token count without losing effectiveness:
# Verbose (expensive)
"Please carefully analyze the following code and provide a detailed explanation of
what it does, how it works, and any potential issues you might find."
# Compressed (efficient, same quality)
"Analyze this code: explain what it does, how it works, and flag any issues."
Before using a prompt in production:
Problem: Model ignores format instructions Solution: Move format instructions to the END of the prompt, after examples. Use strong language: "You MUST return only valid JSON."
Problem: Inconsistent results between runs Solution: Lower the temperature setting (0.0-0.3 for factual tasks). Add more few-shot examples.
Problem: Prompt works in playground but fails in production Solution: Check if system prompt is being sent correctly. Verify token limits aren't being exceeded (use a token counter).
Problem: Output is too long Solution: Add explicit word/sentence limits: "Respond in exactly 3 bullet points, each under 20 words."
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Use when manage multiple local CLI agents via tmux sessions (start/stop/monitor/assign) with cron-friendly scheduling.
日本語の概要は準備中です。原文の説明を表示しています。
Use when a hybrid memory system that provides persistent, searchable knowledge management for AI agents (Architecture, Patterns, Decisions).
日本語の概要は準備中です。原文の説明を表示しています。
Reference for how BDB structures autonomous software engineering work — the seven-node dispatcher graph (Architect, TechLead, UI/UX, Engineering, Media/EventTech, Reviewer, Shipping) that /startcycle-graph actually runs. Use when you need the high-level lifecycle framing without inventing your own process.
日本語の概要は準備中です。原文の説明を表示しています。
Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling.
日本語の概要は準備中です。原文の説明を表示しています。
Harness patterns for coding agents — memory, permissions, context engineering, delegation, skills, hooks, bootstrap.
日本語の概要は準備中です。原文の説明を表示しています。
agenttrail: live map of a multi-agent build in the browser: which plan component is being worked on, by which agent or harness, what is done and what is stuck. Use when a multi-agent pipeline starts (/startcycle, /startcycle-graph, /teamwork-preview) or after a plan-canvas approve, when the user asks to see what the agents are doing ("live map", "build board", "who is running now"), or by yourself whenever a multi-agent run is under way — no user prompt needed.
日本語の概要は準備中です。原文の説明を表示しています。