Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,16 @@ Release history for the `opsmill` spec-kit extension (`extension.yml`).
The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this artifact adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Changed
- `speckit.opsmill.prep` Phase 2 (Plan) gains a research directive for
constrained third-party dependencies: when a dependency lacks a capability
the feature needs, the research phase must evaluate the dependency's
extension mechanism and upstream contribution before designing a
workaround, and record the decision in `research.md`. Applies to
`speckit.opsmill.auto` as well via its delegation to prep.

## [1.1.0] - 2026-06-19

### Added
Expand Down
5 changes: 5 additions & 0 deletions commands/prep.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,11 @@ Invoke the `speckit-specify` skill with the user's feature description (`$ARGUME
Invoke the `speckit-plan` skill.

- Complete the full plan workflow: research unknowns, generate `plan.md`, `research.md`, `data-model.md`, API contracts, `quickstart.md`.
- **Research directive — constrained third-party dependencies.** If the feature depends on a third-party library or tool that does not support something the implementation needs, you MUST evaluate extending that dependency before designing around the gap:
- Check for a built-in extension mechanism (plugin system, hooks, middleware, custom providers, etc.) that could supply the missing capability.
- Consider an upstream contribution (patch, feature PR) when no extension mechanism fits.
- Record the evaluation in `research.md` as an explicit decision: the chosen approach, the rationale, and the extension/upstream alternatives that were rejected and why.
- Only fall back to working around the limitation in our own codebase when both routes are infeasible (e.g., unmaintained upstream, unacceptable timeline) — and record why. The point is to avoid overly complex implementations whose only cause is a dependency gap that the dependency itself was designed to let you fill.
- Make all design decisions autonomously.
- Commit the plan artifacts.

Expand Down