Skip to main content

dev-implementation

AI DevKit · Implementation phase guidance for executing feature plans and checking implementation against design. Use when the user wants to implement planned tasks, update implementation docs, verify code matches design, or run dev-lifecycle phases 5 and 7.

소스 정보

저장소
codeaholicguy/ai-devkit
최근 소스 활동
2026년 8월 26일 17:35
감지된 SKILL.md 언어
영어
스타
1,644
포크
256

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
dev-implementation
description
AI DevKit · Implementation phase guidance for executing feature plans and checking implementation against design. Use when the user wants to implement planned tasks, update implementation docs, verify code matches design, or run dev-lifecycle phases 5 and 7.
# Dev Implementation Run implementation work for configured AI docs features. Before changing docs or code, propose the concrete plan for this phase and wait for user approval unless the user already approved the exact phase plan. ## Phase Contract 1. Run `npx ai-devkit@latest lint` before phase work. 2. If working on a named feature, run `npx ai-devkit@latest lint --feature <name>`. 3. Read requirements, design, planning, implementation, and testing docs before changes. 4. Use the `tdd` skill while executing implementation tasks: write a failing test before production code, then make it pass. 5. Apply the `verify` skill before completing tasks or making implementation alignment claims. 6. Keep testing and implementation docs in lockstep with code. Do not defer all doc updates to final verification. 7. If parent `dev-lifecycle` established usable task tracing, emit phase, progress, next-step, blocker, and evidence events per `task`. ## Execute Plan Use for Phase 5. 1. Run `npx ai-devkit@latest lint --feature <name>` and work through the planning doc path it validates. If manual path resolution is unavoidable, first resolve `.ai-devkit.json` `paths.docs`, falling back to `docs/ai`. 2. Gather context: feature name, planning doc path, supporting docs, current branch, and current diff. 3. Parse task lists and build an ordered queue by section. 4. Present the task queue with status: `todo`, `in-progress`, `done`, `blocked`. 5. For each task, show context, suggest relevant docs, and outline sub-steps from the design doc when useful. 6. If task tracing is available, record current task progress and immediate next action per `task`. 7. Reuse before writing: grep for existing utilities/functions before adding new ones. Reuse only if it fits cleanly. 8. Subtract before adding: delete dead paths, redundant guards, stale tests, and one-caller wrappers when they are in task scope. 9. Handle breaking changes carefully: update all in-repo callers atomically and delete the old internal API; for external/public/cross-service callers, add a new function and deprecate the old one. 10. Model the domain when implementation friction repeats: replace synchronized flags, branch growth, or duplicated shape assumptions with the smallest domain structure that removes them. 11. Generate a markdown tracking snippet after each status change. 12. After each task, update the testing doc with completed scenarios, newly discovered scenarios, and invalidated scenarios. Update the implementation doc with changed files, decisions, design deviations, and edge cases handled. 13. After each section, ask if new tasks were discovered. 14. Summarize completed, in-progress, blocked, skipped, new tasks, task-tracing events emitted or why tracing was unavailable, and doc deltas. Next: after completing any task, run `dev-planning` Phase 6. When all tasks are done, run Check Implementation, then `dev-testing` and `dev-review`. ## Check Implementation Use for Phase 7. 1. Compare implementation against the configured design and requirements docs validated by `npx ai-devkit@latest lint --feature <name>`. 2. Gather context: feature description, modified files, relevant design/requirements docs, constraints. 3. Summarize design: key decisions, components, interfaces, data flows. 4. Review file by file: verify design intent, note deviations, flag logic gaps, edge cases, security issues, and missing tests or doc updates. 5. Treat repeated implementation friction as a redesign signal, not another patch, and return to design when the model no longer fits. 6. Finalize the implementation doc. Verify it captures what shipped, fill gaps, and record follow-ups. 7. Summarize alignment status, deviations with severity, missing pieces, concerns, and next steps. Next: `dev-testing`, then `dev-review`. If major deviations exist, return to `dev-design` if design is wrong or Execute Plan if implementation is wrong.
GitHub에서 보기