jhste-skills 0.5.2 → 0.6.0

package/CHANGELOG.md

@@ -2,6 +2,23 @@
 
 ## Unreleased
 
+## 0.6.0 - 2026-07-13
+
+### Added
+- Added `jhste-grill` for focused, one-question-at-a-time decision interviews.
+- Added `jhste-to-tickets` for GitHub-native parent issues, sub-issues, and dependency graphs.
+- Added `jhste-domain-modeling` for domain terminology, concept boundaries, glossaries, and selective ADR capture.
+- Added Codex UI metadata and explicit implicit-invocation policy for every bundled skill.
+
+### Changed
+- Reworked `jhste-coding` from a SOLID tutorial into a lean outcome, contract, autonomy, and validation discipline for GPT-5.6.
+- Expanded the npm package, documentation, and validation from one skill to four independent skills.
+- Replaced the recommendation to install Matt Pocock workflows separately with a curated JHSTE-owned workflow set.
+
+### Removed
+- Removed SOLID-first branding and exhaustive SOLID restatement from the coding skill.
+- Kept TDD, code review, debugging-process, Wayfinder, and architecture-audit workflows outside the package.
+
 ## 0.5.2 - 2026-07-12
 
 ### Changed

package/README.en.md

@@ -2,50 +2,52 @@
 
 [한국어](README.md) | ENG
 
-A tiny personal coding-discipline skill.
+A personal engineering skill set maintained around GPT-5.6's outcome-first, lean-prompt guidance. Each skill works independently and may be selected implicitly when the user's intent matches its narrow trigger.
 
-This repository provides one skill:
+## Skills
 
-- `jhste-coding`: a lightweight SOLID-first coding discipline for repository code edits.
+- **`jhste-coding`** — implements features, fixes bugs, and refactors code with a small change and relevant validation.
+- **`jhste-grill`** — sharpens a plan or design through one consequential decision question at a time.
+- **`jhste-to-tickets`** — splits defined work into GitHub parent/sub-issues with native dependencies.
+- **`jhste-domain-modeling`** — clarifies domain terms, boundaries, and relationships, and records them in a glossary or ADR when requested.
 
-It does not vendor workflow skills. Use `mattpocock/skills` separately for broader planning, issue, PRD, debugging, architecture, or review workflows.
+The skills do not require or automatically call one another. A request may use more than one when it contains multiple intents. For example, invoke `jhste-grill` with `jhste-domain-modeling` to interview through a design and record the domain terms that become settled.
+
+## Behavioral boundaries
+
+- `jhste-coding` applies only when repository code must change.
+- `jhste-grill` applies when the user wants an interview or decision stress test; ordinary ambiguity alone must not start a long interview.
+- `jhste-to-tickets` drafts by default. It writes to GitHub only when the user explicitly asks to create, post, or publish the issues.
+- `jhste-domain-modeling` analyzes and proposes by default. It edits repository documentation only when the user asks to record or apply the decisions.
+
+This package intentionally omits TDD, code-review, debugging-process, Wayfinder, and architecture-audit workflows. It favors the model's baseline capabilities and repository CI or guidance, adding another skill only after a repeated real failure justifies it.
 
 ## Install user-wide from npm
 
-This package does not provide a CLI. The npm package is a small distribution bundle for the skill file.
+This package has no CLI. It distributes the four skills and their Codex metadata.
 
 ```sh
 npm install -g jhste-skills
 mkdir -p "$HOME/.agents/skills"
-cp -R "$(npm root -g)/jhste-skills/skills/jhste-coding" "$HOME/.agents/skills/"
+cp -R "$(npm root -g)/jhste-skills/skills/." "$HOME/.agents/skills/"
 ```
 
-After updating the npm package, run the copy command again to refresh the installed skill.
+Run the copy command again after updating the npm package. Restart Codex if the updated skills do not appear.
 
 ## Install user-wide from the repository
 
 ```sh
 mkdir -p "$HOME/.agents/skills"
-cp -R skills/jhste-coding "$HOME/.agents/skills/"
+cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-For repository-scoped use, copy the skill from this checkout into the target repository's `.agents/skills` directory.
+If another agent expects a different global skills directory, copy the four directories under `skills/` there. This package does not require project-local skill copies.
+
+## Development and validation
 
 ```sh
