create-yss-spec 3.4.8 → 3.4.9

package/template/.codex/skills/product-design/skills/ideate/SKILL.md

@@ -86,7 +86,7 @@ Rules you must follow:
 
 - Use the Image Gen prompt below.
 - Use the built-in Image Gen tool.
-- Generate exactly three independent images unless the user overrides the count.
+- Respect the user-requested count; default to three distinct options only when exploration is needed. Stop after the selected direction answers the current design decision.
 - Generate options in parallel when possible.
 - Each option must be its own Image Gen result. Do not put multiple ideas in one image.
 - Attach provided screenshots, files, app captures, Figma references, and visual source material as moodboard inspiration when available.
@@ -108,55 +108,7 @@ If the user likes parts of more than one option, combine those choices into a ne
 
 ## Image Gen Prompt
 
-Adapt this prompt to the confirmed design brief, attach any available image references, and send it to Image Gen:
-
-```text
-Create realistic, production-quality UI designs with clear hierarchy, strong typography, intentional imagery, and purposeful spacing.
-
-Keep the design simple. Avoid busy interfaces. Every section should have a clear purpose, and every element should earn its place.
-
-Prioritize clarity, whitespace, and usability over decorative complexity.
-
-### Target Dimensions
-
-Pick the dimensions that best match the user's request and any provided visual reference.
-
- - Mobile app: `390 x 844`
- - Tablet app: `834 x 1194`
- - Desktop app, dashboard, admin, or SaaS: `1440 x 1024`
- - Landing or marketing page: `1440` wide and scrollable
- - Modal, panel, widget, or component: natural container size
- - Provided screenshot, Figma frame, mockup, or reference image: match its dimensions and aspect ratio when the user wants to continue from that visual
-
-Avoid crowding. Make the design fit the chosen dimensions cleanly, with realistic spacing, readable type, and no clipped content.
-
-### Layout
-
-When deciding how to lay elements out on the page, this should be your priority order for tools to differentiate sections:
-
-1. Use spacing, grouping, alignment, typography, and hierarchy on the same product surface.
-2. Use simple dividers or row separators.
-3. Use a subtle surface tint only when the base surface is not enough.
-4. Use borders only when separation still is not clear.
-5. Use shadows/elevation last, and sparingly.
-
-Don'ts:
- - Do not default to a centered "app card" (the whole UI is in a card on the page) on top of a contrasting page background. Use the base page surface first unless the source product or user explicitly asks for a contained app panel.
- - Do not put cards inside cards. Do not make every major section a card. Do not make each list item its own card unless each item is truly a standalone object. A normal list should usually read as one grouped surface with lightweight row separation.
- - Do not make up extraneous features. Add only the things essential to accomplish what the prototype's goal is. Don't make up more features just to fill out a UI.
-
-### Typography
-
- - Anchor UI typography to readable product sizes. Body text should usually sit between 14px and 16px, with the rest of the type scale built around that baseline.
- - Keep long-form text to a comfortable line length, generally no more than 65 characters per line.
- - Use no more than 2 fonts in a UI. You can use any font available in the project, or fonts provided free on Google Fonts. Pick the font that is best for the goal of the product and that matches with its intended look and feel.
-
-### Presentation
-
- - Do not add browser or device chrome around the mockup.
- - Do not put multiple ideas into a single image generation.
- - Vary each idea as much as possible while adhering to the constraints given entirely.
-```
+在实际生成方案图前，按目标尺寸、布局和字体需要读取 [图像提示模板](references/image-prompt-patterns.md)。用户已选来源、方案数量与当前设计决策优先；模板不要求补造无关维度。
 
 ## Output
 

package/template/.codex/skills/product-design/skills/ideate/references/image-prompt-patterns.md

