Claude Code Skills: Parameters and Context Injection

Abstract

Claude Code Skill is a core native automation capability built into Anthropic’s development IDE, designed to encapsulate repeatable engineering workflows as reusable task templates. Its core runtime logic relies on two pre-model processing pipelines: context pre-injection for automatic background data loading, and dynamic parameter passing to accept temporary user input. All data resolution, command execution, file reading and placeholder replacement run entirely within the harness layer before any prompt is delivered to the LLM. The model only receives fully rendered, static text payloads with no awareness of original template placeholders. This article systematically breaks down the three-tier progressive disclosure architecture of context pre-injection, full parameter placeholder syntax, end-to-end invocation lifecycle, frontmatter permission controls and field best practices. Teams orchestrating unified multi-model development traffic can adopt 4sapi to standardise routing for Claude Code and other code-focused LLMs.

1. Core Mental Model: Skill as a Pre-Filled Task Template

All dynamic logic within a Claude Skill executes inside the runtime harness, prior to inference. The LLM never accesses raw template source; it only consumes fully resolved, complete context text. Visualise each Skill as a pre-written task memo with two distinct types of blank slots:

1. Parameter slots: Populated by temporary input provided at invocation time (e.g., bug ID numbers for a fix task). This mechanism is formalised as parameter passing.
2. Context injection slots: Auto-populated by the harness via active environment queries (e.g., current Git branch name). This pipeline is defined as context pre-injection.

All resolution work completes upstream of the model. The core workflow rule governs all subsequent technical details: the LLM receives only final rendered text and cannot trace back placeholder logic in the source Skill file.

2. Context Pre-Injection: Progressive Disclosure Tiered Loading

Context pre-injection adopts a three-stage layered loading strategy to balance two critical requirements: making the model aware of available Skill definitions, while avoiding excessive context bloat that consumes token windows unnecessarily.

2.1 Three-Tier Progressive Disclosure Architecture

The L1 metadata tier forms the critical pre-injection foundation. Every installed Skill registers its name and descriptive summary into the system prompt at chat initialisation; this metadata acts as the sole signal the model uses to judge whether automatic Skill invocation matches user intent.

Anthropic’s official specifications mandate strict formatting rules for description fields: write descriptions in third-person voice with explicit trigger phrases.

# High-quality example (model reliably identifies invocation triggers)
description: This skill should be used when the user asks to "create a hook", "add a PreTool use hook", or mentions hook events.

# Low-quality example (rarely auto-triggered by the model)
description: Provides guidance for working with hooks.

Vague, generic descriptions cause the Skill to remain dormant even for matching user requests, a common pitfall for new Skill developers.

2.2 Three Dynamic Data Sources for Context Pre-Injection

When a Skill activates and its L2 body loads, three placeholder syntaxes trigger real-time environment resolution before text is passed to the model:

① ! Command Execution Inline Injection

Inline bash commands pre-execute inside the harness, with raw standard output embedded directly into the template text.

## Current State
- Branch: `! git branch --show-current`
- Changes: `! git status --short`

Instead of the raw command string, the model receives resolved output such as - Branch: main. This is the literal implementation of pre-injection: commands run fully before model input is constructed. Frontmatter must include allowed-tools: Bash(git:*) to whitelist permitted shell utilities for command placeholders.

② @ File Content Injection

The @ syntax reads full text from specified local files and embeds their contents into context. It supports combined parameter syntax @$1 to dynamically reference file paths passed during invocation. Sample usage:

Review @src/api/users.ts for potential edge-case bugs.

③ ${CLAUDE_PLUGIN_ROOT} Portable Plugin Path Variable

Reserved exclusively for plugin-style Skills, this variable auto-expands to the absolute root directory of the active plugin bundle. It eliminates hardcoded absolute paths when referencing internal plugin scripts and templates:

Run: `! node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js`

3. Runtime Parameter Passing: Accept Temporary Invocation Input

3.1 Dual Invocation Entry Points, Unified Parameter Syntax

Claude Skills support two invocation modes that share identical placeholder resolution logic:

1. Explicit user invocation: Manual slash commands sent directly in chat (/skill-name arg1 arg2)
2. Automatic model invocation: The LLM matches user intent against L1 metadata and triggers the Skill with inferred parameters

