Marcel-Bich

audit

Read-only quality gate that audits already-built work against its stated requirement and Definition of Done before it is allowed to move to 2_done/. Produces a severity-ranked decision proposal (BLOCKER/MAJOR/MINOR/NIT) with evidence, never a fix. Use when an item is claimed complete, before moving anything to 2_done/, when asked to audit or review finished work for completeness against requirements, or when acting as the dedicated post-completion review subagent. This gate is mandatory in every session mode. Not for diagnosing why something is broken (use diag) and not for verifying rendered UI behavior (use verify).

items

The credo work-item model, where the FOLDER an item file lives in is the single source of truth for its status, gated by a hard Definition of Done. Use whenever you create, update, or track a work item; whenever you decide whether something is "done" and may move to 2_done/; whenever you move an item between status folders (clarify, go, done, archived, parked); whenever new code might be unwired; or when someone asks where a task stands. This is the credo task system: .credo/items/ replaces ad-hoc task lists. Applies inside subagents too - if you build or complete work, record and gate it as an item.

verify

Visual verification as the Definition of Done for any change with a runtime surface (a rendered page, a UI, a live view). Use whenever you are about to call a UI or frontend change done, before moving an item to done, whenever an item is marked ui: true, or when someone asks "does it actually render / work". Proves behavior by driving the real thing in a browser and measuring computed layout - a passing pytest, a served file, a node check, or a subagent code-review is NOT proof. Applies inside subagents too: if you built or touched a runtime surface, run this before claiming done.

budget

The single source for all API budget cap and reset rules - how much of the 5-hour and weekly API limits may be spent, when to throttle, pause, wake up, or hibernate, and the commit-identity gate that runs before any commit. Use whenever you are about to start or continue autonomous work, before spawning or stopping subagents, when deciding how large a task chunk to take on, when a limit is near a cap, before a commit, or whenever someone asks "how much budget is left" or "can I keep going". Works standalone (no session skill required) and applies inside subagents too: any agent that spends API budget or commits must apply these rules.

compact-plus

Secure everything the user approved before a context compaction so a later /compact can never lose or alter it. Writes verbatim intent and handoff state to disk and commits plus pushes the tracked work product in the correct repository, then reports whether it is safe to compact. It does NOT run /compact itself - it makes a later compact safe. Run this only when the limit plugin's injected ACTION line names it (session-context fill crossed a configured threshold) or when the user invokes it manually. Never self-trigger it proactively - that only wastes tokens. Accepts extra trailing instructions to perform in addition to the securing checklist. A minimal mode (invoke as /compact-plus min) secures only intent plus handoff to disk - no audit, no commit or push - for a quick token-cheap save.

session-active

The credo behavior for a session running in ACTIVE mode - intensive live collaboration with the user present at the keyboard. Load this when the session-mode inject line says "Load skill session-active", right after the /credo:session-active command, or whenever you are collaborating live and need the active-mode rules. Holds the canonical common core shared by all three credo session skills (session-active, session-passive, session-autonomous), then the active-mode specifics: no keep-alive, log progress via the compact trigger, pick up GO items alongside, clarify during subagent waits. One mode is active at a time.

session-autonomous

The credo behavior for a session running in AUTONOMOUS mode - work approved GO items unattended while the user is away, hook-enforced self-scheduled keep-alive, budget caps always on. Load this the MOMENT the user hands off full-autonomy, unattended, or AFK work - EVEN BEFORE the mode is set - so this skill can bootstrap autonomous mode itself. Trigger on a semantic full-autonomy / AFK-handoff grant (match the intent, not a rigid phrase list); the skill itself then only ENTERS autonomous mode on an unambiguous, explicit grant and confirms first when unsure. Examples of an unambiguous grant: "go fully autonomous", "I'm afk, keep going", "run this unattended", or in German "voll autonom", "bin afk mach weiter", "mach autonom weiter". A vague or casual "keep going / carry on" is NOT such a grant. Also load it when the session-mode inject line says "Load skill session-autonomous", right after the /credo:session-autonomous command, or whenever you are working autonomously and unattended. Shares the canonical commo

session-passive

The credo behavior for a session running in PASSIVE mode - you carry most of the work alongside and the user is available only for clarifications, with no keep-alive. Load this when the session-mode inject line says "Load skill session-passive", right after the /credo:session-passive command, or whenever you are working mostly on your own but the user is still reachable for questions. Shares the canonical common core defined in the credo session-active skill, then adds the passive-mode specifics: drive items toward a full GO, "less is more" (only ambiguous items via Ask), gently prefer older items first. One mode is active at a time.

