New to Claude Skills? Learn how to install them →

github on GitHub

Agent Signals

OfficialFree

Structured signals for effective desk communication.

by github37.7k stars on github/awesome-copilot
2 views
Updated Aug 10, 2026
Get this skill

Free · Opens the source repo

What Agent Signals does

Agent Signals is a tool designed to facilitate structured communication between desks and operators in a collaborative environment. By emitting specific signals such as 'hands-up', 'blocked', 'done', 'checkpoint', and 'partnership', this skill allows desks to convey their statuses and needs clearly. These signals are written in JSON format to a designated .signals/ directory, ensuring that they are easily consumable by dashboards and other monitoring tools. Additionally, a journal entry is created for each signal, providing a persistent record of the communication.

The skill is particularly useful in scenarios where multiple desks are working on interdependent tasks. For instance, if one desk encounters a blockage that requires operator intervention, it can emit a 'blocked' signal, prompting immediate attention. Similarly, when significant progress is made, a 'checkpoint' signal can be sent to keep the operator informed without cluttering the communication with routine updates. This structured approach helps maintain clarity and efficiency in team interactions.

Designed for teams that rely on coordinated efforts, Agent Signals enhances the visibility of each desk's status and needs. It is ideal for environments where multiple contributors work on complex projects, ensuring that everyone is aligned and aware of any issues that may arise. The self-assessment feature allows desks to evaluate their performance, providing insights into coordination quality and areas for improvement.

Overall, Agent Signals streamlines communication, reduces ambiguity, and fosters a culture of accountability within teams. By implementing this skill, teams can enhance their operational efficiency and responsiveness, leading to better project outcomes.

When to use it

Use this skill when desks need to communicate their status, require assistance, or report significant progress during collaborative tasks.

When not to use it

This skill is not suitable for simple status updates or routine communications that do not require structured signaling.

What you can build with it

Operator Needs Attention

A desk emits a 'hands-up' signal when it encounters a disagreement that requires operator input.

Reporting Completion

Once a task is finished, a desk sends a 'done' signal to indicate that the work is ready for review.

Noting Progress

During ongoing work, a desk can issue a 'checkpoint' signal to inform the operator of significant progress made.

How to install Agent Signals

View source

1. Install with the skills CLI

npx skills add github/awesome-copilot/signal-write --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 github

Agent Signals

Emit structured signals from a desk to the operator or other desks.

When to use

  • A desk needs operator attention (hands-up, blocked)
  • Work is complete and ready for review (done)
  • Significant progress worth noting (checkpoint)
  • Two desks disagree and can't resolve it (hands-up)
  • The TA is reporting coordination quality (partnership)

Signal types

hands-up

Two desks disagree and can't settle it against external facts. This is the system working — the operator reads where desks disagree, not where they perform confidence.

blocked

A desk can't proceed without input — missing access, ambiguous scope, need a decision only the operator can make.

done

Work is complete and ready for review. Artifacts are on the bench.

checkpoint

Significant progress worth the operator knowing about, but work continues. Not blocked, not done — just a marker.

partnership

Used by the TA (room coordinator) to report coordination quality. Self-assessment scores reflect coordination, not code accuracy:

  • intent — understood what the operator needed
  • confidence — right work went to the right desks
  • accuracy — dispatched work produced the right outcome
  • completeness — nothing fell through the cracks

How to emit

1. Write a JSON signal file to .signals/

This is the primary output — it's what the dashboard reads. Create desks/<desk-name>/.signals/<timestamp>.json:

{
  "signal_type": "execution",
  "subtype": "checkpoint",
  "timestamp": "2026-07-19T21:30:00Z",
  "run_id": "<optional; set to pair this with an outcome signal>",
  "agent_name": "<desk-name>",
  "self_assessment": {
    "intent": 4,
    "confidence": 5,
    "accuracy": 4,
    "completeness": 3
  },
  "patterns": {
    "what_worked": "description of what went well",
    "what_was_hard": "description of challenges",
    "skill_gap": "areas for improvement"
  },
  "escalation": {
    "reason": null,
    "blocked_on": null,
    "recommendation": null
  }
}

Signal type mapping

Signalsignal_typesubtype
hands-up"escalation""hands-up"
blocked"escalation""blocked"
done"execution""done"
checkpoint"execution""checkpoint"
partnership"partnership""partnership"

The subtype field preserves the specific signal state for dashboard consumers. signal_type controls sort priority (escalation → top).

Note: The signals-dashboard canvas extension reads subtype when present and falls back to signal_type for display. If consuming signals in your own tooling, prefer subtype for the specific state.

Ordering: include a timestamp (ISO 8601 UTC). The dashboard orders signals by it and falls back to file mtime only when it's absent — a git clone/checkout resets mtimes, so mtime alone is not a dependable clock.

2. Note the signal in the journal

Also append a short marker to the desk's journal for persistence:

## <date> — [signal:<type>] <summary>
- <key details>

The journal note is the trail marker. The JSON file is the machine-readable signal.

Outcome signals (calibration)

The signals-dashboard can pair a desk's self-assessment with an outcome — an independent rating of the realized result — and show the honesty gap (how far the desk's confidence was from the delivered quality). Outcome signals are optional and are usually emitted by a reviewer/evaluator, not the desk itself.

Write them to the same .signals/ directory:

{
  "signal_type": "outcome",
  "run_id": "<same run_id as the signal it rates>",
  "agent_name": "<reviewer name>",
  "quality_rating": 4,
  "effort_to_merge": "minimal",
  "issues_found": ["optional short strings"],
  "timestamp": "2026-07-19T22:00:00Z"
}
  • run_id correlates an outcome with the execution/partnership signal it rates — set the same run_id on both. If it's absent, the dashboard falls back to the nearest outcome emitted shortly after the latest signal.
  • quality_rating (0–5) is the realized quality; the dashboard compares it to the desk's self-assessed confidence to compute the honesty gap.
  • effort_to_merge"minimal", "moderate", or "significant".
  • issues_found — optional array of short strings.

Principles

  • Signals are structured, not chatty. Short, factual, actionable.
  • hands-up is not failure — it's the most valuable signal. It means the system caught something one frame alone would have missed.
  • Don't signal for routine progress. Signals are for state changes that affect the room, not status updates.
  • blocked means truly blocked — not "I'd prefer input." If you can proceed with a reasonable default, proceed and note it.
  • Self-assessment scores should be honest, not optimistic. A 3/5 is fine. A 5/5 on everything is suspicious.

Frequently asked questions about Agent Signals

Similar skills