How we collapsed a 20-step proposal into a 10-step automated pipeline — leveraging GitHub Projects for visibility, Slack for actions, and Sling for orchestration.
Automates & orchestrates
Visibility layer
Notifications & actions
Every proposed step was evaluated. Some were already built, some were adapted to use better primitives, and some were deferred to avoid blocking progress.
| # | Proposed Step | Status | Implementation |
|---|---|---|---|
| 1 | Business owner sends requirements | Existing | GitHub issues serve as requirements intake |
| 2 | Sling expands to AI-ready requirements | Existing | Spec generator (Phase 0) already does this |
| 3 | Store requirements in Google Drive | Adapted | Added requirements_url field instead of full Google Drive API integration |
| 4 | Business owner reviews Google Doc | Adapted | Business owners review in GitHub Projects board + Slack notifications |
| 5–6 | Build using Sling | Existing | STIV pipeline + Claude Code execution modes |
| 7 | Review QA videos from Sling | Adapted | Playwright already records video/traces/screenshots — now surfaced in Slack notification with links |
| 8–10 | Iterate: revise → rebuild → repeat | Adapted | Configurable auto-retrigger on change request, with feedback injected into prompt context |
| 11 | Mark project ready for UAT | New | Auto-triggered when post-PR pipeline passes — moves to “Demo Ready” in GitHub Projects |
| 12 | Notify business owners + link to test | New | Rich Slack notification with staging URL, E2E artifacts, and action buttons |
| 13 | Business owners provide feedback | New | Slack thread replies collected and posted to GitHub issue. Multi-reviewer approval tracking. |
| 14 | Product producer completes action | New | Slack buttons: Approve / Request Changes / Push to Production |
| 15 | Slack notification of production readiness | New | Auto-posted on deploy success with deploy status and rollback button |
| 16 | Move to production list with rollback button | New | GitHub Projects “In Production” column + PostgreSQL releases table + Slack rollback button |
| 17 | Rollback: revert code, update status | New | One-click: git revert → auto-merge revert PR → monitor deploy → move to “Reverted” |
| 18 | Reverse engineering prompt → GitHub | New | Claude generates reproduction prompt from task + PR diff, commits to knowledge repo |
| 19 | SharedContext updated | New | PR diff submitted to sctxt.ai as code_review for compliance validation. Score + issues posted to Slack & GitHub PR. |
| 20 | Do’s/Don’ts → sctxt.ai | New | Claude extracts Do’s/Don’ts from deployment, submits as do_dont document proposal to sctxt.ai for admin review. |
Four architectural decisions shaped the implementation. Each removes complexity while preserving the workflow’s intent.
The original proposal implied building custom status tracking and a “production list” UI. GitHub Projects already provides kanban boards with custom fields, filtering, and multi-user access — without granting code access to stakeholders. Building our own would duplicate what already exists.
A full Google Drive API integration would add OAuth complexity, token management, and a hard external dependency. A simple requirements_url text field on the task achieves the same linking — humans manage the docs, Sling links to them.
Playwright already records video, traces, and screenshots for every E2E run on Diagnostic.ly repos. The fix was surfacing these existing artifacts in Slack notifications and PR comments — not building a separate video tool.
Initially deferred, but investigation revealed sctxt.ai has a production REST API at https://sctxt.ai/api/v1. Now fully integrated: compliance validation via /integration/validate and Do’s/Don’ts via /document-proposals.
Steps 1–4 were already built. Steps 5–10 are new.
Requirements as GitHub issue
AI expands to full spec
STIV / Claude Code
Review + staging + E2E
Projects + Slack notify
Slack thread feedback
Slack buttons + threshold
Merge PR + monitor
One-click git revert
Reverse prompt → GitHub
GraphQL client that moves issues between project columns. Caches field IDs to respect rate limits.
Rich Slack message with staging URL, E2E video/screenshot links, and Approve/Request Changes buttons.
All 3 Diagnostic.ly repos configured with UAT settings: Slack channel, project ID, approval thresholds, rollback strategy.
Approve, Request Changes, and Push to Production buttons wired into the existing Slack interactions handler.
Slack thread replies scraped, formatted, and posted to GitHub issue/PR as structured feedback.
Configurable threshold (e.g., 2 of 3 must approve). Any “Request Changes” resets all approvals.
Merges PR to production branch, monitors GitHub Actions deploy, posts status to Slack.
PostgreSQL releases table tracks every production deploy: commit SHA, status, timestamps, rollback info.
Slack button triggers git revert → auto-merge revert PR → deploy monitor. Warns if migration files detected.
After successful deploy, Claude generates a reproduction prompt from the task description + PR diff.
Prompt committed as markdown to a configurable knowledge repo. Link posted back to the original PR.
Knowledge capture runs asynchronously — a failure here never blocks the deploy or rollback flow.
Production rollback is the highest-risk operation. Here’s how we handle it.
Diagnostic.ly uses php artisan migrate --force on deploy. Migrations are irreversible by default. Rollback reverts code only. If migration files are detected in the original PR, Sling posts a warning in Slack before proceeding.
Rollback requires an explicit “Are you sure?” confirmation in Slack before executing.
Every rollback creates a proper revert PR with full context — not a force push. History is preserved.
Per-repo rollbackStrategy: code-only (default, safe) or code-and-migrate-down (opt-in, requires down scripts).
“Push to Production” is gated behind the configured approval count. A single “Request Changes” from any reviewer resets all approvals and blocks production push until re-approved.
These items from the original proposal are deferred — not rejected. Each has a clear trigger for when to build it.
| Feature | Why Deferred | When to Build |
|---|---|---|
| Google Drive API | Heavy OAuth integration for document linking. A URL field achieves the same result. | When stakeholders need to edit requirements inside Sling, not just link to them. |
| sctxt.ai + SharedContext — now implemented (Phase 4). Compliance validation and Do’s/Don’ts proposals integrated. | ||
| QA Video Generation | Playwright already records video/traces/screenshots for every E2E run. No new tool needed. | If stakeholders need a curated demo video beyond raw E2E recordings. |
The code is deployed. Three configuration steps remain.
Create a GitHub Project v2 for Diagnostic.ly with status columns: Demo Ready, Awaiting Feedback, Accepted, In Production, Reverted. Add the project ID to repositories.json.
Ensure the GITHUB_TOKEN has the project scope for the Projects v2 GraphQL API. Without it, status moves will silently fail.
To enable reverse engineering prompts, add "knowledgeRepo": "wbtw-repositories/sling-knowledge" to the UAT config in repositories.json.