accint-solve — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited accint-solve (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
AccInt is a local-first MCP memory server for coding agents. It keeps a scored record of retrieved experience, open commitments, continuation frames, and outcome feedback so the next agent run can build on what actually worked.
Use this skill when AccInt is already configured in the host as an MCP server. The skill adapts AccInt's public solve Claude skill into a host-agnostic workflow for Claude Code, Codex CLI, Cursor, Gemini CLI, OpenCode, and other agent runtimes that can call MCP tools.
debugging history, repo-specific habits, or maintainer feedback may matter.
commitment ID that can later receive a real outcome.
before submitting a proposal back to the memory loop.
reality signal to close the commitment with an honest outcome.
configure AccInt, then rerun the workflow.
Use the host's available MCP/tool list to confirm an AccInt server exposes the two verbs:
acc_retrieve(query)
acc_act(runtime, input)If the host names the tools with a namespace prefix, use the equivalent AccInt MCP verbs. If neither verb is available, stop and ask the user to configure AccInt rather than inventing memory results.
Before a non-trivial step, retrieve relevant prior work:
{"query": "the concrete task or subtask you are about to perform"}Read the returned memories and cite the [ids] you actually build on. Treat retrieved memories as evidence to consider, not as a substitute for inspecting the current repository, running tests, or checking live external state.
solveOpen an AccInt commitment for the concrete goal:
{"runtime": "solve", "input": "the concrete goal to accomplish"}If the response is final, use the answer, commitment ID, and cited memory IDs. If the response is a brain_frame, keep the reasoning in the current session: inspect the frame, resolve the missing judgment or knowledge from the workspace, then submit a concise proposal through continue.
For a returned frame, submit only the frame ID and your proposal text unless the host explicitly manages tokens for you:
{
"runtime": "continue",
"input": {
"frame_id": "bf_...",
"proposal_text": "reasoned answer, plan, or decision grounded in the current evidence"
}
}Do not leave a received frame unresolved. If the frame expires, close or rerun the bound commitment rather than pretending the continuation succeeded.
Do the actual work in the repository, browser, shell, issue tracker, or other real environment. Verify with the strongest relevant evidence available: tests, builds, linters, link checks, PR state, screenshots, maintainer replies, or production telemetry.
AccInt stores the learning loop; it does not replace the work or the evidence.
When reality answers, record the result:
{
"runtime": "outcome",
"input": {
"ref": "solved:...",
"good": true,
"note": "brief evidence: tests passed, PR merged, deploy succeeded, reviewer accepted, or exact failure reason"
}
}Use good: false when the approach failed. Do not tag an outcome as external or owner-validated unless a real external system or the owner actually supplied that verdict.
1. acc_retrieve({"query":"fix failing parser tests in this repo"})
2. Read the returned memories; cite only the relevant [ids].
3. acc_act(runtime="solve", input="Fix the failing parser tests and verify them")
4. Inspect the repo, edit files, run the parser tests.
5. acc_act(runtime="outcome", input={"ref":"solved:...", "good":true, "note":"parser test command passed"})AccInt returns frame bf_123 asking for a judgment about whether to patch the
schema or the caller.
1. Inspect the schema and caller in the current repo.
2. Decide from code evidence, not memory alone.
3. acc_act(runtime="continue", input={"frame_id":"bf_123", "proposal_text":"Patch the caller because..."})
4. Continue implementation and verification.[ids] whenever they shape your plan or answer.credentials, identity, or history the repository cannot prove.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.