Agent skill

Code-Forge Command Creator

by tailcallhq in tailcallhq/forgecode

Creates and structures custom command files for the code-forge CLI, with YAML frontmatter plus special tags for automated lint and test steps.

Apache-2.0Auto-check passedAgent Workflows

Install Code-Forge Command Creator

skills CLI
$ npx skills add tailcallhq/forgecode --skill create-command -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install tailcallhq/forgecode create-command --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/tailcallhq/forgecode.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.forge/skills/create-command .claude/skills/create-command && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-command
GitHub stars
7.6k
Token cost
~3.9k tokens
SKILL.md length
1,112 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
Apache-2.0

At a glance

Creates and structures custom command files for the code-forge CLI, with YAML frontmatter plus special tags for automated lint and test steps.

  • Works in 3 steps: Determine Command Purpose → Choose Command Name → Write the Command File
  • Adding a new custom command to a code-forge project
  • SKILL.md covers File Location, Command File Structure, Creating a New Command and Special Command Tags, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Every command is a single Markdown file placed under the project's forge commands directory, named after the command, and it is the only location forge discovers custom commands from. Each file needs YAML frontmatter with a name and description, plus a body listing the steps to execute in order, written as clear, specific, actionable instructions starting with an action verb.

Command names use hyphens for multi-word names and should read as verbs, such as check or run-tests, rather than nouns like checker. Special tags mark steps meant for automated linting or testing inside the command body, letting one command mix plain instructions with these automated steps.

When your agent uses it

  • Adding a new custom command to a code-forge project
  • Deciding how to name and structure a command file
  • Adding an automated lint or test step to an existing command

Example prompts

  • “Create a code-forge command called pr-description that drafts a PR summary.”
  • “Add a check command with a lint tag and a test tag.”
  • “Rename this command file to follow the verb-based naming convention.”

Requirements

  • A code-forge project with a commands directory

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Determine Command Purpose
  2. Choose Command Name
  3. Write the Command File

What it can do on your machine

Read from SKILL.md and the folder at commit 92a5699. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown, bash and yaml).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Code-Forge Command Creator loads about 3.9k tokens when it runs. Until then it costs about 103 tokens; SKILL.md has 1,112 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~103
When it runs · the whole SKILL.md, loaded when a task matches
~3.9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from tailcallhq/forgecode at commit 92a5699, republished under its Apache-2.0 licence (© tailcallhq). 1,112 words, ~3,929 tokens.

