drt-method 1.0.0

package/src/drt-skills/4-implementation/drt-implement-task/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: drt-implement-task
+description: 'Full coding task flow — clarify intent, approve plan, confirm dependencies, implement, QC, code review, fix loop. Use when the user says implement this task or start coding.'
+---
+
+# Implement Task Workflow
+
+**Goal:** Take a coding task from intent through approved plan, dependency confirmation, implementation, QC, quality review, and bug-fix loops.
+
+Subagents, when available, are an important part of this workflow. Use them as directed. If you need explicit user permission to run subagents, ask once for the whole run.
+
+## Conventions
+
+- Bare paths resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## READY FOR DEVELOPMENT STANDARD
+
+A task spec is ready when:
+
+- **Actionable**: Every task has a file path and specific action.
+- **Logical**: Tasks ordered by dependency.
+- **Testable**: All ACs use Given/When/Then.
+- **Complete**: No placeholders or TBDs.
+- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
+- **Coherent**: No unresolved ambiguities or internal contradictions.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_drt/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_drt/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_drt/drt/config.yaml` and resolve:
+
+- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `date` as system-generated current datetime
+- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
+- `max_review_loops` = `{workflow.max_review_loops}` (default 3 if unset)
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+- **Micro-file Design**: Each step is self-contained and followed exactly
+- **Just-In-Time Loading**: Only load the current step file
+- **Sequential Enforcement**: Complete steps in order, no skipping
+- **State Tracking**: Persist progress via spec frontmatter and in-memory variables
+- **Append-Only Building**: Build artifacts incrementally
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Read the entire step file before acting
+2. **FOLLOW SEQUENCE**: Execute sections in order
+3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
+4. **LOAD NEXT**: When directed, read fully and follow the next step file
+
+### Critical Rules (NO EXCEPTIONS)
+
+- **NEVER** load multiple step files simultaneously
+- **ALWAYS** read entire step file before execution
+- **NEVER** skip steps or optimize the sequence
+- **ALWAYS** follow the exact instructions in the step file
+- **NEVER** proceed past a plan or dependency checkpoint without explicit user approval
+- **ALWAYS** halt at checkpoints and wait for human input
+
+## FIRST STEP
+
+Read fully and follow: `./steps/step-01-gather-intent.md`

package/src/drt-skills/4-implementation/drt-implement-task/assets/task-spec-template.md

@@ -0,0 +1,60 @@
+---
+title: '{title}'
+type: 'feature'
+created: '{date}'
+status: 'draft'
+review_loop_iteration: 0
+approved_dependencies: []
+context: []
+---
+
+<frozen-after-approval reason="human-owned intent — do not modify unless human renegotiates">
+
+## Intent
+
+**Problem:** ONE_TO_TWO_SENTENCES
+
+**Approach:** ONE_TO_TWO_SENTENCES
+
+## Boundaries & Constraints
+
+**Always:** INVARIANT_RULES
+
+**Ask First:** DECISIONS_REQUIRING_HUMAN_APPROVAL
+
+**Never:** NON_GOALS_AND_FORBIDDEN_APPROACHES
+
+## I/O & Edge-Case Matrix
+
+| Scenario | Input / State | Expected Output / Behavior | Error Handling |
+|----------|--------------|---------------------------|----------------|
+| HAPPY_PATH | INPUT | OUTCOME | N/A |
+| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
+
+</frozen-after-approval>
+
+## Code Map
+
+- `FILE` -- ROLE_OR_RELEVANCE
+
+## Tasks & Acceptance
+
+**Execution:**
+- [ ] `FILE` -- ACTION -- RATIONALE
+
+**Acceptance Criteria:**
+- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
+
+## Spec Change Log
+
+## Design Notes
+
+DESIGN_RATIONALE_AND_EXAMPLES
+
+## Verification
+
+**Commands:**
+- `COMMAND` -- expected: SUCCESS_CRITERIA
+
+**Manual checks (if no CLI):**
+- WHAT_TO_INSPECT_AND_EXPECTED_STATE

package/src/drt-skills/4-implementation/drt-implement-task/customize.toml

@@ -0,0 +1,17 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for drt-implement-task.
+
+[workflow]
+
+activation_steps_prepend = []
+
+activation_steps_append = []
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+max_review_loops = 3
+
+on_complete = ""

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-01-gather-intent.md

@@ -0,0 +1,42 @@
+---
+task_summary: ''
+spec_file: ''
+route: ''
+story_file: ''
+---
+
+# Step 1: Gather Intent
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The prompt that triggered this workflow IS the intent — not a hint.
+- Do not modify any files in this step except when resuming an existing task spec.
+
+## INSTRUCTIONS
+
+1. **Resume check.** Scan `{implementation_artifacts}` for `task-*.md` files. If the user did not specify a new task and active specs exist, list them with status and HALT. Ask which to resume or `[N]` for new.
+
+   Resume routing by `status` in frontmatter:
+   - `draft` → set `{spec_file}`, **EARLY EXIT** → `./step-02-plan-and-approve.md`
+   - `ready-for-dev` → set `{spec_file}`, **EARLY EXIT** → `./step-03-confirm-dependencies.md`
+   - `in-progress` → set `{spec_file}`, **EARLY EXIT** → `./step-04-implement.md`
+   - `in-review` → set `{spec_file}`, **EARLY EXIT** → `./step-06-quality-review.md`
+
+2. **Story path — delegate.** Check in order — stop when matched:
+
+   **Tier 1 — Explicit story path.** User passed a story file path → verify it exists. Set `{story_file}`, `{route}` = `story`. Invoke the `drt-dev-story` skill with that story path. When dev-story completes, offer `drt-code-review`. **STOP** this workflow.
+
+   **Tier 2 — Sprint tracking.** If `{sprint_status}` exists, scan `development_status` for the first story with status `ready-for-dev` or `in-progress`. If exactly one found, suggest it and HALT: `[Y] Yes, use this story` | `[N] No, continue task flow`. On Yes → set `{route}` = `story`, invoke `drt-dev-story`. **STOP** this workflow.
+
+3. **Capture task intent.** From the user's message and recent conversation:
+   - Set `{task_summary}` to a one-paragraph summary of what to build or fix.
+   - If intent is ambiguous, HALT with up to 3 numbered questions. Re-ask only unanswered questions until clear.
+
+4. **Optional deepen.** If intent is thin (no problem statement, no success criteria), mention that `drt-brainstorming` or `drt-advanced-elicitation` in a fresh session can help — but do not require them to proceed.
+
+5. **Initialize spec.** Derive kebab-case `{slug}` from `{task_summary}` (lead with issue/ticket ID if mentioned). Set `{spec_file}` = `{implementation_artifacts}/task-{slug}.md`. If file exists with `status: done`, append `-2`, `-3`, etc. Set `{route}` = `task`.
+
+## NEXT
+
+Read fully and follow `./step-02-plan-and-approve.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-02-plan-and-approve.md

