Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

vertical-tdd

Sterne10

Forks1

Aktualisiert25. Juli 2026 um 06:37

Implement one behavior at a time with a red-green-refactor loop. Use when: executing tasks.md, doing TDD, implementing a feature from specs. Do not use: for test planning, bulk implementation.

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

woliveiras

woliveiras/geremmyas

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

3 Dateien

SKILL.md

readonly

name	vertical-tdd
description	Implement one behavior at a time with a red-green-refactor loop. Use when: executing tasks.md, doing TDD, implementing a feature from specs. Do not use: for test planning, bulk implementation.

Vertical TDD

Use one behavior as the unit of progress. Run only after the user has approved the spec.

Process

Read spec.md, plan.md, and tasks.md in the feature folder.
Pick the next task with - [ ] or continue - [~] in progress. Mark the task - [~] when starting and - [x] when done.
Read the task's test-type (unit, integration, or both) and the spec's Test Strategy. If missing, decide using the same rules as test generation reference.
Write one test that verifies observable behavior through the appropriate boundary (unit: public API of a module; integration: cross-module or I/O).
Run the test and confirm it fails for the expected reason.
Implement the minimum production code to pass that test.
Run the focused test and the nearest relevant suite.
Repeat for the next behavior or task.
Refactor only when tests are green; rerun tests after each refactor.
When all acceptance criteria are done and code is merged, set status: Implemented in spec.md frontmatter and update the row in specs/README.md.
Before stopping work (task done, session ending, or handing off), reconcile status: mark every finished task - [x] in tasks.md, clear any stale - [~], and annotate or mark done any plan.md item fully delivered. Do not declare work complete with stale checkboxes.

Rules

Do not write all tests first and then all implementation.
Do not test private functions, call order, or internal collaborators.
Mock only system boundaries (network, time, filesystem, external services).
If a test appears wrong, revisit the spec before changing the test.
When the user only wants tests from acceptance criteria without implementation, follow test generation.
When progress becomes circular or scope changes materially, follow abort criteria.
Update tasks.md checkboxes as each task starts ([~]) and finishes ([x]). Stale checkboxes block reliable resumption from specs/README.md and the feature folder.

Mehr aus diesem Repository

gleiches Repository

skill-authoring

woliveiras/geremmyas

Create or revise coding-assistant skills that match this repository's structure and conventions. Use when: writing, renaming, or reviewing a skill. Do not use: for general writing or non-skill documentation.

2026-07-2510

android-ci-setup

woliveiras/geremmyas

Set up an Android CI/CD pipeline with lint, static analysis, unit tests, dependency review, and build verification. Use when: creating CI for Android, adding Gradle checks. Do not use: for local development setup, non-CI automation.

2026-07-2510

bugfix-loop

woliveiras/geremmyas

Run a disciplined bugfix loop with reproduction, hypotheses, regression test, fix, and cleanup. Use when: fixing bugs, debugging regressions, investigating failures. Do not use: for feature implementation, refactoring.

2026-07-2510

chromadb-rag-workflow

woliveiras/geremmyas

Design or review a ChromaDB-backed RAG workflow. Use when: creating collections, choosing embedding functions, chunking documents, writing retrievers. Do not use: for general LLM integration, non-RAG patterns.

2026-07-2510

ci-workflow

woliveiras/geremmyas

Create, review, or debug a CI/CD workflow. Use when: editing GitHub Actions, fixing CI failures, adding release/deploy automation. Do not use: for general DevOps, infrastructure as code.

2026-07-2510

code-review-requesting

woliveiras/geremmyas

Structured code review workflow ensuring context and clarity. Use when: implementation complete, tests verified, before merge request. Do not use: during active implementation, before verification checklist, or for design reviews.

2026-07-2510

name	vertical-tdd
description	Implement one behavior at a time with a red-green-refactor loop. Use when: executing tasks.md, doing TDD, implementing a feature from specs. Do not use: for test planning, bulk implementation.

Vertical TDD

Use one behavior as the unit of progress. Run only after the user has approved the spec.

Process

Read spec.md, plan.md, and tasks.md in the feature folder.
Pick the next task with - [ ] or continue - [~] in progress. Mark the task - [~] when starting and - [x] when done.
Read the task's test-type (unit, integration, or both) and the spec's Test Strategy. If missing, decide using the same rules as test generation reference.
Write one test that verifies observable behavior through the appropriate boundary (unit: public API of a module; integration: cross-module or I/O).
Run the test and confirm it fails for the expected reason.
Implement the minimum production code to pass that test.
Run the focused test and the nearest relevant suite.
Repeat for the next behavior or task.
Refactor only when tests are green; rerun tests after each refactor.
When all acceptance criteria are done and code is merged, set status: Implemented in spec.md frontmatter and update the row in specs/README.md.
Before stopping work (task done, session ending, or handing off), reconcile status: mark every finished task - [x] in tasks.md, clear any stale - [~], and annotate or mark done any plan.md item fully delivered. Do not declare work complete with stale checkboxes.

Rules

Do not write all tests first and then all implementation.
Do not test private functions, call order, or internal collaborators.
Mock only system boundaries (network, time, filesystem, external services).
If a test appears wrong, revisit the spec before changing the test.
When the user only wants tests from acceptance criteria without implementation, follow test generation.
When progress becomes circular or scope changes materially, follow abort criteria.
Update tasks.md checkboxes as each task starts ([~]) and finishes ([x]). Stale checkboxes block reliable resumption from specs/README.md and the feature folder.