metacoding 1.5.0 → 2.0.1

package/templates/general/docs-update.instructions.md

@@ -1,275 +0,0 @@
----
-description: 'Universal documentation maintenance guidelines for all project types'
-applyTo: '**/*.md'
----
-
-# Universal Documentation Maintenance Guidelines
-
-## Documentation Architecture Principles
-
-This project enforces a strict distinction between different types of documentation to ensure clarity, maintainability, and appropriate use of status indicators across all project types.
-
-### System Documentation (Evergreen, Factual)
-
-**Purpose:** Describes the current state of the system, architecture, and implemented features.
-**Files:** README.md, architecture.md, api-design.md, system-documentation.md, code documentation
-**Language:** Present tense, factual, descriptive
-**Status Indicators:** ❌ **NEVER use status emojis or temporal language**
-**Content Focus:** What exists now, how it works, what it does
-**Examples:**
-
-- ✅ Correct: "The authentication system uses JWT tokens"
-- ❌ Incorrect: "🚧 Authentication system (in progress)"
-- ✅ Correct: "The API supports the following endpoints:"
-- ❌ Incorrect: "📋 Planned API endpoints:"
-
-### Project Management Documentation (Temporal, Status-Oriented)
-
-**Purpose:** Tracks work progress, planning, and execution status.
-**Files:** project-task-list.md, sprint-planning.md, backlog.md
-**Language:** Status-oriented, temporal references allowed
-**Status Indicators:** ✅ **Required - use emojis and progress indicators**
-**Content Focus:** What needs to be done, work progress, planning
-**Examples:**
-
-- ✅ Correct: "🚧 In Progress - Authentication system implementation"
-- ✅ Correct: "✅ Completed - JWT token validation"
-- ✅ Correct: "📋 Backlog - Add OAuth integration"
-
-### User Documentation (Instructional, Current)
-
-**Purpose:** Helps users understand how to use the system.
-**Files:** Installation guides, usage examples, tutorials
-**Language:** Imperative, instructional, present tense
-**Status Indicators:** ⚠️ **Use sparingly** - only for actual user-facing feature status
-**Content Focus:** How to use, what users can do, step-by-step guidance
-
-### Enforcement Rules
-
-1. **No Status Emojis in System Documentation:** Architecture, API docs, and README feature descriptions must be purely factual
-2. **No Temporal Language in System Documentation:** Avoid "currently", "recently", "planned", "upcoming" in system docs
-3. **Status Indicators Required in Project Management:** All task lists and project planning docs must use clear status indicators
-4. **Regular Documentation Audits:** Review and remove status language that has crept into system documentation
-5. **Template Compliance:** All generated documentation must follow these principles
-
-## Documentation Quality Standards
-
-- **Clarity:** Write clear, concise explanations appropriate for the target audience
-- **Completeness:** Ensure documentation covers all necessary aspects of the project
-- **Accuracy:** Verify all information is current and correct
-- **Consistency:** Maintain consistent tone and formatting across all documentation
-- **Accessibility:** Use clear language and proper formatting for accessibility
-- **Architecture Compliance:** Follow the system vs project documentation distinction
-
-## Repeated Documentation Tasks and Checklist Templates
-
-For any recurring documentation process (such as release documentation, API documentation updates, documentation reviews, or similar workflows), always use a dedicated checklist template to ensure all necessary steps are followed and nothing is missed.
-
-- **Documentation Checklist Template Principle:**
-  - Maintain a template checklist file for each repeated documentation process (e.g., `release-documentation-checklist.md`, `api-docs-update-checklist.md`).
-  - For each new instance (e.g., each release or major update), copy the template checklist and tag it with the relevant version or context, preserving the original template for future use.
-  - Systematically work through the checklist for every instance of the repeated documentation task, marking each step as completed.
-  - Proactively identify any documentation process that would benefit from a checklist and prompt the user to use or create one if it does not exist.
-  - If, during execution, you or the user identify missing or unclear documentation steps, update the template checklist to improve future reliability.
-
-**Examples of repeated documentation tasks requiring checklists:**
-
-- Release documentation (README updates, CHANGELOG maintenance, version synchronization)
-- API documentation updates (endpoint changes, parameter updates, example verification)
-- Documentation reviews and audits (link checking, content verification, accessibility checks)
-- Migration documentation (breaking changes, upgrade guides, compatibility notes)
-- Onboarding documentation updates
-- Any other documentation process with multiple required steps or risk of omission
-
-**Agent Guidance for Documentation Tasks:**
-
-- Always check for the existence of a documentation checklist template before starting a repeated documentation task.
-- If a template does not exist, prompt the user to create one and assist in drafting it.
-- When using a documentation checklist, copy it for the specific instance (e.g., `release-docs-v1.5.0.md`), and work through each step systematically.
-- If new documentation steps are discovered or improvements are needed, update the template and inform the user.
-
-## Status Indication Guidelines (For Project Management Documentation Only)
-
-**⚠️ IMPORTANT: These guidelines apply ONLY to project management documentation (task lists, planning docs). System documentation (README, architecture, API docs) must NEVER use status indicators.**
-
-- **Use checkboxes for task status:** `- [ ]` for incomplete, `- [x]` for complete
-- **Use clear status indicators in project management docs:**
-  - ✅ Complete/Implemented
-  - 🚧 In Progress
-  - ❌ Not Started
-  - ⚠️ Needs Review
-  - 🔄 Under Revision
-- **Examples of correct project management documentation:**
-  - ✅ Good: "🚧 In Progress - User authentication implementation"
-  - ✅ Good: "Development Status" with current checkboxes
-  - ✅ Good: "✅ Completed - API endpoint testing"
-
-## Task Management Documentation Guidelines
-
-- **Focus on current state:** Document what needs to be done, not what was recently done
-- **Use project phases:** Organize by logical project phases or milestones, not completion status
-- **Move completed work to changelog:** Record completed work in CHANGELOG.md, not in task lists
-- **Keep task lists current:** Update completed items with current status instead of maintaining "completed" sections
-- **Use descriptive section names:** Use functional names like "Core Features", "Infrastructure", "Testing" instead of "Completed Tasks"
-- **Avoid temporal references:** Don't use "Recent", "Latest", "Upcoming" in section headers - they become outdated quickly
-
-### Task ID Naming Convention
-
-Follow the standardized task naming format for all project management documentation:
-
-#### Required Task Format
-
-```markdown
-- [ ] **[AREA]-TASK-001: Task title** - ❌ **NOT STARTED**
-  - Detailed task description and requirements
-  - Implementation steps and acceptance criteria
-```
-
-#### Task ID Conventions
-
-- **Format:** `[AREA]-TASK-[NUMBER]`
-- **Area Prefixes:** Adapt to your project (CORE, API, UI, DB, AUTH, UTIL, CONFIG, DOC, CLI, TMPL, etc.)
-- **Task Type:** Always use "TASK" for consistency
-- **Sequential Numbering:** 001, 002, 003, etc. within each area
-- **Examples:**
-  - `CLI-TASK-001: Implement validate command`
-  - `API-TASK-002: Add authentication middleware`
-  - `DOC-TASK-003: Update README installation guide`
-  - `TMPL-TASK-004: Create Python project template`
-
-#### Task Organization Requirements
-
-- **Functional Grouping:** Group tasks by system area/component
-- **Clear Descriptions:** Provide specific, actionable task descriptions
-- **Status Tracking:** Use standard status indicators (❌ NOT STARTED, 🚧 IN PROGRESS, ✅ COMPLETED)
-- **Acceptance Criteria:** Include clear completion criteria in task details
-- **Dependencies:** Note task dependencies and prerequisites when relevant
-
-## README.md Standards (System Documentation)
-
-**⚠️ README.md is system documentation - NO status indicators or temporal language allowed**
-
-- **Project Overview:** Keep description current with latest capabilities using factual, present-tense language
-- **Installation Instructions:** Verify and update installation steps with clear, current procedures
-- **Usage Examples:** Ensure all code examples are tested and working, describe what they do
-- **Feature Documentation:** Document all major features with examples using factual descriptions
-- **Version Badges:** Keep version badges synchronized with package.json (or equivalent for other languages)
-- **Links Verification:** Regularly check that all links work correctly
-- **Screenshots/GIFs:** Update visual documentation when UI changes
-- **Avoid Status Language:** Never use "planned", "upcoming", "in progress", or status emojis
-- **Examples:**
-  - ✅ Correct: "The CLI provides three commands for project setup"
-  - ❌ Incorrect: "🚧 CLI commands (in development)"
-  - ✅ Correct: "Authentication uses JWT tokens with refresh capability"
-  - ❌ Incorrect: "Authentication system (planned for v2.0)"
-
-## CHANGELOG.md Maintenance
-
-- **User-Facing Changes:** Document all changes that affect users
-- **Consistent Format:** Follow established changelog format (Keep a Changelog standard)
-- **Categorization:** Group changes appropriately (Added, Changed, Fixed, Security, etc.)
-- **Breaking Changes:** Clearly mark breaking changes
-- **Migration Guides:** Provide migration guidance for breaking changes
-- **Version Dating:** Include release dates in consistent format (YYYY-MM-DD)
-
-## Code Documentation Standards
-
-Refer to language-specific coding instruction files for detailed code documentation standards:
-
-- **TypeScript/Node.js:** See `typescript.coding.instructions.md` for JSDoc standards
-- **Python:** See `python.coding.instructions.md` for docstring standards
-- **React/Frontend:** See `react.coding.instructions.md` for component documentation
-
-### Universal Code Documentation Principles
-
-- **Public APIs:** Always document public interfaces with appropriate documentation format
-- **Complex Logic:** Add comments for complex algorithms or business logic
-- **Function Documentation:** Document parameters, return values, and side effects
-- **Error Conditions:** Document when and why functions might fail
-- **Usage Examples:** Provide examples for non-trivial usage patterns
-
-## API Documentation
-
-- **Endpoint Documentation:** Keep API endpoint documentation current with implementation
-- **Parameter Changes:** Update parameter descriptions for any modifications
-- **Response Examples:** Provide realistic response examples
-- **Error Handling:** Document error responses and status codes
-- **Authentication:** Keep authentication documentation accurate
-- **Versioning:** Document API versioning strategy and compatibility
-
-## Architectural Documentation (System Documentation)
-
-**⚠️ Architecture docs are system documentation - NO status indicators or temporal language allowed**
-
-- **Decision Records:** Record significant architectural decisions in `/_meta` folder using factual language
-- **System Overview:** Maintain high-level system architecture documentation describing current implementation
-- **Data Flow:** Document data flow and process workflows as they currently exist
-- **Integration Points:** Document external system integrations that are implemented
-- **Performance Considerations:** Document performance implications of current design decisions
-- **Examples:**
-  - ✅ Correct: "The system uses a microservices architecture with three main services"
-  - ❌ Incorrect: "🏗️ Microservices architecture (under development)"
-  - ✅ Correct: "Data flows through the validation layer before storage"
-  - ❌ Incorrect: "Data validation layer (planned implementation)"
-
-## Code Examples and Tutorials
-
-- **Working Examples:** Ensure all code examples compile and run in the target language
-- **Complete Examples:** Provide complete, runnable examples when possible
-- **Progressive Complexity:** Start with simple examples, build to complex ones
-- **Error Handling:** Show proper error handling patterns for the language
-- **Best Practices:** Demonstrate best practices in example code
-- **Language Appropriateness:** Use idiomatic patterns for each language
-
-## Test Documentation Standards
-
-Follow the standardized table format for all test case documentation across all project types:
-
-### Required Table Format
-
-```markdown
-| Test Case ID  | Description                                 | Type | Status    |
-| :------------ | :------------------------------------------ | :--- | :-------- |
-| AREA-TYPE-001 | Brief but descriptive test case description | Unit | Completed |
-```
-
-### Test Case ID Conventions
-
-- **Format:** `[AREA]-[TYPE]-[NUMBER]`
-- **Area Prefixes:** Adapt to your project (CORE, API, UI, DB, AUTH, UTIL, CONFIG, DOC, etc.)
-- **Type Suffixes:** UNIT, INT, E2E
-- **Sequential Numbering:** 001, 002, 003, etc.
-
-### Table Organization Requirements
-
-- **Functional Grouping:** Group test cases by system area/component
-- **Consistent Formatting:** Maintain proper column alignment using pipes
-- **Clear Headers:** Use descriptive section headers for test groups
-- **Status Tracking:** Use simple status values: "Completed", "In Progress", "Not Started"
-- **Descriptive Test Cases:** Provide clear, concise descriptions for each test case
-- **Text only** Don't use emojis or bold text in the table - keep it simple and readable
-
-## Documentation Testing
-
-- **Link Checking:** Regularly verify all links work across all documentation
-- **Code Testing:** Test all code examples in documentation using appropriate tools
-- **Installation Testing:** Verify installation instructions work in clean environment
-- **User Testing:** Occasionally have someone unfamiliar try following documentation
-- **Cross-Platform Testing:** Verify instructions work across supported platforms
-
-## Maintenance Schedule
-
-- **Regular Review:** Schedule regular documentation review cycles
-- **Release Updates:** Update documentation as part of release process
-- **Issue Tracking:** Track documentation issues and improvements
-- **Community Feedback:** Incorporate user feedback on documentation clarity
-- **Automated Checks:** Use automated tools to check for broken links and outdated content
-
-## Localization and Accessibility
-
-- **Clear Language:** Use clear, simple language for international audiences
-- **Cultural Sensitivity:** Avoid culture-specific references
-- **Technical Terms:** Define technical terms when first introduced
-- **Consistent Terminology:** Use consistent terminology throughout all documentation
-- **Screen Reader Compatibility:** Ensure proper heading hierarchy and alt text
-- **High Contrast:** Use sufficient color contrast for accessibility