@@ -0,0 +1,43 @@
+---
+---
+
+# Step 2: Plan and Approve
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Do not proceed to implementation until the user explicitly approves the plan.
+- No intermediate approvals beyond CHECKPOINT 1.
+
+## INSTRUCTIONS
+
+1. **Draft resume.** If `{spec_file}` exists with `status: draft`, read it and capture the verbatim `<frozen-after-approval>...</frozen-after-approval>` block as `preserved_intent`. Otherwise `preserved_intent` is empty.
+
+2. **Investigate codebase.** Isolate deep exploration in subagents where available. Instruct subagents to return distilled summaries only.
+
+3. **Write spec.** Read `./assets/task-spec-template.md` fully. Fill it from `{task_summary}` and investigation. Resolve `date` to current system date. If `preserved_intent` is non-empty, replace the `<frozen-after-approval>` block with `preserved_intent` before writing. Write to `{spec_file}` with `status: draft`.
+
+4. **Self-review** against READY FOR DEVELOPMENT STANDARD (defined in SKILL.md).
+
+5. If gaps remain, HALT and ask the user numbered questions. Do not fantasize or leave open questions.
+
+6. **Token check.** If spec exceeds ~1600 tokens, HALT: `[S] Split` | `[K] Keep full spec`. On S, defer secondary goals to `{implementation_artifacts}/deferred-work.md` and rewrite spec for main goal only.
+
+### CHECKPOINT 1
+
+Present plan summary. Display `{spec_file}` as a CWD-relative clickable path.
+
+---
+
+Before approving, you can open the spec file in an editor or ask me to change it. You can also use `drt-advanced-elicitation`, `drt-party-mode`, or `drt-code-review` in another session to avoid context bloat.
+
+---
+
+HALT and ask: `[A] Approve` | `[E] Edit`
+
+- **A**: Re-read `{spec_file}` from disk. If missing, HALT and STOP. If changed since you wrote it, acknowledge edits and use the updated version. Set `status: ready-for-dev`. Everything inside `<frozen-after-approval>` is now locked.
+- **E**: Apply user changes, then return to CHECKPOINT 1.
+
+## NEXT
+
+Read fully and follow `./step-03-confirm-dependencies.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-03-confirm-dependencies.md

@@ -0,0 +1,38 @@
+---
+---
+
+# Step 3: Confirm Dependencies
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Do not install packages or modify lockfiles until the user approves.
+- Do not proceed to implementation without passing this checkpoint when new dependencies are needed.
+
+## INSTRUCTIONS
+
+1. Read `{spec_file}` Tasks section and Code Map.
+
+2. Scan existing manifests: `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `pyproject.toml`, `requirements.txt`, `go.mod`, `Cargo.toml`, `Gemfile`, or equivalents present in the project.
+
+3. List **new dependencies** required for this task: package name, version (or range), reason, and alternative if any.
+
+4. If no new dependencies are needed:
+   - Set `approved_dependencies: []` in `{spec_file}` frontmatter.
+   - Proceed to NEXT.
+
+5. If new dependencies are needed, present a table:
+
+   | Package | Version | Reason |
+   |---------|---------|--------|
+
+   **CHECKPOINT 2** — HALT and ask: `[A] Approve all` | `[P] Approve partial` (user lists which) | `[R] Reject — revise plan`
+
+   - **A** or **P**: Write approved packages to `approved_dependencies` in frontmatter. Only then run install commands (`npm install`, `pip install`, etc.) for approved packages.
+   - **R**: Return to `./step-02-plan-and-approve.md` with user feedback.
+
+6. If implementation later requires a dependency **not** in `approved_dependencies`, HALT and return to this step.
+
+## NEXT
+
+Read fully and follow `./step-04-implement.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-04-implement.md

@@ -0,0 +1,42 @@
+---
+---
+
+# Step 4: Implement
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Red, green, refactor — in that order.
+- No push. No remote ops.
+- Content inside `<frozen-after-approval>` is read-only. Do not modify.
+- Execute tasks in the order written in the spec.
+
+## PRECONDITION
+
+Verify `{spec_file}` exists and `status` is `ready-for-dev` or `in-progress`. If not, HALT.
+
+## INSTRUCTIONS
+
+1. Capture `baseline_commit` (current HEAD, or `NO_VCS` if unavailable) into `{spec_file}` frontmatter.
+
+2. Set `status: in-progress` in frontmatter before making code changes.
+
+3. If `{spec_file}` has a non-empty `context:` list in frontmatter, load those files before implementation.
+
+4. For each task in **Execution** (unchecked):
+   - Write FAILING tests first for the task functionality.
+   - Confirm tests fail before implementation.
+   - Implement minimal code to make tests pass.
+   - Run tests to confirm they pass.
+   - Refactor while keeping tests green.
+   - Mark task `[x]` in the spec.
+
+5. Verify every Acceptance Criterion is satisfied.
+
+6. If a new dependency is needed beyond `approved_dependencies`, HALT and return to `./step-03-confirm-dependencies.md`.
+
+7. If 3 consecutive implementation failures occur on the same task, HALT and ask for guidance.
+
+## NEXT
+
+Read fully and follow `./step-05-qc-test.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-05-qc-test.md

