Fix: Skill Tool Summary Showing 'Unknown' Skill Name

Alex Johnson

-Nov 12, 2025

Fix: Skill Tool Summary Showing 'Unknown' Skill Name

Have you ever been frustrated when your skill tool summary stubbornly displays "Unknown" instead of the actual skill name? It's like trying to remember a song when you only know a few of the lyrics. This article dives deep into why this happens and, more importantly, how to fix it, ensuring you can quickly identify which skill was used. Let's get started!

The Problem: "Skill: Unknown" Strikes Again

Current Behavior

Imagine sifting through a list of executed skills, only to be greeted by the unhelpful message:

Skill: Unknown (completed)

This is the reality many users face, and it presents several key problems:

The skill name is conspicuously absent from the summary.
A generic "Unknown" placeholder takes its place, offering zero insight.
You're forced to expand every single skill tool card just to figure out what ran.
Scanning the message list becomes an exercise in futility.

Expected Behavior

Now, envision a world where the skill tool summary actually tells you something useful:

Skill: github-issue-creator (completed)
Skill: codebase-explorer (completed)
Skill: requirement-validator (completed)

Ah, much better! This simple change unlocks a wealth of benefits:

You can immediately identify which skill was used.
Scanning your message history becomes a breeze.
You gain a clear understanding of your workflow at a glance.
The experience becomes consistent with other tool summaries, creating a cohesive user experience.

The Impact: Why Skill Names Matter

User Impact

Let's break down how this issue affects users directly.

Current Experience (Frustrating):

You're left in the dark about which skill was executed.
All skill tools appear identical in the message list, creating a confusing mess.
You have to expand each tool card, wasting precious time and effort.
Reviewing session activity becomes a tedious chore.
You lose context in the conversation flow, making it harder to follow what's happening.

Improved Experience (Empowering):

You instantly see which skill was used, saving time and mental energy.
You can easily differentiate between different skill executions, gaining clarity and control.
Quickly scan skill usage patterns, identifying trends and opportunities for optimization.
Gain a clear understanding of your workflow, leading to more efficient and effective work.

Frequency

This isn't a rare occurrence. Every single skill tool usage is affected:

github-issue-creator (a frequent flyer in many sessions).
codebase-explorer
requirement-validator
implementation-planner
And, of course, all other skills in your arsenal.

Seeing Through the User's Eyes

User Story

Consider this user story:

"As a user reviewing executed skills in the message list, I want to see the skill name in the tool summary, so that I can quickly identify which skill was used."

This simple statement encapsulates the core need driving this fix.

User Journey

Let's map out the user's journey:

A user session involves the execution of multiple skills (think issue-creator, codebase-explorer, and more).
The user scrolls through their message history, seeking to review their actions.
Currently: They're met with a sea of "Skill: Unknown" entries, making differentiation impossible.
Ideally: They see clear, informative summaries like "Skill: github-issue-creator" and "Skill: codebase-explorer."
The user gains a clear understanding of their workflow at a glance, empowering them to make informed decisions.

Real-World Example

Imagine this:

Current (Utterly Useless):

Skill: Unknown (completed)
Skill: Unknown (completed)
Skill: Unknown (completed)

It's a guessing game! Now, compare it to this:

Expected (Incredibly Informative):

Skill: github-issue-creator (completed)
Skill: codebase-explorer (completed)
Skill: requirement-validator (completed)

The difference is night and day. Suddenly, you have a clear understanding of the skills that were executed and their order of execution.

Quality Standards: Ensuring a Solid Fix

Several quality standards must be met to ensure the fix is robust and doesn't introduce new problems.

Backward Compatibility

[x] The fix must not break existing Skill tool functionality.
[x] It should be a pure display enhancement, adding value without disrupting existing workflows.

Data Persistence

[x] No data changes are required, as the skill name is already stored.
[x] The fix should focus solely on displaying existing data correctly.

Performance

[x] The fix should have no noticeable performance impact.
[x] Accessing a simple property should be quick and efficient.

