feat(cdt): add anti-sycophancy challenge directive to PM and reviewer

[rube-de]

Part of #104

Context

CDT has anti-sycophancy rules preventing the lead from doing teammates' work (plan-workflow.md:256-263, dev-workflow.md:312-320). But there's no directive preventing teammates from rubber-stamping each other's work. The PM validates the architect's design but has no explicit push to find real problems. The reviewer uses /council but isn't told to challenge assumptions.

From lebed2045/orchestration's wf12 workflow: "Anti-sycophancy rule: Do NOT approve unless genuinely satisfied. If the architect's design has flaws, say so with specifics. Your job is to find problems, not to agree."

Without this, echo-chamber dynamics emerge — architect proposes X, PM approves X without challenge, reviewer approves implementation without scrutiny.

Task

Add anti-sycophancy challenge directives to the PM teammate prompt in plan-workflow.md and the reviewer teammate prompt in dev-workflow.md.

Acceptance Criteria

• VERIFY: PM prompt includes directive to actively challenge the architect's design, not just validate
• VERIFY: PM prompt includes: "Your job is to find problems, not to agree"
• VERIFY: Reviewer prompt includes directive to challenge implementation decisions, not just check correctness
• VERIFY: Both directives are specific — they say what to challenge, not just "be critical"

Implementation Guide

Files to Modify

• plugins/cdt/skills/cdt/references/plan-workflow.md — Add anti-sycophancy to PM prompt (lines 141-156)
• plugins/cdt/skills/cdt/references/dev-workflow.md — Add anti-sycophancy to reviewer prompt (lines 151-208)

Approach

1. In PM prompt (plan-workflow.md, after line 153 "Message the architect teammate directly with concerns"), add:

   Anti-sycophancy rule: Do NOT approve unless genuinely satisfied. Actively look for:
   - Overly complex designs where simpler alternatives exist
   - Missing edge cases or error handling in the architecture
   - Tasks that are too large or poorly scoped
   - Assumptions not backed by research findings
   If the design has flaws, say so with specifics. Your job is to find problems, not to agree.
   

2. In reviewer prompt (dev-workflow.md, after line 169 "Review all changed files"), add:

   Anti-sycophancy rule: Do NOT approve unless genuinely satisfied. Challenge:
   - Code that works but doesn't match the plan's architecture
   - Missing error handling or edge cases from the spec
   - Over-engineering beyond what the task requires
   - Inconsistencies with existing codebase patterns
   Your job is to find real problems. If everything is genuinely clean, approve — but never rubber-stamp.
   

Patterns to Follow

• The existing PM flow (plan-workflow.md:152-155) has PM messaging architect with concerns → this directive makes the concern-finding explicit
• The reviewer already uses /council (dev-workflow.md:170) — this adds internal scrutiny before the external check

Scope

In Scope

• Adding anti-sycophancy directives to PM and reviewer prompts

Out of Scope

• Adding anti-sycophancy to developer, code-tester, or qa-tester (they report facts, not judgments)
• Changing the PM validation flow or reviewer flow structure

Dependencies

• Blocked by: None
• Blocks: None

Definition of Done

• Implementation complete
• bun scripts/validate-plugins.mjs passes
• PR approved and merged
• Epic checklist updated