cover-agent
Skill1 starsChanged 49 days agoMITView on GitHub
Temporarily act as a Cover Agent for Agent HQ tasks by spawning a subagent in the current thread that impersonates the assigned Agent HQ role, validates or finishes review-stage work, and prepares truthful review evidence for the ticket. Use when you need Atlas to stand in for an Agent HQ agent in-chat, especially to review implementation work, gather evidence, or post review-ready findings into the task without pretending QA passed.
In this repository7 other files it gives its agents.
- atlas-agent-hq-adminSkill
- create-agentSkill
- create-projectSkill
- create-taskSkill
- create-toolSkill
- task-routing-rulesSkill
- workflow-definitionsSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Use this skill when the operator wants Atlas to temporarily stand in for an Agent HQ agent inside the current thread.
- Distinctive: line 13
Only impersonate the agent's role and workflow responsibility, not fabricated personal work that did not happen.
- Distinctive: line 14
Do not invent artifacts, branches, commits, screenshots, URLs, approvals, or QA results.
- Distinctive: line 15
Do not manually set QA outcomes.
- Distinctive: line 16
Prefer using a spawned subagent to do the actual inspection or verification work, then convert its result into truthful ticket evidence.
- Distinctive: line 17
If required task evidence is missing, say that plainly and stop short of posting a false review handoff.
- Distinctive: line 36
Only move the ticket forward if the required evidence fields actually exist and the lane transition is allowed.
- Distinctive: line 40
When posting review evidence, include only facts you can support directly:
- Distinctive: line 48
If one of those is missing, call it out instead of smoothing over it.
- Distinctive: line 65
When this skill is used, prefer concise evidence-first updates:
- Very specific: line 75
Read references/evidence-template.md when you need a compact template for truthful review evidence notes.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Cover Agent
Use this skill when the operator wants Atlas to temporarily stand in for an Agent HQ agent inside the current thread.
Core rules
- Act as a covering operator, not a faker. Keep evidence truthful.
- Only impersonate the agent's role and workflow responsibility, not fabricated personal work that did not happen.
- Do not invent artifacts, branches, commits, screenshots, URLs, approvals, or QA results.
- Do not manually set QA outcomes.
- Prefer using a spawned subagent to do the actual inspection or verification work, then convert its result into truthful ticket evidence.
- If required task evidence is missing, say that plainly and stop short of posting a false review handoff.
Default workflow
- Identify the Agent HQ task, assigned role, and what lane the task is currently in.
- Inspect the current evidence already attached to the task.
- Spawn a subagent in this thread that matches the needed role:
- dev/backend/frontend/fullstack for implementation review or finish work
- QA for verification
- PM/spec for acceptance against task intent
- Have the subagent work from the canonical repo and exact branch/commit when available.
- Require a structured result back:
- verdict
- what was checked
- commands run
- files touched if any
- branch + commit if relevant
- concrete risks/blockers
- Convert that into truthful review evidence or a truthful blocker note for the Agent HQ ticket.
- Only move the ticket forward if the required evidence fields actually exist and the lane transition is allowed.
Evidence standard
When posting review evidence, include only facts you can support directly:
- branch name
- full commit SHA
- exact verification commands
- exact verdict
- specific blocker if not ready
If one of those is missing, call it out instead of smoothing over it.
Good uses
- Cover an unavailable backend agent long enough to inspect a completed branch and post review-ready evidence.
- Cover a QA agent by running verification in-thread and summarizing the result for the ticket.
- Cover a PM/spec agent by checking implementation against acceptance criteria and writing a precise pass/fail note.
Bad uses
- Fabricating review evidence for work that was never run
- Marking QA passed without real verification
- Pretending an Agent HQ agent completed work when Atlas or an ad hoc subagent actually did it
- Advancing a task when the required branch, commit, or test proof is missing
Output shape
When this skill is used, prefer concise evidence-first updates:
- role covered
- task id
- verdict
- evidence
- blocker or next move
References
- Read
references/evidence-template.mdwhen you need a compact template for truthful review evidence notes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.