Add clear and concise logging with -v flag

examples/.agents/commands/example-command-no-expansion.md

@@ -0,0 +1,11 @@
+---
+expand: false
+---
+
+# Example Command Without Parameter Expansion
+
+This command content will not have parameters expanded.
+
+Placeholders like ${project_name}, ${version}, and ${environment} will be preserved as-is.
+
+Use this when you want the command's output to contain template variables for later processing.

examples/.agents/commands/setup-database.md

@@ -0,0 +1,22 @@
+---
+selectors:
+  database: postgres
+  feature: auth
+---
+
+# Database Setup Instructions
+
+This command provides database setup instructions. When this command is used in a task,
+it will automatically include rules that are tagged with `database: postgres` and 
+`feature: auth` in their frontmatter.
+
+## PostgreSQL Configuration
+
+Connect to PostgreSQL:
+```bash
+psql -U ${db_user} -d ${db_name}
+```
+
+## Authentication Setup
+
+Configure authentication tables and initial data.

examples/.agents/rules/example-rule-no-expansion.md

@@ -0,0 +1,11 @@
+---
+expand: false
+---
+
+# Example Rule Without Parameter Expansion
+
+This rule demonstrates disabling parameter expansion at the rule level.
+
+Template variables: ${variable1}, ${variable2}, ${variable3}
+
+This is useful when rules contain template syntax that should be preserved for the AI agent to process.

examples/.agents/rules/go-implementation-cursor.md

@@ -0,0 +1,29 @@
+---
+task_name: implement-feature
+language: go
+agent: cursor
+---
+
+# Go Implementation Standards for Feature Development
+
+This rule demonstrates standard frontmatter fields for rules:
+
+- **task_name**: `implement-feature` - This rule only applies to the `implement-feature` task
+- **language**: `go` - This rule only applies when the language is go
+- **agent**: `cursor` - This rule is optimized for the Cursor AI agent
+
+## When This Rule Is Included
+
+This rule will be included when:
+1. The task being run is `implement-feature` (or has `task_name: implement-feature` selector)
+2. AND the task has `language: go` (or `-s language=go` is specified)
+3. AND the task has `agent: cursor` (or `-a cursor` is specified)
+
+## Go-Specific Implementation Guidelines
+
+When implementing features in Go:
+- Follow Go idioms and conventions
+- Use table-driven tests
+- Handle errors explicitly
+- Keep functions small and focused
+- Use interfaces for abstraction

examples/.agents/rules/implementation-go.md

@@ -0,0 +1,49 @@
+---
+stage: implementation
+language: go
+---
+
+# Go Implementation Standards
+
+## Code Style
+
+- Follow Go standard formatting (use `gofmt`)
+- Use meaningful variable and function names
+- Keep functions focused and small
+- Comment exported functions and types
+- Use Go idioms and patterns
+
+## Error Handling
+
+- Always check and handle errors explicitly
+- Wrap errors with context using `fmt.Errorf`
+- Return errors rather than panicking
+- Use custom error types when appropriate
+
+## Testing
+
+- Write unit tests for all functions
+- Use table-driven tests for multiple scenarios
+- Aim for high test coverage (>80%)
+- Use meaningful test names that describe the scenario
+
+## Concurrency
+
+- Use channels for communication between goroutines
+- Use sync package primitives appropriately
+- Avoid shared state when possible
+- Document goroutine lifecycle
+
+## Dependencies
+
+- Minimize external dependencies
+- Use standard library when possible
+- Vendor dependencies for reproducible builds
+- Keep dependencies up to date
+
+## Performance
+
+- Profile before optimizing
+- Avoid premature optimization
+- Use benchmarks to measure performance
+- Consider memory allocations

examples/.agents/rules/planning.md

@@ -0,0 +1,42 @@
+---
+stage: planning
+---
+
+# Feature Planning Guidelines
+
+When planning new features, follow these principles:
+
+## Architecture First
+
+- Consider how the feature fits into existing architecture
+- Identify dependencies and affected components
+- Plan for backwards compatibility
+- Consider scalability and performance implications
+
+## Design Patterns
+
+- Use established design patterns from the codebase
+- Maintain consistency with existing code structure
+- Follow SOLID principles
+- Plan for testability from the start
+
+## Breaking Down Work
+
+- Decompose features into manageable units
+- Identify critical path vs. nice-to-have elements
+- Plan incremental delivery when possible
+- Consider feature flags for gradual rollout
+
+## Risk Assessment
+
+- Identify technical risks and mitigation strategies
+- Consider security implications
+- Plan for error handling and edge cases
+- Document assumptions and constraints
+
+## Documentation Planning
+
+- Plan what documentation will be needed
+- Consider API documentation requirements
+- Plan for user-facing documentation
+- Identify training or onboarding needs

examples/.agents/rules/testing.md

@@ -0,0 +1,47 @@
+---
+stage: testing
+---
+
+# Testing Standards
+
+## Test Coverage
+
+- Write tests for all public APIs
+- Test edge cases and error conditions
+- Aim for >80% code coverage
+- Write integration tests for critical paths
+
+## Test Organization
+
+- Group related tests in test files
+- Use descriptive test names
+- Follow AAA pattern: Arrange, Act, Assert
+- Keep tests independent and isolated
+
+## Test Data
+
+- Use fixtures for complex test data
+- Avoid hardcoding test data in tests
+- Clean up test data after tests
+- Use realistic test scenarios
+
+## Mocking and Stubbing
+
+- Mock external dependencies
+- Use interfaces for testability
+- Avoid over-mocking
+- Test real integrations when possible
+
+## Performance Testing
+
+- Write benchmarks for performance-critical code
+- Set performance baselines
+- Monitor performance over time
+- Load test under realistic conditions
+
+## Test Automation
+
+- All tests must run in CI/CD
+- Tests should be fast (<5 minutes total)
+- Flaky tests should be fixed or removed
+- Failed tests should block deployment

