This SKILL.mdEntry point. For details, read the relevant file under references .
Important: For a new PJ, scaffold and configuration file creationmust not begin until the entry flow of this skill is completed and the user approves the rule application. During the entry flow,planning materialscreation is an exception to the scaffold prohibition (for the format and distribution procedure, follow the documentation distribution skill used in conjunction).
Situations for using this skill
- Create a new PJ
- Decide the initial structure of a new repository
- Set up the development foundation including devcontainer and mise from the start
- Decide the standard frontend toolchain
- Want to incorporate pnpm supply chain measures into the initial setup
- Want to incorporate secret scan into the initial setup
- Want to incorporate automatic lint/fmt execution after AI agent edits into the initial setup
- Want to apply a quality gate by running all tests before push
Entry flow
For a new PJ launch, proceed through the following steps in order. Do not start actual work such as devcontainer creation, scaffold, or adding configuration files before approval of phase 4 (scaffold).
- Create an issue(if not yet created). Put only the minimal summary of the issue in the description
- Tentatively place the PJ overview. Prompt and reasonable defaults as the starting point and fill in the gaps; mark unclear points as "needs confirmation".Do not use AskQuestion before presenting the planning materials to the user
- Create the planning materials. Include the rule application table, items needing confirmation, and recommended reasons in the body of the materials (for the format, follow the documentation distribution skill used in conjunction)
- Put the confirmed material URL or link in the issue and present it to the user first. Keep chat to a short pointer and URL; do not paste the full table and bombard them with questions
- Wait until the user views the materials and makes a decision or replies
- Once application / non-application of all rules is finalizedproceed to phase 4 (scaffold)
Phase 1: Tentative placement of the PJ overview
Tentatively place the PJ overview starting from the information included in the prompt. For unstated items, do not ask questions; either applyreasonable defaults or mark them as "needs confirmation".
Do not use AskQuestion before presenting the planning materials to the user.
Items to grasp (for tentative placement):
| Item | Example |
|---|---|
| PJ name / purpose | Internal dashboard, CLI tool, API server |
| Repository type | New / existing empty repository / monorepo addition |
| Delivery form | Web UI / API only / CLI / library / composite |
| Main languages/FWs | TypeScript, Go, Python, etc. |
| Presence of frontend | Whether to provide a browser-facing UI |
| frontend FW | SvelteKit / React / none, etc. |
| devcontainer | Whether to use (Default: none） |
| Development environment | CI destination (GitHub Actions, etc.), local runtime management policy |
| CI runner | ubuntu-latest / Mac Studio self-hosted / mixed |
| Special notes | monorepo structure, continuing existing toolchain, reason for not adopting Vite+, etc. |
Reasonable defaults
For items not stated in the prompt, provisionally set them based on the following. Treat anything that cannot be determined as "Needs confirmation."
- devcontainer: Default isNot applicable(Do not introduce unless explicitly stated to use it)
- Presence of frontend: If not stated,Needs confirmation
- frontend FW: Estimate only when it can be assumed that frontend is present. Otherwise,Needs confirmation
- CI: If not stated, assume GitHub Actions assume
- CI runner: If not stated, assume
ubuntu-latestassume - mise-centric operation, gitleaks, pre-commit / pre-push: In principleApplyRecommended (adjust for backend even in PJs without frontend)
- Frontend-oriented rules such as pnpm / Vite+ / kiso.css: Until it is confirmed that frontend is present,Needs confirmationor not applicable
Phase 2: Creating the rule application table
Rule list Scan all entries and, based on the PJ overview, determine each rule'srecommendation(apply / not applicable / needs confirmation).
- Apply: Conditions are met, and introduce according to the standard policy
- Not applicable: Conditions are not met, or it is unnecessary under the PJ policy
- Needs confirmation: A conditional rule that requires user judgment
The source of truth is the planning document. Put the rule application table, items needing confirmation, and recommendation reasons in the body of the document. In chat, it is acceptable to present only a short pointer and the confirmed document URL or link.
Rule application table (document body template)
The format of the table to put in the body of the planning document. The source of truth is the document. Do not paste the full table into chat.
## ルール適用表（確認用）
| ルール | 条件 | 推奨 | 理由 |
| ------------- | ---- | ---- | ------------------ |
| devcontainer | オプション | 不適用 | デフォルトはローカル開発。必要時のみ導入 |
| mise 中心運用 | 汎用 | 適用 | tools / tasks 集約 |
| ... | ... | ... | ... |
### 要確認項目
- frontend の有無: プロンプト未記載のため要確認
- Vite+: frontend ありの場合に適用推奨
Phase 3: User confirmation and adjustment
The primary means are replies to the planning document and the issue.
- Present the confirmed document URL or link to the user first
- Wait until the user reads the document and replies with approval, changes, or additional requirements for the recommendations
- When revising the document to reflect the reply, update the issue according to the accompanying document distribution skill
- Until apply / not applicable is finalized for all rulesRepeat phase 3
AskQuestion は、After presenting the planning materialsand only blockers that cannot be resolved by checking the main text of the materialslimited to.AskQuestion before presenting the materials or in the same turn as presenting them is prohibited。
Phase 4: Start creation after approval
Once the user approves the rule application, only then begin scaffolding and creating configuration files.
- In the approved table, apply read the reference files corresponding to the row and implement (how to proceed with reading）
- not apply Do not create files or configurations that correspond to rules marked as not applicable
- Before completion, checklist.md check against the approved rules
Keep the approved table briefly as a work log (which rules were applied / not applied).
Rule list
List all rules. In phase 2, use this table as a basis to decide apply / not apply for each project.
| Rule | Condition | Reference | Overview |
|---|---|---|---|
| devcontainer | Optional (default: not applied) | devcontainer-mise.md | Only when used, .devcontainer/devcontainer.json Create. Unify the execution location |
| mise-centric operation | General-purpose | devcontainer-mise.md | mise.toml consolidate tools / env / tasks into |
| Check user settings | When applying devcontainer | devcontainer-mise.md | dev.containers.*, dotfiles.* Check and avoid duplicate settings |
| Start from sample files | General-purpose | devcontainer-mise.md | references/sample-files/ Use as the starting point for initial files |
| gitleaks | General-purpose | gitleaks-pre-commit.md | Introduce secret scan in both GitHub Action and pre-commit |
| self-hosted runner CI | CI = Mac Studio self-hosted を apply | kf-g-github-actions-self-hosted-runner-label | workflow の runs-on を [self-hosted, <repo-slug>] Fix to. If the host runner is not registered, merge is not possible |
| pre-commit / pre-push | General-purpose | gitleaks-pre-commit.md | pre-commit, gitleaks Manage with mise. Enable local hook |
| pre-push all tests | Code changes present | pre-push-test.md | Before push, mise run test Run all tests with. If even one fails, reject the push |
| pnpm fixed | frontend present | frontend-pnpm.md | Fix package manager to pnpm |
| pnpm supply chain | frontend present | frontend-pnpm.md | pnpm-workspace.yaml security settings in |
| Vite+ | frontend present | frontend-vite-plus.md | Align build / dev / check / test with the Vite+ style |
| Svelte / SvelteKit | frontend + Svelte adopted | frontend-vite-plus.md | Use the latest stable version |
| kiso.css | frontend UI present | frontend-vite-plus.md | Introduce reset CSS with pnpm and load it first in entry |
| Oxlint / Oxfmt | frontend present | lint-fmt-hooks.md | frontend linter / formatter. If unsupported, investigate alternatives |
| lint / format command | Code changes present | lint-fmt-hooks.md | package.json scripts と mise run put in task |
| lint/fmt hooks after editing | Code changes present | lint-fmt-hooks.md | Run lint/fmt with project hooks after AI agent edits |
| Hook after Tab completion | Code edits present + tool support | lint-fmt-hooks.md | Configure if the tools used support it (optional) |
| Full set of daily mise tasks | General | devcontainer-mise.md | install / dev / check / test / build / lint / format / hooks-install |
How to read the conditions
| Condition | Applicability decision |
|---|---|
| General | In principle, recommended for all new PJs |
| Optional (default: not applied) | Not applied by default. Applied only when the user explicitly chooses to use it |
| When devcontainer is applied | Only when the devcontainer rule is applied confirmed to apply |
| Frontend present | Includes browser-facing UI or a frontend package |
| Frontend UI present | Frontend that provides user-facing screens and styles |
| Frontend + Svelte adopted | Frontend present, and Svelte / SvelteKit adopted |
| Code edits present | Source code is managed and edited in the repository |
| Code edits present + tool support | Apply post-edit lint/fmt hooks, and Cursor etc. provides a post-Tab-completion hook |
| When CI = Mac Studio self-hosted is applied | Only when CI runner = Mac Studio self-hosted is selected in Phase 1, apply the self-hosted runner CI rule |
For PJs without a frontend, frontend-oriented rules such as pnpm / Vite+ / kiso.css / Oxlint・Oxfmt arenot applied. Select and apply lint / format commands and post-edit hooks according to the backend language.
How to proceed with reading
The implementation procedure after approval is authoritative on the references side. SKILL.md handles only the entry point and rule selection.
- Entry flow Complete.
- Rule list で Applied Read and implement the files in the "Reference" column of each row marked as applied.
- Before completion, checklist.md check against the approved rules.
Output policy
- Before the entry flow is complete,creating the scaffold and configuration filesdo not begin. Creating and presenting planning materials is done during the entry flow.
- During the entry flow, limit yourself to explaining the policy and presenting confirmed material URLs or links. The authoritative rule application table is the planning materials.
- After approval, do not stop at just explaining the policy; create the files corresponding to the approved rules.
- Leave a brief record of the approved rule application table.
Reference files
| File | When to read |
|---|---|
| checklist.md | Final check before Phase 4 completion |
| Each reference in the rule list | In Phase 4, Apply line implementation |