Skip to content

proposal: auto-review primitive for skills#60

Open
JoshSalomon wants to merge 4 commits into
forge-sdlc:mainfrom
JoshSalomon:auto-review
Open

proposal: auto-review primitive for skills#60
JoshSalomon wants to merge 4 commits into
forge-sdlc:mainfrom
JoshSalomon:auto-review

Conversation

@JoshSalomon

@JoshSalomon JoshSalomon commented May 28, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a proposal for an opt-in auto-review mechanism as a new primitive for skills. Any skill can include a review.md alongside SKILL.md to enable automatic worker→reviewer→fix loops.

Decision

Approach A (container-internal loop) has been selected for implementation.

The review loop runs inside the container entrypoint. The orchestrator gets near-real-time visibility via file-based polling of per-cycle JSON files written to the shared workspace mount.

Key Design Points

  • Opt-in: review.md alongside SKILL.md — no file means no review, current behavior preserved
  • Any skill: works for planning skills (PRD, spec) and execution skills (implementation, CI fix)
  • Separate reviewer agent: avoids confirmation bias — reviewer is a different agent than the worker
  • Per-skill retry config: max_retries in review.md frontmatter, global default fallback
  • File-based observability: container writes per-cycle JSON files, orchestrator polls for near-real-time Prometheus metrics and Jira comments
  • Final sweep: orchestrator reads all cycle files after container exit to catch the approval verdict
  • Cycle file persistence: files copied before workspace teardown

Files Changed

  • proposals/auto-review-primitive.md — full proposal (Approach A accepted, Approach B retained for reference)
  • proposals/README.md — index entry added

🤖 Generated with Claude Code

JoshSalomon and others added 3 commits June 1, 2026 13:02
Introduces an opt-in review.md file alongside SKILL.md that enables
automatic worker→reviewer→fix loops for any skill. Includes two
architectural approaches for maintainer discussion, with file-based
observability for near-real-time metrics and Jira visibility.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Interactive script to send Jira webhook payloads to a local Forge
instance. Substitutes ticket IDs, and for revision/question payloads
fetches the latest comment from Jira via REST API so feedback is
always current.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The test payloads hardcode issuetype as "Feature", which bypasses
parent routing for Epics/Tasks. The script now fetches the real
issue type, labels, summary, and status from Jira and injects them
into the payload, so child ticket events route correctly.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

@eshulman2 eshulman2 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree option A is the better option, lets go with this one. please modify the proposal to reflect option A is the chosen one and that option B was considered but wasn't chosen.

Container-internal loop with file-based observability selected for
implementation. Approach B retained for reference. Added implementation
note about final file sweep and cycle file persistence.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@JoshSalomon

Copy link
Copy Markdown
Contributor Author

The proposal was updated to reflect the selected approach (option A - in container loop)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants