# Enable > Build one slice at a time with red-before-green tests at the agreed seams and tight feedback loops. Use when a tracked piece of work is at its enablement stage and a slice needs building. - **Type:** Skill - **Install:** `agentstack add skill-donald-ada-workinggenius-enable` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [donald-ada](https://agentstack.voostack.com/s/donald-ada) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [donald-ada](https://github.com/donald-ada) - **Source:** https://github.com/donald-ada/workinggenius/tree/main/skills/enable ## Install ```sh agentstack add skill-donald-ada-workinggenius-enable ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Enablement The genius of doing the work the work needs. Its failure mode is flying blind: code produced without feedback until a big-bang reveal at the end. Enablement keeps the loop tight — every few minutes, reality gets a vote. Run the `genius-file` skill: read the work file. Galvanizing's gate must be **fully** checked (or skipped, recorded) before this stage begins — count the boxes, don't skim. Unchecked boxes but the file records the user's approval? That's housekeeping the approving session forgot: repair the boxes, note it in the build log, proceed. Unchecked and genuinely unsatisfied? Stop and surface it — building through an open gate is how "the agent rushed ahead" comes back. ## Who builds Decide your role from the invocation: - **A specific slice named** ("slug, slice N") → you are the **builder**: build that one slice by the loop below. - **Only the work named, multiple slices, subagents available** → you are the **coordinator**: dispatch each slice to a fresh subagent, in dependency order. Hand each subagent the *work file path* and its slice number — never a pasted summary of earlier slices; the work file and build log are the whole handoff (a summary would anchor it on your reading and rot as slices land). When a subagent returns: read its build-log entry, **re-run the slice's tests fresh yourself**, and confirm the criteria boxes against that output before dispatching the next — a subagent's word is not evidence. Unblocked slices touching disjoint areas may run in parallel (separate worktrees); when in doubt, sequential. You never write product code — coordinating and building don't share a context. - **No subagents, or the user wants to drive each slice** → fresh session per slice: tell the user to open one and say `/enable , slice N`. Either way, each slice is built inside a fresh context — that's the point: the work file carries the work so no context has to. Check `CLAUDE.md` / `AGENTS.md` for pinned verify commands (typecheck, test, lint) — in a `## Working Genius` section or plainly stated anywhere else — and use them exactly. Otherwise discover them from the project's task runner once, and reuse all session. If a verify command's baseline is already dirty (pre-existing failures), record the baseline in the build log and hold the line at **no new failures** — don't adopt the dirt, don't silently fix unrelated code. ## The loop Build the slice through red → green cycles at the seams agreed in Galvanizing: 1. **Red first.** Write one failing test at the agreed seam for the next bit of behavior. Run it. **Watch it fail** — a test you never saw red proves nothing. 2. **Green minimally.** Write just enough code to pass. No speculative parameters, no hooks for imagined futures — the acceptance criteria are the whole spec. 3. **Typecheck** after each green (and lint if the project has it fast). 4. Repeat until the slice's acceptance criteria are covered. Rules that hold every cycle: - **Test behavior, not implementation.** Assert through the seam's public interface; expected values come from an independent source (a known literal, a worked example), never recomputed the way the code computes them. A test that breaks under refactor while behavior held is testing the wrong thing. - **One slice at a time.** Adjacent slices' code is out of bounds, however tempting. - **Mock only at system boundaries** (third-party APIs, time, randomness) — never your own modules. - **Some criteria can't be red-green** — a visual tweak, a config change, a docs page. Don't force a ceremonial test: verify by running/looking at the real thing and record *what you observed* in the build log. The rule is feedback every few minutes, not tests for their own sake. - **Speak the project's language.** If `CONTEXT.md` exists, test names and interface vocabulary follow it. ## When the plan meets reality and loses If the design doesn't survive contact with the code — the seam is wrong, a criterion is unbuildable, a dependency lied — **don't silently improvise**. Enablement responds to what the work actually needs: surface the problem, propose the adjustment, record the change in the work file (plan changes are decisions too), then continue. A quiet workaround today is an unexplainable diff next month. The plan being **silent** is the same case in miniature: a value, contract, or ordering the plan never fixed. If the user is reachable, ask (with a recommendation). If not — whatever the mode — adopt your recommended answer and record it as `assumed:` in the Enablement section, flagged for review at next contact. Never let a silent gap become an invisible convention. ## Closing a slice - Run the slice's tests plus the tests of anything it touched; read the output. - Check off the slice's acceptance criteria **only against real command output**. - Append to the build log: what landed, **every convention you introduced** (injection mechanisms, error orderings, body shapes, test-setup idioms — the things the next session would otherwise reverse-engineer from code), and **known untested edges**. The next session reads this instead of your mind. - **Commit the slice, work-file update included** (message: what behavior landed). A slice that only exists in the working tree dies with the session; Tenacity reviews and can still reshape history, but every closed slice deserves to survive a crash. More unblocked slices → as coordinator, dispatch the next; as builder, report done and name the next slice. All slices built → check the Enablement gate below in the work file, set `stage: tenacity`, and tell the user: next is `/tenacity`. ## Gate — Enablement - [ ] Every slice built, red-before-green at the agreed seams (recorded exceptions — `(verify)` criteria, observed-not-tested checks — allowed) - [ ] Every acceptance criterion checked against real output - [ ] Every plan deviation and `assumed:` recorded in the work file ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [donald-ada](https://github.com/donald-ada) - **Source:** [donald-ada/workinggenius](https://github.com/donald-ada/workinggenius) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-donald-ada-workinggenius-enable - Seller: https://agentstack.voostack.com/s/donald-ada - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.