Spec → PR: Behind the Scenes
Step 2 — Send open questions back to the PM
Footer comments carry the spec's ambiguities back to Confluence. The workflow deliberately pauses here, before any ticket exists.
Prompt
/mk:confluence-collaborate add-comment 12345 \
"Three open questions from spec analysis: (1) Google scopes? (2) Session expiry style — sliding or hard? (3) Can OAuth users add a password later?" \
--footerWhat happens behind the scenes
| Layer | Action |
|---|---|
| Inline vs footer | Skill enforces --footer for open-question batches (inline comments are reserved for line-level feedback) |
| API call | confluence-as add-comment --page 12345 --type footer --body "..." |
| Notification | PM gets a Confluence notification email; their reply lands as a comment thread |
| Workflow | You stop here. Tickets do not yet exist. |
Why the workflow pauses
Resolving ambiguity before ticket creation prevents two failure modes:
- Tickets with vague ACs that estimator gives a falsely confident number on
- Code that ships matching one valid interpretation of an ambiguous spec, requiring rework when the other interpretation surfaces
Previous: Step 1 — Pull the spec out of Confluence · Next: Step 3 — Tech feasibility breakdown · All steps
Step 1 — Pull the spec out of Confluence
mk:confluence-spec-analyst forks an agent, reads the Confluence page and its children, and writes a Spec Research Report locally — never back to Confluence.
Step 3 — Tech feasibility breakdown (pre-ticket)
A read-only scan with mk:scout and mk:docs-finder that catches 'this needs a refactor first' or 'we already shipped this' before anything gets filed and estimated.