Skip to content

Commit a3fe4e0

Browse files
dgarrosdgarros
authored
Merge pull request #52 from opsmill/dga/chore-opsmill-speckit-ngzj6
chore: install speckit critique, review, and opsmill extensions
2 parents f07dc48 + 8956e36 commit a3fe4e0

63 files changed

Lines changed: 8231 additions & 0 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/skills/speckit-critique-run/SKILL.md‎

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

‎.agents/skills/speckit-opsmill-auto/SKILL.md‎

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
---
2+
name: speckit-opsmill-auto
3+
description: Run the full speckit workflow end-to-end — specify, plan, critique, tasks,
4+
implement, review — making all decisions autonomously. Stops before extract; run
5+
that manually.
6+
compatibility: Requires spec-kit project structure with .specify/ directory
7+
metadata:
8+
author: github-spec-kit
9+
source: opsmill:commands/auto.md
10+
---
11+
12+
## User Input
13+
14+
```text
15+
$ARGUMENTS
16+
```
17+
18+
You **MUST** consider the user input before proceeding (if not empty).
19+
20+
## Outline
21+
22+
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.
23+
24+
This skill is a thin orchestrator over two sibling skills:
25+
26+
- `speckit-opsmill-prep` — Specify → Plan → Critique → Tasks (+ spec/ask alignment check)
27+
- `speckit-opsmill-implement` — Implement → Review → Final report
28+
29+
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.
30+
31+
> 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.
32+
33+
### Phase A — Preparation (delegated to `speckit-opsmill-prep`)
34+
35+
Invoke the `speckit-opsmill-prep` skill with the user's feature description (`$ARGUMENTS`) verbatim.
36+
37+
- This covers Specify → Plan → Critique → Tasks **and** the trailing spec/ask alignment check.
38+
- The sub-skill commits its own artifacts after each phase via `speckit-checkpoint-commit`.
39+
- If the alignment check inside prep loops (re-running plan/critique/tasks to fix spec drift), let it run to completion. Do not interfere.
40+
41+
**Read prep's status line.** `speckit-opsmill-prep` ends its output with a literal final line:
42+
43+
`STATUS: <READY|BLOCKED> | SPEC_DIR: <absolute spec-dir path> | REASON: <...>`
44+
45+
Parse that line — do **not** infer success from the prose summary:
46+
47+
- 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.
48+
- 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.
49+
- Only proceed to Phase B when `STATUS: READY`.
50+
51+
### Phase B — Implementation tail (delegated to `speckit-opsmill-implement`)
52+
53+
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.
54+
55+
- This covers Phase 0 (Preflight) → Phase 5 (Implement loop in clean-context subagents) → Phase 6 (Review) → Phase 7 (Final report).
56+
- The sub-skill writes `<spec-dir>/opsmill-implement-report.md` and commits it.
57+
58+
**Read implement's status line.** `speckit-opsmill-implement` ends its output with a literal final line:
59+
60+
`STATUS: <DONE|INCOMPLETE|BLOCKED> | SPEC_DIR: <...> | REASON: <...>`
61+
62+
- `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.
63+
- `STATUS: INCOMPLETE` — blocked tasks or missing local-pass evidence; capture that for the final summary. The user decides whether to re-run.
64+
- `STATUS: DONE` — all chunks completed with evidence.
65+
66+
In every case, do **not** retry from this orchestrator.
67+
68+
## Completion
69+
70+
After both phases are complete, provide a brief summary:
71+
72+
- Feature name and spec directory
73+
- Whether the alignment check inside auto-prep required retries (and how many)
74+
- Number of tasks completed (from the auto-implement report)
75+
- Any review findings that were fixed inline vs. deferred
76+
- Any notable decisions you or the sub-skills made autonomously
77+
78+
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)