workspace-architect 1.3.0

package/assets/prompts/project-workflow-analysis-blueprint-generator.prompt.md

@@ -0,0 +1,294 @@
+---
+
+description: 'Comprehensive technology-agnostic prompt generator for documenting end-to-end application workflows. Automatically detects project architecture patterns, technology stacks, and data flow patterns to generate detailed implementation blueprints covering entry points, service layers, data access, error handling, and testing approaches across multiple technologies including .NET, Java/Spring, React, and microservices architectures.'
+
+mode: 'agent'
+---
+# Project Workflow Documentation Generator
+
+## Configuration Variables
+
+```
+${PROJECT_TYPE="Auto-detect|.NET|Java|Spring|Node.js|Python|React|Angular|Microservices|Other"}
+<!-- Primary technology stack -->
+
+${ENTRY_POINT="API|GraphQL|Frontend|CLI|Message Consumer|Scheduled Job|Custom"}
+<!-- Starting point for the flow -->
+
+${PERSISTENCE_TYPE="Auto-detect|SQL Database|NoSQL Database|File System|External API|Message Queue|Cache|None"}
+<!-- Data storage type -->
+
+${ARCHITECTURE_PATTERN="Auto-detect|Layered|Clean|CQRS|Microservices|MVC|MVVM|Serverless|Event-Driven|Other"}
+<!-- Primary architecture pattern -->
+
+${WORKFLOW_COUNT=1-5}
+<!-- Number of workflows to document -->
+
+${DETAIL_LEVEL="Standard|Implementation-Ready"}
+<!-- Level of implementation detail to include -->
+
+${INCLUDE_SEQUENCE_DIAGRAM=true|false}
+<!-- Generate sequence diagram -->
+
+${INCLUDE_TEST_PATTERNS=true|false}
+<!-- Include testing approach -->
+```
+
+## Generated Prompt
+
+```
+"Analyze the codebase and document ${WORKFLOW_COUNT} representative end-to-end workflows 
+that can serve as implementation templates for similar features. Use the following approach:
+```
+
+### Initial Detection Phase
+
+```
+${PROJECT_TYPE == "Auto-detect" ? 
+  "Begin by examining the codebase structure to identify technologies:
+   - Check for .NET solutions/projects, Spring configurations, Node.js/Express files, etc.
+   - Identify the primary programming language(s) and frameworks in use
+   - Determine the architectural patterns based on folder structure and key components" 
+  : "Focus on ${PROJECT_TYPE} patterns and conventions"}
+```
+
+```
+${ENTRY_POINT == "Auto-detect" ? 
+  "Identify typical entry points by looking for:
+   - API controllers or route definitions
+   - GraphQL resolvers
+   - UI components that initiate network requests
+   - Message handlers or event subscribers
+   - Scheduled job definitions" 
+  : "Focus on ${ENTRY_POINT} entry points"}
+```
+
+```
+${PERSISTENCE_TYPE == "Auto-detect" ? 
+  "Determine persistence mechanisms by examining:
+   - Database context/connection configurations
+   - Repository implementations
+   - ORM mappings
+   - External API clients
+   - File system interactions" 
+  : "Focus on ${PERSISTENCE_TYPE} interactions"}
+```
+
+### Workflow Documentation Instructions
+
+For each of the `${WORKFLOW_COUNT}` most representative workflow(s) in the system:
+
+#### 1. Workflow Overview
+   - Provide a name and brief description of the workflow
+   - Explain the business purpose it serves
+   - Identify the triggering action or event
+   - List all files/classes involved in the complete workflow
+
+#### 2. Entry Point Implementation
+
+**API Entry Points:**
+```
+${ENTRY_POINT == "API" || ENTRY_POINT == "Auto-detect" ? 
+  "- Document the API controller class and method that receives the request
+   - Show the complete method signature including attributes/annotations
+   - Include the full request DTO/model class definition
+   - Document validation attributes and custom validators
+   - Show authentication/authorization attributes and checks" : ""}
+```
+
+**GraphQL Entry Points:**
+```
+${ENTRY_POINT == "GraphQL" || ENTRY_POINT == "Auto-detect" ? 
+  "- Document the GraphQL resolver class and method
+   - Show the complete schema definition for the query/mutation
+   - Include input type definitions
+   - Show resolver method implementation with parameter handling" : ""}
+```
+
+**Frontend Entry Points:**
+```
+${ENTRY_POINT == "Frontend" || ENTRY_POINT == "Auto-detect" ? 
+  "- Document the component that initiates the API call
+   - Show the event handler that triggers the request
+   - Include the API client service method
+   - Show state management code related to the request" : ""}
+```
+
+**Message Consumer Entry Points:**
+```
+${ENTRY_POINT == "Message Consumer" || ENTRY_POINT == "Auto-detect" ? 
+  "- Document the message handler class and method
+   - Show message subscription configuration
+   - Include the complete message model definition
+   - Show deserialization and validation logic" : ""}
+```
+
+#### 3. Service Layer Implementation
+   - Document each service class involved with their dependencies
+   - Show the complete method signatures with parameters and return types
+   - Include actual method implementations with key business logic
+   - Document interface definitions where applicable
+   - Show dependency injection registration patterns
+
+**CQRS Patterns:**
+```
+${ARCHITECTURE_PATTERN == "CQRS" || ARCHITECTURE_PATTERN == "Auto-detect" ? 
+  "- Include complete command/query handler implementations" : ""}
+```
+
+**Clean Architecture Patterns:**
+```
+${ARCHITECTURE_PATTERN == "Clean" || ARCHITECTURE_PATTERN == "Auto-detect" ? 
+  "- Show use case/interactor implementations" : ""}
+```
+
+#### 4. Data Mapping Patterns
+   - Document DTO to domain model mapping code
+   - Show object mapper configurations or manual mapping methods
+   - Include validation logic during mapping
+   - Document any domain events created during mapping
+
+#### 5. Data Access Implementation
+   - Document repository interfaces and their implementations
+   - Show complete method signatures with parameters and return types
+   - Include actual query implementations
+   - Document entity/model class definitions with all properties
+   - Show transaction handling patterns
+
+**SQL Database Patterns:**
+```
+${PERSISTENCE_TYPE == "SQL Database" || PERSISTENCE_TYPE == "Auto-detect" ? 
+  "- Include ORM configurations, annotations, or Fluent API usage
+   - Show actual SQL queries or ORM statements" : ""}
+```
+
+**NoSQL Database Patterns:**
+```
+${PERSISTENCE_TYPE == "NoSQL Database" || PERSISTENCE_TYPE == "Auto-detect" ? 
+  "- Show document structure definitions
+   - Include document query/update operations" : ""}
+```
+
+#### 6. Response Construction
+   - Document response DTO/model class definitions
+   - Show mapping from domain/entity models to response models
+   - Include status code selection logic
+   - Document error response structure and generation
+
+#### 7. Error Handling Patterns
+   - Document exception types used in the workflow
+   - Show try/catch patterns at each layer
+   - Include global exception handler configurations
+   - Document error logging implementations
+   - Show retry policies or circuit breaker patterns
+   - Include compensating actions for failure scenarios
+
+#### 8. Asynchronous Processing Patterns
+   - Document background job scheduling code
+   - Show event publication implementations
+   - Include message queue sending patterns
+   - Document callback or webhook implementations
+   - Show how async operations are tracked and monitored
+
+**Testing Approach (Optional):**
+```
+${INCLUDE_TEST_PATTERNS ? 
+  "9. **Testing Approach**
+     - Document unit test implementations for each layer
+     - Show mocking patterns and test fixture setup
+     - Include integration test implementations
+     - Document test data generation approaches
+     - Show API/controller test implementations" : ""}
+```
+
+**Sequence Diagram (Optional):**
+```
+${INCLUDE_SEQUENCE_DIAGRAM ? 
+  "10. **Sequence Diagram**
+      - Generate a detailed sequence diagram showing all components
+      - Include method calls with parameter types
+      - Show return values between components
+      - Document conditional flows and error paths" : ""}
+```
+
+#### 11. Naming Conventions
+Document consistent patterns for:
+- Controller naming (e.g., `EntityNameController`)
+- Service naming (e.g., `EntityNameService`)
+- Repository naming (e.g., `IEntityNameRepository`)
+- DTO naming (e.g., `EntityNameRequest`, `EntityNameResponse`)
+- Method naming patterns for CRUD operations
+- Variable naming conventions
+- File organization patterns
+
+#### 12. Implementation Templates
+Provide reusable code templates for:
+- Creating a new API endpoint following the pattern
+- Implementing a new service method
+- Adding a new repository method
+- Creating new domain model classes
+- Implementing proper error handling
+
+### Technology-Specific Implementation Patterns
+
+**.NET Implementation Patterns (if detected):**
+```
+${PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect" ? 
+  "- Complete controller class with attributes, filters, and dependency injection
+   - Service registration in Startup.cs or Program.cs
+   - Entity Framework DbContext configuration
+   - Repository implementation with EF Core or Dapper
+   - AutoMapper profile configurations
+   - Middleware implementations for cross-cutting concerns
+   - Extension method patterns
+   - Options pattern implementation for configuration
+   - Logging implementation with ILogger
+   - Authentication/authorization filter or policy implementations" : ""}
+```
+
+**Spring Implementation Patterns (if detected):**
+```
+${PROJECT_TYPE == "Java" || PROJECT_TYPE == "Spring" || PROJECT_TYPE == "Auto-detect" ? 
+  "- Complete controller class with annotations and dependency injection
+   - Service implementation with transaction boundaries
+   - Repository interface and implementation
+   - JPA entity definitions with relationships
+   - DTO class implementations
+   - Bean configuration and component scanning
+   - Exception handler implementations
+   - Custom validator implementations" : ""}
+```
+
+**React Implementation Patterns (if detected):**
+```
+${PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect" ? 
+  "- Component structure with props and state
+   - Hook implementation patterns (useState, useEffect, custom hooks)
+   - API service implementation
+   - State management patterns (Context, Redux)
+   - Form handling implementations
+   - Route configuration" : ""}
+```
+
+### Implementation Guidelines
+
+Based on the documented workflows, provide specific guidance for implementing new features:
+
+#### 1. Step-by-Step Implementation Process
+- Where to start when adding a similar feature
+- Order of implementation (e.g., model → repository → service → controller)
+- How to integrate with existing cross-cutting concerns
+
+#### 2. Common Pitfalls to Avoid
+- Identify error-prone areas in the current implementation
+- Note performance considerations
+- List common bugs or issues encountered
+
+#### 3. Extension Mechanisms
+- Document how to plug into existing extension points
+- Show how to add new behavior without modifying existing code
+- Explain configuration-driven feature patterns
+
+**Conclusion:**
+Conclude with a summary of the most important patterns that should be followed when 
+implementing new features to maintain consistency with the codebase."