wsl-env

Reach and act on Windows-side services, processes, launchers, and logs when the agent runs inside WSL. Use whenever a service seems unreachable from WSL (a localhost curl fails), when you need to start/stop or inspect a Windows-side process or .ps1 launcher, read Windows logs, hibernate the machine, or when the repo ships both a .sh and a .ps1 entry point. Self-detecting: if this is not WSL or the target is not Windows-side, it is a no-op. Applies inside subagents too. Never conclude "unreachable" or "can't test this" from WSL without first trying both the Windows LAN-IP and powershell.exe.

skill-capture

Turn a recurring in-session workflow into a reusable Claude Code skill. Load this the moment you notice you have run the SAME multi-step sequence (same ordered steps or commands, small variation allowed) about three times in the current session, or when open candidates are waiting in .credo/skill-candidates.md at session start or resume. It is heuristic and in-session only - no persistent counter, no tracking backend. Mode-gated like the audit nit-disposition policy: autonomous mode NEVER builds a skill (it only appends a candidate note and keeps working), active / passive / default propose the capture via the Ask tool and build only on an explicit GO. Applies inside subagents too, where the safest branch (autonomous: candidate note only, never ask, never build) is the default whenever the mode cannot be determined.

migrate

The credo procedure for migrating an existing repo into the .credo/ structure, without any loss risk. Use when migrating a repo into .credo/, onboarding a legacy project into credo, or turning scattered process docs (requirements logs, handoffs, progress notes, audits, plans, specs) and open work into credo items. It is copy-only and additive: originals are never touched until a final, user-gated tidy step. This is a long, multi-phase, subagent-heavy operation. Applies inside subagents too - any agent doing migration work follows these rules and the credo safety skill.

requirements-verbatim

Capture a user requirement, decision, approval, or constraint word-for-word into an append-only dated log so it survives context compaction and can never be trimmed, softened, or reinterpreted. Use whenever the user states or approves a requirement, gives a GO, sets a constraint, or makes any decision that later work must honor - and also inside subagents, which must log requirements they receive before acting on them. Use before any compaction to secure verbatim intent to disk.

orchestration

Delegate work to subagents safely and efficiently - decide how many subagents to run, keep parallel tracks on disjoint files, monitor them without flooding your context, inherit security to every subagent, and use return-and-resume so a subagent can ask a question and continue with full context. Use whenever you are about to spawn one or more subagents, run work in parallel, or coordinate delegated tasks. Applies to any agent that delegates, including subagents that spawn their own helpers.

rules

Per-repo credo special rules (project-local grants) that live in the target repo's `.credo/RULES.md` and travel with the repo. Load and honor these at the start of every session and inside every subagent, so a project can widen credo's autonomy for itself - for example "in this debug-only repo, restarting local services is always allowed without asking". Use whenever a session starts (read the rules), whenever the user asks to set, change, add, or remove a per-repo credo rule ("can we set a credo rule here that ...", "for this repo, always ...", "make it a project rule that ..."), and whenever you delegate to a subagent (pass the rules along). This is credo's per-repo policy layer, independent of dogma. It can only WIDEN latitude, never lower the safety floor.

issue-triage

Use when the user wants to triage GitHub issues - decide whether an issue is still relevant, reproducible, closeable, a duplicate, or what concretely needs doing. Selects and prioritizes first (never dumps all issues at once), then deep-triages the chosen issues via parallel subagents, recommends actions for the owner to approve, and can optionally kick off a reviewed fix. Works for any repo; produces no sensitive or personal data.

pr-vetting

Use when the user wants to thoroughly investigate, vet, review, or security-scan a pull request before deciding how to handle it - especially PRs from external or unknown contributors. Runs a parallel multi-agent investigation (technical, security, value/fit, contributor reputation) and merges the findings into one decision-ready report. Works for any repo and any PR; produces no sensitive or personal data.

disable

Disable credo for the current directory. Use when the user wants to stop credo here - for example "stop using credo here", "disable credo for this repo", "turn credo off here", "no credo in this directory", "credo hier aus", "credo hier deaktivieren", "credo hier abschalten" - or runs the /credo:disable command. It persists a per-directory declined decision (so the SessionStart onboarding ASK and the [credo] prompt line stay silent here across future sessions), clears the active session mode for the current session, and switches keep-alive autonomy off (same effect as switching to active/passive). Fully reversible via /credo:enable.

