agentleFS
mysticaltechmysticaltech/goal-creator-skill/goal-creator/SKILL.md

goal-creator

Skill3 starsChanged 5 months agoMITView on GitHub

Compile plain-language work into concise, host-aware, verifiable agent goals. Use when drafting, rewriting, tightening, auditing, or deciding whether to use a /goal-style contract for Codex, Claude Code, Cursor, OpenClaw, GitHub Copilot, orchestrators, CI agents, background workers, coding agents, review agents, research agents, migrations, debugging, refactors, audits, long-running tasks, or any multi-step work that needs explicit done criteria, proof, stop policy, anti-gaming constraints, review depth, and a completion receipt.

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. zebbern/skills★ 29same name
    2. zebbern/pocmap★ 7same name
    3. yinsang0910-star/goal-creator★ 1same name
    4. YogirajA/Claude-Skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

The file

Show its rules and text

We split this skill into the rules it gives an agent

18 rules. 0 are common, 16 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 16

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default to a normal prompt instead of a goal when the task is one-shot, explanatory, trivial, or lacks a durable proof surface.

    line 12
  2. Very specific:

    Run the checklist below. Use scripts/goal-lint.mjs when a draft is non-trivial, user-facing, or has a hard length budget.

    line 28
  3. Distinctive:

    Stop: When should the run stop as blocked instead of thrashing?

    line 60
  4. Distinctive:

    If a missing answer could change product semantics, architecture, migration behavior, security, data safety, permissions, cost, or …

    line 63
  5. Distinctive:

    Read-only research, docs, small content edits, local cleanup.

    line 68
  6. Distinctive:

    If a review finds a medium-or-above issue, fix it and restart the clean-review count.

    line 79
  7. Distinctive:

    Add explicit "Do not" clauses when the agent could satisfy the metric while violating intent:

    line 83
  8. Distinctive:

    Do not delete, skip, weaken, or rewrite tests just to pass.

    line 85
  9. Distinctive:

    Do not hide failures behind mocks when real integration proof is required.

    line 86
  10. Distinctive:

    Do not disable production build paths, flags, or safety checks to improve a metric.

    line 87
  11. Distinctive:

    Do not crop/embed a reference image to claim visual fidelity.

    line 88
  12. Distinctive:

    Do not declare success without exact validation output.

    line 89
  13. Distinctive:

    Do not broaden scope to make an easier unrelated improvement.

    line 90
  14. Distinctive:

    Do not mutate live data, secrets, permissions, billing, or external systems unless the user explicitly authorized it.

    line 91
  15. Very specific:

    Read references/host-profiles.md when host behavior matters.

    line 95
  16. Distinctive:

    When a goal is appropriate:

    line 113
  17. Distinctive:

    When a goal is not appropriate:

    line 129
  18. Distinctive:

    Keep the answer concise. The user came for the goal, not a lecture about goals.

    line 139

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “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

Goal Creator

Operating Mode

Act as a goal compiler, not a prompt decorator. Convert the user's real objective into the shortest durable execution contract that makes success checkable and fake completion difficult.

Default to a normal prompt instead of a goal when the task is one-shot, explanatory, trivial, or lacks a durable proof surface.

Fast Path

  1. Extract the real objective. Ignore mentions of this skill.
  2. Identify the host: Codex, Claude Code, Cursor, OpenClaw, orchestrator, CI/background worker, or generic agent. If unspecified, write a portable goal and mention host assumptions only when they affect behavior.
  3. Decide whether a goal is appropriate.
  4. Compile the goal with:
    • one primary end state
    • transcript-visible proof
    • allowed scope, context, tools, and environment
    • constraints and forbidden shortcuts
    • operating loop
    • verification and review depth
    • stop policy
    • completion receipt
  5. Run the checklist below. Use scripts/goal-lint.mjs when a draft is non-trivial, user-facing, or has a hard length budget.
  6. Return the ready-to-use goal plus only the assumptions and compiler notes that matter.

Contract Shape

Prefer this structure:

/goal Definition of done: <one durable end state>, verified by <specific transcript-visible proof>, while preserving <non-negotiable constraints> and staying within <scope>.

