st4ck-managed-slack

st4ck

The agent-and-human lifecycle surface for full st4ck — requirements through code, QA, and delivery.

st4ck has two product surfaces: st4ck-lite, the local OSS surface, and full st4ck, which pairs this plugin with an app.st4ck.io workspace. Full st4ck builds on Lite's PRD authoring, agent-driven recording, and deterministic replay and adds agent-team lifecycle orchestration, persistent intent, test/component lineage, attestation, impact analysis, and shared reuse. The MCP-backed lifecycle features require a workspace; the plugin is their agent-and-human client, not a standalone middle tier.

# Inside Claude Code:
/st4ck:implement "Add a per-team usage cap to the billing portal"   # full feature lifecycle
/st4ck:debug "Profile edits aren't appearing in the activity feed"  # role-separated debug flow
/st4ck:po-research "Should refunds be reversible after settlement?" # PO discovery + options
/st4ck:impact                                                       # diff → which tests are affected

Lifecycle commands coordinate purpose-built subagents, explicit human checkpoints, and role-specific write restrictions where configured. Those controls reduce accidental role overlap; the authoritative lineage, attestation, execution, and required-review gates are enforced by the st4ck service.

---

What's bundled

Managed Slack package

The marketplace also includes st4ck-managed-slack, a deliberately small package for a managed Claude Tag in one shared Slack project channel. It contributes one project-bound remote MCP connector and a concise shared-channel operating skill. The package contains no credential; its Claude Tag Access bundle supplies the project-bound authorization at runtime.

Install this package only in the managed Access bundle for the intended Slack channel. Reuse the package, but use a separate project-bound credential and Access bundle for every project channel; never reuse one client's bundle in another channel. It is separate from the full Claude Code lifecycle plugin documented below.

Lifecycle skills (the implementation flow)

Skill	Purpose
/st4ck:po-research	Product-owner feature research — explores codebase, challenges requirements, surfaces logic gaps, presents solution options with effort/risk
/st4ck:plan-author	Comprehensive implementation plans — phased tasks, security analysis, test strategy, migration files
/st4ck:implement	Full feature lifecycle (requirements → plan → code → QA → deliver) with role-separated agents + human gates
/st4ck:debug	Role-separated debug flow — research, test gaps, fix, verify green. The session is the dev manager
/st4ck:impact	Agent-driven test impact analysis: reads local git diff, surfaces affected QA tests, queues test_design_change dev_tasks
/st4ck:supervise	Pause + regroup — reviews the session transcript, reminds you what you said, what's left
/st4ck:regression-author	Author regression test suites for shipped features
/st4ck:regression-run	Execute signed regression suites and report results with evidence (observe-only)
/st4ck:version-author	Author version tests for in-development features (green as implementation lands)
/st4ck:qa-testing-debug	Diagnose + fix a failed test or component
/st4ck:st4ck-run	Execute a deterministic test using the runner (with agentic-block IPC pause + rerun from failure)
/st4ck:st4ck-browse	Drive a real browser one IPC primitive at a time, optional --record saves as a deterministic md test

PRD authoring skills

Source-grounded Product Requirements Document authoring — useful when a platform has been live for a while and the test/spec layer needs an intent anchor.

Skill	Purpose
/st4ck:prd-from-source	Author a PRD by reading source rather than asking the user. Four iron rules; Phase 0 preliminaries (checks get_project_users, asks user for role anchor + extra docs); two-pass mechanical-scaffold + curated-intent approach; cross-module reuse rule; audience triple-target (non-technical / QA / dev); confidence markers (CONFIRMED / INFERRED / GAP).
/st4ck:prd-review	Four-phase review pipeline — self-review → 3 parallel independent reviewers (PO / QA / Dev) → known-gaps-vs-code pass → bug-routing to dev tasks. Converges on diminishing returns.

Three reviewer subagents — prd-reviewer-po, prd-reviewer-qa, prd-reviewer-dev — encode each review angle as a stable agent type for consistent, cached prompts across sessions.

Code + QA agents (used internally by the lifecycle skills)

code-agent, code-reviewer, codebase-explorer, qa-author, qa-reviewer, qa-runner, solution-analyst — each with a defined workflow role and role-specific tool/write settings. These client-side settings are workflow guardrails, not a security boundary.

---

Three principles