How Skaftor works
The end-to-end model: features move through an approval workflow, agents do the work on workstations or over MCP, and every artifact is linked in the engineering memory graph.
Skaftor combines three things: a workflow that decides who approves what, agents that do the work, and a knowledge graph that remembers how everything connects.
Features and the workflow
Work enters Skaftor as a feature (planned spec-first) or a bug (straight to work orders from a repro). A feature moves through your organisation's workflow. Each step has an owner and, for approval steps, a role that must sign off before it moves on. A step can send work back to an earlier one.
Agents do the work
Agents draft requirements, write designs, cut work orders, implement them, review the code, and run QA. Heavy work runs on workstations — managed cloud machines with your repository and the agent ready — on Skaftor Cloud or in your own cloud. You can also build in your own editor, with the work order's context wired in through Skaftor's MCP server.
Turn on "Run automatically" for a feature and each stage starts as soon as the one before it is approved. The approvals stay with people.
The engineering memory graph
Every link — requirement → design section, design section → work order, work order → pull request, feedback → work order — is written as a graph edge. That's how Skaftor answers "what depends on this?" and "why does this exist?", and how it derives blast radius, traceability and drift.
Governance
Approval steps produce an audit trail. Pull-request gates check CI and the acceptance criteria; deployment gates check your app's own rules; readiness and QA decide when a release can ship.