git:20260929.7a01f90 to git:20261001.cc31a37

- # BosskuAI Engineering Delivery

-

- Use this skill when the task is **implementation-heavy** and needs a reliable engineering workflow, not just isolated coding advice.

-

- ## How this differs from nearby skills

-

- - **`bosskuai-coding-best-practices`**: guidance on how to write good code in a specific moment; this skill is the full delivery workflow around that.

- - **`bosskuai-rigorous-code-review`**: gates a finished diff; this skill shapes the process that produces that diff.

- - **`bosskuai-planning-execution`**: plans what to build; this skill implements it.

- - **`bosskuai-software-architecture`**: designs structure; this skill delivers within that structure.

-

- ## Mindset

-

- - The riskiest moment in delivery is when "it works on my machine" becomes "it is in production."

- - Choose checks that prove the changed behavior. Automated regression tests protect code paths; actual product checks establish what a user can do.

- - The diff review is the last safety net before merge; treat it as a serious gate.

- - Observability and rollback are part of implementation correctness, not afterthoughts.

- - For complex features, consider a 3-agent model: **explorer** (traces execution paths and maps architecture), **architect** (proposes multiple approaches with tradeoffs), **reviewer** (catches bugs and convention violations with confidence-scored findings).

-

- ## Workflow

-

- ### Phase 1 — Classify and orient

-

- 1. Identify the task type: new feature, bug fix, refactor, integration, migration, or performance work. Each type has different risk and testing needs.

- 2. Read nearby code, tests, docs, and conventions before editing anything. Understand the current extension points and naming patterns.

- 3. Check if the change has security, performance, or data-migration implications — flag these before implementing.

-

- ### Phase 2 — Plan

-

- 4. For meaningful changes, write a short implementation plan:

- - What changes and where?

- - What stays the same?

- - What is the test strategy?

- - What is the rollback strategy?

- - Are there feature flags needed for risky changes?

- - What check proves each step? Turn a vague task into a verifiable goal:

-

- | Vague task | Verifiable goal |

- |---|---|

- | Add validation | Write tests for invalid inputs, then make them pass |

- | Fix the bug | Write a test that reproduces it, then make it pass |

- | Refactor X | Tests pass before and after; no behavior change |

- | Speed up the query | EXPLAIN ANALYZE shows X ms before, Y ms after; pick the threshold |

- | Make it more secure | Name the threat model; write tests that prove the mitigation works |

-

- ### Phase 3 — Test-guide, then implement

-

- 5. **For bug fixes**: Write a failing test that reproduces the bug before fixing it. The test should pass when the fix is correct.

- 6. **For new behavior**: Write the test or acceptance criteria first, then implement to make it pass.

- 7. **For refactors**: Ensure existing tests pass before and after — no behavioral change should occur.

- 8. Apply the test pyramid: unit tests for logic, integration tests for behavior at module boundaries, E2E or smoke tests for critical user paths.

- 9. Test error paths, not just happy paths. Test boundary values. Test empty and null states.

- 10. Implement the **smallest safe change** that fits the current architecture. Flag scope creep.

-

- ### Phase 4 — Review the diff

-

- 11. Before marking done, review your own diff:

- - Correctness: does it do what it claims?

- - Scope: every changed line traces to the request. No drive-by reformatting or renames; mention unrelated dead code instead of deleting it, but remove what your own change orphaned.

- - Regressions: does it break anything nearby?

- - Security: any new trust boundaries, secrets exposure, or auth gaps?

- - Business logic: are the rules encoded correctly?

- - Missing tests: are edge cases, failure paths, and the bug path covered?

- - Observability: is there logging or metrics for this in production?

-

- ### Phase 5 — Verify and apply the Definition of Done

-

- Run the full DoD checklist before declaring the task complete. **Do not declare done until every item passes.**

-

- **Files applied:**

- - [ ] Every file change is written to disk — not drafted in a code block, actually saved

- - [ ] No planned change is missing from the applied set

-

- **Correctness:**

- - [ ] Re-read the original requirement verbatim — implementation satisfies it exactly

- - [ ] Edge cases covered: empty input, null/undefined, boundary values, error paths

