skill-library-mcp 1.0.0

package/skills/bamboohr-automation/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: bamboohr-automation
+description: "Automate BambooHR tasks via Rube MCP (Composio): employees, time-off, benefits, dependents, employee updates. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# BambooHR Automation via Rube MCP
+
+Automate BambooHR human resources operations through Composio's BambooHR toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active BambooHR connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `bamboohr`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `bamboohr`
+3. If connection is not ACTIVE, follow the returned auth link to complete BambooHR authentication
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. List and Search Employees
+
+**When to use**: User wants to find employees or get the full employee directory
+
+**Tool sequence**:
+1. `BAMBOOHR_GET_ALL_EMPLOYEES` - Get the employee directory [Required]
+2. `BAMBOOHR_GET_EMPLOYEE` - Get detailed info for a specific employee [Optional]
+
+**Key parameters**:
+- For GET_ALL_EMPLOYEES: No required parameters; returns directory
+- For GET_EMPLOYEE:
+  - `id`: Employee ID (numeric)
+  - `fields`: Comma-separated list of fields to return (e.g., 'firstName,lastName,department,jobTitle')
+
+**Pitfalls**:
+- Employee IDs are numeric integers
+- GET_ALL_EMPLOYEES returns basic directory info; use GET_EMPLOYEE for full details
+- The `fields` parameter controls which fields are returned; omitting it may return minimal data
+- Common fields: firstName, lastName, department, division, jobTitle, workEmail, status
+- Inactive/terminated employees may be included; check `status` field
+
+### 2. Track Employee Changes
+
+**When to use**: User wants to detect recent employee data changes for sync or auditing
+
+**Tool sequence**:
+1. `BAMBOOHR_EMPLOYEE_GET_CHANGED` - Get employees with recent changes [Required]
+
+**Key parameters**:
+- `since`: ISO 8601 datetime string for change detection threshold
+- `type`: Type of changes to check (e.g., 'inserted', 'updated', 'deleted')
+
+**Pitfalls**:
+- `since` parameter is required; use ISO 8601 format (e.g., '2024-01-15T00:00:00Z')
+- Returns IDs of changed employees, not full employee data
+- Must call GET_EMPLOYEE separately for each changed employee's details
+- Useful for incremental sync workflows; cache the last sync timestamp
+
+### 3. Manage Time-Off
+
+**When to use**: User wants to view time-off balances, request time off, or manage requests
+
+**Tool sequence**:
+1. `BAMBOOHR_GET_META_TIME_OFF_TYPES` - List available time-off types [Prerequisite]
+2. `BAMBOOHR_GET_TIME_OFF_BALANCES` - Check current balances [Optional]
+3. `BAMBOOHR_GET_TIME_OFF_REQUESTS` - List existing requests [Optional]
+4. `BAMBOOHR_CREATE_TIME_OFF_REQUEST` - Submit a new request [Optional]
+5. `BAMBOOHR_UPDATE_TIME_OFF_REQUEST` - Modify or approve/deny a request [Optional]
+
+**Key parameters**:
+- For balances: `employeeId`, time-off type ID
+- For requests: `start`, `end` (date range), `employeeId`
+- For creation:
+  - `employeeId`: Employee to request for
+  - `timeOffTypeId`: Type ID from GET_META_TIME_OFF_TYPES
+  - `start`: Start date (YYYY-MM-DD)
+  - `end`: End date (YYYY-MM-DD)
+  - `amount`: Number of days/hours
+  - `notes`: Optional notes for the request
+- For update: `requestId`, `status` ('approved', 'denied', 'cancelled')
+
+**Pitfalls**:
+- Time-off type IDs are numeric; resolve via GET_META_TIME_OFF_TYPES first
+- Date format is 'YYYY-MM-DD' for start and end dates
+- Balances may be in hours or days depending on company configuration
+- Request status updates require appropriate permissions (manager/admin)
+- Creating a request does NOT auto-approve it; separate approval step needed
+
+### 4. Update Employee Information
+
+**When to use**: User wants to modify employee profile data
+
+**Tool sequence**:
+1. `BAMBOOHR_GET_EMPLOYEE` - Get current employee data [Prerequisite]
+2. `BAMBOOHR_UPDATE_EMPLOYEE` - Update employee fields [Required]
+
+**Key parameters**:
+- `id`: Employee ID (numeric, required)
+- Field-value pairs for the fields to update (e.g., `department`, `jobTitle`, `workPhone`)
+
+**Pitfalls**:
+- Only fields included in the request are updated; others remain unchanged
+- Some fields are read-only and cannot be updated via API
+- Field names must match BambooHR's expected field names exactly
+- Updates are audited; changes appear in the employee's change history
+- Verify current values with GET_EMPLOYEE before updating to avoid overwriting
+
+### 5. Manage Dependents and Benefits
+
+**When to use**: User wants to view employee dependents or benefit coverage
+
+**Tool sequence**:
+1. `BAMBOOHR_DEPENDENTS_GET_ALL` - List all dependents [Required]
+2. `BAMBOOHR_BENEFIT_GET_COVERAGES` - Get benefit coverage details [Optional]
+
+**Key parameters**:
+- For dependents: Optional `employeeId` filter
+- For benefits: Depends on schema; check RUBE_SEARCH_TOOLS for current parameters
+
+**Pitfalls**:
+- Dependent data includes sensitive PII; handle with appropriate care
+- Benefit coverages may include multiple plan types per employee
+- Not all BambooHR plans include benefits administration; check account features
+- Data access depends on API key permissions
+
+## Common Patterns
+
+### ID Resolution
+
+**Employee name -> Employee ID**:
+```
+1. Call BAMBOOHR_GET_ALL_EMPLOYEES
+2. Find employee by name in directory results
+3. Extract id (numeric) for detailed operations
+```
+
+**Time-off type name -> Type ID**:
+```
+1. Call BAMBOOHR_GET_META_TIME_OFF_TYPES
+2. Find type by name (e.g., 'Vacation', 'Sick Leave')
+3. Extract id for time-off requests
+```
+
+### Incremental Sync Pattern
+
+For keeping external systems in sync with BambooHR:
+```
+1. Store last_sync_timestamp
+2. Call BAMBOOHR_EMPLOYEE_GET_CHANGED with since=last_sync_timestamp
+3. For each changed employee ID, call BAMBOOHR_GET_EMPLOYEE
+4. Process updates in external system
+5. Update last_sync_timestamp
+```
+
+### Time-Off Workflow
+
+```
+1. GET_META_TIME_OFF_TYPES -> find type ID
+2. GET_TIME_OFF_BALANCES -> verify available balance
+3. CREATE_TIME_OFF_REQUEST -> submit request
+4. UPDATE_TIME_OFF_REQUEST -> approve/deny (manager action)
+```
+
+## Known Pitfalls
+
+**Employee IDs**:
+- Always numeric integers
+- Resolve names to IDs via GET_ALL_EMPLOYEES
+- Terminated employees retain their IDs
+
+**Date Formats**:
+- Time-off dates: 'YYYY-MM-DD'
+- Change detection: ISO 8601 with timezone
+- Inconsistent formats between endpoints; check each endpoint's schema
+
+**Permissions**:
+- API key permissions determine accessible fields and operations
+- Some operations require admin or manager-level access
+- Time-off approvals require appropriate role permissions
+
+**Sensitive Data**:
+- Employee data includes PII (names, addresses, SSN, etc.)
+- Handle all responses with appropriate security measures
+- Dependent data is especially sensitive
+
+**Rate Limits**:
+- BambooHR API has rate limits per API key
+- Bulk operations should be throttled
+- GET_ALL_EMPLOYEES is more efficient than individual GET_EMPLOYEE calls
+
+**Response Parsing**:
+- Response data may be nested under `data` key
+- Employee fields vary based on `fields` parameter
+- Empty fields may be omitted or returned as null
+- Parse defensively with fallbacks
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List all employees | BAMBOOHR_GET_ALL_EMPLOYEES | (none) |
+| Get employee details | BAMBOOHR_GET_EMPLOYEE | id, fields |
+| Track changes | BAMBOOHR_EMPLOYEE_GET_CHANGED | since, type |
+| Time-off types | BAMBOOHR_GET_META_TIME_OFF_TYPES | (none) |
+| Time-off balances | BAMBOOHR_GET_TIME_OFF_BALANCES | employeeId |
+| List time-off requests | BAMBOOHR_GET_TIME_OFF_REQUESTS | start, end, employeeId |
+| Create time-off request | BAMBOOHR_CREATE_TIME_OFF_REQUEST | employeeId, timeOffTypeId, start, end |
+| Update time-off request | BAMBOOHR_UPDATE_TIME_OFF_REQUEST | requestId, status |
+| Update employee | BAMBOOHR_UPDATE_EMPLOYEE | id, (field updates) |
+| List dependents | BAMBOOHR_DEPENDENTS_GET_ALL | employeeId |
+| Benefit coverages | BAMBOOHR_BENEFIT_GET_COVERAGES | (check schema) |

