Claude's /goal Command Can Manage Your AI

There's a version of the AI productivity story that goes like this: you spend weeks carefully building a system of rules, skills, and markdown files to make Claude Code behave exactly how you want—and then you quietly stop maintaining it, because maintaining a system you built to save you time is its own kind of time. The folder rots. Rules start contradicting each other. Half-finished projects pile up like browser tabs you're definitely going to get back to.

Mark Kashef, who runs the Early AI Adopters community and posts regularly about Claude Code workflows, thinks the /goal command is the answer to that particular problem. In a recent video, he walks through five practical ways to point /goal not at some external task, but inward—at the agentic OS itself.

The pitch is recursive in a way that's either elegant or slightly vertiginous, depending on your tolerance for AI-manages-AI architectures: the system audits and improves itself, while you're doing something else entirely.

What /goal Actually Does

Before getting to the use cases, it's worth understanding the mechanism, because it's meaningfully different from just asking Claude to do a task.

You give /goal an objective—up to 4,000 characters—and it runs in a loop. What most people apparently don't know, and what Kashef emphasizes, is that the evaluation isn't self-reported. A second, separate language model acts as judge, checking the primary agent's work against the stated criteria. As Kashef explains it: "every time the agent thinks it's done, it has another agent looking over its shoulders to confirm, has the condition been met?"

That distinction matters more than it might seem. Anyone who's used AI to evaluate AI output has noticed the grade inflation problem—models tend to score their own work generously. The two-model structure at least adds friction to that dynamic, though it doesn't eliminate the underlying question of whether either model shares your actual standards.

The tasks can run anywhere from a few minutes to an hour. Which means the practical use case Kashef is building toward—set it running, go to sleep, come back to a cleaner workspace—is at least technically plausible.

Five Moves, One Idea

Kashef demos five scenarios, and they're worth examining individually because they're not all the same kind of thing.

Clean is the most straightforward. He starts with a hypothetical folder holding 47 skills and 7 rule files. In under three minutes, /goal reduces those to 17 skills (archiving the rest rather than deleting them outright, so nothing is irreversibly lost) and 4 rules, having identified 3 rule contradictions along the way. The speed is the interesting part—this is exactly the kind of audit that's genuinely tedious to do manually and genuinely valuable to have done.

Sharpen introduces a concept worth dwelling on: the rubric. Before running /goal, Kashef creates a separate rubric file defining exactly what "good" looks like for a given skill. Then the goal is to evaluate and rewrite the skill against those criteria. His reasoning: "if you've tested using AI before, usually it will go easier on itself to try to increase the chances that it accomplishes the goal." The rubric is a forcing function—it anchors the evaluation to your standards rather than the model's self-assessed ones. Whether it fully solves that problem or just moves it upstream (now you have to write a good rubric) is a fair question.

Revive is the most humanly relatable scenario. Twenty-two half-built projects, assessed by Claude Code for viability based on existing git commits, tests, and Python functions. The obvious-failures—"dormant hello world projects," as Kashef puts it—get removed. The ones with actual substance get flagged for resurrection. The interesting judgment call here isn't technical; it's whether an AI's assessment of a project's viability aligns with yours. A project can look dead by any measurable signal and still matter to the person who started it.

Forge takes a different angle entirely. Rather than cleaning up what exists, it mines session transcripts—stored as JSONL files in ~/.claude—to identify recurring prompting patterns that haven't been formalized into skills yet. Kashef's demo finds three: a pattern for creating Excalidraw canvas images, one for auditing content, one for generating LinkedIn posts. The insight is that your workflow already contains latent skills you haven't named or saved. /goal can surface them. What it can't do is tell you which ones are worth formalizing versus which ones just happened to recur because you were stuck in a rut.

Maintain is where the architecture gets genuinely interesting, and also where the commitment being asked starts to register. Kashef combines /loop (which repeats a task on a set interval) with /goal to create what amounts to a continuous background audit—every 30 minutes, as long as the terminal session stays open, the system checks whether skills are stale, whether rules still apply, whether anything contradicts anything else. A maintenance log records the findings.

The demo result: one "drifted skill" last used March 31st (45 days prior), flagged automatically. One contradiction identified. "Imagine you have this system running and it keeps looping," Kashef says. "It keeps writing this maintenance log and then you can start analyzing your maintenance log to see how well it's maintaining my infrastructure."

The Meta-Question Under All of This

The frame Kashef uses throughout is "giving the agent a mirror"—the system examines itself. It's a clean metaphor for something that has some genuine strangeness to it.

When an AI audits your workflow and decides which skills to archive, which rules to keep, which projects have merit—those are judgment calls that encode values. The model is making decisions about what's useful, what's redundant, what's worth preserving. In most cases, those judgments will probably align with yours. The rubric approach in the Sharpen demo is an attempt to tighten that alignment explicitly. But the other scenarios don't have rubrics—they rely on the model's implicit sense of what "good" looks like.

That's not a reason to dismiss the workflow. It's a reason to understand it clearly. The maintenance log Kashef mentions is actually the most important part of the architecture: it creates a record of what the system decided, which means you can audit the auditor. You can notice when the AI is archiving things you'd keep, or keeping things you'd drop, and adjust accordingly.

There's also a simpler tension worth naming: the whole value proposition of an agentic OS—a personalized system of skills and rules that reflects how you work—is that it's tuned to you specifically. Delegating the tuning to an autonomous loop is efficient. It's also, in a small but real way, a transfer of authorship. The system that emerges from months of /maintain runs isn't quite the one you designed; it's the one the model iteratively optimized toward its understanding of your goals.

That might be fine. It might even be better. The question is whether you're keeping enough visibility into the process to know the difference.

The strongest version of Kashef's argument isn't "let AI manage your AI workspace so you don't have to think about it." It's closer to: these maintenance tasks are genuinely tedious, they genuinely don't get done, and a system that does them automatically—even imperfectly—is better than a system left to rot. Forty-seven skills you never review aren't serving you. Seventeen curated ones might.

That argument holds up. The interesting work, for anyone actually building this kind of setup, is figuring out how much supervision the supervisor needs.

By Marcus Chen-Ramirez, Senior Technology Correspondent