-mkdir -p /path/to/target-repo/.agents/skills
-cp -R skills/jhste-coding /path/to/target-repo/.agents/skills/
+npm test
+npm pack --dry-run
 ```
 
-If another agent expects a different skills directory, copy `skills/jhste-coding/` there instead. Restart Codex if the updated skill does not appear.
-
-## SOLID-first discipline
-
-`jhste-coding` keeps code changes small and practical, with SOLID as the main lens:
-
-- **Single Responsibility:** keep each changed unit centered on one clear job.
-- **Open/Closed:** add extension seams only when real variation would otherwise keep changing the same core logic.
-- **Liskov Substitution:** preserve caller-facing expectations such as return shape, nullability, errors, and side effects.
-- **Interface Segregation:** depend on the smallest useful contract.
-- **Dependency Inversion:** keep business rules separate from concrete side effects when it improves clarity.
-
-The skill is for active coding discipline, not broader process automation or review pipelines.
+Pushing a `v*.*.*` release tag runs GitHub Actions checks and publishes the package through npm trusted publishing.

package/README.md

@@ -2,50 +2,52 @@
 
 한국어 | [ENG](README.en.md)
 
-작은 개인용 코딩 규율 스킬입니다.
+GPT-5.6의 outcome-first, lean-prompt 지침에 맞춰 관리하는 개인용 엔지니어링 스킬 모음입니다. 각 스킬은 독립적으로 동작하며, 필요한 경우 Codex가 사용자 의도에 맞춰 자동 호출할 수 있습니다.
 
-이 저장소는 하나의 스킬만 제공합니다.
+## 스킬
 
-- `jhste-coding`: 저장소 코드 수정 중 적용하는 가벼운 SOLID-first 코딩 규율
+- **`jhste-coding`** — 기능 구현, 버그 수정, 리팩터링을 작은 변경과 관련 검증으로 완료합니다.
+- **`jhste-grill`** — 계획이나 설계를 한 번에 하나의 중요한 결정 질문으로 구체화합니다.
+- **`jhste-to-tickets`** — 명확해진 작업을 GitHub 부모/sub-issues와 native dependency로 분할합니다.
+- **`jhste-domain-modeling`** — 도메인 용어, 개념 경계, 관계를 명확히 하고 요청 시 glossary나 ADR에 반영합니다.
 
-이 저장소는 workflow 스킬을 vendoring하지 않습니다. 더 넓은 계획, 이슈, PRD, 디버깅, 아키텍처, 리뷰 workflow에는 `mattpocock/skills`를 별도로 사용하세요.
+스킬은 서로를 강제로 호출하지 않습니다. 하나의 요청이 여러 의도를 포함하면 함께 사용할 수 있습니다. 예를 들어 설계 인터뷰 중 확정된 용어를 기록하려면 `jhste-grill`과 `jhste-domain-modeling`을 함께 지정할 수 있습니다.
+
+## 동작 경계
+
+- `jhste-coding`은 실제 코드 변경 요청에만 사용합니다.
+- `jhste-grill`은 사용자가 인터뷰나 결정 검증을 원할 때 사용하며, 단순한 모호성만으로 긴 인터뷰를 시작하지 않습니다.
+- `jhste-to-tickets`는 기본적으로 초안을 만듭니다. 사용자가 GitHub에 생성·게시하라고 명시한 경우에만 외부 쓰기를 수행합니다.
+- `jhste-domain-modeling`은 기본적으로 분석하고 제안합니다. 사용자가 기록·반영을 요청한 경우에만 저장소 문서를 수정합니다.
+
+TDD, 코드 리뷰, 디버깅 절차, Wayfinder, 아키텍처 감사 workflow는 포함하지 않습니다. 모델의 기본 능력과 저장소 자체의 CI·지침을 우선하고, 반복되는 실제 실패가 확인될 때만 새 스킬을 추가합니다.
 
 ## npm으로 사용자 전역 설치
 
-이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 스킬 파일을 배포하기 위한 작은 번들입니다.
+이 패키지는 CLI를 제공하지 않습니다. npm 패키지는 네 스킬과 Codex 메타데이터를 배포하는 번들입니다.
 
 ```sh
 npm install -g jhste-skills
 mkdir -p "$HOME/.agents/skills"
