tinkabot

Triggers on /c3 or architecture questions in projects with .c3/ directory. Phrases: "adopt C3", "onboard", "where is X", "audit architecture", "check docs", "add component", "implement feature", "what breaks if I change X", "add ref", "coding standard", "edit the canvas", "add prd/user-story". Ops: onboard, query, audit, change, ref, rule, canvas, sweep. The CANVAS is your architecture's own vocabulary; onboarded facts FREEZE; work advances by change-units. Classifies intent, loads the reference, runs the CLI.

Use when design, planning, implementation, or delegation risks mixing abstraction layers or skipping from high-level intent to detail too quickly; triggers include architecture decisions, design artifacts, testing strategy, implementation plans, task handoffs, layered docs, orchestration, decomposition, verification strategy, artifact-set refinement, derive/match review surfaces, and strategy-to-execution drift.

A workflow for turning goals, objectives, missions, measurable improvements, or decision-oriented research into a self-correcting OKR loop with measured anti-goal guardrails. Use when the user is setting OKRs, planning toward a metric, asking how to make progress without breaking a constraint (budget, quality, risk, trust), or wants delegated loop execution with human control. Trigger even for "help me set a goal", "what should my OKRs be", "I want to grow X", or open-ended research that needs DKR discovery to reduce uncertainty. Produces candidate objective metrics and anti-goals for ratification, then the structured loop: objective, anti-goal, decomposition, eval points, flags, and operating cadence.

Use when running Claude Fable on codebase-heavy or token-heavy work and the user wants Fable to orchestrate research, coding, and testing while cheaper subagents do bounded heavy lifting.

Use Agent-Native Plans when coding-agent work needs a reviewable plan published as an interactive document — inline diagrams, annotated code walkthroughs, file trees, optional UI wireframes or prototypes, open-question forms, and comments — before implementation starts.

Use when writing or refactoring code, choosing names, reducing boilerplate, deciding whether explicit types are needed, or reviewing code for human terseness. Prefer compiler-backed inference, short clear names, and less ceremony while keeping verification, public contracts, and safety boundaries explicit.