From Requirements to Delivery
First clarify what the user wants to change and what completion means, then execute. Continuously push authorized work forward; when a decision is needed, complete the parts that don't depend on it first. Do not treat "a plan was written," "the code compiles," or "auto-merge has been enabled" as final delivery.
Working Conventions
- Choose the development method based on goals, risks, and feedback cost. You may write a specification first, or start with tests on a clear public interface, or implement directly and then validate; methods can be combined. Always define observable completion criteria, gather evidence of actual behavior, and do not force a single process on all tasks.
- Describe "what it is now" using current code, runtime results, and actual release artifacts; describe "what it should become" using user-confirmed goals. When discrepancies are found, fix the implementation or the outdated records—do not overwrite user goals with old documentation.
- Choose the process based on scope. For small changes, the specification can be a few sentences; only for cross-module requirements should you split into slices, design, and document. Do not load all knowledge, establish a fixed approval chain, or fill out empty templates for every edit.
- Authorized scope remains valid. Research, implementation, and reversible verification do not require repeated confirmation; external releases follow the user's explicit goals. If production goals or authorization are still missing, first prepare artifacts, diffs, rollback plans, and checks, then explain what is missing.
- This skill can be used independently. When the skills listed in the table below are installed, call them as needed; when not installed, produce the results for that stage directly, without requiring the user to install the full suite.
- A task is continuously driven by its current owner. Dedicated methods supplement the evidence and artifacts of the current stage, reusing confirmed decisions and the same record—do not start a competing process.
Choose the Next Step
| Current Situation | Next Action | Callable Skill |
|---|---|---|
| Unsure which capability to use, or just want to know how to use it | Pick the minimal entry point for the task; first explain how to use it, do not mistake a consultation for implementation authorization | dev-help |
| First-time setup of environment, persona, or reasoning budget | Check the actual available tools and model, save a brief preference; do not assume a fixed vendor or backend capability | dev-setup |
| Want repetitive work to gradually match your habits | Extract stable patterns from readable history, forming a short maintainable project skill | dev-personalize |
| User asks for progress during a task, or needs a handoff summary | Summarize what's done, current evidence, and pending items; after answering, continue the original task unless explicitly asked to pause | dev-status |
| Input comes from chat, issues, screenshots, logs, or multiple feedback channels | Find the original evidence, actual behavior, goals, and scope; merge duplicate requests | dev-intake |
| Need to configure reporting integrations or monitor requirements by source | Separately select sources, trackers, repository routes, control methods, and actual triggers; complete initialization within authorized scope | dev-issue-setup |
| Reports from configured source adapters need classification, deduplication, or triage | Process evidence according to native reports, identity, and tracker contracts; sources can be chat, tickets, email, alerts, or manual input—do not reproduce or fix at this stage | dev-issue-triage |
| Reports pipeline is configured, trusted triage and real UI control conditions are met | Verify ownership, reproduce or validate existing fixes per the full protocol; when needed and authorized, fix and deliver a draft PR | dev-issue-fix |
| Product rules have key ambiguities | First answer factual questions from the code, then clarify around questions that would change the plan round by round | dev-grill |
| Requirements are clear but not yet directly verifiable | Write user behaviors, boundaries, non-goals, and success conditions | dev-spec |
| User wants to deepen or rewrite a pending request | Use four questions to check professional omissions, original materials, specific methods, and independent evidence; deliver a usable prompt | dev-sharpen |
| Taking over an unfamiliar module | Walk through one real use case covering entry, business logic, storage, feedback, and failure paths | dev-learn |
| Don't understand why a historical design exists | Distinguish current behavior, rationale at the time, and speculation; trace back to code and available decision evidence | dev-why |
| There's a substantive trade-off at boundaries or interfaces | Compare different structures; judge from caller experience, state ownership, and domain terminology | dev-architecture |
| A TLA+ model exists or is clearly needed, need a statechart with check results | Run TLC, generate rule marks and shortest counterexample, iteratively cross-check against real code | dev-statechart |
| Need to check key properties, choose a formal tool, or maintain models | Clarify properties, assumptions, and boundaries; run checks and identify model drift; ordinary explanatory diagrams do not automatically enter this flow | dev-formal-verify |
| Involves pages, interactions, design systems, or visual acceptance | Use components and tokens from the actual code; read design specs per product or marketing context; do not require design tool accounts | dev-ui-design |
| Requirements cannot be reliably delivered in one shot | Split into verifiable vertical feature slices with explicit dependencies; first run the smallest complete path end-to-end | dev-plan |
| There is non-conflicting work or alternative solutions worth comparing | Assign scope and acceptance rules for each, then integrate and validate the final result | dev-parallel |
| Specification or slices are ready for implementation | Implement per existing engineering conventions, wire up real behavior, verify current artifacts | dev-build |
| Common issue, CLI/API/UI functional error, or acceptance failure | Reproduce along the real entry point and locate root cause; only enter the measurement flow when performance is the target | dev-debug |
| User specified test-first, or current implementation has chosen TDD | Complete failing tests and minimal implementations one at a time on the public interface; supplementing tests for already correct behavior does not automatically enter red-green implementation | dev-tdd |
| Same type of error recurring, or critical constraints easily bypassed | Prioritize improving types, interfaces, and state ownership; add executable rules only when real value exists | dev-guardrails |
| Implementation is complete | Separately check specification conformance and engineering quality; fix real issues | dev-review |
| Need to prove real user paths are working | Drive the real application, check results and side effects, maintain a repeatable verification method | dev-verify |
| Goal is to improve latency, throughput, resources, or other measured metrics | Fix the workload and measurement scope, complete evidence collection, optimization, or fair comparison; reuse the same baseline | dev-benchmark |
| Goal includes launching to production | Confirm environment and version, perform authorized deployment, verify the live service and record | dev-deploy |
| Need clear documentation, commit messages, or PR summary | Organize information around the reader's questions; provide concrete behavior, evidence, and necessary trade-offs | dev-writing |
| A requirement has been delivered or explicitly stopped | Organize new knowledge, fix conflicts, retain valuable rationale, and archive the process | dev-archive |
If a specification already exists, implement directly; if only a design is requested, deliver the design; if only an explanation is requested, stop at the explanation. Read Execution & Resume for handling parallelism and interruptions. When requirements need refinement, read Phase Transitions from Requirements to Implementation; when executing a chosen task, read Engineering Operating Method; these supplement the current stage without re-selecting a completed stage.
When a complex task has no suitable existing process, use Custom Workflow to form verifiable units and continue authorized work. For recording and post-hoc review of long-running tasks, use Decision Trail Method to check that decisions, alternatives, and actual evidence correspond; when only a review is requested, deliver the audit results without automatically continuing migration or implementation. Tracing why a specific design was adopted at that time is handled by dev-why. When the user explicitly wants to build an actionable status dashboard, treat it as an implementation task; for mere progress queries, use dev-status.
Keep Work Moving
Project materials created by this skill set use .agents/wtadev/ as the root, with the following partitions as needed. Existing materials are consulted at their real location and retain necessary references; only move them when explicitly requested, preserving content, identifiers, and valid links. When the user explicitly specifies a different location for this session, follow their instruction:
.agents/wtadev/changes/<date-topic>/: Brief, spec, plan, progress, evidence for the current requirement; created as needed..agents/wtadev/notes/: Verified terminology, context, decisions, error experience, and module understanding; the entryindex.mdonly points the way..agents/wtadev/deploy/<environment>/: Deployment manual and historical release records underreleases/..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: Finished work and historical knowledge; explicitly does not represent current behavior.
These are materials for the target project and must not be written into the installation .agents/skills/. When recovery is needed, use the handoff template, leaving only the current results, evidence, open issues, and next steps.
Wrap-up
Compare against the original delivery goals, provide the actual changes, verification evidence of the current version, delivery address or commit, and the parts that are truly incomplete. If a launch is needed but not yet deployed, explicitly write "Implementation complete, deployment not complete"; after successful deployment, integrate reusable knowledge and the latest code references into the project, rather than stuffing the entire chat history into AGENTS.md.
Full Local References
Use the Method Index to select the full processes, check rules, examples, and templates within this skill. All necessary runtime resources are included in this package and do not require installing other skills; only read the content needed for the current task branch.