You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+26-16Lines changed: 26 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
[](https://simplycubed.com/code?utm_source=github&utm_medium=readme&utm_campaign=code)
4
4
5
-
An autonomous coding agent that lives inside your own GitHub. You file an issue, it opens a pull request, and a human decides whether to merge.
5
+
SimplyCubed Code is an autonomous coding agent you install into your own GitHub. Your team files an issue, the agent prepares a pull request in your repository, and one of your reviewers decides whether it ships.
6
6
7
7
> Beta, at `v0.1.9`. Product overview: [simplycubed.com/code](https://simplycubed.com/code?utm_source=github&utm_medium=readme&utm_campaign=code). See [Status](#status).
8
8
@@ -16,25 +16,37 @@ That runs the whole loop, including the model and your own gate. It makes no Git
16
16
17
17
`simplycubed init --workflow` also writes a self-test into your repository. Dispatch it once and it checks, in your own runner, that the App token resolves to a bot, that it can read what it needs, and that it is denied Actions administration. The install fails if that denial does not hold. Delete the workflow once it passes.
18
18
19
-
## What it is
19
+
## Product overview
20
20
21
-
SimplyCubed Code turns a GitHub issue into a pull request without a person writing the code. A human files an issue describing the change; the agent implements it against the repo's own quality gate and opens a pull request for a human to merge. When a human then requests changes on that pull request, a fixer role reads the feedback, addresses it, re-runs the gate, and pushes back to the same branch for another look.
21
+
SimplyCubed Code turns a GitHub issue into a proposed code change inside your own environment. Your team keeps the repository, runners, secrets, and branch protection rules. The agent does the implementation work, but it never merges its own pull requests.
22
22
23
-
It proposes. It does not dispose. The agent never pushes to `main` and never merges its own work. A person is always the one who clicks merge.
23
+
For a customer team, the model is simple:
24
24
25
-
The part that makes it different from hosted coding agents is where it runs. Everything happens inside your own GitHub Actions, on your runners, using your minutes and your secrets. SimplyCubed hosts nothing, runs no server on your behalf, and never sees your code or your credentials. Compare that to tools like Copilot's coding agent, Devin, or Codex cloud, which run the model against your code on someone else's infrastructure.
25
+
- Your developers describe work in GitHub issues.
26
+
- SimplyCubed Code implements against the repository's existing quality gate, such as `make check`.
27
+
- The agent opens or updates a pull request for human review.
28
+
- Your team keeps final control over merge, release, and production access.
29
+
30
+
The product is designed for teams that want autonomous implementation without handing their source code or GitHub credentials to a hosted vendor runtime. Everything runs in your own GitHub Actions environment, on your runners, using your secrets.
31
+
32
+
## Why teams use it
33
+
34
+
- It runs inside your GitHub, not SimplyCubed's infrastructure.
35
+
- It uses your repository's existing quality gate instead of inventing its own definition of done.
36
+
- It is built for a human-review workflow, not auto-merge automation.
37
+
- It keeps permissions narrow: the agent can propose changes, but not deploy or merge them.
26
38
27
39
## How it works
28
40
29
-
The loop is issue to pull request, driven entirely through GitHub.
41
+
The customer workflow is issue to pull request, driven entirely through GitHub.
30
42
31
43
1. A human files an issue and applies the `sc:go` label. That label is the only thing a person applies to start the work.
32
44
2. The agent implements the change on a branch and runs the repo's own quality gate, using the gate's output to guide each retry until it passes or it stops and asks for a human.
33
45
3. Once the gate passes, the agent opens a pull request and hands it back to a human.
34
46
4. A human reviews. If they request changes, a fixer role reads the feedback, makes the changes, re-runs the gate, and pushes back to the same pull request for another look. Only feedback left against the current head is addressed, so the loop never re-litigates a comment it already handled.
35
47
5. A human merges. The agent does not.
36
48
37
-
An automated reviewer runs before step 4 if you turn it on (`review: true`, off by default). It comments; it never approves and never merges. Step 5 is a human either way.
49
+
An automated reviewer can also run before human review if you turn on `review: true`. It comments on the change; it does not approve and it does not merge.
38
50
39
51
### Label lifecycle
40
52
@@ -78,11 +90,11 @@ flowchart LR
78
90
79
91
A plain comment in the conversation box is not a review. To run the fixer from a review, submit it through **Files changed → Review changes**. Every path checks that the person has write access before anything else happens.
80
92
81
-
## Running in your own GitHub
93
+
## Deployment model
82
94
83
-
The whole thing runs on GitHub Actions, event-driven, with no server and no VM for SimplyCubed to operate. When you install the app and file issues, the work executes on your runners inside your organization.
95
+
SimplyCubed Code is deployed into your GitHub organization. There is no SimplyCubed-hosted control plane managing your repositories for you. When your team installs the GitHub App and adds the workflow, the work runs on your runners inside your account.
84
96
85
-
### What it can do to your repo, and what stops it
97
+
### What it can do, and what stops it
86
98
87
99
It can open a pull request against a branch. That is the strongest action available to it.
88
100
@@ -95,20 +107,20 @@ What stops it, roughly in order of how much you should trust each one:
95
107
5. Neither engine's "dangerous" bypass flag is set. When a change cannot be made under those constraints, the run stops and a human finishes it. [Why](docs/faq.md).
96
108
6. No deploy credentials, and no path to production. Your branch protection rules decide what happens once the pull request exists.
97
109
98
-
What this buys you:
110
+
What that means for customers:
99
111
100
112
- Your code stays in your repos. SimplyCubed never receives it.
101
113
- Your model provider keys, the GitHub App's private key, and any other secrets stay in your GitHub secret store. They are read by your own Actions runs and never transit our infrastructure.
102
114
- It does not use the engines' "dangerous" bypass flags, and does not receive a GitHub token in the model's shell. When a change cannot be made under those constraints, the run stops and a human finishes it. See the [FAQ](docs/faq.md).
103
115
- The agent holds no deploy credentials and has no path to production. The most it can do is open a pull request against a branch. A human and your branch protection rules decide what happens next.
104
116
105
-
Setup files are written locally by `simplycubed init` and merged by a human, because the runtime holds no `workflows` permission and cannot add its own workflow files.
117
+
Setup files are generated locally by `simplycubed init` and then merged by a human, because the runtime holds no `workflows` permission and cannot add or update workflow files on its own.
106
118
107
119
The GitHub App identity is `simplycubed-code[bot]`. That bot is the single audit signal for everything the agent does.
108
120
109
121
## Getting started
110
122
111
-
Start with the adopter quickstart in [docs/setup.md](docs/setup.md). It covers the shipped path from CLI install to the first issue-driven pull request, including where the Azure endpoint and key live for local CLI runs versus GitHub Actions.
123
+
Start with [docs/setup.md](docs/setup.md). It walks through customer installation in a repository you control, from CLI install through the first issue-driven pull request.
112
124
113
125
## Installation
114
126
@@ -123,9 +135,7 @@ That prints `0.1.7`. Pre-1.0 releases follow semver with the usual caveat: minor
123
135
versions may still change behavior. Pin the tag you have validated rather than
124
136
floating on `@latest`.
125
137
126
-
Then follow the [quickstart in `docs/setup.md`](docs/setup.md) to write the repo
127
-
config, add the caller workflow, set the Azure values, and open the first pull
128
-
request.
138
+
Then follow the [setup guide in `docs/setup.md`](docs/setup.md) to add the repository config, install the GitHub workflow, set the required credentials, and run the first issue through the system.
![simplycubed-code[bot]](https://avatars.githubusercontent.com/in/4425872?v=4&size=40){kind=avatar}
![simplycubed-code[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png?size=40){kind=avatar}
0 commit comments