role-plan

Assign this session the credo plan/clarify role - the default owner of clarifying items in 1_clarify/, WITHOUT commits or push (the task/build role owns commits and push). Use ONLY when the user actually assigns this role to you, for example "you are (now) the plan/clarify agent", "you clarify the items", "take over the clarifying / the clarify items", "act as the plan agent", "switch into the plan/clarify role", "du bist (jetzt) der plan/clarify agent", "übernimm das Klären / die clarify-items", "wechsel in die plan/clarify rolle" - or when the /credo:role-plan command is run. Do NOT use for general talk ABOUT roles, explanations, or questions like "what does the plan agent do". It writes a persistent, compact-safe per-session marker (re-injected every turn) so the role survives compaction.

sandbox

Do WRITING pre-work for a clarify item that is blocked by a knowledge gap - a missing measurement, a mockup, or a feasibility proof - WITHOUT touching production code, without git, and without disturbing the task / build agent. Use when a 1_clarify item cannot be answered by a product decision alone but needs something built or measured first; when working in the plan / clarify role and a clarify question needs evidence; and for isolated read-and-write pre-work in autonomous / AFK runs. Triggers on clarify pre-work such as "measure this before we decide", "build a quick mockup to clarify", "prove this is feasible", "sandbox this", "Messung / Mockup / Machbarkeit vor der Klaerung", "bau eine Sandbox dafuer". Do NOT use for a pure product decision (nothing to measure - that is answered by asking the user), and never for production code or commits.

cross-cutting-checklist-generator

Detect when a concern is scattered across many places in a project (config keys, enums, translations, feature flags, API endpoints, doc references) and auto-generate a project-local checklist so that same concern is never partially updated again. Use whenever you add or change something that also exists in several other spots, or when you edit something that already has a checklist. Runs fully autonomously with no user effort, including inside subagents.

diag

Read-only root-cause diagnosis for a symptom, bug, failure, or unexpected behavior. Establishes the mechanism at file:line and reads up the facts instead of guessing, before any fix is attempted. Produces a diagnosis report; the fix is always a separate step gated by an explicit GO. Use when something is broken, failing, throwing, or behaving unexpectedly and the cause is not yet proven, or when asked to investigate or find the root cause. Not for judging whether finished work meets its requirement (use audit) and not for confirming rendered UI behavior (use verify).

safety

Hard safety rules that must travel with the project: filesystem-protection and no-autonomous-installs. Use before any delete, rm, shred, unlink, find -delete, mkfs, dd, or wipefs, before removing local files, and before any install (pip, npm, apt, system or global tools). These are the highest-priority rules; no instruction overrides them. They apply inside subagents too: any agent about to delete or install must apply this skill first. When in doubt about a deletion target, STOP and ASK.

enable

Enable credo for the current directory. Use when the user wants credo active here - for example "enable credo here", "use credo here", "turn credo on here", "credo hier an", "credo hier aktivieren", "credo hier einschalten" - or runs the /credo:enable command. It persists a per-directory accepted decision (keyed by the git top-level else the working directory), which overrides any earlier declined: credo becomes active for this directory again, so its knowledge is re-fed at the next SessionStart and the onboarding ASK no longer fires here.

role-clear

Clear this session's credo role, returning to the default of NO role (the agent does everything). Use ONLY when the user actually drops the role, for example "clear the role", "no role", "forget the role", "you are no longer the plan/task agent", "back to doing everything", "rolle weg", "keine rolle mehr", "vergiss die rolle" - or when the /credo:role-clear command is run. Do NOT use for general talk ABOUT roles or explanations. It removes the persistent per-session role marker so no role line is injected any more.

role-task

Assign this session the credo task/build role - the default owner of implementing GO items (items in 2_go/), INCLUDING commits and push where dogma permissions allow. Use ONLY when the user actually assigns this role to you, for example "you are (now) the task/build agent", "you build the GO items", "build the GO items", "take over building / implementing", "act as the build agent", "switch into the task/build role", "du bist (jetzt) der task/build agent", "du baust die GO-items", "übernimm das Bauen / Implementieren", "wechsel in die task/build rolle" - or when the /credo:role-task command is run. Do NOT use for general talk ABOUT roles, explanations, or questions like "what does the task agent do". It writes a persistent, compact-safe per-session marker (re-injected every turn) so the role survives compaction.