@@ -0,0 +1,51 @@
+## Image Gen Prompt
+
+Adapt this prompt to the confirmed design brief, attach any available image references, and send it to Image Gen:
+
+```text
+Create realistic, production-quality UI designs with clear hierarchy, strong typography, intentional imagery, and purposeful spacing.
+
+Keep the design simple. Avoid busy interfaces. Every section should have a clear purpose, and every element should earn its place.
+
+Prioritize clarity, whitespace, and usability over decorative complexity.
+
+### Target Dimensions
+
+Pick the dimensions that best match the user's request and any provided visual reference.
+
+ - Mobile app: `390 x 844`
+ - Tablet app: `834 x 1194`
+ - Desktop app, dashboard, admin, or SaaS: `1440 x 1024`
+ - Landing or marketing page: `1440` wide and scrollable
+ - Modal, panel, widget, or component: natural container size
+ - Provided screenshot, Figma frame, mockup, or reference image: match its dimensions and aspect ratio when the user wants to continue from that visual
+
+Avoid crowding. Make the design fit the chosen dimensions cleanly, with realistic spacing, readable type, and no clipped content.
+
+### Layout
+
+When deciding how to lay elements out on the page, this should be your priority order for tools to differentiate sections:
+
+1. Use spacing, grouping, alignment, typography, and hierarchy on the same product surface.
+2. Use simple dividers or row separators.
+3. Use a subtle surface tint only when the base surface is not enough.
+4. Use borders only when separation still is not clear.
+5. Use shadows/elevation last, and sparingly.
+
+Don'ts:
+ - Do not default to a centered "app card" (the whole UI is in a card on the page) on top of a contrasting page background. Use the base page surface first unless the source product or user explicitly asks for a contained app panel.
+ - Do not put cards inside cards. Do not make every major section a card. Do not make each list item its own card unless each item is truly a standalone object. A normal list should usually read as one grouped surface with lightweight row separation.
+ - Do not make up extraneous features. Add only the things essential to accomplish what the prototype's goal is. Don't make up more features just to fill out a UI.
+
+### Typography
+
+ - Anchor UI typography to readable product sizes. Body text should usually sit between 14px and 16px, with the rest of the type scale built around that baseline.
+ - Keep long-form text to a comfortable line length, generally no more than 65 characters per line.
+ - Use no more than 2 fonts in a UI. You can use any font available in the project, or fonts provided free on Google Fonts. Pick the font that is best for the goal of the product and that matches with its intended look and feel.
+
+### Presentation
+
+ - Do not add browser or device chrome around the mockup.
+ - Do not put multiple ideas into a single image generation.
+ - Vary each idea as much as possible while adhering to the constraints given entirely.
+```

package/template/.codex/skills/product-design/skills/image-to-code/SKILL.md

@@ -32,7 +32,7 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
 3. If the provided design is a mobile viewport, build a mobile app. If it's unclear, default to desktop.
 
-4. Review the reference design, catalog every image asset in the design, and use the Image Gen tool to create individual images for each one. Zoom in so you can catch every asset that needs to be generated.
+4. Review the reference design and inventory its assets. Reuse provided or authorized source assets unchanged unless modification is requested. Generate only a genuinely missing asset when its creation is in scope and the tool is available; name unresolved asset gaps.
 
     Examples include:
 
@@ -47,7 +47,7 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
     Rules:
 
-    - CRITICAL RULE: Do not create custom div art, CSS art, inline SVGs, handcrafted SVGs, HTML element drawings, div/span shapes, CSS drawings, gradients, emoji, or text glyphs instead of real icons and image assets ever. Use the built-in Image Gen tool for images and the closest matching icon library for icons.
+    - CRITICAL RULE: Do not replace approved source assets with unapproved approximate drawings or placeholders. Reuse provided SVGs and other original assets; only missing in-scope assets require a generation or library capability.
     - If text is part of an image asset, keep it in the image asset. Examples include full bleed hero images, signs, posters, packaging, storefronts, article art, and illustrations where the type belongs to the visual itself. Do not crop the background image and recreate that text with transparent text boxes, HTML, CSS, or separate overlay layers unless the source clearly shows editable UI text sitting on top of the image.
     - Do not use generic placeholders where the reference implies custom visual content.
     - Generated assets must share the same art direction, palette, rendering style, and design language as the reference mockup.
@@ -61,9 +61,9 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
 
     Rules:
 
-    - CRITICAL RULE: Do not create custom inline SVGs, handcrafted SVGs, HTML element drawings, div/span shapes, CSS drawings, gradients, emoji, or text glyphs. Use the built-in Image Gen tool to generate assets and use the closest matching icon library for icons.
+    - CRITICAL RULE: Preserve original SVGs, icon assets and code-native visual components. Do not substitute approximate drawings without approval. Use a matching library or generation tool only for missing in-scope assets.
 
