mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-18 20:49:28 +00:00
Marius CiepluchandClaude Opus 4.8
6699f1f8f9
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]>
30 lines
1.8 KiB
Markdown
30 lines
1.8 KiB
Markdown
# Design Synthesis
|
|
|
|
After discovery and before writing the design document, apply these three lenses to the collected findings. This step requires the full picture — do not parallelize.
|
|
|
|
## 1. Generalization
|
|
|
|
Look across all requirements as a group. Identify cases where multiple requirements are variations of the same underlying problem.
|
|
|
|
- If feature A is a special case of a more general capability X, design X with an interface that naturally supports A (and potentially B, C later)
|
|
- Keep the implementation scope to what the current requirements demand — generalize the interface, not the implementation
|
|
- Record identified generalizations in `research.md` under Design Decisions
|
|
|
|
## 2. Build vs. Adopt
|
|
|
|
For each major component in the emerging design, ask: is this problem already solved?
|
|
|
|
- Search for established standards (RFCs, protocols), battle-tested libraries, or platform-native capabilities that address the requirement
|
|
- Prefer adopting existing solutions over building custom ones when they fit the requirements without significant adaptation
|
|
- If adopting: verify the solution is actively maintained, compatible with the project's stack (check steering), and meets non-functional requirements
|
|
- If building: document why existing solutions were rejected (capture in `research.md`)
|
|
|
|
## 3. Simplification
|
|
|
|
For each component and abstraction layer in the emerging design, ask: is this necessary?
|
|
|
|
- Remove components that exist "just in case" or for hypothetical future requirements not in the current spec
|
|
- Flatten unnecessary abstraction layers — if an interface has only one implementation with no foreseeable second, it may not need the indirection
|
|
- Prefer fewer, cohesive components over many fine-grained ones
|
|
- The right design is the smallest one that satisfies all requirements and remains extensible at the interface level
|