feat: add Claude Code integration and comprehensive documentation
- Add .claudcode/ directory with templates, workflows, and configuration - Create Claude-Feedback.md with detailed analysis of instruction collection - Significantly expand README.md with comprehensive project documentation - Include base instructions, project context, and user profiles - Add templates for shell scripts, documentation, and git workflows - Provide quick start guides for different user types 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
35
.claudcode/README.md
Normal file
35
.claudcode/README.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
# .claudcode Directory
|
||||||
|
|
||||||
|
This directory contains Claude Code configuration and templates for consistent AI interactions.
|
||||||
|
|
||||||
|
## Structure
|
||||||
|
- **settings.json**: Claude Code behavior configuration
|
||||||
|
- **base-instructions.md**: Core behavioral guidelines
|
||||||
|
- **project-context.md**: Project-specific context and requirements
|
||||||
|
- **templates/**: Reusable instruction templates
|
||||||
|
- **workflows/**: Step-by-step processes for common tasks
|
||||||
|
- **profiles/**: User and team preference profiles
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
1. Customize `project-context.md` for your specific project
|
||||||
|
2. Modify `settings.json` to match your preferences
|
||||||
|
3. Use templates for consistent outputs
|
||||||
|
4. Follow workflows for complex processes
|
||||||
|
5. Update profiles as needed
|
||||||
|
|
||||||
|
## Templates Available
|
||||||
|
- **shell-script.md**: Shell script generation standards
|
||||||
|
- **documentation.md**: Documentation creation guidelines
|
||||||
|
- **code-review.md**: Code review process (template)
|
||||||
|
- **technical-spec.md**: Technical specification format (template)
|
||||||
|
|
||||||
|
## Workflows Available
|
||||||
|
- **git-commit.md**: Git commit message standards
|
||||||
|
- **code-review.md**: Code review process (template)
|
||||||
|
- **debugging.md**: Debugging methodology (template)
|
||||||
|
|
||||||
|
## Customization
|
||||||
|
Each file can be customized to match your team's standards and preferences. The structure is designed to be flexible while maintaining consistency.
|
||||||
|
|
||||||
|
## Integration
|
||||||
|
Claude Code will automatically read these files to understand your preferences and provide consistent, high-quality assistance.
|
||||||
41
.claudcode/base-instructions.md
Normal file
41
.claudcode/base-instructions.md
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
# Base Instructions for Claude Code
|
||||||
|
|
||||||
|
## Core Behavioral Guidelines
|
||||||
|
|
||||||
|
### Response Standards
|
||||||
|
- Provide accurate, relevant, and factual information
|
||||||
|
- Never hallucinate or make up information
|
||||||
|
- Cite sources for all factual claims
|
||||||
|
- Use appropriate level of detail for the context
|
||||||
|
|
||||||
|
### Code Standards
|
||||||
|
- Follow existing code conventions in the project
|
||||||
|
- Add copyright headers for ReachableCEO Enterprises 2025
|
||||||
|
- Use AGPL v3.0 license for generated code
|
||||||
|
- Include robust error handling and validation
|
||||||
|
- Ensure code passes linting and syntax checks
|
||||||
|
|
||||||
|
### Communication Style
|
||||||
|
- Be direct and professional
|
||||||
|
- Use bullet points for complex information
|
||||||
|
- Ask clarifying questions when requirements are unclear
|
||||||
|
- Provide step-by-step explanations for complex processes
|
||||||
|
|
||||||
|
### Documentation Standards
|
||||||
|
- Use proper Markdown formatting
|
||||||
|
- Include version numbers and timestamps
|
||||||
|
- Create table of contents for long documents
|
||||||
|
- Add definitions section for technical terms
|
||||||
|
- Include references and citations
|
||||||
|
|
||||||
|
### File Management
|
||||||
|
- Always read existing files before modifying
|
||||||
|
- Prefer editing existing files over creating new ones
|
||||||
|
- Use absolute paths for file operations
|
||||||
|
- Follow established naming conventions
|
||||||
|
|
||||||
|
## Quality Assurance
|
||||||
|
- Verify all information before presenting
|
||||||
|
- Check code syntax and logic
|
||||||
|
- Validate markdown formatting
|
||||||
|
- Ensure compliance with project standards
|
||||||
53
.claudcode/profiles/charles-wyble.md
Normal file
53
.claudcode/profiles/charles-wyble.md
Normal file
@@ -0,0 +1,53 @@
|
|||||||
|
# Charles N Wyble - Claude Code Profile
|
||||||
|
|
||||||
|
## Professional Information
|
||||||
|
- **Name**: Charles N Wyble
|
||||||
|
- **Role**: Chief Technology And Product Officer (CTPO)
|
||||||
|
- **Company**: Suborbital Systems LLC
|
||||||
|
- **Location**: Austin, Texas
|
||||||
|
- **Experience**: 20+ years in technical leadership
|
||||||
|
|
||||||
|
## Communication Preferences
|
||||||
|
- **Style**: Direct, professional, bullet-point format
|
||||||
|
- **Complexity**: Intermediate to advanced technical level
|
||||||
|
- **Response Length**: Concise but comprehensive
|
||||||
|
- **Question Style**: One focused question per response
|
||||||
|
|
||||||
|
## Technical Preferences
|
||||||
|
- **Languages**: [Primary languages used]
|
||||||
|
- **Frameworks**: [Preferred frameworks]
|
||||||
|
- **Tools**: [Development tools]
|
||||||
|
- **Standards**: High quality, well-documented code
|
||||||
|
|
||||||
|
## Work Style
|
||||||
|
- **Schedule**: 18 hours awake, 6 hours sleep
|
||||||
|
- **Work Days**: Monday-Saturday (Sunday off)
|
||||||
|
- **Team**: Small, dedicated team
|
||||||
|
- **Approach**: Consensus-building with decisive action
|
||||||
|
|
||||||
|
## Values and Standards
|
||||||
|
- **Professionalism**: High standards of conduct and output
|
||||||
|
- **Candor**: Straightforward and honest communication
|
||||||
|
- **Consistency**: Reliable and dependable approach
|
||||||
|
- **Completion**: Following through on commitments
|
||||||
|
- **Quality**: Commitment to excellence in all work
|
||||||
|
|
||||||
|
## Project Focus
|
||||||
|
- **Current**: Launching Suborbital Systems and ventures
|
||||||
|
- **Transition**: Moving from COO to CTPO responsibilities
|
||||||
|
- **Content**: Newsletter writing and digital artifact creation
|
||||||
|
- **Properties**: Managing three different properties
|
||||||
|
|
||||||
|
## Code Standards
|
||||||
|
- **Copyright**: ReachableCEO Enterprises 2025
|
||||||
|
- **License**: AGPL v3.0 preferred
|
||||||
|
- **Error Handling**: Robust error handling required
|
||||||
|
- **Testing**: Comprehensive testing expected
|
||||||
|
- **Documentation**: Well-documented code required
|
||||||
|
|
||||||
|
## Interaction Guidelines
|
||||||
|
- Present information in bullet points
|
||||||
|
- Focus on practical, actionable advice
|
||||||
|
- Provide step-by-step processes
|
||||||
|
- Include relevant examples
|
||||||
|
- Ask clarifying questions when needed
|
||||||
38
.claudcode/project-context.md
Normal file
38
.claudcode/project-context.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
# Project Context
|
||||||
|
|
||||||
|
## Project Information
|
||||||
|
- **Name**: [PROJECT_NAME]
|
||||||
|
- **Type**: [software|documentation|mixed]
|
||||||
|
- **Description**: [Brief project description]
|
||||||
|
- **Repository**: [Git repository URL]
|
||||||
|
- **Main Language**: [Primary programming language]
|
||||||
|
- **Framework**: [Main framework/stack]
|
||||||
|
|
||||||
|
## Team Information
|
||||||
|
- **Project Lead**: Charles N Wyble
|
||||||
|
- **Team Size**: [Number of team members]
|
||||||
|
- **Development Method**: [Agile/Waterfall/etc.]
|
||||||
|
- **Review Process**: [Code review requirements]
|
||||||
|
|
||||||
|
## Technical Standards
|
||||||
|
- **License**: AGPL v3.0
|
||||||
|
- **Copyright**: ReachableCEO Enterprises 2025
|
||||||
|
- **Code Style**: [Specific style guide]
|
||||||
|
- **Testing**: [Testing requirements]
|
||||||
|
- **Documentation**: [Documentation standards]
|
||||||
|
|
||||||
|
## Project Goals
|
||||||
|
- [Primary objective]
|
||||||
|
- [Secondary objectives]
|
||||||
|
- [Success metrics]
|
||||||
|
|
||||||
|
## Current Status
|
||||||
|
- **Phase**: [Development phase]
|
||||||
|
- **Version**: [Current version]
|
||||||
|
- **Last Updated**: [Date]
|
||||||
|
- **Key Milestones**: [Upcoming milestones]
|
||||||
|
|
||||||
|
## Special Considerations
|
||||||
|
- [Any specific requirements or constraints]
|
||||||
|
- [Domain-specific knowledge needed]
|
||||||
|
- [Integration requirements]
|
||||||
29
.claudcode/settings.json
Normal file
29
.claudcode/settings.json
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
{
|
||||||
|
"version": "1.0.0",
|
||||||
|
"project": {
|
||||||
|
"name": "PROJECT_NAME",
|
||||||
|
"description": "Project description",
|
||||||
|
"type": "software|documentation|mixed"
|
||||||
|
},
|
||||||
|
"behavior": {
|
||||||
|
"response_style": "concise|detailed|professional",
|
||||||
|
"code_style": "compact|verbose|documented",
|
||||||
|
"error_handling": "strict|permissive",
|
||||||
|
"citations_required": true,
|
||||||
|
"markdown_linting": true
|
||||||
|
},
|
||||||
|
"templates": {
|
||||||
|
"default_code": "templates/code-generation.md",
|
||||||
|
"default_docs": "templates/documentation.md",
|
||||||
|
"shell_scripts": "templates/shell-script.md"
|
||||||
|
},
|
||||||
|
"workflows": {
|
||||||
|
"git_commit": "workflows/git-commit.md",
|
||||||
|
"code_review": "workflows/code-review.md",
|
||||||
|
"debugging": "workflows/debugging.md"
|
||||||
|
},
|
||||||
|
"profiles": {
|
||||||
|
"active_profile": "profiles/charles-wyble.md",
|
||||||
|
"team_standards": "profiles/team-standards.md"
|
||||||
|
}
|
||||||
|
}
|
||||||
65
.claudcode/templates/documentation.md
Normal file
65
.claudcode/templates/documentation.md
Normal file
@@ -0,0 +1,65 @@
|
|||||||
|
# Documentation Template
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
When creating documentation, follow these standards:
|
||||||
|
|
||||||
|
### Document Structure
|
||||||
|
- Title with version number
|
||||||
|
- Table of contents for documents > 500 words
|
||||||
|
- Metadata section with author, date, status
|
||||||
|
- Clear section hierarchy using ## and ###
|
||||||
|
- Definitions section for technical terms
|
||||||
|
- References section for citations
|
||||||
|
|
||||||
|
### Formatting Standards
|
||||||
|
- Use proper Markdown syntax
|
||||||
|
- Include code blocks with language specification
|
||||||
|
- Create tables for structured comparisons
|
||||||
|
- Use bullet points for lists
|
||||||
|
- Apply bold/italic formatting for emphasis
|
||||||
|
|
||||||
|
### Content Requirements
|
||||||
|
- Provide accurate, factual information
|
||||||
|
- Include citations for all claims
|
||||||
|
- Use appropriate technical language for audience
|
||||||
|
- Include practical examples
|
||||||
|
- Add troubleshooting sections where relevant
|
||||||
|
|
||||||
|
### Document Template
|
||||||
|
```markdown
|
||||||
|
# [Document Title] v1.0.0
|
||||||
|
|
||||||
|
## Table of Contents
|
||||||
|
- [Section 1](#section-1)
|
||||||
|
- [Section 2](#section-2)
|
||||||
|
|
||||||
|
## Metadata
|
||||||
|
- **Version**: 1.0.0
|
||||||
|
- **Last Updated**: YYYY-MM-DD
|
||||||
|
- **Author**: [Author Name]
|
||||||
|
- **Status**: [Draft|Review|Final]
|
||||||
|
|
||||||
|
## Section 1
|
||||||
|
Content here...
|
||||||
|
|
||||||
|
## Definitions
|
||||||
|
| Term | Definition |
|
||||||
|
|------|------------|
|
||||||
|
| [Term] | [Definition] |
|
||||||
|
|
||||||
|
## References
|
||||||
|
1. [Citation format]
|
||||||
|
|
||||||
|
## Version History
|
||||||
|
| Date | Version | Changes |
|
||||||
|
|------|---------|---------|
|
||||||
|
| YYYY-MM-DD | v1.0.0 | Initial creation |
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quality Checklist
|
||||||
|
- [ ] Proper markdown syntax
|
||||||
|
- [ ] All technical terms defined
|
||||||
|
- [ ] Citations included
|
||||||
|
- [ ] Examples provided
|
||||||
|
- [ ] Version information complete
|
||||||
|
- [ ] Proofread for accuracy
|
||||||
72
.claudcode/templates/shell-script.md
Normal file
72
.claudcode/templates/shell-script.md
Normal file
@@ -0,0 +1,72 @@
|
|||||||
|
# Shell Script Generation Template
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
When generating shell scripts, follow these requirements:
|
||||||
|
|
||||||
|
### Header Requirements
|
||||||
|
- Add ReachableCEO Enterprises 2025 copyright header
|
||||||
|
- Include verbose AGPL v3.0 license header
|
||||||
|
- Add script description and usage information
|
||||||
|
|
||||||
|
### Code Standards
|
||||||
|
- Use bash strict mode (set -euo pipefail)
|
||||||
|
- Format functions with blank lines around curly brackets
|
||||||
|
- Add robust error handling with trap for cleanup
|
||||||
|
- Check return values of all commands
|
||||||
|
- Use shellcheck-compliant syntax
|
||||||
|
|
||||||
|
### Output and Logging
|
||||||
|
- Print status messages with [INFO] and [ERROR] prefixes
|
||||||
|
- Colorize output (green for info, red for errors)
|
||||||
|
- Log all output to timestamped log file
|
||||||
|
- Format: LOG-(ScriptName)-MM-DD-YYYY-HH-MM-SS.log
|
||||||
|
- Include timestamps in MM-DD-YYYY-HH-MM-SS format
|
||||||
|
|
||||||
|
### File Generation
|
||||||
|
- Prompt for script name value
|
||||||
|
- Generate script file: (ScriptName)-Script-MM-DD-YYYY-HH-MM-SS.sh
|
||||||
|
- Create git commit message file: (ScriptName)-GitMsg-MM-DD-YYYY-HH-MM-SS.txt
|
||||||
|
- Generate test suite: (ScriptName)-TestSuite-MM-DD-YYYY-HH-MM-SS.sh
|
||||||
|
- Provide git add && git commit && git push command
|
||||||
|
|
||||||
|
### Code Structure
|
||||||
|
```bash
|
||||||
|
#!/bin/bash
|
||||||
|
# Copyright ReachableCEO Enterprises 2025
|
||||||
|
# Licensed under AGPL v3.0
|
||||||
|
|
||||||
|
# [Script description]
|
||||||
|
# Usage: [usage information]
|
||||||
|
|
||||||
|
set -euo pipefail
|
||||||
|
|
||||||
|
# Color codes
|
||||||
|
RED='\033[0;31m'
|
||||||
|
GREEN='\033[0;32m'
|
||||||
|
NC='\033[0m' # No Color
|
||||||
|
|
||||||
|
# Logging setup
|
||||||
|
LOG_FILE="LOG-$(basename "$0" .sh)-$(date +%m-%d-%Y-%H-%M-%S).log"
|
||||||
|
|
||||||
|
# Function template
|
||||||
|
function example_function() {
|
||||||
|
|
||||||
|
# Function implementation
|
||||||
|
echo -e "${GREEN}[INFO]${NC} Function started" | tee -a "$LOG_FILE"
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
# Error handling
|
||||||
|
trap 'echo -e "${RED}[ERROR]${NC} Script failed at line $LINENO" | tee -a "$LOG_FILE"' ERR
|
||||||
|
|
||||||
|
# Main script logic
|
||||||
|
main() {
|
||||||
|
|
||||||
|
echo -e "${GREEN}[INFO]${NC} Script started at $(date +%m-%d-%Y-%H-%M-%S)" | tee -a "$LOG_FILE"
|
||||||
|
# Implementation here
|
||||||
|
echo -e "${GREEN}[INFO]${NC} Script completed at $(date +%m-%d-%Y-%H-%M-%S)" | tee -a "$LOG_FILE"
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
main "$@"
|
||||||
|
```
|
||||||
67
.claudcode/workflows/git-commit.md
Normal file
67
.claudcode/workflows/git-commit.md
Normal file
@@ -0,0 +1,67 @@
|
|||||||
|
# Git Commit Workflow
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
Follow this workflow when creating git commits:
|
||||||
|
|
||||||
|
### Pre-Commit Checks
|
||||||
|
1. Run `git status` to see all changes
|
||||||
|
2. Run `git diff` to review staged and unstaged changes
|
||||||
|
3. Run `git log --oneline -5` to see recent commit style
|
||||||
|
4. Verify all files are properly formatted and linted
|
||||||
|
|
||||||
|
### Commit Message Format
|
||||||
|
Use conventional commit format:
|
||||||
|
```
|
||||||
|
type(scope): description
|
||||||
|
|
||||||
|
Longer explanation if needed
|
||||||
|
|
||||||
|
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||||
|
|
||||||
|
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Commit Types
|
||||||
|
- **feat**: New feature
|
||||||
|
- **fix**: Bug fix
|
||||||
|
- **docs**: Documentation changes
|
||||||
|
- **style**: Code style/formatting
|
||||||
|
- **refactor**: Code refactoring
|
||||||
|
- **test**: Test changes
|
||||||
|
- **chore**: Maintenance tasks
|
||||||
|
|
||||||
|
### Commit Process
|
||||||
|
1. Stage relevant files: `git add [files]`
|
||||||
|
2. Create commit with message
|
||||||
|
3. Verify commit with `git status`
|
||||||
|
4. Push if required: `git push origin [branch]`
|
||||||
|
|
||||||
|
### Example Commands
|
||||||
|
```bash
|
||||||
|
# Stage files
|
||||||
|
git add src/file.js docs/readme.md
|
||||||
|
|
||||||
|
# Create commit
|
||||||
|
git commit -m "$(cat <<'EOF'
|
||||||
|
feat(auth): add user authentication system
|
||||||
|
|
||||||
|
Implement JWT-based authentication with login/logout
|
||||||
|
Add middleware for protected routes
|
||||||
|
Include user session management
|
||||||
|
|
||||||
|
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||||
|
|
||||||
|
Co-Authored-By: Claude <noreply@anthropic.com>
|
||||||
|
EOF
|
||||||
|
)"
|
||||||
|
|
||||||
|
# Verify and push
|
||||||
|
git status && git push origin main
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quality Checks
|
||||||
|
- [ ] Commit message follows conventional format
|
||||||
|
- [ ] Changes are logically grouped
|
||||||
|
- [ ] No sensitive information included
|
||||||
|
- [ ] All tests pass
|
||||||
|
- [ ] Documentation updated if needed
|
||||||
146
Claude-Feedback.md
Normal file
146
Claude-Feedback.md
Normal file
@@ -0,0 +1,146 @@
|
|||||||
|
# Claude Feedback on LLM Instruction Collection
|
||||||
|
|
||||||
|
## Executive Summary
|
||||||
|
|
||||||
|
Your LLM instruction collection represents a sophisticated and comprehensive approach to AI interaction management. The three-tier hierarchical structure, emphasis on quality standards, and detailed process documentation demonstrate a mature understanding of prompt engineering principles. However, the complexity and rigidity of some requirements may present barriers to adoption and everyday usability.
|
||||||
|
|
||||||
|
## Detailed Analysis
|
||||||
|
|
||||||
|
### Strengths
|
||||||
|
|
||||||
|
#### 1. Comprehensive Coverage
|
||||||
|
- **Three-tier hierarchy**: The Global → Chat Type → Specific Chat structure provides excellent scalability
|
||||||
|
- **Quality assurance**: Strong emphasis on accuracy, citations, and professional standards
|
||||||
|
- **Process documentation**: Detailed workflows like the Complete Workflow.md provide clear guidance
|
||||||
|
- **Version control**: Excellent semantic versioning practices across all artifacts
|
||||||
|
|
||||||
|
#### 2. Professional Standards
|
||||||
|
- **No hallucination rule**: Absolute requirement for factual accuracy is essential
|
||||||
|
- **Citation requirements**: Mandatory citations for all factual claims ensures credibility
|
||||||
|
- **Markdown compliance**: Strict formatting standards improve consistency
|
||||||
|
- **Copyright and licensing**: Clear AGPL v3.0 requirements with proper attribution
|
||||||
|
|
||||||
|
#### 3. Structured Approach
|
||||||
|
- **Dual-version system**: LLM-optimized and human-optimized versions show thoughtful consideration
|
||||||
|
- **Multi-part document support**: Proper handling of size limitations
|
||||||
|
- **Metadata requirements**: Consistent headers with version, author, and status information
|
||||||
|
- **Document sections**: Standardized structure with TOC, definitions, references, and version history
|
||||||
|
|
||||||
|
#### 4. Clear Hierarchical Organization
|
||||||
|
- **Tier 1 (Global)**: Universal requirements applicable to all interactions
|
||||||
|
- **Tier 2 (Chat Type)**: Category-specific requirements
|
||||||
|
- **Tier 3 (Specific Chat)**: Individual conversation requirements
|
||||||
|
- **Override rules**: Clear precedence order with non-negotiable core requirements
|
||||||
|
|
||||||
|
### Areas for Improvement
|
||||||
|
|
||||||
|
#### 1. Complexity Management
|
||||||
|
- **Overwhelming detail**: The instruction set is extremely comprehensive but may overwhelm new users
|
||||||
|
- **High barrier to entry**: Complex requirements may discourage adoption for simple tasks
|
||||||
|
- **Cognitive load**: Multiple simultaneous requirements may be difficult to maintain consistently
|
||||||
|
|
||||||
|
#### 2. Rigidity Issues
|
||||||
|
- **Single question rule**: The "exactly one question per response" requirement may feel unnatural in conversational contexts
|
||||||
|
- **Strict formatting**: Some formatting requirements may be overly prescriptive for informal use
|
||||||
|
- **Inflexibility**: Limited accommodation for different interaction styles or contexts
|
||||||
|
|
||||||
|
#### 3. Maintenance Challenges
|
||||||
|
- **Content duplication**: Some requirements appear across multiple files, creating maintenance overhead
|
||||||
|
- **Version synchronization**: Dual-version requirements double the maintenance burden
|
||||||
|
- **Scope creep**: The comprehensive nature may lead to ever-expanding requirements
|
||||||
|
|
||||||
|
#### 4. Usability Concerns
|
||||||
|
- **No progressive disclosure**: No simplified entry points for basic use cases
|
||||||
|
- **All-or-nothing approach**: Difficult to selectively apply requirements
|
||||||
|
- **Learning curve**: Steep learning curve for team members or collaborators
|
||||||
|
|
||||||
|
### Specific Recommendations
|
||||||
|
|
||||||
|
#### 1. Create Graduated Complexity Levels
|
||||||
|
- **Basic**: Simple instructions for everyday use
|
||||||
|
- **Intermediate**: Standard professional requirements
|
||||||
|
- **Advanced**: Full comprehensive instruction set
|
||||||
|
- **Expert**: Specialized domain requirements
|
||||||
|
|
||||||
|
#### 2. Improve Accessibility
|
||||||
|
- **Quick start guides**: Simple templates for common tasks
|
||||||
|
- **Example galleries**: Practical examples showing instruction application
|
||||||
|
- **Troubleshooting guides**: Common issues and solutions
|
||||||
|
- **Progressive enhancement**: Start simple, add complexity as needed
|
||||||
|
|
||||||
|
#### 3. Reduce Redundancy
|
||||||
|
- **Centralize common requirements**: Create shared modules for repeated elements
|
||||||
|
- **Reference system**: Use references instead of duplication
|
||||||
|
- **Modular design**: Break large instructions into composable pieces
|
||||||
|
- **Inheritance patterns**: Clear parent-child relationships between instruction levels
|
||||||
|
|
||||||
|
#### 4. Enhance Flexibility
|
||||||
|
- **Contextual adaptations**: Allow requirements to adapt based on use case
|
||||||
|
- **Optional vs. mandatory**: Clearly distinguish between required and optional elements
|
||||||
|
- **Escape hatches**: Provide ways to deviate from strict requirements when appropriate
|
||||||
|
- **User preferences**: Allow customization of interaction styles
|
||||||
|
|
||||||
|
#### 5. Streamline Common Use Cases
|
||||||
|
- **Template library**: Pre-built templates for frequent tasks
|
||||||
|
- **Workflow automation**: Scripts or tools to apply common patterns
|
||||||
|
- **Default configurations**: Sensible defaults that work for most situations
|
||||||
|
- **One-click applications**: Easy ways to apply instruction sets
|
||||||
|
|
||||||
|
## Specific Technical Feedback
|
||||||
|
|
||||||
|
### FINAL-GlobalPrompt v2.0.0
|
||||||
|
- **Strength**: Excellent structural organization and comprehensive coverage
|
||||||
|
- **Concern**: Size and complexity may overwhelm users
|
||||||
|
- **Recommendation**: Create a condensed "essential" version for daily use
|
||||||
|
|
||||||
|
### Shell Script Instructions
|
||||||
|
- **Strength**: Very specific, actionable requirements
|
||||||
|
- **Strength**: Good integration with development workflows
|
||||||
|
- **Recommendation**: Could be extended to other programming languages
|
||||||
|
|
||||||
|
### Professional Profile
|
||||||
|
- **Strength**: Provides good context for AI interactions
|
||||||
|
- **Recommendation**: Could include more specific technical preferences and examples
|
||||||
|
|
||||||
|
### Complete Workflow
|
||||||
|
- **Strength**: Excellent process documentation
|
||||||
|
- **Strength**: Clear phase-by-phase guidance
|
||||||
|
- **Recommendation**: Could benefit from decision trees for different scenarios
|
||||||
|
|
||||||
|
## Strategic Recommendations
|
||||||
|
|
||||||
|
### 1. Tiered Implementation Strategy
|
||||||
|
- **Phase 1**: Implement essential requirements only
|
||||||
|
- **Phase 2**: Add intermediate complexity features
|
||||||
|
- **Phase 3**: Full comprehensive instruction set
|
||||||
|
- **Phase 4**: Specialized domain extensions
|
||||||
|
|
||||||
|
### 2. User Experience Focus
|
||||||
|
- **Onboarding**: Create guided setup process
|
||||||
|
- **Documentation**: Provide clear examples and use cases
|
||||||
|
- **Feedback loops**: Mechanisms to improve instructions based on usage
|
||||||
|
- **Community**: Consider sharing successful patterns
|
||||||
|
|
||||||
|
### 3. Maintenance Strategy
|
||||||
|
- **Version control**: Clear branching strategy for instruction evolution
|
||||||
|
- **Testing**: Systematic testing of instruction effectiveness
|
||||||
|
- **Metrics**: Track success rates and user satisfaction
|
||||||
|
- **Continuous improvement**: Regular review and optimization cycles
|
||||||
|
|
||||||
|
## Conclusion
|
||||||
|
|
||||||
|
Your LLM instruction collection demonstrates exceptional attention to quality and comprehensive coverage. The three-tier hierarchy and emphasis on professional standards create a solid foundation for consistent AI interactions. However, the current implementation may benefit from simplified entry points and greater flexibility to accommodate different use cases and user preferences.
|
||||||
|
|
||||||
|
The transformation into a `.claudcode` directory structure addresses many of these concerns by creating a more modular, accessible approach while preserving the core quality standards. This represents a significant step toward making your sophisticated instruction framework more practical and adoptable.
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
1. **Validate the .claudcode structure** with real-world usage
|
||||||
|
2. **Create simplified templates** for common use cases
|
||||||
|
3. **Develop onboarding documentation** for new users
|
||||||
|
4. **Establish feedback mechanisms** for continuous improvement
|
||||||
|
5. **Consider automation tools** to reduce manual overhead
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Feedback generated by Claude Code on [DATE]*
|
||||||
147
README.md
147
README.md
@@ -1,9 +1,146 @@
|
|||||||
# LLMScaffolding
|
# LLMScaffolding
|
||||||
|
|
||||||
All things related to how the @ReachableCEO uses LLM (Claude/Claude Code)
|
A comprehensive collection of Claude prompts, instructions, and configurations developed by @ReachableCEO for professional AI interactions.
|
||||||
|
|
||||||
- Claude prompts that I share publicly
|
## Overview
|
||||||
- Claude Code
|
|
||||||
- Infrastructure
|
This repository contains a mature LLM instruction framework designed for consistent, high-quality AI interactions across different projects and contexts. The system emphasizes professional standards, accuracy, and structured documentation.
|
||||||
- MCP
|
|
||||||
|
## Repository Structure
|
||||||
|
|
||||||
|
### Core Components
|
||||||
|
|
||||||
|
#### `/ReleasedPrompts/`
|
||||||
|
Public Claude prompts and instruction sets:
|
||||||
|
- **Global Prompts**: Universal guidelines for all AI interactions
|
||||||
|
- **Professional Profiles**: Context about team members and preferences
|
||||||
|
- **Workflow Documentation**: Complete processes for prompt engineering
|
||||||
|
- **Chat Type Instructions**: Domain-specific requirements
|
||||||
|
|
||||||
|
#### `/AICoFounder/`
|
||||||
|
Role-based AI assistant configurations:
|
||||||
|
- **Production environments** for TSYS and Family Office operations
|
||||||
|
- **Organizational hierarchy** with CTO, COO, and specialized roles
|
||||||
|
- **General instructions** for shell scripting and meta-instructions
|
||||||
|
- **Staff status** tracking and management
|
||||||
|
|
||||||
|
#### `/MCP/`
|
||||||
|
Model Context Protocol configurations:
|
||||||
|
- **Memory management** for persistent AI interactions
|
||||||
|
- **Service integrations** (Cloudron, Joplin, Redmine)
|
||||||
|
- **Basic memory** setup and configuration
|
||||||
|
|
||||||
|
#### `/.claudcode/`
|
||||||
|
Claude Code configuration directory:
|
||||||
|
- **Base instructions** for consistent behavior
|
||||||
|
- **Project templates** for common tasks
|
||||||
|
- **Workflow definitions** for complex processes
|
||||||
|
- **User profiles** and team standards
|
||||||
|
|
||||||
|
## Key Features
|
||||||
|
|
||||||
|
### Three-Tier Instruction Hierarchy
|
||||||
|
1. **Global Instructions**: Universal requirements for all AI interactions
|
||||||
|
2. **Chat Type Instructions**: Domain-specific requirements
|
||||||
|
3. **Specific Chat Instructions**: Individual conversation requirements
|
||||||
|
|
||||||
|
### Quality Standards
|
||||||
|
- **No hallucination policy**: Absolute requirement for factual accuracy
|
||||||
|
- **Citation requirements**: All factual claims must be sourced
|
||||||
|
- **Professional formatting**: Strict Markdown compliance
|
||||||
|
- **Version control**: Semantic versioning across all artifacts
|
||||||
|
|
||||||
|
### Professional Standards
|
||||||
|
- **Copyright**: ReachableCEO Enterprises 2025
|
||||||
|
- **License**: AGPL v3.0 for generated code
|
||||||
|
- **Error handling**: Robust error handling requirements
|
||||||
|
- **Documentation**: Comprehensive documentation standards
|
||||||
|
|
||||||
|
## Quick Start
|
||||||
|
|
||||||
|
### For New Users
|
||||||
|
1. Review the [base instructions](/.claudcode/base-instructions.md)
|
||||||
|
2. Customize the [project context](/.claudcode/project-context.md)
|
||||||
|
3. Use templates from `/.claudcode/templates/` for common tasks
|
||||||
|
4. Follow workflows in `/.claudcode/workflows/` for complex processes
|
||||||
|
|
||||||
|
### For Developers
|
||||||
|
1. Copy the `.claudcode` directory to your project root
|
||||||
|
2. Customize `settings.json` for your project needs
|
||||||
|
3. Update `profiles/` with your team information
|
||||||
|
4. Use templates for consistent code generation
|
||||||
|
|
||||||
|
### For Advanced Users
|
||||||
|
1. Study the comprehensive [Global Prompt](ReleasedPrompts/LLM%20Scaffolding/Released%20prompts/FINAL-GlobalPrompt%20v2.0.0%20(Part%201%20of%203).md)
|
||||||
|
2. Implement the [Complete Workflow](ReleasedPrompts/LLM%20Scaffolding/COO%20Work/Doc%20prompt%20eng/Complete%20Workflow.md)
|
||||||
|
3. Customize role-based configurations in `/AICoFounder/`
|
||||||
|
|
||||||
|
## Usage Examples
|
||||||
|
|
||||||
|
### Shell Script Generation
|
||||||
|
Use the [shell script template](/.claudcode/templates/shell-script.md) for:
|
||||||
|
- Automated ReachableCEO copyright headers
|
||||||
|
- AGPL v3.0 licensing
|
||||||
|
- Robust error handling
|
||||||
|
- Colored output with logging
|
||||||
|
- Comprehensive test suite generation
|
||||||
|
|
||||||
|
### Documentation Creation
|
||||||
|
Follow the [documentation template](/.claudcode/templates/documentation.md) for:
|
||||||
|
- Consistent markdown formatting
|
||||||
|
- Version-controlled documents
|
||||||
|
- Citation requirements
|
||||||
|
- Professional structure
|
||||||
|
|
||||||
|
### Git Workflow
|
||||||
|
Use the [git commit workflow](/.claudcode/workflows/git-commit.md) for:
|
||||||
|
- Conventional commit messages
|
||||||
|
- Proper attribution
|
||||||
|
- Quality checks before commits
|
||||||
|
|
||||||
|
## Architecture
|
||||||
|
|
||||||
|
### Design Principles
|
||||||
|
- **Modular**: Composable instruction components
|
||||||
|
- **Scalable**: Hierarchical structure supports growth
|
||||||
|
- **Maintainable**: Clear versioning and documentation
|
||||||
|
- **Professional**: High standards for all outputs
|
||||||
|
|
||||||
|
### Technical Implementation
|
||||||
|
- **Markdown-based**: All instructions in standard Markdown
|
||||||
|
- **Version controlled**: Semantic versioning throughout
|
||||||
|
- **Template-driven**: Reusable components for consistency
|
||||||
|
- **Configurable**: Adaptable to different projects and teams
|
||||||
|
|
||||||
|
## Contributing
|
||||||
|
|
||||||
|
### Standards
|
||||||
|
- All contributions must follow the established quality standards
|
||||||
|
- Include proper citations for any factual claims
|
||||||
|
- Follow the semantic versioning scheme
|
||||||
|
- Maintain dual-version artifacts (LLM and human optimized)
|
||||||
|
|
||||||
|
### Process
|
||||||
|
1. Review existing instructions for patterns
|
||||||
|
2. Follow the [Complete Workflow](ReleasedPrompts/LLM%20Scaffolding/COO%20Work/Doc%20prompt%20eng/Complete%20Workflow.md)
|
||||||
|
3. Test thoroughly before submission
|
||||||
|
4. Document all changes with proper version control
|
||||||
|
|
||||||
|
## License
|
||||||
|
|
||||||
|
This project is licensed under AGPL v3.0. See individual files for specific licensing information.
|
||||||
|
|
||||||
|
## Contact
|
||||||
|
|
||||||
|
- **Project Lead**: Charles N Wyble
|
||||||
|
- **Email**: Reachableceo@turnsys.com
|
||||||
|
- **Company**: ReachableCEO Enterprises
|
||||||
|
|
||||||
|
## Feedback
|
||||||
|
|
||||||
|
For feedback on this instruction collection, see [Claude-Feedback.md](Claude-Feedback.md) for detailed analysis and recommendations.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Documentation maintained by ReachableCEO Enterprises - Professional AI interaction framework for consistent, high-quality results.*
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user