Run AI Agents from Jira, Linear, GitHub Issues, or Markdown

Notifications You must be signed in to change notification settings

Fork 0

Star 6

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

125 Commits

125 Commits

.github/workflows

.github/workflows

adapters

adapters

bin

bin

config

config

docs/superpowers

docs/superpowers

exports

exports

extensions/tracker-backends

extensions/tracker-backends

packaging

packaging

reference

reference

roles

roles

src/startup_factory_cli

src/startup_factory_cli

teams

teams

tests

tests

.gitignore

.gitignore

LICENSE

LICENSE

README.md

README.md

SKILL.md

SKILL.md

pyproject.toml

pyproject.toml

Repository files navigation

Turn your product board into a governed software delivery system.

Startup Factory is an agentic orchestration framework for end-to-end product delivery. Connect the project-management tool your team already loves—Linear, Jira, GitHub Issues, local Markdown, or your own adapter—and make it the durable control plane for a cross-functional team of AI agents.

Put a [task] in ToDo—the shipped mapping of the generic queued state. When automation is enabled and scheduled, the deterministic PM supervisor checks the board every three minutes by default, leaves anything labeled human-work to people, routes every other queued task by its explicit team preset (or your configured default), and drives it through architecture, implementation, a four-party In Review gate, optional specialist QA, and integration. It also observes Blocked work as a human-controlled safety lock: the matching task workers stop, while independent ToDo work continues. When your release policy, exact approval, and protected green CI proof allow it, a separate credential-isolated executor deploys the reviewed immutable artifact, verifies the target, and only then closes the parent [feature] as Live.

Bring your own models, repository, stack, tracker, and infrastructure. Provider-neutral structured hooks can target production in any cloud, platform, cluster, datacenter, or internal environment that can implement the plan/apply/status/verify contract. Startup Factory supplies the delivery protocol, team topology, deterministic runtime, recovery model, and safety boundaries around them.

Project-management native · Multi-model · Cloud agnostic · Fail closed · Auditable

This is not a hidden chatbot loop. Plans, ownership, progress, decisions, evidence, blockers, approvals, policy denials, and deployment state remain visible in the same board where your team manages the product. Tracker text and claimed authorship are workflow evidence, never security authentication or production authority.

ToDo -> In Progress -> In Review -> Ready for production -> deploy -> Live findings -> ToDo -> fresh attempt -> In Progress red / pending / missing CI ----------------------X deploy anywhere

Safe by default: board automation and production delivery both ship disabled. Ordinary agents never receive production credentials; enabling a release requires protected external configuration, hooks, identities, and verification. Only an exact, current green CI/CD proof for the release commit permits deployment.

Table of contents

Layered safety boundaries for AI builders

Why Startup Factory

Superpowers + Startup Factory

Full transparency in your tracker

Choose your operating mode

Requirements

Quick Start (2 minutes, no accounts)

Install into your repository

Connect your LLM

Connect your tracker

Configure

Use it

Automate the board and production delivery

The six preset teams

How it works

Documentation map

Directory map

Extend it

Troubleshooting

Credits

License

Layered safety boundaries for AI builders

Autonomous agents are only as useful as the boundaries around them. Startup Factory supplies fail-closed workflow and release controls, but repository code is not an operating-system security boundary. Ordinary agents still require a real worktree-scoped sandbox and least-privilege identity:

A code-owned production policy gate. bin/policy-check.py screens every privileged release-hook command and normalized production plan before that subprocess starts. Its deny baseline — shell composition, privilege escalation, filesystem/database/ infrastructure destruction, secret dumping, metadata-credential access, encoded-command bypasses — is owned by the code: project configuration can add denials, never remove one.

A three-tier authority model. Every action resolves to DENY, REQUIRE HUMAN APPROVAL, or ALLOW (reference/guardrails.md). Approvals bind exact digests, environments, targets, expirations, and one-use nonces. Silence never approves; unknown anything is denied.

A [task]-level release-denial trail. A normalized production-plan denial is projected idempotently as [DENIED ACTION] through bin/tracker-ops.sh record-denial. Other launcher, path, queue, and identity preflight refusals fail before mutation and remain in protected runtime logs; they are not falsely advertised as tracker records.

Least-privilege agent sandboxes. In enforced mode every LLM process and WORKTREE_SETUP runs as AGENT_SANDBOX_RUNNER --workdir -- /usr/bin/env -i .... The launcher accepts only a protected executable outside the repository; that runner must enforce filesystem, process, network, and IAM isolation. In broker mode no LLM—including the team lead—receives tracker credentials.

Contained workspaces. Every implementer is isolated in its own git worktree; tracker file paths are symlink-safe and confined to their configured root; integration and terminal transitions are serialized, verified by read-back, and reserved to dedicated components.

Automation that is off by default. The portfolio supervisor is deterministic (not an LLM), disabled until explicitly enabled, and stops the pass rather than fabricating state when anything is malformed.

