Solutions, by the problem you arrive with
Signoos is one product — a repository, a team, and the tasks between them — but people arrive at it from different problems. This page gives the solution to the four or five most common ones in the product's own terms, with a link to the mechanism behind each answer.
Engineering leaders
You delegate work in sentences, not issue templates, and you need to know later what was asked and what happened. In Signoos a task holds the ask in your own words, the files the localizer bound it to, the branch it is judged on, every advisory review of every push, and the conversation around it — including the disagreement. Nothing in that chain is a summary of something else: each part links to what it was derived from.
The review on each push is measured against what was actually asked rather than against the diff alone, and it is advice: it cannot block a merge or close a task. Only a human closes work. What that buys you is a review your team reads instead of routes around.
Product managers
Insights is the optional layer for the question “what do our users keep asking for that we have not planned?” Add review sources in project settings and a ten-stage pipeline mines the latent needs out of them, tests each against what the GitHub roadmap already covers, and ranks the gaps that survive.
Every number is computed rather than asserted, every quote is verified against its source, and 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 that carries its own evidence and — where you allowed code access — the file and lines it lands in, so the handover to engineering is the ticket itself.
Developers
Your tasks are where you work. @signoos/cli puts them in the terminal — list what is assigned to you, read one with its thread, and connect a machine once with a rotating device credential that carries task-read scope and nothing else. @signoos/mcp puts the same two reads inside your editor, so an assistant you already use can see the task without you pasting it.
The AI on a task is advisory throughout: reviews are comments you can answer, the solver's output is a patch on the thread, and pushing it is your decision and your button — one commit, to the task's own branch, with a pull request your team reviews. Nothing Signoos does is ever merged for you. Setup for both clients is in the documentation.
Adopting AI with a boundary
The blocker is rarely capability; it is what the tool is allowed to touch. Signoos' answer is four mechanisms rather than a policy statement. Code access is off until you turn it on, folder by folder, enforced at the one choke point every read passes through, failing closed. No GitHub credential is stored — installations mint hour-long tokens at the moment of use. Every AI job is a role with a model you choose and a daily spend ceiling checked before each call. And a result is a draft until somebody pushes it, on purpose, to its own task branch as a pull request — never a merge, and never at all where a leader switched pushing off.
The AI processing page lists what leaves the system, job by job, which provider receives it, and the caps — including the two jobs that always run on our own OpenAI account, and how to use Signoos with no AI access to your code at all.
A record of every decision
When work is delegated in chat, the ask, the code, the review and the decision end up in four tools and agree with none of them. Signoos keeps them as one object, and keeps the parts that are usually lost: the review that disagreed, the answer the developer gave it, the candidates a localization offered when it could not be certain, and the model that actually ran when the assigned one could not.
Six months later, “why is the code like this?” has an answer you can open rather than reconstruct.
Passing a security review
Signoos is built to be checked rather than trusted. The security overview describes each control as a mechanism a reviewer can verify: consent enforced in one place and failing closed, no stored repository credential, __Host- session cookies with two-factor and re-proven identity for privileged actions, deny-by-default data rules with every request checked for project membership, a solver sandbox holding no credentials at all, and a nonce-based content security policy with zero inline scripts in the application.
The Privacy Policy names every sub-processor individually rather than by category, states the real retention periods, and lists the seven cookies that are actually set. If your review needs something those pages do not answer, ask us — an unanswered question is a finding.
Where to start
Connect one repository, answer the code-access question, and delegate a single task. That is enough to see the whole loop: localization, the branch, a review on the first push. The documentation walks through the first ten minutes, and every answer you give — including the code-access one — can be changed or withdrawn later.