-8. Build the app starting with [local-prototype-preflight](../../references/local-prototype-preflight.md). Build all interactions, ensuring the app is complete, functional, and interactive: all controls and states activated and functional.
+8. Build the app starting with [local-prototype-preflight](../../references/local-prototype-preflight.md). Carry the confirmed brief's `interactivity` and `required_states`. For static scope, implement faithful visual states without adding action workflows; for interactive scope, implement and verify the agreed controls and recovery states.
 
     Examples include:
 
@@ -73,12 +73,12 @@ CRITICAL: THIS IS NOT GUIDANCE. THIS IS A CHECKLIST TO COMPLETE.
     - Clickable cards and buttons
     - Animated affordances if implied by the design
     - Newsletter forms, tags, filters, or navigation elements shown in the mockup
-    - Bring the thing to life. Do not deliver a static site; the less you do, the more the designer has to add.
+    - A static prototype is complete when the agreed visual/state review is supported; do not expand it into a functional product.
 
     Rules:
 
     - Place every image asset you generated into its position before proceeding. I repeat, replace all placeholders, including CSS/SVG placeholders, before proceeding.
-    - Do not leave visible controls as static chrome. Do not create new pages or routes unless the user asks for them.
+    - For interactive scope, required controls must work; for static scope, clearly label simulated controls. Do not create new pages or routes unless requested.
 
 9. Run the local app.
 

package/template/.codex/skills/product-design/skills/index/SKILL.md

@@ -41,10 +41,10 @@ For new app, prototype, redesign, or UI build requests without a URL, screenshot
 
 - Run `$get-context`.
 - After the brief is approved, route to `$ideate`.
-- Show exactly three visual options and wait for the user to choose one.
+- Show the user-requested number of visual options (default three when exploration is needed) and wait for the user to choose one.
 - Do not scaffold, edit files, or start a server before a visual option is selected.
 
-`Full working version`, `no refs`, `go for it`, `make an assumption`, or a confirmed brief do not waive this.
+A confirmed selected visual source skips ideation. Otherwise retain the visual-selection step, respecting the user-requested option count; a static brief does not authorize full interaction.
 
 ## User Context
 

package/template/.codex/skills/product-design/skills/prototype/SKILL.md

@@ -65,7 +65,7 @@ Required next steps:
 Required next steps:
 
 - `$get-context` - confirm the design brief, including the product idea, user goal, visual direction, source constraints, and interactivity level.
-- `$ideate` - generate exactly three app or website design options; show them and wait for selection.
+- `$ideate` - generate the requested number of app or website design options (default three); show them and wait for selection.
 - `$image-to-code` - only after the user selects an option.
 
 ### Redesign product
@@ -75,7 +75,7 @@ Required next steps:
 Required next steps:
 
 - `$get-context` - confirm the design brief, including the redesign goal, visual direction, source constraints, and interactivity level.
-- `$ideate` - attach the provided app or website design to ImageGen; generate exactly three redesign options; show them and wait for selection.
+- `$ideate` - attach the provided app or website design to ImageGen; generate the requested number of redesign options (default three); show them and wait for selection.
 - `$image-to-code` - only after the user selects an option.
 
 "Redesign this {URL}"
@@ -83,7 +83,7 @@ Required next steps:
 Required next steps:
 
 - `$get-context` - confirm the design brief, including the target URL, redesign goal, source constraints, and interactivity level.
-- `$ideate` - attach provided app or website screenshot at the URL to ImageGen; generate exactly three redesign options; show them and wait for selection.
+- `$ideate` - attach provided app or website screenshot at the URL to ImageGen; generate the requested number of redesign options (default three); show them and wait for selection.
 - `$image-to-code` - only after the user selects an option; use the URL as reference for existing content, structure, and interactions.
 
 "Redesign my app"
@@ -93,7 +93,7 @@ Required next steps:
 - `$get-context` - confirm the design brief, including the app surface, redesign goal, source constraints, and interactivity level.
 - Find the app or website in the codebase.
 - If there is more than one possible target, ask the user which one to redesign and whether they want to edit it directly or create a fresh prototype.
-- `$ideate` - use the existing app or website as the source; generate exactly three redesign options; show them and wait for selection.
+- `$ideate` - use the existing app or website as the source; generate the requested number of redesign options (default three); show them and wait for selection.
 - `$image-to-code` - only after the user selects an option; refer to [references/existing-codebase-edits.md](references/existing-codebase-edits.md)
 
 ### Extend product
@@ -120,9 +120,9 @@ When the user references a product name without a source URL or image, use the b
 
 - Written design direction is not a visual target. Use it as input to `$ideate` and ImageGen.
 - Do not build from a brief alone.
