As an indie developer who ships apps, I once wrote a skill for checking an app's store text before release. It was a dozen or so lines: the items I wanted looked at every time. Whenever I asked the agent to run it, the answer was polite and reassuring. "I followed the skill and everything looks fine."
Nothing in that reply showed the skill had been read. What I had received was a sentence saying a check happened, not the result of one.
The Antigravity forum has reports that sound very similar. One user on 2.2.1 wrote that neither global nor workspace rules were being followed, and that the agent produced text implying it had used skills or tools when it hadn't. Within days, several others replied that they saw the same thing.
Other replies went the opposite way: maybe the rules were badly written, maybe talking to the agent and explaining the reasons would help. The thread stays split, and I can't tell you which side is right.
What I can say is that you can find out what's happening in your own environment in a few minutes. Here is how I do it.
A reply is not evidence
"I used it" is words. From the text alone, you can't tell whether the skill was loaded or whether a rule was consulted.
The forum reporter made the same point about the verbose chat, saying it displayed tool-use indicators even when nothing was actually used. I can't verify that claim from where I sit. Still, it shows why trusting the text is a risky way to work.
So I pick evidence the agent can only leave by acting: a file appears, a line is appended. That is enough.
Put one marker in a skill and one in a rule
You need two small changes. Add an instruction at the very top of the skill you want to test, telling the agent to write a marker file. Do the same with one line in a rule.
For the skill, it looks like this. Check your version's official docs for where the file goes and how it must be formatted; I'm only showing the contents.
---
name: store-text-check
description: Procedure for checking app store text before release
---
# Do this first, always
1. Append one line to `.canary/skill-used.log` with the current time and this skill's name
2. Then continue with the checklist below
# Checklist
(your real procedure goes here)And the rule:
Before starting any work, append one line with the current time to `.canary/rule-seen.log`.The marker comes before the real work on purpose. Even if the agent stops halfway or skips steps, you can still tell whether the instruction was read at all.
Run it three times and count
Give the same request three times, each in a brand-new conversation. Continuing an old one changes the conditions under which things get loaded.
#!/usr/bin/env bash
# canary_count.sh — count the lines in each marker file.
# Usage: run from the project root: ./canary_count.sh
set -u
count_lines() {
# A missing file counts as 0: its absence is the result
if [ -f "$1" ]; then wc -l < "$1" | tr -d ' '; else echo 0; fi
}
skill=$(count_lines .canary/skill-used.log)
rule=$(count_lines .canary/rule-seen.log)
echo "skill: ${skill} / 3"
echo "rule : ${rule} / 3"Then read the result like this.
| Markers (out of 3) | What it suggests | Next step |
|---|---|---|
| All 3 present | The instruction reaches the agent. The problem may be in how it's written | Shorten it, one action per sentence |
| 1 or 2 present | It arrives some days and not others, possibly depending on conversation length or type | Move the important instruction somewhere that loads every time |
| None present | Placement, naming, or loading conditions prevent it from arriving at all | Compare against the official docs; if that doesn't fix it, report it |
"Three" has no statistical meaning. It's the smallest number I trust for deciding when to stop. One run picks up luck, and ten wears me out before I learn anything.
Rewrite, add a mechanical check, or stop delegating
Once you have the count, there are three moves, in this order.
First, rewrite. If the marker appears but the behavior doesn't follow, suspect the wording. Long paragraphs with several instructions tend to lose one of them. Split them. I wrote about where each kind of instruction belongs in Rules or Skills? How I Re-Decided Where Instructions Live.
Second, hand it to a machine. If an instruction keeps wobbling after rewrites, stop relying on the agent's memory and verify compliance mechanically: a test or lint for forbidden patterns, a hook for before-and-after checks. I covered the idea of backing an advisory skill with a hard gate in The Built-in Guide Skill Is Only Advice — Add a Gate That Rejects Output Mechanically.
Third, stop delegating that task. If you've verified placement, rewritten, and added a gate, and it still wobbles, decide that for now this job doesn't go to the agent.
Fix the wobbles you can fix; for the ones you can't, change who does the work. Deciding this in advance gets you out of the loop of "one more rewrite."
Three things I check before giving up
Before I stop delegating, I always confirm:
- I counted markers across three brand-new conversations
- I compared placement and names against the official docs, character by character
- My own skill isn't colliding with a built-in one
The third is easy to miss. A custom skill that never gets called can come down to a trigger clash with a built-in skill, which I wrote up in The Day My Own Skill Stopped Firing.
Whether the forum's complaint is really a model defect, I can't claim. A marker file at least leaves you with a plain fact: how many times the instruction arrived in your own environment.
As a first step, I'd add one marker line to the skill you trust the most, and look at whether a file appears, rather than at what the reply says.