Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Goal

ASecurity

Emit one goal statement for current work, capped under 4000 chars. Optional focus hint like /compact. Derives from recent pivots/plan/tasks if no arg. Use for 'what am I trying to do' or seeding a session/subagent.

3 stars
0 votes
0 copies
1 views
Added 9/19/2026
ai-agentsgobashgit

Works with

claude codecli

Security Analysis

A100/100

Scanned 10/4/2026

$npx -y skills add dryvist/claude-code-plugins --skill goal --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Goal?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Goal
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/dryvist-goal/badge)](https://www.skillsdirectory.com/skills/dryvist-goal)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: goal
description: "Emit one goal statement for current work, capped under 4000 chars. Optional focus hint like /compact. Derives from recent pivots/plan/tasks if no arg. Use for 'what am I trying to do' or seeding a session/subagent."
---

# Goal

Emit a single objective statement the reader can act on with no other context.
Print it and stop. This skill produces one artifact and takes no other action.

Run it at any point: mid-task, before a handoff, after a pivot, in a scratch
directory with no repository. It never blocks on state it cannot find.

## Scope

**In:** one goal statement body, under 4000 characters, printed to the user.
Direct invocation wraps it in a `## Goal statement` header (Step 5); the body
itself never contains a heading.

**Out:** file writes, commits, git or `gh` calls, network access, plan edits,
task updates. The single command this skill runs is the `wc -m` measurement in
Step 4, which reads from a heredoc and writes nothing. If you find yourself
running anything else, stop — it is outside this skill's scope.

## Step 1: Determine focus

If an argument was supplied, it **is** the focus. Treat it exactly as
`/compact`'s hint: a steer on what matters, not a full specification. Honor
exclusions in it literally — "ignore the docs work" means no docs criterion,
even if docs work is unfinished.

With no argument, derive focus from these sources, highest weight first:

1. **The most recent pivot.** Where the work changed direction, scope, or
   approach — a correction, a rejected approach, a new constraint. The current
   objective lives after the last pivot, not at the top of the session.
2. **Unfinished plan items.** Resolve the plan file from the most recent
   `## Plan File Info:` block in a `<system-reminder>` — match
   `[^[:space:]]+/\.claude/plans/[^[:space:]]+\.md` and take the latest. Read it
   and collect unchecked `- [ ]` items. No such block means no plan file; skip.
3. **Open tasks.** Call `TaskList`; keep entries whose `status != "completed"`.

Skip any source that is absent. All three absent is normal and fine — derive
the goal from the conversation alone.

Where sources disagree, the conversation wins. A plan file records what was
true when written; the session records what is true now.

## Step 2: Draft the statement

Two parts, in this order.

**Objective and boundary.** One or two sentences naming what must become true,
then an explicit limit so the reader cannot wander. The boundary is what makes
this a goal instead of a wish — write "deploy and document, not redesign", not
"improve the deployment".

**Numbered success criteria, in dependency order.** Each leads with a bolded
noun phrase. Each is a **verifiable condition**: something a reader can check
and get a yes or no. "Error handling is improved" is not checkable; "**Retry
path** — a failed upload retries three times, then surfaces the error" is. See
`karpathy-skills:karpathy-guidelines` for why unverifiable criteria produce
confident wrong work.

The last criterion is always end-to-end verification. Name what gets run and
what output proves it.

Close with one persistence line calibrating how eagerly to proceed: keep working
until every criterion holds, and do not stop to ask when the next action is
unambiguous.

## Step 3: Enforce the rules

Check the draft against every rule before printing.

| Rule | Why |
| --- | --- |
| State end conditions, never steps | Steps go stale; conditions stay true |
| Self-contained — no "continue where you left off", no "as discussed above" | The reader has no memory of this session |
| Absolute paths; full URLs for any PR, issue, or ticket | A bare `#123` is unresolvable cold |
| No secret values, hostnames, or IPs — name where the value lives | The statement gets pasted into other tools and logs |
| Harness-neutral wording | It may be pasted into any agent CLI, not only the one that produced it |
| Never a blockquote — the `>` marker on every line is counted toward the 4000-character cap and pushes the statement over it | The reader pastes the body as plain text, not quoted prose |

## Step 4: Measure the cap

The 4000-character cap comes from Claude Code's goal feature, which is the
statement's most common consumer. Measure it. Never estimate.

The measured text is exactly what gets pasted — no quote markers, no
indentation. Pipe the draft straight into `wc -m` — no file, no temp directory:

```bash
LC_ALL=en_US.UTF-8 wc -m <<'GOAL_EOF'
<the drafted goal statement, verbatim>
GOAL_EOF
```

`-m` counts characters, `-c` counts bytes. The cap is in characters, and these
statements routinely contain em-dashes and other multi-byte characters, so `-c`
over-reports and would trigger a cut the statement did not need.

**The locale prefix is load-bearing.** `wc -m` only counts characters inside a
UTF-8 locale; under `LC_ALL=C` it silently falls back to counting bytes and
becomes identical to `-c`. If `en_US.UTF-8` is unavailable, substitute any UTF-8
locale the system has — `C.UTF-8` is the usual one on Linux. Never drop the
prefix and rely on the ambient locale.

Read the number. Over the cap, cut in this order and re-measure after each cut:

1. Prose inside criteria — keep the condition, drop the explanation.
2. The objective's second sentence.
3. Background or motivation that is not a condition.

Never drop a criterion the work actually needs. If it still will not fit, print
it anyway, state the measured count, and say which criterion is at risk — an
honest over-cap statement beats a silently truncated one.

## Step 5: Print

**The statement is the body only — it never contains a heading.** That is what
makes it embeddable: a caller supplies whatever header its own format needs. Print it
as plain paragraphs, never inside a Markdown blockquote.

Invoked directly, wrap the body in this header so the user sees the count:

```text
## Goal statement (<N> chars)

<the statement body>
```

Invoked by another skill, return **only the body**, preceded by one line
carrying the measurement:

```text
chars: <N>
<the statement body>
```

Callers such as `/session-status` and `/wrap-up` supply their own header and
take `<N>` from that line rather than re-measuring, since this skill owns the count.

Print nothing else — no summary of what you did, no offer to write it somewhere.
Exactly two things may follow, each one line, only when true:

- A source was missing and changed the result.
- The statement is over the cap: name the criterion at risk. (The count is
  already reported, in the header or the `chars:` line.)

## Related Skills

- **handoff** (mattpocock/skills, installed through nix-ai) — user-invoked
  portable Markdown document in the OS temporary directory; no goal-length cap.
- **session-status** (this plugin) — the done-versus-remaining view; use it when
  you want progress, not an objective.
- **karpathy-guidelines** (karpathy-skills) — verifiable success criteria and
  surfacing assumptions.
- **autoresearch:plan** — when the goal needs a measurable metric and an
  automated verify command rather than prose criteria.
- **writing-plans** (superpowers) — when the objective is settled and the next
  artifact is a plan.

Attribution

dryvistdryvist
View sourceSee grades on GitHubMore from dryvist →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698621 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →