tdpeuter/agent-instructions
1
Fork 0
Code Issues Pull requests Releases Activity Actions

feat(copilot): add personal workflow instructions

Browse source
This commit is contained in:
Tibo De Peuter 2026-09-10 16:29:13 +02:00
parent a2b41a8355
commit ad22eee20e
1 changed files with 37 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

37
copilot/instructions/workflow.instructions.md Normal file
View file

@ -0,0 +1,37 @@
# Personal workflow instructions (Copilot CLI)
Standing habits for how I like implementation work approached in this CLI, independent
of any one repository. Repo-specific facts and conventions belong in that repo's own
`.github/copilot-instructions.md` — this file is about *how I like to work*, not about
any particular codebase.
## Planning
- Use `/plan` for anything beyond a trivial change. Start the plan with branch + worktree
setup (follow the target repo's own naming/location conventions if it has them).
- Structure the plan into one or more phases, each with zero, one, or more commits, and
give each planned commit a determined Conventional Commit message up front.
- Use `/grilling` before committing to a plan whenever there's real ambiguity to resolve —
don't skip it just to move faster on non-trivial scope decisions.
- After I approve a plan, restate the exact in-scope deliverables and keep anything
discussion-only (ideas, "what if", tangents) out of scope unless I explicitly promote it.
## Execution
- Prefer sized, reviewable commits over one big end-of-task commit — commit at the end of
each phase, including when a fleet of sub-agents executes the phases (each phase agent
commits its own work before reporting done).
- **Model/agent choice per phase is up to the executing agent(s), not pre-assigned by the
planner.** Each phase should pick the most cost-effective model/agent capable of doing
that phase's work well, and be able to explain the choice if asked. See `model-guide.md`
in this same directory for the current model comparison — don't inline that table here,
since it changes independently of this workflow.
- Dispatch parallelizable phases with `/fleet` once the plan is approved.
- End coding work with a short state summary: changed file count, staged vs. unstaged,
branch ahead/behind, and the recommended next action.
## PRs
- Open a PR once the planned work is complete, unless told otherwise.
- Follow the target repo's own commit/PR conventions (Conventional Commits, merge-vs-squash,
etc.) — those live in the repo, not here.