Operating instructions: use <allowed context/tools/files/environments>; first inspect <source-of-truth inputs>; after each failure or partial result, update the hypothesis and make the smallest defensible next move. Maintain <progress artifact or checkpoint cadence if long-running>. Do not <forbidden shortcuts>.

Verification: run <focused checks> before <broad checks>; require <review tier>; independent verifier/reviewer must confirm <critical proof> when risk warrants it.

Stop if <blocked condition, unsafe ambiguity, missing credential, no defensible path, or budget bound>; report attempted paths, evidence gathered, blocker, unresolved findings, and next input needed.

Completion receipt: print changed files/artifacts, exact validation commands and exits, review result, proof links/logs, and remaining risks.

For hosts with strict character budgets, compress to one paragraph while preserving done, proof, constraints, verification, stop policy, and receipt.

Decision Checklist

A draft is not done until these are clear:

  • End state: What is true when work is complete?
  • Proof: What exact output, command, artifact, citation, screenshot, log, or review result proves it?
  • Scope: What repos, files, services, data, tools, branches, worktrees, and environments are allowed?
  • Constraints: What must not regress, mutate, leak, delete, or be faked?
  • Context: What specs, docs, issues, plans, logs, or prior decisions must be referenced instead of buried in the goal?
  • Loop: How should the agent choose the next move after failures or partial progress?
  • Review: What risk tier and review loop protect the objective?
  • Stop: When should the run stop as blocked instead of thrashing?
  • Receipt: What must be printed before completion?

If a missing answer could change product semantics, architecture, migration behavior, security, data safety, permissions, cost, or long-term maintainability, ask targeted questions before compiling.

Risk Tiers

Low:

  • Read-only research, docs, small content edits, local cleanup.
  • Require one self-review or adversarial review and resolve medium-or-above findings.

Medium:

  • Normal code changes, refactors, tests, generated artifacts, or docs that describe behavior.
  • Require focused verification plus one adversarial review.
  • Resolve all medium/high/critical findings.

High:

  • Public APIs, migrations, security, auth, permissions, data loss, release/publish flows, activation, packaging, command behavior, broad cross-file behavior, or production-affecting changes.
  • Require two consecutive clean adversarial reviews with no medium-or-above findings.
  • If a review finds a medium-or-above issue, fix it and restart the clean-review count.

Anti-Gaming Defaults

Add explicit "Do not" clauses when the agent could satisfy the metric while violating intent:

  • Do not delete, skip, weaken, or rewrite tests just to pass.
  • Do not hide failures behind mocks when real integration proof is required.
  • Do not disable production build paths, flags, or safety checks to improve a metric.
  • Do not crop/embed a reference image to claim visual fidelity.
  • Do not declare success without exact validation output.
  • Do not broaden scope to make an easier unrelated improvement.
  • Do not mutate live data, secrets, permissions, billing, or external systems unless the user explicitly authorized it.

Host Notes

Read references/host-profiles.md when host behavior matters.

Use these defaults:

  • Codex: durable objective, validation loop, checkpoint evidence, scope boundary, blocked behavior, final receipt.
  • Claude Code: completion evaluator needs proof in transcript; keep the condition compact and under the host limit.
  • Generic agents: write as an acceptance contract with proof and stop policy; avoid host-specific commands.
  • Orchestrators: separate builder, reviewer, verifier, handoff, queue state, worktree/branch boundaries, and final independent verification.

Resources

  • scripts/goal-lint.mjs: deterministic draft checker for structure, length, vague language, missing proof, missing stop policy, and missing receipt.
  • references/goal-contract-model.md: deeper model, anti-gaming patterns, long-running goals, and task-specific contract guidance.
  • references/host-profiles.md: host-specific goal semantics.
  • references/example-goals.md: compact examples for common task types.

Output Format

When a goal is appropriate:

Recommended Goal:
<ready-to-use /goal block>

Assumptions:
<only material assumptions, or omit>

Compiler Notes:
- Host: <host/profile>
- Proof: <main proof surface>
- Review: <risk tier>
- Stop: <main bound>

When a goal is not appropriate:

Better As A Prompt:
<concise normal prompt>

Why Not A Goal:
<one sentence naming the missing durable objective or proof surface>

Keep the answer concise. The user came for the goal, not a lecture about goals.

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.