examples/.agents/tasks/code-review.md

@@ -0,0 +1,63 @@
+---
+task_name: code-review
+---
+
+# Code Review Task
+
+You are an expert code reviewer analyzing a pull request.
+
+## Pull Request Information
+
+- **PR Number**: #${pr_number}
+- **Title**: ${pr_title}
+- **URL**: ${pr_url}
+- **Base Branch**: ${base_branch}
+- **Head Branch**: ${head_branch}
+
+## Your Task
+
+Perform a thorough code review covering:
+
+1. **Code Quality**
+   - Readability and maintainability
+   - Adherence to coding standards
+   - Proper naming conventions
+   - Code organization
+
+2. **Correctness**
+   - Logic errors or bugs
+   - Edge case handling
+   - Error handling completeness
+   - Type safety
+
+3. **Testing**
+   - Test coverage adequacy
+   - Test quality and relevance
+   - Missing test scenarios
+   - Test maintainability
+
+4. **Security**
+   - Security vulnerabilities
+   - Input validation
+   - Authentication/authorization
+   - Sensitive data handling
+
+5. **Performance**
+   - Performance implications
+   - Resource usage
+   - Scalability concerns
+   - Optimization opportunities
+
+6. **Documentation**
+   - Code comments where needed
+   - API documentation
+   - README updates if needed
+   - Migration guides if applicable
+
+## Output Format
+
+Provide your review as:
+- Overall summary
+- Specific inline comments for issues
+- Recommendations for improvement
+- Approval status (approve, request changes, comment)

examples/.agents/tasks/example-mcp-arbitrary-fields.md

@@ -0,0 +1,81 @@
+---
+task_name: example-mcp-arbitrary-fields
+agent: cursor
+---
+
+# Example Rule with MCP Server Configuration
+
+This example demonstrates how rules can specify MCP server configuration with arbitrary custom fields.
+
+Note: MCP servers are specified in rules, not in tasks. Tasks can select which rules (and thus which MCP servers) to use via selectors.
+
+## The `mcp_server` Field in Rules
+
+Rules can specify a single MCP server configuration with both standard and arbitrary custom fields.
+
+The `mcp_server` field, when present in a rule, specifies that rule's single MCP server configuration with both standard and arbitrary custom fields. Tasks cannot define MCP servers directly.
+
+**Standard fields:**
+- `command`: The executable to run (e.g., "python", "npx", "docker")
+- `args`: Array of command-line arguments
+- `env`: Environment variables for the server process
+- `type`: Connection protocol ("stdio", "http", "sse") - optional, defaults to stdio
+- `url`: Endpoint URL for HTTP/SSE types
+- `headers`: Custom HTTP headers for HTTP/SSE types
+
+## Example Rule with MCP Server
+
+```yaml
+---
+rule_name: python-mcp-server
+mcp_server:
+  command: python
+  args: ["-m", "server"]
+  env:
+    PYTHON_PATH: /usr/bin/python3
+  custom_config:
+    host: localhost
+    port: 5432
+    ssl: true
+    pool:
+      min: 2
+      max: 10
+  monitoring:
+    enabled: true
+    metrics_port: 9090
+---
+
+# Python MCP Server Rule
+
+This rule provides the Python MCP server configuration.
+```
+
+## Why Arbitrary Fields?
+
+Different MCP servers may need different configuration options beyond the standard fields. Arbitrary fields allow you to:
+
+1. **Add custom metadata**: Version info, regions, endpoints, etc.
+2. **Configure behavior**: Caching, retry policies, timeouts, rate limits
+3. **Include nested config**: Complex configuration objects specific to your server
+4. **Future-proof**: Add new fields without changing the schema
+
+## How It Works
+
+The `MCPServerConfig` struct includes a `Content` field that captures all fields from YAML/JSON:
+
+```go
+type MCPServerConfig struct {
+    // Standard fields
+    Type    TransportType
+    Command string
+    Args    []string
+    Env     map[string]string
+    URL     string
+    Headers map[string]string
+
+    // Arbitrary fields via inline map
+    Content map[string]any `yaml:",inline"`
+}
+```
+
+All fields (both standard and custom) are preserved when the configuration is parsed and can be accessed via the struct fields or the `Content` map.

examples/.agents/tasks/example-no-expansion.md

@@ -0,0 +1,31 @@
+---
+task_name: example-no-expansion
+expand: false
+---
+
+# Example Task Without Parameter Expansion
+
+This task demonstrates how to disable parameter expansion using the `expand: false` frontmatter field.
+
+## Usage
+
+When `expand` is set to `false`, parameter placeholders are preserved as-is:
+
+- Issue Number: ${issue_number}
+- Issue Title: ${issue_title}
+- Repository: ${repo}
+- Branch: ${branch}
+
+This is useful when:
+1. You want to pass parameters directly to an AI agent that will handle its own substitution
+2. You're using template syntax that conflicts with the parameter expansion syntax
+3. You want to preserve the template for later processing
+
+## Example
+
+```bash
+coding-context -p issue_number=123 -p issue_title="Bug Fix" example-no-expansion
+```
+
+Even though parameters are passed on the command line, they won't be expanded in the output.
+The placeholders `${issue_number}` and `${issue_title}` will remain unchanged.