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 synaptiai/synapti-marketplace --skill goal-lifecyclegit clone --depth 1 https://github.com/synaptiai/synapti-marketplaceWrote 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/synaptiai/synapti-marketplace/goal-lifecycle)<a href="https://agentmods.dev/skills/synaptiai/synapti-marketplace/goal-lifecycle"><img src="https://agentmods.dev/badge/skills/synaptiai/synapti-marketplace/goal-lifecycle/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/synaptiai/synapti-marketplace/goal-lifecycle"><img src="https://agentmods.dev/badge/skills/synaptiai/synapti-marketplace/goal-lifecycle.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00138 | $0.01179 |
| Opus 5 | $0.00069 | $0.00589 |
| Sonnet 5 | $0.00028 | $0.00236 |
| Haiku 4.5 | $0.00014 | $0.00118 |
Grade A, and why
goal-lifecycle scanned grade A with 0 findings 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 2d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Goal Lifecycle
Contract
Iron law: no lifecycle.status transition without an audit-trail entry — the goal file changes only through bin/flow-goal-record.sh --update-lifecycle, and every transition writes a goal-created (draft → active) or goal-evaluation journal artifact. Invoked by /flow:goal create, /flow:start Phase 1, and /flow:debug for draft → active after goal-contract-capture; by /flow:goal pause | resume | clear; after /flow:goal evaluate confirms a terminal verdict; and by goal-evaluator for non-terminal updates. Inputs: goal id, from-state, to-state, reason, trigger (evaluator | command | hook | user). Returns the new status once the write and the artifact both succeed. Permitted skip: the run event when scope.run_id is unset. Nothing else.
State machine
Non-terminal: draft, active, and the resumable waiting_for_user, waiting_for_ci, blocked. Terminal and immutable: achieved, failed, cancelled — new work needs a new goal id. The allowed-transition table with triggers, the disallowed transitions, and the last_evaluation.result mapping live in references/goal-lifecycle-transitions.md; bin/flow-goal-record.sh enforces the same table and refuses anything outside it (including terminal → any, active → draft, and blocked → achieved without passing through active).
Outputs
- Goal file:
lifecycle.status,lifecycle.last_evaluation, optionalcurrent_phase/current_activity,turns_evaluatedincremented when leavingactivefor a non-terminal state. - Journal artifact:
goal-createdfor draft → active,goal-evaluationfor every other transition. - One
lifecycle_transitionevent in.flow/runs/<run-id>/events.jsonlwhenrun_idis set.
Workflow
- Validate — read the goal. If its status differs from the caller's from-state, another process transitioned it: stop and raise the six-field escalation (
references/escalation-format.md). Reject a transition outside the table with a stderr explanation and exit 1. - Compose the lifecycle fragment:
lifecycle: status: <to> current_phase: <preserved or caller-updated> current_activity: <preserved or caller-updated> turns_evaluated: <incremented when from=active and to is non-terminal> last_evaluation: result: <pass | incomplete | fail | needs_human_review | blocked> reason: <caller-provided; under 200 chars; comma-safe> at: <ISO-8601 UTC now> - Write —
bin/flow-goal-record.sh --update-lifecycle --goal-id <id> --lifecycle-file <fragment> --from-status <from>. The helper takes an O_NOFOLLOW lock, replaces only thelifecycleblock, validates againstschemas/v1/goal.schema.jsonwhenjsonschemais installed, and writes tempfile + rename + fsync. Surface any non-zero exit with its stderr; do not retry blindly — a race means re-reading the state. - Journal — draft → active:
bin/journal-record.sh --issue {N} --type goal-created --metadata goal_id=<id> --metadata source=<src>. Otherwise:bin/journal-record.sh --issue {N} --type goal-evaluation --metadata goal_id=<id> --metadata result=<to> --metadata reason=<short>. Ad-hoc goals with no issue write to the session journal.decisions/session-{YYYY-MM-DD}.md. - Run event — when
run_idis set, append{"at","type":"lifecycle_transition","goal_id","from","to"}to.flow/runs/<run-id>/events.jsonl;bin/flow-record-activity.shappends it as part of the FlowActivity the caller records for the phase boundary.
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.
- 2d ago Changed · -107 lines · -29 tokens per session 29816d17db4c
- 9d ago First seen · 161 lines · 167 tokens per session scan A 355153ff4cb5
goal-lifecycle is a skill published in the GitHub repository synaptiai/synapti-marketplace (6 stars, last pushed today), licensed Apache-2.0. It adds 138 tokens to every session and 1,179 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
step4-archive-spec
Archive a completed spec — moves it to specs-archived and blocks agent access.
plan-roadmap
Create or update a prioritized product roadmap with phased milestones.
x-dev
A development workflow for completing tasks from a task folder. It follows the task's README and checklist, implements work in dependency order, and records verification evidence.
x-req
A requirements planner that turns a confirmed request into a ready-to-build task package. It assigns a risk level from Q0 to Q3, where higher levels cover changes such as permissions, public interfaces, data migrations, or concurrency.
pocket-closing
Terminal pocket stage. User invokes after pocket-development's phase-level pass writes verdicts. Reconciles reviews against log.json, gates on REVIEWFAIL/REVIEWBLOCKED, advances REVIEW→DONE, runs log close, and emits a closeout summary. Trigger on "pocket-closing", "close the plan", "close out", "finalize plan", or…
product-manager
Use when writing user stories or acceptance criteria, defining product requirements, prioritising a feature backlog, creating a product roadmap, analysing product metrics, facilitating discovery for a new feature, evaluating trade-offs between product directions, or any task that requires deciding what to build and…