dragoncrafted87/kobold-codex

Use when adding Kobold to a repository. Convert its instructions into skills and playbooks, either by minimizing the root instruction files or by leaving those files alone, and ask which bounds fit what the files already say.

Use when a plan has been approved. Run its tasks in order, hand fast tasks and independent tasks to another agent only when subagents allows it, and finish each task on the check the plan named.

Use before adding a dependency, a bundled grammar or data file, or a language server or other tool to a project, and before a release. Check each license against the project policy, bundle nothing under the GPL unless the policy allows it, and record the result where the project keeps its deployment docs.

Use when prose or a diff needs a pass for narration, stock phrasing, and comments that restate the code. Encode a real constraint in the structure, then drop the comment.

Use when a failure can be reproduced. Hold one hypothesis at a time, check it on the running system, and put the fix at the producer of the symptom.

Use when reading or changing code in a workspace whose tools can look up symbols. Move from an overview of the files to the symbol and its context before reading whole files, fall back to text search or an exact-text edit when no symbol tool covers the file, and read again when a file has changed since it was read.

Use when work that does not share state should run as parallel workers. Split it, wait for the workers, and return one report. subagents has to allow the parallel form.

Use before changing a subsystem. Name the runtime path, the package that owns the behavior, and the layer the change belongs on.

Use when feature work, a fix meant for a pull request, or the execution of a plan should sit in its own checkout, and always when the current checkout holds other work in progress or another agent. Create that checkout when worktrees allows it, and record the path so ship-the-branch can remove it.

Use before exploring code to answer a question about how it works, after verifying such an answer, and before reviewing or shipping a change. Read the saved findings first, explore only what they leave open, write back each finding verified this session with its evidence, scope, owner, and review trigger, and recheck the findings a change trips.

Use before writing a reply, a diff, a commit message, or a document. Kobold Codex is the voice and the engineering principles for DragonCrafted87's agents on Grok and Claude Code.

Use after a session that stumbled, or that found a preference worth keeping. Name the lesson and edit the skill or playbook that should carry it. A bounds value is named and handed to set-the-bounds.

Use for a long run or an unattended run. Append one row per decision, with what, why, evidence, and result, to a log a reviewer can read afterward.

Use when a task is to keep changing and checking until a stated goal holds, such as a passing suite, a metric under a limit, or a clean scan. State the goal as a check that can be run, set the stop conditions and the attempt limit before the first pass, and loop change then check until the goal holds or a stop condition hits.

Use when work passes between skills or agents along more than one path, such as a review that can send work back or a step that can branch. Write the handoffs as a graph in the plan, with each node a step or a skill and each edge a condition and the payload it carries, and follow only the edges the graph names.

Use before a small diff ships. Name what else could break outside the diff, and prove that claim by running the code that would show the break.

Use when a new session should continue work already in progress. Rebuild a short brief from the branch, the transcript, and the trail.

Use when a repo has no scripted way to drive the app the way a user does. Write a project-local verification skill, prove it once, and re-run it so the map stays honest.

Use before a merge, or when the user asks for a review. Review the diff against the request and the checks, report each finding with file and line, and leave the tree alone.

Use once a week, or when asked, to review the session transcripts since the last review. Sort each lesson to this plugin, a project, or the user, and report before any edit.

Use when a task should follow a playbook. Match it to one playbook, copy that playbook's steps into the working list, record a skip with a reason, and stop where the resolved bounds say to stop.

Use before changing a file or making a commit. Name the scope of the edit, then add only the plan and the proof that scope calls for.

Use before a commit, a push, a pull request, a merge, a force-push, an unattended stretch, a named tool, or a change to a live system such as a deploy, a migration, a backup, or a restore. Resolve the four bounds layers, and revise one layer when the user wants a change.

Use when the checks pass and the branch should be integrated. Commit the specs, the plans, and the work under their own keys, then push, open a pull request, or merge, add Implements links on the tracker items the branch carries out, and remove the worktree, each as the resolved bounds allow.

Use when a rewrite or a port needs specs from an existing system. Extract one module at a time, in source mode from its code and tests or in clean-room mode from public docs and a running instance only, into domain rules, API shapes, a data model, and behavior cases under stable IDs, with every claim tagged SEEN, INFERRED, or UNKNOWN, a provenance header, a coverage checklist, and a resumable progress file.

Use when a diff needs several independent reviews. Run separate passes that each try to break it, try to refute every finding, merge what survives into one list, and leave the tree alone.

Use when review notes are in hand. Check each note against the code, implement the notes that hold, and for a note that does not hold say why and leave that code as it is.

Use when the first shape of a change would stick. Run several candidates, pick a base, and fold the strongest pieces of the others into it.

Use when you need the reason for a behavior or a threshold. Recover it from the code, the history, the issues, and the docs, and cite each source.

Use when authoring or revising a skill in this plugin. Write one trigger description and original wording, and keep the manifest check current.

Use when writing or revising a README, a spec, a pull request, or a commit message. Use the headings the project already uses, in sentences a new reader can follow.

Use when an architectural change needs a written plan, or the user asks for one. Write what will change, what it touches, what stays the same, what the checks cover, and the ordered tasks, then stop.