Download SKILL.mdSave it as .claude/skills/create-command/SKILL.md (or your agent's skills folder).
name
create-command
description
Create new commands for the code-forge application. Commands are stored as .md files in the <cwd>/.forge/commands directory with YAML frontmatter (name, description) and markdown body containing command steps. Use when users need to add new commands, modify existing commands, or understand the command file structure. Supports special command tags like <lint> and <test> for automated workflows.

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
markdown
---
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:

markdown
---
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
yaml
---
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:

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

For testing commands:

markdown
<test>cargo insta test --accept --unreferenced=delete</test>
<shell> Tag

For general shell commands (not linting or testing):

markdown
<shell>rm -rf target/debug</shell>
Using Tags

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

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

Command Types

Simple Commands

Single-step or instruction-only commands:

markdown
---
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:

markdown
---
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:

markdown
---
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
markdown
---
name: simple-command
description: Does one specific thing
---

Single clear instruction or description.
Automated Workflow Template
markdown
---
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
markdown
---
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
markdown
---
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
markdown
---
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
markdown
---
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
markdown
---
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
markdown
---
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:

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

(Missing closing ---)

Good: Correct:

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

Bad: Missing required field:

markdown
---
name: my-command
---

(Missing description)

Good: Correct:

markdown
---
name: my-command
description: Does something useful
---
Naming Mistakes

Bad: CamelCase name:

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

Good: Correct:

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

Bad: Noun instead of verb:

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

Good: Correct:

markdown
---
name: check
description: Checks something
---
Step Mistakes

Bad: No action verb:

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

- The tests
- The code

Good: Correct:

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

- Run all tests
- Verify code quality

Bad: Vague steps:

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

- Do the deployment
- Make sure it works

Good: Correct:

markdown
---
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
Show full SKILL.md (474 more words)Show less
Tag Mistakes

Bad: Tag on same line:

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

Good: Correct:

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

Bad: Invalid tag:

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

Good: Correct:

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

Bad: Incomplete command:

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

(Missing --all flag)

Good: Correct:

markdown
- 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

    bash
    # 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

    bash
    # 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:

    bash
    # 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

© tailcallhq, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .forge/skills/create-command of tailcallhq/forgecode.

Open the folder on GitHubat commit 92a5699

Compare with similar skills

Code-Forge Command Creator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Code-Forge Command Creator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Code-Forge Command Creator this skilltailcallhq/forgecode7.6k—~3.9kAutomated safety check: PassApache-2.0
Neat-Freak Knowledge CloseoutKKKKhazix/khazix-skills21k—~1.9kAutomated safety check: PassMIT
Dsh Web Documentationzhu1090093659/dsh-web8.4k—~479Automated safety check: PassApache-2.0
Harness Engineering GuideOdradekAI/harness-engineering-guide1251 repos~4.3kAutomated safety check: PassApache-2.0
Agent Setup Health Audittw93/Waza7.2k—~5.2kAutomated safety check: NotesMIT
Agnixagent-sh/agnix444—~874Automated safety check: PassApache-2.0

Similar skills

  • Neat-Freak Knowledge Closeout

    KKKKhazix/khazix-skills

    Brings project docs, agent rule files, authorized memory and leftover workspace files back in line with what the code and runtime actually do at the end of a work session.

    21k GitHub stars~1.9k tokensUpdated 6 days ago
    Agent WorkflowsAuto-check passed
  • Dsh Web Documentation

    zhu1090093659/dsh-web

    A skill your agent uses when adding or editing dsh-web README files, docs, AGENTS.md instructions, user-facing configuration text, or bilingual documentation pairs.

    8.4k GitHub stars~479 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Harness Engineering Guide

    OdradekAI/harness-engineering-guide

    Audit, design, and implement AI agent harnesses for any codebase.

    125 GitHub starsUsed in 1 repo~4.3k tokens
    Agent WorkflowsAuto-check passed
  • Audits a project's agent configuration, instruction drift, hooks, MCP and AI maintainability, then reports prioritized findings with evidence and next actions.

    7.2k GitHub stars~5.2k tokensUpdated today
    Agent WorkflowsAuto-check: notes
  • Agnix

    agent-sh/agnix

    A skill your agent uses when user asks to 'lint agent configs', 'validate skills', 'check CLAUDE.md', 'validate hooks', 'lint MCP'.

    444 GitHub stars~874 tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Setup Matt Pocock Skills

    ywwynm/EverythingDone

    Sets up an Agent skills block in AGENTS.md/CLAUDE.md and docs/agents/ so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc…

    144 GitHub starsUsed in 9 repos~1.7k tokens
    Agent WorkflowsAuto-check passed

More from tailcallhq/forgecode

All 14 skills in this repo
  • Git Merge Conflict Resolver

    tailcallhq/forgecode

    Resolves Git merge conflicts with a plan-first workflow that keeps both sides' intent, regenerates lock files and backs up deleted-but-modified files.

    7.6k GitHub starsUsed in 1 repo~4.5k tokens
    Auto-check passed
  • Forge CLI Debug Workflow

    tailcallhq/forgecode

    Gives a systematic process for debugging the forge CLI: build in debug mode, check the latest help output, test with the non-interactive -p flag, and clone conversations before reproducing bugs.

    7.6k GitHub starsUsed in 1 repo~1.6k tokens
    Auto-check passed
  • FIXME Resolver

    tailcallhq/forgecode

    Finds every FIXME comment in a codebase, groups related ones across files into one task, implements the work they describe and removes the comments once it is done.

    7.6k GitHub stars~1.1k tokensUpdated today
    Auto-check passed
  • Reasoning Serialization Tests

    tailcallhq/forgecode

    Checks that ReasoningConfig fields are serialized into the right provider-specific JSON for OpenRouter, Anthropic, GitHub Copilot and Codex requests.

    7.6k GitHub stars~1k tokensUpdated today
    Auto-check passed
  • Implementation Plan Creator

    tailcallhq/forgecode

    Writes a structured Markdown implementation plan with checkbox tasks, verification criteria and risks, then checks it with a validation script; no code changes.

    7.6k GitHub starsUsed in 1 repo~1.1k tokens
    Auto-check passed
  • Release Notes Writer

    tailcallhq/forgecode

    Pulls a GitHub release and every linked pull request, then writes polished, factual release notes from the combined set of changes.

    7.6k GitHub stars~1.4k tokensUpdated today
    Auto-check passed

Questions about Code-Forge Command Creator

What does Code-Forge Command Creator do?

Creates and structures custom command files for the code-forge CLI, with YAML frontmatter plus special tags for automated lint and test steps. Every command is a single Markdown file placed under the project's forge commands directory, named after the command, and it is the only location forge discovers custom commands from. Each file needs YAML frontmatter with a name and description, plus a body listing the steps to execute in order, written as clear, specific, actionable instructions starting with an action verb.

When should I use Code-Forge Command Creator?

Code-Forge Command Creator fits situations like: adding a new custom command to a code-forge project; deciding how to name and structure a command file; adding an automated lint or test step to an existing command.

How do I install Code-Forge Command Creator in Claude Code?

Run `npx skills add tailcallhq/forgecode --skill create-command -a claude-code`. Or copy the skill folder (.forge/skills/create-command in tailcallhq/forgecode) into .claude/skills/create-command in your project. Claude Code loads it when a task matches its description.

How do I install Code-Forge Command Creator in Codex?

Run `npx skills add tailcallhq/forgecode --skill create-command -a codex`. Or copy the skill folder (.forge/skills/create-command in tailcallhq/forgecode) into .agents/skills/create-command in your project. Codex loads it when a task matches its description.

Can I use Code-Forge Command Creator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add tailcallhq/forgecode --skill create-command -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-command, .gemini/skills/create-command, .github/skills/create-command and .opencode/skills/create-command in your project.

What does Code-Forge Command Creator need to run?

SKILL.md names no scripts, command-line tools or credentials: Code-Forge Command Creator is instructions for the agent only. Our summary lists: A code-forge project with a commands directory.

Does Code-Forge Command Creator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Code-Forge Command Creator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Code-Forge Command Creator use?

Code-Forge Command Creator is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Code-Forge Command Creator use?

About 3.9k tokens (SKILL.md is roughly 16k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Code-Forge Command Creator?

Skills that share tags, products or a category with Code-Forge Command Creator: Neat-Freak Knowledge Closeout (KKKKhazix/khazix-skills, 21k stars), Dsh Web Documentation (zhu1090093659/dsh-web, 8.4k stars), Harness Engineering Guide (OdradekAI/harness-engineering-guide, 125 stars) and Agent Setup Health Audit (tw93/Waza, 7.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Code-Forge Command Creator?

tailcallhq (a GitHub organization) maintains it in tailcallhq/forgecode, which has 7,642 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 7, 2026.

Source: tailcallhq/forgecode on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.