mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-20 05:29:28 +00:00
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]>
This commit is contained in:
Marius Ciepluch
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
8fe8911020
commit
6699f1f8f9
@@ -0,0 +1,171 @@
|
||||
---
|
||||
name: kiro-review
|
||||
description: Review a task implementation against approved specs, task boundaries, and verification evidence. Use after an implementer finishes a task, after remediation, or before accepting a task as complete.
|
||||
---
|
||||
|
||||
# kiro-review
|
||||
|
||||
<background_information>
|
||||
This skill performs task-local adversarial review. It verifies that the implementation is real, complete, bounded, aligned with approved requirements and design, and supported by mechanical verification evidence.
|
||||
|
||||
Boundary terminology continuity:
|
||||
- discovery identifies `Boundary Candidates`
|
||||
- design fixes `Boundary Commitments`
|
||||
- tasks constrain execution with `_Boundary:_`
|
||||
- review rejects concrete `Boundary Violations`
|
||||
</background_information>
|
||||
|
||||
<instructions>
|
||||
## When to Use
|
||||
|
||||
- After an implementer reports `READY_FOR_REVIEW`
|
||||
- After remediation for a rejected review
|
||||
- Before marking a task `[x]`
|
||||
- Before accepting a task into feature-level validation
|
||||
|
||||
Do not use this skill to invent missing requirements or silently reinterpret the spec.
|
||||
|
||||
## Inputs
|
||||
|
||||
Provide:
|
||||
- Task ID and exact task text from `tasks.md`
|
||||
- Relevant requirement section numbers
|
||||
- Relevant design section numbers
|
||||
- Spec file paths (`requirements.md`, `design.md`, optionally `tasks.md`)
|
||||
- The implementer's status report
|
||||
- The task `_Boundary:_` scope constraints
|
||||
- Validation commands discovered by the controller
|
||||
- Relevant steering excerpts when applicable
|
||||
- Relevant `## Implementation Notes` entries when applicable
|
||||
|
||||
## Outputs
|
||||
|
||||
Return one of:
|
||||
- `APPROVED`
|
||||
- `REJECTED`
|
||||
|
||||
Also return:
|
||||
- Mechanical results
|
||||
- Findings with severity
|
||||
- Required remediation
|
||||
- One-sentence summary
|
||||
|
||||
Use the language specified in `spec.json`.
|
||||
|
||||
## First Action
|
||||
|
||||
Run `git diff` to inspect the actual code changes. If the diff is large or ambiguous, read the changed files directly. Do not trust the implementer report as source of truth.
|
||||
|
||||
## Core Principle
|
||||
|
||||
Read the spec yourself. Read the diff yourself. Verify mechanically where possible. Reject on concrete failures rather than interpretive optimism.
|
||||
The main review question is not just "does it work?" but "does it stay inside the approved responsibility boundary without hiding new coupling?"
|
||||
|
||||
## Mechanical Checks
|
||||
|
||||
Run these checks and use the result as primary signal.
|
||||
|
||||
### 1. Regression Safety
|
||||
- Run the project's canonical test suite using the validation commands discovered by the controller.
|
||||
- If tests fail, reject.
|
||||
|
||||
### 2. No Residual Placeholder Markers
|
||||
- Check changed files for `TBD`, `TODO`, `FIXME`, `HACK`, `XXX`.
|
||||
- Reject if new placeholder markers were introduced without explicit task justification.
|
||||
|
||||
### 3. No Hardcoded Secrets
|
||||
- Check changed files for hardcoded secrets or credentials.
|
||||
- Reject if concrete secret patterns are introduced.
|
||||
|
||||
### 4. Boundary Respect
|
||||
- Compare changed files against the task `_Boundary:_` scope.
|
||||
- Reject if the change spills outside the approved boundary without explicit justification.
|
||||
- Reject if the implementation introduces hidden cross-boundary coordination inside what should be a local task.
|
||||
|
||||
### 5. RED Phase Evidence
|
||||
- For behavioral tasks, verify that the implementer status report includes `RED_PHASE_OUTPUT`.
|
||||
- Reject if RED evidence is missing, empty, or unrelated to the task's acceptance criteria.
|
||||
|
||||
### 6. Runtime-Sensitive Static Checks
|
||||
- If the project already has lint or equivalent static analysis for the touched stack, run the relevant command for the task boundary.
|
||||
- Pay attention to patterns that can survive typecheck/build yet fail at runtime: type-only imports used as values, missing namespace value imports for qualified-name access, unresolved globals, and newly introduced runtime-sensitive dependencies without matching boot/runtime handling.
|
||||
- If no project lint command exists, perform a targeted diff-based spot check in the changed files for those patterns.
|
||||
- Reject on concrete findings that create a realistic boot-time or module-load failure.
|
||||
|
||||
## Judgment Checks
|
||||
|
||||
### 7. Reality Check
|
||||
- Confirm the implementation is real production code, not a placeholder, stub, fake path, or deferred-work shell.
|
||||
|
||||
### 8. Acceptance Criteria Coverage
|
||||
- Read the task description and confirm all aspects are implemented, not only the primary happy path.
|
||||
|
||||
### 9. Requirements Alignment
|
||||
- Read the referenced sections in `requirements.md`.
|
||||
- Confirm each requirement is satisfied by concrete observable behavior.
|
||||
- Use original section numbers only.
|
||||
|
||||
### 10. Design Alignment
|
||||
- Read the referenced sections in `design.md`.
|
||||
- Confirm the implementation uses the prescribed structures, interfaces, and dependency direction.
|
||||
- Reject silent substitutions for design-mandated choices.
|
||||
|
||||
### 10.5 Boundary Audit
|
||||
- Compare the implementation against the design's boundary commitments and out-of-boundary statements.
|
||||
- Reject if downstream-specific behavior is pushed into an upstream boundary for convenience.
|
||||
- Reject if the implementation creates new hidden dependencies, shared ownership, or undeclared coupling across adjacent boundaries.
|
||||
- Reject if a task that is not an explicit integration task now behaves like one.
|
||||
|
||||
### 11. Test Quality
|
||||
- Confirm tests prove the required behavior rather than only scaffolding.
|
||||
- Confirm tests would fail if the implementation were removed or broken.
|
||||
|
||||
### 12. Error Handling
|
||||
- Confirm relevant failure paths are handled and not silently swallowed.
|
||||
|
||||
## Severity Model
|
||||
|
||||
Use:
|
||||
- `Critical` for broken functionality, invalid verification, data loss, security risk, or major scope violation
|
||||
- `Important` for required fixes before acceptance
|
||||
- `Suggestion` for non-blocking improvements
|
||||
- `FYI` for informational notes
|
||||
|
||||
## Stop / Escalate
|
||||
|
||||
Escalate instead of papering over the issue when:
|
||||
- The approved spec is ambiguous in a correctness-critical way
|
||||
- The design conflicts with what is technically possible
|
||||
- Required evidence cannot be gathered
|
||||
- The implementation only works by silently deviating from approved scope
|
||||
- Boundary ownership cannot be determined cleanly from requirements, design, and task scope
|
||||
|
||||
## Common Rationalizations
|
||||
|
||||
| Rationalization | Reality |
|
||||
|---|---|
|
||||
| “Tests pass, so approve” | Passing tests do not prove spec compliance or boundary respect. |
|
||||
| “The extra behavior is useful” | Extra behavior outside approved scope is still drift. |
|
||||
| “The implementer said RED was done” | RED must be evidenced, not asserted. |
|
||||
| “This gap is small enough to let through” | Real gaps must be rejected or escalated. |
|
||||
|
||||
## Output Format
|
||||
|
||||
```md
|
||||
## Review Verdict
|
||||
- VERDICT: APPROVED | REJECTED
|
||||
- TASK: <task-id>
|
||||
- MECHANICAL_RESULTS:
|
||||
- Tests: PASS | FAIL (command and exit code)
|
||||
- TBD/TODO grep: CLEAN | <count> matches
|
||||
- Secrets grep: CLEAN | <count> matches
|
||||
- Static checks: PASS | FAIL | SPOT_CHECKED
|
||||
- Boundary: WITHIN | <files outside boundary>
|
||||
- Boundary audit: CLEAN | <spillover / hidden dependency findings>
|
||||
- RED phase: VERIFIED | MISSING | N/A
|
||||
- FINDINGS:
|
||||
1. <specific finding with exact files/spec refs>
|
||||
- REMEDIATION: <mandatory if REJECTED>
|
||||
- SUMMARY: <one sentence>
|
||||
```
|
||||
</instructions>
|
||||
@@ -0,0 +1,6 @@
|
||||
interface:
|
||||
display_name: "Review Task"
|
||||
short_description: "Review task implementation against spec, design, and evidence"
|
||||
|
||||
policy:
|
||||
allow_implicit_invocation: false
|
||||
Reference in New Issue
Block a user