-cp -R "$(npm root -g)/jhste-skills/skills/jhste-coding" "$HOME/.agents/skills/"
+cp -R "$(npm root -g)/jhste-skills/skills/." "$HOME/.agents/skills/"
 ```
 
-npm 패키지를 업데이트한 뒤에는 복사 명령을 다시 실행해야 설치된 스킬도 갱신됩니다.
+npm 패키지를 업데이트한 뒤에는 복사 명령을 다시 실행해야 설치된 스킬도 갱신됩니다. Codex가 변경된 스킬을 표시하지 않으면 다시 시작하세요.
 
 ## 저장소에서 사용자 전역 설치
 
 ```sh
 mkdir -p "$HOME/.agents/skills"
-cp -R skills/jhste-coding "$HOME/.agents/skills/"
+cp -R skills/. "$HOME/.agents/skills/"
 ```
 
-특정 저장소에서만 사용하려면 이 저장소를 내려받은 위치에서 대상 저장소의 `.agents/skills`로 복사하세요.
+다른 에이전트가 별도 전역 skills 디렉터리를 요구하면 `skills/` 아래의 네 디렉터리를 그 위치로 복사하세요. 이 패키지는 프로젝트별 스킬 복사본을 요구하지 않습니다.
+
+## 개발 및 검증
 
 ```sh
