agentic-dev 0.2.6 → 0.2.7

package/.claude/skills/sdd/SKILL.md

@@ -19,6 +19,7 @@ This skill enforces one workflow:
 
 When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
 For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
+Unless the user explicitly forbids it, durable work is not complete at code-edit state. Finish with a coherent git commit, push the retained result to the configured remote, and if the repository ships an installable package or CLI, publish the new version and verify the registry reflects it.
 
 Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
 For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
@@ -155,6 +156,8 @@ Do not use this skill for:
 - Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
 - Do not skip planning review just because the code change looks small.
 - Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
+- Do not stop after local edits when durable changes remain; commit and push are the default completion bar unless the user explicitly forbids them.
+- Do not leave a publishable package or CLI unpublished after changing shipped behavior or instructions unless the user explicitly forbids publish.
 - When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
 - When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
 - When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
@@ -175,7 +178,9 @@ By the end of an implementation task, the expected trail is:
 - plan file updated,
 - build summary written,
 - verification summary written, including selected regression scope and residual risk,
-- operate status updated if rollout occurred.
+- operate status updated if rollout occurred,
+- coherent git commit created and pushed,
+- publishable package/CLI인 경우 registry publish and latest verification completed unless the user explicitly forbade it.
 
 When PROD rollout is in scope, the retained completion state also requires:
 - DEV deployment happened first and the retained full-layer DEV validation surface passed,

package/.codex/skills/sdd/SKILL.md

@@ -19,6 +19,7 @@ This skill enforces one workflow:
 
 When rollout is explicitly in scope, and the repository has separate DEV and PROD environments, this skill enforces a staged release rule: deploy to DEV first, complete the retained full-layer validation surface there, promote to PROD only after DEV passes, then rerun the same retained validation surface in PROD. If PROD validation fails, rollback is required unless the user explicitly redirects and that risk is recorded.
 For persistence-affecting work, this skill also enforces schema-parity verification. Always compare migration or model intent against the real DEV and PROD schema state for the affected database objects instead of assuming deployed reality matches the code.
+Unless the user explicitly forbids it, durable work is not complete at code-edit state. Finish with a coherent git commit, push the retained result to the configured remote, and if the repository ships an installable package or CLI, publish the new version and verify the registry reflects it.
 
 Read [references/section-map.md](references/section-map.md) when you need the exact destination inside `sdd/`.
 For screen-spec-driven UI work, reusable static assets from the spec must be extracted through the repo's canonical asset builder before being used in code.
@@ -155,6 +156,8 @@ Do not use this skill for:
 - Do not create or repopulate a parallel `docs/` tree when `sdd/` exists.
 - Do not skip planning review just because the code change looks small.
 - Do not leave build, verify, or operate evidence only in chat text when it should live in `sdd/`.
+- Do not stop after local edits when durable changes remain; commit and push are the default completion bar unless the user explicitly forbids them.
+- Do not leave a publishable package or CLI unpublished after changing shipped behavior or instructions unless the user explicitly forbids publish.
 - When PROD rollout is in scope, do not promote to PROD before the retained full-layer DEV validation surface has passed.
 - When PROD rollout is in scope, do not use a weaker PROD validation surface than the one that gated DEV unless the user explicitly approves and that risk is recorded.
 - When PROD rollout is in scope, do not stop at "PROD deployment succeeded"; post-deploy PROD validation is mandatory.
@@ -175,7 +178,9 @@ By the end of an implementation task, the expected trail is:
 - plan file updated,
 - build summary written,
 - verification summary written, including selected regression scope and residual risk,
-- operate status updated if rollout occurred.
+- operate status updated if rollout occurred,
+- coherent git commit created and pushed,
+- publishable package/CLI인 경우 registry publish and latest verification completed unless the user explicitly forbade it.
 
 When PROD rollout is in scope, the retained completion state also requires:
 - DEV deployment happened first and the retained full-layer DEV validation surface passed,

package/AGENTS.md

@@ -25,6 +25,14 @@
 - 완료된 work branch는 관련 정합성 체크가 끝나고 변경이 `main`과 `origin/main`에 안전하게 반영된 뒤 local/remote branch를 모두 삭제한다. 사용자가 branch 유지를 명시한 경우만 예외다.
 - branch retire 전 최소 정합성 체크는 `관련 canonical 검증 명령 재실행`, `worktree clean 확인`, `최종 변경의 main 포함 여부 확인`이다.
 
+## Completion And Release Policy
+
+- 사용자가 명시적으로 금지하지 않는 한, durable 변경이 남은 agent 작업은 `commit -> push -> publish 가능한 패키지/CLI는 publish`까지 끝나야 완료로 간주한다.
+- "설명만 하고 종료", "로컬 수정만 남기고 종료", "커밋 없이 종료", "원격 미반영 상태로 종료"는 기본 완료 상태가 아니다.
+- npm package, 설치형 CLI, 배포 artifact처럼 사용자가 즉시 받는 deliverable을 가진 저장소는 변경 후 새 버전을 발행하고 registry 배포까지 확인한다.
+- publish 가능한 저장소에서 publish를 생략할 수 있는 예외는 사용자가 그 turn에서 명시적으로 금지한 경우뿐이다.
+- 완료 보고 전 최소 확인 항목은 `coherent commit 존재`, `원격 push 완료`, `publish 대상이면 registry 최신 반영 확인`이다.
+
 ## Runtime Naming Policy
 
 - 문서/대화/로그에서 실행 환경은 항상 `DEV(개발계)`로 표기한다.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agentic-dev",
-  "version": "0.2.6",
+  "version": "0.2.7",
   "description": "Scaffold an agentic template repo with the selected frontend surface and shared toolchain assets.",
   "type": "module",
   "packageManager": "pnpm@10.32.0",