Run any Skill in Manus with one click

finish-the-loop

Stars0

Forks0

UpdatedJuly 1, 2026 at 22:44

Closed-loop delegation — define done as an observable behavior, boot the real app, drive it like a user, fix what breaks, and verify by using it again before reporting. Use when implementing any feature or fix with a runtime surface, when tempted to report "it should work now", or when a task will span a long unattended stretch and the result must be trustworthy without supervision.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

zakelfassi

zakelfassi/skdd-commons

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	finish-the-loop
description	Closed-loop delegation — define done as an observable behavior, boot the real app, drive it like a user, fix what breaks, and verify by using it again before reporting. Use when implementing any feature or fix with a runtime surface, when tempted to report "it should work now", or when a task will span a long unattended stretch and the result must be trustworthy without supervision.
metadata	{"pack":"2026-07-frontier","forged-by":"claude-fable-5","forged-from":"session-2026-07-01-fable-festival","forged-reason":"From the Fable Festival letter: there's an interruption tax, and the fix is the closed loop — 'not I wrote the code and it should work; I watched it work.' Delegating outcomes instead of keystrokes only functions if the agent closes the loop itself; this skill is the closing procedure.","usage-count":"0"}

Finish the Loop

Done means observed, not compiled. The loop is: define done → reproduce → change → drive the real artifact → re-drive after every fix → report with evidence.

Inputs

The goal, stated or restated as observable behavior: "a user who does X sees Y" — not "the code is updated"
A bootable environment (dev server, CLI, simulator, browser)

Steps

Write the acceptance line first. One sentence per behavior: "Submitting the form with an invalid email shows an inline error and preserves the other fields." If the request came as a vibe ("make login less janky"), convert it to acceptance lines and state them — they are the contract for the rest of the loop.
Boot the real thing. Dev server up, app open, in the state a user would actually start from. If the project has a run/boot skill, use it; if booting took undocumented steps, that's a skill to forge later.
Reproduce before fixing. For bugs: watch it fail first. A fix for an unreproduced bug is a guess with a commit message.
Make the change. Smallest diff that satisfies the acceptance lines.
Drive it like a user. Click, type, navigate, submit — through the UI or CLI, not just the test suite. Cover the acceptance lines plus the adjacent paths: the empty state, the error state, the second submission, the mobile width, the back button.
Re-drive after every fix. Each repair re-runs the whole affected flow, not just the step that broke. Fixes regress their neighbors.
Sweep before reporting. Tests, typecheck, lint — the mechanical gates — plus one full pass of the core flow end to end.
Report with evidence. For each acceptance line: what you did, what you observed (screenshot, output, log line). The words "should work" are banned from the report; if something is unverified, name it as unverified rather than laundering it into confidence.

Conventions

Interruptions reset the loop — if the user redirects mid-loop, restate the new acceptance lines before continuing.
Time spent making the app bootable is loop infrastructure, not yak shaving; do it once, freeze it as a skill.

Edge Cases

No runtime surface (pure library, config change): the loop's "drive" step becomes a consumer test — write the snippet a real caller would write and run it. Docs-only diffs exit the skill; there's nothing to observe.
Can't reproduce the bug. Say so and deliver the instrumentation instead: the logging/repro harness that will catch it next occurrence. Don't ship a speculative fix as if it were verified.
The environment can't boot (missing credentials, broken deps): that blocker is the deliverable — report it precisely; a loop that can't close honestly reports itself open.

More from this repository

same repository

name-the-aha

zakelfassi/skdd-commons

Interrogate a product for its core value — name the observable aha moment, measure time-to-aha, or honestly conclude there is none yet. Use when starting Growth Circle work on any repo, when someone asks "how do we grow this", when GROWTH.md is missing or its Aha section is empty, or before any activation/retention/distribution work is proposed. This is the gatekeeper skill — every other growth skill depends on its output.

2026-07-020

prove-the-value

zakelfassi/skdd-commons

Compile a product's earned, evidence-backed claims from GROWTH.md into a public VALUE.md — the proof-of-value surface that agent-mediated discovery reads — with attestation levels, expiry dates, and honest retractions. Use when creating or refreshing a VALUE.md, when marketing copy needs grounding in evidence, when preparing a product to be evaluated by assistants and their principals' agents, or when a published claim has gone stale.

2026-07-020

run-the-loop

zakelfassi/skdd-commons

Run the growth experiment cadence — propose ranked by keystone impact, pre-register before launch, evaluate by the committed rule, keep/kill without relitigating, log everything. Enforces the virality gate (get-users-to-get-users proposals are parked until activation and retention run green) and the alienation test (auto-kill anything a fully-informed user would resent). Use when the growth cadence comes due (weekly/biweekly), when someone proposes "a growth hack", or when experiment results need an honest verdict.

