# Dextrace Contributor > understand the dextrace repository and guide contributor workflows for setup, code navigation, and test selection. use when chatgpt is asked to work on dextrace development tasks such as explaining module responsibilities, finding where to change code, setting up the development environment, or choosing validation steps. prefer container-based setup that works for both vscode and non-vscode users, and avoid vscode ui-dependent instructions. - Skill: `ev-flow/dextrace-contributor` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add ev-flow/dextrace-contributor` - Raw SKILL.md: https://api.skillmd.com/api/skills/ev-flow/dextrace-contributor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ev-flow (https://skillmd.com/u/ev-flow) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ev-flow/dextrace-contributor --- # DexTrace contributor Use this skill when helping with the DexTrace repository. ## Start here Before answering, read these files if they exist: - `README.md` - `CONTRIBUTING.md` - `docs/modules-overview.md` - `docs/development-workflow.md` - `docs/current-status.md` Treat them as the source of truth for repository structure, contributor workflows, and current project scope. ## What this skill does Use this skill to: - explain DexTrace module responsibilities - map a task to the correct subsystem - guide development environment setup - recommend the right tests for a change - onboard contributors to the current repository state Do not use this skill for issue drafting, PR drafting, or mismatch analysis unless the user explicitly asks. ## Repository mental model Map requests to one of these areas first: - `src/dextrace/cli/` for CLI behavior - `src/dextrace/core/` for APK / DEX parsing and API extraction - `src/dextrace/dalvik/` for bytecode decoding and disassembly internals - `src/dextrace/vm/` for Dalvik bytecode execution (engine, opcode handlers, Android stubs) behind `dextrace run` - `src/dextrace/manifest/` for binary manifest parsing - `tests/` for validation and fixtures Do not invent modules, files, or workflows that are not present in the repository. ## Setup rules Prefer container-based setup that works for both: - VS Code users - non-VS Code users Do not make VS Code UI actions the primary path. For DexTrace, prefer this order: 1. Read `CONTRIBUTING.md` first. 2. Check whether the repository provides container-related files such as: - `devcontainer.json` or `.devcontainer/` - `Dockerfile` - compose files - setup scripts 3. If container files exist, explain setup through CLI-first container workflows. 4. Reuse the same container definition for both VS Code and non-VS Code contributors. 5. Use documented install commands inside the container. 6. Verify setup with the smallest useful checks: - package import - targeted tests - full test suite only when needed If the repository provides devcontainer-compatible configuration, treat it as a shared container definition, not as a VS Code-only workflow. Do not claim automatic setup unless the repository actually provides the required files or scripts. ## Change-to-subsystem mapping ### CLI Files: - `src/dextrace/cli/main.py` - `src/dextrace/cli/cmd_meta.py` - `src/dextrace/cli/cmd_disasm.py` - `src/dextrace/cli/cmd_dex.py` - `src/dextrace/cli/cmd_run.py` Tests: - `tests/test_cli_meta.py` - `tests/test_smoke.py` ### APK and metadata Files: - `src/dextrace/core/apk_reader.py` - `src/dextrace/core/apk_metadata.py` Tests: - `tests/test_apk_reader.py` - `tests/test_apk_metadata.py` ### Manifest Files: - `src/dextrace/core/manifest_parser.py` - `src/dextrace/manifest/axml_parser.py` Tests: - `tests/test_manifest_parser.py` ### DEX structure parsing Files: - `src/dextrace/core/dex_parser.py` - `src/dextrace/core/dex_header.py` - `src/dextrace/core/dex_string_table.py` - `src/dextrace/core/dex_proto_table.py` - `src/dextrace/core/dex_method_table.py` - `src/dextrace/core/dex_code_map.py` Tests: - `tests/test_dex_parser.py` - `tests/test_dex_header.py` ### API extraction and resolution Files: - `src/dextrace/core/dex_api_extractor.py` - `src/dextrace/core/dex_resolver.py` Tests: - `tests/test_dex_api_extractor.py` ### Dalvik disassembly Files: - `src/dextrace/dalvik/disassembler.py` - `src/dextrace/dalvik/operand_decoder.py` - `src/dextrace/dalvik/format_size_infer.py` - `src/dextrace/dalvik/format_table.py` - `src/dextrace/dalvik/opcode_table_builder.py` - `src/dextrace/dalvik/payload.py` - `src/dextrace/dalvik/size_resolver.py` - `src/dextrace/dalvik/smali.py` - `src/dextrace/dalvik/types.py` Tests: - `tests/test_operand_decoder.py` - `tests/test_size_resolver.py` - `tests/test_opcode_table_builder.py` - `tests/test_format_size_infer_oracle.py` - `tests/test_disassembler_e2e_dummy_dex.py` - `tests/test_disassembler_evidence_smali_hex.py` - `tests/test_dalvik_payload.py` - `tests/test_all_formats_inferable.py` - `tests/test_generated_bytecode_vectors.py` ### VM execution (`dextrace run`) Bytecode execution and dynamic analysis, distinct from `dalvik/` disassembly. Files: - `src/dextrace/vm/engine.py` - `src/dextrace/vm/decoder.py` - `src/dextrace/vm/state.py` - `src/dextrace/vm/register_file.py` - `src/dextrace/vm/call_frame.py` - `src/dextrace/vm/heap.py` - `src/dextrace/vm/class_hierarchy.py` - `src/dextrace/vm/int_ops.py` - `src/dextrace/vm/signals.py` - `src/dextrace/vm/trace.py` - `src/dextrace/vm/errors.py` - `src/dextrace/vm/handlers/` (opcode handlers) - `src/dextrace/vm/android_stubs/` (simulated Android/Java framework methods) - `src/dextrace/cli/cmd_run.py` Tests: - `tests/test_vm_run_*.py` - `tests/test_vm_null_receiver.py` - `tests/test_vm_pending_result_lifecycle.py` - `tests/vm/` Run with `pytest -k vm`. ## Testing behavior Recommend the narrowest relevant tests first. Use full `pytest` only when: - shared logic changed - the user asks for full validation - targeted tests are not enough When setup verification is requested, prefer: 1. package import 2. one or two targeted tests 3. full suite only after basic checks pass ## Documentation behavior When explaining the repository: - use `README.md` for project overview and CLI basics - use `CONTRIBUTING.md` for setup and contribution flow - use `docs/modules-overview.md` for module responsibilities - use `docs/development-workflow.md` for validation steps - use `docs/current-status.md` for current scope and handoff notes If documents disagree, prefer the more specific contributor document and mention the inconsistency. ## Container guidance rules When talking about container workflows: - prefer editor-agnostic wording - do not assume VS Code is available - do not require GUI actions - explain the workflow in terms of repository files, container runtime, and CLI commands - treat devcontainer-compatible configuration as reusable by both VS Code and non-VS Code users when paired with a shared `Dockerfile` If the repository provides both `devcontainer.json` and `Dockerfile`, prefer describing the Dockerfile-based CLI workflow first, then mention VS Code compatibility as optional. ## What not to do Do not: - assume nonexistent modules or future architecture - promise automatic environment setup if the repository lacks the required files - describe mismatch investigation workflows unless the user asks for them - drift into issue-writing or PR-writing guidance unless requested - make VS Code UI steps the primary setup path ## Output rules Be concrete. Always prefer: - exact file paths - exact subsystem names - exact test files - verified repository facts - documented setup commands over generic contributor advice. When something is missing from the repo, say that it is missing instead of inferring that it exists.