-- For redesigns, use `$ideate` to generate exactly three design options, show them, and wait for the user to choose one.
+- For redesigns, use `$ideate` to generate the requested number of design options (default three), show them, and wait for the user to choose one.
 - Do not build a redesign until the user has chosen a design option.
-- When a new product has no visual target after `$get-context`, use `$ideate` to generate exactly three design options, show them, and wait for the user to choose one.
+- When a new product has no visual target after `$get-context`, use `$ideate` to generate the requested number of design options (default three), show them, and wait for the user to choose one.
 - If the user gives feedback, or says they like more than one design, use `$ideate` to create a new ImageGen mock with the feedback or combined direction before build.
 - Pass the user's written direction and attached design references into `$ideate` and ImageGen.
 - If the current folder looks like an existing prototype and it is unclear whether to edit it or create a new one, ask the user.

package/template/.codex/skills/product-design/skills/url-to-code/SKILL.md

@@ -116,7 +116,7 @@ Do not inspect every saved reference. Inspect only what the current task needs.
 ## Hard Rules
 
 - Capture source evidence first. Do not scaffold, write app code, start a server, or create the local prototype until desktop capture, mobile capture, key states, and every required asset, icon, control mark, and font is captured or replaced.
-- Do not hand off until every single interaction and state is captured from the target.
+- Before handoff, capture and verify the agreed routes, key states and interactions within the confirmed scope. Record inaccessible states as gaps; do not expand a bounded clone into the entire source product.
 - Do not build from memory, screenshots alone, guessed CSS, generic assets, or prior chats.
 - Do not implement a saved state without source screenshot plus the available DOM/style/layout evidence for that state.
 - Do not use hotlinked source assets in the final app.

package/template/.codex/skills/product-design/skills/user-context/SKILL.md

@@ -51,7 +51,7 @@ If the file does not exist, continue normally unless the user asks to set up Pro
 
 ## Preflight
 
