[Feature]: Add /speckit.guide for dry-run implementation planning

### Problem Statement

While /speckit.clarify helps reduce ambiguity in the feature specification before planning, there is currently no equivalent step for validating implementation scope after task generation and before execution.

This leaves a gap where /speckit.implement may exceed the intended scope by acting on future tasks or making architectural assumptions that were not explicitly reviewed beforehand.

This creates risks such as:

Scope creep across planned phases
Unintended architecture changes
Hallucinated dependencies or missing interfaces
Higher review and rollback costs

### Proposed Solution

Introduce a new optional command: `/speckit.guide`.

This command would run after `/speckit.tasks` and before `/speckit.implement`, generating a `guide.md` file that acts as a dry-run implementation plan.

The generated guide would describe:

* Which files are expected to be modified
* Which interfaces or services may be affected
* Required dependencies or prerequisites
* Execution order of tasks
* Scope boundaries for the current phase
* Potential risks or stop conditions

This would provide developers with a reviewable implementation artifact before execution, reducing the chance of scope drift and improving architecture control.

Proposed workflow:

```text
/speckit.specify
→ /speckit.clarify
→ /speckit.plan
→ /speckit.tasks
→ /speckit.guide
→ Human review
→ /speckit.implement
```

This would not replace `/speckit.clarify`, but complement it by extending the same validation principle into the implementation phase.

### Alternatives Considered

Yes, I considered the following alternatives:

1. **Using `/speckit.clarify`**

* This helps resolve ambiguity in the feature specification before planning.
* However, it does not address implementation scope validation after task generation.

2. **Improving `/speckit.implement` directly**

* Scope validation logic could be embedded into `/speckit.implement`.
* However, this would mix planning/review concerns with execution, reducing workflow transparency.

3. **Manual `guide.md` creation**

* This is the current workaround I use.
* It provides better control, but it is manual, inconsistent, and not integrated into the Spec Kit workflow.

I believe a dedicated `/speckit.guide` command is the cleanest solution because it introduces a reusable, explicit review layer between task generation and implementation.

### Component

Agent integrations (command files, workflows)

### AI Agent (if applicable)

None

### Use Cases

_No response_

### Acceptance Criteria

_No response_

### Additional Context

_No response_

Start by inspecting the existing command files and workflows for /speckit.tasks and /speckit.implement to understand how a new /speckit.guide step would fit. The issue proposes generating guide.md with scope, dependencies, execution order, boundaries, risks, and stop conditions, but provides no named files, tests, or acceptance criteria; those need to be established before implementation is complete.

Scritto dal modello di indicizzazione a partire dal testo della issue.