-mkdir -p /path/to/target-repo/.agents/skills
-cp -R skills/jhste-coding /path/to/target-repo/.agents/skills/
+npm test
+npm pack --dry-run
 ```
 
-다른 에이전트가 별도 skills 디렉터리를 요구하면 `skills/jhste-coding/`을 그 위치로 복사하세요. Codex가 변경된 스킬을 표시하지 않으면 다시 시작하세요.
-
-## SOLID-first 규율
-
-`jhste-coding`은 작은 실제 코드 변경에 SOLID를 주된 렌즈로 적용합니다.
-
-- **단일 책임:** 변경한 단위가 하나의 분명한 일을 하도록 유지합니다.
-- **개방/폐쇄:** 실제 변형이 반복해서 같은 핵심 로직을 바꾸게 만들 때만 확장 지점을 둡니다.
-- **리스코프 치환:** 반환 형태, null 가능성, 오류, 부수 효과 같은 호출자 기대를 보존합니다.
-- **인터페이스 분리:** 필요한 만큼의 작은 계약에 의존합니다.
-- **의존성 역전:** 명확해질 때 비즈니스 규칙과 구체적인 부수 효과를 분리합니다.
-
-이 스킬은 코드 작성 중 쓰는 규율이며 더 넓은 프로세스 자동화나 리뷰 파이프라인이 아닙니다.
+릴리스 태그 `v*.*.*`를 푸시하면 GitHub Actions가 테스트 후 npm trusted publishing으로 공개 배포합니다.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "jhste-skills",
-  "version": "0.5.2",
-  "description": "A single lightweight SOLID-first coding discipline skill.",
+  "version": "0.6.0",
+  "description": "A lean GPT-5.6-oriented engineering skill set for coding, decision interviews, GitHub tickets, and domain modeling.",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -9,14 +9,14 @@
     "url": "git+https://github.com/jhste102lab/jhste-skills.git"
   },
   "files": [
-    "skills/jhste-coding/SKILL.md",
+    "skills",
     "README.md",
     "README.en.md",
     "CHANGELOG.md",
     "LICENSE"
   ],
   "scripts": {
-    "test": "node --input-type=module -e \"import fs from 'node:fs'; const exists = (p) => fs.existsSync(p); const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8')); const skill = 'skills/jhste-coding/SKILL.md'; if (!exists(skill)) throw new Error('missing skill'); const text = fs.readFileSync(skill, 'utf8'); if (!/^---\\nname: jhste-coding\\ndescription: .+\\n---/m.test(text)) throw new Error('invalid skill frontmatter'); const dirs = fs.readdirSync('skills', { withFileTypes: true }).filter((d) => d.isDirectory()).map((d) => d.name); if (dirs.length !== 1 || dirs[0] !== 'jhste-coding') throw new Error('expected only jhste-coding skill'); for (const file of pkg.files) if (!exists(file)) throw new Error('package file does not exist: ' + file); for (const file of ['README.md', 'README.en.md']) { const body = fs.readFileSync(file, 'utf8'); if (!body.includes('jhste-coding')) throw new Error(file + ' does not describe jhste-coding'); for (const match of body.matchAll(/\\[[^\\]]+\\]\\(([^)]+)\\)/g)) { const href = match[1]; if (!/^(https?:|mailto:|#)/.test(href) && !exists(href.split('#')[0])) throw new Error(file + ' has broken link: ' + href); } }\""
+    "test": "node scripts/validate-package.mjs"
   },
   "engines": {
     "node": ">=18"

package/skills/jhste-coding/SKILL.md

@@ -1,37 +1,33 @@
 ---
 name: jhste-coding
-description: Use for implementation, bug fixes, and refactors that modify repository code with lightweight SOLID-first discipline. Do not use for read-only review, planning, architecture discussion, or documentation-only work.
+description: Implement features, fix bugs, and refactor repository code with a small, contract-preserving change and relevant validation. Use when the requested outcome requires modifying code. Do not use for read-only analysis, planning, interviewing, issue creation, or domain documentation.
 ---
 
-# jhste-coding
+# JHSTE Coding
 
-Use this skill to write small, direct, readable code guided primarily by SOLID.
+## Goal
 
-SOLID is the main discipline. The guardrails below keep the code practical.
+Deliver the requested behavior with the smallest clear change that fits the repository.
 
-## Core rule
+## Success criteria
 
-Prefer the smallest clear change that fits the requested problem and keeps the code SOLID-aligned.
+- The requested behavior is implemented without unrelated scope.
+- Existing caller-visible contracts remain intact unless the request changes them.
+- Relevant non-destructive validation passes, or the unverified surface and reason are reported.
+- Uncertain, partial, and failed states are not silently treated as success.
 
-Use SOLID for the current change; speculative architecture, broad refactors, and abstraction layers are outside this skill's purpose.
+## Working contract
 
-## SOLID discipline
+Inspect the affected code, repository guidance, and nearby patterns before editing. Reuse established boundaries and abstractions when they fit. Introduce a new abstraction only when the current change has real variation, repeated logic, or a concrete side-effect boundary that becomes clearer by doing so.
 
-- **S — Single Responsibility:** keep each changed function, module, or class centered on one clear job. Choose names that make the job easy to see.
-- **O — Open/Closed:** add an extension seam when real variation or repeated branching would otherwise keep changing the same core logic. Keep simple branches when they read better.
-- **L — Liskov Substitution:** preserve caller-facing expectations: return shape, nullability, errors, side effects, timing assumptions, and documented behavior.
-- **I — Interface Segregation:** depend on the smallest useful contract. Prefer narrow parameters over broad objects, global context, or large config bags when only a small slice is needed.
-- **D — Dependency Inversion:** keep business rules separate from concrete side effects when that separation makes the code clearer. Make database, network, filesystem, browser, queue, email, payment, clock, environment, and secret boundaries easy to see.
+Treat public return shapes, nullability, errors, side effects, ordering, and documented behavior as contracts. Validate external input at its entry boundary. Keep credentials, sessions, authorization data, and sensitive payloads out of logs and responses.
 
-## Practical guardrails
+For implementation requests, make in-scope local edits and run the narrowest useful validation without pausing for routine confirmation. Stop before an external write, destructive action, or material expansion of scope unless the user authorized it.
 
-- Interfaces, factories, base classes, dependency containers, and strategy layers fit best when they clarify a real boundary, remove real repeated change, or protect a caller contract.
-- Validate external input where it enters the code path.
-- Make uncertain, partial, and failed states visible rather than silently treating them as success.
-- Keep secrets, tokens, credentials, cookies, authorization headers, sessions, and raw sensitive payloads out of logs and responses.
-- After changing code, run the narrowest relevant non-destructive validation. If it cannot run, state why; do not imply the change is verified.
-- When adding or changing tests, focus on observable behavior related to the change.
+## Validation
+
+Choose checks that exercise the changed behavior: targeted tests first, then applicable type, lint, build, or smoke checks. Do not add a test at an artificial seam merely to claim coverage. Never imply that a check ran when it did not.
 
 ## Final response
 
-Report what changed, what validation ran, and any material caveat; omit unchanged details and generic background.
+Report the outcome, validation performed, and any material caveat or remaining blocker. Omit generic background and unchanged details.

package/skills/jhste-coding/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Coding"
+  short_description: "Make scoped code changes with relevant validation"
+  default_prompt: "Use $jhste-coding to implement this change with the smallest clear patch and relevant validation."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-domain-modeling/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: jhste-domain-modeling
+description: Clarify domain terminology, concept boundaries, and relationships, and optionally maintain a project glossary or ADRs. Use when the user asks to define domain language, resolve conflicting terms, build a glossary, model domain concepts, or record a significant domain decision. Do not invoke for ordinary coding, generic architecture discussion, or incidental naming choices.
+---
+
+# JHSTE Domain Modeling
+
+## Goal
+
+Establish precise shared language that matches the intended domain and the behavior implemented by the code.
+
+## Investigate
+
+Read existing glossary, context-map, ADR, issue, and code conventions before proposing terms. Treat implementation as evidence, not unquestioned truth. Surface contradictions between the user's model, documentation, and code.
+
+Clarify one material concept at a time. Use concrete scenarios and edge cases to test boundaries, identities, state transitions, and relationships. Prefer one canonical term per concept and distinguish concepts that only appear similar.
+
+Keep the glossary free of implementation details. Keep specifications, task notes, and temporary decisions in their own artifacts.
+
+## Analyze versus write
+
+Analyze and propose changes by default. Edit `CONTEXT.md`, a repository-equivalent glossary, or an ADR only when the user asks to record, update, or apply the decisions. Follow the repository's existing location and format; create a new convention only with user authorization.
+
+Offer an ADR only when the decision is all three:
+
+- costly to reverse;
+- surprising without its rationale;
+- the result of a real trade-off between alternatives.
+
+Do not create an ADR for routine, temporary, or self-evident choices.
+
+## Completion
+
+Report:
+
+- terms added, changed, rejected, or still ambiguous;
+- scenarios used to test the model;
+- code or document mismatches found;
+- files changed, if writing was authorized;
+- ADR candidates and unresolved decisions that materially block the model.

package/skills/jhste-domain-modeling/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Domain Modeling"
+  short_description: "Clarify domain terms, boundaries, and decisions"
+  default_prompt: "Use $jhste-domain-modeling to clarify the domain language and surface any conflicting concepts."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-grill/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: jhste-grill
+description: Interview the user one decision at a time to sharpen or stress-test a plan, product behavior, or design. Use when the user asks to be interviewed, grilled, questioned, or guided through unresolved decisions. Do not invoke merely because an ordinary request has a small ambiguity.
+---
+
+# JHSTE Grill
+
+## Goal
+
+Reach enough shared understanding for the user to make or delegate the next layer of work confidently.
+
+## Interview
+
+Inspect available code, documents, and prior decisions instead of asking the user for discoverable facts. Ask about choices that belong to the user: desired behavior, scope, priorities, compatibility, failure behavior, and consequential trade-offs.
+
+Ask one decision question at a time. For each question, provide a recommended answer with its main reason and meaningful trade-off. Follow dependencies between decisions; do not explore branches that cannot affect the outcome.
+
+Challenge contradictions and unsupported assumptions directly. Preserve explicit user choices. Do not implement code, publish issues, or edit domain documents as part of this skill alone.
+
+## Stop condition
+
+Stop when the goal, success criteria, scope, important behavior, and material failure cases are clear enough for the intended next step. Do not continue into reversible preferences or implementation details that the next worker can decide safely.
+
+## Outcome
+
+Summarize only what the session established:
+
+- goal and success criteria;
+- decisions and their reasons;
+- constraints and out-of-scope items;
+- unresolved questions that still block progress;
+- domain terms affected and ADR candidates, when material.

package/skills/jhste-grill/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE Grill"
+  short_description: "Sharpen plans through focused decision interviews"
+  default_prompt: "Use $jhste-grill to interview me one decision at a time and summarize what we decide."
+
+policy:
+  allow_implicit_invocation: true

package/skills/jhste-to-tickets/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: jhste-to-tickets
+description: Turn a defined plan, specification, or conversation into GitHub parent and sub-issues with acceptance criteria and native dependency relationships. Use when the user asks to draft, split, organize, or publish work as GitHub issues or tickets. Do not use for ordinary planning or work whose execution path still requires major investigation.
+---
+
+# JHSTE To Tickets
+
+## Goal
+
+Create a GitHub-native work graph whose ready issues can be claimed and completed independently by fresh workers.
+
+## Resolve context
+
+Identify the GitHub repository from the request or current remote. Read any referenced issue, specification, conversation context, repository guidance, and relevant code. Ask only for a missing decision that would materially change scope, issue boundaries, or dependencies.
+
+## Draft the work graph
+
+Use a parent issue to hold the shared goal, success criteria, decisions, constraints, open questions, and out-of-scope items. Reuse an existing parent when supplied. Otherwise draft one.
+
+Split implementation into tracer-bullet issues. Each issue must:
+
+- deliver a narrow but complete behavior across the layers it needs;
+- be independently demonstrable or verifiable;
+- fit one fresh worker context;
+- state observable acceptance criteria and relevant validation;
+- preserve only the shared context needed to execute it.
+
+Do not create separate database, API, UI, and test issues when none delivers behavior alone. Do not split work that is already safe and reviewable as one issue.
+
+For a wide mechanical change that cannot land green as vertical slices, use expand-migrate-contract: introduce the compatible form, migrate bounded batches, then remove the old form.
+
+Add a dependency only when the blocked issue cannot start until the blocker completes. Convenience or preferred order is not a dependency. The open, unblocked issues form the execution frontier.
+
+## Draft versus publish
+
+Draft by default. Present the parent, sub-issues, and dependency edges without writing to GitHub.
+
+Publish when the user explicitly asks to create, post, or publish the issues. That request authorizes these GitHub writes; it does not authorize unrelated repository changes. Create the parent and sub-issues, use GitHub's native parent and blocked-by relationships, then return their links and the initial frontier.
+
+When native relationships are unavailable, report the limitation before falling back to references in issue bodies.
+
+## Issue shape
+
+Each sub-issue should contain:
+
+```markdown
+## Outcome
+
+## Acceptance criteria
+- [ ] Observable result
+- [ ] Relevant validation
+
+## Context
+
+## Coordination
+- Blocked by: native GitHub relationship, or None
+- Integration point: branch, contract, or artifact when known
+```
+
+Avoid speculative file paths, implementation recipes, and code snippets that will go stale. Include a prototype-derived shape only when it records a decision more precisely than prose.
+
+## Completion
+
+Before finishing, verify that every issue has a clear outcome, every dependency is necessary, and at least one frontier issue exists unless an explicit external blocker prevents all work.

package/skills/jhste-to-tickets/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "JHSTE To Tickets"
+  short_description: "Turn defined work into GitHub issue slices"
+  default_prompt: "Use $jhste-to-tickets to draft GitHub issues for this defined body of work."
+
+policy:
+  allow_implicit_invocation: true