agentleFS
Sign inStart free
stardustaistardustai/stardust-skills/skills/ceo-feedback-processing/SKILL.md

ceo-feedback-processing

Skill0 starsChanged 2 months agoMITView on GitHub

Use when an Agent is asked to diagnose and repair repository feedback recorded in the local feedback queue. The Skill owns the repository workflow and evidence receipt; the service owns persistence and state transitions.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use persisted feedback_key as the stable identity.

    line 11
  2. Distinctive:

    Use the brainstorming skill in every processing conversation.

    line 31
  3. Distinctive:

    Use supplied task, attempt, run, persisted summaries, and references.

    line 33
  4. Very specific:

    Add a regression test; run focused tests and relevant broad tests.

    line 36
  5. Distinctive:

    Read batch detail back before editing.

    line 40
  6. Very specific:

    Every feedback-processing resolution requires restarting com.ceo-agent-service.main.

    line 55

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

CEO Feedback Processing

Use persisted feedback_key as the stable identity. Confirm the repository root, current branch, and current HEAD; preserve uncommitted user changes. The Console API is local-only with no auth at http://127.0.0.1:8765/api/console/feedback. Import formatting never calls a model. No new UI workflow or service_bugfix route is allowed. Direct SQLite writes are forbidden.

Exact operations

PurposeOperation
pending/detailGET /api/console/feedback; GET /api/console/feedback/{feedback_key}
claim/detailPOST /api/console/feedback/batches; GET /api/console/feedback/batches/{batch_id}
associatePATCH /api/console/feedback/batches/{batch_id}
evidencePATCH /api/console/feedback/items/{feedback_key}
reopenPOST /api/console/feedback/items/{feedback_key}/reopen
resolvePOST /api/console/feedback/batches/{batch_id}/resolve

Repository workflow

  1. Use the brainstorming skill in every processing conversation. Read the pending batch and detail for every selected item before claiming the batch. Use supplied task, attempt, run, persisted summaries, and references; never invent IDs.
  2. reproduce before editing. Capture the exact command, failure, and references. Add a regression test; run focused tests and relevant broad tests. Record each command, exit_code=0, run time, and brief output.
  3. Claim only requested keys. Associate the supplied Workbench task using workbench_task_id, workbench_turn_id, attempt_id, and agent_run_id. Read batch detail back before editing.
  4. Make the smallest repair and git commit. Verify git rev-parse HEAD matches the committed SHA before recording evidence.

Reopen and current-round rules

Reopen with exactly {"reason":"<factual reason>"}. It returns to pending and creates no round. Read back pending, then claim a new batch; claim creates the new processing round. Never copy or reuse old evidence, green receipts, or Workbench associations. An existing commit cannot replace fresh current-round code, test, commit, restart, backlog, and readback evidence. Only the current round receipt may resolve the item.

Evidence and resolution

Every feedback-processing resolution requires restarting com.ceo-agent-service.main. Verify launchctl print, a new before/after PID, /healthz, and authoritative zero processing, failed, and retryable failed/processing backlog. Deadlines never waive broad tests or these gates.

Persist per-item evidence through the API: commit SHA, focused/broad tests, restart evidence, health evidence, associations, and concise note. Read item and batch back before marking the item resolved. Resolve only after all items complete. Evidence-free resolve is forbidden; incomplete evidence or any failure or interruption leaves the item processing in the same batch and Workbench task.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free