@@ -0,0 +1,31 @@
+---
+---
+
+# Step 5: QC Test
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Do not proceed to code review while tests are failing.
+
+## INSTRUCTIONS
+
+1. Read **Verification** section in `{spec_file}`. If empty, infer test and lint commands from project structure and `project-context.md`.
+
+2. Run the **full existing test suite** (regression check).
+
+3. Run **new tests** introduced for this task.
+
+4. Run lint/format if the project has standard scripts.
+
+5. Present results: pass/fail per command, failing output summarized.
+
+6. **If any check fails** → return to `./step-04-implement.md` to fix. Do not proceed.
+
+7. **If all pass:**
+   - Set `status: in-review` in `{spec_file}` frontmatter.
+   - Mention that `drt-qa-generate-e2e-tests` is available if the user wants automated API/E2E coverage before review.
+
+## NEXT
+
+Read fully and follow `./step-06-quality-review.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-06-quality-review.md

@@ -0,0 +1,30 @@
+---
+review_findings_count: 0
+---
+
+# Step 6: Quality Review
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Delegate adversarial review to `drt-code-review` — do not duplicate review layers here.
+
+## INSTRUCTIONS
+
+1. Increment `review_loop_iteration` in `{spec_file}` frontmatter before invoking review.
+
+2. Invoke the **`drt-code-review`** skill with:
+   - `{spec_file}` as the spec/story context
+   - Diff since `baseline_commit` in frontmatter (or uncommitted changes if `NO_VCS`)
+
+3. Let `drt-code-review` complete its triage and present findings. Collect counts: `decision_needed`, `patch`, `defer`, `dismiss`.
+
+4. Set `{review_findings_count}` = number of unresolved `patch` + `decision_needed` findings after CR completes.
+
+5. Routing:
+   - If `decision_needed` or `patch` findings remain → **NEXT** → `./step-07-fix-findings.md`
+   - If clean (zero patch/decision_needed) or only defer/dismiss → **NEXT** → `./step-08-complete.md`
+
+## NEXT
+
+If findings need fixing, read fully and follow `./step-07-fix-findings.md`. Otherwise read fully and follow `./step-08-complete.md`.

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-07-fix-findings.md

@@ -0,0 +1,33 @@
+---
+---
+
+# Step 7: Fix Findings
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Resolve `decision_needed` findings before applying `patch` fixes.
+
+## INSTRUCTIONS
+
+1. **Decision-needed.** For each `decision_needed` finding from code review, present detail and options. HALT until the user decides. Each resolved item becomes `patch`, `defer`, or dismissed.
+
+2. **Patch findings.** HALT and ask:
+
+   > **How would you like to handle the patch findings?**
+   > 1. **Apply every patch** — fix all now
+   > 2. **Walk through each** — show details before deciding
+   > 3. **Leave as action items** — keep in spec, stop here
+
+   - **Apply every patch** or **Walk through**: fix code, check off items in spec Review Findings section if present.
+   - **Leave as action items**: set spec `status: in-progress`, proceed to step 8 with open items noted.
+
+3. **Loop guard.** Read `review_loop_iteration` from `{spec_file}` frontmatter. If it exceeds `{max_review_loops}` and unresolved `high` or `medium` findings remain, HALT. Offer `drt-correct-course` or user override to continue.
+
+4. After fixes applied, return to `./step-05-qc-test.md` then `./step-06-quality-review.md` for another review round.
+
+5. When review is clean or only defer items remain, proceed to step 8.
+
+## NEXT
+
+After QC and re-review pass, read fully and follow `./step-08-complete.md`

package/src/drt-skills/4-implementation/drt-implement-task/steps/step-08-complete.md

@@ -0,0 +1,35 @@
+---
+---
+
+# Step 8: Complete
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+## INSTRUCTIONS
+
+1. If no unresolved `patch` or `decision_needed` findings remain, set `status: done` in `{spec_file}` frontmatter.
+
+2. Present completion summary:
+   - Task title and `{spec_file}` path
+   - Files changed (CWD-relative paths with `:line` where helpful)
+   - Test results from final QC pass
+   - Review rounds (`review_loop_iteration`)
+   - Deferred items count
+
+3. Offer next steps:
+
+   > **What would you like to do next?**
+   > 1. **Start another task** — run `drt-implement-task` again
+   > 2. **Run code review again** — `drt-code-review`
+   > 3. **Ask what's next** — `drt-help`
+   > 4. **Done**
+
+   HALT and wait for user choice.
+
+## On Complete
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow.on_complete`
+
+If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/drt-skills/4-implementation/drt-qa-generate-e2e-tests/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: drt-qa-generate-e2e-tests
+description: 'Generate end to end automated tests for existing features. Use when the user says "create qa automated tests for [feature]"'
+---
+
+# QA Generate E2E Tests Workflow
+
+**Goal:** Generate automated API and E2E tests for implemented code.
+
+**Your Role:** You are a QA automation engineer. You generate tests ONLY — no code review or story validation (use the `drt-code-review` skill for that).
+
+## Conventions
+
+- Bare paths (e.g. `checklist.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_drt/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_drt/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/_drt/drt/config.yaml` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `implementation_artifacts`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
+
+## Paths
+
+- `test_dir` = `{project-root}/tests`
+- `source_dir` = `{project-root}`
+- `default_output_file` = `{implementation_artifacts}/tests/test-summary.md`
+
+## Execution
+
+### Step 0: Detect Test Framework
+
+Check project for existing test framework:
+
+- Look for `package.json` dependencies (playwright, jest, vitest, cypress, etc.)
+- Check for existing test files to understand patterns
+- Use whatever test framework the project already has
+- If no framework exists:
+  - Analyze source code to determine project type (React, Vue, Node API, etc.)
+  - Search online for current recommended test framework for that stack
+  - Suggest the meta framework and use it (or ask user to confirm)
+
+### Step 1: Identify Features
+
+Ask user what to test:
+
+- Specific feature/component name
+- Directory to scan (e.g., `src/components/`)
+- Or auto-discover features in the codebase
+
+### Step 2: Generate API Tests (if applicable)
+
+For API endpoints/services, generate tests that:
+
+- Test status codes (200, 400, 404, 500)
+- Validate response structure
+- Cover happy path + 1-2 error cases
+- Use project's existing test framework patterns
+
+### Step 3: Generate E2E Tests (if UI exists)
+
+For UI features, generate tests that:
+
+- Test user workflows end-to-end
+- Use semantic locators (roles, labels, text)
+- Focus on user interactions (clicks, form fills, navigation)
+- Assert visible outcomes
+- Keep tests linear and simple
+- Follow project's existing test patterns
+
+### Step 4: Run Tests
+
+Execute tests to verify they pass (use project's test command).
+
+If failures occur, fix them immediately.
+
+### Step 5: Create Summary
+
+Output markdown summary:
+
+```markdown
+# Test Automation Summary
+
+## Generated Tests
+
+### API Tests
+- [x] tests/api/endpoint.spec.ts - Endpoint validation
+
+### E2E Tests
+- [x] tests/e2e/feature.spec.ts - User workflow
+
+## Coverage
+- API endpoints: 5/10 covered
+- UI features: 3/8 covered
+
+## Next Steps
+- Run tests in CI
+- Add more edge cases as needed
+```
+
+## Keep It Simple
+
+**Do:**
+
+- Use standard test framework APIs
+- Focus on happy path + critical errors
+- Write readable, maintainable tests
+- Run tests to verify they pass
+
+**Avoid:**
+
+- Complex fixture composition
+- Over-engineering
+- Unnecessary abstractions
+
+**For Advanced Features:**
+
+If the project needs:
+
+- Risk-based test strategy
+- Test design planning
+- Quality gates and NFR assessment
+- Comprehensive coverage analysis
+- Advanced testing patterns and utilities
+
+> **Install Test Architect (TEA) module**: <https://drt-method.github.io/drt-method-test-architecture-enterprise/>
+
+## Output
+
+Save summary to: `{default_output_file}`
+
+**Done!** Tests generated and verified. Validate against `./checklist.md`.
+
+## On Complete
+
+Run: `node {project-root}/_drt/scripts/resolve-customization.js --skill {skill-root} --key workflow.on_complete`
+
+If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.