CAPABILITIES
Everything the Arcane framework does
Every capability that ships today, by theme. Each line says how it holds (a CLI check, a spell step or a convention) and keeps its limit in the sentence. Filter by any of the three.
100 lines · checked against arcane-cli 1.12.4 · updated
https://arcaneai.net/capabilities · checked against arcane-cli 1.12.4 · 2026-10-26
Start here
- Evidence before "done". Only "succeeded" may be called done, and each merge is checked against the issues it closed.In: Session discipline · Commits and pull requests
- Provenance. A hash for every file the CLI placed; agent commits made through the spells name the agent and the model.In: Context that travels with the repository · Commits and pull requests
- Gates that block. A blocked repository refuses to push, even with --no-verify; updates refuse to run over uncommitted work.In: Safety gates · Context that travels with the repository
- Decisions on record. Numbered against the trunk so that branches do not collide, and superseded in place with a link back.In: Decisions on record · Decisions on record
What it does not do
- It does not run your agents or call an AI model. The spells are instructions your AI client follows; the CLI installs them, keeps them current and checks the repository.
- It does not intercept raw git. A commit you type by hand skips the spells' approval and test gates.
- The credential scan looks for known patterns: it can find a leak, never prove a commit is clean.
- The push controls stop an accidental push, not a determined operator.
How a line holds
- CLI
- The spell command, or a hook it installs, does it.
- Spell step
- Your AI client does it when the work runs through the spells.
- Convention
- The standards ask for it; nothing checks it.
Showing 100 of 100
CONTEXT
Context that travels with the repository
One command installs your standards into any repository: governance documents, spell prompts and agent definitions, with a manifest that records a hash of every file it placed.
Pick how much to install: everything, a lighter set, methodology only, documentation only, or governance only.
Updates keep your edits. A file you edited is three-way merged with the new version, with conflict markers where the two disagree, or left untouched with a warning when offline. Leftover files are reported, and removed only on request and only when untouched: by recorded hash or, for files installed before hashes, by git (tracked, clean, one commit), which cannot see an edit made before the first commit.
Customized client shims are kept byte for byte, including one trimmed to its include line. A shim that is a symlink, or whose body is only a path, is rewritten as a regular file; every conversion is listed, and spell doctor blocks on any left behind.
A repository set to take its spells from the machine-wide install refuses to update on a machine that has none, and names the fix, instead of leaving instructions that point at nothing.
Define your agents once; the CLI writes them where Claude Code, GitHub Copilot and Codex each expect them, and can install the spells once per user instead of per repository.
Three versions are compared by spell status and at session open: your managed files, the installed CLI and the latest published release; a drift diagram shows which one is behind.
A doctor check confirms the files a session needs to resume (the open-items list, the decision log, the agent context file, the journal folder) exist, and creates missing ones on request.
Every document carries front matter (title, audience, date, status, tags) and wiki-links so agents navigate by following references instead of searching.
Updates refuse to run over uncommitted changes or outside a git repository.
SESSIONS
Session discipline
Every session opens by rebuilding context from the repository and closes by writing a dated journal entry and a handoff block the next session reads first.
The handoff's "needs you" items surface above everything else at the next open, and pending verifications are re-checked rather than repeated.
Unfinished work must exist in the open-items list or your tracker before a handoff counts as consumed; the handoff is a pointer, never the only copy.
A read-only session never creates a branch. The first write triggers a guard that creates a dated session branch, renames a tool-generated name, or keeps a branch that already backs a pull request.
Each session picks where it runs: the primary checkout, a linked worktree or a full clone, and serializes work whose files overlap instead of isolating it.
At close, every piece of background work is classified succeeded, failed, pending, dispatched or unverifiable; only "succeeded" may be called done.
Lessons learned at close are routed to the feedback file or the idea book after one batch approval; nothing is posted publicly.
Branches are deleted only after a content check proves everything in them landed; branches with unmerged content are reported, never deleted.
Every spell report ends with one block of the actions only you can take, each with the reason the agent could not do it.
With Azure DevOps as the external tracker and its MCP server connected, open pull requests are listed at session open with age flags. Azure DevOps only, and only with its MCP server connected.
DRIFT
Drift detection
Detects drift at session open: journal order, done-versus-carried-forward items, decision ids that do not exist or skip a number, installed files that differ from the canonical ones, hub-only content that leaked into a product repository.
Drift findings are graded and reported with the exact fix; nothing is edited unless you pass --fix, and only mechanical, unambiguous fixes are applied then.
High-severity drift stops the session until you decide what to do.
Doctor flags placeholders left unresolved in active governance documents.
THE LOOP
The Spell Loop
A six-spell loop from idea to merged pull request: plan, architect, implement, test, review, ship, each consuming the previous one's artifact.
The full-cycle chain gates every phase: testable acceptance criteria, a validated story schema, a halt after three stuck attempts, at most two fix loops for coverage and two for review, any high finding blocks, one human gate at pull-request approval.
The chain discloses what its sandbox could not verify before asking for a merge.
A PRD enhancement pass scores seven dimensions bronze to gold, always adds a security baseline, forces prioritization when scope doubles, never removes an original requirement, and replaces the PRD only with your approval.
Oversized PRDs are split into epics before architecture.
The implement loop commits once per story, marks and skips a stuck story, and keeps a progress file.
The bug spell records the bug in your tracker, checks the environment before the code when it "worked before", and requires a regression test.
Work items are created in the tracker you configured, with a type fallback that never flattens the hierarchy silently.
REVIEW
Review and quality
Adversarial review across six lenses with a pass/warn/fail table, stable finding ids, graded severity, and no finding quota.
The verdict goes into the pull-request body and as a formal review vote; the reviewer lifts its own block when the fix lands.
A batch review covers every open pull request and gives a single go or no-go.
A security review that never skips an OWASP category, adds an AI-agent risk pass, and audits dependencies and secrets.
Coverage thresholds of 80 percent, 95 percent on the critical path, with every acceptance criterion mapped to a test. The loop applies whatever thresholds your project configures; these numbers are the shipped standard.
Ship refuses without an open pull request, a real merge-and-test against the target and a version bump, and asks for human approval with a rollback plan before production.
A compliance review against written GDPR, CCPA, SOC 2 and HIPAA rules, read-only and cited by rule id. It reports; it never gates.
A search and AI-assistant discoverability audit for web properties, dry run by default, verified by re-fetching.
A mobile store deployment spell with release standards built in.
COMMITS
Commits and pull requests
No commit without your approval in an interactive session: the spell shows the diff and the message, fingerprints that exact pair, and re-checks the fingerprint right before committing. Through the spells; a commit you type by hand is not intercepted.
The spells stop on main and move the work to a topic branch; a pull request is the only road to main.
Conventional Commits, one purpose per commit, mixed batches split.
Every agent commit made through the spells names its agent, model, model source and provider in trailers, and the approving human is the committer.
The commit spell halts when tests fail or coverage is under the project's threshold.
A mandatory fetch and rebase on the target branch precedes every pull request; conflicts hand off to a dedicated sync spell.
The pull-request body is written to a file before anything is pushed, carries a branch marker, and is read back after creation to catch an empty or mismatched title or body.
Never squash: merge or rebase-and-fast-forward only, with a human approval bound to the pull-request id and head commit.
After a merge the spell checks that each closed issue's change is actually in the merged diff.
A stale pull request is synced safely: a backup tag first, conflicts classified, ambiguous ones abort, gates run before a force-with-lease push.
Review comments are addressed with a plan you confirm, one approved commit per fix, a tracked item for anything deferred, and every thread resolved or listed.
A warn-only pre-push hook tells you when the branch's pull request is already closed or merged. GitHub remotes with the gh command only.
A push to a merged pull request is stopped by the spell.
SAFETY
Safety gates
A recorded push policy per repository: open, guarded (every push needs your explicit confirmation; unattended runs never push) or blocked. Guarded is held by the spells; blocked by a hook.
Blocked means blocked: a pre-push hook refuses, and every remote's push URL is pointed at a sentinel so --no-verify does not help. A remote added later keeps a live URL until the block is re-applied; spell doctor names it and the fix.
No flag can loosen a push policy. Lifting a block takes an interactive terminal and the repository's name typed in full.
A pre-commit hook scans every commit for credentials (API keys, bearer tokens, private keys, cloud and chat tokens), and the same scan runs repository-wide on request. Detection by pattern, not prevention: it can find a leak, never prove a commit is clean.
A ward scan finds leaked identifiers (your own terms, plus a built-in vendor list) in content and file names, and can fail a build with --gate.
Doctor reads your platform's merge policy (GitHub rulesets or Azure DevOps branch policy) and warns if squash merges are still allowed. Report only.
Doctor verifies that a blocked policy is actually in force and lists where a guarded repository would push.
Hooks are installed only where no other hook manager owns the path; the installer fails closed.
The CLI's own git calls can never hang on a prompt and time out by command class.
Uninstall refuses while a push block is in force.
Recommendations that lead to a purchase, a subscription, an account or an irreversible action are flagged, verified against current facts, paired with a free alternative, and confirmed explicitly above a stated amount.
Repositories marked sensitive are cited by path, never by content, and keep no screenshots.
DECISIONS
Decisions on record
Two prefixes keep organization decisions and framework decisions apart; merged records are never renumbered.
Decision numbers are allocated against the trunk at session close (fetch, then highest plus one), so parallel branches do not collide; a local-only repository says so.
A lean decision format under twenty lines, a required "naming impact" section whenever a name changes, and companion documents for the long version.
Records are superseded in place with a tombstone header and a reverse link; nothing is deleted without a recorded decision.
The decision ids the framework cites ship with it, so references resolve offline in any repository.
A root-cause analysis is required before a correction that touches many files, filed by number, never auto-committed.
A verification ledger records only claims that were actually checked, and the program report reads it.
A program report is generated offline from the plan, the operator queue, the ledger and git history, as JSON and HTML.
AGENTS
Agents and trust
Six trust levels per agent per repository, from spectator to archmage; an agent may commit and merge on its own only from level four, and otherwise queues a pull request for a human. Resolving the level is a spell step; assigning it is a convention.
Every agent starts at the lowest level and is promoted only after a validated fix-and-verify loop.
One agent per branch, one owner per feature folder, an append-only progress file, and a vantage-point check before any branch is pruned.
Twenty-seven universal rules every agent follows, from "no secrets on the command line" to "a zero-match search is evidence about the pattern, not about absence".
Permitted and prohibited action lists with a stop-log-queue escalation path.
Approved paths per agent, narrowest access, and standing delegations in a file doctor lists. Doctor lists them; it never grants access.
Twelve built-in personas that ship anywhere, re-skinnable into any universe, with the publishing checklist in the box.
Doctor warns about MCP servers configured without a timeout.
MANY REPOS
Many repositories, one hub
One repository can be the hub for many: it records the role, keeps a registry of its products, and scaffolds a new one from a template.
Ideas and open items flow from the hub to a product repository through a triage spell with a disclosure gate keyed on the destination's visibility and a leak scan for hub-only names and paths.
Idea books and open-items books with capture, elaboration, counting, validation and pruning spells; destructive passes need a fingerprinted approval and never touch unchecked items.
Feedback about the workflow is captured append-only and routed upstream only after an explicit disclose.
Each repository records its role, tracking mode (internal or an external tracker), content sensitivity and push policy once, in a manifest with a flag for every question.
Running from an AI harness with no terminal, the CLI prints the exact flags for the questions it could not ask instead of guessing.
NAMING
Naming and documentation
A name-clearance spell checks a candidate against your own repository first, then the outside world, and returns pass, pass-with-disclosure or kill.
Three naming tiers that never mix: machines, agents, services.
One canonical prompt file per spell with generated client shims; every workflow carries the same prefix and session work comes as an open/close pair.
Spell prompts are graded on an eight-dimension rubric with a hard floor: no real organization, person or machine names, placeholders instead. Self-graded; only the placeholder floor is checked, and only in the framework's own repository.
Bring an existing documentation tree under governance: dry run first, one commit per step with a rollback, nothing deleted or overwritten.
Turn an analysis from a conversation into a permanent reference document, with a diff before any overwrite.
Executive summaries on operational documents and a fixed troubleshooting format.
Helper spells: brainstorm three to five options before committing, explain a concept without modifying anything, present the framework from live repository state.
STANDARDS
Standards that install like packages
Written standards for testing, CI/CD, branch policy, deployment gates, authentication, threat modeling, host hardening, compliance, mobile releases and web discoverability, installed as versioned files you update like a dependency. Each rule states its own enforcement mode.
CI skip decisions come from changed paths, never from commit messages.
A proof-of-concept pattern where ideas are never deleted, and a new-business setup guide.