Accessibility

[x] Screen readers should announce the skill name, providing context for visually impaired users.
[x] The fix should improve context for all users, regardless of their abilities.

Acceptance Criteria: Defining "Done"

Definition of Done

To declare this issue resolved, the following criteria must be met:

[ ] The Skill tool summary displays the actual skill name, not just "Unknown."
[ ] The format should be consistent: "Skill: {skill_name} (status)".
[ ] The "Unknown" placeholder should be banished, appearing only when the skill name is genuinely missing.
[ ] The skill name should be extracted reliably from the tool input or parameters.
[ ] The fix should work seamlessly for all available skills.
[ ] A fallback mechanism should be in place, defaulting to "Unknown" only as a last resort.

Summary Format

We're aiming for this target format:

Skill: <skill_name> (<status>)

Here are some concrete examples:

Skill: github-issue-creator (completed)
Skill: codebase-explorer (running)
Skill: requirement-validator (completed)
Skill: implementation-planner (completed)

Skill Name Extraction

Let's peek at the expected tool use data structure:

{
  "type": "tool_use",
  "tool": "Skill",
  "tool_use_id": "skill-123",
  "input": {
    "skill": "github-issue-creator"  // ← Extract this
  }
}

The goal is to extract the skill property from the input object. Here's the basic extraction logic:

// Access skill name from tool input
const skillName = toolUse.input?.skill || 'Unknown';

// Display in summary
summary = `Skill: ${skillName} (${status})`;

Implementation Location

The fix likely resides within a frontend component, such as:

frontend/src/components/messages/tools/SkillToolHandler.vue (if it exists).
A generic tool handler responsible for handling Skill tools.
Or, potentially, frontend/src/components/messages/ToolCallCard.vue.

Here's a glimpse of the suspected current implementation (the culprit!):

<template>
  <div class="skill-tool">
    <div class="tool-header">
      Skill: Unknown ({{ status }})  <!-- Hardcoded or missing extraction -->
    </div>
  </div>
</template>

And here's how we can fix it:

<template>
  <div class="skill-tool">
    <div class="tool-header">
      Skill: {{ skillName }} ({{ status }})
    </div>
  </div>
</template>

<script setup>
import { computed } from 'vue';

const props = defineProps(['toolUse', 'result']);

const skillName = computed(() => {
  return props.toolUse.input?.skill || 'Unknown';
});

const status = computed(() => {
  if (!props.result) return 'running';
  return props.result.success ? 'completed' : 'failed';
});
</script>

Test Scenarios: Putting the Fix to the Test

We need rigorous testing to ensure the fix works as expected.

Scenario: Execute the github-issue-creator skill.
- Given: Skill tool invoked with skill="github-issue-creator".
- When: Tool card displayed.
- Then: Summary shows "Skill: github-issue-creator (completed)".
Scenario: Execute the codebase-explorer skill.
- Given: Skill tool invoked with skill="codebase-explorer".
- When: Tool card displayed.
- Then: Summary shows "Skill: codebase-explorer (completed)".
Scenario: Skill is running (not completed).
- Given: Skill tool is executing.
- When: Tool card displayed before completion.
- Then: Summary shows "Skill: {name} (running)".
Scenario: Multiple skills in the same session.
- Given: Session uses 3 different skills.
- When: User views message list.
- Then: Each skill shows its specific name (not all "Unknown").
Scenario: Skill input is malformed (edge case).
- Given: Skill tool with missing or invalid input.skill.
- When: Tool card displayed.
- Then: Summary shows "Skill: Unknown (completed)" (graceful fallback).
Scenario: Old messages from before the fix.
- Given: Existing session messages with Skill tools.
- When: Messages loaded after fix deployed.
- Then: Skill names display correctly (or fallback to Unknown if data missing).

Root Cause Analysis: Unraveling the Mystery

Possible Causes

Several factors could be contributing to this issue:

