> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sudocode.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# sudocode feedback show

> Show detailed information about a specific feedback entry, including full content and anchor location

## Syntax

```bash theme={null}
sudocode feedback show <feedback-id>
```

## Description

The `feedback show` command displays comprehensive details about a feedback entry, including:

* Feedback ID and type
* Source issue and target spec
* Dismissed status and agent
* Creation and update timestamps
* Full feedback content
* Anchor location with status
* Original location (if relocated or stale)
* Context snippets

Use this to review feedback in detail before addressing it or to understand the context of a specific comment, suggestion, or request.

<Note>
  This command shows the complete feedback content, unlike `feedback list` which only shows a preview.
</Note>

## Arguments

<ParamField path="feedback-id" type="string" required>
  The feedback ID to display

  **Example:** `FB-001`

  The unique identifier for the feedback entry.
</ParamField>

## Examples

### Show Basic Feedback

Display feedback details:

```bash theme={null}
sudocode feedback show FB-001
```

<Accordion title="Expected output">
  ```
  FB-001 request
  ────────────────────────────────────────────────────────────
  Issue: ISSUE-001
  Spec: SPEC-001
  Status: Active
  Agent: alice
  Created: 2025-10-29T10:15:00Z
  Updated: 2025-10-29T10:15:00Z

  Content:
  Token expiration policy not specified. Should we use fixed or sliding window?
  Consider adding explicit policy in the Authentication section with recommended
  values for access tokens (15 minutes) and refresh tokens (7 days).

  Anchor Location:
    Status: valid
    Section: Authentication Flow
    Line: 42
    Snippet: "Token expiration policy"
  ```
</Accordion>

### Show Feedback with Stale Anchor

View feedback with outdated anchor:

```bash theme={null}
sudocode feedback show FB-004
```

<Accordion title="Expected output">
  ```
  FB-004 request
  ────────────────────────────────────────────────────────────
  Issue: ISSUE-015
  Spec: SPEC-001
  Status: Active
  Agent: bob
  Created: 2025-10-28T14:30:00Z
  Updated: 2025-10-29T09:00:00Z

  Content:
  Need clarification on error response format. Should we use RFC 7807
  problem details format or custom error structure? This affects client
  error handling implementation.

  Anchor Location:
    Status: stale
    Section: Error Handling
    Line: 45
    Snippet: "Error response format"

  Original Location:
    Line: 38
    Section: Error Handling
  ```
</Accordion>

<Info>
  When anchor status is "stale" or "relocated", the original location is shown for reference.
</Info>

### Show Relocated Feedback

View feedback that was moved:

```bash theme={null}
sudocode feedback show FB-005
```

<Accordion title="Expected output">
  ```
  FB-005 suggestion
  ────────────────────────────────────────────────────────────
  Issue: ISSUE-020
  Spec: SPEC-003
  Status: Active
  Agent: carol
  Created: 2025-10-27T11:00:00Z
  Updated: 2025-10-29T10:45:00Z

  Content:
  Consider using enum type instead of string constants for user roles.
  This provides better type safety and IDE autocomplete support.

  Example:
  enum UserRole {
    ADMIN = 'admin',
    USER = 'user',
    GUEST = 'guest'
  }

  Anchor Location:
    Status: relocated
    Section: Data Model
    Line: 92
    Snippet: "User role definitions"

  Original Location:
    Line: 85
    Section: User Schema
  ```
</Accordion>

### Show Dismissed Feedback

View resolved feedback:

```bash theme={null}
sudocode feedback show FB-003
```

<Accordion title="Expected output">
  ```
  FB-003 suggestion
  ────────────────────────────────────────────────────────────
  Issue: ISSUE-010
  Spec: SPEC-002
  Status: Dismissed
  Agent: alice
  Created: 2025-10-26T09:00:00Z
  Updated: 2025-10-28T16:30:00Z

  Content:
  Consider adding rate limiting to prevent abuse: 10 requests/minute per client.
  Could use token bucket algorithm with Redis for distributed tracking.

  Anchor Location:
    Status: valid
    Section: API Endpoints
    Line: 78
    Snippet: "Rate limiting policy"
  ```
</Accordion>

### Show Comment Feedback

View implementation notes:

```bash theme={null}
sudocode feedback show FB-002
```

<Accordion title="Expected output">
  ```
  FB-002 comment
  ────────────────────────────────────────────────────────────
  Issue: ISSUE-005
  Spec: SPEC-001
  Status: Active
  Agent: bob
  Created: 2025-10-29T11:00:00Z
  Updated: 2025-10-29T11:00:00Z

  Content:
  OAuth flow implemented successfully with PKCE extension as specified.
  Used authorization code flow with state parameter for CSRF protection.
  Access token TTL set to 1 hour, refresh token to 30 days as per OAuth 2.0
  best practices.

  Anchor Location:
    Status: valid
    Section: OAuth 2.0 Flow
    Line: 30
    Snippet: "OAuth implementation details"
  ```