2026-07-020

forge-the-local-circle

zakelfassi/skdd-commons

Use SkDD to forge project-specialized adaptations of the Growth Circle skills — local skills that carry this product's keystone, event names, query paths, contexts, and cadence baked in, so future sessions (and cheaper models) run the circle without rediscovering it. Use when the generic pack has run against a project a few times and keeps re-deriving the same context, when handing growth work to scheduled or lighter-weight agents, or when a project's circle has stabilized enough to be worth freezing as skills.

2026-07-020

wind-the-clock

zakelfassi/skdd-commons

Make the growth circle self-running — schedule its recurring checks (loop cadence, keystone sunset, first-light freshness, AEO probes, trust-ledger review) using whatever scheduling primitive the current harness offers, and record every schedule in GROWTH.md so it survives harness changes. Use when the circle's gates are open but nothing recurs, when a keystone sunset or instrumentation check exists only as a date nobody watches, after run-the-loop establishes a cadence, or when growth work keeps happening "whenever someone remembers".

2026-07-020

hire-the-circle

zakelfassi/skdd-commons

Turn growth-team values into working artifacts — role scorecards, interview kits with listen-fors — and map which rings of the growth circle run on agents versus humans, with explicit approval boundaries. Use when hiring a first growth person, when staffing growth work across a human/agent team, when a growth hire is failing and nobody can say why, or when deciding what an autonomous agent may and may not do to users.

2026-07-020

name	finish-the-loop
description	Closed-loop delegation — define done as an observable behavior, boot the real app, drive it like a user, fix what breaks, and verify by using it again before reporting. Use when implementing any feature or fix with a runtime surface, when tempted to report "it should work now", or when a task will span a long unattended stretch and the result must be trustworthy without supervision.
metadata	{"pack":"2026-07-frontier","forged-by":"claude-fable-5","forged-from":"session-2026-07-01-fable-festival","forged-reason":"From the Fable Festival letter: there's an interruption tax, and the fix is the closed loop — 'not I wrote the code and it should work; I watched it work.' Delegating outcomes instead of keystrokes only functions if the agent closes the loop itself; this skill is the closing procedure.","usage-count":"0"}

Finish the Loop

Done means observed, not compiled. The loop is: define done → reproduce → change → drive the real artifact → re-drive after every fix → report with evidence.

Inputs

The goal, stated or restated as observable behavior: "a user who does X sees Y" — not "the code is updated"
A bootable environment (dev server, CLI, simulator, browser)

Steps

Write the acceptance line first. One sentence per behavior: "Submitting the form with an invalid email shows an inline error and preserves the other fields." If the request came as a vibe ("make login less janky"), convert it to acceptance lines and state them — they are the contract for the rest of the loop.
Boot the real thing. Dev server up, app open, in the state a user would actually start from. If the project has a run/boot skill, use it; if booting took undocumented steps, that's a skill to forge later.
Reproduce before fixing. For bugs: watch it fail first. A fix for an unreproduced bug is a guess with a commit message.
Make the change. Smallest diff that satisfies the acceptance lines.
Drive it like a user. Click, type, navigate, submit — through the UI or CLI, not just the test suite. Cover the acceptance lines plus the adjacent paths: the empty state, the error state, the second submission, the mobile width, the back button.
Re-drive after every fix. Each repair re-runs the whole affected flow, not just the step that broke. Fixes regress their neighbors.
Sweep before reporting. Tests, typecheck, lint — the mechanical gates — plus one full pass of the core flow end to end.
Report with evidence. For each acceptance line: what you did, what you observed (screenshot, output, log line). The words "should work" are banned from the report; if something is unverified, name it as unverified rather than laundering it into confidence.

Conventions

Interruptions reset the loop — if the user redirects mid-loop, restate the new acceptance lines before continuing.
Time spent making the app bootable is loop infrastructure, not yak shaving; do it once, freeze it as a skill.

Edge Cases

No runtime surface (pure library, config change): the loop's "drive" step becomes a consumer test — write the snippet a real caller would write and run it. Docs-only diffs exit the skill; there's nothing to observe.
Can't reproduce the bug. Say so and deliver the instrumentation instead: the logging/repro harness that will catch it next occurrence. Don't ship a speculative fix as if it were verified.
The environment can't boot (missing credentials, broken deps): that blocker is the deliverable — report it precisely; a loop that can't close honestly reports itself open.