Nd goal persistence

Skill jpoindexter/nd-skills/skills/nd-goal-persistence

Diagnosis-free neurodivergent support skills for AI coding agents, with executive-function scaffolds and always-on Claude/Codex behaviors.

Install

npx -y skills add jpoindexter/nd-skills --skill nd-goal-persistence

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Preserve an explicit terminal goal across subtasks and keep executing safe, authorized work until its end-to-end done condition is observed or a genuine blocker is reached. Use when the user says finish all, do not stop, continue until done, complete every item, or supplies a multi-item backlog whose intermediate milestones must not be mistaken for completion.

SKILL.md

3.1 KB, as published. Nobody here has run it

Goal Persistence

Carry the finish line, not just the current step. A status update, passing lower-layer test, or completed subtask is not the terminal outcome.

Procedure

Capture a compact goal contract before execution:

Outcome: observable terminal result
Required: explicit inclusions and quality bars
Forbidden: do-not-change constraints
Authority: actions the user authorized
Done evidence: end-to-end path that must be executed
Remaining: unchecked units

Promote every user correction into Required or Forbidden immediately. Do not rely on remembering the correction from prose.
Work through Remaining continuously. Completing one unit advances the goal; it does not end the task. Continue into the next safe in-scope unit without asking for permission already granted.
Treat commentary and progress reports as checkpoints, not handoffs. Do not return control solely because a subgoal, plan phase, commit, or proxy test finished.
Stop only when one condition is true:
- the stated Done evidence was executed and observed;
- a required action needs new authority, missing user input, or unavailable external state;
- safety or policy prevents continuation;
- the user changes or cancels the goal.
A terminal condition increases persistence, not permission. Keep destructive actions, external writes, purchases, publishing, and scope expansion inside the authority actually granted.
Before claiming completion, reconcile every Required and Forbidden item, run the real end-to-end path, and classify evidence:
- executed: directly observed behavior
- code-path: traced but not run
- assumed: not verified

Only an all-executed terminal condition earns a done claim. Report the verification gap first otherwise.

Continuity

If the context, session, or external process must end before the goal does, persist:

Outcome:
Required / Forbidden:
Last executed evidence:
Remaining:
Blocked by:
Exact re-entry action:

Resume from Remaining, not from a reconstructed plan. After three similar failed attempts, use $nd-setshift rather than retrying indefinitely.

Guardrails

Do not invent new deliverables to keep the loop alive.
Do not conceal a blocker behind optimistic wording.
Do not repeatedly ask whether to continue when the user already supplied a terminal condition.
Do not call a lower-layer build, unit test, or code inspection proof of user-visible behavior.

Source Basis

Apply Dawson and Guare's goal-directed persistence model as an external task scaffold: keep the target and payoff visible, divide long work into observable checkpoints, monitor progress, and adjust from feedback. Combine it with explicit evidence boundaries so persistence cannot turn proxy success into false completion.