Signoos documentation, on one page

Getting started

The first ten minutes, in four steps:

1. Create an account at signoos.com/register — with an email and password, or with GitHub.
2. Create a project and connect a repository. A project is one repository and one team. The connection goes through the Signoos GitHub App — you choose the repositories the installation may see, on GitHub's own consent screen. Signoos stores no GitHub credential; each installation mints an hour-long token on demand.
3. Answer the code-access question. Off by default. Turn it on per folder if you want localization, fix drafts and the solver to see code — or leave it off and use everything else.
4. Delegate a task. Describe the work the way you would to a colleague. Signoos titles it, locates the code it is about, binds it to a branch, and reviews every push to that branch from then on.

Team members are found by their public username and join by invitation. Roles decide what a member sees: a leader administers the project, a developer works in it, and a files-only member gets the repository browser and nothing else.

Code access and consent

Consent is a per-folder rule, enforced in the one place every read goes through: the search index, the localizer, the mirror and the file browser alike. Matching is per path segment — sharing frontend/ never shares frontend2/ — and the check fails closed: when it cannot be evaluated, the answer is no.

Every AI job that could see repository contents is filtered by the grant first. Where a review diff had files removed for that reason, the model is told how many were withheld rather than being handed a diff that silently pretends to be complete. The full per-job payload list is on the AI processing page.

Tasks and localization

A task starts as a sentence. The progressive localizer reads it and searches the folders you shared for the files the work is about, one candidate at a time, narrowing as it goes. It ends in one of two honest states: located, with the files named — or not located, with its candidates listed. It never guesses, because a wrong file stated confidently is worse than a question.

Each task is bound to a branch. The branch is the unit of judgement: pushes to it are what the advisory review reads. The task's thread carries the conversation — replies from the team, replies from the AI where the leader enabled them, review verdicts, and solver drafts.

Push review

Every push to a task branch triggers an advisory review measured against what was actually asked: the task text, the located files, your commit messages, the cumulative diff of the branch, and the results of any CI checks. The review states what was asked, what the push did, and where the two differ.

It is advice by construction. It cannot block a merge, cannot close the task, and the developer can always answer back on the thread — the dissent stays on the record beside the review. Only a human closes work.

The automatic solver

Opt-in, per task. A goal loop reads the located code, states an objective, plans, and writes a patch — in steps you can watch while it runs, and stop at any point. The patch is then judged against the objective by an independent review from a second model, which reports whether the objective was met and with what confidence, including when the answer is no.

Where the team has configured an execution sandbox, verification really runs the repository's own declared commands against the patched copy, in an ephemeral container holding no credentials — and everything that comes back is treated as data, never as instruction. The result is a draft patch on the task thread. Nothing is pushed unless your team has pushing on and somebody presses the button — by default to the task's own branch, as a pull request — or unless a leader switched on the automatic commit, which is off by default. Applying it any other way is a decision a person makes, in their own working copy.

The repository browser

Pushes keep a hosted mirror of the repository in step, so the team reads files, commit history and snapshots inside Signoos. The browser serves only what the folder grant allows, re-checked when each file is served, and renders code with syntax highlighting — read-only, like everything else that touches your repository.

The AI console

Every project has one. Each AI job is a role — task titles, code search, push review, thread replies, fix drafts, the solver, project Q&A, ticket drafting — and the team leader assigns a model to each from a catalogue across OpenAI, Anthropic and Google. Every member can read the assignments; only the leader changes them. A request always names a role, never an endpoint or a key, and if the assigned model cannot answer, the result says which model actually ran and why.

Spend is governed by daily ceilings, checked before every call. Teams can bring their own provider keys — sealed with envelope encryption, never returned by any endpoint — and the leader decides, per member and per provider, whose account pays.

Insights

The optional review-mining layer. Add review sources in project settings and a ten-stage pipeline mines latent needs out of them, tests each against what the GitHub roadmap already covers, and surfaces ranked, evidence-traced gaps with computed confidence. Quotes are verified verbatim against their source; a candidate must survive an adversarial pass before it ranks; “no supporting signal” is a result, not an error. A confirmed gap becomes a ticket carrying its own evidence and, where code access allows, the file and lines it lands in.

The command line: @signoos/cli

Signoos from the terminal: the tasks assigned to you, located in the repository you have open. Zero runtime dependencies, by policy — this binary handles a credential, and every package it would pull in is a party to that. Requires Node.js 20 or newer.

npm install -g @signoos/cli

Or run it without installing: npx @signoos/cli login.

signoos login              Connect this machine to your Signoos account
signoos projects           List the products you belong to and their repositories
signoos tasks              List the tasks assigned to you in this repository
signoos task tsk-4         Show one task in full
signoos setup [client]     Print the MCP config for your editor
signoos doctor             Check this machine's setup and say what to fix
signoos account            Show the account this machine is connected to
signoos logout             Sign this machine out and revoke its credential

signoos login opens your browser; on a machine with no browser — an SSH session, a container — use signoos login --manual and complete the sign-in elsewhere. signoos tasks and signoos task use the repository you are standing in; pass --repo owner/name when there is no origin remote to read.

One machine holds one account. The durable credential is a rotating refresh token in ~/.signoos, hardened to your OS user; access tokens live in process memory only. signoos login on a connected machine tells you who it is connected as and stops — signing in never signs anyone out. Disconnecting is signoos logout, which revokes the machine's credential server-side. signoos doctor verifies the setup, including warning when the credential directory sits in a synced folder.

The editor server: @signoos/mcp

A stdio MCP server that gives your editor's agent read access to the Signoos tasks assigned to you — and nothing else. Your editor spawns it; you do not run it yourself. Connect the machine once, then let the CLI print the config block for your editor:

npm install -g @signoos/cli
signoos login          # once per machine
signoos setup cursor   # or: claude-code, vscode, codex, kiro, windsurf

It exposes two tools:

Its security properties are deliberate:

• No secret in any config file. The editor config names a command; the credential lives in ~/.signoos, managed by the CLI.
• Read-only by construction. The device credential carries task-read scope only — settings, consent, team, budgets and billing are unreachable regardless of what any prompt says.
• The human discussion thread is excluded from get_task on purpose: task comments are untrusted text relative to the agent reading them, so the payload carries only the ask and material Signoos itself generated.
• Every field an agent receives is capped and validated. File paths must be repository-relative, branch names must be valid git refs, and anything dropped is counted in the payload so the agent asks rather than improvises.

Devices and revocation

Every connected machine is listed at signoos.com under Configurations → Devices, and can be revoked there — effective on the machine's next request. A device credential ever used twice, as happens after a backup is restored, revokes itself and emails you: that is the reuse detection working, and reconnecting is one signoos login.

Going deeper

• AI processing — which providers may receive your content, what is in each request, and the caps.
• Security — the security model, from consent to the sandbox to vulnerability disclosure.
• Terms of Service and Privacy Policy — the agreement and what we hold.
• Community — where to get help, report an issue, or tell us what to build next.