package/skills/basecamp-automation/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: basecamp-automation
+description: "Automate Basecamp project management, to-dos, messages, people, and to-do list organization via Rube MCP (Composio). Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# Basecamp Automation via Rube MCP
+
+Automate Basecamp operations including project management, to-do list creation, task management, message board posting, people management, and to-do group organization through Composio's Basecamp toolkit.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active Basecamp connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `basecamp`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `basecamp`
+3. If connection is not ACTIVE, follow the returned auth link to complete Basecamp OAuth
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Manage To-Do Lists and Tasks
+
+**When to use**: User wants to create to-do lists, add tasks, or organize work within a Basecamp project
+
+**Tool sequence**:
+1. `BASECAMP_GET_PROJECTS` - List projects to find the target bucket_id [Prerequisite]
+2. `BASECAMP_GET_BUCKETS_TODOSETS` - Get the to-do set within a project [Prerequisite]
+3. `BASECAMP_GET_BUCKETS_TODOSETS_TODOLISTS` - List existing to-do lists to avoid duplicates [Optional]
+4. `BASECAMP_POST_BUCKETS_TODOSETS_TODOLISTS` - Create a new to-do list in a to-do set [Required for list creation]
+5. `BASECAMP_GET_BUCKETS_TODOLISTS` - Get details of a specific to-do list [Optional]
+6. `BASECAMP_POST_BUCKETS_TODOLISTS_TODOS` - Create a to-do item in a to-do list [Required for task creation]
+7. `BASECAMP_CREATE_TODO` - Alternative tool for creating individual to-dos [Alternative]
+8. `BASECAMP_GET_BUCKETS_TODOLISTS_TODOS` - List to-dos within a to-do list [Optional]
+
+**Key parameters for creating to-do lists**:
+- `bucket_id`: Integer project/bucket ID (from GET_PROJECTS)
+- `todoset_id`: Integer to-do set ID (from GET_BUCKETS_TODOSETS)
+- `name`: Title of the to-do list (required)
+- `description`: HTML-formatted description (supports Rich text)
+
+**Key parameters for creating to-dos**:
+- `bucket_id`: Integer project/bucket ID
+- `todolist_id`: Integer to-do list ID
+- `content`: What the to-do is for (required)
+- `description`: HTML details about the to-do
+- `assignee_ids`: Array of integer person IDs
+- `due_on`: Due date in `YYYY-MM-DD` format
+- `starts_on`: Start date in `YYYY-MM-DD` format
+- `notify`: Boolean to notify assignees (defaults to false)
+- `completion_subscriber_ids`: Person IDs notified upon completion
+
+**Pitfalls**:
+- A project (bucket) can contain multiple to-do sets; selecting the wrong `todoset_id` creates lists in the wrong section
+- Always check existing to-do lists before creating to avoid near-duplicate names
+- Success payloads include user-facing URLs (`app_url`, `app_todos_url`); prefer returning these over raw IDs
+- All IDs (`bucket_id`, `todoset_id`, `todolist_id`) are integers, not strings
+- Descriptions support HTML formatting only, not Markdown
+
+### 2. Post and Manage Messages
+
+**When to use**: User wants to post messages to a project message board or update existing messages
+
+**Tool sequence**:
+1. `BASECAMP_GET_PROJECTS` - Find the target project and bucket_id [Prerequisite]
+2. `BASECAMP_GET_MESSAGE_BOARD` - Get the message board ID for the project [Prerequisite]
+3. `BASECAMP_CREATE_MESSAGE` - Create a new message on the board [Required]
+4. `BASECAMP_POST_BUCKETS_MESSAGE_BOARDS_MESSAGES` - Alternative message creation tool [Fallback]
+5. `BASECAMP_GET_MESSAGE` - Read a specific message by ID [Optional]
+6. `BASECAMP_PUT_BUCKETS_MESSAGES` - Update an existing message [Optional]
+
+**Key parameters**:
+- `bucket_id`: Integer project/bucket ID
+- `message_board_id`: Integer message board ID (from GET_MESSAGE_BOARD)
+- `subject`: Message title (required)
+- `content`: HTML body of the message
+- `status`: Set to `"active"` to publish immediately
+- `category_id`: Message type classification (optional)
+- `subscriptions`: Array of person IDs to notify; omit to notify all project members
+
+**Pitfalls**:
+- `status="draft"` can produce HTTP 400; use `status="active"` as the reliable option
+- `bucket_id` and `message_board_id` must belong to the same project; mismatches fail or misroute
+- Message content supports HTML tags only; not Markdown
+- Updates via `PUT_BUCKETS_MESSAGES` replace the entire body -- include the full corrected content, not just a diff
+- Prefer `app_url` from the response for user-facing confirmation links
+- Both `CREATE_MESSAGE` and `POST_BUCKETS_MESSAGE_BOARDS_MESSAGES` do the same thing; use CREATE_MESSAGE first and fall back to POST if it fails
+
+### 3. Manage People and Access
+
+**When to use**: User wants to list people, manage project access, or add new users
+
+**Tool sequence**:
+1. `BASECAMP_GET_PEOPLE` - List all people visible to the current user [Required]
+2. `BASECAMP_GET_PROJECTS` - Find the target project [Prerequisite]
+3. `BASECAMP_LIST_PROJECT_PEOPLE` - List people on a specific project [Required]
+4. `BASECAMP_GET_PROJECTS_PEOPLE` - Alternative to list project members [Alternative]
+5. `BASECAMP_PUT_PROJECTS_PEOPLE_USERS` - Grant or revoke project access [Required for access changes]
+
+**Key parameters for PUT_PROJECTS_PEOPLE_USERS**:
+- `project_id`: Integer project ID
+- `grant`: Array of integer person IDs to add to the project
+- `revoke`: Array of integer person IDs to remove from the project
+- `create`: Array of objects with `name`, `email_address`, and optional `company_name`, `title` for new users
+- At least one of `grant`, `revoke`, or `create` must be provided
+
+**Pitfalls**:
+- Person IDs are integers; always resolve names to IDs via GET_PEOPLE first
+- `project_id` for people management is the same as `bucket_id` for other operations
+- `LIST_PROJECT_PEOPLE` and `GET_PROJECTS_PEOPLE` are near-identical; use either
+- Creating users via `create` also grants them project access in one step
+
+### 4. Organize To-Dos with Groups
+
+**When to use**: User wants to organize to-dos within a list into color-coded groups
+
+**Tool sequence**:
+1. `BASECAMP_GET_PROJECTS` - Find the target project [Prerequisite]
+2. `BASECAMP_GET_BUCKETS_TODOLISTS` - Get the to-do list details [Prerequisite]
+3. `BASECAMP_GET_TODOLIST_GROUPS` - List existing groups in a to-do list [Optional]
+4. `BASECAMP_GET_BUCKETS_TODOLISTS_GROUPS` - Alternative group listing [Alternative]
+5. `BASECAMP_POST_BUCKETS_TODOLISTS_GROUPS` - Create a new group in a to-do list [Required]
+6. `BASECAMP_CREATE_TODOLIST_GROUP` - Alternative group creation tool [Alternative]
+
+**Key parameters**:
+- `bucket_id`: Integer project/bucket ID
+- `todolist_id`: Integer to-do list ID
+- `name`: Group title (required)
+- `color`: Visual color identifier -- one of: `white`, `red`, `orange`, `yellow`, `green`, `blue`, `aqua`, `purple`, `gray`, `pink`, `brown`
+- `status`: Filter for listing -- `"archived"` or `"trashed"` (omit for active groups)
+
+**Pitfalls**:
+- `POST_BUCKETS_TODOLISTS_GROUPS` and `CREATE_TODOLIST_GROUP` are near-identical; use either
+- Color values must be from the fixed palette; arbitrary hex/rgb values are not supported
+- Groups are sub-sections within a to-do list, not standalone entities
+
+### 5. Browse and Inspect Projects
+
+**When to use**: User wants to list projects, get project details, or explore project structure
+
+**Tool sequence**:
+1. `BASECAMP_GET_PROJECTS` - List all active projects [Required]
+2. `BASECAMP_GET_PROJECT` - Get comprehensive details for a specific project [Optional]
+3. `BASECAMP_GET_PROJECTS_BY_PROJECT_ID` - Alternative project detail retrieval [Alternative]
+
+**Key parameters**:
+- `status`: Filter by `"archived"` or `"trashed"`; omit for active projects
+- `project_id`: Integer project ID for detailed retrieval
+
+**Pitfalls**:
+- Projects are sorted by most recently created first
+- The response includes a `dock` array with tools (todoset, message_board, etc.) and their IDs
+- Use the dock tool IDs to find `todoset_id`, `message_board_id`, etc. for downstream operations
+
+## Common Patterns
+
+### ID Resolution
+Basecamp uses a hierarchical ID structure. Always resolve top-down:
+- **Project (bucket_id)**: `BASECAMP_GET_PROJECTS` -- find by name, capture the `id`
+- **To-do set (todoset_id)**: Found in project dock or via `BASECAMP_GET_BUCKETS_TODOSETS`
+- **Message board (message_board_id)**: Found in project dock or via `BASECAMP_GET_MESSAGE_BOARD`
+- **To-do list (todolist_id)**: `BASECAMP_GET_BUCKETS_TODOSETS_TODOLISTS`
+- **People (person_id)**: `BASECAMP_GET_PEOPLE` or `BASECAMP_LIST_PROJECT_PEOPLE`
+- Note: `bucket_id` and `project_id` refer to the same entity in different contexts
+
+### Pagination
+Basecamp uses page-based pagination on list endpoints:
+- Response headers or body may indicate more pages available
+- `GET_PROJECTS`, `GET_BUCKETS_TODOSETS_TODOLISTS`, and list endpoints return paginated results
+- Continue fetching until no more results are returned
+
+### Content Formatting
+- All rich text fields use HTML, not Markdown
+- Wrap content in `<div>` tags; use `<strong>`, `<em>`, `<ul>`, `<ol>`, `<li>`, `<a>` etc.
+- Example: `<div><strong>Important:</strong> Complete by Friday</div>`
+
+## Known Pitfalls
+
+### ID Formats
+- All Basecamp IDs are integers, not strings or UUIDs
+- `bucket_id` = `project_id` (same entity, different parameter names across tools)
+- To-do set IDs, to-do list IDs, and message board IDs are found in the project's `dock` array
+- Person IDs are integers; resolve names via `GET_PEOPLE` before operations
+
+### Status Field
+- `status="draft"` for messages can cause HTTP 400; always use `status="active"`
+- Project/to-do list status filters: `"archived"`, `"trashed"`, or omit for active
+
+### Content Format
+- HTML only, never Markdown
+- Updates replace the entire body, not a partial diff
+- Invalid HTML tags may be silently stripped
+
+### Rate Limits
+- Basecamp API has rate limits; space out rapid sequential requests
+- Large projects with many to-dos should be paginated carefully
+
+### URL Handling
+- Prefer `app_url` from API responses for user-facing links
+- Do not reconstruct Basecamp URLs manually from IDs
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List projects | `BASECAMP_GET_PROJECTS` | `status` |
+| Get project | `BASECAMP_GET_PROJECT` | `project_id` |
+| Get project detail | `BASECAMP_GET_PROJECTS_BY_PROJECT_ID` | `project_id` |
+| Get to-do set | `BASECAMP_GET_BUCKETS_TODOSETS` | `bucket_id`, `todoset_id` |
+| List to-do lists | `BASECAMP_GET_BUCKETS_TODOSETS_TODOLISTS` | `bucket_id`, `todoset_id` |
+| Get to-do list | `BASECAMP_GET_BUCKETS_TODOLISTS` | `bucket_id`, `todolist_id` |
+| Create to-do list | `BASECAMP_POST_BUCKETS_TODOSETS_TODOLISTS` | `bucket_id`, `todoset_id`, `name` |
+| Create to-do | `BASECAMP_POST_BUCKETS_TODOLISTS_TODOS` | `bucket_id`, `todolist_id`, `content` |
+| Create to-do (alt) | `BASECAMP_CREATE_TODO` | `bucket_id`, `todolist_id`, `content` |
+| List to-dos | `BASECAMP_GET_BUCKETS_TODOLISTS_TODOS` | `bucket_id`, `todolist_id` |
+| List to-do groups | `BASECAMP_GET_TODOLIST_GROUPS` | `bucket_id`, `todolist_id` |
+| Create to-do group | `BASECAMP_POST_BUCKETS_TODOLISTS_GROUPS` | `bucket_id`, `todolist_id`, `name`, `color` |
+| Create to-do group (alt) | `BASECAMP_CREATE_TODOLIST_GROUP` | `bucket_id`, `todolist_id`, `name` |
+| Get message board | `BASECAMP_GET_MESSAGE_BOARD` | `bucket_id`, `message_board_id` |
+| Create message | `BASECAMP_CREATE_MESSAGE` | `bucket_id`, `message_board_id`, `subject`, `status` |
+| Create message (alt) | `BASECAMP_POST_BUCKETS_MESSAGE_BOARDS_MESSAGES` | `bucket_id`, `message_board_id`, `subject` |
+| Get message | `BASECAMP_GET_MESSAGE` | `bucket_id`, `message_id` |
+| Update message | `BASECAMP_PUT_BUCKETS_MESSAGES` | `bucket_id`, `message_id` |
+| List all people | `BASECAMP_GET_PEOPLE` | (none) |
+| List project people | `BASECAMP_LIST_PROJECT_PEOPLE` | `project_id` |
+| Manage access | `BASECAMP_PUT_PROJECTS_PEOPLE_USERS` | `project_id`, `grant`, `revoke`, `create` |