-When any Product Design workflow needs saved context, run:
+Resolve this skill's directory first. Run the following command from that directory (or use its absolute script path), only when the workflow needs saved context. Reuse the loaded result while state paths/digests and relevant scope are unchanged:
 
 ```bash
 python3 scripts/user_context_preflight.py

package/template/.codex/skills/prototype/SKILL.md

@@ -23,4 +23,4 @@ The two branches produce very different artifacts — getting this wrong wastes
 3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
 4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast.
 5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
-6. **Capture it when done.** Fold any validated decision into the real code, then capture the prototype itself as a **primary source**: commit it to a throwaway branch, out of main, and leave a context pointer to that branch on the implementation issue. Capture the answer too — the verdict and the question it settled — in the issue or a commit. The main branch keeps only the validated decision.
+6. **Capture the evidence.** Save the prototype and the question, inputs, observed result and limitations in the authorized local output location. Return validated decisions to the current design owner. Production implementation still requires its approved contract; Git commit/push and tracker publication each require applicable authorization. An experiment does not authorize those actions.

package/template/.codex/skills/prototype-review/SKILL.md

@@ -19,7 +19,7 @@ Run this independent gate only when UI changes affect a primary user flow, navig
 - `docs/.scratch/<feature>/design/<feature>-interaction-spec.md` or prototype link.
 - State matrix, preferably based on `docs/design/templates/state-matrix-template.md`.
 - Existing OpenAPI Draft only if the review is checking alignment; do not require OpenAPI before product design.
-- `docs/.scratch/<feature>/verification/prototype-evidence.yaml` may be created as a pending schema v3 record, but档位构建与浏览器验证属于后续 `check.prototype-verified`。
+- `docs/.scratch/<feature>/verification/prototype-evidence.yaml` may be created as a pending Prototype Evidence schema v4 record from `docs/design/templates/prototype-evidence-template.yaml`, but档位构建与浏览器验证属于后续 `check.prototype-verified`。
 
 ## Review Gates
 

package/template/.codex/skills/resolving-merge-conflicts/SKILL.md

@@ -7,8 +7,8 @@ description: "Use when you need to resolve an in-progress git merge/rebase confl
 
 2. **Find the primary sources** for each conflict. Understand deeply why each change was made, and what the original intent was. Read the commit messages, check the PRs, check original issues/tickets.
 
-3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. Always resolve; never `--abort`.
+3. **Resolve each hunk.** Preserve both intents where possible. Where incompatible, pick the one matching the merge's stated goal and note the trade-off. Do **not** invent new behaviour. If the intents cannot be reconciled safely, report the conflicting decision. Abort only when the user has authorized it; do not discard work to hide a conflict.
 
 4. Discover the project's **automated checks** and run them — typically typecheck, then tests, then format. Fix anything the merge broke.
 
-5. **Finish the merge/rebase.** Stage everything and commit. If rebasing, continue the rebase process until all commits are rebased.
+5. **Return the resolved files and verification.** Preserve the initial index and unrelated dirty files. Stage only the explicitly authorized conflict paths, never the entire working tree. Commit, or continue a merge/rebase when that creates commits, only with current authorization covering that action; otherwise leave the resolution ready for review and report the next command.

package/template/.codex/skills/tdd/SKILL.md

@@ -35,4 +35,4 @@ When the shape of that interface is itself in question — how deep the module i
 
 - **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
 - **One slice at a time.** One seam, one test, one minimal implementation per cycle.
-- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.
+- **Refactoring follows evidence.** The implementer performs necessary in-scope refactoring with green behavior tests. The independent Reviewer reads and reports findings; it does not edit the implementation or review its own changes. The implementer fixes findings, then returns the changed candidate for fresh review.

package/template/.codex/skills/to-questionnaire/SKILL.md

@@ -8,9 +8,11 @@ Turn something the user can't answer alone into a **questionnaire** — a Markdo
 
 **Grill the send, not the subject.** Interview the user only about the _send_, which they can always answer: who it goes to, and what they need back. The questions in the document then target the **gap** between what the recipient knows and what the user needs.
 
-1. **Who is it going to?** Ask, in one exchange, the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
+Reuse the recipient, purpose and constraints already provided. Ask only for missing information that changes the questionnaire; when both are known, draft directly.
 
-2. **What do you need back?** Ask, in one exchange, the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
+1. **Who is it going to?** If missing, ask for the recipient's role, expertise, and relationship to the user. This fixes the questionnaire's tone and how much context it must carry. Done when you know who the recipient is and what they know that the user doesn't.
+
+2. **What do you need back?** If missing, ask for the specific decisions or facts the user can't resolve alone and needs from this person. Done when you have a concrete list of what the user must walk away able to do or decide.
 
 3. **Write the questionnaire.** Draft questions aimed at the gap from steps 1–2, following the Document structure below. Write it to `to-questionnaire-<slug>.md` in the current directory (slug from the topic) and report the path. Done when the file exists and every item the user named in step 2 is covered by a question.
 

package/template/.codex/skills/to-spec/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: to-spec
-description: Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
+description: 显式将已确认讨论综合为 Spec 草稿；经主控预检后按配置持久化并回交验收。
 disable-model-invocation: true
 ---
 
-This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user — just synthesize what you already know.
+This explicit compatibility entry synthesizes confirmed context into a Spec draft. Before formal writes, the active lifecycle orchestrator checks repository identity, Plan → Spec entry evidence, allowed paths and current decisions. Template-source maintenance creates no product Spec. Reuse confirmed inputs and seams; ask only for a material missing decision. Return the draft to the orchestrator for validation and acceptance without approving it.
 
 If the issue tracker or triage label vocabulary is missing, tell the user to run `/setup-matt-pocock-skills`; do not invoke another user-invoked skill yourself.
 
@@ -14,7 +14,7 @@ If the issue tracker or triage label vocabulary is missing, tell the user to run
 
 2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
 
-Check with the user that these seams match their expectations.
+Reuse already confirmed seams; ask only when a seam is new or materially changed.
 
 3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-human` triage label. Spec drafts need a human baseline approval before they are `approved`, and before implementation tickets may become `ready-for-agent`. Do not label the Spec itself `ready-for-agent`.
 

package/template/.codex/skills/to-tickets/SKILL.md

@@ -6,7 +6,7 @@ disable-model-invocation: true
 
 # To Tickets
 
-Break a plan, spec, or conversation into a set of **tickets** — tracer-bullet vertical slices, each declaring the tickets that **block** it.
+Break an explicitly requested, confirmed plan or Spec into tracer-bullet Ticket drafts. Before any formal write, return to the active lifecycle orchestrator for repository identity, current inputs, allowed paths and applicable gates. Template-source maintenance does not create product Tickets. The explicit entry may write its prepared artifacts only within that preflight contract and returns them to the orchestrator for validation and acceptance; it cannot approve a Slice Contract or decide readiness.
 
 If the issue tracker or triage label vocabulary is missing, tell the user to run `/setup-matt-pocock-skills`; do not invoke another user-invoked skill yourself.
 
