mirror of
https://github.com/norandom/OpenUltraSAST.git
synced 2026-10-17 20:19:29 +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]>
51 lines
3.0 KiB
Markdown
51 lines
3.0 KiB
Markdown
---
|
|
name: kiro-spec-init
|
|
description: Initialize a new specification with detailed project description
|
|
---
|
|
|
|
|
|
# Spec Initialization
|
|
|
|
<instructions>
|
|
## Core Task
|
|
Generate a unique feature name from the project description ($ARGUMENTS) and initialize the specification structure.
|
|
|
|
## Execution Steps
|
|
1. **Check for Brief**: If `.kiro/specs/{feature-name}/brief.md` exists (created by `/kiro-discovery`), read it. The brief contains problem, approach, scope, and constraints from the discovery session. Use this to pre-fill the project description and skip clarification questions that the brief already answers.
|
|
2. **Clarify Intent**: The Project Description in requirements.md must contain three elements: (a) who has the problem, (b) current situation, (c) what should change. If a brief.md exists and covers these, skip to step 3. Otherwise, ask the user to clarify before proceeding. Ask as many questions as needed; do not fill in gaps with your own assumptions.
|
|
3. **Check Uniqueness**: Verify `.kiro/specs/` for naming conflicts. If the directory already exists with only `brief.md` (no `spec.json`), use that directory (discovery created it).
|
|
4. **Create Directory**: `.kiro/specs/[feature-name]/` (skip if already exists from discovery)
|
|
5. **Initialize Files Using Templates**:
|
|
- Read `.kiro/settings/templates/specs/init.json`
|
|
- Read `.kiro/settings/templates/specs/requirements-init.md`
|
|
- Replace placeholders:
|
|
- `{{FEATURE_NAME}}` → generated feature name
|
|
- `{{TIMESTAMP}}` → current ISO 8601 timestamp
|
|
- `{{PROJECT_DESCRIPTION}}` → from brief.md if available, otherwise $ARGUMENTS
|
|
- `en` → language code (detect from user's input language, default to `en`)
|
|
- Write `spec.json` and `requirements.md` to spec directory
|
|
|
|
## Important Constraints
|
|
- Do NOT generate requirements, design, or tasks. This skill only creates spec.json and requirements.md.
|
|
</instructions>
|
|
|
|
## Output Description
|
|
Provide output in the language specified in `spec.json` with the following structure:
|
|
|
|
1. **Generated Feature Name**: `feature-name` format with 1-2 sentence rationale
|
|
2. **Project Summary**: Brief summary (1 sentence)
|
|
3. **Created Files**: Bullet list with full paths
|
|
4. **Next Step**: Command block showing `/kiro-spec-requirements <feature-name>`
|
|
|
|
**Format Requirements**:
|
|
- Use Markdown headings (##, ###)
|
|
- Wrap commands in code blocks
|
|
- Keep total output concise (under 250 words)
|
|
- Use clear, professional language per `spec.json.language`
|
|
|
|
## Safety & Fallback
|
|
- **Ambiguous Feature Name**: If feature name generation is unclear, propose 2-3 options and ask user to select
|
|
- **Template Missing**: If template files don't exist in `.kiro/settings/templates/specs/`, report error with specific missing file path and suggest checking repository setup
|
|
- **Directory Conflict**: If feature name already exists, append numeric suffix (e.g., `feature-name-2`) and notify user of automatic conflict resolution
|
|
- **Write Failure**: Report error with specific path and suggest checking permissions or disk space
|