Skip to content

Commit 17483a0

Browse files
dgarrosdgarros
authored
Merge pull request #1126 from opsmill/stable
Merge stable into develop
2 parents 27b624c + 117d811 commit 17483a0

89 files changed

Lines changed: 10822 additions & 47 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎.agents/commands/speckit.critique.run.md‎

Lines changed: 242 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,242 @@
1+
---
2+
description: Perform a dual-lens critical review of the specification and plan from
3+
both product strategy and engineering risk perspectives before implementation.
4+
scripts:
5+
sh: .specify/scripts/bash/check-prerequisites.sh --json --include-tasks
6+
ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json -IncludeTasks
7+
---
8+
9+
10+
<!-- Extension: critique -->
11+
<!-- Config: .specify/extensions/critique/ -->
12+
## User Input
13+
14+
```text
15+
$ARGUMENTS
16+
```
17+
18+
You **MUST** consider the user input before proceeding (if not empty).
19+
20+
## Pre-Execution Checks
21+
22+
**Check for extension hooks (before critique)**:
23+
- Check if `.specify/extensions.yml` exists in the project root.
24+
- If it exists, read it and look for entries under the `hooks.before_critique` key
25+
- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
26+
- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
27+
- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
28+
- If the hook has no `condition` field, or it is null/empty, treat the hook as executable
29+
- If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
30+
- For each executable hook, output the following based on its `optional` flag:
31+
- **Optional hook** (`optional: true`):
32+
```
33+
## Extension Hooks
34+
35+
**Optional Pre-Hook**: {extension}
36+
Command: `/{command}`
37+
Description: {description}
38+
39+
Prompt: {prompt}
40+
To execute: `/{command}`
41+
```
42+
- **Mandatory hook** (`optional: false`):
43+
```
44+
## Extension Hooks
45+
46+
**Automatic Pre-Hook**: {extension}
47+
Executing: `/{command}`
48+
EXECUTE_COMMAND: {command}
49+
50+
Wait for the result of the hook command before proceeding to the Outline.
51+
```
52+
- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently
53+
54+
## Goal
55+
56+
Challenge the specification and implementation plan through two distinct expert lenses BEFORE committing to implementation. The **Product Lens** evaluates whether the right problem is being solved in the right way for users. The **Engineering Lens** evaluates whether the technical approach is sound, scalable, and free of hidden risks. This dual review prevents costly mid-implementation pivots and catches strategic and technical blind spots early.
57+
58+
## Operating Constraints
59+
60+
**STRICTLY READ-ONLY FOR EXISTING ARTIFACTS**: During this command, do **not** directly modify existing project files such as `spec.md`, `plan.md`, or other source/docs. You **may** create a new critique report under `FEATURE_DIR/critiques/critique-{timestamp}.md`. Propose, but do not apply, edits to `spec.md`/`plan.md`; applying any changes requires explicit user approval in a follow-up step or command after the user reviews the findings.
61+
62+
**CONSTRUCTIVE CHALLENGE**: The goal is to strengthen the spec and plan, not to block progress. Every critique item must include a constructive suggestion for improvement.
63+
64+
**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) defines non-negotiable principles. Any spec/plan element conflicting with the constitution is automatically a 🎯 Must-Address item.
65+
66+
## Outline
67+
68+
1. Run `.specify/scripts/bash/check-prerequisites.sh --json --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
69+
70+
2. **Load Critique Context**:
71+
- **REQUIRED**: Read `spec.md` for requirements, user stories, and acceptance criteria
72+
- **REQUIRED**: Read `plan.md` for architecture, tech stack, and implementation phases
73+
- **IF EXISTS**: Read `.specify/memory/constitution.md` for governing principles
74+
- **IF EXISTS**: Read `tasks.md` for task breakdown (if already generated)
75+
- **IF EXISTS**: Read previous critique reports in FEATURE_DIR/critiques/ for context
76+
77+
3. **Product Lens Review** (CEO/Product Lead Perspective):
78+
79+
Adopt the mindset of an experienced product leader who cares deeply about user value, market fit, and business impact. Evaluate:
80+
81+
#### 3a. Problem Validation
82+
- Is the problem statement clear and well-defined?
83+
- Is this solving a real user pain point, or is it a solution looking for a problem?
84+
- What evidence supports the need for this feature? (user research, data, customer requests)
85+
- Is the scope appropriate — not too broad (trying to do everything) or too narrow (missing the core value)?
86+
87+
#### 3b. User Value Assessment
88+
- Does every user story deliver tangible user value?
89+
- Are the acceptance criteria written from the user's perspective (outcomes, not implementation)?
90+
- Is the user journey complete — or are there gaps where users would get stuck?
91+
- What's the simplest version that would deliver 80% of the value? (MVP analysis)
92+
- Are there unnecessary features that add complexity without proportional value?
93+
94+
#### 3c. Alternative Approaches
95+
- Could a simpler solution achieve the same outcome?
96+
- Are there existing tools, libraries, or services that could replace custom implementation?
97+
- What would a competitor's approach look like?
98+
- What would happen if this feature were NOT built? What's the cost of inaction?
99+
100+
#### 3d. Edge Cases & User Experience
101+
- What happens when things go wrong? (error states, empty states, loading states)
102+
- How does this feature interact with existing functionality?
103+
- Are accessibility considerations addressed?
104+
- Is the feature discoverable and intuitive?
105+
- What are the onboarding/migration implications for existing users?
106+
107+
#### 3e. Success Measurement
108+
- Are the success criteria measurable and time-bound?
109+
- How will you know if this feature is successful after launch?
110+
- What metrics should be tracked?
111+
- What would trigger a rollback decision?
112+
113+
4. **Engineering Lens Review** (Staff Engineer Perspective):
114+
115+
Adopt the mindset of a senior staff engineer who has seen projects fail due to hidden technical risks. Evaluate:
116+
117+
#### 4a. Architecture Soundness
118+
- Does the architecture follow established patterns for this type of system?
119+
- Are boundaries and interfaces well-defined (separation of concerns)?
120+
- Is the architecture testable at each layer?
121+
- Are there circular dependencies or tight coupling risks?
122+
- Does the architecture support future evolution without major refactoring?
123+
124+
#### 4b. Failure Mode Analysis
125+
- What are the most likely failure modes? (network failures, data corruption, resource exhaustion)
126+
- How does the system degrade gracefully under each failure mode?
127+
- What happens under peak load? Is there a scaling bottleneck?
128+
- What are the blast radius implications — can a failure in this feature affect other parts of the system?
129+
- Are retry, timeout, and circuit-breaker strategies defined?
130+
131+
#### 4c. Security & Privacy Review
132+
- What is the threat model? What attack vectors does this feature introduce?
133+
- Are trust boundaries clearly defined (user input, API responses, third-party data)?
134+
- Is sensitive data handled appropriately (encryption, access control, retention)?
135+
- Are there compliance implications (GDPR, SOC2, HIPAA)?
136+
- Is the principle of least privilege followed?
137+
138+
#### 4d. Performance & Scalability
139+
- Are there potential bottlenecks in the data flow?
140+
- What are the expected data volumes? Will the design handle 10x growth?
141+
- Are caching strategies appropriate and cache invalidation well-defined?
142+
- Are database queries optimized (indexing, pagination, query complexity)?
143+
- Are there resource-intensive operations that should be async or batched?
144+
145+
#### 4e. Testing Strategy
146+
- Is the testing plan comprehensive (unit, integration, E2E)?
147+
- Are the critical paths identified for priority testing?
148+
- Is the test data strategy realistic?
149+
- Are there testability concerns (hard-to-mock dependencies, race conditions)?
150+
- Is the test coverage target appropriate for the risk level?
151+
152+
#### 4f. Operational Readiness
153+
- Is observability planned (logging, metrics, tracing)?
154+
- Are alerting thresholds defined?
155+
- Is there a rollback strategy?
156+
- Are database migrations reversible?
157+
- Is the deployment strategy clear (blue-green, canary, feature flags)?
158+
159+
#### 4g. Dependencies & Integration Risks
160+
- Are third-party dependencies well-understood (stability, licensing, maintenance)?
161+
- Are integration points with existing systems well-defined?
162+
- What happens if an external service is unavailable?
163+
- Are API versioning and backward compatibility considered?
164+
165+
5. **Cross-Lens Synthesis**:
166+
Identify items where both lenses converge (these are highest priority):
167+
- Product simplification that also reduces engineering risk
168+
- Engineering constraints that affect user experience
169+
- Scope adjustments that improve both value delivery and technical feasibility
170+
171+
6. **Severity Classification**:
172+
Classify each finding:
173+
174+
- 🎯 **Must-Address**: Blocks proceeding to implementation. Critical product gap, security vulnerability, architecture flaw, or constitution violation. Must be resolved before `/speckit.tasks`.
175+
- 💡 **Recommendation**: Strongly suggested improvement that would significantly improve quality, value, or risk profile. Should be addressed but won't block progress.
176+
- 🤔 **Question**: Ambiguity or assumption that needs stakeholder input. Cannot be resolved by the development team alone.
177+
178+
7. **Generate Critique Report**:
179+
Ensure the directory `FEATURE_DIR/critiques/` exists (create it if necessary), then create the critique report at `FEATURE_DIR/critiques/critique-{timestamp}.md` using `.specify/templates/critique-template.md` as the required structure. The report must include:
180+
181+
- **Executive Summary**: Overall assessment and readiness to proceed
182+
- **Product Lens Findings**: Organized by subcategory (3a-3e)
183+
- **Engineering Lens Findings**: Organized by subcategory (4a-4g)
184+
- **Cross-Lens Insights**: Items where both perspectives converge
185+
- **Findings Summary Table**: All items with ID, lens, severity, summary, suggestion
186+
187+
**Findings Table Format**:
188+
| ID | Lens | Severity | Category | Finding | Suggestion |
189+
|----|------|----------|----------|---------|------------|
190+
| P1 | Product | 🎯 | Problem Validation | No evidence of user need | Conduct 5 user interviews or reference support tickets |
191+
| E1 | Engineering | 💡 | Failure Modes | No retry strategy for API calls | Add exponential backoff with circuit breaker |
192+
| X1 | Both | 🎯 | Scope × Risk | Feature X adds complexity with unclear value | Defer to v2; reduces both scope and technical risk |
193+
194+
8. **Provide Verdict**:
195+
Based on findings, provide one of:
196+
- ✅ **PROCEED**: No must-address items. Spec and plan are solid. Run `/speckit.tasks` to proceed.
197+
- ⚠️ **PROCEED WITH UPDATES**: Must-address items found but are resolvable. Offer to apply fixes to spec/plan, then proceed.
198+
- 🛑 **RETHINK**: Fundamental product or architecture concerns. Recommend revisiting the spec with `/speckit.specify` or the plan with `/speckit.plan`.
199+
200+
9. **Offer Remediation**:
201+
For each must-address item and recommendation:
202+
- Provide a specific suggested edit to `spec.md` or `plan.md`
203+
- Ask: "Would you like me to apply these changes? (all / select / none)"
204+
- If user approves, apply changes to the relevant files
205+
- After applying changes, recommend re-running `/speckit.critique` to verify
206+
207+
## Post-Critique Actions
208+
209+
Suggest next steps based on verdict:
210+
- If PROCEED: "Run `/speckit.tasks` to break the plan into actionable tasks"
211+
- If PROCEED WITH UPDATES: "Review the suggested changes, then run `/speckit.tasks`"
212+
- If RETHINK: "Consider running `/speckit.specify` to refine the spec or `/speckit.plan` to revise the architecture"
213+
214+
**Check for extension hooks (after critique)**:
215+
- Check if `.specify/extensions.yml` exists in the project root.
216+
- If it exists, read it and look for entries under the `hooks.after_critique` key
217+
- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
218+
- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
219+
- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
220+
- If the hook has no `condition` field, or it is null/empty, treat the hook as executable
221+
- If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
222+
- For each executable hook, output the following based on its `optional` flag:
223+
- **Optional hook** (`optional: true`):
224+
```
225+
## Extension Hooks
226+
227+
**Optional Hook**: {extension}
228+
Command: `/{command}`
229+
Description: {description}
230+
231+
Prompt: {prompt}
232+
To execute: `/{command}`
233+
```
234+
- **Mandatory hook** (`optional: false`):
235+
```
236+
## Extension Hooks
237+
238+
**Automatic Hook**: {extension}
239+
Executing: `/{command}`
240+
EXECUTE_COMMAND: {command}
241+
```
242+
- If no hooks are registered or `.specify/extensions.yml` does not exist, skip silently

‎.agents/commands/speckit.opsmill.auto.md‎

Lines changed: 76 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
---
2+
description: Run the full speckit workflow end-to-end — specify, plan, critique, tasks,
3+
implement, review — making all decisions autonomously. Stops before extract; run
4+
that manually.
5+
---
6+
7+
8+
<!-- Extension: opsmill -->
9+
<!-- Config: .specify/extensions/opsmill/ -->
10+
## User Input
11+
12+
```text
13+
$ARGUMENTS
14+
```
15+
16+
You **MUST** consider the user input before proceeding (if not empty).
17+
18+
## Outline
19+
20+
You are running the **full speckit pipeline** end-to-end. The user's input (above) is the feature description that will seed the specification phase.
21+
22+
This skill is a thin orchestrator over two sibling skills:
23+
24+
- `speckit-opsmill-prep` — Specify → Plan → Critique → Tasks (+ spec/ask alignment check)
25+
- `speckit-opsmill-implement` — Implement → Review → Final report
26+
27+
Run them back-to-back, making all decisions autonomously. Do not stop to ask the user for input between phases — if a sub-phase requires choices (clarification questions in specify, research decisions in plan, drift remediation in alignment), use your best judgment and proceed. The user expects a hands-off, one-shot execution. Extraction (`speckit-opsmill-extract`) is **not** run by this command — the user invokes it manually after reviewing the implementation report.
28+
29+
> Each phase below is executed by invoking the named skill (e.g. via the agent's Skill tool). Skills are agent-agnostic, so this workflow runs identically across any harness that supports skill discovery — not only those exposing speckit slash commands.
30+
31+
### Phase A — Preparation (delegated to `speckit-opsmill-prep`)
32+
33+
Invoke the `speckit-opsmill-prep` skill with the user's feature description (`$ARGUMENTS`) verbatim.
34+
35+
- This covers Specify → Plan → Critique → Tasks **and** the trailing spec/ask alignment check.
36+
- The sub-skill commits its own artifacts after each phase via `speckit-checkpoint-commit`.
37+
- If the alignment check inside prep loops (re-running plan/critique/tasks to fix spec drift), let it run to completion. Do not interfere.
38+
39+
**Read prep's status line.** `speckit-opsmill-prep` ends its output with a literal final line:
40+
41+
`STATUS: <READY|BLOCKED> | SPEC_DIR: <absolute spec-dir path> | REASON: <...>`
42+
43+
Parse that line — do **not** infer success from the prose summary:
44+
45+
- Take **`SPEC_DIR`** from this line as the spec directory to pass to Phase B. This is the deterministic hand-off; do not scrape the path out of free text.
46+
- If **`STATUS: BLOCKED`** (e.g., alignment never converged within its retry budget, or a phase could not complete), surface the reason to the user and **stop**. Do **not** proceed to implementation on a misaligned or incomplete spec.
47+
- Only proceed to Phase B when `STATUS: READY`.
48+
49+
### Phase B — Implementation tail (delegated to `speckit-opsmill-implement`)
50+
51+
Invoke the `speckit-opsmill-implement` skill with the `SPEC_DIR` path from Phase A as its argument. Because you pass an explicit spec-dir path, the sub-skill runs in **autonomous-parent** mode: its Phase 0 stop-conditions abort with a `STATUS: BLOCKED` line instead of pausing for a user.
52+
53+
- This covers Phase 0 (Preflight) → Phase 5 (Implement loop in clean-context subagents) → Phase 6 (Review) → Phase 7 (Final report).
54+
- The sub-skill writes `<spec-dir>/opsmill-implement-report.md` and commits it.
55+
56+
**Read implement's status line.** `speckit-opsmill-implement` ends its output with a literal final line:
57+
58+
`STATUS: <DONE|INCOMPLETE|BLOCKED> | SPEC_DIR: <...> | REASON: <...>`
59+
60+
- `STATUS: BLOCKED` — a Phase 0 stop-condition aborted before any implementation (no report written). Surface the reason in the final summary; do not retry from this orchestrator.
61+
- `STATUS: INCOMPLETE` — blocked tasks or missing local-pass evidence; capture that for the final summary. The user decides whether to re-run.
62+
- `STATUS: DONE` — all chunks completed with evidence.
63+
64+
In every case, do **not** retry from this orchestrator.
65+
66+
## Completion
67+
68+
After both phases are complete, provide a brief summary:
69+
70+
- Feature name and spec directory
71+
- Whether the alignment check inside auto-prep required retries (and how many)
72+
- Number of tasks completed (from the auto-implement report)
73+
- Any review findings that were fixed inline vs. deferred
74+
- Any notable decisions you or the sub-skills made autonomously
75+
76+
Do **not** open a PR, push, run extraction, or start a new feature. The user takes it from there — extraction (`/speckit.opsmill.extract`) is intentionally left as a manual follow-up so the user can review the implementation report first.

0 commit comments

Comments
 (0)