A key implementation detail: legacy /.claude/commands/*.md and modern /.claude/skills/<name>/SKILL.md files utilise identical runtime resolution pipelines; only directory structure differs, so all placeholder syntax works cross-compatibly.

3.2 Three Standard Parameter Placeholder Types

1. $ARGUMENTS: Capture all input as a single concatenated string

# Template line
Fix issue $ARGUMENTS following internal coding standards.
# Invocation input: /fix-issue 123
# Resolved output: Fix issue #123 following internal coding standards.

2. Positional Indexed Placeholders $1, $2, $3

Map sequentially passed arguments to discrete template positions:

# Template line
Review PR #$1 with priority $2, then assign task to $3.
# Invocation input: /review-pr 123 high alice
# Resolved output: Review PR #123 with priority high, then assign task to alice.

3. Mixed positional + remainder capture

Map fixed leading positions and bundle all trailing arguments into a single variable slot:

# Template line
Deploy $1 to $2 with options: $3
# Invocation input: /deploy api staging --force --skip-tests
# Resolved output: Deploy api to staging with options: --force --skip-tests

3.3 Fallback Rule for Undeclared Parameters

If the SKILL.md template contains no explicit parameter placeholders, the harness appends all input arguments to the end of the rendered context block in the format ARGUMENTS: <raw input string>. Parameters are never discarded; the only difference is targeted inline insertion versus automatic trailing attachment for unmarked templates.

3.4 argument-hint: Pure Documentation Metadata

The argument-hint field in frontmatter only populates auto-completion hints and /help documentation output; it does not participate in runtime text substitution. All live parameter resolution relies entirely on $ARGUMENTS and indexed $N placeholders.

argument-hint: [pr-number] [priority] [assignee]

4. End-to-End Invocation Lifecycle: Full Execution Sequence

All parameter substitution, command resolution and file reading execute sequentially inside the harness before any text is sent to the model, using the official pr-check Skill as a demonstration case:

1. User submits invocation command /pr-check with attached arguments
2. Harness expands all parameter placeholders ($ARGUMENTS, $1, positional slots)
3. All inline ! shell commands execute, standard output is embedded into template text
4. @ file references and ${CLAUDE_PLUGIN_ROOT} paths resolve to static text content
5. A single complete block of fully rendered static text is generated
6. Resolved context payload is injected into a isolated sub-agent session defined by context: fork
7. The LLM receives only the final static text, with no visibility of original template syntax or placeholders

An alternative lightweight Skill design omits explicit parameter placeholders entirely. Instead of accepting pre-passed arguments, inline shell commands such as git status and git diff pull live environment state during pre-injection, letting the model dynamically assemble commit messages from real-time workspace data. This pattern demonstrates parameter passing is not mandatory; self-contained context injection workflows often deliver greater flexibility for dynamic engineering tasks.

5. Frontmatter Reference: Core Control Switches

The YAML frontmatter at the head of every SKILL.md governs invocation permissions, tool whitelisting and isolation rules:

Invocation Permission Matrix

6. Five Production-Grade Implementation Best Practices

1. Optimise L1 trigger descriptions: Write third-person explicit trigger phrases for reliable auto-invocation. Vague summary descriptions result in dormant Skills the model fails to activate.
2. Placeholder resolution is one-time static rendering: Inline ! command output is frozen at invocation time; dynamic workspace changes mid-conversation will not refresh data until the Skill re-runs.
3. $ARGUMENTS performs raw text insertion with zero validation logic: Implement filtering and regex validation inline via shell commands (! echo "$1" | grep -E ...) if input sanitisation is required.
4. Avoid oversized L2 main body content: Excessively long core templates degrade context efficiency and inflate token consumption per trigger; offload static reference data to L3 external asset files loaded on-demand.
5. Adopt the modern /.claude/skills/ directory layout over legacy commands/ folders: The skills structure fully supports three-tier progressive disclosure via separated references/, scripts/ and asset directories, unlocking the full layered context pre-injection capability.

Conclusion

The strength of Claude Code Skills stems from its pre-model layered processing pipeline, separating dynamic data resolution entirely from LLM inference. Two core subsystems deliver its automation power:

1. Context pre-injection (three-tier progressive disclosure): Auto-load static metadata at session start, inject core workflow logic on trigger, and pull external assets on-demand via !, @ and plugin root path variables.
2. Runtime parameter passing: Three placeholder syntaxes accept temporary user input, with a built-in fallback mechanism to guarantee no invocation arguments are lost.

Every blank slot defined in a Skill template resolves completely within the harness before the model receives input. Distinguishing between auto-queried environment context and user-supplied temporary parameters enables engineers to design low-token, reliable automation workflows tailored to daily software development tasks. Mastery of frontmatter permission controls and tiered context loading eliminates common pitfalls such as failed auto-triggering, excessive context bloat and unregulated destructive shell execution.