The tool handler isn't extracting the skill name, displaying a hardcoded "Unknown" instead.
The code is accessing the wrong property for the skill name.
A recent code change introduced a regression in the tool handler.
The data structure has changed, rendering the extraction logic obsolete.

Investigation Steps

To pinpoint the root cause, we need to:

Inspect the Skill tool handler component (SkillToolHandler.vue or similar).
Examine the tool_use message structure in the browser's DevTools.
Verify that the input.skill property exists and contains the skill name.
Check if other tool summaries are working correctly (e.g., Read, Edit).

Message Structure Verification

Here's what the expected tool use message should look like:

{
  "type": "tool_use",
  "id": "msg-123",
  "tool": "Skill",
  "tool_use_id": "skill-456",
  "input": {
    "skill": "github-issue-creator"
  }
}

If the structure deviates, we need to adjust our extraction logic accordingly. For example:

// Alternative 1: skill as parameter
{
  "input": {
    "command": "github-issue-creator"
  }
}

// Alternative 2: skill in different location
{
  "parameters": {
    "skill": "github-issue-creator"
  }
}

Fallback Handling

Graceful degradation is crucial. Here's a robust fallback mechanism:

function getSkillName(toolUse) {
  // Try primary location
  if (toolUse.input?.skill) {
    return toolUse.input.skill;
  }

  // Try alternative locations
  if (toolUse.input?.command) {
    return toolUse.input.command;
  }

  if (toolUse.parameters?.skill) {
    return toolUse.parameters.skill;
  }

  // Fallback
  return 'Unknown';
}

Similar Tools to Check

Let's ensure consistency across the board. Verify that these tools also display correctly:

Task tool (should show subagent_type or description).
SlashCommand tool (should show the command name).
Other custom tools.

The pattern should be uniform: show a meaningful identifier in the summary.

Edge Cases to Consider

We need to handle various edge cases gracefully:

Skill name is an empty string.
Skill name is null or undefined.
Skill name contains special characters.
Very long skill names (truncate?).
Skill name with spaces (should work).
Case sensitivity (display as-is).
Unknown/unregistered skill names.

Out of Scope (For This Issue)

These enhancements are beyond the scope of this particular fix:

Adding skill descriptions to the summary.
Syntax highlighting skill names.
Skill usage analytics.
Filtering by skill type.
Skill execution history view.

Additional Context: Understanding the Bigger Picture

When This Broke

It's essential to determine when this issue first surfaced. This requires:

Checking the Git history for recent changes to the Skill tool handler.
Investigating whether the Vue 3 migration played a role.
Ascertaining if the skill name has ever been displayed correctly.

Skill Tool Purpose

The Skills system empowers agents with reusable capabilities, accessible via the Skill tool. Displaying the skill name is vital for understanding the flow of a session.

Tool Handler Architecture

The tool handler pattern involves dedicated components for each tool type. These handlers should extract relevant information for the summary display.

Comparison with Other Tools

Other tools are displaying information correctly.

User Confusion

The current "Skill: Unknown" message creates confusion and degrades trust in the system. Users are left wondering what skill ran and whether a bug is to blame.

Implementation Complexity

This fix is relatively straightforward, involving property access, summary display updates, and fallback implementation.

Testing Strategy

Manual testing and browser DevTools inspection are crucial for validating the fix.

Notes

This is likely a simple property access issue. The skill name is already in the data; it just needs to be displayed.

Implementation Details: From Plan to Action

Implementation planning happens after the issue is approved.

Once the issue is approved, these steps will be taken:

Locate the Skill tool handler component.
Inspect the tool_use message structure in DevTools.
Identify the correct property path for the skill name.
Update the summary display to extract and show the skill name.
Add a fallback to "Unknown" for missing data.
Test with multiple different skills.
Verify that old messages display correctly (or fallback gracefully).

By addressing this seemingly small issue, we can significantly improve the user experience and empower users to understand their skill usage patterns more effectively.

For more information on related topics, check out The official Vue.js documentation