mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-16 19:59:26 +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]>
68 lines
3.9 KiB
Markdown
68 lines
3.9 KiB
Markdown
# Agentic SDLC and Spec-Driven Development
|
|
|
|
Kiro-style Spec-Driven Development on an agentic SDLC
|
|
|
|
## Project Memory
|
|
Project memory keeps persistent guidance (steering, specs notes, component docs) so OpenCode honors your standards each run. Treat it as the long-lived source of truth for patterns, conventions, and decisions.
|
|
|
|
- Use `.kiro/steering/` for project-wide policies: architecture principles, naming schemes, security constraints, tech stack decisions, api standards, etc.
|
|
- Use local `AGENTS.md` files for feature or library context (e.g. `src/lib/payments/AGENTS.md`): describe domain assumptions, API contracts, or testing conventions specific to that folder. OpenCode auto-loads these when working in the matching path.
|
|
- Specs notes stay with each spec (under `.kiro/specs/`) to guide specification-level workflows.
|
|
|
|
## Project Context
|
|
|
|
### Paths
|
|
- Steering: `.kiro/steering/`
|
|
- Specs: `.kiro/specs/`
|
|
|
|
### Steering vs Specification
|
|
|
|
**Steering** (`.kiro/steering/`) - Guide AI with project-wide rules and context
|
|
**Specs** (`.kiro/specs/`) - Formalize development process for individual features
|
|
|
|
### Active Specifications
|
|
- Check `.kiro/specs/` for active specifications
|
|
- Use `/kiro-spec-status [feature-name]` to check progress
|
|
|
|
## Development Guidelines
|
|
- Think in English, generate responses in English. All Markdown content written to project files (e.g., requirements.md, design.md, tasks.md, research.md, validation reports) MUST be written in the target language configured for this specification (see spec.json.language).
|
|
|
|
## Minimal Workflow
|
|
- Phase 0 (optional): `/kiro-steering`, `/kiro-steering-custom`
|
|
- Discovery: `/kiro-discovery "idea"` — determines action path, writes brief.md + roadmap.md for multi-spec projects
|
|
- Phase 1 (Specification):
|
|
- Single spec: `/kiro-spec-quick {feature} [--auto]` or step by step:
|
|
- `/kiro-spec-init "description"`
|
|
- `/kiro-spec-requirements {feature}`
|
|
- `/kiro-validate-gap {feature}` (optional: for existing codebase)
|
|
- `/kiro-spec-design {feature} [-y]`
|
|
- `/kiro-validate-design {feature}` (optional: design review)
|
|
- `/kiro-spec-tasks {feature} [-y]`
|
|
- Multi-spec: `/kiro-spec-batch` — creates all specs from roadmap.md in parallel by dependency wave
|
|
- Phase 2 (Implementation): `/kiro-impl {feature} [tasks]`
|
|
- Without task numbers: autonomous mode (subagent per task + independent review + final validation)
|
|
- With task numbers: manual mode (selected tasks in main context, still reviewer-gated before completion)
|
|
- `/kiro-validate-impl {feature}` (standalone re-validation)
|
|
- Progress check: `/kiro-spec-status {feature}` (use anytime)
|
|
|
|
## Skills Structure
|
|
Skills are located in `.opencode/skills/kiro-*/SKILL.md`
|
|
- Each skill is a directory with a `SKILL.md` file
|
|
- Use `/skills` to inspect currently available skills
|
|
- Invoke a skill directly with `/kiro-<skill-name>`
|
|
- **If there is even a 1% chance a skill applies to the current task, invoke it.** Do not skip skills because the task seems simple.
|
|
- `kiro-review` — task-local adversarial review protocol used by reviewer subagents
|
|
- `kiro-debug` — root-cause-first debug protocol used by debugger subagents
|
|
- `kiro-verify-completion` — fresh-evidence gate before success or completion claims
|
|
|
|
## Development Rules
|
|
- 3-phase approval workflow: Requirements → Design → Tasks → Implementation
|
|
- Human review required each phase; use `-y` only for intentional fast-track
|
|
- Keep steering current and verify alignment with `/kiro-spec-status`
|
|
- Follow the user's instructions precisely, and within that scope act autonomously: gather the necessary context and complete the requested work end-to-end in this run, asking questions only when essential information is missing or the instructions are critically ambiguous.
|
|
|
|
## Steering Configuration
|
|
- Load entire `.kiro/steering/` as project memory
|
|
- Default files: `product.md`, `tech.md`, `structure.md`
|
|
- Custom files are supported (managed via `/kiro-steering-custom`)
|