</Accordion>

### JSON Output

Get machine-readable output:

```bash theme={null}
sudocode --json feedback show FB-001
```

<Accordion title="JSON output">
  ```json theme={null}
  {
    "id": "FB-001",
    "issue_id": "ISSUE-001",
    "spec_id": "SPEC-001",
    "feedback_type": "request",
    "content": "Token expiration policy not specified. Should we use fixed or sliding window? Consider adding explicit policy in the Authentication section with recommended values for access tokens (15 minutes) and refresh tokens (7 days).",
    "agent": "alice",
    "anchor": {
      "line_number": 42,
      "section_heading": "Authentication Flow",
      "text_snippet": "Token expiration policy",
      "anchor_status": "valid",
      "context_before": "## Authentication Flow\n\nThe system uses JWT tokens for authentication.",
      "context_after": "Tokens should be validated on each request.\n\n### Token Refresh"
    },
    "dismissed": false,
    "created_at": "2025-10-29T10:15:00Z",
    "updated_at": "2025-10-29T10:15:00Z"
  }
  ```
</Accordion>

## Understanding Feedback Details

### Feedback Types

<CardGroup cols={3}>
  <Card title="comment" icon="message">
    **Informational notes**

    Documents implementation decisions, shares learnings, or provides status updates. No action required.
  </Card>

  <Card title="suggestion" icon="lightbulb">
    **Improvement proposals**

    Proposes changes or enhancements to the spec based on implementation experience.
  </Card>

  <Card title="request" icon="circle-question">
    **Clarification needed**

    Points out ambiguities or missing requirements discovered during implementation.
  </Card>
</CardGroup>

### Anchor Status

The anchor status indicates whether the feedback location is still accurate:

<Steps>
  <Step title="valid (green)">
    Anchor is accurate - the line number and context match the current spec content.

    **No action needed.**
  </Step>

  <Step title="relocated (yellow)">
    Content moved but anchor was successfully updated to new location.

    **Review to confirm accuracy, but usually fine.**
  </Step>

  <Step title="stale (red)">
    Content changed significantly - anchor may be invalid or pointing to wrong location.

    **Action required:** Use `feedback relocate` to manually fix the anchor.
  </Step>
</Steps>

### Original Location

When feedback has been relocated or become stale, the "Original Location" section shows:

* The line number where the anchor was originally created
* The section heading at that original location

This helps you understand where the feedback was initially anchored and track how the spec has evolved.

## Common Workflows

### Review Feedback Before Responding

<Steps>
  <Step title="Show feedback details">
    ```bash theme={null}
    sudocode feedback show FB-001
    ```
  </Step>

  <Step title="View spec context">
    ```bash theme={null}
    sudocode spec show SPEC-001
    ```
  </Step>

  <Step title="Update spec if needed">
    Edit the spec to address the feedback
  </Step>

  <Step title="Dismiss feedback">
    ```bash theme={null}
    sudocode feedback dismiss FB-001
    ```
  </Step>
</Steps>

### Investigate Stale Feedback

<Steps>
  <Step title="Find stale feedback">
    ```bash theme={null}
    sudocode feedback stale
    ```
  </Step>

  <Step title="Show details">
    ```bash theme={null}
    sudocode feedback show FB-004
    ```
  </Step>

  <Step title="View current spec">
    ```bash theme={null}
    sudocode spec show SPEC-001
    ```

    Look at the original line number to see what changed
  </Step>

  <Step title="Relocate or dismiss">
    ```bash theme={null}
    # If still relevant, relocate
    sudocode feedback relocate FB-004 --line 50

    # If no longer relevant, dismiss
    sudocode feedback dismiss FB-004
    ```
  </Step>
</Steps>

### Audit Implementation Feedback

View all feedback from a completed issue:

<Steps>
  <Step title="List issue feedback">
    ```bash theme={null}
    sudocode feedback list --issue ISSUE-005
    ```
  </Step>

  <Step title="Review each entry">
    ```bash theme={null}
    sudocode feedback show FB-002
    ```
  </Step>

  <Step title="Extract learnings">
    Use feedback to improve future specs
  </Step>
</Steps>

### Generate Feedback Report

Create a summary of feedback:

```bash theme={null}
# Show all active requests
for fb_id in $(sudocode --json feedback list --type request --dismissed false | jq -r '.[] | .id'); do
  echo "=== $fb_id ==="
  sudocode feedback show "$fb_id"
  echo
done
```

## Scripting Examples

### Extract Feedback Content

```bash theme={null}
# Get just the content text
sudocode --json feedback show FB-001 | jq -r '.content'
```

