What is Signoos, and what it does

The product in one paragraph

A team connects a repository through the Signoos GitHub App and decides, folder by folder, whether Signoos may read the code. From there the team gets a hosted repository browser kept in step by pushes, a member list, and tasks: delegated in a sentence, located in the code by a progressive localizer, bound to a branch, and reviewed by an advisory AI on every push. A task can optionally be attempted automatically by a goal loop whose result is always a draft. A per-project AI console shows which model performs which job, under daily spend ceilings. An optional Insights layer mines review sources for the needs your users keep expressing and tests them against your roadmap.

A project is one product

Everything in Signoos hangs off a project: one repository, one team, and the tasks between them. The person who creates a project is its team leader, with administrative control over its members, its AI configuration, its stored keys and its deletion. Members are found by their public username and join by invitation; a member's role decides what they see, down to a files-only role that gets the repository browser and nothing else.

Tasks, delegated in plain words

A task is written the way you would brief a colleague — no issue template, no label taxonomy. The progressive localizer reads the description and finds the files the work is about, using only the folders you shared. When it cannot find them with confidence, it says so and lists its candidates; it never guesses. The task is bound to a branch, and that branch is where the work is judged.

Each task carries its own conversation thread, where the developer, the lead and the advisory review meet — questions, decisions, drafts and dissent all live in one place, next to the work they are about.

A repository mirror you can read

Pushes keep a hosted copy of the repository in step, so the team browses files, commits and snapshots inside Signoos without leaving the product. The mirror obeys the same folder consent as everything else, checked again at the moment each file is served — sharing frontend/ never shares frontend2/, and the check fails closed.

A review on every push

Every push to a task branch gets an advisory AI review measured against what was actually asked — the task text and what was agreed on the thread — not just the diff. The review states what was asked, what the push did, and where the two differ. It is advice: it cannot block a merge, it cannot close the task, and the developer can always answer back on the thread. Only a human closes work.

The automatic solver

Ask for it on a task, and a goal loop reads the code, states an objective, plans, writes a patch and has that patch independently reviewed by a second model before it reaches you. Where an execution sandbox is configured, the verification step really runs the repository's own declared commands against the patched copy, in an ephemeral container holding no credentials. What arrives is a proposed patch on the task thread. Keeping it means applying and pushing it yourself; discarding it means simply not doing so.

The AI console

Each AI job in a project is its own role — task titles, code search, push review, thread replies, fix drafts, the solver — and the team leader assigns a model to each from a catalogue across OpenAI, Anthropic and Google. Every member can read the assignments; a role running on a fallback says so instead of pretending. Spend is the guardrail: every call is checked against a daily ceiling before it is made. Teams can bring their own provider keys, sealed with envelope encryption, and the leader decides who may spend on which account. The full detail is on the AI processing page.

Insights

Optional for any project: add review sources in project settings and a ten-stage pipeline mines the latent needs out of them, tests each one against what the GitHub roadmap already covers, and surfaces the ranked gaps with the evidence still attached. Every number is computed, every quote is verified against its source, and a candidate has to survive an adversarial pass before it ranks. “No supporting signal” is a legitimate answer and is shown as one. A confirmed gap becomes a ticket that carries its own evidence — and, where you allowed code access, the file and lines it lands in.

What Signoos never does

• It never merges, and never writes outside a branch you can throw away. The most a finished patch can become is a commit on the task’s own branch with a pull request beside it. No merge, no force-push over work that moved, no comment on your repository — and nothing at all where a team leader switched pushing off. Every result the AI produces is a draft, and a person decides what happens to it.
• It never stores a GitHub credential. The App installation is exchanged for an hour-long token at the moment of use, scoped to the repositories you picked, and allowed to expire.
• It never reads code without consent. Code access is off until you turn it on, folder by folder, and every read path enforces the same grant.
• It never trains on your content. Your code, tasks, reviews and tickets are not used to build or tune any model or product offered to anyone else.
• It never closes work. Reviews and verdicts are advice; tasks are closed by people.

For the reasoning behind these choices, read Why Signoos; for the mechanics, the documentation.