بنقرة واحدة
command-designer
Best practices for creating AWS Coworker slash commands as workflows
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Best practices for creating AWS Coworker slash commands as workflows
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | command-designer |
| description | Best practices for creating AWS Coworker slash commands as workflows |
| version | 1.0.0 |
| category | meta |
| agents | ["aws-coworker-meta-designer"] |
| tools | ["Read","Write","Edit","Glob","Grep"] |
This meta-skill provides patterns, templates, and best practices for creating slash commands in AWS Coworker. Slash commands are workflow orchestrators that combine agents and skills to accomplish specific tasks.
Before creating a command, answer:
What outcome does this achieve?
Who will use it?
What safeguards are needed?
| Dependency | When Needed |
|---|---|
| Agent | Primary orchestrator for the workflow |
| Skills | Reference material and patterns to follow |
| Tools | Capabilities required (Read, Bash, etc.) |
Naming Convention: aws-coworker-{action}-{scope}
Good names:
aws-coworker-plan-interaction — Clear action and scopeaws-coworker-execute-nonprod — Indicates environment constraintaws-coworker-audit-library — Self-referential for meta-commandsAvoid:
run-aws — Too vaguedo-stuff — Not descriptivemy-command — Not meaningfulFollow this template:
---
description: One-line description of what this command accomplishes
skills: [skill-1, skill-2]
agent: primary-agent-name
tools: [Read, Write, Bash, etc]
arguments:
- name: argument-name
description: What this argument specifies
required: true|false
default: optional-default-value
---
# Command Name
## Overview
[Brief description of what this command does and when to use it]
## Prerequisites
- [Prerequisite 1]
- [Prerequisite 2]
## Workflow
### Step 1: [First Phase]
[Instructions for the agent to follow]
### Step 2: [Second Phase]
[Instructions for the agent to follow]
### Step 3: [Approval/Checkpoint]
[Where human approval is required]
### Step 4: [Final Phase]
[Instructions for completion]
## Output
[What the user should expect as output]
## Error Handling
[How to handle common failures]
| Field | Type | Description |
|---|---|---|
description | string | Brief description, max 100 characters |
skills | array | Skills this command uses |
agent | string | Primary agent for orchestration |
tools | array | Tools this command may use |
| Field | Type | Description |
|---|---|---|
arguments | array | Input parameters |
arguments[].name | string | Argument identifier |
arguments[].description | string | What the argument does |
arguments[].required | boolean | Whether it's mandatory |
arguments[].default | any | Default value if not provided |
For commands that analyze and propose without executing:
---
description: Plan [what] for [context]
skills: [aws-cli-playbook, aws-well-architected, aws-governance-guardrails]
agent: aws-coworker-planner
tools: [Read, Grep, Glob]
---
Key characteristics:
For commands that make changes:
---
description: Execute [what] in [environment]
skills: [aws-cli-playbook, aws-governance-guardrails]
agent: aws-coworker-executor
tools: [Read, Write, Bash]
---
Key characteristics:
For commands that check compliance:
---
description: Validate [what] against [criteria]
skills: [aws-governance-guardrails]
agent: aws-coworker-guardrail
tools: [Read, Grep, Glob]
---
Key characteristics:
For commands that evolve AWS Coworker itself:
---
description: [Meta-operation] for AWS Coworker
skills: [skill-designer, command-designer, audit-library]
agent: aws-coworker-meta-designer
tools: [Read, Write, Edit, Bash]
---
Key characteristics:
Include explicit approval points for mutations:
### Step 3: Approval Checkpoint
**Before proceeding, confirm:**
1. Review the proposed changes above
2. Verify the target environment: `{profile}` / `{region}`
3. Confirm blast radius is acceptable
**Awaiting explicit user confirmation to proceed.**
Enforce environment constraints:
### Environment Validation
This command is restricted to **non-production** environments.
Before any execution:
1. Confirm profile is classified as non-production
2. Verify region is in the allowed list
3. If production detected, abort and suggest `/aws-coworker-prepare-prod-change`
Always disclose impact:
### Impact Assessment
**Resources affected:**
- [Resource type]: [count] in [scope]
- [Resource type]: [count] in [scope]
**Estimated blast radius:** [Low/Medium/High]
**Rollback complexity:** [Simple/Moderate/Complex]
Before finalizing a command, verify:
## Workflow
### Step 1: Discovery
Use `aws-cli-playbook` to discover current state:
- [Discovery command 1]
- [Discovery command 2]
### Step 2: Planning
Based on discovery, create execution plan:
- Proposed changes
- Sequence of operations
- Rollback steps
### Step 3: Validation
Run guardrail checks against the plan:
- Policy compliance
- Tagging requirements
- Security constraints
### Step 4: Approval
Present plan for human approval:
- Summary of changes
- Blast radius
- Risk assessment
### Step 5: Execution (upon approval)
Execute the approved plan:
- Run commands in sequence
- Validate each step
- Report completion
## Workflow
### Step 1: Inventory
Collect current state:
- List resources
- Gather configurations
- Note relationships
### Step 2: Analysis
Evaluate against criteria:
- Policy compliance
- Best practices
- Cost efficiency
### Step 3: Findings
Generate findings report:
- Issues identified
- Severity levels
- Affected resources
### Step 4: Recommendations
Propose remediation:
- Prioritized actions
- Implementation guidance
- Estimated effort
## Workflow
### Step 1: Generation
Create artifacts based on requirements:
- IaC templates
- Configuration files
- Documentation
### Step 2: Validation
Verify generated content:
- Syntax validation
- Policy compliance
- Completeness check
### Step 3: Review
Present for human review:
- Show generated files
- Highlight key decisions
- Note assumptions
### Step 4: Commit (upon approval)
Persist changes via Git:
- Create branch
- Stage files
- Commit with message
- Report PR-ready
Avoid these common mistakes:
❌ 20-step workflow with no clear phases
✅ Grouped into 4-6 logical phases with clear transitions
❌ Commands that modify without explicit acknowledgment
✅ Clear "this will modify..." statements before any mutation
❌ Execute without rollback guidance
✅ Every mutation includes "to undo this..." instructions
❌ "Make sure everything is set up"
✅ "Requires: AWS CLI configured, profile X with Y permissions"
❌ Assume everything succeeds
✅ Include "If X fails, do Y" guidance
Before publishing a command:
Use /aws-coworker-audit-library to check command quality.
**AWS Coworker Development Guardrails** - MANDATORY when extending or modifying AWS Coworker itself. TRIGGERS (use this skill when ANY of these apply): - User asks to add new skills, agents, or commands to AWS Coworker - User asks to modify existing AWS Coworker components - User asks about AWS Coworker architecture or design - User wants to add support for new AWS services - Discussion involves directory structure or file organization - User mentions "extending", "customizing", or "adding to" AWS Coworker - Creating or modifying files in: skills/, .claude/agents/, .claude/commands/, config/ NOT for: Using AWS Coworker to interact with AWS (that's CLAUDE.md's domain)
Canonical AWS CLI patterns for discover, plan, deploy, validate, and rollback
AWS Well-Architected Framework alignment for planning and review
Organization governance policies - never do, always do, and compliance rules
Git and GitHub best practices for AWS Coworker change management
Multi-account and OU strategy, landing zone patterns, and workload placement