package/assets/prompts/prompt-builder.prompt.md

@@ -0,0 +1,142 @@
+---
+mode: 'agent'
+tools: ['search/codebase', 'edit/editFiles', 'search']
+description: 'Guide users through creating high-quality GitHub Copilot prompts with proper structure, tools, and best practices.'
+---
+
+# Professional Prompt Builder
+
+You are an expert prompt engineer specializing in GitHub Copilot prompt development with deep knowledge of:
+- Prompt engineering best practices and patterns
+- VS Code Copilot customization capabilities  
+- Effective persona design and task specification
+- Tool integration and front matter configuration
+- Output format optimization for AI consumption
+
+Your task is to guide me through creating a new `.prompt.md` file by systematically gathering requirements and generating a complete, production-ready prompt file.
+
+## Discovery Process
+
+I will ask you targeted questions to gather all necessary information. After collecting your responses, I will generate the complete prompt file content following established patterns from this repository.
+
+### 1. **Prompt Identity & Purpose**
+- What is the intended filename for your prompt (e.g., `generate-react-component.prompt.md`)?
+- Provide a clear, one-sentence description of what this prompt accomplishes
+- What category does this prompt fall into? (code generation, analysis, documentation, testing, refactoring, architecture, etc.)
+
+### 2. **Persona Definition**
+- What role/expertise should Copilot embody? Be specific about:
+    - Technical expertise level (junior, senior, expert, specialist)
+    - Domain knowledge (languages, frameworks, tools)
+    - Years of experience or specific qualifications
+    - Example: "You are a senior .NET architect with 10+ years of experience in enterprise applications and extensive knowledge of C# 12, ASP.NET Core, and clean architecture patterns"
+
+### 3. **Task Specification**
+- What is the primary task this prompt performs? Be explicit and measurable
+- Are there secondary or optional tasks?
+- What should the user provide as input? (selection, file, parameters, etc.)
+- What constraints or requirements must be followed?
+
+### 4. **Context & Variable Requirements**
+- Will it use `${selection}` (user's selected code)?
+- Will it use `${file}` (current file) or other file references?
+- Does it need input variables like `${input:variableName}` or `${input:variableName:placeholder}`?
+- Will it reference workspace variables (`${workspaceFolder}`, etc.)?
+- Does it need to access other files or prompt files as dependencies?
+
+### 5. **Detailed Instructions & Standards**
+- What step-by-step process should Copilot follow?
+- Are there specific coding standards, frameworks, or libraries to use?
+- What patterns or best practices should be enforced?
+- Are there things to avoid or constraints to respect?
+- Should it follow any existing instruction files (`.instructions.md`)?
+
+### 6. **Output Requirements**
+- What format should the output be? (code, markdown, JSON, structured data, etc.)
+- Should it create new files? If so, where and with what naming convention?
+- Should it modify existing files?
+- Do you have examples of ideal output that can be used for few-shot learning?
+- Are there specific formatting or structure requirements?
+
+### 7. **Tool & Capability Requirements**
+Which tools does this prompt need? Common options include:
+- **File Operations**: `codebase`, `editFiles`, `search`, `problems`
+- **Execution**: `runCommands`, `runTasks`, `runTests`, `terminalLastCommand`
+- **External**: `fetch`, `githubRepo`, `openSimpleBrowser`
+- **Specialized**: `playwright`, `usages`, `vscodeAPI`, `extensions`
+- **Analysis**: `changes`, `findTestFiles`, `testFailure`, `searchResults`
+
+### 8. **Technical Configuration**
+- Should this run in a specific mode? (`agent`, `ask`, `edit`)
+- Does it require a specific model? (usually auto-detected)
+- Are there any special requirements or constraints?
+
+### 9. **Quality & Validation Criteria**
+- How should success be measured?
+- What validation steps should be included?
+- Are there common failure modes to address?
+- Should it include error handling or recovery steps?
+
+## Best Practices Integration
+
+Based on analysis of existing prompts, I will ensure your prompt includes:
+
+✅ **Clear Structure**: Well-organized sections with logical flow
+✅ **Specific Instructions**: Actionable, unambiguous directions  
+✅ **Proper Context**: All necessary information for task completion
+✅ **Tool Integration**: Appropriate tool selection for the task
+✅ **Error Handling**: Guidance for edge cases and failures
+✅ **Output Standards**: Clear formatting and structure requirements
+✅ **Validation**: Criteria for measuring success
+✅ **Maintainability**: Easy to update and extend
+
+## Next Steps
+
+Please start by answering the questions in section 1 (Prompt Identity & Purpose). I'll guide you through each section systematically, then generate your complete prompt file.
+
+## Template Generation
+
+After gathering all requirements, I will generate a complete `.prompt.md` file following this structure:
+
+```markdown
+---
+description: "[Clear, concise description from requirements]"
+mode: "[agent|ask|edit based on task type]"
+tools: ["[appropriate tools based on functionality]"]
+model: "[only if specific model required]"
+---
+
+# [Prompt Title]
+
+[Persona definition - specific role and expertise]
+
+## [Task Section]
+[Clear task description with specific requirements]
+
+## [Instructions Section]
+[Step-by-step instructions following established patterns]
+
+## [Context/Input Section] 
+[Variable usage and context requirements]
+
+## [Output Section]
+[Expected output format and structure]
+
+## [Quality/Validation Section]
+[Success criteria and validation steps]
+```
+
+The generated prompt will follow patterns observed in high-quality prompts like:
+- **Comprehensive blueprints** (architecture-blueprint-generator)
+- **Structured specifications** (create-github-action-workflow-specification)  
+- **Best practice guides** (dotnet-best-practices, csharp-xunit)
+- **Implementation plans** (create-implementation-plan)
+- **Code generation** (playwright-generate-test)
+
+Each prompt will be optimized for:
+- **AI Consumption**: Token-efficient, structured content
+- **Maintainability**: Clear sections, consistent formatting
+- **Extensibility**: Easy to modify and enhance
+- **Reliability**: Comprehensive instructions and error handling
+
+Please start by telling me the name and description for the new prompt you want to build.

package/assets/prompts/pytest-coverage.prompt.md

@@ -0,0 +1,28 @@
+---
+agent: agent
+description: 'Run pytest tests with coverage, discover lines missing coverage, and increase coverage to 100%.'
+---
+
+The goal is for the tests to cover all lines of code.
+
+Generate a coverage report with:
+
+pytest --cov --cov-report=annotate:cov_annotate
+
+If you are checking for coverage of a specific module, you can specify it like this:
+
+pytest --cov=your_module_name --cov-report=annotate:cov_annotate
+
+You can also specify specific tests to run, for example:
+
+pytest tests/test_your_module.py --cov=your_module_name --cov-report=annotate:cov_annotate
+
+Open the cov_annotate directory to view the annotated source code.
+There will be one file per source file. If a file has 100% source coverage, it means all lines are covered by tests, so you do not need to open the file.
+
+For each file that has less than 100% test coverage, find the matching file in cov_annotate and review the file.
+
+If a line starts with a ! (exclamation mark), it means that the line is not covered by tests.
+Add tests to cover the missing lines.
+
+Keep running the tests and improving coverage until all lines are covered.

package/assets/prompts/python-mcp-server-generator.prompt.md

@@ -0,0 +1,105 @@
+---
+mode: 'agent'
+description: 'Generate a complete MCP server project in Python with tools, resources, and proper configuration'
+---
+
+# Generate Python MCP Server
+
+Create a complete Model Context Protocol (MCP) server in Python with the following specifications:
+
+## Requirements
+
+1. **Project Structure**: Create a new Python project with proper structure using uv
+2. **Dependencies**: Include mcp[cli] package with uv
+3. **Transport Type**: Choose between stdio (for local) or streamable-http (for remote)
+4. **Tools**: Create at least one useful tool with proper type hints
+5. **Error Handling**: Include comprehensive error handling and validation
+
+## Implementation Details
+
+### Project Setup
+- Initialize with `uv init project-name`
+- Add MCP SDK: `uv add "mcp[cli]"`
+- Create main server file (e.g., `server.py`)
+- Add `.gitignore` for Python projects
+- Configure for direct execution with `if __name__ == "__main__"`
+
+### Server Configuration
+- Use `FastMCP` class from `mcp.server.fastmcp`
+- Set server name and optional instructions
+- Choose transport: stdio (default) or streamable-http
+- For HTTP: optionally configure host, port, and stateless mode
+
+### Tool Implementation
+- Use `@mcp.tool()` decorator on functions
+- Always include type hints - they generate schemas automatically
+- Write clear docstrings - they become tool descriptions
+- Use Pydantic models or TypedDicts for structured outputs
+- Support async operations for I/O-bound tasks
+- Include proper error handling
+
+### Resource/Prompt Setup (Optional)
+- Add resources with `@mcp.resource()` decorator
+- Use URI templates for dynamic resources: `"resource://{param}"`
+- Add prompts with `@mcp.prompt()` decorator
+- Return strings or Message lists from prompts
+
+### Code Quality
+- Use type hints for all function parameters and returns
+- Write docstrings for tools, resources, and prompts
+- Follow PEP 8 style guidelines
+- Use async/await for asynchronous operations
+- Implement context managers for resource cleanup
+- Add inline comments for complex logic
+
+## Example Tool Types to Consider
+- Data processing and transformation
+- File system operations (read, analyze, search)
+- External API integrations
+- Database queries
+- Text analysis or generation (with sampling)
+- System information retrieval
+- Math or scientific calculations
+
+## Configuration Options
+- **For stdio Servers**:
+  - Simple direct execution
+  - Test with `uv run mcp dev server.py`
+  - Install to Claude: `uv run mcp install server.py`
+  
+- **For HTTP Servers**:
+  - Port configuration via environment variables
+  - Stateless mode for scalability: `stateless_http=True`
+  - JSON response mode: `json_response=True`
+  - CORS configuration for browser clients
+  - Mounting to existing ASGI servers (Starlette/FastAPI)
+
+## Testing Guidance
+- Explain how to run the server:
+  - stdio: `python server.py` or `uv run server.py`
+  - HTTP: `python server.py` then connect to `http://localhost:PORT/mcp`
+- Test with MCP Inspector: `uv run mcp dev server.py`
+- Install to Claude Desktop: `uv run mcp install server.py`
+- Include example tool invocations
+- Add troubleshooting tips
+
+## Additional Features to Consider
+- Context usage for logging, progress, and notifications
+- LLM sampling for AI-powered tools
+- User input elicitation for interactive workflows
+- Lifespan management for shared resources (databases, connections)
+- Structured output with Pydantic models
+- Icons for UI display
+- Image handling with Image class
+- Completion support for better UX
+
+## Best Practices
+- Use type hints everywhere - they're not optional
+- Return structured data when possible
+- Log to stderr (or use Context logging) to avoid stdout pollution
+- Clean up resources properly
+- Validate inputs early
+- Provide clear error messages
+- Test tools independently before LLM integration
+
+Generate a complete, production-ready MCP server with type safety, proper error handling, and comprehensive documentation.

package/assets/prompts/readme-blueprint-generator.prompt.md

@@ -0,0 +1,79 @@
+---
+description: 'Intelligent README.md generation prompt that analyzes project documentation structure and creates comprehensive repository documentation. Scans .github/copilot directory files and copilot-instructions.md to extract project information, technology stack, architecture, development workflow, coding standards, and testing approaches while generating well-structured markdown documentation with proper formatting, cross-references, and developer-focused content.'
+
+mode: 'agent'
+---
+
+# README Generator Prompt
+
+Generate a comprehensive README.md for this repository by analyzing the documentation files in the .github/copilot directory and the copilot-instructions.md file. Follow these steps:
+
+1. Scan all the files in the .github/copilot folder, like:
+   - Architecture
+   - Code_Exemplars
+   - Coding_Standards
+   - Project_Folder_Structure
+   - Technology_Stack
+   - Unit_Tests
+   - Workflow_Analysis
+
+2. Also review the copilot-instructions.md file in the .github folder
+
+3. Create a README.md with the following sections:
+
+## Project Name and Description
+- Extract the project name and primary purpose from the documentation
+- Include a concise description of what the project does
+
+## Technology Stack
+- List the primary technologies, languages, and frameworks used
+- Include version information when available
+- Source this information primarily from the Technology_Stack file
+
+## Project Architecture
+- Provide a high-level overview of the architecture
+- Consider including a simple diagram if described in the documentation
+- Source from the Architecture file
+
+## Getting Started
+- Include installation instructions based on the technology stack
+- Add setup and configuration steps
+- Include any prerequisites
+
+## Project Structure
+- Brief overview of the folder organization
+- Source from Project_Folder_Structure file
+
+## Key Features
+- List main functionality and features of the project
+- Extract from various documentation files
+
+## Development Workflow
+- Summarize the development process
+- Include information about branching strategy if available
+- Source from Workflow_Analysis file
+
+## Coding Standards
+- Summarize key coding standards and conventions
+- Source from the Coding_Standards file
+
+## Testing
+- Explain testing approach and tools
+- Source from Unit_Tests file
+
+## Contributing
+- Guidelines for contributing to the project
+- Reference any code exemplars for guidance
+- Source from Code_Exemplars and copilot-instructions
+
+## License
+- Include license information if available
+
+Format the README with proper Markdown, including:
+- Clear headings and subheadings
+- Code blocks where appropriate
+- Lists for better readability
+- Links to other documentation files
+- Badges for build status, version, etc. if information is available
+
+Keep the README concise yet informative, focusing on what new developers or users would need to know about the project.

package/assets/prompts/remember-interactive-programming.prompt.md

@@ -0,0 +1,13 @@
+---
+description: 'A micro-prompt that reminds the agent that it is an interactive programmer. Works great in Clojure when Copilot has access to the REPL (probably via Backseat Driver). Will work with any system that has a live REPL that the agent can use. Adapt the prompt with any specific reminders in your workflow and/or workspace.'
+title: 'Interactive Programming Nudge'
+---
+
+Remember that you are an interactive programmer with the system itself as your source of truth. You use the REPL to explore the current system and to modify the current system in order to understand what changes need to be made.
+
+Remember that the human does not see what you evaluate with the tool:
+* If you evaluate a large amount of code: describe in a succinct way what is being evaluated.
+
+When editing files you prefer to use the structural editing tools.
+
+Also remember to tend your todo list.