New to Claude Skills? Learn how to install them →

Ctailcallhq on GitHub

Create Commands

Free

Easily manage commands for code-forge workflows.

Get this skill

Free · Opens the source repo

What Create Commands does

Create Commands allows developers to define and manage custom commands for the code-forge application, enhancing their workflow automation. Commands are stored as markdown files in the designated .forge/commands directory within the current working directory of a project. Each command file consists of YAML frontmatter that specifies the command's name and description, followed by a markdown body detailing the steps to execute. This structured approach ensures clarity and consistency in command definitions.

The command files support special tags such as <lint>, <test>, and <shell>, which facilitate automated workflows by allowing users to include specific linting, testing, or shell commands directly within the command steps. This feature is particularly useful for teams looking to streamline their development processes by automating routine checks and actions. By following the provided templates and best practices, users can create simple or complex commands tailored to their needs.

This skill is ideal for developers who frequently work with the code-forge application and need a systematic way to create, modify, and understand command structures. Whether you're adding new commands or refining existing ones, Create Commands provides the necessary tools to enhance your productivity and maintain project organization. The clear file structure and tagging system help ensure that commands are easily discoverable and executable within the code-forge environment.

When to use it

Use this skill when you need to create or modify commands for the code-forge application to automate tasks and improve workflow efficiency.

When not to use it

This skill is not suitable for projects that do not utilize the code-forge application or for users who do not require command automation.

What you can build with it

Automating Code Checks

Create a command that runs linting and testing checks automatically before committing code changes.

Streamlining Pull Request Updates

Define a command that updates pull request descriptions based on the current changes and conventions.

Managing Project Workflows

Develop a series of commands to manage various project tasks, ensuring consistency and efficiency.

How to install Create Commands

View source

1. Install with the skills CLI

npx skills add tailcallhq/forgecode/create-command --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by tailcallhq

Create Commands

Create and manage commands for the code-forge application. Commands are modular workflows that can be invoked to perform specific tasks.

File Location

CRITICAL: All command files must be created in the <cwd>/.forge/commands directory, where <cwd> is the current working directory of your code-forge project.

  • Directory: <cwd>/.forge/commands
  • File format: {command-name}.md
  • Example: If your project is at /home/user/my-project, commands go in /home/user/my-project/.forge/commands/

This is the only location where forge will discover and load custom commands.

Command File Structure

Every command file must have:

  1. YAML Frontmatter (required):

    • name: Command identifier (use hyphens for multi-word names)
    • description: What the command does
  2. Command Body (required):

    • List of steps to execute
    • Special tags for automated workflows
    • Clear instructions for each step

Example Command File

---
name: check
description: Checks if the code is ready to be committed
---

- Run the `lint` and `test` commands and verify if everything is fine.
  <lint>cargo +nightly fmt --all; cargo +nightly clippy --fix --allow-staged --allow-dirty --workspace</lint>
  <test>cargo insta test --accept --unreferenced=delete</test>
- Fix every issue found in the process

Complete Sample Command

This sample demonstrates all three tag types:

---
name: sample-command
description: Sample command demonstrating the command file structure
---

This is a sample command that demonstrates the structure of command files.

- First step: Perform an initial action
  <lint>echo "Running linting..."</lint>
- Second step: Execute tests
  <test>echo "Running tests..."</test>
- Third step: Complete the workflow
  <shell>echo "Workflow complete!"</shell>
- Final step: Verify everything worked correctly

Creating a New Command

Step 1: Determine Command Purpose

Identify what the command should accomplish:

  • What task will it perform?
  • What steps are involved?
  • Are there automated checks or tests needed?
  • What should the user do with the results?

Step 2: Choose Command Name

Use verb-based names with hyphens for multi-word commands:

  • Good: check, fixme, pr-description, run-tests
  • Bad: checker, fixing, PRdescription

Step 3: Write the Command File

Create the file in the <cwd>/.forge/commands directory with the format: {command-name}.md

IMPORTANT: The file MUST be in <cwd>/.forge/commands where <cwd> is your current working directory. Commands placed anywhere else will not be discovered by forge.

Frontmatter

---
name: your-command-name
description: Clear, concise description of what this command does
---

Command Body

Use markdown lists for steps. Each step should:

  • Start with a clear action verb
  • Be specific and actionable
  • Include context about what to do

Special Command Tags

Use these tags for automated workflows:

<lint> Tag

For linting/formatting commands:

<lint>cargo +nightly fmt --all; cargo +nightly clippy --fix --allow-staged --allow-dirty --workspace</lint>

<test> Tag

For testing commands:

<test>cargo insta test --accept --unreferenced=delete</test>

<shell> Tag

For general shell commands (not linting or testing):

<shell>rm -rf target/debug</shell>

Using Tags

Tags should be placed on their own line after the step description:

- Run linting and testing
  <lint>your-lint-command</lint>
  <test>your-test-command</test>

Command Types

Simple Commands