- - [ ] No regressions: adjacent behavior unchanged or intentionally changed and documented

-

- **Verification run:**

- - [ ] Build/compile passes without errors

- - [ ] All affected tests pass — run them, do not assume

- - [ ] Lint/type checks pass if applicable

- - [ ] Migrations are backwards-compatible; deployment order is safe

-

- **Triple-check:**

- - [ ] Implementation re-read from the actual saved file — not from memory, not from the conversation

- - [ ] Self-diff review: the change does exactly what it claims, no more, no less

- - [ ] If new tests were written: they actually run and pass

-

- **Security minimum:**

- - [ ] No new trust boundaries without validation

- - [ ] No secrets hardcoded or logged

- - [ ] Auth/permissions unchanged or explicitly reviewed

-

- **Rollback and handoff:**

- - [ ] Rollback path confirmed: can this be reverted or feature-flagged off without data loss?

- - [ ] Anything that could NOT be verified is named explicitly — do not silently omit gaps

-

- **If any item fails: fix it, then re-run the checklist. Never declare done with failing items.**

-

- ## Product evidence and recovery

-

- - For a changed user journey, CLI, or integration, use `bosskuai-product-verification` to exercise the real path with safe test data. A unit-test pass does not prove an unrun journey works.

- - Keep a project launch recipe: prerequisites, startup command, readiness signal, inputs, expected behavior, evidence, and cleanup.

- - If repeated attempts invalidate the plan, record the failure evidence and re-plan. Do not keep appending failed experiments indefinitely; preserve a targeted handoff before a context reset.

-

-

- ## Supporting artifacts

-

- - **ADR writing**: For non-obvious architecture choices, use lightweight ADR format: Context → Decision → Consequences. Store in the project's ADR directory.

- - **Standup summaries**: Consolidate recent commits and PRs into structured team updates: what shipped, what's in progress, what's blocked.

- - **Incident postmortems**: Blameless format: timeline, root cause, contributing factors, action items with owners and due dates.

- - **Technical documentation**: Generate and refine API docs, runbooks, and architecture diagrams alongside implementation — not after.

-

- ## Feature flags

-

- Use feature flags when:

- - The change affects a significant user-facing surface

- - The change has high rollback risk

- - You want to test with a subset of users first

- - The change has dependencies on other unreleased work

-

- ## Rollback strategy

-

- Every meaningful change should have a rollback answer:

- - **Feature flag**: disable the flag to revert behavior without code deployment

- - **Migration**: ensure the new schema works with the old code; deploy code first, migrate second; only drop old columns in a later release

- - **Service change**: verify old clients still work during the transition window

-

- ## Guardrails

-

- - Do not declare done until the full Definition of Done checklist passes — "it works on my machine" is not done.

- - Do not mix feature work and refactoring in the same PR — separate commits keep rollback clean.

- - Do not skip test-guide for bug fixes — a failing test that reproduces the bug is the proof the fix is real.

-

- ## Output format

-

- ```

- Task classification: [type + risk level]

- Implementation plan: [what changes, where, test strategy, rollback]

- Test strategy: [unit/integration/E2E breakdown, what is tested, what is not]

- Security-sensitive areas: [if any]

-

- Definition of Done — status:

- Files applied: [✅ all saved / ❌ missing: list]

- Requirement satisfied: [✅ confirmed / ❌ gap: describe]

- Edge cases checked: [✅ / ❌ unchecked: list]

- Build/tests pass: [✅ / ❌ failing: describe]

- Triple-check done: [✅ re-read from file / ❌]

- Self-diff review: [✅ clean / ❌ issue found: describe]

- Security minimum: [✅ / ❌ gap: describe]

- Rollback strategy: [feature flag / migration safety / revert path]

- Residual risks or gaps: [what could not be verified — named explicitly]

- ```

- ## References

- - `../../references/checklists/engineering-delivery-checklist.md`

- - `../../references/checklists/coding-best-practices-checklist.md`

- - `../../references/checklists/security-risk-checklist.md`

- - `../../references/checklists/verification-checklist.md`

- - `../../references/playbooks/verification-playbook.md` — validating a change is ready to hand off