### Check Anchor Status

```bash theme={null}
# Get anchor status for a feedback
status=$(sudocode --json feedback show FB-001 | jq -r '.anchor.anchor_status')
echo "Anchor status: $status"
```

### Find Feedback Location

```bash theme={null}
# Get spec and line number
sudocode --json feedback show FB-001 | jq -r '"\(.spec_id):\(.anchor.line_number)"'
# Output: SPEC-001:42
```

### Batch Review

```bash theme={null}
# Review all feedback for a spec
for fb_id in $(sudocode --json feedback list --spec SPEC-001 | jq -r '.[] | .id'); do
  echo "Reviewing $fb_id..."
  sudocode feedback show "$fb_id"
  echo "Press enter for next..."
  read
done
```

## Common Questions

<AccordionGroup>
  <Accordion title="How do I see the feedback in context of the spec?">
    Use `spec show` to view the spec with all its feedback:

    ```bash theme={null}
    sudocode spec show SPEC-001
    ```

    This shows feedback anchored to specific locations in the spec content.
  </Accordion>

  <Accordion title="What does the snippet show?">
    The snippet is a short excerpt from the spec at the anchor location. It helps confirm the feedback is pointing to the right content.
  </Accordion>

  <Accordion title="Can I edit feedback after creating it?">
    No, there's no edit command. To modify feedback:

    1. Dismiss the old feedback
    2. Add new feedback with updated content
  </Accordion>

  <Accordion title="Why does dismissed feedback show old timestamps?">
    `updated_at` reflects when the feedback was last modified, including when it was dismissed. The dismiss action updates this timestamp.
  </Accordion>

  <Accordion title="What's the difference between context_before and context_after?">
    These are lines surrounding the anchor point:

    * **context\_before** - Text above the anchor location
    * **context\_after** - Text below the anchor location

    They help verify the anchor is still pointing to the correct location.
  </Accordion>

  <Accordion title="Can I show multiple feedback entries at once?">
    Not with a single command. Use shell scripting:

    ```bash theme={null}
    for id in FB-001 FB-002 FB-003; do
      sudocode feedback show "$id"
    done
    ```
  </Accordion>
</AccordionGroup>

## Troubleshooting

<AccordionGroup>
  <Accordion title="Error: Feedback not found">
    **Cause:** The feedback ID doesn't exist

    **Solution:**
    List all feedback to find the correct ID:

    ```bash theme={null}
    sudocode feedback list
    ```
  </Accordion>

  <Accordion title="Anchor shows as stale but content looks correct">
    **Cause:** Line numbers changed due to edits elsewhere in spec

    **Solution:**
    If the location is still correct, update status to relocated:

    ```bash theme={null}
    sudocode feedback relocate FB-001 --line 42
    ```
  </Accordion>

  <Accordion title="Original location is missing">
    **Cause:** Feedback has never been relocated (status is valid)

    **Solution:**
    Original location only appears when status is "relocated" or "stale". Valid anchors don't need it.
  </Accordion>

  <Accordion title="Content is truncated in JSON output">
    **Cause:** Content is likely complete, check if it's a display issue

    **Solution:**
    Verify content length:

    ```bash theme={null}
    sudocode --json feedback show FB-001 | jq -r '.content | length'
    ```
  </Accordion>
</AccordionGroup>

## Related Commands

<CardGroup cols={3}>
  <Card title="feedback list" icon="list" href="/cli/feedback-list">
    List all feedback
  </Card>

  <Card title="feedback add" icon="plus" href="/cli/feedback-add">
    Add new feedback
  </Card>

  <Card title="feedback dismiss" icon="check" href="/cli/feedback-dismiss">
    Dismiss feedback
  </Card>

  <Card title="feedback relocate" icon="arrows-up-down" href="/cli/feedback-relocate">
    Relocate stale anchor
  </Card>

  <Card title="spec show" icon="file-lines" href="/cli/spec-show">
    View spec with feedback
  </Card>

  <Card title="issue show" icon="list-check" href="/cli/issue-show">
    View issue with feedback
  </Card>
</CardGroup>

## Next Steps

<Steps>
  <Step title="List feedback">
    ```bash theme={null}
    sudocode feedback list --dismissed false
    ```
  </Step>

  <Step title="Show details">
    ```bash theme={null}
    sudocode feedback show FB-001
    ```
  </Step>

  <Step title="Review spec">
    ```bash theme={null}
    sudocode spec show SPEC-001
    ```
  </Step>

  <Step title="Take action">
    Update spec, relocate anchor, or dismiss feedback
  </Step>
</Steps>

<Card title="Feedback System Concept Guide" icon="book" href="/concepts/feedback">
  Learn more about the feedback system and bidirectional learning
</Card>