Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

task-implement

Sterne19

Forks3

Aktualisiert23. Juni 2026 um 13:44

Use to execute a single task from an approved tasks.md. Fourth stage of the four-stage spec-driven workflow. Reads spec.html, plan.html, tasks.md, then implements one task at a time, respecting constitution gates.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

Boavizta

Boavizta/e-footprint

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name	task-implement
description	Use to execute a single task from an approved tasks.md. Fourth stage of the four-stage spec-driven workflow. Reads spec.html, plan.html, tasks.md, then implements one task at a time, respecting constitution gates.

task-implement

You are about to implement one task from an approved tasks list.

Process

Confirm which feature and which task. Read specs/features/<feature-name>/tasks.md. The user must name a specific task or pick the first uncompleted one.
Read the spec, plan, and tasks for this feature in full. Read specs/architecture.md and specs/conventions.md. Read specs/constitution.md for the quality gates.
Implement the task. Touch only the files listed in the task. If you need to touch more, stop and surface it.
Run quality gates from specs/constitution.md §2:
- Tests pass.
- Any other repo-specific gates (mkdocs build, JSON round-trip, schema migration, CHANGELOG entry).
Update tasks.md to mark the task done (e.g. add a **Status:** Done line under it).
Commit the task. Stage all changes and commit with a message following the repo convention:
- Prefix: pick one of [ADD], [UPDATE], [FIX], [REFACTO], [REMOVE] based on the nature of the task.
- Body: <feature-name>: <task title from tasks.md>.
- Example: [ADD] source-block: hoist inline sources to top-level Sources block. This scopes the diff so task-review can analyse it cleanly.
Tell the user what was implemented, what tests pass, what's left in the tasks list. Also remind the user to run the task-review skill on the task.

Constraints

One task at a time. Do not chain into the next task without user confirmation.
If a task reveals a missing dependency or an incorrect plan assumption, stop and surface it rather than expanding scope.
If you discover an unrelated bug, follow constitution §3.1: fix on the spot or surface it. Do not paper over.
Never reference spec documents in code comments or any production/test file. Do not mention task numbers (e.g. "Task 3"), spec section markers (e.g. "§4.2"), plan paragraphs, or feature names from the spec workflow (e.g. "model-comparison Task 4"). Spec documents are deleted after the archiving step; any such reference becomes a dangling pointer and leaks implementation-process noise into the codebase. Describe the why of the code in plain terms instead.

Mehr aus diesem Repository

gleiches Repository

feature-archive

Boavizta/e-footprint

Stage 5 of the spec-driven workflow — archive a shipped feature. Run this only once every task in the feature's tasks.md has shipped AND you are satisfied the work is done (typically after review, and when PR is ready to open). It promotes any durable insight into the live reference specs, then deletes the spec folder. It never writes an archive summary file. Invoke explicitly; it is not auto-chained from feature-implement.

2026-07-0219

feature-implement

Boavizta/e-footprint

Orchestrate the full implementation of a feature's tasks.md end to end. A supervisor agent loops over every uncompleted task, spawning an implement sub-agent then a review sub-agent, triaging the review findings with its own judgement — auto-approving the evident fixes and escalating only genuinely structuring decisions to the user via AskUserQuestion — applying the fixes, and continuing to the next task. Use when you want to drive a whole feature with minimal human intervention, surfacing only the decisions that genuinely need you.

2026-06-3019

spec-plan

Boavizta/e-footprint

Use after the user approves a spec.html to write or refine the corresponding plan.html. Second stage of the four-stage spec-driven workflow. Plan answers HOW the spec becomes code; respects architecture.md. Still no code execution.

2026-06-0219

spec-specify

Boavizta/e-footprint

Use when the user wants to start a new feature in this repo. Walks the agent through writing specs/features/<feature-name>/spec.html — the first stage of the four-stage spec-driven workflow (specify → plan → tasks → implement). Read-only on code. May also draft plan.html in the same pass when the kickoff is design-rich.

2026-06-0219

spec-tasks

Boavizta/e-footprint

Use after the user approves a plan.html to break it into ordered, independently-shippable tasks. Third stage of the four-stage spec-driven workflow. Output is tasks.md; still no code execution.

2026-06-0219

task-review

Boavizta/e-footprint

Review the last commit for complexity, dead code, missed invariants, test quality, and broader code quality opportunities. Returns a numbered findings list for discussion — does not implement fixes. Use after task-implement completes a task.

2026-06-0219

name	task-implement
description	Use to execute a single task from an approved tasks.md. Fourth stage of the four-stage spec-driven workflow. Reads spec.html, plan.html, tasks.md, then implements one task at a time, respecting constitution gates.

task-implement

You are about to implement one task from an approved tasks list.

Process

Confirm which feature and which task. Read specs/features/<feature-name>/tasks.md. The user must name a specific task or pick the first uncompleted one.
Read the spec, plan, and tasks for this feature in full. Read specs/architecture.md and specs/conventions.md. Read specs/constitution.md for the quality gates.
Implement the task. Touch only the files listed in the task. If you need to touch more, stop and surface it.
Run quality gates from specs/constitution.md §2:
- Tests pass.
- Any other repo-specific gates (mkdocs build, JSON round-trip, schema migration, CHANGELOG entry).
Update tasks.md to mark the task done (e.g. add a **Status:** Done line under it).
Commit the task. Stage all changes and commit with a message following the repo convention:
- Prefix: pick one of [ADD], [UPDATE], [FIX], [REFACTO], [REMOVE] based on the nature of the task.
- Body: <feature-name>: <task title from tasks.md>.
- Example: [ADD] source-block: hoist inline sources to top-level Sources block. This scopes the diff so task-review can analyse it cleanly.
Tell the user what was implemented, what tests pass, what's left in the tasks list. Also remind the user to run the task-review skill on the task.

Constraints

One task at a time. Do not chain into the next task without user confirmation.
If a task reveals a missing dependency or an incorrect plan assumption, stop and surface it rather than expanding scope.
If you discover an unrelated bug, follow constitution §3.1: fix on the spot or surface it. Do not paper over.
Never reference spec documents in code comments or any production/test file. Do not mention task numbers (e.g. "Task 3"), spec section markers (e.g. "§4.2"), plan paragraphs, or feature names from the spec workflow (e.g. "model-comparison Task 4"). Spec documents are deleted after the archiving step; any such reference becomes a dangling pointer and leaks implementation-process noise into the codebase. Describe the why of the code in plain terms instead.