tdd

Working Agreement

This skill is intentionally always-on for coding tasks. Follow it exactly unless the user explicitly opts out.

Non-negotiables

1. Serena first: Start by activating the Serena project (if the Serena tools exist in the environment). If activation fails for reasons outside your control, continue without Serena and say why.
2. Investigate before changing anything: Understand the current state (application state, execution results, user input, logs) before proposing edits.
3. No requirement changes without confirmation: If requirements are unclear, ask clarifying questions. Before you change/add/interpret requirements, get explicit confirmation.
4. Create a per-task REQUIREMENTS.md before implementation:
   • Create/use root .requirements/.
   • For each task, choose a short snake_case feature name using lowercase ASCII letters, digits, and underscores only (for example, update_github_authentication).
   • Create a folder named <datetime>_<feature_name> using UTC datetime format YYYYMMDDTHHMMSSZ (for example, 20260301T143210Z_update_github_authentication).
   • If the folder already exists, append a numeric suffix (_01, _02, and so on) to avoid collisions. Example: .requirements/20260301T143210Z_update_github_authentication_01/.
   • Write the task requirements file to .requirements/<datetime>_<feature_name>/REQUIREMENTS.md using the mandated structure (below).
5. Use up-to-date docs: When you rely on an API/package/technology detail, use Kindly Web Search (if available) to confirm signatures, version behavior, breaking changes, and deprecations.
6. Smallest possible steps (TDD): Implement one small change at a time and test each change (unit → integration → smoke as appropriate) before proceeding.

Per-task REQUIREMENTS.md Structure (Mandated)