package/skills/bash-defensive-patterns/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: bash-defensive-patterns
+description: Master defensive Bash programming techniques for production-grade scripts. Use when writing robust shell scripts, CI/CD pipelines, or system utilities requiring fault tolerance and safety.
+---
+
+# Bash Defensive Patterns
+
+Comprehensive guidance for writing production-ready Bash scripts using defensive programming techniques, error handling, and safety best practices to prevent common pitfalls and ensure reliability.
+
+## Use this skill when
+
+- Writing production automation scripts
+- Building CI/CD pipeline scripts
+- Creating system administration utilities
+- Developing error-resilient deployment automation
+- Writing scripts that must handle edge cases safely
+- Building maintainable shell script libraries
+- Implementing comprehensive logging and monitoring
+- Creating scripts that must work across different platforms
+
+## Do not use this skill when
+
+- You need a single ad-hoc shell command, not a script
+- The target environment requires strict POSIX sh only
+- The task is unrelated to shell scripting or automation
+
+## Instructions
+
+1. Confirm the target shell, OS, and execution environment.
+2. Enable strict mode and safe defaults from the start.
+3. Validate inputs, quote variables, and handle files safely.
+4. Add logging, error traps, and basic tests.
+
+## Safety
+
+- Avoid destructive commands without confirmation or dry-run flags.
+- Do not run scripts as root unless strictly required.
+
+Refer to `resources/implementation-playbook.md` for detailed patterns, checklists, and templates.
+
+## Resources
+
+- `resources/implementation-playbook.md` for detailed patterns, checklists, and templates.