Single-step or instruction-only commands:

---
name: fixme
description: Looks for all the fixme comments in the code and attempts to fix them
---

Find all the FIXME comments in source-code files and attempt to fix them.

Multi-Step Commands

Commands with multiple sequential steps:

---
name: pr-description
description: Updates the description of the PR
---

- I have created a Pull Request with all the accepted changes
- Understand the current PR deeply using the GH CLI and update the PR title and description
- Make sure the title follows conventional commits standard
- Top-level summary should contain 2-3 lines about the core functionality improvements

Automated Workflow Commands

Commands that include automated checks:

---
name: check
description: Checks if the code is ready to be committed
---

- Run the `lint` and `test` commands and verify if everything is fine.
  <lint>cargo +nightly fmt --all; cargo +nightly clippy --fix --allow-staged --allow-dirty --workspace</lint>
  <test>cargo insta test --accept --unreferenced=delete</test>
- Fix every issue found in the process

Command Templates

Simple Command Template

---
name: simple-command
description: Does one specific thing
---

Single clear instruction or description.

Automated Workflow Template

---
name: automated-workflow
description: Runs automated checks and performs follow-up actions
---

- Run automated checks
  <lint>your-lint-command</lint>
  <test>your-test-command</test>
- Review and fix any issues found
- Complete the workflow

Multi-Step Workflow Template

---
name: multi-step-workflow
description: Performs multiple sequential steps
---

- First step with clear action
- Second step with context
- Third step with specific requirements
- Final step with verification

Git Workflow Template

---
name: git-workflow
description: Performs git operations
---

- Stage changes
  <shell>git add .</shell>
- Run pre-commit checks
  <lint>cargo fmt --all</lint>
  <test>cargo test</test>
- Commit with message
  <shell>git commit -m "your commit message"</shell>
- Push to remote
  <shell>git push</shell>

Best Practices

Naming

  • Use lowercase letters
  • Use hyphens to separate words
  • Use verb-based names (imperative form)
  • Keep names short but descriptive

Descriptions

  • Be clear and concise
  • Describe what the command does, not how
  • Include the main purpose and key outcomes
  • Avoid implementation details

Command Steps

  • Use numbered lists for sequential steps
  • Start each step with an action verb
  • Be specific about what to do
  • Include context for complex steps
  • Use present tense

Special Tags

  • Place tags on their own line after the step
  • Only use <lint>, <test>, and <shell> tags
  • Include complete commands that can be executed
  • Use appropriate flags for your workflow

Common Patterns

Git Workflow Commands

---
name: commit-check
description: Verifies code is ready to commit
---

- Run linting and tests
  <lint>cargo fmt --all; cargo clippy --fix --allow-staged</lint>
  <test>cargo test</test>
- Review and fix any issues
- Stage all changes

Documentation Commands

---
name: update-docs
description: Updates documentation for recent changes
---

- Review recent code changes
- Identify functions or modules that need documentation
- Update inline documentation comments
- Regenerate any auto-generated docs
- Verify documentation builds successfully

Cleanup Commands

---
name: cleanup
description: Cleans up temporary files and artifacts
---

- Remove build artifacts
  <shell>rm -rf target/debug</shell>
- Remove temporary files
  <shell>find . -name "*.tmp" -delete</shell>
- Clean up dependency caches if needed
- Verify the project still builds

Build and Deploy Commands

---
name: build-deploy
description: Builds the project and deploys to staging
---

- Build the project in release mode
  <shell>cargo build --release</shell>
- Run integration tests
  <test>cargo test --test integration</test>
- Build Docker image
  <shell>docker build -t myapp:latest .</shell>
- Tag image for staging
  <shell>docker tag myapp:latest myapp:staging</shell>
- Push to registry
  <shell>docker push myapp:staging</shell>
- Deploy to staging environment
  <shell>kubectl set image deployment/myapp myapp=myapp:staging</shell>

Validation Checklist

Use this checklist to verify your command is complete and correct:

File Structure

  • File is in the <cwd>/.forge/commands directory (CRITICAL)
  • Filename matches command name (e.g., check.md for name: check)
  • File has .md extension
  • YAML frontmatter uses --- delimiters

Frontmatter

  • name field is present
  • name uses lowercase letters
  • name uses hyphens for multi-word names
  • name is verb-based (imperative form)
  • description field is present
  • description is clear and concise
  • description describes what, not how

Command Body

  • At least one step is defined
  • Steps use bullet points (-)
  • Each step starts with action verb
  • Steps are specific and actionable
  • Complex steps include context
  • Steps are in logical order

Special Tags

  • Tags are on their own line after step description
  • Only valid tags are used (<lint>, <test>, <shell>)
  • Tag commands are complete and executable
  • Tag commands use appropriate flags
  • Tag commands are properly formatted

Content Quality

  • Command name is descriptive
  • Steps are clear and unambiguous
  • No redundant or duplicate steps
  • Steps follow logical sequence
  • Special requirements are documented
  • Error handling is considered

