메뉴
Initialize structured implementation workflow documents in siw/ (spec, LOG.md, issues)
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Analyze code quality of branch changes using specialized review agents (tests, errors, types, security, performance, slop, lean deletion, refactor fit, simplification). Outputs REVIEW_OVERVIEW.md with actionable findings, or replies inline with --inline. Use --team for multi-agent cross-validation. Not for UX, visual, or accessibility review -- use kramme:pr:ux-review for those.
Resolve findings from code reviews by implementing fixes and documenting changes. Implements fixes as commits on the current branch. Use --team to resolve independent findings in parallel by file area.
Charts huge or foggy initiatives into a local `.context` decision map and resolves one typed frontier ticket per session until the work is ready for SIW or another execution workflow. Use when the route to a destination cannot fit in one agent session or parallel workspaces need coordinated planning state. Not for clear specs, ordinary issue decomposition, implementation, or Linear-native tracking.
Builds a clearly throwaway logic/state or UI prototype to answer one design question before implementation hardens. Use when the user wants to sanity-check a state model, data shape, API surface, page layout, component direction, or interaction idea with disposable code. Not for production implementation, polished demos, visual diff reports, permanent routes, or broad design-system work.
Investigates a question against primary sources and saves one cited Markdown artifact. Use for reading legwork: official docs/API facts, source-code or spec checks, standards, and first-party service behavior before planning or implementation. Not for making product or architecture decisions, implementing code, broad web search, secondary blog summaries, or uncited answers.
Break spec into atomic, phase-based issues with tests and validation
| name | kramme:siw:init |
| description | Initialize structured implementation workflow documents in siw/ (spec, LOG.md, issues) |
| argument-hint | [spec-file(s) | folder | discover] [--auto] |
| disable-model-invocation | true |
| user-invocable | true |
Set up the three-document system for tracking complex implementations locally, without requiring Linear or other external issue trackers.
This command ONLY initializes workflow documents.
Issue definition is a separate workflow. After this command completes, invoke /kramme:siw:issue-define to create your first issue, or /kramme:siw:generate-phases when the spec should be decomposed into phased issues. Spec hardening is a separate workflow. To strengthen an existing SIW spec, use /kramme:siw:discovery.
Use this shared vocabulary in setup summaries and handoffs:
product-only: the source explains the problem, user, or desired outcome but still lacks testable scope or success criteria.requirements-only: scope and success criteria exist, but implementation planning still lacks phase boundaries, dependencies, or enough technical context.planning-ready: the SIW spec is concrete enough for /kramme:siw:generate-phases or /kramme:siw:issue-define.implementation-ready: an issue file has executable scope, dependencies, acceptance criteria, and verification. This skill never produces implementation-ready artifacts.siw:init creates the tracked planning container. It may preserve a product-only or requirements-only source as context, or produce a planning-ready SIW spec when the imported/discovered content is concrete enough; it must not imply implementation is ready until issues exist.
/kramme:siw:init [spec-file(s) | folder | discover]
↓
[Check for existing files] -> Found? -> Ask: resume or start fresh
↓
[Handle arguments] -> file/folder: import content
-> discover: run greenfield discovery, then import siw/DISCOVERY_BRIEF.md
-> empty: continue to brief interview
↓
[Brief interview OR Confirm imported content]
↓
[Read STRATEGY.md if present]
↓
[Select work context] -> Profile for downstream tool adaptation
↓
[Auto-detect spec type] -> Confirm filename
↓
[Ask about supporting specs] -> Need detailed specs?
↓
[Create documents] -> siw/spec, siw/LOG.md, siw/issues/, (supporting-specs/)
↓
[Report success] -> Suggest next readiness-gated skill
Before Phase 1, parse $ARGUMENTS as shell-style arguments. If --auto is present, set AUTO_MODE=true and remove it from the remaining input. --auto uses safe initialization defaults when enough context is already supplied: keep linked files in place, use all discovered files from an explicit folder, choose the auto-detected work context and spec filename, and create a single spec file without supporting specs. It does not bypass required project context, existing-workflow protection, deletion confirmation, file overwrite checks, or fresh discovery topic requirements.
Check if any workflow files already exist:
find siw -maxdepth 1 \( \
-name "LOG.md" -o \
-name "OPEN_ISSUES_OVERVIEW.md" -o \
-name "AUDIT_IMPLEMENTATION_REPORT.md" -o \
-name "AUDIT_SPEC_REPORT.md" -o \
-name "PRODUCT_AUDIT.md" -o \
-name "SIW_*.md" -o \
-name "SPEC_STRENGTHENING_PLAN.md" -o \
-name "DISCOVERY_BRIEF.md" -o \
-name "issues" \
\) -print 2> /dev/null
# Permanent SIW spec detection (referenced as `permanent-spec find` elsewhere in this skill).
# Case-insensitive so lowercase/mixed-case filenames like `feature_spec.md` are not missed.
# Synced SIW spec-exclusion contract (keep aligned across SIW spec detectors): `LOG.md`, `OPEN_ISSUES_OVERVIEW.md`, `DISCOVERY_BRIEF.md`, `SPEC_STRENGTHENING_PLAN.md`, `AUDIT_*.md`, `PRODUCT_AUDIT.md`, `SIW_*.md`.
find siw -maxdepth 1 -type f \( -iname "*SPEC*.md" -o -iname "*SPECIFICATION*.md" -o -iname "*PLAN*.md" -o -iname "*DESIGN*.md" \) \
! -iname "LOG.md" \
! -iname "OPEN_ISSUES_OVERVIEW.md" \
! -iname "DISCOVERY_BRIEF.md" \
! -iname "SPEC_STRENGTHENING_PLAN.md" \
! -iname "AUDIT_*.md" \
! -iname "PRODUCT_AUDIT.md" \
! -iname "SIW_*.md" \
2> /dev/null
Read references/existing-workflow-handling.md and follow the first matching branch for siw/DISCOVERY_BRIEF.md only, siw/DISCOVERY_BRIEF.md + siw/SPEC_STRENGTHENING_PLAN.md, siw/SPEC_STRENGTHENING_PLAN.md only, other workflow files, or no files.
Read references/argument-handling.md and follow the matching case for file paths, folder paths, discover / interview, or no arguments. This phase sets linked_spec_files, linked_spec_readiness_context, discovered_content, project_description, or resolved_arguments for later phases.
Skip this phase if imported_spec_content or discovered_content exists from Phase 1.5.
If AUTO_MODE=true and Phase 2 would run, stop before asking with MISSING REQUIREMENT: project context required for --auto; pass a spec file, folder, discovery brief, or use discover <topic>.
Read the Phase 2 templates from references/interviews.md, use them to gather project context, urgency and outcome, scope boundaries, and decision boundaries, then store the responses as project_description, why_now, out_of_scope_non_goals, and decision_boundaries_notes.
Only executed if linked_spec_files exists from Phase 1.5 (file/folder import).
Skip this phase if discovered_content exists (discover mode already has confirmation built in).
Show the files that will be linked:
Linked Specification Files:
───────────────────────────
The following files will be referenced (not duplicated) in the SIW spec:
1. {file1} - "{title from first heading}"
2. {file2} - "{title from first heading}"
...
These files remain the source of truth. The SIW spec will link to them.
If AUTO_MODE=true, choose Keep in place. Otherwise read the Phase 2.5 file-location template from references/interviews.md and use AskUserQuestion.
For both "Move to siw/" and "Copy to siw/", before transferring each file, check the target path with [ -e "siw/{filename}" ]. If a file already exists at the target, read the Phase 2.5 collision template from references/interviews.md and use AskUserQuestion before overwriting.
Apply the user's choice per file, then:
linked_spec_files, continue to Phase 2.6siw/{filename} (or the renamed/skipped path per the collision prompt above)linked_spec_files with the resulting pathssiw/ (or the renamed/skipped path per the collision prompt above)linked_spec_files with the resulting pathsOnly executed if linked_spec_files exists.
If AUTO_MODE=true, use the inferred default value. Otherwise read the Phase 2.6 project-context template from references/interviews.md and use AskUserQuestion.
Store the response as project_description.
If user provides empty response or selects "Skip", use a generic description derived from the linked file names.
Before selecting the work context, check for repo-root STRATEGY.md. If it exists, read it, store concise strategy_context, mark stale context with STALE: when last_updated is older than 90 days, and surface conflicts with active tracks or non-goals without blocking initialization. If no strategy exists, stay silent for narrow work; for broad product-direction work, include MISSING PRODUCT CONTEXT: no STRATEGY.md found in the generated spec's strategy context note and suggest /kramme:product:strategy after initialization.
Select a work context profile that tells downstream tools (spec-audit, product-review, discovery, generate-phases) how to adapt their rigor and focus.
Read the profile definitions and auto-detection heuristics from references/work-context-profiles.md.
Based on project_description or discovered_content topic, use the keyword heuristics from the reference file to suggest a profile. If AUTO_MODE=true, choose the auto-detected profile; otherwise read the Phase 2.8 work-context template from references/interviews.md, deduplicate options as documented there, and use AskUserQuestion.
Store the selected profile as work_context_profile with all attribute values from the reference file (work_type, maturity, priority_dimensions, deprioritized, notes).
Use the Phase 3 filename detection heuristics in references/interviews.md to auto-detect the most appropriate spec filename. If AUTO_MODE=true, choose it automatically. Otherwise read the Phase 3 specification-document template from references/interviews.md and use AskUserQuestion; if "Custom name" is selected, use AskUserQuestion to get the filename.
Store as spec_filename.
If AUTO_MODE=true, choose No - single spec file is enough. Otherwise read the Phase 3.5 supporting-specifications template from references/interviews.md and use AskUserQuestion.
Store as use_supporting_specs.
Read references/document-creation.md, apply its readiness classification procedure, and follow it to create siw/, siw/{spec_filename}, siw/LOG.md, siw/OPEN_ISSUES_OVERVIEW.md, siw/issues/, and optional siw/supporting-specs/.
When strategy_context exists, include a concise ## Product Strategy Context section in the generated SIW spec using the relevant placeholders from assets/spec-templates.md. Keep it to strategy facts and conflicts; do not duplicate the entire STRATEGY.md.
Read the Phase 5 success-report templates from references/success-report.md, display the applicable summary sections, then stop.
Include one readiness line in the success report:
Artifact readiness: <product-only|requirements-only|planning-ready> — <one-line reason and next skill>
If the result is product-only or requirements-only, point to /kramme:siw:discovery before phase or issue creation. If it is planning-ready, point to /kramme:siw:generate-phases for phased work or /kramme:siw:issue-define for a single first issue.
STOP HERE. Wait for the user's next instruction.