Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

tdd-red-green-refactor

Étoiles4

Forks0

Mis à jour8 juin 2026 à 09:27

Implement behaviour changes with Arey Pi strict Red-Green-Refactor. Use when adding features, fixing bugs, or changing production behaviour where tests must drive implementation.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

alereyleyva

alereyleyva/arey-pi

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	tdd-red-green-refactor
description	Implement behaviour changes with Arey Pi strict Red-Green-Refactor. Use when adding features, fixing bugs, or changing production behaviour where tests must drive implementation.

TDD Red-Green-Refactor

Use this skill for production behaviour changes under Arey Pi.

TDD is mandatory unless the user explicitly chooses a non-behaviour mode or a project constraint blocks it. If blocked, report the blocker; do not claim TDD evidence.

Required Reading

Read these files when available:

AGENTS.md
rules/engineering/tdd.md
rules/engineering/test-quality.md
rules/engineering/engineering-quality.md
rules/engineering/quality-tooling.md
rules/core/definition-of-done.md
rules/specs/spec-sync.md
affected Gherkin specs under specs/features/
existing tests and test runner configuration

Workflow

Understand accepted behaviour
- Identify the canonical spec, bug report, or explicit user acceptance criteria.
- Ask focused questions if behaviour is ambiguous.
Red
- Add or update meaningful tests before production code changes.
- Prefer tests/, test/, spec/, or equivalent dedicated test directories.
- Do not place tests inside production source directories by default.
- Run the narrowest relevant test command and capture failure evidence.
Green
- Implement the smallest high-quality production change.
- Avoid speculative abstractions and broad rewrites.
- Run the failing test again and capture passing evidence.
Refactor
- Improve clarity/design only while tests remain green.
- Keep behaviour unchanged during refactor.
Validate
- Run available formatter, lint/static analysis, typecheck, tests, coverage, mutation testing, or dynamic checks appropriate to risk.
- Surface missing quality tooling as a gap.
Sync
- Update specs, docs, DBML, ADRs, glossary, or architecture docs when the intended behaviour or contract changed.

Output

Return:

TDD report:
- Behaviour:
- Tests added/updated and location:
- Red evidence:
- Green evidence:
- Refactor evidence:
- Validation commands and results:
- Spec/docs/ADR/DBML/glossary impact:
- Quality notes:
- Residual risks:

Plus depuis ce dépôt

même dépôt

engineering-review

alereyleyva/arey-pi

Perform an adversarial Arey Pi engineering review of a diff, feature, bugfix, plan, or repository area. Use to assess correctness, tests, quality tooling, security, maintainability, and spec/docs sync before completion.

2026-06-084

spec-sync

alereyleyva/arey-pi

Find and repair drift between Arey Pi specs, tests, code, DBML, ADRs, glossary, docs, prompts, skills, agents, and tooling instructions. Use before finalising non-trivial work or when drift is suspected.

2026-06-084

project-readiness

alereyleyva/arey-pi

Evaluate whether a repository is aligned with Arey Pi rules. Use when assessing specs, tests, quality tooling, AGENTS.md, skills, prompts, subagents, or project readiness.

2026-06-084

TDD Red-Green-Refactor

Use this skill for production behaviour changes under Arey Pi.

TDD is mandatory unless the user explicitly chooses a non-behaviour mode or a project constraint blocks it. If blocked, report the blocker; do not claim TDD evidence.

Required Reading

Read these files when available:

AGENTS.md

rules/engineering/tdd.md

rules/engineering/test-quality.md

rules/engineering/engineering-quality.md

rules/engineering/quality-tooling.md

rules/core/definition-of-done.md

rules/specs/spec-sync.md

affected Gherkin specs under specs/features/

existing tests and test runner configuration

Workflow

Understand accepted behaviour

Identify the canonical spec, bug report, or explicit user acceptance criteria.
Ask focused questions if behaviour is ambiguous.

Red

Add or update meaningful tests before production code changes.
Prefer tests/, test/, spec/, or equivalent dedicated test directories.
Do not place tests inside production source directories by default.
Run the narrowest relevant test command and capture failure evidence.

Green

Implement the smallest high-quality production change.
Avoid speculative abstractions and broad rewrites.
Run the failing test again and capture passing evidence.

Refactor

Improve clarity/design only while tests remain green.
Keep behaviour unchanged during refactor.

Validate

Run available formatter, lint/static analysis, typecheck, tests, coverage, mutation testing, or dynamic checks appropriate to risk.
Surface missing quality tooling as a gap.

Sync

Update specs, docs, DBML, ADRs, glossary, or architecture docs when the intended behaviour or contract changed.

Output

Return:

TDD report: - Behaviour: - Tests added/updated and location: - Red evidence: - Green evidence: - Refactor evidence: - Validation commands and results: - Spec/docs/ADR/DBML/glossary impact: - Quality notes: - Residual risks: