kiro-discovery

Analyze repository metadata and steering files to determine the correct action path for new work.

3.6k|274|Updated Jul 17, 2025
One-click install
npx skills add https://github.com/gotalab/cc-sdd --skill kiro-discovery
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kiro-discovery
Source: https://github.com/gotalab/cc-sdd/tree/main/tools/cc-sdd/templates/agents/claude-code-skills/skills/kiro-discovery
Command: npx skills add https://github.com/gotalab/cc-sdd --skill kiro-discovery

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill determines the right next step for a new work idea or request by scanning repository-level metadata and steering artifacts to avoid wasted effort, unclear boundaries, or duplicated spec work. It helps teams decide whether to update an existing spec, implement directly, create a single new spec, decompose into multiple specs, or use a mixed approach so work starts with a clear, actionable artifact on disk.

Core Features & Use Cases

  • Lightweight metadata scan: Inspect specs inventory, steering presence, and top-level structure without loading full file contents to preserve context budget.
  • Action path determination: Classify requests into existing-spec extension, no-spec direct work, single new spec, multi-spec decomposition, or mixed decomposition and recommend the next step.
  • Contexted deep exploration: When needed, delegate heavy codebase exploration and technical research to subagents while keeping only concise summaries in main context.
  • On-disk continuity: Create brief.md or roadmap.md files as required to persist discovery decisions and enable reproducible handoffs.

Quick Start

Ask kiro-discovery to evaluate an idea and propose the best action path based on the repository's current spec and steering metadata.

Frequently Asked Questions about kiro-discovery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether to extend an existing spec or create a new one for a new feature request?

Spec decomposition determines the correct action path for a new request by scanning repository metadata and steering artifacts. It classifies the request into existing-spec extension, direct implementation, single new spec, or multi-spec decomposition to recommend the next step.

What is the best way to plan a multi-spec roadmap across a project's steering directories?

Roadmap planning across steering directories involves analyzing repository-level metadata to avoid duplicated work and unclear boundaries. The process proposes 2-3 approaches with trade-offs and creates a roadmap.md file to persist discovery decisions for reproducible handoffs.

How do I scan repository specs without loading full file contents into the main context?

Repository metadata scanning inspects specs inventory, steering presence, and top-level structure without loading full file contents. This preserves context budget by delegating heavy codebase exploration and technical research to subagents while keeping only concise summaries.

Can I use this approach for direct implementation if my repository has no existing specs?

No-spec direct work is a supported action path. The discovery process evaluates repository metadata to determine if a request should bypass spec creation and be implemented directly, or if a brief.md file is required to establish actionable project continuity.

Does this discovery process work with mixed decomposition scenarios involving both existing and new specs?

Mixed decomposition scenarios are supported by analyzing repository steering and specs directories. The process determines whether to update existing specs, implement directly, create single new specs, decompose into multiple specs, or use a mixed approach to start work with a clear artifact on disk.

Why should I use repository discovery before starting spec work on a new work idea?

Repository discovery avoids wasted effort, unclear boundaries, or duplicated spec work by scanning steering artifacts before implementation. It ensures work starts with a clear, actionable artifact on disk, such as a brief.md or roadmap.md file, minimizing main-context loading.