Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add AlexZio00/sovereign-skills --skill goal-lockgit clone --depth 1 https://github.com/AlexZio00/sovereign-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/alexzio00/sovereign-skills/goal-lock)<a href="https://agentmods.dev/skills/alexzio00/sovereign-skills/goal-lock"><img src="https://agentmods.dev/badge/skills/alexzio00/sovereign-skills/goal-lock/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/alexzio00/sovereign-skills/goal-lock"><img src="https://agentmods.dev/badge/skills/alexzio00/sovereign-skills/goal-lock.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 9 findings, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 538 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 166 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium MCP Rug Pull · line 339 npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.Fix: Pin the version: npx @scope/[email protected]
- medium MCP Rug Pull · line 340 npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.Fix: Pin the version: npx @scope/[email protected]
- medium Excessive Agency · line 353 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 475 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 494 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Excessive Agency · line 515 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
- medium Memory Poisoning · line 606 Skill attempts to fill the context window with filler content, displacing legitimate instructions and safety constraints. This can degrade agent performance or bypass safety boundaries.Fix: Implement context-window management that detects and rejects padding or stuffing attempts. Prioritize system instructions over user-injected content.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00049 | $0.07906 |
| Opus 5 | $0.00024 | $0.03953 |
| Sonnet 5 | $0.00010 | $0.01581 |
| Haiku 4.5 | $0.00005 | $0.00791 |
Grade A, and why
goal-lock scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
e.g.: `curl localhost:3000/api/health` → 200 OK How it starts
The opening of the file, as written. The whole thing — 641 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/goal-lock — Agent Discipline Engine v1.0
Lock the goal. Run the loop. Ship clean.
Prevents agents from drifting off target, masquerading success, or creeping scope. Quality through enforced loops, not prompt obedience.
Dominant Variable
Is DONE EVIDENCE verified by actual execution? — What the agent says is done vs what is actually done. Closing this gap to zero is the purpose of this skill.
Trigger
/goal-lock/goal-lock quick(Quick mode)- "goal lock"
- "task harness"
Discard If
- Simple question/conversation (no code changes)
- goal-lock already active in this session
- Single-file 1-line fix — goal-lock overhead > the work itself
Architecture: 2 Layers
[A] GOAL Input Sheet — fill per task (goal definition)
[B] Fixed Loop — same for every task (execution discipline)
Missing/contradictory input → STOP. Conflicts → PRIORITY. STOP RULES → halt.
Mode Selection
| Mode | Condition | Input Sheet | Loop |
|---|---|---|---|
| Quick | 1 file, clear change, ≤10 lines | 3 fields (GOAL/DONE/SCOPE) | DO→VERIFY only |
| Full | Everything else | All 7 fields | B1~B5 full |
User specifies /goal-lock quick, or change fits Quick criteria. When unsure, use Full.
[A] GOAL Input Sheet
Full Mode (7 fields)
## GOAL Input Sheet
### 1. GOAL
[Single measurable goal. No expansion.]
### 2. DONE EVIDENCE
[Completion proof. The evidence contract branches by artifact type —
don't force one shape onto both:]
- **Code artifact** → command to run + expected result. No subjective
criteria.
e.g.: `pytest tests/test_X.py -v` → 5 passed
e.g.: `curl localhost:3000/api/health` → 200 OK
- **Non-code artifact** (writing, analysis, reports, designs, prompts, spec
docs) → no exit code exists to demand. State the review contract instead:
what a reviewer checks off, or what a named approver signs off on (e.g.
"reviewer confirms the 3 required sections are present and each claim
cites a source" or "user approves the draft"). This feeds directly into
the REFINE loop below (VERIFY/REFINE split) rather than VERIFY's execution
path.
**Adversarial criteria design**: when setting DONE EVIDENCE, ask first "how
could an agent game this criterion." An unblocked loophole tends to get
found eventually — threshold relaxation, mock wrapping, hardcoding all
exploit a DONE EVIDENCE that was underspecified to begin with. Check for
loopholes at design time, especially on long-running or repeated tasks.
**Evidence-Rigor Pre-spec** [borrowed from ultraprompt]: when DONE EVIDENCE
includes concurrency, benchmark, p99-style statistics, or long-running-process
claims, pre-check the verification agent's evidence-rigor rules (N≥5 repeats,
before/after symmetry, evidence-scope matching, flaky-means-new-bug,
positive-signal-required) and write DONE EVIDENCE to already satisfy them —
this prevents a later insufficient-evidence rejection at the verify step by
fixing the design at spec time instead.
### 3. CONTEXT
[Current state · existing structure · prior decisions · dependencies · known constraints]
### 4. STARTING POINT
[Files/logs/tests to look at first. Start here, no broad exploration.]
### 5. SCOPE
- **Include**: [Editable area + required work]
- **Exclude**: [Out of bounds · unrelated refactors · new features · production behavior changes]
- **Capability-spillover (flag, don't fix)**: other bugs, design/structural
improvement ideas, or similar edge cases noticed mid-task all stay in
Exclude. Report them separately (one inline line, or a follow-up task)
and return to the current GOAL. Stronger models trend toward "fixing it
all while I'm in here" — scope is a lock, not a ceiling.
### 6. CONSTRAINTS
- New dependencies: allow/forbid
- Network/API calls: allow/forbid
- Commit/PR/push: allow/forbid
- Migration/DB changes: allow/forbid
- Destructive actions: allow/forbid
### 7. BUDGET
[Time/token/call/cost limits. Follow if given, don't invent if not.]
### 8. EVAL TYPE (optional — only for tasks measuring a skill/hook/gate's own reliability)
[yes — this GOAL measures whether the verification logic itself actually works]
[no or omit — regular implementation. Normal DO→VERIFY iteration is allowed]
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago Changed · +83 lines 4b2220a17ba7
- 13d ago First seen · 558 lines · 49 tokens per session scan A 6e8336a05b86
goal-lock is a skill published in the GitHub repository AlexZio00/sovereign-skills (129 stars, last pushed 5d ago), licensed MIT. It adds 49 tokens to every session and 7,906 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
nobrainer-review
Use when the owner says nb-review, deep-audit, deep-code-review, or deep-autoreview; explicitly requests an evidence-gated CLOSEOUT, adversarial BUGHUNT or RELEASEGATE; or needs final findings filtered to verified actionable defects. Use nobrainer-build for ordinary implementation and correction work.
sdd-tasks
Break an SDD change into implementation tasks. Trigger: orchestrator launches task planning for a change.
review-work
Post-implementation gate review: run manual QA on the real surface yourself, then launch ONE gate reviewer (never a panel) to audit goal, constraints, code quality, security, missed context, and QA evidence. Use before a PR handoff or when the user explicitly asks to review completed work.
ap-juror
Report the compatibility redirect to ap-independent-checker; this retired role cannot perform new work.
ijfw-cross-audit
Generate a cross-platform multi-model audit (Trident) on a diff, brief, or artifact. Trigger: 'cross audit', 'Trident', 'second opinion', 'check with other models', 'check with other AIs', 'cross-check this', 'get another perspective', /cross-audit.
doubt-driven-development
Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now…