End-to-end workflow for resolving one GitHub issue in dynamic-neural-field-composer - branch, TDD, build, review, docs, PR. Use when asked to fix, implement, or close a specific issue number.
中文简介正在准备中。当前显示原文说明。
安装前可以查看交给 AI 代理的指令内容。
One issue, one branch, one PR. Do not stack unrelated changes.
gh issue view <N> --comments
Restate in your own words: the goal, and the success criterion - the observable thing that will be true when this is done. If you cannot state a success criterion, the issue is too vague to work unattended; stop and say so.
Never commit to main. Branch from an up-to-date base:
git fetch origin
git switch -c <type>/<slug> origin/main
Branch type is one of bug/ feat/ chore/ ci/ docs/ test/ refactor/. Keep the slug short
and specific: bug/connection-dim-check, not bug/fix-the-connection-dimension-problem.
Write the test that reproduces the bug or specifies the feature. Add it to
tests/CMakeLists.txt if it is a new file. Build and watch it fail - a test that passes
before you have implemented anything is testing nothing.
Follow the suite's existing conventions: EXPECT_NEAR with an explicit tolerance for
floating point, file-local makeField/makeStimulus helpers rather than a shared header,
fixtures with SetUp/TearDown for anything touching the filesystem.
If the failing test does not immediately tell you why, do not reason about the control flow by reading source. Add logging, run it, and read what actually happened:
tools::logger::log(tools::logger::DEBUG,
"field 'u' step 42: max activation 0.87 at index 51, below threshold 1.0, no bump");
Write messages as plain natural-language sentences carrying the values that matter. Guessing
at the flow costs more than instrumenting it. Remove the instrumentation before the PR
unless it earns a permanent place at DEBUG.
Minimally. The smallest change that makes the test pass and nothing more.
Before writing any helper function, search tools/ first - math.h, utils.h,
profiling.h, logger.h, fft_convolution.h, and exceptions/exception.h. If something
close already exists, extend or reuse it. A new free function duplicating an existing helper
will be rejected in review.
Use the build-and-test skill. Green means the full suite, not just your new test.
If the diff touches the simulation hot path — src/elements/, src/simulation/, src/tools/,
include/tools/math.h, include/tools/fft_convolution.h, include/tools/simd_dispatch.h —
use the perf-regression-test skill.
Skip it otherwise, and say you skipped it. A silent skip reads as a pass.
An inconclusive result (too noisy, or no baseline for this machine) is not a pass. Report it as unverified rather than moving on quietly.
Use the project-code-review skill on git diff origin/main...HEAD. Fix what it finds
before asking anyone else to look.
Use the docs-check skill. Doxygen on new public API, wiki page for user-visible changes,
and no stale references left behind.
Add an entry under [Unreleased] in the repo-root CHANGELOG.md — the one beside
README.md, not inside dynamic-neural-field-composer/. Create the [Unreleased] heading
if the last release consumed it.
Pick the subsection matching the work; the file uses Added, Changed, Fixed,
Removed, Performance, Tests, Documentation, Build and CI. Create it in that
order if absent.
Write for someone reading the release notes months from now with no access to the issue:
what changed, and why it mattered. Reference the issue as (#N). Match the surrounding
entries' density — they are full sentences, not one-line summaries.
Every issue gets an entry, CI- and test-only work included. It is easier to drop a line at release time than to reconstruct one from a diff.
git add -A && git commit -m "<type>: <lowercase summary>"
git push -u origin <branch>
gh pr create --title "<type>: <summary>" --body "<what / why / how to verify>
Closes #<N>"
Do not merge. The PR waits for human review.
Report: PR URL, what changed, what you verified (with the test count), and anything you deliberately left out.
Stop and ask rather than guessing when:
When you stop, say exactly what you completed, what is blocked, and what you need.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Orchestrate unattended resolution of open GitHub issues - triage by complexity, dispatch parallel worker agents into isolated worktrees, review their diffs, open PRs, and monitor CI and CodeRabbit until green. Use when asked to work through open issues autonomously or put Claude on auto-pilot.
中文简介正在准备中。当前显示原文说明。
Configure, build and test dynamic-neural-field-composer. Use whenever you need to compile the library, run the GoogleTest suite, verify a change builds, or reproduce a test failure.
中文简介正在准备中。当前显示原文说明。
Read the uncommitted diff in dynamic-neural-field-composer and print conventional commit message(s) for it, grouped by logical change. Use when asked to write, suggest or draft a commit message, or "what should I commit this as".
中文简介正在准备中。当前显示原文说明。
Verify documentation keeps up with a code change in dynamic-neural-field-composer - Doxygen on public API, the matching wiki page, and stale references elsewhere. Use before opening a PR, or when asked whether docs need updating.
中文简介正在准备中。当前显示原文说明。
Check a change for performance regression against this machine's recorded baseline - decide whether the diff needs checking, run the deck benchmark under the hygiene wrapper, and attribute any regression to an element. Use before opening a PR that touches the simulation hot path.
中文简介正在准备中。当前显示原文说明。
Read the branch diff in dynamic-neural-field-composer and print a PR title and description in chat, filling the repo's pull request template. Use when asked to write, draft or suggest a PR title/description, or "what should the PR say".
中文简介正在准备中。当前显示原文说明。