merging stuff from my joplin notes
This commit is contained in:
8
MCP/LLM Scaffolding/MCP/Basic Memory.md
Executable file
8
MCP/LLM Scaffolding/MCP/Basic Memory.md
Executable file
@@ -0,0 +1,8 @@
|
|||||||
|
Basic Memory
|
||||||
|
|
||||||
|
- URLs:
|
||||||
|
- https://memory.basicmachines.co/integrations/claude-desktop
|
||||||
|
- https://github.com/basicmachines-co/basic-memory
|
||||||
|
- https://www.reddit.com/r/ClaudeAI/comments/1jdga7v/basic_memory_a_tool_that_gives_claude_persistent/
|
||||||
|
|
||||||
|
- Status: Installed/integrated with Claude Desktop
|
||||||
4
MCP/LLM Scaffolding/MCP/Cloudron.md
Executable file
4
MCP/LLM Scaffolding/MCP/Cloudron.md
Executable file
@@ -0,0 +1,4 @@
|
|||||||
|
Cloudron
|
||||||
|
|
||||||
|
URL: https://git.cloudron.io/playground/toy-mcp-server/
|
||||||
|
Status: cloned, deps installed, not yet hooked to Claude Desktop
|
||||||
26
MCP/LLM Scaffolding/MCP/Joplin.md
Executable file
26
MCP/LLM Scaffolding/MCP/Joplin.md
Executable file
@@ -0,0 +1,26 @@
|
|||||||
|
- URLs:
|
||||||
|
- https://mcpmarket.com/server/joplin
|
||||||
|
- https://github.com/dweigend/joplin-mcp-server
|
||||||
|
|
||||||
|
- Here is the config:
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"mcpServers": {
|
||||||
|
"joplin": {
|
||||||
|
"command":"C:\\Users\\tsys\\.local\\bin\\uv.exe",
|
||||||
|
"args": [
|
||||||
|
"--directory",
|
||||||
|
"E:/tsys/LLM/MCP/joplin-mcp-server",
|
||||||
|
"run",
|
||||||
|
"src/mcp/joplin_mcp.py"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
- Status: Configured and deployed in Claude Desktop
|
||||||
|
|
||||||
|
Here is the successful execution:
|
||||||
|
|
||||||
|
|
||||||
20
MCP/LLM Scaffolding/MCP/Redmine.md
Executable file
20
MCP/LLM Scaffolding/MCP/Redmine.md
Executable file
@@ -0,0 +1,20 @@
|
|||||||
|
Redmine
|
||||||
|
|
||||||
|
- URL: https://github.com/runekaagaard/mcp-redmine
|
||||||
|
- Status: Configured and deployed in Claude Desktop
|
||||||
|
|
||||||
|
- Here is the config:
|
||||||
|
```json
|
||||||
|
"redmine": {
|
||||||
|
"command": "uvx",
|
||||||
|
"args": ["--from", "mcp-redmine==2025.04.09.153531",
|
||||||
|
"--refresh-package", "mcp-redmine", "mcp-redmine"],
|
||||||
|
"env": {
|
||||||
|
"REDMINE_URL": "https://projects.knownelement.com",
|
||||||
|
"REDMINE_API_KEY": "[redacted]",
|
||||||
|
"REDMINE_REQUEST_INSTRUCTIONS": "E:/tsys/LLM/MCP/redmine-mcp-server/instructions.md"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
BIN
MCP/_resources/6e5ad57ec0bb70995a2ab92d65844308.png
Executable file
BIN
MCP/_resources/6e5ad57ec0bb70995a2ab92d65844308.png
Executable file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
@@ -0,0 +1,164 @@
|
|||||||
|
# Artifact Structure Guide
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This guide establishes standard formats for creating both human-optimized and Claude-optimized artifacts to ensure consistency and effectiveness in document engineering projects.
|
||||||
|
|
||||||
|
## COMMON ELEMENTS FOR ALL ARTIFACTS
|
||||||
|
|
||||||
|
### 1. METADATA HEADER
|
||||||
|
All artifacts must include:
|
||||||
|
```
|
||||||
|
# [Artifact Title]
|
||||||
|
Version: [Version Number] ([Date in YYYY-MM-DD format])
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. VERSION CONTROL
|
||||||
|
Version numbering follows semantic versioning:
|
||||||
|
- Major version (1.0): Significant structural changes
|
||||||
|
- Minor version (0.1): Content updates that maintain structure
|
||||||
|
- Patch version (0.0.1): Small corrections or clarifications
|
||||||
|
|
||||||
|
### 3. CROSS-REFERENCES
|
||||||
|
End each artifact with related documents:
|
||||||
|
```
|
||||||
|
---
|
||||||
|
*Cross-reference with: [Related Artifact 1], [Related Artifact 2]*
|
||||||
|
```
|
||||||
|
|
||||||
|
## HUMAN-OPTIMIZED ARTIFACTS
|
||||||
|
|
||||||
|
These artifacts are designed for human readability and use.
|
||||||
|
|
||||||
|
### Structure Guidelines
|
||||||
|
|
||||||
|
1. **Hierarchical Organization**
|
||||||
|
- Use consistent header levels (H1 for title, H2 for major sections, etc.)
|
||||||
|
- Limited to 3 levels of nesting for readability
|
||||||
|
- Each level should have 2-7 subsections maximum
|
||||||
|
|
||||||
|
2. **Visual Elements**
|
||||||
|
- Use tables for comparing multiple items
|
||||||
|
- Use bulleted lists for unordered collections
|
||||||
|
- Use numbered lists for sequential instructions
|
||||||
|
- Use code blocks for templates, examples, or fill-in sections
|
||||||
|
|
||||||
|
3. **Navigation Aids**
|
||||||
|
- Include a brief purpose statement at the top
|
||||||
|
- Add a table of contents for documents over 2 pages
|
||||||
|
- Use horizontal rules to separate major sections
|
||||||
|
|
||||||
|
4. **Actionable Components**
|
||||||
|
- Include checkboxes for completion tracking
|
||||||
|
- Clearly mark required vs. optional elements
|
||||||
|
- Provide example text in italics or gray formatting
|
||||||
|
|
||||||
|
### Example Format
|
||||||
|
```markdown
|
||||||
|
# Artifact Title
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
Brief description of the artifact's intended use and value.
|
||||||
|
|
||||||
|
## SECTION ONE
|
||||||
|
Main content organized with:
|
||||||
|
- Bullet points for collections
|
||||||
|
- Tables for comparisons
|
||||||
|
- Code blocks for templates
|
||||||
|
|
||||||
|
### Subsection
|
||||||
|
More detailed content with specific guidelines.
|
||||||
|
|
||||||
|
## SECTION TWO
|
||||||
|
Additional structured content.
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Related Artifact 1, Related Artifact 2*
|
||||||
|
```
|
||||||
|
|
||||||
|
## CLAUDE-OPTIMIZED ARTIFACTS
|
||||||
|
|
||||||
|
These artifacts are designed to be optimally processed by Claude.
|
||||||
|
|
||||||
|
### Structure Guidelines
|
||||||
|
|
||||||
|
1. **Clear Demarcation**
|
||||||
|
- Use XML-style tags to clearly indicate sections
|
||||||
|
- Include role specifications when applicable
|
||||||
|
- Separate instructions from examples with clear markers
|
||||||
|
|
||||||
|
2. **Processing Instructions**
|
||||||
|
- Place critical instructions at the beginning
|
||||||
|
- Use numbered lists for sequential processing steps
|
||||||
|
- Mark optional paths with explicit conditionals
|
||||||
|
- Include stop conditions for iterative processes
|
||||||
|
|
||||||
|
3. **Context Management**
|
||||||
|
- Group related information within single sections
|
||||||
|
- Label sections with descriptive IDs for reference
|
||||||
|
- Include summary sections for complex content
|
||||||
|
- Maintain consistent terminology throughout
|
||||||
|
|
||||||
|
4. **Output Formatting**
|
||||||
|
- Specify desired output structure explicitly
|
||||||
|
- Include sample outputs with annotations
|
||||||
|
- Define error handling and fallback options
|
||||||
|
- Provide quantitative requirements (length, detail level)
|
||||||
|
|
||||||
|
### Example Format
|
||||||
|
```
|
||||||
|
<ARTIFACT id="example_artifact" version="1.0" date="2025-03-25">
|
||||||
|
|
||||||
|
<PURPOSE>
|
||||||
|
Precisely defined purpose statement with success criteria.
|
||||||
|
</PURPOSE>
|
||||||
|
|
||||||
|
<INSTRUCTIONS>
|
||||||
|
1. First processing step with specific guidance
|
||||||
|
2. Second processing step with decision points
|
||||||
|
3. Third processing step with output requirements
|
||||||
|
</INSTRUCTIONS>
|
||||||
|
|
||||||
|
<CONTEXT id="domain_knowledge">
|
||||||
|
Essential information Claude needs to understand the domain.
|
||||||
|
</CONTEXT>
|
||||||
|
|
||||||
|
<EXAMPLES>
|
||||||
|
<EXAMPLE id="example1">
|
||||||
|
Input: Sample input
|
||||||
|
Expected output: Sample output
|
||||||
|
Explanation: Why this output meets requirements
|
||||||
|
</EXAMPLE>
|
||||||
|
</EXAMPLES>
|
||||||
|
|
||||||
|
<OUTPUT_REQUIREMENTS>
|
||||||
|
- Format specification
|
||||||
|
- Content requirements
|
||||||
|
- Quality indicators
|
||||||
|
- Error handling procedures
|
||||||
|
</OUTPUT_REQUIREMENTS>
|
||||||
|
|
||||||
|
</ARTIFACT>
|
||||||
|
```
|
||||||
|
|
||||||
|
## HYBRID ARTIFACT APPROACH
|
||||||
|
|
||||||
|
For optimal results in document engineering projects:
|
||||||
|
|
||||||
|
1. **Create human-optimized artifacts first** for team review and approval
|
||||||
|
2. **Derive Claude-optimized versions** for implementation
|
||||||
|
3. **Maintain both versions** with synchronized updates
|
||||||
|
4. **Test Claude-optimized artifacts** with various inputs
|
||||||
|
5. **Document transformation patterns** between human and Claude versions
|
||||||
|
|
||||||
|
## RECOMMENDED ARTIFACT TYPES
|
||||||
|
|
||||||
|
1. **Templates**: Structured outlines for creating consistent documents
|
||||||
|
2. **Checklists**: Sequential verification steps to ensure quality
|
||||||
|
3. **Protocols**: Standardized procedures for handling specific scenarios
|
||||||
|
4. **Repositories**: Collections of reusable components or examples
|
||||||
|
5. **Indices**: Catalogs of available artifacts with access information
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Terminology Bank, Validation Checklist, Comprehensive Templates Index*
|
||||||
183
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Complete Workflow.md
Executable file
183
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Complete Workflow.md
Executable file
@@ -0,0 +1,183 @@
|
|||||||
|
# Complete Workflow
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This workflow provides a comprehensive overview of the two-step document prompt engineering process, from initial requirement gathering through implementation and maintenance.
|
||||||
|
|
||||||
|
## TWO-STEP PROCESS OVERVIEW
|
||||||
|
|
||||||
|
The document prompt engineering process consists of two primary phases:
|
||||||
|
|
||||||
|
1. **Initial Prompt Engineering**: Focused on requirements gathering, analysis, and initial prompt creation
|
||||||
|
2. **Prompt Review**: Focused on evaluation, refinement, and optimization
|
||||||
|
|
||||||
|
This separation ensures thorough exploration followed by targeted improvement.
|
||||||
|
|
||||||
|
## DETAILED WORKFLOW
|
||||||
|
|
||||||
|
### PHASE 1: PREPARATION
|
||||||
|
|
||||||
|
#### 1.1 Project Initialization
|
||||||
|
- Define document type and purpose
|
||||||
|
- Gather sample documents
|
||||||
|
- Identify stakeholders and subject matter experts
|
||||||
|
- Establish success criteria
|
||||||
|
- Create project continuity document
|
||||||
|
|
||||||
|
#### 1.2 Requirements Analysis
|
||||||
|
- Analyze document structure and components
|
||||||
|
- Identify regulatory or compliance requirements
|
||||||
|
- Document user needs and pain points
|
||||||
|
- Map content relationships and dependencies
|
||||||
|
- Define terminology standards
|
||||||
|
|
||||||
|
#### 1.3 Environment Setup
|
||||||
|
- Create project folder structure
|
||||||
|
- Initialize artifact templates
|
||||||
|
- Establish version control approach
|
||||||
|
- Set up testing methodology
|
||||||
|
- Prepare continuity management system
|
||||||
|
|
||||||
|
### PHASE 2: INITIAL PROMPT ENGINEERING
|
||||||
|
|
||||||
|
#### 2.1 Exploratory Interview
|
||||||
|
- Conduct structured interview with Claude
|
||||||
|
- Focus on one question at a time
|
||||||
|
- Document all insights and recommendations
|
||||||
|
- Utilize extended thinking mode for complex topics
|
||||||
|
- Update continuity document with progress
|
||||||
|
|
||||||
|
#### 2.2 Document Analysis
|
||||||
|
- Analyze structural patterns
|
||||||
|
- Identify critical components
|
||||||
|
- Document domain-specific terminology
|
||||||
|
- Map content relationships
|
||||||
|
- Define document lifecycle
|
||||||
|
|
||||||
|
#### 2.3 Prompt Architecture Development
|
||||||
|
- Design context provision strategy
|
||||||
|
- Develop instruction components
|
||||||
|
- Create format specification
|
||||||
|
- Draft example blocks
|
||||||
|
- Establish guardrails and constraints
|
||||||
|
|
||||||
|
#### 2.4 Initial Prompt Creation
|
||||||
|
- Draft complete prompt using structured template
|
||||||
|
- Incorporate all key elements identified
|
||||||
|
- Ensure proper formatting and organization
|
||||||
|
- Document assumptions and design decisions
|
||||||
|
- Create Claude-optimized version if needed
|
||||||
|
|
||||||
|
#### 2.5 Preliminary Testing
|
||||||
|
- Test with sample scenarios
|
||||||
|
- Document initial performance
|
||||||
|
- Identify obvious improvement areas
|
||||||
|
- Prepare for review session
|
||||||
|
- Update continuity document
|
||||||
|
|
||||||
|
### PHASE 3: PROMPT REVIEW
|
||||||
|
|
||||||
|
#### 3.1 Performance Assessment
|
||||||
|
- Evaluate against success criteria
|
||||||
|
- Analyze output quality and consistency
|
||||||
|
- Identify strengths and weaknesses
|
||||||
|
- Document performance metrics
|
||||||
|
- Prioritize improvement areas
|
||||||
|
|
||||||
|
#### 3.2 Structural Analysis
|
||||||
|
- Evaluate context effectiveness
|
||||||
|
- Assess instruction clarity
|
||||||
|
- Review format adherence
|
||||||
|
- Analyze example utility
|
||||||
|
- Document structural insights
|
||||||
|
|
||||||
|
#### 3.3 Content Quality Evaluation
|
||||||
|
- Assess factual accuracy
|
||||||
|
- Evaluate completeness
|
||||||
|
- Review logical flow
|
||||||
|
- Check tone appropriateness
|
||||||
|
- Verify terminology consistency
|
||||||
|
|
||||||
|
#### 3.4 Optimization Strategy
|
||||||
|
- Develop targeted improvements
|
||||||
|
- Create experimental variations
|
||||||
|
- Design comparison methodology
|
||||||
|
- Define success indicators
|
||||||
|
- Document optimization approach
|
||||||
|
|
||||||
|
#### 3.5 Prompt Revision
|
||||||
|
- Implement prioritized improvements
|
||||||
|
- Create revised prompt draft
|
||||||
|
- Document changes and rationale
|
||||||
|
- Update related artifacts
|
||||||
|
- Prepare for validation testing
|
||||||
|
|
||||||
|
#### 3.6 Validation Testing
|
||||||
|
- Test with predefined scenarios
|
||||||
|
- Compare to original performance
|
||||||
|
- Document improvements
|
||||||
|
- Identify any new issues
|
||||||
|
- Make final adjustments
|
||||||
|
|
||||||
|
### PHASE 4: IMPLEMENTATION
|
||||||
|
|
||||||
|
#### 4.1 Finalization
|
||||||
|
- Make go/no-go decision
|
||||||
|
- Finalize prompt documentation
|
||||||
|
- Create implementation guide
|
||||||
|
- Establish monitoring plan
|
||||||
|
- Update all project artifacts
|
||||||
|
|
||||||
|
#### 4.2 Deployment
|
||||||
|
- Implement in target environment
|
||||||
|
- Provide user training if needed
|
||||||
|
- Monitor initial performance
|
||||||
|
- Gather feedback
|
||||||
|
- Document deployment process
|
||||||
|
|
||||||
|
#### 4.3 Performance Monitoring
|
||||||
|
- Track key performance indicators
|
||||||
|
- Collect user feedback
|
||||||
|
- Document edge cases
|
||||||
|
- Identify optimization opportunities
|
||||||
|
- Schedule periodic reviews
|
||||||
|
|
||||||
|
### PHASE 5: MAINTENANCE
|
||||||
|
|
||||||
|
#### 5.1 Periodic Review
|
||||||
|
- Evaluate ongoing performance
|
||||||
|
- Identify changing requirements
|
||||||
|
- Update prompt as needed
|
||||||
|
- Document review findings
|
||||||
|
- Schedule next review
|
||||||
|
|
||||||
|
#### 5.2 Continuous Improvement
|
||||||
|
- Implement minor optimizations
|
||||||
|
- Test variations
|
||||||
|
- Document performance changes
|
||||||
|
- Update related artifacts
|
||||||
|
- Maintain version history
|
||||||
|
|
||||||
|
## ROLE-SPECIFIC WORKFLOWS
|
||||||
|
|
||||||
|
### FOR PROMPT ENGINEERS
|
||||||
|
|
||||||
|
1. Lead initial requirements gathering
|
||||||
|
2. Conduct exploratory interviews with Claude
|
||||||
|
3. Draft initial prompt architecture
|
||||||
|
4. Create example blocks
|
||||||
|
5. Document design decisions
|
||||||
|
6. Participate in review sessions
|
||||||
|
7. Implement technical optimizations
|
||||||
|
8. Update technical documentation
|
||||||
|
|
||||||
|
### FOR SUBJECT MATTER EXPERTS
|
||||||
|
|
||||||
|
1. Provide domain knowledge
|
||||||
|
2. Review document components for accuracy
|
||||||
|
3. Validate terminology usage
|
||||||
|
4. Assess output quality
|
||||||
|
5. Identify domain-specific edge cases
|
||||||
|
6. Help prioritize improvements
|
||||||
|
7. Review final documentation
|
||||||
|
8. Support
|
||||||
116
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Continuity Document.md
Executable file
116
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Continuity Document.md
Executable file
@@ -0,0 +1,116 @@
|
|||||||
|
# Continuity Document
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This master document serves as a persistent record of project progress and current status, enabling seamless resumption of work across multiple sessions and different Claude instances.
|
||||||
|
|
||||||
|
## PROJECT METADATA
|
||||||
|
```
|
||||||
|
[PROJECT TITLE]:
|
||||||
|
[START DATE]:
|
||||||
|
[CURRENT PHASE]:
|
||||||
|
[TARGET COMPLETION DATE]:
|
||||||
|
[KEY STAKEHOLDERS]:
|
||||||
|
[PRIMARY OBJECTIVES]:
|
||||||
|
```
|
||||||
|
|
||||||
|
## CURRENT STATUS SUMMARY
|
||||||
|
Provide a concise overview of the current state of the project (50-75 words).
|
||||||
|
```
|
||||||
|
[CURRENT STATUS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
## ACTIVE ARTIFACTS INVENTORY
|
||||||
|
List all artifacts currently in use with their latest versions.
|
||||||
|
|
||||||
|
| Artifact Name | Version | Last Updated | Description |
|
||||||
|
|---------------|---------|--------------|-------------|
|
||||||
|
| [Artifact 1] | [v#.#] | [YYYY-MM-DD] | [Brief description] |
|
||||||
|
| [Artifact 2] | [v#.#] | [YYYY-MM-DD] | [Brief description] |
|
||||||
|
| [Add more rows as needed] |
|
||||||
|
|
||||||
|
## CONVERSATION TIMELINE
|
||||||
|
|
||||||
|
### Session 1: [Date]
|
||||||
|
- Key accomplishments:
|
||||||
|
- [Accomplishment 1]
|
||||||
|
- [Accomplishment 2]
|
||||||
|
- Decisions made:
|
||||||
|
- [Decision 1]
|
||||||
|
- [Decision 2]
|
||||||
|
- Created artifacts:
|
||||||
|
- [Artifact 1] (v1.0)
|
||||||
|
- [Artifact 2] (v1.0)
|
||||||
|
|
||||||
|
### Session 2: [Date]
|
||||||
|
- Key accomplishments:
|
||||||
|
- [Accomplishment 1]
|
||||||
|
- [Accomplishment 2]
|
||||||
|
- Decisions made:
|
||||||
|
- [Decision 1]
|
||||||
|
- [Decision 2]
|
||||||
|
- Updated artifacts:
|
||||||
|
- [Artifact 1] (v1.1): [Summary of changes]
|
||||||
|
- [Artifact 3] (v1.0): [New artifact]
|
||||||
|
|
||||||
|
### [Add more sessions as needed]
|
||||||
|
|
||||||
|
## CURRENT FOCUS
|
||||||
|
```
|
||||||
|
[CURRENT TASK]:
|
||||||
|
[PROGRESS ON CURRENT TASK]:
|
||||||
|
[BLOCKING ISSUES]:
|
||||||
|
[NEXT IMMEDIATE ACTIONS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
## DECISIONS LOG
|
||||||
|
Record all significant decisions with rationale.
|
||||||
|
|
||||||
|
| Date | Decision | Rationale | Alternatives Considered |
|
||||||
|
|------|----------|-----------|-------------------------|
|
||||||
|
| [YYYY-MM-DD] | [Decision summary] | [Brief rationale] | [Alternative approaches] |
|
||||||
|
| [Add more rows as needed] |
|
||||||
|
|
||||||
|
## ASSUMPTIONS REGISTER
|
||||||
|
Document all assumptions being made in the project.
|
||||||
|
|
||||||
|
| ID | Assumption | Impact if Invalid | Verification Method |
|
||||||
|
|----|------------|-------------------|---------------------|
|
||||||
|
| A1 | [Assumption description] | [Potential impact] | [How/when to verify] |
|
||||||
|
| [Add more rows as needed] |
|
||||||
|
|
||||||
|
## CONVERSATION CONTEXT PRESERVATION
|
||||||
|
Key information to maintain conversation continuity:
|
||||||
|
```
|
||||||
|
[RECENT DISCUSSION POINTS]:
|
||||||
|
[PENDING QUERIES]:
|
||||||
|
[UNRESOLVED QUESTIONS]:
|
||||||
|
[AGREED TERMINOLOGY]:
|
||||||
|
```
|
||||||
|
|
||||||
|
## NEXT STEPS
|
||||||
|
- [ ] [Next action 1]
|
||||||
|
- [ ] [Next action 2]
|
||||||
|
- [ ] [Next action 3]
|
||||||
|
- [ ] [Additional actions as needed]
|
||||||
|
|
||||||
|
## TRANSITION NOTES
|
||||||
|
Information specifically for Claude when resuming in a new session:
|
||||||
|
```
|
||||||
|
[CRITICAL CONTEXT]:
|
||||||
|
[SPECIALIZED ROLES/EXPERTISE NEEDED]:
|
||||||
|
[PREFERRED COMMUNICATION STYLE]:
|
||||||
|
[ADDITIONAL INSTRUCTIONS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
## APPENDIX: SESSION RESUMPTION INSTRUCTIONS
|
||||||
|
|
||||||
|
To resume work on this project in a new session, please:
|
||||||
|
|
||||||
|
1. Share this continuity document with Claude
|
||||||
|
2. Use the prompt: "Document engineering chat - Please review this continuity document and help me resume our work exactly where we left off."
|
||||||
|
3. Confirm that Claude acknowledges the current status and next steps
|
||||||
|
4. Proceed with the next action items as outlined above
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Multi-Session Handoff, Chat Transition Protocol, Comprehensive Templates Index*
|
||||||
@@ -0,0 +1,167 @@
|
|||||||
|
# Exploratory Interview Guide
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This guide provides a structured approach to conducting exploratory interviews with Claude during document prompt engineering, emphasizing a one-question-at-a-time methodology to maximize the effectiveness of extended thinking mode.
|
||||||
|
|
||||||
|
## CORE PRINCIPLES
|
||||||
|
|
||||||
|
1. **Hierarchical Questioning**: Move from general to specific
|
||||||
|
2. **Active Listening**: Adapt questions based on previous responses
|
||||||
|
3. **Single-Focus Queries**: One concept per question
|
||||||
|
4. **Deliberate Progression**: Build a logical path of inquiry
|
||||||
|
5. **Extended Thinking Activation**: Strategic use of complex questions
|
||||||
|
|
||||||
|
## QUESTION HIERARCHY FRAMEWORK
|
||||||
|
|
||||||
|
### Level 1: Domain Understanding
|
||||||
|
These questions establish fundamental context and document characteristics.
|
||||||
|
|
||||||
|
**Example Questions:**
|
||||||
|
- "What are the defining characteristics of [document type]?"
|
||||||
|
- "What purpose does [document type] serve in [specific industry]?"
|
||||||
|
- "What components are essential for a complete [document type]?"
|
||||||
|
- "What common errors or omissions occur in [document type]?"
|
||||||
|
- "How has [document type] evolved over the past 5 years?"
|
||||||
|
|
||||||
|
**Follow-up Pattern:**
|
||||||
|
- Ask for clarification on unexpected elements
|
||||||
|
- Request examples of mentioned characteristics
|
||||||
|
- Explore regional or industry variations
|
||||||
|
|
||||||
|
### Level 2: Structure Analysis
|
||||||
|
These questions examine the format and organization of the document.
|
||||||
|
|
||||||
|
**Example Questions:**
|
||||||
|
- "What organizational structure is most effective for [document type]?"
|
||||||
|
- "How should information hierarchy be established in [document type]?"
|
||||||
|
- "What sections are mandatory vs. optional in [document type]?"
|
||||||
|
- "How does the structure of [document type] support its usability?"
|
||||||
|
- "What dependencies exist between different sections of [document type]?"
|
||||||
|
|
||||||
|
**Follow-up Pattern:**
|
||||||
|
- Probe for reasoning behind structural recommendations
|
||||||
|
- Ask about alternative structures and their tradeoffs
|
||||||
|
- Explore how structure affects document effectiveness
|
||||||
|
|
||||||
|
### Level 3: Content Optimization
|
||||||
|
These questions focus on the quality and effectiveness of the document's content.
|
||||||
|
|
||||||
|
**Example Questions:**
|
||||||
|
- "What language patterns increase clarity in [document type]?"
|
||||||
|
- "How should technical terminology be handled in [document type]?"
|
||||||
|
- "What level of detail is appropriate for [specific section]?"
|
||||||
|
- "How can [document type] balance comprehensiveness with readability?"
|
||||||
|
- "What contextual information is necessary for [specific element]?"
|
||||||
|
|
||||||
|
**Follow-up Pattern:**
|
||||||
|
- Request examples of optimal vs. suboptimal content
|
||||||
|
- Explore content variations for different audiences
|
||||||
|
- Ask about content evolution over document lifecycle
|
||||||
|
|
||||||
|
### Level 4: Edge Case Management
|
||||||
|
These questions address unusual scenarios and exception handling.
|
||||||
|
|
||||||
|
**Example Questions:**
|
||||||
|
- "How should [document type] address [uncommon scenario]?"
|
||||||
|
- "What contingencies should be included for [potential issue]?"
|
||||||
|
- "What flexibility is required in [document type] to accommodate [variable factor]?"
|
||||||
|
- "How can [document type] maintain integrity when [challenging condition]?"
|
||||||
|
- "What failsafes should be incorporated into [document type]?"
|
||||||
|
|
||||||
|
**Follow-up Pattern:**
|
||||||
|
- Explore frequency and impact of edge cases
|
||||||
|
- Ask about prioritization of different edge cases
|
||||||
|
- Request examples of well-handled edge cases
|
||||||
|
|
||||||
|
### Level 5: Implementation Strategy
|
||||||
|
These questions focus on practical application and execution.
|
||||||
|
|
||||||
|
**Example Questions:**
|
||||||
|
- "What approach would you recommend for transitioning from [current document] to [optimized document]?"
|
||||||
|
- "How should [specific challenge] be addressed during implementation?"
|
||||||
|
- "What metrics would effectively measure the success of [document type]?"
|
||||||
|
- "What timeline is realistic for developing and implementing [document type]?"
|
||||||
|
- "How should feedback be incorporated into [document type] iterations?"
|
||||||
|
|
||||||
|
**Follow-up Pattern:**
|
||||||
|
- Ask for step-by-step implementation recommendations
|
||||||
|
- Explore potential obstacles and solutions
|
||||||
|
- Request examples of successful implementations
|
||||||
|
|
||||||
|
## EXTENDED THINKING MODE ACTIVATION
|
||||||
|
|
||||||
|
For optimal use of Claude's extended thinking mode, structure questions that:
|
||||||
|
|
||||||
|
1. **Require Multivariate Analysis**
|
||||||
|
- "How would changes to [element X] impact [components A, B, and C] in [document type]?"
|
||||||
|
- "What interdependencies exist between [element X] and [elements Y and Z]?"
|
||||||
|
|
||||||
|
2. **Involve Complex Tradeoffs**
|
||||||
|
- "What are the tradeoffs between [approach A] and [approach B] when considering [factors X, Y, and Z]?"
|
||||||
|
- "How should [competing priorities X and Y] be balanced in [document type]?"
|
||||||
|
|
||||||
|
3. **Request Synthesized Insights**
|
||||||
|
- "Based on our discussion of [elements A, B, and C], what overarching principles should guide [document type]?"
|
||||||
|
- "What patterns emerge when comparing [scenarios X, Y, and Z] in [document type]?"
|
||||||
|
|
||||||
|
4. **Require Judgment in Ambiguous Scenarios**
|
||||||
|
- "Given the uncertainty around [factor X], what approach would you recommend for [document element]?"
|
||||||
|
- "How should [document type] handle situations where [conflicting requirements] exist?"
|
||||||
|
|
||||||
|
## FOLLOW-UP PROTOCOLS
|
||||||
|
|
||||||
|
### 1. Clarification Sequence
|
||||||
|
When Claude's response requires clarification:
|
||||||
|
|
||||||
|
1. Echo the unclear point: "You mentioned [specific point]. Could you clarify what you mean by that?"
|
||||||
|
2. Ask for an example: "Could you provide an example of [unclear concept]?"
|
||||||
|
3. Request reframing: "Could you explain [unclear concept] in a different way?"
|
||||||
|
4. Offer interpretation: "I understand [unclear concept] to mean [your interpretation]. Is that correct?"
|
||||||
|
|
||||||
|
### 2. Expansion Sequence
|
||||||
|
When Claude's response should be expanded:
|
||||||
|
|
||||||
|
1. Request depth: "Could you elaborate further on [specific aspect]?"
|
||||||
|
2. Ask for additional dimensions: "Beyond [mentioned aspects], what other factors should be considered?"
|
||||||
|
3. Request implications: "What are the implications of [specific aspect] for [related element]?"
|
||||||
|
4. Explore variations: "How might [specific aspect] vary in different contexts?"
|
||||||
|
|
||||||
|
### 3. Contrast Sequence
|
||||||
|
When comparing approaches or elements:
|
||||||
|
|
||||||
|
1. Request direct comparison: "How does [approach A] compare to [approach B] regarding [specific criterion]?"
|
||||||
|
2. Ask for advantages/disadvantages: "What are the pros and cons of [approach] compared to alternatives?"
|
||||||
|
3. Explore contextual variations: "In what scenarios would [approach A] be preferable to [approach B]?"
|
||||||
|
4. Request integration possibilities: "Could elements of [approach A] and [approach B] be combined?"
|
||||||
|
|
||||||
|
### 4. Validation Sequence
|
||||||
|
When confirming understanding or alignment:
|
||||||
|
|
||||||
|
1. Summarize understanding: "Based on our discussion, my understanding is [summary]. Is that accurate?"
|
||||||
|
2. Test with scenarios: "If [specific scenario] occurred, how would the approach you've described address it?"
|
||||||
|
3. Challenge assumptions: "What assumptions underlie the approach you've described?"
|
||||||
|
4. Explore limitations: "What limitations or constraints should we be aware of with this approach?"
|
||||||
|
|
||||||
|
## DOCUMENTATION PRACTICES
|
||||||
|
|
||||||
|
For each question and answer:
|
||||||
|
|
||||||
|
1. Record the exact question asked
|
||||||
|
2. Document Claude's complete response
|
||||||
|
3. Note any areas requiring follow-up
|
||||||
|
4. Track key insights and recommendations
|
||||||
|
5. Update the project continuity document with session progress
|
||||||
|
|
||||||
|
## INTERVIEW TERMINATION CRITERIA
|
||||||
|
|
||||||
|
Conclude the interview when:
|
||||||
|
|
||||||
|
- All planned question topics have been covered
|
||||||
|
- Response patterns become repetitive without new insights
|
||||||
|
- Clear recommendations have emerged for all key areas
|
||||||
|
- Sufficient material has been gathered for prompt development
|
||||||
|
- Chat context length approaches limitations
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Initial Prompt Engineering Session, Validation Checklist, Chat Transition Protocol*
|
||||||
@@ -0,0 +1,109 @@
|
|||||||
|
# Initial Prompt Engineering Session Template
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This template guides the initial session of document prompt engineering to systematically develop an effective prompt structure for any document type.
|
||||||
|
|
||||||
|
## PREPARATION CHECKLIST
|
||||||
|
- [ ] Document samples collected (minimum 3 recommended)
|
||||||
|
- [ ] Target outcome defined
|
||||||
|
- [ ] Stakeholder requirements documented
|
||||||
|
- [ ] Domain expertise identified/secured
|
||||||
|
- [ ] Technical constraints acknowledged
|
||||||
|
|
||||||
|
## SESSION STRUCTURE
|
||||||
|
|
||||||
|
### 1. DOCUMENT ANALYSIS
|
||||||
|
```
|
||||||
|
[DOCUMENT TYPE]:
|
||||||
|
[PRIMARY PURPOSE]:
|
||||||
|
[TARGET AUDIENCE]:
|
||||||
|
[CRITICAL COMPONENTS]:
|
||||||
|
[DOMAIN-SPECIFIC TERMINOLOGY]:
|
||||||
|
[STRUCTURAL PATTERNS]:
|
||||||
|
[PAIN POINTS IN CURRENT PROCESS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. PROMPT OBJECTIVES
|
||||||
|
```
|
||||||
|
[PRIMARY OBJECTIVE]:
|
||||||
|
[SECONDARY OBJECTIVES]:
|
||||||
|
[SUCCESS CRITERIA]:
|
||||||
|
[FAILURE MODES TO AVOID]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. PROMPT ARCHITECTURE
|
||||||
|
|
||||||
|
#### 3.1 Context Provision
|
||||||
|
```
|
||||||
|
[ESSENTIAL BACKGROUND]:
|
||||||
|
[DOMAIN KNOWLEDGE REQUIREMENTS]:
|
||||||
|
[REGULATORY/COMPLIANCE ELEMENTS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3.2 Instruction Components
|
||||||
|
```
|
||||||
|
[CORE INSTRUCTIONS]:
|
||||||
|
[SUPPLEMENTARY GUIDELINES]:
|
||||||
|
[GUARDRAILS AND CONSTRAINTS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3.3 Format Specification
|
||||||
|
```
|
||||||
|
[REQUIRED SECTIONS]:
|
||||||
|
[STRUCTURAL REQUIREMENTS]:
|
||||||
|
[STYLISTIC GUIDELINES]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 3.4 Examples Block
|
||||||
|
```
|
||||||
|
[INPUT EXAMPLE 1]:
|
||||||
|
[EXPECTED OUTPUT 1]:
|
||||||
|
|
||||||
|
[INPUT EXAMPLE 2]:
|
||||||
|
[EXPECTED OUTPUT 2]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. QUESTION SEQUENCE FOR CLAUDE
|
||||||
|
Use the Exploratory Interview Guide artifact for structured questioning hierarchy. Document each question and answer from Claude.
|
||||||
|
|
||||||
|
```
|
||||||
|
Q1: [First high-level question]
|
||||||
|
A1: [Claude's response]
|
||||||
|
|
||||||
|
Q2: [Follow-up based on response]
|
||||||
|
A2: [Claude's response]
|
||||||
|
|
||||||
|
[CONTINUE SEQUENCE]
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. INITIAL PROMPT DRAFT
|
||||||
|
```
|
||||||
|
[FULL PROMPT TEXT]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. PRELIMINARY TESTING NOTES
|
||||||
|
```
|
||||||
|
[TEST SCENARIO 1]:
|
||||||
|
[OUTCOME]:
|
||||||
|
[OBSERVATIONS]:
|
||||||
|
|
||||||
|
[TEST SCENARIO 2]:
|
||||||
|
[OUTCOME]:
|
||||||
|
[OBSERVATIONS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 7. NEXT STEPS
|
||||||
|
- [ ] Schedule prompt review session
|
||||||
|
- [ ] Identify subject matter experts for review
|
||||||
|
- [ ] Plan A/B testing methodology
|
||||||
|
- [ ] Update continuity document with session outcomes
|
||||||
|
|
||||||
|
## NOTES
|
||||||
|
- Use extended thinking mode for complex document analysis
|
||||||
|
- Maintain consistent terminology (reference Terminology Bank artifact)
|
||||||
|
- Document all assumptions made during the session
|
||||||
|
- Flag any areas requiring additional research
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Artifact Structure Guide, Exploratory Interview Guide, Terminology Bank*
|
||||||
@@ -0,0 +1,122 @@
|
|||||||
|
# Prompt Review Session Template
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This template facilitates a structured review of prompts developed during the initial engineering session to refine and optimize their effectiveness.
|
||||||
|
|
||||||
|
## PREPARATION CHECKLIST
|
||||||
|
- [ ] Initial prompt draft ready for review
|
||||||
|
- [ ] Test results from initial implementation documented
|
||||||
|
- [ ] Review team assembled with appropriate expertise
|
||||||
|
- [ ] Success criteria clearly defined
|
||||||
|
- [ ] Previous session notes accessible
|
||||||
|
|
||||||
|
## SESSION STRUCTURE
|
||||||
|
|
||||||
|
### 1. PROMPT PERFORMANCE ASSESSMENT
|
||||||
|
```
|
||||||
|
[PROMPT UNDER REVIEW]:
|
||||||
|
[INITIAL SUCCESS CRITERIA]:
|
||||||
|
[PERFORMANCE METRICS]:
|
||||||
|
[AREAS MEETING EXPECTATIONS]:
|
||||||
|
[AREAS REQUIRING IMPROVEMENT]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2. STRUCTURAL ANALYSIS
|
||||||
|
|
||||||
|
#### 2.1 Context Effectiveness
|
||||||
|
```
|
||||||
|
[SUFFICIENT BACKGROUND PROVIDED?]: Yes/No
|
||||||
|
[MISSING CONTEXT ELEMENTS]:
|
||||||
|
[SUPERFLUOUS CONTEXT ELEMENTS]:
|
||||||
|
[CLARITY OF DOMAIN KNOWLEDGE]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2.2 Instruction Clarity
|
||||||
|
```
|
||||||
|
[AMBIGUOUS INSTRUCTIONS IDENTIFIED]:
|
||||||
|
[CONFLICTING GUIDELINES IDENTIFIED]:
|
||||||
|
[INSTRUCTION HIERARCHY CLEAR?]: Yes/No
|
||||||
|
[GUARDRAIL EFFECTIVENESS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2.3 Format Adherence
|
||||||
|
```
|
||||||
|
[FORMAT REQUIREMENTS MET?]: Yes/No
|
||||||
|
[STRUCTURAL INCONSISTENCIES]:
|
||||||
|
[STYLISTIC DEVIATIONS]:
|
||||||
|
[QUALITY OF OUTPUT STRUCTURE]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 2.4 Example Utility
|
||||||
|
```
|
||||||
|
[EXAMPLES PROPERLY REFERENCED?]: Yes/No
|
||||||
|
[EXAMPLE DIVERSITY SUFFICIENT?]: Yes/No
|
||||||
|
[MISSING EXAMPLE SCENARIOS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 3. CONTENT QUALITY EVALUATION
|
||||||
|
```
|
||||||
|
[FACTUAL ACCURACY]:
|
||||||
|
[COMPLETENESS OF CONTENT]:
|
||||||
|
[LOGICAL FLOW]:
|
||||||
|
[APPROPRIATE TONE]:
|
||||||
|
[TERMINOLOGY CONSISTENCY]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. OPTIMIZATION STRATEGIES
|
||||||
|
|
||||||
|
#### 4.1 Targeted Improvements
|
||||||
|
```
|
||||||
|
[SPECIFIC ELEMENT]:
|
||||||
|
[CURRENT STATE]:
|
||||||
|
[PROPOSED REVISION]:
|
||||||
|
[RATIONALE]:
|
||||||
|
```
|
||||||
|
|
||||||
|
#### 4.2 Experimental Variations
|
||||||
|
```
|
||||||
|
[VARIATION A]:
|
||||||
|
[VARIATION B]:
|
||||||
|
[COMPARISON METHODOLOGY]:
|
||||||
|
[SUCCESS INDICATORS]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. REVISED PROMPT
|
||||||
|
```
|
||||||
|
[UPDATED FULL PROMPT TEXT]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. VALIDATION TESTING
|
||||||
|
```
|
||||||
|
[TEST SCENARIO 1]:
|
||||||
|
[OUTCOME]:
|
||||||
|
[IMPROVEMENT FROM ORIGINAL?]: Yes/No/Partial
|
||||||
|
|
||||||
|
[TEST SCENARIO 2]:
|
||||||
|
[OUTCOME]:
|
||||||
|
[IMPROVEMENT FROM ORIGINAL?]: Yes/No/Partial
|
||||||
|
```
|
||||||
|
|
||||||
|
### 7. IMPLEMENTATION RECOMMENDATIONS
|
||||||
|
```
|
||||||
|
[GO/NO-GO DECISION]:
|
||||||
|
[RECOMMENDED DEPLOYMENT CONTEXT]:
|
||||||
|
[MONITORING REQUIREMENTS]:
|
||||||
|
[EXPECTED MAINTENANCE FREQUENCY]:
|
||||||
|
```
|
||||||
|
|
||||||
|
### 8. NEXT STEPS
|
||||||
|
- [ ] Finalize prompt documentation
|
||||||
|
- [ ] Schedule follow-up review if needed
|
||||||
|
- [ ] Plan implementation strategy
|
||||||
|
- [ ] Update continuity document with review outcomes
|
||||||
|
|
||||||
|
## NOTES
|
||||||
|
- Use validation checklist to prevent redundant testing
|
||||||
|
- Document all stakeholder feedback received
|
||||||
|
- Consider A/B testing for significant changes
|
||||||
|
- Flag edge cases for special handling
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Validation Checklist, Initial Prompt Engineering Session, Continuity Document*
|
||||||
107
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Terminology Bank.md
Executable file
107
ReleasedPrompts/LLM Scaffolding/COO Work/Doc prompt eng/Terminology Bank.md
Executable file
@@ -0,0 +1,107 @@
|
|||||||
|
# Terminology Bank
|
||||||
|
Version: 1.0 (2025-03-25)
|
||||||
|
|
||||||
|
## PURPOSE
|
||||||
|
This terminology bank establishes standardized definitions for terms used in document prompt engineering to ensure consistency across artifacts and conversations.
|
||||||
|
|
||||||
|
## USAGE INSTRUCTIONS
|
||||||
|
1. Refer to this bank when introducing new terms in artifacts
|
||||||
|
2. Update with new terminology as it emerges in the project
|
||||||
|
3. Resolve any conflicting definitions before proceeding
|
||||||
|
4. Include relevant domain-specific terms for each project
|
||||||
|
5. Reference in the continuity document to maintain consistency across sessions
|
||||||
|
|
||||||
|
## CORE TERMINOLOGY
|
||||||
|
|
||||||
|
### Document Engineering Concepts
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| Document Prompt Engineering | The systematic process of developing, testing, and refining prompts specifically for document creation or analysis. | Preferred over "prompt design" or "prompt crafting" |
|
||||||
|
| Initial Engineering Session | The first phase of prompt development focused on understanding requirements and drafting initial approaches. | Always followed by at least one review session |
|
||||||
|
| Prompt Review Session | A structured evaluation of prompt performance with specific optimization objectives. | May be iterative depending on complexity |
|
||||||
|
| Artifact | A self-contained document that serves a specific function in the prompt engineering process. | All artifacts should follow the structure guide |
|
||||||
|
| Two-Step Process | The complete document prompt engineering workflow consisting of initial engineering and subsequent review. | Standard approach for all document types |
|
||||||
|
| Continuity Management | Techniques to maintain project context across multiple sessions or Claude instances. | Essential for complex projects |
|
||||||
|
|
||||||
|
### Prompt Structure Elements
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| Context Block | Information provided to Claude about the document domain, purpose, and background. | Should be comprehensive but concise |
|
||||||
|
| Instruction Set | Specific directives for Claude regarding document creation or analysis. | Organized hierarchically by priority |
|
||||||
|
| Format Specification | Requirements for the structure, style, and organization of the output. | Includes both mandatory and optional elements |
|
||||||
|
| Examples Block | Sample inputs and outputs that illustrate desired performance. | Should cover standard cases and edge cases |
|
||||||
|
| Guardrails | Constraints and limitations that prevent undesired outputs. | Both positive and negative constraints |
|
||||||
|
| Extended Thinking Trigger | Phrasings designed to activate Claude's extended reasoning capabilities. | Used for complex analytical requirements |
|
||||||
|
|
||||||
|
### Document Components
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| Structural Element | Any component that defines the organization of a document. | E.g., sections, subsections, headers |
|
||||||
|
| Content Element | Text, data, or media that provides information within the document. | Distinguished from structural elements |
|
||||||
|
| Conditional Element | Document components that appear only when specific criteria are met. | Important for adaptable documents |
|
||||||
|
| Metadata | Information about the document itself rather than its subject matter. | E.g., version, author, date, status |
|
||||||
|
| Compliance Element | Components required to meet regulatory or policy requirements. | Should be clearly identified as mandatory |
|
||||||
|
| User Input Field | Designated area for information to be provided by end-users. | Requires clear instructions and validation |
|
||||||
|
|
||||||
|
### Process Terminology
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| Exploratory Interview | A structured conversation with Claude to gather insights for prompt development. | Follows the interview guide artifact |
|
||||||
|
| Validation Testing | Systematic evaluation of prompt performance against predefined criteria. | Uses the validation checklist |
|
||||||
|
| A/B Testing | Comparison of alternative prompt versions to determine optimal approach. | Requires consistent test scenarios |
|
||||||
|
| Prompt Iteration | The process of refining a prompt based on performance analysis. | Should be tracked in the continuity document |
|
||||||
|
| Chat Transition | The process of moving a conversation to a new chat when approaching length limitations. | Follows the transition protocol |
|
||||||
|
| Multi-Session Handoff | The process of resuming work across different conversations. | Uses the handoff template |
|
||||||
|
|
||||||
|
## PROJECT-SPECIFIC TERMINOLOGY
|
||||||
|
|
||||||
|
Add domain-specific terminology relevant to the current project.
|
||||||
|
|
||||||
|
### [Domain Name]
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| [Term 1] | [Definition] | [Usage notes] |
|
||||||
|
| [Term 2] | [Definition] | [Usage notes] |
|
||||||
|
| [Add more as needed] |
|
||||||
|
|
||||||
|
### [Additional Domains as Needed]
|
||||||
|
|
||||||
|
| Term | Definition | Usage Notes |
|
||||||
|
|------|------------|-------------|
|
||||||
|
| [Term 1] | [Definition] | [Usage notes] |
|
||||||
|
| [Term 2] | [Definition] | [Usage notes] |
|
||||||
|
| [Add more as needed] |
|
||||||
|
|
||||||
|
## TERMINOLOGY MAINTENANCE
|
||||||
|
|
||||||
|
### Addition Process
|
||||||
|
To add new terminology:
|
||||||
|
1. Confirm term is not already defined (with potential variations)
|
||||||
|
2. Draft clear, concise definition
|
||||||
|
3. Provide usage notes with examples
|
||||||
|
4. Update the version number of this document
|
||||||
|
5. Reference the update in the continuity document
|
||||||
|
|
||||||
|
### Revision Process
|
||||||
|
To revise existing terminology:
|
||||||
|
1. Document both old and new definitions
|
||||||
|
2. Provide rationale for the change
|
||||||
|
3. Update all artifacts using the term
|
||||||
|
4. Note the revision in the continuity document
|
||||||
|
5. Update the version number of this document
|
||||||
|
|
||||||
|
### Retirement Process
|
||||||
|
To retire obsolete terminology:
|
||||||
|
1. Mark as deprecated with date
|
||||||
|
2. Provide recommended alternative term(s)
|
||||||
|
3. Maintain in the bank with deprecated status for reference
|
||||||
|
4. Update all artifacts using the term
|
||||||
|
5. Update the version number of this document
|
||||||
|
|
||||||
|
---
|
||||||
|
*Cross-reference with: Artifact Structure Guide, Continuity Document, Comprehensive Templates Index*
|
||||||
Reference in New Issue
Block a user