Manage the current team member's personal Work·Verify settings so that the user does not have to explain the desired execution method repeatedly each time. Do not save instructions that apply only to this run. Modify files only when creation, modification, or reset of persistent settings is requested, and do not change task contracts, stages, management authority, or verification obligations through personal settings.
Before performing this skill, references/communication.mdand apply it to explanations, questions, and reports. Then
references/project-gate.mdand edit only when all targets are in a state where they can be entered. It does not require a Work contract or active management authority, and this skill is not recorded as next_routenor does it initialize or recover the project.
The current team member uses the gate's existing team identity.
In a valid edit, references/member-preferences.mdand apply authority, conflict, and verification boundaries.
Handle only supported settings
The writing scope is the current team member's .devflow/team/<current-member>/preferences/work.md와 verify.md. Work contains
implementation approach, defect reproduction/cause determination, and self-check methods, while Verify contains observation order, counterexamples, boundary inputs, and evidence confirmation methods for existing verification items. When the user asks about scope, explain only the options relevant to the request and do not create files. Ask only when it is genuinely unclear whether the setting is persistent. direct.mdor other skill settings are not created.
Read only the requested files. Read the counterpart file of the same team member only when coordinating both roles together or when the relationship between the two must actually be judged. Do not edit other team members' files, project canonical sources, or active task artifacts. Do not create additional documents, states, registries, or auxiliary scripts for personalization, nor instruct their creation in personal files.
Edit while preserving existing meaning
Understand the reason, behavior, and application conditions the user wants, and preserve unrelated existing preferences. If the same purpose can be expressed in an allowed way, write it in that expression. For alternatives that change the purpose or effect, explain the difference before saving and obtain a choice. Exclude requirements that conflict with shared contracts and content that depends on them, and do not turn a rejected requirement into a new preference in different words. If there is no valid content, do not create a file.
Personal files are written in Markdown with the project's standard summary와 read_when header,
read_whenstates the task conditions under which this preference applies. The body explains the reason and desired method self-containedly, but does not duplicate Work·Verify common rules or task history.
The first setting creates only the requested files and the necessary parent folders. A partial unset removes only the requested preferences, and a full reset deletes only the one specified personal file. If the existing content already satisfies the request, it is not rewritten. If an existing file cannot be read or there is a merge conflict, do not guess and replace it. Immediately before writing, re-check the current content, and if there is an unexpected change, stop and confirm what should be preserved.
Check the actual results
After completion, re-check the creation, modification, and deletion results. Do not commit, and report the paths of the personal files changed or deleted, the fact that they have not yet been committed, the different execution method, and the requirements excluded. The actual effect of the configuration is judged at the next Work/Verify entry, so do not report that the behavior has been proven merely by editing.