mirror of https://github.com/norandom/OpenUltraSAST.git synced 2026-10-16 03:49:26 +00:00

Files

T

Marius CiepluchandClaude Opus 4.8 6699f1f8f9 chore: add kiro spec-driven tooling and steering docs

Add the Kiro-style agentic SDLC tooling used to drive this project: the
.opencode/skills/kiro-* skill set (discovery, spec init/requirements/design/
tasks, validation, implementation, review, steering), the .kiro/settings
templates, and AGENTS.md describing the workflow. Update the spec docs
(assessment/design/requirements/tasks) to current state.

Scope tests/test_opencode_skills.py to the project's own openultrasast-*
skills so the third-party kiro-* tooling (which uses a different frontmatter
convention) no longer breaks the frontmatter check.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

2026-06-21 14:28:19 +02:00

2.8 KiB

Raw Blame History

name, description

name	description
kiro-spec-status	Show specification status and progress

Specification Status

<background_information>

Success Criteria:
- Show current phase and completion status
- Identify next actions and blockers
- Provide clear visibility into progress
- Surface boundary readiness, upstream/downstream context, and likely revalidation needs when available </background_information>

## Execution Steps

Step 1: Load Spec Context

Read .kiro/specs/$1/spec.json for metadata and phase status
Read .kiro/specs/$1/brief.md if it exists
Read existing files: requirements.md, design.md, tasks.md (if they exist)
Check .kiro/specs/$1/ directory for available files
Read .kiro/steering/roadmap.md if it exists and this spec appears in it

Step 2: Analyze Status

Parse each phase:

Requirements: Count requirements and acceptance criteria
Design: Check for architecture, components, diagrams, and whether boundary sections are present
Tasks: Count completed vs total tasks (parse - [x] vs - [ ])
Approvals: Check approval status in spec.json
Boundary context:
- From brief.md: note Boundary Candidates, Upstream / Downstream, and Existing Spec Touchpoints if present
- From design.md: note Boundary Commitments, Out of Boundary, Allowed Dependencies, and Revalidation Triggers if present
- From roadmap.md: note upstream dependencies and whether this spec is adjacent to Existing Spec Updates
Revalidation watchlist:
- Identify downstream specs, neighboring existing-spec updates, or rollout-sensitive design notes that may need revalidation if this spec changes
- Call out when the current spec shape looks too broad and may want roadmap/design splitting instead of more local repair

Step 3: Generate Report

Create report in the language specified in spec.json covering:

Current Phase & Progress: Where the spec is in the workflow
Completion Status: Percentage complete for each phase
Task Breakdown: If tasks exist, show completed/remaining counts
Boundary Context: Upstream/downstream, out-of-boundary, and allowed dependency notes when available
Revalidation Watchlist: Downstream or adjacent work likely affected by changes to this spec
Next Actions: What needs to be done next
Blockers: Any issues preventing progress

Safety & Fallback

Error Scenarios

Spec Not Found:

Message: "No spec found for $1. Check available specs in .kiro/specs/"
Action: List available spec directories

Incomplete Spec:

Warning: Identify which files are missing
Suggested Action: Point to next phase command

List All Specs

To see all available specs:

Run with no argument or use wildcard
Shows all specs in .kiro/specs/ with their status

2.8 KiB Raw Blame History