Technical Debt
Operations
research [scope]: inspect the requested scope, defaulting to turbo/, and
report verified findings. This operation is read-only.issue [report]: create an English GitHub issue from current, verified
findings. If no report exists, research first. Create or comment on an issue
only when the caller requested that operation.
The tech-debt-research and tech-debt-issue commands remain aliases for these
operations. A report is evidence at its recorded revision, not a standing
instruction to change code.
Research
- Record the repository, HEAD, scope, and date. Read
code quality and use
the index for the affected surfaces.
- Use
rg to find candidates and inspect matching files and consumers. Exclude
dependencies, generated/vendor content, and historical migrations from
generic cleanup recommendations. Preserve permanent migration records.
- Check type/lint suppressions, dynamic imports, environment configuration,
error handling, fallback ownership, and unused dependencies against actual
contracts. Use testing guidance for tests and
ccstate guidance for signal/React code.
- Validate each candidate. File length, a relative import, a
catch, or an
ESLint off / Oxlint allow setting is not proof of a defect. Read override
scope, replacement enforcement, generated-code boundaries, and documented
exceptions. In particular, do not replace every floating promise with
detach() or assume every parentless resetSignal() leaks.
- Report the concrete consequence, file/line, applicable rule, evidence,
proposed remedy, and uncertainty. Use severity based on demonstrated impact.
Distinguish static inspection from executable or production verification.
Keep the report proportional to the findings: scope and revision, confirmed
issues, dismissed candidates when useful, and next actions. Save detailed
evidence when it is too long for the response. Do not invent schedules or effort
estimates from match counts.
Issue
Recheck the report against current source and existing issues before posting.
Use an English title describing the concrete problem; include affected paths,
evidence, impact, and actionable acceptance criteria in the body. Use only
existing relevant labels and include source links pinned to the inspected SHA.
Write the body to a temporary file and pass gh issue create --repo vm0-ai/vm0 --body-file <file> the exact Markdown. Keep the report focused enough to fit one
issue; add detailed comments only when needed for the requested tracking task.
Verify the created issue and return its URL. If posting fails, retain the report
and state which action failed.
1---2name: tech-debt3description: Research repository technical debt or create an issue from verified findings when requested4---56# Technical Debt78## Operations910- `research [scope]`: inspect the requested scope, defaulting to `turbo/`, and11 report verified findings. This operation is read-only.12- `issue [report]`: create an English GitHub issue from current, verified13 findings. If no report exists, research first. Create or comment on an issue14 only when the caller requested that operation.1516The `tech-debt-research` and `tech-debt-issue` commands remain aliases for these17operations. A report is evidence at its recorded revision, not a standing18instruction to change code.1920## Research21221. Record the repository, HEAD, scope, and date. Read23 [code quality](../../../docs/bad-smell.md) and use24 [the index](../../../docs/docs.md) for the affected surfaces.252. Use `rg` to find candidates and inspect matching files and consumers. Exclude26 dependencies, generated/vendor content, and historical migrations from27 generic cleanup recommendations. Preserve permanent migration records.283. Check type/lint suppressions, dynamic imports, environment configuration,29 error handling, fallback ownership, and unused dependencies against actual30 contracts. Use [testing guidance](../../../docs/testing.md) for tests and31 [ccstate guidance](../ccstate/SKILL.md) for signal/React code.324. Validate each candidate. File length, a relative import, a `catch`, or an33 ESLint `off` / Oxlint `allow` setting is not proof of a defect. Read override34 scope, replacement enforcement, generated-code boundaries, and documented35 exceptions. In particular, do not replace every floating promise with36 `detach()` or assume every parentless `resetSignal()` leaks.375. Report the concrete consequence, file/line, applicable rule, evidence,38 proposed remedy, and uncertainty. Use severity based on demonstrated impact.39 Distinguish static inspection from executable or production verification.4041Keep the report proportional to the findings: scope and revision, confirmed42issues, dismissed candidates when useful, and next actions. Save detailed43evidence when it is too long for the response. Do not invent schedules or effort44estimates from match counts.4546## Issue4748Recheck the report against current source and existing issues before posting.49Use an English title describing the concrete problem; include affected paths,50evidence, impact, and actionable acceptance criteria in the body. Use only51existing relevant labels and include source links pinned to the inspected SHA.5253Write the body to a temporary file and pass `gh issue create --repo vm0-ai/vm054--body-file <file>` the exact Markdown. Keep the report focused enough to fit one55issue; add detailed comments only when needed for the requested tracking task.56Verify the created issue and return its URL. If posting fails, retain the report57and state which action failed.
vm0-ai