@@ -35,7 +35,7 @@ Break the work into **tracer bullet** tickets.
 
 </vertical-slice-rules>
 
-Give each ticket its **blocking edges** — the other tickets that must complete before it can start. A ticket with no blockers can start immediately.
+Give each ticket its **blocking edges** — the other tickets that must complete before it can start. A ticket with no dependency edges still needs a current approved Slice Contract and all applicable implementation gates before it can start.
 
 **Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change — rename a column, retype a shared symbol — whose **blast radius** fans across the whole codebase, so a single edit breaks thousands of call sites at once and no vertical slice can land green. Don't force it into a tracer bullet; sequence it as **expand–contract**. First expand: add the new form beside the old so nothing breaks. Then migrate the call sites over in batches sized by blast radius (per package, per directory), each batch its own ticket blocked by the expand, keeping CI green batch to batch because the old form still exists. Finally contract: delete the old form once no caller remains, in a ticket blocked by every migrate batch. When even the batches can't stay green alone, keep the sequence but let them share an integration branch that all block a final integrate-and-verify ticket — green is promised only there.
 
@@ -53,14 +53,14 @@ Ask the user:
 - Are the blocking edges correct — does each ticket only depend on tickets that genuinely gate it?
 - Should any tickets be merged or split further?
 
-Iterate until the user approves the breakdown.
+Reuse an existing approval that covers this same breakdown. Ask only about unresolved scope, granularity or dependency decisions; return accepted drafts and evidence to the orchestrator.
 
 ### 5. Publish the tickets to the configured tracker
 
 Publish the approved tickets. **How** depends on the tracker `/setup-matt-pocock-skills` configured — the tickets are the same either way, only the shape of the blocking edges changes:
 
 - **Local files** → write one file per ticket under `docs/.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on. Use the per-ticket file template below — one ticket per file, never a single combined file.
-- **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
+- **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Keep drafts `ready-for-human`. Only the orchestrator may mark a narrow slice `ready-for-agent` after checking its current approved contract and applicable gates. Publishing to a remote tracker requires explicit authorization for that action.
 
 Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
 
@@ -72,9 +72,9 @@ Do NOT close or modify any parent issue.
 
 **What to build:** the end-to-end behaviour this ticket makes work, from the user's perspective — not a layer-by-layer implementation list.
 
-**Blocked by:** the numbers/titles of the tickets that gate this one, or "None — can start immediately".
+**Blocked by:** the numbers/titles of the tickets that gate this one, or "None — readiness still requires contract and gate verification".
 
-**Status:** ready-for-agent
+**Status:** ready-for-human
 
 - [ ] Acceptance criterion 1
 - [ ] Acceptance criterion 2
@@ -98,7 +98,7 @@ The end-to-end behaviour this ticket makes work, from the user's perspective —
 
 ## Blocked by
 
-- A reference to each blocking ticket, or "None — can start immediately".
+- A reference to each blocking ticket, or "None — readiness still requires contract and gate verification".
 
 </issue-template>
 

package/template/.codex/skills/using-git-worktrees/SKILL.md

@@ -83,7 +83,7 @@ Follow this priority order. Explicit user preference always beats observed files
 git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
 ```
 
-**If NOT ignored:** Add to .gitignore, commit the change, then proceed.
+**If NOT ignored:** Add the chosen directory to .gitignore within the authorized setup scope, verify it is ignored, then proceed. Leave that edit uncommitted unless Git commit authorization already covers it.
 
 **Why critical:** Prevents accidentally committing worktree contents to repository.
 
@@ -97,15 +97,17 @@ git worktree add "$path" -b "$BRANCH_NAME"
 cd "$path"
 ```
 
-**Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place.
+**Isolation failure:** If worktree creation is blocked, report the actual error and preserve the current checkout. Use another already authorized isolated location when available; ask only if proceeding would change the requested isolation boundary. Do not silently begin implementation in the original checkout.
 
 ## Step 2: Project Setup
 
 Auto-detect and run appropriate setup:
 
 ```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