Testing

  • Command can be executed successfully
  • All steps complete as expected
  • Special tags work correctly
  • Output is as expected
  • Edge cases are handled
  • Command is recognized by forge: Run forge list command --custom (or forge list cmd) and verify your command appears in the list

Common Mistakes to Avoid

Frontmatter Mistakes

Bad: Wrong delimiter:

---
name: my-command
description: My command

(Missing closing ---)

Good: Correct:

---
name: my-command
description: My command
---

Bad: Missing required field:

---
name: my-command
---

(Missing description)

Good: Correct:

---
name: my-command
description: Does something useful
---

Naming Mistakes

Bad: CamelCase name:

---
name: myCommand
description: Does something
---

Good: Correct:

---
name: my-command
description: Does something
---

Bad: Noun instead of verb:

---
name: checker
description: Checks something
---

Good: Correct:

---
name: check
description: Checks something
---

Step Mistakes

Bad: No action verb:

---
name: test
description: Runs tests
---

- The tests
- The code

Good: Correct:

---
name: test
description: Runs tests
---

- Run all tests
- Verify code quality

Bad: Vague steps:

---
name: deploy
description: Deploys application
---

- Do the deployment
- Make sure it works

Good: Correct:

---
name: deploy
description: Deploys application to production
---

- Build the Docker image
  <shell>docker build -t myapp:latest .</shell>
- Push to registry
  <shell>docker push myapp:latest</shell>
- Deploy to production
  <shell>kubectl set image deployment/myapp myapp=myapp:latest</shell>
- Verify deployment is healthy

Tag Mistakes

Bad: Tag on same line:

- Run tests <test>cargo test</test>

Good: Correct:

- Run tests
  <test>cargo test</test>

Bad: Invalid tag:

- Run checks
  <check>cargo clippy</check>

Good: Correct:

- Run checks
  <lint>cargo clippy</lint>

Bad: Incomplete command:

- Format code
  <lint>cargo fmt</lint>

(Missing --all flag)

Good: Correct:

- Format code
  <lint>cargo fmt --all</lint>

Quick Reference

File Location

  • Directory: <cwd>/.forge/commands (where <cwd> is current working directory)
  • Format: {command-name}.md
  • CRITICAL: Commands MUST be in this exact location to be discovered by forge

Valid Tags

  • <lint> - For linting/formatting commands
  • <test> - For testing commands
  • <shell> - For general shell commands

Naming Rules

  • Lowercase only
  • Hyphens for multi-word names
  • Verb-based (imperative form)
  • Keep it short but descriptive

Step Guidelines

  • Start with action verb
  • Be specific
  • Include context for complex steps
  • Use present tense
  • Keep steps focused

When to Use Tags

  • Use <lint> when running formatters or linters
  • Use <test> when running test suites
  • Use <shell> for other shell commands
  • Place tags on their own line after step description
  • Don't use tags if the step is just an instruction

Testing Your Command

After creating a command, test it by:

  1. Syntax Check: Verify YAML is valid

    # If you have yamllint installed
    yamllint path/to/your-command.md
    
  2. Manual Review: Read through the command

    • Does each step make sense?
    • Is the order logical?
    • Are all commands complete?
  3. Execution Test: Run the command

    • Does each step execute successfully?
    • Is the output as expected?
    • Are there any errors?
  4. Forge Recognition Test: Verify the command is recognized by forge

    # Option 1: List all commands (custom commands marked as type: custom)
    forge list command
    
    # Option 2: List only custom commands
    forge list cmd
    
    # Option 3: List only custom commands (newer versions)
    forge list command --custom
    
    • Does your command appear in the list?
    • Is the name correct?
    • Is the description correct?
  5. Edge Cases: Consider unusual scenarios

    • What happens if a step fails?
    • What if the environment is different?
    • What if files are missing?

Verification

After creating a command:

  1. Verify the file location: Ensure the file is in <cwd>/.forge/commands directory (CRITICAL - commands anywhere else will not be found)

  2. Check YAML frontmatter is valid (use --- delimiters)

  3. Ensure the command name matches the filename (without .md)

  4. Verify the command is recognized by forge:

    # Option 1: List all commands (custom commands marked as type: custom)
    forge list command
    
    # Option 2: List only custom commands
    forge list cmd
    
    # Option 3: List only custom commands (newer versions)
    forge list command --custom
    

    Your new command should appear in the list with its name and description

  5. Test the command to ensure it works as expected

  6. Verify special tags are properly formatted

If your command doesn't appear in the list, check:

  • File location: File MUST be in <cwd>/.forge/commands directory (this is the most common issue)
  • Filename matches the name field in frontmatter
  • YAML frontmatter is properly formatted with --- delimiters
  • Both name and description fields are present

Getting Help

If you're unsure about something:

  • Review the examples in this skill
  • Follow the validation checklist
  • Test your command before finalizing

Frequently asked questions about Create Commands

Similar skills