mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-19 04:59: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,145 @@
|
||||
---
|
||||
name: kiro-steering-custom
|
||||
description: Create custom steering documents for specialized project contexts
|
||||
metadata:
|
||||
shared-rules: "steering-principles.md"
|
||||
---
|
||||
|
||||
|
||||
# Kiro Custom Steering Creation
|
||||
|
||||
<background_information>
|
||||
**Role**: Create specialized steering documents beyond core files (product, tech, structure).
|
||||
|
||||
**Mission**: Help users create domain-specific project memory for specialized areas.
|
||||
|
||||
**Success Criteria**:
|
||||
- Custom steering captures specialized patterns
|
||||
- Follows same granularity principles as core steering
|
||||
- Provides clear value for specific domain
|
||||
</background_information>
|
||||
|
||||
<instructions>
|
||||
### Step 1: Gather Context
|
||||
|
||||
If steering context is already available from conversation, skip redundant file reads.
|
||||
Otherwise:
|
||||
- Check `.kiro/settings/templates/steering-custom/` for available templates
|
||||
- Read `rules/steering-principles.md` from this skill's directory for steering principles
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Ask user** for custom steering needs:
|
||||
- Domain/topic (e.g., "API standards", "testing approach")
|
||||
- Specific requirements or patterns to document
|
||||
|
||||
2. **Check if template exists**:
|
||||
- Load from `.kiro/settings/templates/steering-custom/{name}.md` if available
|
||||
- Use as starting point, customize based on project
|
||||
|
||||
3. **Analyze codebase** (JIT) for relevant patterns:
|
||||
|
||||
#### Parallel Research
|
||||
|
||||
The following research areas are independent and can be executed in parallel:
|
||||
1. **Template & principles**: Load matching template and steering-principles.md
|
||||
2. **Domain patterns**: Analyze codebase for domain-specific patterns using Glob/Grep/Read
|
||||
|
||||
If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.
|
||||
|
||||
After all parallel research completes, synthesize findings for steering document.
|
||||
|
||||
4. **Generate custom steering**:
|
||||
- Follow template structure if available
|
||||
- Apply principles from `rules/steering-principles.md` from this skill's directory
|
||||
- Focus on patterns, not exhaustive lists
|
||||
- Keep to 100-200 lines (2-3 minute read)
|
||||
|
||||
5. **Create file** in `.kiro/steering/{name}.md`
|
||||
|
||||
## Available Templates
|
||||
|
||||
Templates available in `.kiro/settings/templates/steering-custom/`:
|
||||
|
||||
1. **api-standards.md** - REST/GraphQL conventions, error handling
|
||||
2. **testing.md** - Test organization, mocking, coverage
|
||||
3. **security.md** - Auth patterns, input validation, secrets
|
||||
4. **database.md** - Schema design, migrations, query patterns
|
||||
5. **error-handling.md** - Error types, logging, retry strategies
|
||||
6. **authentication.md** - Auth flows, permissions, session management
|
||||
7. **deployment.md** - CI/CD, environments, rollback procedures
|
||||
|
||||
Load template when needed, customize for project.
|
||||
|
||||
## Steering Principles
|
||||
|
||||
From `rules/steering-principles.md` (in this skill's directory):
|
||||
|
||||
- **Patterns over lists**: Document patterns, not every file/component
|
||||
- **Single domain**: One topic per file
|
||||
- **Concrete examples**: Show patterns with code
|
||||
- **Maintainable size**: 100-200 lines typical
|
||||
- **Security first**: Never include secrets or sensitive data
|
||||
|
||||
</instructions>
|
||||
|
||||
## Tool guidance
|
||||
|
||||
- **Read**: Load template, analyze existing code
|
||||
- **Glob**: Find related files for pattern analysis
|
||||
- **Grep**: Search for specific patterns
|
||||
- **Bash** with `ls`: Understand relevant structure
|
||||
|
||||
**JIT Strategy**: Load template only when creating that type of steering.
|
||||
|
||||
## Output description
|
||||
|
||||
Chat summary with file location (file created directly).
|
||||
|
||||
```
|
||||
✅ Custom Steering Created
|
||||
|
||||
## Created:
|
||||
- .kiro/steering/api-standards.md
|
||||
|
||||
## Based On:
|
||||
- Template: api-standards.md
|
||||
- Analyzed: src/api/ directory patterns
|
||||
- Extracted: REST conventions, error format
|
||||
|
||||
## Content:
|
||||
- Endpoint naming patterns
|
||||
- Request/response format
|
||||
- Error handling conventions
|
||||
- Authentication approach
|
||||
|
||||
Review and customize as needed.
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Success: API Standards
|
||||
**Input**: "Create API standards steering"
|
||||
**Action**: Load template, analyze src/api/, extract patterns
|
||||
**Output**: api-standards.md with project-specific REST conventions
|
||||
|
||||
### Success: Testing Strategy
|
||||
**Input**: "Document our testing approach"
|
||||
**Action**: Load template, analyze test files, extract patterns
|
||||
**Output**: testing.md with test organization and mocking strategies
|
||||
|
||||
## Safety & Fallback
|
||||
|
||||
- **No template**: Generate from scratch based on domain knowledge
|
||||
- **Security**: Never include secrets (load principles)
|
||||
- **Validation**: Ensure doesn't duplicate core steering content
|
||||
|
||||
## Notes
|
||||
|
||||
- Templates are starting points, customize for project
|
||||
- Follow same granularity principles as core steering
|
||||
- All steering files loaded as project memory
|
||||
- Custom files equally important as core files
|
||||
- Avoid documenting agent-specific tooling directories (e.g. `.cursor/`, `.gemini/`, `.claude/`)
|
||||
- Light references to `.kiro/specs/` and `.kiro/steering/` are acceptable; avoid other `.kiro/` directories
|
||||
|
||||
@@ -0,0 +1,90 @@
|
||||
# Steering Principles
|
||||
|
||||
Steering files are **project memory**, not exhaustive specifications.
|
||||
|
||||
---
|
||||
|
||||
## Content Granularity
|
||||
|
||||
### Golden Rule
|
||||
> "If new code follows existing patterns, steering shouldn't need updating."
|
||||
|
||||
### ✅ Document
|
||||
- Organizational patterns (feature-first, layered)
|
||||
- Naming conventions (PascalCase rules)
|
||||
- Import strategies (absolute vs relative)
|
||||
- Architectural decisions (state management)
|
||||
- Technology standards (key frameworks)
|
||||
|
||||
### ❌ Avoid
|
||||
- Complete file listings
|
||||
- Every component description
|
||||
- All dependencies
|
||||
- Implementation details
|
||||
- Agent-specific tooling directories (e.g. `.cursor/`, `.gemini/`, `.claude/`)
|
||||
- Detailed documentation of `.kiro/` metadata directories (settings, automation)
|
||||
|
||||
### Example Comparison
|
||||
|
||||
**Bad** (Specification-like):
|
||||
```markdown
|
||||
- /components/Button.tsx - Primary button with variants
|
||||
- /components/Input.tsx - Text input with validation
|
||||
- /components/Modal.tsx - Modal dialog
|
||||
... (50+ files)
|
||||
```
|
||||
|
||||
**Good** (Project Memory):
|
||||
```markdown
|
||||
## UI Components (`/components/ui/`)
|
||||
Reusable, design-system aligned primitives
|
||||
- Named by function (Button, Input, Modal)
|
||||
- Export component + TypeScript interface
|
||||
- No business logic
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Security
|
||||
|
||||
Never include:
|
||||
- API keys, passwords, credentials
|
||||
- Database URLs, internal IPs
|
||||
- Secrets or sensitive data
|
||||
|
||||
---
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- **Single domain**: One topic per file
|
||||
- **Concrete examples**: Show patterns with code
|
||||
- **Explain rationale**: Why decisions were made
|
||||
- **Maintainable size**: 100-200 lines typical
|
||||
|
||||
---
|
||||
|
||||
## Preservation (when updating)
|
||||
|
||||
- Preserve user sections and custom examples
|
||||
- Additive by default (add, don't replace)
|
||||
- Add `updated_at` timestamp
|
||||
- Note why changes were made
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- Templates are starting points, customize as needed
|
||||
- Follow same granularity principles as core steering
|
||||
- All steering files loaded as project memory
|
||||
- Light references to `.kiro/specs/` and `.kiro/steering/` are acceptable; avoid other `.kiro/` directories
|
||||
- Custom files equally important as core files
|
||||
|
||||
---
|
||||
|
||||
## File-Specific Focus
|
||||
|
||||
- **product.md**: Purpose, value, business context (not exhaustive features)
|
||||
- **tech.md**: Key frameworks, standards, conventions (not all dependencies)
|
||||
- **structure.md**: Organization patterns, naming rules (not directory trees)
|
||||
- **Custom files**: Specialized patterns (API, testing, security, etc.)
|
||||
Reference in New Issue
Block a user