Add artifact vault contents

This commit is contained in:
2026-08-01 14:05:09 -04:00
parent 361bde2621
commit 3230f9395b
78 changed files with 6156 additions and 42 deletions

View File

@@ -0,0 +1,40 @@
---
status: resolved
parent: "[[053-implement-skill-review-validation-grill]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T11:35:19-04:00"
blocked-by:
- "[[053-implement-skill-review-validation-grill]]"
- "[[055-implement-skill-tdd-refactor-grill]]"
tags:
- ticket/grill
---
# Implement workflow dependency orchestration grill
## Question
How should `implement` invoke, sequence, and consume the workflow's supporting skills and tools, including `test-driven-development` and `review`?
## Resolution
`implement` should use `test-driven-development` as a strong default when behavior can be usefully specified and tested before implementation.
It may skip TDD when the work is mechanical, documentation-only, exploratory, or when test-first would not add value.
Skipping TDD should be an agent judgment rather than an accident.
`test-driven-development` is process discipline, not a separate artifact.
`implement` records only durable outcomes such as tests added or changed, verification run, and deviations worth noting.
It should not require a TDD report or per-cycle log.
`implement` must run `review` before final handoff or Wayfinder task resolution.
Timing is left to agent judgment: review may happen before commit, after commit, or both.
The review must cover the final intended handoff state, or the agent must explain why it does not.
Blocking review findings should be fixed unless explicitly accepted by the agent or user.
When code changes are made in response to review, `implement` reruns review on the relevant change set.
Accepted blocking findings are recorded where appropriate.
Non-blocking findings are handled by agent judgment: fix when cheap or high-value, otherwise report or record only when useful.
No other supporting skill invocations are prescribed.
The agent may use any skill or tool it judges relevant, but only `test-driven-development` and `review` are named workflow dependencies.
External validation gates such as `no-mistakes` are not part of this implementation workflow.