trkbt10

README construction — initialize template structure, generate per-package READMEs from doc comments, plan writing tasks, assemble root README from docs/ and package READMEs via doc.json config, and verify edits with `plan drift`.

Detect and review name/content drift in code using `indexion identity audit`, then plan verified renames, moves, folder changes, or splits.

Generate and use a pre-edit structure brief so coding agents learn likely owners, consumer surfaces, and unsafe edit locations before implementing.

Generate SDD requirements from RFCs/specs and quantitatively verify implementation conformance. spec draft → spec align → spec verify → automated validation loop with codex/claude. Operate spec-to-impl drift gates as CI checks.

Documentation analysis — assess coverage, detect code-to-doc drift with plan reconcile, visualize dependencies with doc graph. Answers "what needs docs?" and "are docs still accurate?"

Project wiki lifecycle — create pages, track source changes with ingest, update stale pages, lint structural integrity, detect code-to-doc drift with reconcile, and manage search indexes. A runbook for navigating and maintaining the wiki as an agent.

Debug and inspect KGF specs — view tokenization results, parse trees, and extracted edges from source files. Use when adding/fixing language support or when indexion's analysis output looks wrong.

After writing code, detect and clean up duplication at three levels — copy-paste blocks, cross-package shared code, unnecessary wrappers, and concept-level SoT violations. Detect with indexion, fix, and verify.

Create comprehensive technical design for a specification

Initialize a new specification with detailed project description

Quick spec generation with interactive or automatic mode

Generate comprehensive requirements for a specification

Show specification status and progress

Generate implementation tasks for a specification

Validate feature-level integration after all tasks are implemented. Checks cross-task consistency, full test suite, and overall spec coverage.

Use when capturing an investigation, PoC, measurement, or finding as a durable report. Create one directory per purpose with an evidence-complete README stating the question, method, and result, authored in isolation. Trigger on "write up the findings", "document this PoC".

Use when fixing a bug, dependency mismatch, broken build, or any other defect in product code under a canonical-branch-protecting workflow. Treat the fix exactly like a feature PoC — open a purpose-named report with the diagnosis and acceptance criteria, do the change in an isolated worktree, prove the gate goes from red to green, then cherry-pick. Trigger on "fix this", "build is broken", "deps mismatch", "rename leaks". This is the bug-side companion to `isolate-and-integrate`; it inherits that operation and adds the report-first discipline so a fix is documented evidence, not a hidden patch.

Prove a change is interpretable AND actually works at the consumer side before landing. Extract the deliverable's surface deterministically from source (no editorializing), enumerate its state matrix, hand the raw extraction and — when a UI can render — real screenshots to blind multi-persona agents, judge against pre-written ground truth, and block on FAIL. This is the procedure behind the iron rule "green only once consumed." Use AFTER a UI- or contract-facing change and BEFORE landing. Trigger on "zero-knowledge verification", "blind test", "verify before land", "consumer-side verification", "UI verify".

Use when implementing or changing product code in a repository that protects a canonical branch. Do the work in a throwaway git worktree off the canonical branch, verify it against the full quality gate, and cherry-pick only the finished, verified commits back — never commit to the canonical branch directly. Trigger on requests to add, fix, or refactor code.

Use BEFORE a non-trivial or unfamiliar change, when unsure which module owns the behavior — and BEFORE diving into a fix when prior reports may already describe the area. Build a pre-edit structure brief over both the source tree and the reports directory so candidate owners and prior investigations surface together; CONFIRM the owner by searching and reading before committing to it. Then deliver the change in isolation. Trigger on "where should this go", "did anyone already look at this", "what's the context".

Use when surveying or updating the implementation status of `requirements/RNN-*.md` against the current `source/` and `reports/`. The status model is multi-axis (not binary done/not-done) because parts can exist as building blocks for a larger exploration even when no single requirement is "done", and shipped features may differ from the requirement on purpose. Trigger on "update requirement status", "requirement status", "show the status table", "what's the status of R0N", "update the tracker".

Inspect, build, and verify Office documents (PPTX, DOCX, XLSX) using the oxen CLI. Use this skill when: (1) Inspecting existing Office files, (2) Building PPTX/DOCX/XLSX from JSON spec, (3) Previewing slide/document/sheet content in terminal, (4) Extracting text or data, (5) Verifying build results, (6) User asks about ".pptx", ".docx", ".xlsx" inspection or generation.

Create and modify PowerPoint presentations (PPTX) through direct XML manipulation. Use this skill when: (1) Creating presentations from scratch, (2) Adding/editing/deleting slides, (3) Inserting images or custom shapes, (4) Applying POTX templates for consistent branding, (5) Editing existing PPTX files, (6) Working with slide layouts and placeholders, (7) User asks to make a "presentation", "slides", "deck", or mentions ".pptx". Supports all 11 standard Office slide layouts.

Create custom node definitions with renderers, ports, external data, and constraints. Use when implementing new node types, custom node appearances, or node-specific behaviors.

Create and customize inspector panels for node editors. Use when implementing custom inspector tabs, settings panels, node-specific inspectors, or using inspector UI components.

Release process for indexion. Use when the user asks to release, deploy, bump version, create a tag, or push a release. Ensures submodule→parent push ordering, version sync, and tag consistency.

Inspect, build, and verify Office documents (PPTX, DOCX, XLSX) using the aurochs CLI. Use this skill when: (1) Inspecting existing Office files, (2) Building PPTX/DOCX/XLSX from JSON spec, (3) Previewing slide/document/sheet content in terminal, (4) Extracting text or data, (5) Verifying build results, (6) User asks about ".pptx", ".docx", ".xlsx" inspection or generation.