speckit-analyze-zh

Original：🇨🇳 Chinese

Translated

1 scriptsChecked / no sensitive code detected

Perform non-destructive cross-artifact consistency and quality analysis on three core documents: spec.md, plan.md, and tasks.md. Identify inconsistent, duplicate, ambiguous, and under-specified items after task generation. Trigger words include: "speckit-analyze", "speckit-analyze", "document consistency analysis", "specification analysis", "quality check", "artifact analysis", "spec analysis", "plan analysis", "task analysis"

2installs

Sourceforztf/open-skilled-sdd

Added on2026-03-25

NPX Install

npx skill4agent add forztf/open-skilled-sdd speckit-analyze-zh

SKILL.md Content (Chinese)

View Translation Comparison →

User Input

text

$ARGUMENTS

You must consider the user input (if not empty) before proceeding.

Objectives

Before implementation, identify inconsistent, duplicate, ambiguous, and under-specified items among the three core artifacts (

spec.md

,

plan.md

,

tasks.md

). This command must only be run after

speckit-tasks

has successfully generated the complete

tasks.md

.

Operational Constraints

Strictly Read-Only: Do NOT modify any files. Output a structured analysis report. Provide an optional remediation plan (users must explicitly approve before any subsequent edit commands can be manually invoked).

Charter Authority: The project charter (

.specify/memory/constitution.md

) is non-negotiable within the scope of this analysis. Charter conflicts are automatically critical-level issues, requiring adjustments to the specification, plan, or tasks—not dilution, reinterpretation, or silent disregard of principles. If the principles themselves need to be changed, this must be done in a separate, explicit charter update outside of

speckit-analyze

.

Execution Steps

scripts: sh: .specify/scripts/bash/check-prerequisites.sh --json ps: .specify/scripts/powershell/check-prerequisites.ps1 -Json

1. Initialize Analysis Context

Run

{SCRIPT}

once from the repository root and parse the JSON to get FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:

SPEC = FEATURE_DIR/spec.md
PLAN = FEATURE_DIR/plan.md
TASKS = FEATURE_DIR/tasks.md

Abort with an error message (instructing the user to run the missing prerequisite commands) if any required files are missing. For single quotes in arguments, such as "I'm Groot", use escape syntax: e.g., 'I'''m Groot' (or use double quotes if possible: "I'm Groot").

2. Load Artifacts (Progressive Disclosure)

Load only the minimal necessary context for each artifact:

From spec.md:

Overview/Context
Functional Requirements
Non-Functional Requirements
User Stories
Edge Cases (if present)

From plan.md:

Architecture/Technology Stack Selection
Data Model References
Phases
Technical Constraints

From tasks.md:

Task IDs
Descriptions
Phase Grouping
Parallel Marker [P]
Referenced File Paths

From constitution:

Load
```
.specify/memory/constitution.md
```
for principle validation

3. Build Semantic Model

Create an internal representation (do not include raw artifacts in output):

Requirements Inventory: Each functional + non-functional requirement with a stable key (derive slug from imperative; e.g., "User can upload files" →
```
user-can-upload-file
```
)
User Stories/Actions Inventory: Discrete user actions with acceptance criteria
Task Coverage Mapping: Map each task to one or more requirements or stories (inferred via keywords/explicit reference patterns like IDs or keywords)
Charter Rule Set: Extract principle names and MUST/SHOULD normative statements

4. Detection Process (Efficient Token Analysis)

Focus on high-signal findings. Limit total findings to 50; aggregate remaining findings in an overflow summary.

A. Duplication Detection

Identify approximately duplicate requirements
Flag lower-quality wording for merging

B. Ambiguity Detection

Flag vague adjectives without measurable criteria (fast, scalable, secure, intuitive, robust)
Flag unresolved placeholders (TODO, TKTK, ???,
```
<placeholder>
```
, etc.)

C. Under-Specification

Requirements with verbs but missing objects or measurable outcomes
User stories lacking alignment with acceptance criteria
Tasks referencing files or components not defined in the specification/plan

D. Charter Alignment

Any requirements or plan elements conflicting with MUST principles
Missing sections or quality gates mandated in the charter

E. Coverage Gaps

Requirements with no associated tasks
Tasks with no mapped requirements/stories
Non-functional requirements not reflected in tasks (e.g., performance, security)

F. Inconsistencies

Term drift (same concept with different names in different files)
Data entities referenced in the plan but missing from the specification (and vice versa)
Contradictory task sequencing (e.g., integration task before foundational setup task without dependency annotations)
Conflicting requirements (e.g., one requiring Next.js while another specifies Vue)

5. Severity Assignment

Use this heuristic to prioritize findings:

Critical: Violation of charter MUSTs, missing core specification artifacts, or zero-coverage requirements blocking basic functionality
High: Duplicate or conflicting requirements, vague security/performance attributes, untestable acceptance criteria
Medium: Term drift, missing non-functional task coverage, under-specified edge cases
Low: Style/wording improvements, minor redundancies that do not impact execution order

6. Generate Compact Analysis Report

Output a Markdown report (do not write to file) with the following structure:

Specification Analysis Report

ID	Category	Severity	Location	Summary	Recommendation
A1	Duplication	High	spec.md:L120-134	Two similar requirements ...	Merge wording; retain the clearer version

(Add one row per finding; generate stable IDs prefixed with the category initial.)

Coverage Summary Table:

Requirement Key	Has Task?	Task ID	Notes

Charter Alignment Issues: (if any)

Unmapped Tasks: (if any)

Metrics:

Total Requirements
Total Tasks
Coverage % (requirements with >=1 task)
Ambiguity Count
Duplication Count
Critical Issue Count

7. Provide Next Steps

At the end of the report, output a concise next steps block:

If critical issues exist: Recommend resolving before
```
speckit-implement
```
If only low/medium issues: User may proceed, but provide improvement suggestions
Provide explicit command recommendations: e.g., "Run
```
speckit-specify
```
with improvements", "Run
```
speckit-plan
```
to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"

8. Provide Remediation

Ask the user: "Would you like me to suggest specific remediation edits for the top N issues?" (Do not apply them automatically.)

Operational Principles

Context Efficiency

Minimum High-Signal Tokens: Focus on actionable findings rather than exhaustive documentation
Progressive Disclosure: Incrementally load artifacts; do not dump everything into analysis
Efficient Token Output: Limit findings table to 50 rows; summarize overflow
Deterministic Results: Re-running without changes should produce consistent IDs and counts

Analysis Guidelines

Never Modify Files (this is read-only analysis)
Never Invent Missing Sections (report accurately if missing)
Prioritize Charter Violations (these are always critical)
Use Examples Instead of Exhaustive Rules (cite specific instances, not generic patterns)
Gracefully Report Zero Issues (issue a success report with coverage statistics)

Context

{ARGS}