The built-in authority policy is intentionally simple:

Decision Representative actions Who can authorize it

Always deny Path escape or recursive/bulk deletion outside disposable task scope; database/schema drops or truncation; production instance, cluster, storage, network, DNS, certificate, key, backup, or log deletion; secret extraction; privilege escalation; wildcard IAM; force-push/history rewrite; sandbox or policy bypasses Nobody inside Startup Factory. Use a separate human-operated break-glass process.

Require exact human approval Non-destructive production infrastructure, IAM, network, DNS, certificate, capacity, schema, backfill, traffic, cost, or scale changes; external communication A protected verifier must authorize the exact manifest, target, commit, artifact, digests, expiry, and one-use nonce. A tracker comment is not approval.

Allow within scope Read-only inspection, plans, tests, builds, linting, worktree-local edits, task-branch checkpoints, brokered integration, health checks, and a policy-clean immutable-artifact release The assigned role or deterministic executor, within its path, identity, target, quota, and lifecycle boundaries.

The full non-bypassable list and enforcement boundary are in reference/guardrails.md.

The result: you can hand real delivery work to AI agents and inspect, from your tracker, the workflow actor, workflow approvals, production approval ID, and policy denials for each delivery. Authenticated production approver identity remains in protected transaction state; tracker authorship is never treated as authentication.

Why Startup Factory

Advantage What it gives you

Move fast without merge chaos A deterministic dispatcher launches only design-approved, dependency-ready, resource-safe work. Each attempt gets its own task branch and worktree; integration stays serialized.

See the whole delivery, not just agent output One live [progress] record per [task] and one [digest] per [feature] show tracker status, execution stage, actor, and attempt in your project-management tool.

Use the right model for each job Mix Claude, Codex, Gemini, or any file-reading CLI by role, then route individual tasks to fast, standard, or strong model profiles.

Keep quality gates explicit Architecture approval precedes implementation. In Review requires independent approvals from the Principal Architect, Sceptical Principal Architect, Senior Security Engineer, and Team Lead over one exact package; optional QA may add evidence, and the integrator runs your build, test, and lint commands before merging.

Recover instead of restarting Immutable task packets, durable events, checkpoint branches, an idempotent outbox, and attempt-aware relaunches make interrupted work inspectable and recoverable.

Keep your stack and your tracker The same workflow runs across languages, frameworks, LLMs, and project-management tools. Start offline with Markdown and switch adapters without rewriting the process.

Turn the board into a safe delivery queue A deterministic cron/service pass observes queued/blocked work, restores in-flight runs, chooses an explicit team preset, and launches LLMs only for eligible queued tasks.

Pause one task without stopping the factory On the next scan, [Blocked] immediately fences only the matching task. Independent ToDo work and other features continue; only a human can unlock it.

Keep dangerous authority out of agents One deny/approval/allow contract governs every role. The code gate blocks dangerous privileged release hooks and plans; your required OS sandbox and least-privilege identities enforce ordinary-agent filesystem, network, process, and IAM boundaries.

Superpowers + Startup Factory: split the SDLC by strength

obra/superpowers and Startup Factory operate at different, complementary levels.

Superpowers is an engineering methodology packaged as agent skills. Its full upstream workflow can cover brainstorming, implementation planning, worktree creation, task execution, TDD, debugging, code review, verification, and branch completion. Startup Factory is a project delivery control plane: it coordinates product, architecture, implementation, security, quality, integration, portfolio automation, and production release across durable tracker state and multiple independent agents.

The combined integration deliberately uses the strongest part of each system without running two execution orchestrators:

Superpowers shapes the idea into an approved specification and detailed implementation plan.

Startup Factory reviews those documents as inputs, creates and governs the tracked delivery, and owns execution through verified production.

Claude task workers may use focused Superpowers methods for TDD, debugging, receiving review, and fresh verification inside their one assigned task.

Superpowers does not create a second worktree, dispatch a second team, execute the plan, merge the branch, or declare the feature released.

flowchart LR Idea["Product idea or ticket"] Brainstorm["Superpowers brainstorming questions · alternatives · approved design"] Plan["Superpowers writing-plans exact files · interfaces · tests · commands"] Handoff["Digest-bound planning handoff committed spec + plan"] Shape["Startup Factory planning review Product · Lead · Principal · Sceptical"] Tracker["Tracked feature and tasks acceptance · dependencies · resources"] Execute["Startup Factory execution packets · branches · worktrees · dispatch"] Methods["Claude-local Superpowers methods TDD · debugging · review response · verification"] Review["Exact-package review board Lead · Principal · Sceptical · Security"] Integrate["Serialized integration validated feature branch"] Release["Protected CI and release policy · approval · deploy · verify"]

Idea --> Brainstorm --> Plan --> Handoff --> Shape --> Tracker --> Execute Execute --> Methods --> Review --> Integrate --> Release

Loading

Why divide the lifecycle

Reason Benefit

One authority per stage T

[truncated for AI cost control]