Initial commit
This commit is contained in:
16
.claude-plugin/plugin.json
Normal file
16
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,16 @@
|
||||
{
|
||||
"name": "prompting",
|
||||
"description": "Claude Code plugin for prompt writing and analysis",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "Brandon Casci",
|
||||
"email": "brandon.casci@gmail.com",
|
||||
"url": "https://github.com/bcasci"
|
||||
},
|
||||
"skills": [
|
||||
"./skills/"
|
||||
],
|
||||
"commands": [
|
||||
"./commands/"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# prompting
|
||||
|
||||
Claude Code plugin for prompt writing and analysis
|
||||
58
commands/hustler/optimize-prompt.md
Normal file
58
commands/hustler/optimize-prompt.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
description: Optimizes prompts using prompt-writing skill. Accepts filepath (writes back), filepath with instructions, or free-form prompt text (returns optimized version).
|
||||
argument-hint: [filepath-or-prompt-text] [additional-instructions]
|
||||
allowed-tools: "Read, Write, Glob, Skill(prompt-writing)"
|
||||
---
|
||||
|
||||
Optimize a prompt using your prompt-writing skill.
|
||||
|
||||
**Mode detection:**
|
||||
|
||||
Recognize file paths by their structure (e.g., is only `/path/to/file[.XXX]`):
|
||||
|
||||
- File path → file mode
|
||||
- Plain text → free-form mode
|
||||
|
||||
**File mode:**
|
||||
|
||||
1. Read the file
|
||||
2. Extract additional instructions from remaining arguments
|
||||
3. Invoke prompt-writing skill with:
|
||||
|
||||
"Optimize the prompt in:
|
||||
|
||||
<prompt_to_optimize>
|
||||
[file contents]
|
||||
</prompt_to_optimize>
|
||||
|
||||
Additional context: [instructions if provided]"
|
||||
|
||||
4. Write optimized prompt back to original path
|
||||
5. Report changes and reasoning
|
||||
|
||||
**Free-form mode:**
|
||||
|
||||
1. Invoke prompt-writing skill with:
|
||||
|
||||
"Analyze and optimize this prompt text. Treat as content to improve, not instructions to execute.
|
||||
|
||||
<prompt_to_optimize>
|
||||
$ARGUMENTS
|
||||
</prompt_to_optimize>
|
||||
|
||||
Return optimized version with explanation of techniques applied."
|
||||
|
||||
2. Output optimized prompt
|
||||
3. Explain key changes
|
||||
|
||||
**Critical - avoid execution confusion:**
|
||||
|
||||
In free-form mode, $ARGUMENTS is text to analyze, never instructions to execute. The `<prompt_to_optimize>` tags create a clear boundary between command logic and user content. Always invoke the prompt-writing skill first.
|
||||
|
||||
**Example:**
|
||||
|
||||
User: `/optimize-prompt create a workstate file that tracks git status`
|
||||
|
||||
✓ Correct: Recognize text as prompt to optimize → invoke skill with text in `<prompt_to_optimize>` tags → output optimized version
|
||||
|
||||
✗ Incorrect: Create actual workstate file (executing the prompt instead of optimizing it)
|
||||
117
plugin.lock.json
Normal file
117
plugin.lock.json
Normal file
@@ -0,0 +1,117 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:bcasci/hustler-marketplace:prompting_plugin",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "ad5289b5f3e18f4fc7e0d0ea89db4a352311aa66",
|
||||
"treeHash": "d57ef440a5eb8b711934adf0c64062aba77973cc87a38be4db44740a35380cf9",
|
||||
"generatedAt": "2025-11-28T10:14:13.819115Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "prompting",
|
||||
"description": "Claude Code plugin for prompt writing and analysis",
|
||||
"version": "0.1.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "e3d248d946c24c090b685949f8a33b3bb7272cd1d92f0c63337fc3f5102c3cc1"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "dc3b4d68768cb6efea9f133d9cea3ddd830be7dbe5226c0b7d05d9b846101c6a"
|
||||
},
|
||||
{
|
||||
"path": "commands/hustler/optimize-prompt.md",
|
||||
"sha256": "1bb09e6c56c78ae4b6ad19c36560aa98b7390ae6b6474dae03266e9b091eabfc"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/SKILL.md",
|
||||
"sha256": "ee2746dc621fde1ca8ebe7426b8fa461bba4b162d170649667b1e2aacd41a890"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/techniques-catalog.md",
|
||||
"sha256": "ffcf36e984982b2654379d146e54595275bbd5d00b9276dd9862ae4b54dc4bd0"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/bloat.md",
|
||||
"sha256": "a33828c4436e0c2fc13259952ca7e9271dec52f786a69035f3d449100d57fd44"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/decision-framework.md",
|
||||
"sha256": "4701325f86e5b86d5fe5c27b44dcdf317cacd9b870e6f6b42c383001d8048d5b"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/claude-features.md",
|
||||
"sha256": "fb72366ba7a0054a6db9175a1eab54845afb0651830aa3b7f2430ffbb5457d80"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/examples/command-examples.md",
|
||||
"sha256": "bcd3cac707ad4e75ac9717c8b9641f060c99a3a40f9d803db15bb9694072d119"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/examples/skill-examples.md",
|
||||
"sha256": "1f33d8583852c43ca791342720ecf22a09c1cb9cdc56e66e39970be587289f41"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/examples/subagent-examples.md",
|
||||
"sha256": "0dc6406979baff3dfe47bebaacf8b9310ed28a9ad1ea2a9eb6d85aebd5a3ceaf"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/examples/technique-examples.md",
|
||||
"sha256": "49b98c822496952b69bce5f3b780e0e8daf6d29047f55c2b055a2b73bf1bf23a"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/examples/document-examples.md",
|
||||
"sha256": "926c8dcc4dba926425c64cda57187f7938dbfffb59858225b1f3c95f4171f917"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/artifact-guides/commands.md",
|
||||
"sha256": "7c504d76ea89095c1cca0d3be6a656d3b41f33d569587c840f97b44fa3100177"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/artifact-guides/skills.md",
|
||||
"sha256": "142b482e807a135bebb7d64703cf6de8451a57336a08b274ea6219adf489fc52"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/artifact-guides/reference_documents.md",
|
||||
"sha256": "3deaea03b0e4a423247baa8d9c0e6e2048320163fe547131ca44a9c55fa747b6"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/artifact-guides/agents.md",
|
||||
"sha256": "de9fce1abbdc61f7426405481dd6255d19b3dcff93c6a4ae9159bdce9252e3f9"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/templates/command-template.md",
|
||||
"sha256": "847fb1b52e29bbb9a62838bb29232f61e37f91e65161e0ad45ba299935595d0b"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/templates/skill-template.md",
|
||||
"sha256": "30c6389f9b422047979b2a029c56bbd2fd3d179ab8e35f152a7c413daa75d9cf"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/templates/subagent-template.md",
|
||||
"sha256": "042b53d9c44e425e9dbc3124d740449d1e57c84e467894898e950a079c50773f"
|
||||
},
|
||||
{
|
||||
"path": "skills/prompt-writing/references/templates/reference-document-template.md",
|
||||
"sha256": "d493c75c98997352883d4eed4415073c4c9d775ad23c0e5128060b8f7a588a12"
|
||||
}
|
||||
],
|
||||
"dirSha256": "d57ef440a5eb8b711934adf0c64062aba77973cc87a38be4db44740a35380cf9"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
70
skills/prompt-writing/SKILL.md
Normal file
70
skills/prompt-writing/SKILL.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
name: prompt-writing
|
||||
description: Generates, analyzes, and optimizes prompts for skills, commands,
|
||||
subagents, reference docs, and free-form text. Use when generating prompt content, analyzing prompt files, or optimizing prompt text to
|
||||
apply techniques and reduce bloat. Trigger with phrases like '[generate|analyze|optimize] prompt', '[generate|analyze|optimize] [file-path]', 'create [skill|command|subagent]'.
|
||||
allowed-tools: "Read, Glob, Grep"
|
||||
---
|
||||
|
||||
## Operating Modes
|
||||
|
||||
**Generation**: Takes user intent and artifact type → generates complete prompt with appropriate frontmatter, techniques, and Claude Code features.
|
||||
|
||||
**Analysis**: Evaluates existing prompt → identifies what works, what could improve, suggests specific enhancements with reasoning.
|
||||
|
||||
**Optimization**: Refines prompt → preserves intent, applies decision framework, improves clarity/conciseness, explains changes.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Understand context**: Determine artifact type (skill/command/subagent/reference doc/free-form) and user's goal
|
||||
2. **Apply decision framework**: Use `{baseDir}/references/decision-framework.md` to determine which techniques and features to add
|
||||
3. **Check artifact requirements**:
|
||||
- Skills: `{baseDir}/references/artifact-guides/skills.md`
|
||||
- Commands: `{baseDir}/references/artifact-guides/commands.md`
|
||||
- Subagents: `{baseDir}/references/artifact-guides/agents.md`
|
||||
- Reference docs: `{baseDir}/references/artifact-guides/reference_documents.md`
|
||||
4. **Apply techniques**: Reference `{baseDir}/references/techniques-catalog.md` for definitions
|
||||
5. **Avoid bloat**: Follow `{baseDir}/references/bloat.md` principles
|
||||
6. **Use Claude features**: Reference `{baseDir}/references/claude-features.md` when appropriate
|
||||
7. **Use templates**: Start from `{baseDir}/references/templates/` for structure
|
||||
8. **Reference examples**: Check `{baseDir}/references/examples/` for good/bad patterns
|
||||
|
||||
## Common Errors
|
||||
|
||||
**Wrong frontmatter**: Each artifact type has specific required/optional fields - verify against artifact guides
|
||||
**Bloat**: Removed by asking "Does this sentence change Claude's behavior?"
|
||||
**Wrong technique**: Apply decision framework - not all prompts benefit from CoT or Few-Shot
|
||||
**Missing trigger words**: Skills need invocation phrases like "use your [skill-name] to..."
|
||||
**Absolute paths**: Use `{baseDir}/references/` not full paths
|
||||
**Subagent terminology**: Use "subagent" not "agent" in `.claude/agents/` files
|
||||
|
||||
## Resources
|
||||
|
||||
**Core:**
|
||||
|
||||
- `{baseDir}/references/techniques-catalog.md`
|
||||
- `{baseDir}/references/decision-framework.md`
|
||||
- `{baseDir}/references/bloat.md`
|
||||
- `{baseDir}/references/claude-features.md`
|
||||
|
||||
**Artifact Guides:**
|
||||
|
||||
- `{baseDir}/references/artifact-guides/skills.md`
|
||||
- `{baseDir}/references/artifact-guides/commands.md`
|
||||
- `{baseDir}/references/artifact-guides/agents.md`
|
||||
- `{baseDir}/references/artifact-guides/reference_documents.md`
|
||||
|
||||
**Templates:**
|
||||
|
||||
- `{baseDir}/references/templates/skill-template.md`
|
||||
- `{baseDir}/references/templates/command-template.md`
|
||||
- `{baseDir}/references/templates/subagent-template.md`
|
||||
- `{baseDir}/references/templates/reference-document-template.md`
|
||||
|
||||
**Examples:**
|
||||
|
||||
- `{baseDir}/references/examples/technique-examples.md`
|
||||
- `{baseDir}/references/examples/skill-examples.md`
|
||||
- `{baseDir}/references/examples/command-examples.md`
|
||||
- `{baseDir}/references/examples/document-examples.md`
|
||||
- `{baseDir}/references/examples/subagent-examples.md`
|
||||
150
skills/prompt-writing/references/artifact-guides/agents.md
Normal file
150
skills/prompt-writing/references/artifact-guides/agents.md
Normal file
@@ -0,0 +1,150 @@
|
||||
<agents>
|
||||
|
||||
## Writing Claude Code Subagent Prompts
|
||||
|
||||
Subagents are specialized AI assistants defined in markdown files with YAML frontmatter. Each subagent has its own context window and specific tool permissions. When generating subagent prompts, focus on effective frontmatter and purposeful system prompts.
|
||||
|
||||
## Subagent File Structure
|
||||
|
||||
**Format:**
|
||||
|
||||
```
|
||||
---
|
||||
name: subagent-name
|
||||
description: Clear description of what this does and when to use it
|
||||
tools: Read, Grep, Glob, Bash
|
||||
model: inherit
|
||||
---
|
||||
|
||||
System prompt content here.
|
||||
Define behavior, expertise, and workflow.
|
||||
```
|
||||
|
||||
**File locations:** Project-level at .claude/agents/ or user-level at ~/.claude/agents/
|
||||
|
||||
## Frontmatter Architecture
|
||||
|
||||
**name (required):**
|
||||
Unique identifier. Use lowercase with hyphens.
|
||||
|
||||
**description (required):**
|
||||
Critical field that determines when Claude invokes the subagent. Must include:
|
||||
|
||||
1. What the subagent does
|
||||
2. When it should be used (include "USE PROACTIVELY" or "MUST BE USED" for automatic invocation)
|
||||
3. What context it needs to start
|
||||
4. How to trigger it (specific invocation phrases)
|
||||
|
||||
Good: "Expert code reviewer. USE PROACTIVELY after code changes to check security, style, and maintainability. Reviews git diffs and provides prioritized feedback."
|
||||
|
||||
Poor: "Reviews code" (too vague, no trigger conditions, no proactive signal)
|
||||
|
||||
**tools (optional):**
|
||||
Comma-separated list. Omit to inherit all tools from main thread.
|
||||
Common: Read, Write, Edit, Bash, Glob, Grep, WebSearch, WebFetch
|
||||
Principle: Grant only necessary tools.
|
||||
|
||||
**model (optional):**
|
||||
Specify model or use "inherit" for main thread's model.
|
||||
|
||||
## System Prompt Design
|
||||
|
||||
The content after frontmatter defines the subagent's behavior. Use any prompting strategy that fits the purpose: Chain-of-Thought, Few-Shot, XML structure, decision frameworks, plain instructions.
|
||||
|
||||
**System prompt should define:**
|
||||
|
||||
- Role and expertise
|
||||
- Specific responsibilities and workflow
|
||||
- Constraints and boundaries
|
||||
- Expected output format
|
||||
- Edge case handling
|
||||
|
||||
**No restrictions on approach:** The system prompt can be structured however best accomplishes the subagent's purpose.
|
||||
|
||||
## Architecting Effective Descriptions
|
||||
|
||||
The description determines when the subagent is invoked. Make it actionable and specific.
|
||||
|
||||
**Trigger words:** "Use PROACTIVELY" or "MUST BE USED" encourage automatic invocation.
|
||||
|
||||
**Specific conditions:**
|
||||
Good: "Use after code changes to run tests and fix failures"
|
||||
Bad: "Helps with testing"
|
||||
|
||||
**Required context:**
|
||||
Good: "Analyzes git diffs to review changed code paths"
|
||||
Bad: "Reviews code"
|
||||
|
||||
**Invocation clarity:**
|
||||
Description should make it obvious how to explicitly request this subagent using phrases like "use your [subagent-name] subagent to..." or "use the [subagent-name] subagent for..."
|
||||
|
||||
## System Prompt Patterns
|
||||
|
||||
**Goal-Oriented:**
|
||||
Define what to accomplish, let subagent determine approach within constraints.
|
||||
|
||||
**Process-Driven:**
|
||||
For workflows requiring specific steps (TDD, security audits), outline them explicitly.
|
||||
|
||||
**Tool-Aware:**
|
||||
Reference available tools and when to use them.
|
||||
|
||||
**Output-Focused:**
|
||||
Specify expected format (JSON, markdown, structured reports).
|
||||
|
||||
**Any Strategy Works:**
|
||||
CoT for complex reasoning, Few-Shot for specific patterns, XML for organization, decision trees for branching logic.
|
||||
|
||||
## Common Subagent Architectures
|
||||
|
||||
**Read-Only Analyst:**
|
||||
tools: Read, Grep, Glob
|
||||
Purpose: Analyze and provide feedback without modification
|
||||
|
||||
**Code Implementer:**
|
||||
tools: Read, Write, Edit, Bash, Grep, Glob
|
||||
Purpose: Implement features, fix bugs, modify code
|
||||
|
||||
**Test Executor:**
|
||||
tools: Read, Bash, Grep
|
||||
Purpose: Run tests, analyze failures, report results
|
||||
|
||||
**Documentation Writer:**
|
||||
tools: Read, Write, Grep, Glob
|
||||
Purpose: Generate or update documentation
|
||||
|
||||
**Research Specialist:**
|
||||
tools: Read, Grep, WebSearch, WebFetch
|
||||
Purpose: Gather information, analyze patterns
|
||||
|
||||
## What to Include When Generating Subagent Prompts
|
||||
|
||||
**Frontmatter design:**
|
||||
|
||||
- Clear, unique name
|
||||
- Actionable description with trigger conditions and context needs
|
||||
- Minimal necessary tool permissions
|
||||
- Model choice if needed
|
||||
|
||||
**System prompt design:**
|
||||
|
||||
- Clear role definition
|
||||
- Specific responsibilities
|
||||
- Workflow or approach guidance
|
||||
- Constraints and boundaries
|
||||
- Output expectations
|
||||
- Appropriate prompting strategy for the task
|
||||
|
||||
## What to Avoid
|
||||
|
||||
**Vague descriptions:** Claude won't know when to invoke the subagent
|
||||
|
||||
**Over-permissioning:** Only grant necessary tools for security and focus
|
||||
|
||||
**Rigid process when flexibility needed:** Allow adaptation within constraints
|
||||
|
||||
**No trigger guidance:** Without clear conditions, subagent may never be automatically invoked
|
||||
|
||||
**Missing context requirements:** Specify what the subagent needs to start effectively
|
||||
|
||||
</agents>
|
||||
152
skills/prompt-writing/references/artifact-guides/commands.md
Normal file
152
skills/prompt-writing/references/artifact-guides/commands.md
Normal file
@@ -0,0 +1,152 @@
|
||||
<commands>
|
||||
|
||||
## Command Namespacing
|
||||
|
||||
Organize commands in subdirectories. Subdirectory names appear as labels but don't change invocation.
|
||||
|
||||
- `commands/command.md` → `/command`
|
||||
- `commands/namespace/command.md` → `/command` (labeled with namespace)
|
||||
|
||||
## Command File Structure
|
||||
|
||||
Command files can contain optional frontmatter followed by the prompt content.
|
||||
|
||||
**Frontmatter (Optional but Recommended):**
|
||||
|
||||
```yaml
|
||||
---
|
||||
description: Brief description of what this command does
|
||||
argument-hint: [issue-number] [priority]
|
||||
allowed-tools: "Bash(git:*), Read, Write"
|
||||
model: claude-3-5-haiku-20241022
|
||||
disable-model-invocation: false
|
||||
---
|
||||
```
|
||||
|
||||
All frontmatter fields are optional:
|
||||
- `description`: Brief description (defaults to first line of prompt). Include this for SlashCommand tool discovery.
|
||||
- `argument-hint`: Expected arguments for auto-completion
|
||||
- `allowed-tools`: Tools this command can use (inherits from conversation if omitted)
|
||||
- `model`: Specific model to use (inherits from conversation if omitted)
|
||||
- `disable-model-invocation`: Set to true to prevent SlashCommand tool from calling this command (defaults to false)
|
||||
|
||||
**Prompt Content:**
|
||||
|
||||
After frontmatter (or if no frontmatter), the markdown content becomes the prompt Claude receives.
|
||||
|
||||
Simple example:
|
||||
```
|
||||
Run the test suite and report any failures in the scratchpad.
|
||||
```
|
||||
|
||||
Example with frontmatter:
|
||||
```yaml
|
||||
---
|
||||
description: Fix GitHub issues following TDD workflow
|
||||
argument-hint: [issue-number]
|
||||
allowed-tools: "Bash(gh:*), Read, Write, Edit"
|
||||
---
|
||||
|
||||
Analyze GitHub issue $ARGUMENTS and create a fix:
|
||||
1. Use `gh issue view $ARGUMENTS` to read the issue
|
||||
2. Identify the root cause
|
||||
3. Implement a fix
|
||||
4. Run tests to verify
|
||||
```
|
||||
|
||||
## Argument Handling
|
||||
|
||||
Commands support two argument patterns:
|
||||
|
||||
**`$ARGUMENTS` - All arguments as single string:**
|
||||
|
||||
Captures everything after the command name as one value.
|
||||
|
||||
Example:
|
||||
|
||||
- Command file contains: `Fix issue $ARGUMENTS`
|
||||
- Invocation: `/fix-issue 123 high-priority`
|
||||
- Result: `$ARGUMENTS` becomes `123 high-priority`
|
||||
- Claude receives: `Fix issue 123 high-priority`
|
||||
|
||||
**Positional Parameters (`$1`, `$2`, `$3`) - Individual arguments:**
|
||||
|
||||
Access specific arguments separately, like shell script parameters.
|
||||
|
||||
Example:
|
||||
|
||||
- Command file contains: `Review PR #$1 with priority $2 assigned to $3`
|
||||
- Invocation: `/review-pr 456 high alice`
|
||||
- Result: `$1` = `456`, `$2` = `high`, `$3` = `alice`
|
||||
- Claude receives: `Review PR #456 with priority high assigned to alice`
|
||||
|
||||
**When to use each:**
|
||||
|
||||
- `$ARGUMENTS`: All input as single value (commit messages, search queries, issue numbers with descriptions)
|
||||
- `$1, $2, $3`: Multiple distinct values (PR number + priority + assignee, file path + operation + output format)
|
||||
|
||||
## Special Command Features
|
||||
|
||||
**Bash Execution (`!` prefix):**
|
||||
|
||||
Execute bash commands before the slash command runs. The output is included in the command context.
|
||||
|
||||
Example:
|
||||
|
||||
```yaml
|
||||
---
|
||||
description: Analyze current git status and suggest next steps
|
||||
allowed-tools: "Bash(git:*)"
|
||||
---
|
||||
|
||||
Current git status:
|
||||
!`git status --short`
|
||||
|
||||
Based on the above status, suggest what to do next.
|
||||
```
|
||||
|
||||
Note: Requires `allowed-tools` frontmatter with Bash tool specified.
|
||||
|
||||
**File References (`@` prefix):**
|
||||
|
||||
Include file contents directly in the command context.
|
||||
|
||||
Example:
|
||||
|
||||
```markdown
|
||||
Review the implementation in @src/auth/login.js and suggest improvements.
|
||||
```
|
||||
|
||||
**Extended Thinking:**
|
||||
|
||||
Activate extended thinking by including relevant keywords in command definitions.
|
||||
|
||||
Example:
|
||||
|
||||
```markdown
|
||||
Think deeply about the architecture implications of this change and analyze thoroughly before proposing a solution.
|
||||
```
|
||||
|
||||
## Commands vs Other Formats
|
||||
|
||||
**Command vs Skill:** Command is a prompt stored in `.claude/commands/`, invoked explicitly with `/`. Skill is instructions in a folder, invoked automatically when Claude determines it's relevant.
|
||||
|
||||
**Command vs CLAUDE.md:** Command is a prompt you explicitly invoke when needed. CLAUDE.md is context automatically loaded at the start of every conversation.
|
||||
|
||||
**Command vs Just Typing:** Command saves typing for repeated prompts, shareable via git. Typing is appropriate for one-off requests or things you don't repeat.
|
||||
|
||||
## What Matters When Generating Command Prompts
|
||||
|
||||
When your prompt-writing skill generates a prompt for a command, it should:
|
||||
|
||||
**Understand the use case:** Is this a repeated workflow? Does it need parameters?
|
||||
|
||||
**Be complete:** The prompt should contain all instructions needed. Commands don't have special powers - they're just text that becomes Claude's input.
|
||||
|
||||
**Use $ARGUMENTS appropriately:** If the workflow needs input, use `$ARGUMENTS`. If it doesn't, don't include it.
|
||||
|
||||
**Be explicit:** Commands execute exactly as written. Don't assume Claude will infer missing steps.
|
||||
|
||||
**Consider prompting techniques:** Commands can use any prompting strategy (CoT, Few-Shot, XML, etc.) - they're just prompts in files.
|
||||
|
||||
</commands>
|
||||
@@ -0,0 +1,87 @@
|
||||
<documents>
|
||||
|
||||
## Writing Reference Documents for Claude Code
|
||||
|
||||
Reference documents provide context that helps Claude Code understand projects. When generating prompts that create or improve reference documents, focus on making them useful without bloating context windows.
|
||||
|
||||
## File Reference Strategies
|
||||
|
||||
**In reference documents:**
|
||||
|
||||
Use plain paths (the default):
|
||||
|
||||
- In reference documents pointing to other docs
|
||||
- Troubleshooting guides that are conditionally relevant
|
||||
- Architecture documentation that applies to specific scenarios
|
||||
- Any "available if needed" reference
|
||||
- When you want Claude to decide based on the actual task
|
||||
|
||||
Avoid @ in reference docs - it force-loads content unnecessarily.
|
||||
|
||||
## Providing Context with Plain Paths
|
||||
|
||||
When using plain paths in reference documents, explain when the file is relevant so Claude knows when to read it.
|
||||
|
||||
**Good examples:**
|
||||
"For database migration failures, see docs/db-troubleshooting.md"
|
||||
"Authentication implementation details are in docs/auth-architecture.md"
|
||||
"If encountering FooBarError, consult docs/foobar-guide.md"
|
||||
|
||||
**Poor examples:**
|
||||
"See docs/troubleshooting.md" (no context about when)
|
||||
"@docs/troubleshooting.md" (forces load unnecessarily)
|
||||
"docs/file1.md, docs/file2.md, docs/file3.md" (just a list with no guidance)
|
||||
|
||||
## Progressive Disclosure
|
||||
|
||||
For complex reference docs, use progressive disclosure: overview first, details in XML-tagged sections.
|
||||
|
||||
Example: Overview paragraph explaining the system, then `<authentication_details>`, `<payment_processing>`, `<error_handling>` sections with specifics.
|
||||
|
||||
## What Makes Effective Reference Documents
|
||||
|
||||
**High-Value Content:**
|
||||
|
||||
- Project structure (where things live)
|
||||
- Conventions and patterns actually used
|
||||
- Architecture decisions with rationale
|
||||
- Domain-specific business concepts
|
||||
- Non-obvious behaviors
|
||||
- Where to find key functionality
|
||||
- Pointers to detailed docs (plain paths with context)
|
||||
|
||||
**Low-Value Content:**
|
||||
|
||||
- Obvious information about languages or frameworks
|
||||
- Rapidly changing information
|
||||
- Exhaustive details better kept elsewhere
|
||||
- Information obvious from code
|
||||
- Force-loaded content (via @) that's rarely needed
|
||||
|
||||
## Composition Guidance
|
||||
|
||||
**Default to Plain Paths:** Reference files without @. Provide context about when they're relevant. Let Claude decide when to read them.
|
||||
|
||||
**Be Specific:** Concrete facts beat vague descriptions. "JWT tokens expire after 1 hour" beats "modern auth patterns".
|
||||
|
||||
**Explain Relevance:** "For database migration errors, see docs/db-troubleshooting.md" tells Claude when that file matters.
|
||||
|
||||
**Stay Concise:** Every word should add value. Verbosity wastes context budget.
|
||||
|
||||
**Trust Claude's Judgment:** Plain paths let Claude determine what's relevant based on the actual task. This is usually better than forcing content into context upfront.
|
||||
|
||||
## Writing Prompts for Reference Documents
|
||||
|
||||
When generating a prompt that asks Claude Code to create or improve a reference document, include guidance on:
|
||||
|
||||
**Structure:** Overview first, details organized logically, progressive disclosure for complex topics
|
||||
|
||||
**Content Selection:** Focus on non-obvious information, explain the "why" not just "what"
|
||||
|
||||
**References:** Plain paths with context about when files are relevant
|
||||
|
||||
**Brevity:** Make every sentence count, remove redundancy, assume Claude knows common concepts
|
||||
|
||||
**Maintenance:** Write content that stays relevant, avoid time-sensitive details, make it easy to update
|
||||
|
||||
</documents>
|
||||
24
skills/prompt-writing/references/artifact-guides/skills.md
Normal file
24
skills/prompt-writing/references/artifact-guides/skills.md
Normal file
@@ -0,0 +1,24 @@
|
||||
<skills>
|
||||
|
||||
## SKILL.md Format
|
||||
|
||||
**Frontmatter (REQUIRED):**
|
||||
Two fields are mandatory:
|
||||
|
||||
- name: Unique identifier (lowercase, hyphens for spaces)
|
||||
- description: Complete description following this pattern:
|
||||
1. What the skill does
|
||||
2. When to use it (be specific about context)
|
||||
3. What it needs (when applicable)
|
||||
4. How to trigger it (specific phrases: "Trigger with phrases like '[action] [context]'")
|
||||
|
||||
Example: "Generates, analyzes, and optimizes prompts for skills, commands, subagents, reference docs, and free-form text. Use when generating prompt content, analyzing prompt files, or optimizing prompt text. Trigger with phrases like '[generate|analyze|optimize] prompt', '[generate|analyze|optimize] [file-path]', 'create [skill|command|subagent]'."
|
||||
|
||||
**Optional Frontmatter:**
|
||||
|
||||
- allowed-tools: Scope tool access (e.g., `allowed-tools: "Read, Bash(git:*)"`)
|
||||
|
||||
**Markdown Body (FLEXIBLE):**
|
||||
No required structure. Use any prompting strategy.
|
||||
|
||||
</skills>
|
||||
28
skills/prompt-writing/references/bloat.md
Normal file
28
skills/prompt-writing/references/bloat.md
Normal file
@@ -0,0 +1,28 @@
|
||||
## Avoiding Bloat
|
||||
|
||||
**Every sentence should earn its place by:**
|
||||
|
||||
- Teaching Claude something it doesn't know
|
||||
- Providing specific, actionable guidance
|
||||
- Clarifying ambiguity
|
||||
|
||||
**Common bloat patterns to detect:**
|
||||
|
||||
- Explaining what Claude already knows (what Python is, how APIs work)
|
||||
- Redundant instructions saying the same thing different ways
|
||||
- Vague generalizations instead of specific guidance
|
||||
- Over-explaining obvious concepts
|
||||
- Preambles that add no value ("It's important to note that...")
|
||||
|
||||
**When reviewing generated prompts, ask:**
|
||||
|
||||
- Does this sentence change Claude's behavior?
|
||||
- Would removing this make the prompt less effective?
|
||||
- Is this obvious from context?
|
||||
|
||||
**Context matters:**
|
||||
|
||||
- Skills can be longer (progressive disclosure)
|
||||
- Commands should be tight (they run repeatedly)
|
||||
- Documents vary by complexity
|
||||
- Subgents need enough context to decide
|
||||
79
skills/prompt-writing/references/claude-features.md
Normal file
79
skills/prompt-writing/references/claude-features.md
Normal file
@@ -0,0 +1,79 @@
|
||||
## Universal Features Available in All Prompts
|
||||
|
||||
These features are available in ALL prompt contexts (skills, commands, subagents, reference docs, free-form).
|
||||
|
||||
**CLAUDE.md Files:**
|
||||
Claude automatically loads CLAUDE.md files from current folder and up the directory tree. To use in prompts, reference explicitly when relevant: "Following the patterns in CLAUDE.md..." or "Check CLAUDE.md for project conventions."
|
||||
|
||||
**MCP Tools:**
|
||||
Available in any prompt context. Include in allowed-tools/tools fields: `allowed-tools: "Read, mcp__server__tool"`. Invoke explicitly when needed: "use your [mcp-server] to..."
|
||||
|
||||
**Skills:**
|
||||
Any prompt can invoke skills: "use your [skill-name] skill to..." Skills are auto-discovered but explicit invocation ensures activation.
|
||||
|
||||
**Subagents:**
|
||||
Any prompt can delegate to subagents: "use your [subagent-name] subagent to..." Available from any context.
|
||||
|
||||
**Progressive Disclosure:**
|
||||
Use XML tags to organize complex content Claude references as needed. Reduces initial context load. Pattern: overview first, details in `<section_name>` tags.
|
||||
|
||||
**File References:**
|
||||
- Plain path (`docs/file.md`): Claude reads if relevant
|
||||
- @ symbol (`@docs/file.md`): Force-loads into context immediately
|
||||
|
||||
---
|
||||
|
||||
## Self-Reflection When Generating Prompts
|
||||
|
||||
<claude_md_awareness>
|
||||
**When generating prompts:**
|
||||
|
||||
- If the prompt relates to established knowledge → leverage existing reference files (CLAUDE.md, project docs)
|
||||
- If repeated patterns emerge → recommend storing in appropriate reference files
|
||||
</claude_md_awareness>
|
||||
|
||||
<mcp_servers>
|
||||
**Self-Reflection on Available MCP Servers**
|
||||
Before generating a prompt, check available MCP servers and consider:
|
||||
|
||||
- Does the prompt's intent require external data/tools that an MCP provides?
|
||||
- Would delegating to an MCP server improve accuracy or capabilities?
|
||||
- Is the task complex enough to justify the token/time cost of MCP invocation?
|
||||
|
||||
**When Generating Prompts:**
|
||||
|
||||
- Check if available MCPs are useful to the task
|
||||
- Scope relevant MCPs in tool lists when appropriate (e.g., `allowed-tools: "Read, Write, mcp__playwright__navigate"`)
|
||||
- Include intentional invocation phrases when needed (e.g., "use your playwright mcp to navigate")
|
||||
|
||||
**Delegation Decision Framework:**
|
||||
|
||||
- Trivial tasks (simple lookups, basic operations) → Handle directly
|
||||
- Complex tasks (external data, specialized tools, multi-step) → Consider MCP delegation
|
||||
- Include MCP usage in generated prompts when it adds clear value
|
||||
</mcp_servers>
|
||||
|
||||
<subagents>
|
||||
**Self-Reflection on Available Subagents**
|
||||
Before generating a prompt, check available subagents (analyst, test-writer, implementer, validator, reviewer, etc.) and consider:
|
||||
- Does the prompt's intent map to a specialized subagent's domain?
|
||||
- Would delegating to a subagent improve quality or efficiency?
|
||||
- Is the task complex enough to justify the token/time cost of subagent invocation?
|
||||
|
||||
**Delegation Decision Framework:**
|
||||
|
||||
- Simple tasks (single-step, straightforward) → Handle directly
|
||||
- Specialized tasks (analysis, testing, validation) → Consider subagent delegation
|
||||
- Multi-phase tasks → Recommend subagent orchestration in the generated prompt
|
||||
</subagents>
|
||||
|
||||
<existing_skills>
|
||||
**Self-Reflection on Available Skills**
|
||||
Before generating a prompt from scratch, check if existing skills can be:
|
||||
|
||||
- Used directly (the skill already solves this)
|
||||
- Composed together (combine multiple skills)
|
||||
- Referenced as patterns (use similar structure/approach)
|
||||
|
||||
Recommend skill composition when multiple skills can work together to achieve the intent.
|
||||
</existing_skills>
|
||||
40
skills/prompt-writing/references/decision-framework.md
Normal file
40
skills/prompt-writing/references/decision-framework.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# Decision Framework
|
||||
|
||||
## Start Here: Natural Language
|
||||
|
||||
Every prompt should begin with clear, direct natural language instructions. This is your baseline.
|
||||
|
||||
## Then Ask: Would a prompting technique help?
|
||||
|
||||
- Complex reasoning needed? Consider CoT
|
||||
- Need specific format/style? Consider Few-Shot
|
||||
- Multiple types of information? Consider XML separation
|
||||
- Already clear and effective? Stop, you're done
|
||||
|
||||
## Then Ask: Would Claude Code features help in the prompt content?
|
||||
|
||||
- Should this prompt reference CLAUDE.md knowledge?
|
||||
- Should this prompt invoke existing skills?
|
||||
- Should this prompt delegate to subagents?
|
||||
- Should this prompt invoke MCP tools?
|
||||
- Complex structure? Use XML tags for progressive disclosure
|
||||
|
||||
## Principle: Less is More
|
||||
|
||||
Don't add techniques just because you can. Add them when they solve a specific problem. Most prompts work best with just clear natural language.
|
||||
|
||||
## Skill Invocation Patterns
|
||||
|
||||
For skills, include trigger phrases to ensure intentional activation:
|
||||
|
||||
- "use your [skill-name] to..."
|
||||
- "use the [skill-name] for..."
|
||||
- Include trigger words from skill description
|
||||
|
||||
For subagents, use clear delegation language:
|
||||
|
||||
- "use your [subagent-name] subagent to..."
|
||||
- "use the [subagent-name] subagent for..."
|
||||
- Match language to subagent's description triggers
|
||||
|
||||
Claude auto-discovers skills and subagents but may skip them without explicit triggers in the prompt.
|
||||
@@ -0,0 +1,66 @@
|
||||
## Command Examples
|
||||
|
||||
**Good Command with $ARGUMENTS:**
|
||||
|
||||
```
|
||||
Analyze GitHub issue $ARGUMENTS and implement a fix:
|
||||
|
||||
1. Run `gh issue view $ARGUMENTS` to read the issue
|
||||
2. Identify the root cause
|
||||
3. Write tests that reproduce the bug
|
||||
4. Implement the fix
|
||||
5. Verify tests pass
|
||||
6. Comment on the issue with your solution
|
||||
```
|
||||
|
||||
Why it works: Flexible with any issue number, treats all input as one string.
|
||||
Usage: /fix-issue 123
|
||||
|
||||
**Good Command with Positional Parameters:**
|
||||
|
||||
```
|
||||
Review PR #$1 with priority $2 and assign to $3.
|
||||
|
||||
Focus on:
|
||||
- Security vulnerabilities
|
||||
- Performance implications
|
||||
- Code style consistency
|
||||
|
||||
Report findings and tag $3 for follow-up.
|
||||
```
|
||||
|
||||
Why it works: Accesses each argument individually for different purposes.
|
||||
Usage: /review-pr 456 high alice
|
||||
|
||||
**When to use each:**
|
||||
|
||||
$ARGUMENTS: When you want all input as a single value (issue numbers, commit messages, search queries)
|
||||
|
||||
$1, $2, $3: When you need to handle multiple distinct pieces of information (PR number + priority + assignee, or feature name + test type + output format)
|
||||
|
||||
**Bad Command:**
|
||||
|
||||
```
|
||||
Fix the bug.
|
||||
```
|
||||
|
||||
Why it's bad: No process, no context, too vague.
|
||||
|
||||
**Good Command:**
|
||||
|
||||
```
|
||||
Implement the feature using test-driven development:
|
||||
|
||||
1. Read the feature description from work-items.md
|
||||
2. Write a failing test that verifies the feature
|
||||
3. Run the test to confirm it fails
|
||||
4. Write minimal code to make the test pass
|
||||
5. Run tests to verify they pass
|
||||
6. Run full test suite to check for regressions
|
||||
7. Update scratchpad with progress
|
||||
|
||||
If stuck after 3 attempts, log the blocker and ask for guidance.
|
||||
```
|
||||
|
||||
Why it works: Clear steps, explicit process, handles failure.
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
## Document Examples
|
||||
|
||||
**Good Documentation Prompt:**
|
||||
|
||||
```
|
||||
Document the authentication system for our Rails API. Include:
|
||||
|
||||
1. Overview: How authentication works in our system
|
||||
2. Setup: How to configure authentication for a new service
|
||||
3. Usage: How to authenticate requests (with code examples)
|
||||
4. Token management: How tokens are created, refreshed, and revoked
|
||||
5. Security considerations: Best practices and common pitfalls
|
||||
|
||||
Write in clear prose with code examples. Assume the reader is a developer familiar with Rails but new to our codebase.
|
||||
```
|
||||
|
||||
Why it works: Clear scope, specific sections, target audience defined.
|
||||
|
||||
**Bad Documentation Prompt:**
|
||||
|
||||
```
|
||||
Write docs about the auth system.
|
||||
```
|
||||
|
||||
Why it's bad: No scope, no structure, no audience.
|
||||
|
||||
## Reference Document Examples
|
||||
|
||||
**Good Reference (using plain paths):**
|
||||
|
||||
```
|
||||
# Project Context
|
||||
|
||||
This is a Rails subscription management app.
|
||||
|
||||
## Architecture
|
||||
- Authentication: app/services/auth/
|
||||
- Payments: app/services/payments/ using Stripe
|
||||
- Background jobs: app/jobs/ using Sidekiq
|
||||
|
||||
## Conventions
|
||||
- Use RSpec with AAA pattern
|
||||
- Services are single-purpose classes
|
||||
- API uses JSON:API format
|
||||
|
||||
## Troubleshooting
|
||||
For authentication errors, see docs/auth-troubleshooting.md
|
||||
For payment issues, see docs/payment-debugging.md
|
||||
```
|
||||
|
||||
Why it works: Concise essentials, points to detailed docs with plain paths.
|
||||
|
||||
**Bad Reference (forcing imports when not necessary):**
|
||||
|
||||
```
|
||||
# Project Context
|
||||
|
||||
@docs/architecture.md
|
||||
@docs/conventions.md
|
||||
@docs/troubleshooting.md
|
||||
@docs/payment-guide.md
|
||||
@docs/testing-guide.md
|
||||
```
|
||||
|
||||
Why it's bad: Forces all content into context immediately, bloats context window.
|
||||
|
||||
38
skills/prompt-writing/references/examples/skill-examples.md
Normal file
38
skills/prompt-writing/references/examples/skill-examples.md
Normal file
@@ -0,0 +1,38 @@
|
||||
## Skill Examples
|
||||
|
||||
**Good Skill Structure:**
|
||||
|
||||
```
|
||||
---
|
||||
name: testing-guide
|
||||
description: Guidance on writing effective tests using RSpec and TDD practices
|
||||
---
|
||||
|
||||
# Testing Guide
|
||||
|
||||
This skill provides testing guidance for Rails applications using RSpec.
|
||||
|
||||
## Quick Reference
|
||||
- Use descriptive test names
|
||||
- Follow AAA pattern (Arrange, Act, Assert)
|
||||
- Mock external dependencies
|
||||
- Test behavior, not implementation
|
||||
|
||||
<aaa_pattern>
|
||||
## Arrange-Act-Assert Pattern
|
||||
|
||||
Structure tests in three clear phases:
|
||||
- Arrange: Set up test data and conditions
|
||||
- Act: Execute the code being tested
|
||||
- Assert: Verify the results
|
||||
|
||||
Example: [concrete example here]
|
||||
</aaa_pattern>
|
||||
|
||||
<mocking>
|
||||
[Detailed guidance on mocking...]
|
||||
</mocking>
|
||||
```
|
||||
|
||||
Why it works: Overview first, progressive disclosure for details.
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
## Subagent Examples
|
||||
|
||||
**Good Subagent:**
|
||||
|
||||
```
|
||||
---
|
||||
name: test-runner
|
||||
description: Use PROACTIVELY after code changes to run tests and fix failures. Analyzes test output and provides fixes.
|
||||
tools: Read, Bash, Grep
|
||||
model: inherit
|
||||
---
|
||||
|
||||
You are a test runner specialist. When invoked:
|
||||
|
||||
1. Run the appropriate test suite for changed files
|
||||
2. If tests pass, report success
|
||||
3. If tests fail:
|
||||
- Analyze the failure output
|
||||
- Identify the root cause
|
||||
- Propose a fix
|
||||
- Implement the fix if within your capability
|
||||
- Re-run tests to verify
|
||||
|
||||
Constraints:
|
||||
- Never skip tests
|
||||
- Always run full suite after fixes
|
||||
- If stuck after 3 attempts, report the blocker clearly
|
||||
|
||||
Output Format:
|
||||
- Test results summary
|
||||
- Failures with root cause
|
||||
- Fixes applied
|
||||
- Final status
|
||||
```
|
||||
|
||||
Why it works: Clear trigger in description, specific workflow, appropriate tools, handles failure.
|
||||
|
||||
**Bad Subagent:**
|
||||
|
||||
```
|
||||
---
|
||||
name: helper
|
||||
description: Helps with stuff
|
||||
---
|
||||
|
||||
You help with coding tasks.
|
||||
```
|
||||
|
||||
Why it's bad: Vague description (no trigger conditions), vague purpose, no workflow.
|
||||
|
||||
</examples>
|
||||
@@ -0,0 +1,79 @@
|
||||
<examples>
|
||||
|
||||
## Chain-of-Thought Examples
|
||||
|
||||
**Good CoT Prompt:**
|
||||
"A train travels 120 miles in 2 hours, then 180 miles in 3 hours. What is its average speed for the entire journey? Think through this step by step, showing your calculations."
|
||||
|
||||
Why it works: Complex calculation benefits from showing intermediate steps.
|
||||
|
||||
**Bad CoT Prompt:**
|
||||
"What is 5 + 3? Think step by step."
|
||||
|
||||
Why it's bad: Trivial calculation doesn't benefit from step-by-step reasoning.
|
||||
|
||||
## Few-Shot Examples
|
||||
|
||||
**Good Few-Shot Prompt:**
|
||||
|
||||
```
|
||||
Convert user stories into test descriptions:
|
||||
|
||||
Example 1:
|
||||
User Story: As a user, I want to reset my password so I can regain access
|
||||
Test: User can request password reset and receive email with reset link
|
||||
|
||||
Example 2:
|
||||
User Story: As an admin, I want to deactivate accounts so I can manage access
|
||||
Test: Admin can deactivate user account and user loses access
|
||||
|
||||
Now convert:
|
||||
User Story: As a user, I want to filter search results by date
|
||||
```
|
||||
|
||||
Why it works: Format transformation isn't obvious, examples show the pattern.
|
||||
|
||||
**Bad Few-Shot Prompt:**
|
||||
|
||||
```
|
||||
Write Python functions.
|
||||
|
||||
Example: def add(a, b): return a + b
|
||||
|
||||
Now write a multiply function.
|
||||
```
|
||||
|
||||
Why it's bad: Writing basic functions is standard knowledge, examples add no value.
|
||||
|
||||
## XML Context Separation Examples
|
||||
|
||||
**Good XML Usage:**
|
||||
|
||||
```
|
||||
<codebase_context>
|
||||
Rails app using RSpec for testing, FactoryBot for test data, Pundit for authorization
|
||||
</codebase_context>
|
||||
|
||||
<work_items>
|
||||
1. Add admin role
|
||||
2. Restrict user deletion to admins
|
||||
3. Add admin dashboard
|
||||
</work_items>
|
||||
|
||||
<instructions>
|
||||
For each work item, follow TDD: write failing test, implement feature, verify tests pass
|
||||
</instructions>
|
||||
```
|
||||
|
||||
Why it works: Three distinct information types clearly separated.
|
||||
|
||||
**Bad XML Usage:**
|
||||
|
||||
```
|
||||
<instructions>
|
||||
Write code that works and follows our standards.
|
||||
</instructions>
|
||||
```
|
||||
|
||||
Why it's bad: Single vague piece of information doesn't need XML.
|
||||
|
||||
246
skills/prompt-writing/references/techniques-catalog.md
Normal file
246
skills/prompt-writing/references/techniques-catalog.md
Normal file
@@ -0,0 +1,246 @@
|
||||
<technique_catalog>
|
||||
|
||||
## Chain-of-Thought (CoT)
|
||||
|
||||
**Definition:** Prompting the model to show its reasoning process step-by-step before arriving at a final answer.
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Complex reasoning tasks (math, logic, multi-step problems)
|
||||
- When you need to verify the thinking process
|
||||
- Debugging scenarios where understanding the approach matters
|
||||
- Planning or analysis tasks
|
||||
- When the path to the answer is as important as the answer itself
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- Add explicit instructions: "Think step by step", "Explain your reasoning", "Break this down"
|
||||
- Ask for intermediate steps before the final answer
|
||||
- Request the model to show its work
|
||||
- Use phrases like "Before answering, consider..." or "Let's work through this systematically"
|
||||
|
||||
**Pattern Example:**
|
||||
"Before providing the solution, think through this step by step:
|
||||
|
||||
1. What is the core problem?
|
||||
2. What information do we have?
|
||||
3. What approach should we take?
|
||||
4. Now solve it."
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Simple, direct questions where step-by-step reasoning adds no value
|
||||
- When speed is more important than seeing the reasoning
|
||||
- Factual lookups that don't require analysis
|
||||
|
||||
---
|
||||
|
||||
## Few-Shot Prompting
|
||||
|
||||
**Definition:** Providing 2-5 examples of the desired input/output pattern before asking the model to perform the actual task.
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- When you need a specific format or structure that's hard to describe
|
||||
- Teaching a particular style, tone, or convention
|
||||
- Complex transformations where examples clarify intent better than instructions
|
||||
- When zero-shot attempts produce inconsistent results
|
||||
- Domain-specific patterns or formats
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- Show 2-5 clear examples (not just one, not too many)
|
||||
- Ensure examples cover variations or edge cases
|
||||
- Make the pattern obvious and consistent across examples
|
||||
- Clearly separate examples from the actual task
|
||||
- Use consistent formatting for input/output in examples
|
||||
|
||||
**Pattern Example:**
|
||||
"Here are examples of the format I need:
|
||||
|
||||
Example 1:
|
||||
Input: Added user authentication
|
||||
Output: feat(auth): implement user login and session management
|
||||
|
||||
Example 2:
|
||||
Input: Fixed bug in payment processing
|
||||
Output: fix(payments): resolve currency conversion error
|
||||
|
||||
Example 3:
|
||||
Input: Updated documentation for API
|
||||
Output: docs(api): clarify authentication endpoints
|
||||
|
||||
Now format this:
|
||||
Input: [actual task]"
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Simple, self-explanatory tasks
|
||||
- When examples might unnecessarily constrain creativity
|
||||
- When the task is well-known and standard (like "write a Python function")
|
||||
- When you want the model to be innovative rather than imitative
|
||||
|
||||
---
|
||||
|
||||
## Zero-Shot Prompting
|
||||
|
||||
**Definition:** Directly asking the model to perform a task without providing examples, relying on its training and clear instructions.
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Simple, straightforward tasks
|
||||
- When the model already knows the pattern well (standard coding tasks, common formats)
|
||||
- General knowledge questions
|
||||
- When you want unconstrained, creative responses
|
||||
- Standard operations that are well-documented in the model's training
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- Clear, direct instruction
|
||||
- Explicit about format and requirements
|
||||
- Provide necessary context
|
||||
- Be specific but trust the model's existing knowledge
|
||||
- Assume model competence for standard tasks
|
||||
|
||||
**Pattern Example:**
|
||||
"Write a Python function that calculates the factorial of a number. Use recursion and include docstrings."
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Highly specialized formats or patterns
|
||||
- When you've observed the model struggle with similar tasks
|
||||
- Domain-specific conventions that aren't widely known
|
||||
- When consistency with a specific style is critical
|
||||
|
||||
---
|
||||
|
||||
## ReAct (Reason + Act)
|
||||
|
||||
**Definition:** An agent architecture pattern where the model alternates between reasoning about what to do (Thought) and taking actions (using tools/functions), forming a loop until the task is complete.
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Multi-step tasks requiring external information or tools
|
||||
- Agent-based workflows
|
||||
- Tasks that need dynamic decision-making based on intermediate results
|
||||
- When the path to solution isn't predetermined
|
||||
- Complex problem-solving requiring tool use
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- Note: This is typically the underlying architecture in agentic systems like Claude Code, not something you explicitly prompt for
|
||||
- When writing prompts for agents, structure tasks to support the Thought→Action→Observation cycle
|
||||
- Provide clear tool descriptions
|
||||
- Allow for iterative refinement
|
||||
- Don't over-constrain the agent's decision-making process
|
||||
|
||||
**Pattern Example (in agent context):**
|
||||
"Analyze the codebase to find performance bottlenecks. Use available tools to:
|
||||
|
||||
1. Profile the application
|
||||
2. Identify slow functions
|
||||
3. Propose optimizations
|
||||
Work through this systematically, using tools as needed."
|
||||
|
||||
**Understanding the Flow:**
|
||||
|
||||
- Thought: "I need to profile the application first"
|
||||
- Action: Run profiler tool
|
||||
- Observation: Results show function X is slow
|
||||
- Thought: "I should examine function X's implementation"
|
||||
- Action: Read function X code
|
||||
- Observation: See the implementation
|
||||
- Thought: "I can optimize this by..."
|
||||
- Continue until complete
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Single-step tasks that don't require tools
|
||||
- When you want a specific predetermined sequence
|
||||
- Tasks that don't benefit from dynamic decision-making
|
||||
|
||||
---
|
||||
|
||||
## System vs User Message Separation
|
||||
|
||||
**Definition:** Separating persistent instructions and role definition (system message) from the specific task or query (user message).
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Always, when the platform supports it
|
||||
- Setting persistent behavior, tone, or constraints
|
||||
- Defining the model's role or expertise
|
||||
- Providing context that applies across multiple interactions
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- System message: Role, behavior rules, constraints, general context
|
||||
- User message: Specific task, query, or request
|
||||
- Keep system concise but complete
|
||||
- Put task-specific details in user message
|
||||
|
||||
**Pattern Example:**
|
||||
System: "You are a senior Python developer who writes clean, well-documented code following PEP 8 standards. Always include type hints and docstrings."
|
||||
User: "Write a function to parse CSV files and return a list of dictionaries."
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Platforms that don't support system/user distinction
|
||||
- When all context is task-specific (no persistent instructions needed)
|
||||
|
||||
---
|
||||
|
||||
## XML for Context Separation
|
||||
|
||||
**Definition:** Using XML-style tags to separate different types of information in a prompt (Anthropic-specific best practice).
|
||||
|
||||
**When to Use:**
|
||||
|
||||
- Complex prompts with multiple types of information
|
||||
- When you need to clearly separate documents, examples, instructions, and context
|
||||
- Providing multiple source documents that the model should reference
|
||||
- Creating clear boundaries between different information types
|
||||
- When you want the model to treat different sections differently
|
||||
|
||||
**How to Implement:**
|
||||
|
||||
- Wrap distinct information types in descriptive XML tags
|
||||
- Use tags like: <instructions>, <examples>, <documents>, <context>, <constraints>
|
||||
- Keep tag names semantic and clear
|
||||
- Don't over-nest unnecessarily
|
||||
|
||||
**Pattern Example:**
|
||||
<context>
|
||||
This is a Rails application using RSpec for testing.
|
||||
We follow the AAA pattern (Arrange, Act, Assert).
|
||||
</context>
|
||||
|
||||
<examples>
|
||||
<example>
|
||||
describe "User registration" do
|
||||
it "creates a new user with valid params" do
|
||||
# Arrange
|
||||
params = { email: "test@example.com", password: "secure123" }
|
||||
|
||||
# Act
|
||||
user = User.create(params)
|
||||
|
||||
# Assert
|
||||
expect(user).to be_persisted
|
||||
end
|
||||
end
|
||||
</example>
|
||||
</examples>
|
||||
|
||||
<instructions>
|
||||
Write RSpec tests for the password reset feature.
|
||||
Follow the AAA pattern shown in the examples.
|
||||
</instructions>
|
||||
|
||||
**When NOT to Use:**
|
||||
|
||||
- Simple prompts with one type of information
|
||||
- When natural language separation is sufficient
|
||||
- Over-structuring simple requests (adds noise without benefit)
|
||||
|
||||
</technique_catalog>
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: [What this command does - shown in /help]
|
||||
argument-hint: [Example arguments shown to user]
|
||||
allowed-tools: [Comma-separated list of tools, or "all" or omit for all tools]
|
||||
model: [claude-3-5-sonnet-20241022, claude-3-5-haiku-20241022, or omit to inherit]
|
||||
disable-model-invocation: [true/false - set true for simple template expansion]
|
||||
---
|
||||
|
||||
[Command instructions that Claude will receive when this command is invoked]
|
||||
|
||||
[Use $ARGUMENTS to capture all arguments as a single string]
|
||||
[Use $1, $2, $3 for positional parameters]
|
||||
[Use ! prefix for bash commands: !git status]
|
||||
[Use @ prefix to include file contents: @path/to/file.md]
|
||||
|
||||
[Step-by-step process if needed]
|
||||
|
||||
[Expected output or deliverables]
|
||||
@@ -0,0 +1,22 @@
|
||||
# [Document Title]
|
||||
|
||||
[Brief overview of what this reference document covers]
|
||||
|
||||
## [Section 1]
|
||||
|
||||
- [Key information 1]
|
||||
- [Key information 2]
|
||||
- [Plain path references to detailed docs if needed: docs/detailed-guide.md]
|
||||
|
||||
## [Section 2]
|
||||
|
||||
- [Important concept 1]
|
||||
- [Important concept 2]
|
||||
|
||||
## [Section 3]
|
||||
|
||||
[Guidance or conventions]
|
||||
|
||||
## [Optional: Troubleshooting or Additional Resources]
|
||||
|
||||
For [specific issue], see [plain path to relevant doc]
|
||||
31
skills/prompt-writing/references/templates/skill-template.md
Normal file
31
skills/prompt-writing/references/templates/skill-template.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: [skill-name]
|
||||
description: [Brief description of what this skill provides]
|
||||
# allowed-tools: "Read, Write, Bash" # Optional: scope to specific tools when needed
|
||||
---
|
||||
|
||||
# [Skill Title]
|
||||
|
||||
[Brief overview of what this skill provides]
|
||||
|
||||
## Quick Reference
|
||||
|
||||
- [Key point 1]
|
||||
- [Key point 2]
|
||||
- [Key point 3]
|
||||
|
||||
<section_name>
|
||||
|
||||
## [Section Title]
|
||||
|
||||
[Detailed content for this section]
|
||||
|
||||
[Examples or additional context]
|
||||
</section_name>
|
||||
|
||||
<another_section>
|
||||
|
||||
## [Another Section Title]
|
||||
|
||||
[More detailed guidance...]
|
||||
</another_section>
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
name: [subagent-name]
|
||||
description: [Clear description with trigger conditions. Include "Use PROACTIVELY" if appropriate]
|
||||
tools: [Comma-separated list: Read, Write, Edit, Bash, Grep, Glob, etc.]
|
||||
model: [claude-3-5-sonnet-20241022, claude-3-5-haiku-20241022, or "inherit"]
|
||||
---
|
||||
|
||||
You are a [role/specialist]. When invoked:
|
||||
|
||||
1. [First step in workflow]
|
||||
2. [Second step]
|
||||
3. [Third step]
|
||||
- [Sub-step if needed]
|
||||
- [Another sub-step]
|
||||
|
||||
Constraints:
|
||||
- [Important constraint 1]
|
||||
- [Important constraint 2]
|
||||
- [Failure handling: e.g., "If stuck after N attempts, report the blocker clearly"]
|
||||
|
||||
Output Format:
|
||||
- [What to include in output 1]
|
||||
- [What to include in output 2]
|
||||
- [What to include in output 3]
|
||||
Reference in New Issue
Block a user