+# Node.js: inspect packageManager, lockfile and project instructions first.
+# In a pnpm project, use the recorded version and frozen lockfile:
+# pnpm install --frozen-lockfile
+# Use npm/yarn only when the repository actually declares them.
 
 # Rust
 if [ -f Cargo.toml ]; then cargo build; fi
@@ -124,10 +126,10 @@ Run tests to ensure workspace starts clean:
 
 ```bash
 # Use project-appropriate command
-npm test / cargo test / pytest / go test ./...
+pnpm test / cargo test / pytest / go test ./... # select the declared project runner
 ```
 
-**If tests fail:** Report failures, ask whether to proceed or investigate.
+**If tests fail:** Record the existing failure and investigate within the authorized scope. Ask only if a new decision or access is needed; do not label the baseline clean.
 
 **If tests pass:** Report ready.
 
@@ -151,9 +153,9 @@ Ready to implement <feature-name>
 | `worktrees/` exists | Use it (verify ignored) |
 | Both exist | Use `.worktrees/` |
 | Neither exists | Check instruction file, then default `.worktrees/` |
-| Directory not ignored | Add to .gitignore + commit |
-| Permission error on create | Sandbox fallback, work in place |
-| Tests fail during baseline | Report failures + ask |
+| Directory not ignored | Add to .gitignore; commit only when authorized |
+| Permission error on create | Report failure; preserve the requested isolation boundary |
+| Tests fail during baseline | Record failures; continue authorized diagnosis |
 | No package.json/Cargo.toml | Skip dependency install |
 
 ## Common Mistakes
@@ -181,7 +183,7 @@ Ready to implement <feature-name>
 ### Proceeding with failing tests
 
 - **Problem:** Can't distinguish new bugs from pre-existing issues
-- **Fix:** Report failures, get explicit permission to proceed
+- **Fix:** Distinguish baseline failures from new defects; ask only for a missing decision
 
 ## Red Flags
 
@@ -191,7 +193,7 @@ Ready to implement <feature-name>
 - Skip Step 1a by jumping straight to Step 1b's git commands
 - Create worktree without verifying it's ignored (project-local)
 - Skip baseline test verification
-- Proceed with failing tests without asking
+- Claim a clean baseline when checks failed
 
 **Always:**
 - Run Step 0 detection first

package/template/.codex/skills/wait-what/SKILL.md

@@ -4,4 +4,4 @@ description: "Stop. That last message did not land: re-pitch it."
 disable-model-invocation: true
 ---
 
-Wait, I don't understand where you've got to here. Re-pitch that: give me a little bit of context, talk in ASD-STE100 Simplified Technical English, and use the ubiquitous language from the repository-root `CONTEXT.md`. When the repository has multiple bounded contexts, resolve the term by its `<ContextId>/<EnglishIdentifier>` reference and the `适用限界上下文` column in that single glossary.
+用用户当前使用的语言，补足刚才说明所缺的背景并重新解释。保持简明、具体，复用仓库根目录唯一 `CONTEXT.md` 的词汇；跨业务责任区按 `<ContextId>/<EnglishIdentifier>` 定位。只改表达，不启动完整生命周期或重建上下文。

package/template/.codex/skills/wayfinder/SKILL.md

@@ -20,6 +20,8 @@ Every map and ticket is an issue, so it has a **name** — its title. In everyth
 
 The map is a single issue on this repo's issue tracker, labelled `wayfinder:map` — the canonical artifact. Its tickets are child issues of the map.
 
+Return the decision map to the active orchestrator for formal asset/state acceptance. Explicit invocation does not authorize remote publication or Git commits; preserve those action boundaries.
+
 The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
 
 **Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
@@ -54,7 +56,7 @@ The whole map at low resolution, loaded once per session. Open tickets are **not
 
 ### Tickets
 
-Each ticket is a **child issue** of the map; the tracker's issue id is its identity. Its body is the question, sized to one 100K token agent session:
+Each ticket is a **child issue** of the map; the tracker's issue id is its identity. Its body is the question, bounded by a coherent decision and the current runtime/context capacity:
 
 ```markdown
 ## Question
@@ -102,7 +104,7 @@ Ruling something out of scope is a scoping act, not a step on the route. When a
 
 ## Invocation
 
-Two modes. Either way, **never resolve more than one ticket per session** — with the exception of research tickets.
+Two modes. Keep each decision traceable and stop at a real dependency, decision or context boundary; related small tickets may share a session when their evidence remains clear.
 
 ### Chart the map