📝[Enhancement]: Add structured reporting during the process

.github/prompts/analyze.prompt.md

@@ -94,7 +94,46 @@ Execution steps:
      * Duplication Count
      * Critical Issues Count
 
-7. At end of report, output a concise Next Actions block:
+7. **Post issue comment** with analysis results organized by severity:
+   - Post a comment to the GitHub issue with the analysis findings
+   - Format the comment with separate tables for each severity level (only include levels that have findings):
+     ```markdown
+     ## Analysis Report
+
+     ### Summary
+     - Total Requirements: X
+     - Total Tasks: Y
+     - Coverage: Z%
+     - Issues Found: N (A critical, B high, C medium, D low)
+
+     ### Critical Issues
+     | ID | Category | Location(s) | Summary | Recommendation |
+     |----|----------|-------------|---------|----------------|
+     | C1 | ... | ... | ... | ... |
+
+     ### High Priority Issues
+     | ID | Category | Location(s) | Summary | Recommendation |
+     |----|----------|-------------|---------|----------------|
+     | H1 | ... | ... | ... | ... |
+
+     ### Medium Priority Issues
+     | ID | Category | Location(s) | Summary | Recommendation |
+     |----|----------|-------------|---------|----------------|
+     | M1 | ... | ... | ... | ... |
+
+     ### Low Priority Issues
+     | ID | Category | Location(s) | Summary | Recommendation |
+     |----|----------|-------------|---------|----------------|
+     | L1 | ... | ... | ... | ... |
+
+     ### Next Actions
+     - [Recommendation based on findings]
+     ```
+   - Keep tables concise, limit to 20 findings per severity level
+   - If more than 20 findings in a category, add a note: "_(Additional N issues not shown - see full report)_"
+   - Include the complete "Next Actions" block with specific recommendations
+
+8. At end of report, output a concise Next Actions block:
    - If CRITICAL issues exist: Recommend resolving them before `/implement`.
    - If only LOW/MEDIUM issues: User may proceed, but provide improvement suggestions.
    - Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", or "Manually edit tasks.md to add coverage for 'performance-metrics'".

.github/prompts/clarify.prompt.md

@@ -142,7 +142,24 @@ Execution steps:
 
 7. Write the updated spec back to `FEATURE_SPEC`.
 
-8. Report completion (after questioning loop ends or early termination):
+8. **Post issue comment** with clarification summary (only if questions were asked and answered):
+   - Post a comment to the GitHub issue summarizing the clarifications
+   - Format the comment as:
+     ```markdown
+     ## Clarification Session (YYYY-MM-DD)
+
+     | # | Question | Answer |
+     |---|----------|--------|
+     | 1 | <question text> | <answer text> |
+     | 2 | <question text> | <answer text> |
+     | ... | ... | ... |
+
+     _All clarifications have been integrated into the specification._
+     ```
+   - Keep the table concise and readable
+   - Include all questions asked and answers received during this session (up to 5)
+
+9. Report completion (after questioning loop ends or early termination):
    - Number of questions asked & answered.
    - Path to updated spec.
    - Sections touched (list names).

.github/prompts/plan.prompt.md

@@ -23,6 +23,7 @@ Given the implementation details provided as an argument, do this:
      - **If exists**: You are ITERATING on an existing plan. User input should guide refinements/additions to the existing plan content.
      - **If not exists**: You are CREATING a new plan from scratch.
    - BEFORE proceeding, inspect FEATURE_SPEC for a `## Clarifications` section with at least one `Session` subheading. If missing or clearly ambiguous areas remain (vague adjectives, unresolved critical choices), PAUSE and instruct the user to run `/clarify` first to reduce rework. Only continue if: (a) Clarifications exist OR (b) an explicit user override is provided (e.g., "proceed without clarification"). Do not attempt to fabricate clarifications yourself.
+
 2. Read and analyze the feature specification to understand:
    - The feature requirements and user stories
    - Functional and non-functional requirements
@@ -138,6 +139,8 @@ Given the implementation details provided as an argument, do this:
    gh issue edit <issue-number> --remove-label "Specification" --add-label "Plan"
    ```
 
-9. Report results with branch name, PR URL, file paths, and generated artifacts.
+9. **Post final status comment**: "✅ Planning complete. Ready for task generation with `/tasks` or analysis with `/analyze`."
+
+10. Report results with branch name, PR URL, file paths, and generated artifacts.
 
 Use absolute paths with the repository root for all file operations to avoid path issues.

.github/prompts/specify.prompt.md

@@ -137,6 +137,8 @@ Given that feature description, do this:
    gh issue edit <issue-number> --body-file <SPEC_FILE>
    ```
 
-8. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase.
+8. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`."
+
+9. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase.
 
 Note: The script handles branch creation/reuse and initializes the spec file before writing.

.github/prompts/tasks.prompt.md

@@ -109,7 +109,9 @@ $ARGUMENTS
    rm temp_body.md
    ```
 
-9. Report completion with task count, file path, and PR update status.
+9. **Post final status comment**: "✅ Task list ready. Run `/analyze` for quality check or `/implement` to begin execution."
+
+10. Report completion with task count, file path, and PR update status.
 
 Context for task generation: $ARGUMENTS