package/templates/general/release.instructions.md

@@ -1,242 +0,0 @@
----
-description: 'Universal release process for all project types'
-applyTo: 'package.json,setup.py,pyproject.toml,Cargo.toml'
----
-
-# Universal Release Process Guidelines
-
-## Pre-Release Validation
-
-### Code Quality Verification
-
-1. **Test Suite:** Verify all tests pass using project-appropriate test runner
-2. **Build Verification:** Ensure clean build without errors using project build system
-3. **Linting:** Check code quality standards using project linter configuration
-4. **Dependencies:** Review and update dependencies if needed
-5. **Security Audit:** Run security audit using language-appropriate tools
-
-### Language-Specific Pre-Release Steps
-
-For detailed language-specific release steps, refer to:
-
-- **TypeScript/Node.js:** `npm test`, `npm run build`, `npm audit`
-- **Python:** `pytest`, `python -m build`, `pip-audit` or `safety check`
-- **React/Frontend:** `npm test`, `npm run build`, `npm run lint`
-
-## Version Management
-
-### Semantic Versioning
-
-Follow SemVer (Semantic Versioning) principles across all project types:
-
-- **MAJOR (X.0.0):** Breaking changes that require user action
-- **MINOR (0.X.0):** New features that are backward compatible
-- **PATCH (0.0.X):** Bug fixes that are backward compatible
-
-### Version Consistency
-
-1. **Primary Version File:** Update version in main project file:
-   - Node.js: `package.json`
-   - Python: `setup.py`, `pyproject.toml`, or `__version__.py`
-   - Rust: `Cargo.toml`
-   - Other languages: Follow language conventions
-2. **Cross-File Consistency:** Ensure version matches across all relevant files
-3. **Breaking Changes:** Document breaking changes prominently in changelog
-
-## Documentation Updates
-
-### README.md Updates
-
-1. **Version Badges:** Update version badges to match project version
-2. **Installation Instructions:** Refresh installation instructions if needed
-3. **Feature Descriptions:** Update feature descriptions for new capabilities
-4. **Link Verification:** Verify all links and examples work correctly
-5. **Language-Specific Updates:** Update language-specific installation commands
-
-### API Documentation
-
-- **Interface Changes:** Update API documentation for any interface changes
-- **Compatibility Notes:** Document backward compatibility information
-- **Migration Guides:** Provide migration guidance for breaking changes
-
-## Changelog Management
-
-### Entry Structure
-
-Create new section in CHANGELOG.md with:
-
-1. **Release Header:** Version number matching project version file
-2. **Release Date:** Date in YYYY-MM-DD format
-3. **Grouped Changes:** Organize by standard categories:
-   - **Added:** New features
-   - **Changed:** Changes in existing functionality
-   - **Deprecated:** Soon-to-be removed features
-   - **Removed:** Now removed features
-   - **Fixed:** Bug fixes
-   - **Security:** Security vulnerability fixes
-
-### Entry Guidelines
-
-- **User Impact Focus:** Write from user perspective, not technical implementation
-- **Descriptive but Brief:** 1-2 lines per change explaining user impact
-- **Issue References:** Include issue/PR numbers when applicable: `(#123)`
-- **Breaking Changes:** Highlight with ⚠️ or **BREAKING:** prefix
-- **Migration Information:** Include migration steps for breaking changes
-
-## Git Operations
-
-### Commit and Tagging
-
-1. **Stage Changes:** Add all release-related changes (version files, changelog, docs)
-2. **Commit Message:** Use consistent format: `chore: bump version to vX.Y.Z`
-3. **Create Tag:** Tag the commit with version:
-   - Git: `git tag vX.Y.Z`
-   - Follow project conventions for tag naming
-4. **Push Changes:** Push commits and tags: `git push && git push --tags`
-
-### Branch Management
-
-- **Release Branches:** Use release branches for complex release processes
-- **Hotfix Handling:** Follow established branching strategy for hotfixes
-- **Merge Strategy:** Use consistent merge strategy (merge commits vs. squash)
-
-## Platform-Specific Release Steps
-
-### Package Registry Publishing
-
-**Node.js/npm:**
-
-```bash
-npm publish
-# Or for scoped packages: npm publish --access public
-```
-
-**Python/PyPI:**
-
-```bash
-python -m build
-twine upload dist/*
-```
-
-**GitHub Releases:**
-
-1. **Create Release:** Create GitHub release with tag matching project version
-2. **Release Title:** Use format: `vX.Y.Z - [Brief description]`
-3. **Release Notes:** Copy relevant sections from CHANGELOG.md
-4. **Asset Uploads:** Include built artifacts if applicable
-
-### Registry-Specific Considerations
-
-- **Package Validation:** Verify package content before publishing
-- **Permissions:** Ensure proper publishing permissions are configured
-- **Registry Status:** Check target registry availability before publishing
-
-## Post-Release Verification
-
-### Publication Verification
-
-1. **Registry Confirmation:** Verify package published correctly to target registry
-2. **Installation Test:** Test installation from registry in clean environment
-3. **Version Verification:** Confirm published version matches expected version
-4. **Metadata Check:** Verify package metadata is correct
-
-### Documentation and Communication
-
-1. **Documentation Links:** Ensure all documentation links work correctly
-2. **Update Notifications:** Notify relevant stakeholders of release
-3. **Community Communication:** Post to relevant community channels if applicable
-4. **Monitor Issues:** Watch for immediate issues reported by users
-
-## Release Monitoring
-
-### Immediate Post-Release
-
-- **Download/Install Metrics:** Monitor initial adoption metrics
-- **Error Monitoring:** Watch for error reports from new version
-- **User Feedback:** Monitor support channels for user feedback
-- **Dependency Issues:** Watch for reports of dependency conflicts
-
-### Issue Response
-
-- **Rapid Response:** Establish process for rapid response to critical issues
-- **Hotfix Process:** Have clear process for emergency hotfixes
-- **Communication Plan:** Prepare communication strategy for critical issues
-- **Rollback Preparedness:** Know how to rollback if necessary
-
-## Rollback and Emergency Procedures
-
-### Rollback Planning
-
-- **Git Revert:** Know how to revert problematic releases
-- **Registry Management:** Understand registry policies for unpublishing
-- **User Communication:** Prepare communication strategy for rollbacks
-- **Data Migration:** Plan for any data migration rollbacks if applicable
-
-### Emergency Release Process
-
-- **Hotfix Workflow:** Streamlined process for critical security fixes
-- **Testing Requirements:** Minimum testing requirements for emergency releases
-- **Approval Process:** Expedited approval process for critical fixes
-- **Communication Protocol:** Emergency communication procedures
-
-## Release Automation
-
-### CI/CD Integration
-
-- **Automated Testing:** All tests must pass before release
-- **Automated Building:** Automated build process for release artifacts
-- **Automated Publishing:** Consider automated publishing for appropriate project types
-- **Release Notes Generation:** Automate generation of release notes from changelog
-
-### Quality Gates
-
-- **Test Coverage:** Minimum test coverage requirements
-- **Security Scanning:** Automated security vulnerability scanning
-- **Dependency Auditing:** Automated dependency security auditing
-- **Performance Benchmarks:** Performance regression testing
-
-## Multi-Language Project Considerations
-
-### Coordinated Releases
-
-- **Version Synchronization:** Keep versions synchronized across language components
-- **Testing Integration:** Test all language components together
-- **Documentation Coordination:** Ensure documentation covers all language components
-- **Compatibility Matrix:** Document compatibility between different language versions
-
-### Release Coordination
-
-- **Release Orchestration:** Coordinate release timing across components
-- **Dependency Management:** Manage dependencies between language components
-- **Testing Strategy:** Test integration between language components
-- **Communication:** Coordinate communication across different language communities
-
-## Compliance and Legal
-
-### License Compliance
-
-- **License Verification:** Ensure all dependencies comply with project license
-- **License Updates:** Update license information for new dependencies
-- **Attribution:** Provide proper attribution for third-party components
-
-### Security and Privacy
-
-- **Security Review:** Review security implications of changes
-- **Privacy Impact:** Assess privacy impact of new features
-- **Compliance Requirements:** Meet relevant compliance requirements (GDPR, HIPAA, etc.)
-
-## Release Metrics and Analytics
-
-### Success Metrics
-
-- **Adoption Rate:** Track adoption of new version
-- **Error Rate:** Monitor error rates in new version
-- **Performance Metrics:** Track performance of new version
-- **User Satisfaction:** Gather user feedback on new features
-
-### Continuous Improvement
-
-- **Release Retrospectives:** Conduct retrospectives after major releases
-- **Process Refinement:** Continuously improve release process
-- **Tool Evaluation:** Regularly evaluate and improve release tooling
-- **Documentation Updates:** Keep release documentation current with process changes

package/templates/general/template.json

@@ -1,9 +0,0 @@
-{
-  "name": "general",
-  "description": "General purpose metacoding template for any project type",
-  "prompts": [],
-  "vscodeSettings": {
-    "github.copilot.chat.codeGeneration.useInstructionFiles": true,
-    "chat.promptFiles": true
-  }
-}