[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D308SWFEEC4PEF3PB5WWS6":3,"skill-same:01M6D308SWFEEC4PEF3PB5WWS6":119},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6D308SWFEEC4PEF3PB5WWS6","plan-phase",null,"Decompose a single roadmap phase into implementation steps, tests, and file-level detail","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fagent-work-admin\u002Fcodex\u002Fplan-phase\u002Farchive\u002Fv0.4\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"plan","plan phase","planning","file","v0","roadmap","decompose","implementation","detail","tests","2026-11-10 10:12:30",false,"---\nname: plan-phase\ndescription: Decompose a single roadmap phase into implementation steps, tests, and file-level detail\ntype: planning\nversion: v0.4\ninvocation: sub-skill\nparent: exec\n---\n\n# Plan Phase\n\nInvoke as `$plan-phase`.\n\nFill in the implementation detail for **one** phase of `tasks\u002Froadmap.md`. Invoked just-in-time — either manually, by `$roadmap` (to seed Phase 1), or by `$ship` and `$exec` when a new phase begins. Implementation detail is generated when a phase starts, not upfront, because context from earlier phases informs later decisions.\n\n## Prerequisites\n\n- `tasks\u002Froadmap.md` must exist. If it does not, stop and tell the user to run `$roadmap` (or `$research-roadmap` (research-admin pack) → `$roadmap` if no spec exists).\n- The target phase must already have a Goal, Scope, and Acceptance Criteria in the roadmap.\n\n## Input\n\nRead arguments:\n\n- If arguments contain a phase number (e.g., `2`), plan that phase.\n- If arguments are empty, plan the **first phase that has acceptance criteria but no implementation steps** (no `### Tests First` or `### Implementation` section yet).\n- If arguments contain `--no-tdd`, use `tests-after` for this phase regardless of other signals.\n\nRead:\n\n- `tasks\u002Froadmap.md` for the target phase's Goal, Scope, and Acceptance Criteria.\n- `specs\u002F` (or `spec.md`) for the detailed requirements referenced by the phase's scope.\n- The codebase as needed to understand existing code, patterns, and which files to modify.\n- The roadmap phase's `Parallelization` and `Coordination Notes` fields, if present.\n\n## Planning Process\n\n### Determine Test Strategy\n\nCheck in order:\n\n1. If arguments contain `--no-tdd`, use `tests-after`.\n2. If `AGENTS.md` or `CLAUDE.md` has a `## Test Strategy` section, follow the project default.\n3. Otherwise, classify the phase:\n   - **`tdd`**: stable interfaces, APIs, data models, business logic with known contracts, payment\u002Fauth flows\n   - **`tests-after`**: UI components, prototyping, exploratory features, design-in-flux work\n   - **`none`**: pure config, docs, scaffolding, infra setup, CI\u002FCD changes\n\nAnnotate the phase with `> Test strategy: tdd|tests-after|none`.\n\n### Determine Execution Profile\n\nExpand the roadmap's strategic parallelization mode into a concrete execution profile for this phase. If the roadmap has no `Parallelization` field, default to `serial`.\n\nUse these modes:\n\n- **`serial`**: one main agent does the work; use when ownership is coupled or unclear.\n- **`research-only`**: read-only subagents may gather context before implementation; main agent implements.\n- **`review-only`**: main agent implements; subagents review before final validation.\n- **`implementation-safe`**: write subagents may work only on disjoint owned paths; main agent integrates.\n- **`agent-team`**: work is too broad or cross-cutting for one shared local tree; write lanes must use separate GitHub branches and a consolidation\u002FPR review gate before final integration.\n\nDowngrade `implementation-safe` to `research-only` or `serial` if path ownership overlaps, shared chokepoints dominate, or the likely integration surface is unclear.\n\nAdd this section before implementation steps:\n\n```markdown\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [findings, patch summary, changed paths, tests, branch + commit SHA + PR URL, or review report]\n```\n\nFor `serial`, use `**Subagent lanes:** none`. For `research-only` and `review-only`, lanes must not have write mode. For `implementation-safe`, every write lane must have non-overlapping `Owns` paths and explicit `Must not edit` boundaries.\nFor `agent-team`, every write lane must have a deterministic `Branch:` value that is not `main` or `master`, and the phase steps must include a consolidation\u002FPR review step after all write lanes complete and before final validation or shipping. If GitHub branch push or PR review is unavailable, downgrade to `implementation-safe`, `research-only`, or `serial`, or stop and document the blocker.\n\n### Break the Phase into Steps\n\nDefine ordered steps beneath the existing Goal\u002FScope\u002FAcceptance Criteria. The structure depends on the test strategy:\n\nFor new user-facing product, SaaS, marketplace, dashboard, internal tool, or product-experience phases, apply a prototype-first planning gate before writing steps:\n\n- If there is no accepted clickable journey yet and the current roadmap phase combines prototype exploration with production implementation, stop and re-scope the current work into a distinct prototype\u002Fexperiment phase before writing implementation steps. Prefer `Phase 0: Prototype Experiments` when the project convention allows it; otherwise make the next phase explicitly prototype-only and push production implementation later.\n- If the roadmap\u002Fspec does not explicitly approve durable database\u002Fstorage, auth, payments, analytics, deployment, admin tooling, multi-tenancy, or production observability for the current phase, keep those items in a later \"eventual production infrastructure\" backlog and plan the current phase as a clickable local\u002Fstatic prototype with fake, fixture, or in-memory data.\n- For new feature prototypes or uncertain product surfaces, plan multiple small experiments on separate clickable routes such as `\u002Fexperiments\u002F\u003Cvariant>` or project-native equivalents. Each route should test a distinct workflow, layout, density, copy, navigation, or interaction hypothesis without sharing hidden production infrastructure.\n- Include a calibration step before any infrastructure promotion: the user must be able to try one journey and record what felt wrong, slow, generic, too dense, too sparse, off-brand, or workflow-breaking.\n- Promote infrastructure into the current phase only when the phase is explicitly production hardening, the user has approved that infrastructure, or the core prototype cannot test the primary interaction without it. State the evidence in the phase notes.\n\n**For `tdd` phases:**\n```\n## Phase N: [Title]\n> Test strategy: tdd\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Tests First\n- Step N.1: Write failing tests for this phase's acceptance criteria\n  - List specific test cases to write\n  - Tests should cover happy path, edge cases, and error cases\n  - Tests MUST fail at this point (red)\n\n### Implementation\n- Step N.2: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- Step N.3: [Next implementation task]\n  - Files: modify `path\u002Fto\u002Ffile.ts`\n- ...\n\n### Green\n- Step N.X: Run tests, verify all pass, and perform only concrete cleanup found by validation\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap — do not rewrite)\n- [ ] [criterion 1]\n- [ ] All phase tests pass\n- [ ] No regressions in previous phase tests\n```\n\n**For `tests-after` phases:**\n```\n## Phase N: [Title]\n> Test strategy: tests-after\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Implementation\n- Step N.1: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- ...\n\n### Green\n- Step N.X: Write regression tests covering acceptance criteria\n- Step N.Y: Run all tests, verify they pass, and perform only concrete cleanup found by validation\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap)\n- [ ] [criterion 1]\n- [ ] All phase tests pass\n- [ ] No regressions in previous phase tests\n```\n\n**For `none` phases:**\n```\n## Phase N: [Title]\n> Test strategy: none\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Implementation\n- Step N.1: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- ...\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap)\n- [ ] [criterion 1]\n```\n\n**On Completion** (fill in when phase is done — all strategies):\n- Deviations from plan: [none, or describe]\n- Tech debt \u002F follow-ups: [none, or list]\n- Ready for next phase: yes\u002Fno\n\n### Test Requirements\n\n- **`tdd` phases**: start with writing tests BEFORE implementation. Tests tied to acceptance criteria. Include test file paths.\n- **`tests-after` phases**: implementation comes first. The Green step writes regression tests covering the acceptance criteria.\n- **`none` phases**: no test steps. Milestone omits \"All phase tests pass\".\n- All `tdd` and `tests-after` milestones must include \"All phase tests pass\" and \"No regressions in previous phase tests\".\n- If the project has no test framework yet, the first phase's first step should set it up.\n\n### File-Level Granularity\n\n- Every implementation step lists the specific files to create, modify, or delete.\n- This gives the executing agent clear scope and prevents steps from becoming unbounded.\n- Write-capable subagent lanes must have disjoint owned paths. If they do not, keep implementation serial and use research or review lanes only.\n- Agent-team phases must include a final automated consolidation\u002FPR review step that inspects each lane's branch\u002FPR, verifies changed paths against `Owns` and `Must not edit`, records blocker\u002Fadvisory findings, integrates only approved lane work, and then runs the phase validation gate.\n\n### Task Classification\n\nClassify each step or follow-up as exactly one of:\n\n- **automated** — the agent executes it as implementation or verification work in `tasks\u002Ftodo.md`.\n- **manual** — a human-only external action tied to an automated step in `tasks\u002Fmanual-todo.md`.\n- **record** — a one-time, non-blocking record or measurement that should happen only after a condition becomes true in `tasks\u002Frecord-todo.md`.\n- **recurring** — cadence-based operational, research, or maintenance work in `tasks\u002Frecurring-todo.md`.\n\nUse the narrowest classification that can execute without losing context:\n\n- If the agent can do it by editing repo files, running local commands, using an approved CLI\u002FMCP\u002FAPI integration, or writing a script with already-available credentials, classify it as **automated**.\n- If the work is blocked only because a secret, account, payment method, approval, hardware device, or human judgment\u002Fevidence is missing, classify only that missing prerequisite as **manual**.\n- If one item mixes human and automatable work, split it: the human-gated prerequisite goes to `tasks\u002Fmanual-todo.md`; the repo\u002Fcode\u002Fconfig\u002Ftest follow-up stays in `tasks\u002Ftodo.md`.\n\nManual tasks include only human-gated work such as:\n\n- DNS configuration, domain setup, SSL certificates\n- Browser\u002Fdevice testing or visual QA that requires a real account, real device, production environment, or subjective human sign-off\n- OAuth\u002FAPI credential setup with third-party services when no authenticated CLI\u002FAPI path is available\n- Deployment approvals, paid environment provisioning, quota\u002Fbilling approval, or account ownership decisions\n- Signing up for services, billing setup\n- Any step requiring a GUI, physical device, or human judgment that cannot be scripted\n\nDo not classify these as manual:\n\n- Editing source, docs, `.env.example`, config templates, or task docs\n- Installing or wiring SDKs\u002Fpackages, creating adapters, writing scripts, or updating metadata contracts\n- Running builds, unit tests, local smoke tests, Lighthouse, Playwright, linters, or repo audits\n- Setting local environment variables when the required non-secret values are known or the user has already provided the secret values\n- Running provider CLIs or API calls when authentication is already present or can be requested through the normal approval flow\n\nManual tasks MUST NOT appear in `tasks\u002Ftodo.md`. They go in `tasks\u002Fmanual-todo.md`.\nAgent-executable tasks MUST NOT appear in `tasks\u002Fmanual-todo.md`. If found there, promote them to `tasks\u002Ftodo.md` or route a reconciliation fix.\n\nRecord tasks MUST NOT appear in `tasks\u002Ftodo.md` unless they are launch gates or current execution work. They go in `tasks\u002Frecord-todo.md` with source, condition, non-blocking reason, required data\u002Faccess, measurement\u002Fquery, target note, revisit cadence\u002Fdate, completion evidence, and promotion rule.\n\nRecurring tasks MUST NOT appear in `tasks\u002Ftodo.md` unless the current run is explicitly in scope for this phase. They go in `tasks\u002Frecurring-todo.md` with task, cadence, owner\u002Fagent, scope, trigger, last run, next due, command\u002Fskill, evidence\u002Foutput path, and escalation conditions.\n\n## Output\n\n1. **Update `tasks\u002Froadmap.md`** — insert the implementation structure (Tests First \u002F Implementation \u002F Green \u002F Milestone, per strategy) into the target phase, beneath the existing Goal\u002FScope\u002FAcceptance Criteria. Do NOT modify other phases. Do NOT rewrite the Goal, Scope, or Acceptance Criteria.\n\n2. **Write `tasks\u002Ftodo.md`** — extract the target phase as a standalone working document, including the `### Execution Profile`. Include enough context (project name, current phase number, total phases) so a fresh session can orient itself without reading `tasks\u002Froadmap.md`. If `tasks\u002Ftodo.md` already has in-progress work for a different phase, ask the user before overwriting.\n\n3. **Write `tasks\u002Fmanual-todo.md`** (only if this phase has manual tasks):\n   ```markdown\n   # Manual Tasks — [Project Name]\n\n   > Phase: N — [Phase Title]\n   > These tasks require human-only external action. Do not put repo edits, local commands, CLI\u002FAPI work, tests, audits, or implementation follow-ups here.\n   > Check them off as you complete them.\n\n   ## Pre-Phase \u002F Setup\n   - [ ] [task] _(blocks: Step N.X)_\n\n   ## During Phase\n   - [ ] [task] _(after: Step N.X)_\n\n   ## Post-Phase \u002F Verification\n   - [ ] [task]\n   ```\n   - `_(blocks: Step N.X)_` = must be done before that automated step\n   - `_(after: Step N.X)_` = should be done after that automated step\n   - No annotation = do anytime during the phase\n   - Only create this file when manual tasks exist — no empty files.\n\n4. **Write `tasks\u002Frecord-todo.md`** (only if this phase identifies non-blocking condition-gated records):\n   ```markdown\n   # Record Tasks — [Project Name]\n\n   > These tasks are non-blocking records or measurements. Do not execute them through `$exec` unless promoted to `tasks\u002Ftodo.md`.\n\n   - [ ] [task]\n     - Source: [phase\u002Fspec\u002Fcriterion]\n     - Condition: [when this becomes eligible]\n     - Non-blocking reason: [why this is not a launch gate or current step]\n     - Required data\u002Faccess: [data, portal, aggregate, credential, or user-provided output]\n     - Measurement\u002Fquery: [how to collect evidence]\n     - Target\u002Facceptance note: [threshold or expected record]\n     - Revisit: [date or cadence]\n     - Completion evidence: [where to record the result]\n     - Promotion rule: [when to move this into `tasks\u002Ftodo.md`]\n   ```\n\n5. **Write `tasks\u002Frecurring-todo.md`** (only if this phase identifies recurring obligations):\n   ```markdown\n   # Recurring Tasks — [Project Name]\n\n   > These tasks recur on a cadence. Do not execute them through `$exec` unless a due run is promoted to `tasks\u002Ftodo.md`.\n\n   - [ ] [task]\n     - Cadence: [daily\u002Fweekly\u002Fmonthly\u002Fquarterly\u002Fon release\u002Fetc.]\n     - Owner\u002Fagent: [human, `$skill`, or agent role]\n     - Scope: [project\u002Fapp\u002Farea]\n     - Trigger: [time, release, data threshold, user request]\n     - Last run: [date or never]\n     - Next due: [date or rule]\n     - Command\u002Fskill: [command or skill to run]\n     - Evidence\u002Foutput path: [where results are recorded]\n     - Escalation conditions: [when it becomes executable or blocking work]\n   ```\n\n## Next-Step Routing\n\nBefore handing back, identify the next concrete work item from project state, then recommend the executor and invocation.\n\nOutput exactly two lines beyond the normal report:\n\n- **Next work:** \u003Cspecific first step, manual blocker, or verification gap for the planned phase>\n- **Recommended next command:** \u003Cone command or route>\n\nRules:\n\n- Make the next work item primary. Derive it from the first executable step in `tasks\u002Ftodo.md`, any matching blocker in `tasks\u002Fmanual-todo.md`, or the phase's verification\u002Fsetup gap. Do not use agent mode itself as the next work item.\n- Use `.\u002Fscripts\u002Fagent-mode.sh` only to choose command text. If it is missing, unset, or non-zero, infer routing from the current invocation and task type instead of asking the user to select a mode by default.\n- Inference defaults:\n  - Codex skill invocation (`$plan-phase`, `$exec`) → recommend the matching `$...` command.\n  - Hybrid execution handoff → check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell, first; if `agent-bridge` is enabled, recommend `$delegate $exec`.\n  - Claude slash invocation (`\u002Fplan-phase`, `\u002Fexec`, `\u002Fdelegate`) or orchestration-heavy work → check `.agents\u002Fproject.json.enabled_packs` for `exec-loop` — if `exec-loop` is not enabled, recommend `npx skillpacks install exec-loop` from the project shell, first; if `exec-loop` is enabled, recommend the matching `\u002F...` route.\n  - External human-only manual work (browser\u002Fauth\u002FDNS\u002Fservice dashboard work with no reliable authenticated CLI\u002FAPI path, paid account setup, real-device checks, or production smoke-test work needing human sign-off) → check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell, first; if `guided-walkthrough` is enabled, recommend `$guide` — or a Claude-guided manual step rather than `$exec`.\n  - Agent-executable work misfiled in `tasks\u002Fmanual-todo.md`, task-doc bookkeeping, stale `tasks\u002Fmanual-todo.md` cleanup, or reconciliation against repo\u002Fhistory reality → check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell, first; if `docs-health` is enabled, recommend `$reconcile-dev-docs fix tasks` — promotion to `tasks\u002Ftodo.md`, or a direct dev-doc audit, not `$guide`.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, include `npx skillpacks install \u003Cpack-name>` from the project shell, as the install prerequisite before the recommendation.\n- Only present multiple commands when the ambiguity materially changes execution safety or there are equally valid next work items. Otherwise choose the best route and mention degraded mode lookup inline.\n\n## Constraints\n\n- **One phase per invocation.** Do not decompose multiple phases ahead of time.\n- **Require `tasks\u002Froadmap.md`.** If it's missing, stop and direct the user to `$roadmap`.\n- **Preserve the roadmap's Goal, Scope, and Acceptance Criteria exactly.** Those are `$roadmap`'s decisions. Only add implementation detail beneath them.\n- **Phase headers must use `## Phase N: [Title]` format** and steps must use `- Step N.X:` format — this is required by `$exec` and `$ship`.\n- Every milestone must have specific, checkable acceptance criteria — not vague statements like \"works correctly\" but concrete conditions like \"POST \u002Fapi\u002Fitems returns 201 with valid payload and persists to database.\"\n- Every `tdd` phase must start with writing failing tests. `tests-after` phases write tests in the Green step.\n- Do not generate standalone cleanup\u002Frefactor steps that are conditional on validation finding drift. Fold those checks into the Green validation step and only create a separate follow-up when there is known concrete remediation work.\n- Do not include implementation code — describe what to build and what to test.\n- Note what already exists in the codebase vs. what needs to be created.\n- The `### Execution Profile` must be decision-complete enough for `$exec` to decide whether to use serial execution, read-only subagents, review subagents, or disjoint write subagents after presenting the plan and proceeding under implicit approval.\n- Subagents must not own task docs, roadmap\u002Fhistory updates, shipping, or deploy steps. Those stay with the main agent.\n- Agent-team write lanes must not target `main` or `master`; each lane gets its own GitHub branch and must return branch, commit SHA, validation evidence, and PR URL before consolidation.\n- Manual tasks MUST NOT appear in `tasks\u002Ftodo.md` — they go in `tasks\u002Fmanual-todo.md` only.\n- Agent-executable work MUST NOT appear in `tasks\u002Fmanual-todo.md` — it goes in `tasks\u002Ftodo.md` or an implementation skill.\n- Non-blocking record tasks MUST NOT appear in `tasks\u002Ftodo.md` — they go in `tasks\u002Frecord-todo.md` unless explicitly promoted.\n- Recurring obligations MUST NOT appear in `tasks\u002Ftodo.md` by default — they go in `tasks\u002Frecurring-todo.md` unless a due run is current execution work.\n- Do NOT put plans in `AGENTS.md`, `CLAUDE.md`, or `docs\u002Fplan.md`.\n\n## Alignment Page\n\nBy default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks\u002F*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment\u002Fplan-phase-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification\u002Freview need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Plan Phase\n\nInvoke as `$plan-phase`.\n\nFill in the implementation detail for **one** phase of `tasks\u002Froadmap.md`. Invoked just-in-time — either manually, by `$roadmap` (to seed Phase 1), or by `$ship` and `$exec` when a new phase begins. Implementation detail is generated when a phase starts, not upfront, because context from earlier phases informs later decisions.\n\n## Prerequisites\n\n- `tasks\u002Froadmap.md` must exist. If it does not, stop and tell the user to run `$roadmap` (or `$research-roadmap` (research-admin pack) → `$roadmap` if no spec exists).\n- The target phase must already have a Goal, Scope, and Acceptance Criteria in the roadmap.\n\n## Input\n\nRead arguments:\n\n- If arguments contain a phase number (e.g., `2`), plan that phase.\n- If arguments are empty, plan the **first phase that has acceptance criteria but no implementation steps** (no `### Tests First` or `### Implementation` section yet).\n- If arguments contain `--no-tdd`, use `tests-after` for this phase regardless of other signals.\n\nRead:\n\n- `tasks\u002Froadmap.md` for the target phase's Goal, Scope, and Acceptance Criteria.\n- `specs\u002F` (or `spec.md`) for the detailed requirements referenced by the phase's scope.\n- The codebase as needed to understand existing code, patterns, and which files to modify.\n- The roadmap phase's `Parallelization` and `Coordination Notes` fields, if present.\n\n## Planning Process\n\n### Determine Test Strategy\n\nCheck in order:\n\n1. If arguments contain `--no-tdd`, use `tests-after`.\n2. If `AGENTS.md` or `CLAUDE.md` has a `## Test Strategy` section, follow the project default.\n3. Otherwise, classify the phase:\n   - **`tdd`**: stable interfaces, APIs, data models, business logic with known contracts, payment\u002Fauth flows\n   - **`tests-after`**: UI components, prototyping, exploratory features, design-in-flux work\n   - **`none`**: pure config, docs, scaffolding, infra setup, CI\u002FCD changes\n\nAnnotate the phase with `> Test strategy: tdd|tests-after|none`.\n\n### Determine Execution Profile\n\nExpand the roadmap's strategic parallelization mode into a concrete execution profile for this phase. If the roadmap has no `Parallelization` field, default to `serial`.\n\nUse these modes:\n\n- **`serial`**: one main agent does the work; use when ownership is coupled or unclear.\n- **`research-only`**: read-only subagents may gather context before implementation; main agent implements.\n- **`review-only`**: main agent implements; subagents review before final validation.\n- **`implementation-safe`**: write subagents may work only on disjoint owned paths; main agent integrates.\n- **`agent-team`**: work is too broad or cross-cutting for one shared local tree; write lanes must use separate GitHub branches and a consolidation\u002FPR review gate before final integration.\n\nDowngrade `implementation-safe` to `research-only` or `serial` if path ownership overlaps, shared chokepoints dominate, or the likely integration surface is unclear.\n\nAdd this section before implementation steps:\n\n```markdown\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [findings, patch summary, changed paths, tests, branch + commit SHA + PR URL, or review report]\n```\n\nFor `serial`, use `**Subagent lanes:** none`. For `research-only` and `review-only`, lanes must not have write mode. For `implementation-safe`, every write lane must have non-overlapping `Owns` paths and explicit `Must not edit` boundaries.\nFor `agent-team`, every write lane must have a deterministic `Branch:` value that is not `main` or `master`, and the phase steps must include a consolidation\u002FPR review step after all write lanes complete and before final validation or shipping. If GitHub branch push or PR review is unavailable, downgrade to `implementation-safe`, `research-only`, or `serial`, or stop and document the blocker.\n\n### Break the Phase into Steps\n\nDefine ordered steps beneath the existing Goal\u002FScope\u002FAcceptance Criteria. The structure depends on the test strategy:\n\nFor new user-facing product, SaaS, marketplace, dashboard, internal tool, or product-experience phases, apply a prototype-first planning gate before writing steps:\n\n- If there is no accepted clickable journey yet and the current roadmap phase combines prototype exploration with production implementation, stop and re-scope the current work into a distinct prototype\u002Fexperiment phase before writing implementation steps. Prefer `Phase 0: Prototype Experiments` when the project convention allows it; otherwise make the next phase explicitly prototype-only and push production implementation later.\n- If the roadmap\u002Fspec does not explicitly approve durable database\u002Fstorage, auth, payments, analytics, deployment, admin tooling, multi-tenancy, or production observability for the current phase, keep those items in a later \"eventual production infrastructure\" backlog and plan the current phase as a clickable local\u002Fstatic prototype with fake, fixture, or in-memory data.\n- For new feature prototypes or uncertain product surfaces, plan multiple small experiments on separate clickable routes such as `\u002Fexperiments\u002F\u003Cvariant>` or project-native equivalents. Each route should test a distinct workflow, layout, density, copy, navigation, or interaction hypothesis without sharing hidden production infrastructure.\n- Include a calibration step before any infrastructure promotion: the user must be able to try one journey and record what felt wrong, slow, generic, too dense, too sparse, off-brand, or workflow-breaking.\n- Promote infrastructure into the current phase only when the phase is explicitly production hardening, the user has approved that infrastructure, or the core prototype cannot test the primary interaction without it. State the evidence in the phase notes.\n\n**For `tdd` phases:**\n```\n## Phase N: [Title]\n> Test strategy: tdd\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Tests First\n- Step N.1: Write failing tests for this phase's acceptance criteria\n  - List specific test cases to write\n  - Tests should cover happy path, edge cases, and error cases\n  - Tests MUST fail at this point (red)\n\n### Implementation\n- Step N.2: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- Step N.3: [Next implementation task]\n  - Files: modify `path\u002Fto\u002Ffile.ts`\n- ...\n\n### Green\n- Step N.X: Run tests, verify all pass, and perform only concrete cleanup found by validation\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap — do not rewrite)\n- [ ] [criterion 1]\n- [ ] All phase tests pass\n- [ ] No regressions in previous phase tests\n```\n\n**For `tests-after` phases:**\n```\n## Phase N: [Title]\n> Test strategy: tests-after\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Implementation\n- Step N.1: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- ...\n\n### Green\n- Step N.X: Write regression tests covering acceptance criteria\n- Step N.Y: Run all tests, verify they pass, and perform only concrete cleanup found by validation\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap)\n- [ ] [criterion 1]\n- [ ] All phase tests pass\n- [ ] No regressions in previous phase tests\n```\n\n**For `none` phases:**\n```\n## Phase N: [Title]\n> Test strategy: none\n\n### Execution Profile\n**Parallel mode:** serial | research-only | review-only | implementation-safe | agent-team\n**Integration owner:** main agent\n**Conflict risk:** low | medium | high\n**Review gates:** correctness, tests, security, performance, docs\u002FAPI conformance, UX, or none\n\n**Subagent lanes:**\n- Lane: [lane-name or none]\n  - Agent: explorer | worker | default\n  - Role: explorer | implementer | reviewer | docs-researcher | test-reviewer\n  - Mode: read-only | write | review\n  - Scope: [bounded task]\n  - Owns: `path\u002For\u002Fglob` (write lanes only)\n  - Must not edit: `path\u002For\u002Fglob` (write lanes only)\n  - Branch: `agent-team\u002Fphase-N-lane-name` (agent-team write lanes only)\n  - Depends on: [lane, step, or none]\n  - Deliverable: [expected output, including branch + commit SHA + PR URL for agent-team write lanes]\n\n### Implementation\n- Step N.1: [First implementation task]\n  - Files: create `path\u002Fto\u002Fnew.ts`, modify `path\u002Fto\u002Fexisting.ts`\n- ...\n\n### Milestone: [Phase N Milestone Name]\n**Acceptance Criteria:** (preserve from roadmap)\n- [ ] [criterion 1]\n```\n\n**On Completion** (fill in when phase is done — all strategies):\n- Deviations from plan: [none, or describe]\n- Tech debt \u002F follow-ups: [none, or list]\n- Ready for next phase: yes\u002Fno\n\n### Test Requirements\n\n- **`tdd` phases**: start with writing tests BEFORE implementation. Tests tied to acceptance criteria. Include test file paths.\n- **`tests-after` phases**: implementation comes first. The Green step writes regression tests covering the acceptance criteria.\n- **`none` phases**: no test steps. Milestone omits \"All phase tests pass\".\n- All `tdd` and `tests-after` milestones must include \"All phase tests pass\" and \"No regressions in previous phase tests\".\n- If the project has no test framework yet, the first phase's first step should set it up.\n\n### File-Level Granularity\n\n- Every implementation step lists the specific files to create, modify, or delete.\n- This gives the executing agent clear scope and prevents steps from becoming unbounded.\n- Write-capable subagent lanes must have disjoint owned paths. If they do not, keep implementation serial and use research or review lanes only.\n- Agent-team phases must include a final automated consolidation\u002FPR review step that inspects each lane's branch\u002FPR, verifies changed paths against `Owns` and `Must not edit`, records blocker\u002Fadvisory findings, integrates only approved lane work, and then runs the phase validation gate.\n\n### Task Classification\n\nClassify each step or follow-up as exactly one of:\n\n- **automated** — the agent executes it as implementation or verification work in `tasks\u002Ftodo.md`.\n- **manual** — a human-only external action tied to an automated step in `tasks\u002Fmanual-todo.md`.\n- **record** — a one-time, non-blocking record or measurement that should happen only after a condition becomes true in `tasks\u002Frecord-todo.md`.\n- **recurring** — cadence-based operational, research, or maintenance work in `tasks\u002Frecurring-todo.md`.\n\nUse the narrowest classification that can execute without losing context:\n\n- If the agent can do it by editing repo files, running local commands, using an approved CLI\u002FMCP\u002FAPI integration, or writing a script with already-available credentials, classify it as **automated**.\n- If the work is blocked only because a secret, account, payment method, approval, hardware device, or human judgment\u002Fevidence is missing, classify only that missing prerequisite as **manual**.\n- If one item mixes human and automatable work, split it: the human-gated prerequisite goes to `tasks\u002Fmanual-todo.md`; the repo\u002Fcode\u002Fconfig\u002Ftest follow-up stays in `tasks\u002Ftodo.md`.\n\nManual tasks include only human-gated work such as:\n\n- DNS configuration, domain setup, SSL certificates\n- Browser\u002Fdevice testing or visual QA that requires a real account, real device, production environment, or subjective human sign-off\n- OAuth\u002FAPI credential setup with third-party services when no authenticated CLI\u002FAPI path is available\n- Deployment approvals, paid environment provisioning, quota\u002Fbilling approval, or account ownership decisions\n- Signing up for services, billing setup\n- Any step requiring a GUI, physical device, or human judgment that cannot be scripted\n\nDo not classify these as manual:\n\n- Editing source, docs, `.env.example`, config templates, or task docs\n- Installing or wiring SDKs\u002Fpackages, creating adapters, writing scripts, or updating metadata contracts\n- Running builds, unit tests, local smoke tests, Lighthouse, Playwright, linters, or repo audits\n- Setting local environment variables when the required non-secret values are known or the user has already provided the secret values\n- Running provider CLIs or API calls when authentication is already present or can be requested through the normal approval flow\n\nManual tasks MUST NOT appear in `tasks\u002Ftodo.md`. They go in `tasks\u002Fmanual-todo.md`.\nAgent-executable tasks MUST NOT appear in `tasks\u002Fmanual-todo.md`. If found there, promote them to `tasks\u002Ftodo.md` or route a reconciliation fix.\n\nRecord tasks MUST NOT appear in `tasks\u002Ftodo.md` unless they are launch gates or current execution work. They go in `tasks\u002Frecord-todo.md` with source, condition, non-blocking reason, required data\u002Faccess, measurement\u002Fquery, target note, revisit cadence\u002Fdate, completion evidence, and promotion rule.\n\nRecurring tasks MUST NOT appear in `tasks\u002Ftodo.md` unless the current run is explicitly in scope for this phase. They go in `tasks\u002Frecurring-todo.md` with task, cadence, owner\u002Fagent, scope, trigger, last run, next due, command\u002Fskill, evidence\u002Foutput path, and escalation conditions.\n\n## Output\n\n1. **Update `tasks\u002Froadmap.md`** — insert the implementation structure (Tests First \u002F Implementation \u002F Green \u002F Milestone, per strategy) into the target phase, beneath the existing Goal\u002FScope\u002FAcceptance Criteria. Do NOT modify other phases. Do NOT rewrite the Goal, Scope, or Acceptance Criteria.\n\n2. **Write `tasks\u002Ftodo.md`** — extract the target phase as a standalone working document, including the `### Execution Profile`. Include enough context (project name, current phase number, total phases) so a fresh session can orient itself without reading `tasks\u002Froadmap.md`. If `tasks\u002Ftodo.md` already has in-progress work for a different phase, ask the user before overwriting.\n\n3. **Write `tasks\u002Fmanual-todo.md`** (only if this phase has manual tasks):\n   ```markdown\n   # Manual Tasks — [Project Name]\n\n   > Phase: N — [Phase Title]\n   > These tasks require human-only external action. Do not put repo edits, local commands, CLI\u002FAPI work, tests, audits, or implementation follow-ups here.\n   > Check them off as you complete them.\n\n   ## Pre-Phase \u002F Setup\n   - [ ] [task] _(blocks: Step N.X)_\n\n   ## During Phase\n   - [ ] [task] _(after: Step N.X)_\n\n   ## Post-Phase \u002F Verification\n   - [ ] [task]\n   ```\n   - `_(blocks: Step N.X)_` = must be done before that automated step\n   - `_(after: Step N.X)_` = should be done after that automated step\n   - No annotation = do anytime during the phase\n   - Only create this file when manual tasks exist — no empty files.\n\n4. **Write `tasks\u002Frecord-todo.md`** (only if this phase identifies non-blocking condition-gated records):\n   ```markdown\n   # Record Tasks — [Project Name]\n\n   > These tasks are non-blocking records or measurements. Do not execute them through `$exec` unless promoted to `tasks\u002Ftodo.md`.\n\n   - [ ] [task]\n     - Source: [phase\u002Fspec\u002Fcriterion]\n     - Condition: [when this becomes eligible]\n     - Non-blocking reason: [why this is not a launch gate or current step]\n     - Required data\u002Faccess: [data, portal, aggregate, credential, or user-provided output]\n     - Measurement\u002Fquery: [how to collect evidence]\n     - Target\u002Facceptance note: [threshold or expected record]\n     - Revisit: [date or cadence]\n     - Completion evidence: [where to record the result]\n     - Promotion rule: [when to move this into `tasks\u002Ftodo.md`]\n   ```\n\n5. **Write `tasks\u002Frecurring-todo.md`** (only if this phase identifies recurring obligations):\n   ```markdown\n   # Recurring Tasks — [Project Name]\n\n   > These tasks recur on a cadence. Do not execute them through `$exec` unless a due run is promoted to `tasks\u002Ftodo.md`.\n\n   - [ ] [task]\n     - Cadence: [daily\u002Fweekly\u002Fmonthly\u002Fquarterly\u002Fon release\u002Fetc.]\n     - Owner\u002Fagent: [human, `$skill`, or agent role]\n     - Scope: [project\u002Fapp\u002Farea]\n     - Trigger: [time, release, data threshold, user request]\n     - Last run: [date or never]\n     - Next due: [date or rule]\n     - Command\u002Fskill: [command or skill to run]\n     - Evidence\u002Foutput path: [where results are recorded]\n     - Escalation conditions: [when it becomes executable or blocking work]\n   ```\n\n## Next-Step Routing\n\nBefore handing back, identify the next concrete work item from project state, then recommend the executor and invocation.\n\nOutput exactly two lines beyond the normal report:\n\n- **Next work:** \u003Cspecific first step, manual blocker, or verification gap for the planned phase>\n- **Recommended next command:** \u003Cone command or route>\n\nRules:\n\n- Make the next work item primary. Derive it from the first executable step in `tasks\u002Ftodo.md`, any matching blocker in `tasks\u002Fmanual-todo.md`, or the phase's verification\u002Fsetup gap. Do not use agent mode itself as the next work item.\n- Use `.\u002Fscripts\u002Fagent-mode.sh` only to choose command text. If it is missing, unset, or non-zero, infer routing from the current invocation and task type instead of asking the user to select a mode by default.\n- Inference defaults:\n  - Codex skill invocation (`$plan-phase`, `$exec`) → recommend the matching `$...` command.\n  - Hybrid execution handoff → check `.agents\u002Fproject.json.enabled_packs` for `agent-bridge` — if `agent-bridge` is not enabled, recommend `npx skillpacks install agent-bridge` from the project shell, first; if `agent-bridge` is enabled, recommend `$delegate $exec`.\n  - Claude slash invocation (`\u002Fplan-phase`, `\u002Fexec`, `\u002Fdelegate`) or orchestration-heavy work → check `.agents\u002Fproject.json.enabled_packs` for `exec-loop` — if `exec-loop` is not enabled, recommend `npx skillpacks install exec-loop` from the project shell, first; if `exec-loop` is enabled, recommend the matching `\u002F...` route.\n  - External human-only manual work (browser\u002Fauth\u002FDNS\u002Fservice dashboard work with no reliable authenticated CLI\u002FAPI path, paid account setup, real-device checks, or production smoke-test work needing human sign-off) → check `.agents\u002Fproject.json.enabled_packs` for `guided-walkthrough` — if `guided-walkthrough` is not enabled, recommend `npx skillpacks install guided-walkthrough` from the project shell, first; if `guided-walkthrough` is enabled, recommend `$guide` — or a Claude-guided manual step rather than `$exec`.\n  - Agent-executable work misfiled in `tasks\u002Fmanual-todo.md`, task-doc bookkeeping, stale `tasks\u002Fmanual-todo.md` cleanup, or reconciliation against repo\u002Fhistory reality → check `.agents\u002Fproject.json.enabled_packs` for `docs-health` — if `docs-health` is not enabled, recommend `npx skillpacks install docs-health` from the project shell, first; if `docs-health` is enabled, recommend `$reconcile-dev-docs fix tasks` — promotion to `tasks\u002Ftodo.md`, or a direct dev-doc audit, not `$guide`.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, include `npx skillpacks install \u003Cpack-name>` from the project shell, as the install prerequisite before the recommendation.\n- Only present multiple commands when the ambiguity materially changes execution safety or there are equally valid next work items. Otherwise choose the best route and mention degraded mode lookup inline.\n\n## Constraints\n\n- **One phase per invocation.** Do not decompose multiple phases ahead of time.\n- **Require `tasks\u002Froadmap.md`.** If it's missing, stop and direct the user to `$roadmap`.\n- **Preserve the roadmap's Goal, Scope, and Acceptance Criteria exactly.** Those are `$roadmap`'s decisions. Only add implementation detail beneath them.\n- **Phase headers must use `## Phase N: [Title]` format** and steps must use `- Step N.X:` format — this is required by `$exec` and `$ship`.\n- Every milestone must have specific, checkable acceptance criteria — not vague statements like \"works correctly\" but concrete conditions like \"POST \u002Fapi\u002Fitems returns 201 with valid payload and persists to database.\"\n- Every `tdd` phase must start with writing failing tests. `tests-after` phases write tests in the Green step.\n- Do not generate standalone cleanup\u002Frefactor steps that are conditional on validation finding drift. Fold those checks into the Green validation step and only create a separate follow-up when there is known concrete remediation work.\n- Do not include implementation code — describe what to build and what to test.\n- Note what already exists in the codebase vs. what needs to be created.\n- The `### Execution Profile` must be decision-complete enough for `$exec` to decide whether to use serial execution, read-only subagents, review subagents, or disjoint write subagents after presenting the plan and proceeding under implicit approval.\n- Subagents must not own task docs, roadmap\u002Fhistory updates, shipping, or deploy steps. Those stay with the main agent.\n- Agent-team write lanes must not target `main` or `master`; each lane gets its own GitHub branch and must return branch, commit SHA, validation evidence, and PR URL before consolidation.\n- Manual tasks MUST NOT appear in `tasks\u002Ftodo.md` — they go in `tasks\u002Fmanual-todo.md` only.\n- Agent-executable work MUST NOT appear in `tasks\u002Fmanual-todo.md` — it goes in `tasks\u002Ftodo.md` or an implementation skill.\n- Non-blocking record tasks MUST NOT appear in `tasks\u002Ftodo.md` — they go in `tasks\u002Frecord-todo.md` unless explicitly promoted.\n- Recurring obligations MUST NOT appear in `tasks\u002Ftodo.md` by default — they go in `tasks\u002Frecurring-todo.md` unless a due run is current execution work.\n- Do NOT put plans in `AGENTS.md`, `CLAUDE.md`, or `docs\u002Fplan.md`.\n\n## Alignment Page\n\nBy default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks\u002F*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment\u002Fplan-phase-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification\u002Freview need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":21,"parent":34,"version":35,"invocation":36,"description":7},"exec","v0.4","sub-skill","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fagent-work-admin\u002Fcodex\u002Fplan-phase\u002Farchive\u002Fv0.4",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill plan-phase",{"tool":53,"command":54},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill plan-phase",{"tool":56,"command":57},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill plan-phase","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fagent-work-admin\u002Fcodex\u002Fplan-phase\u002Farchive\u002Fv0.4\u002FSKILL.md",true,[61,67,71,75,79,83,87,91,95,99,103,107,111,115],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fandroid.md","REFERENCE","参考文档",2081,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Freferences\u002Fandroid.md",{"path":68,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fapple.md",3919,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Freferences\u002Fapple.md",{"path":72,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fcross-platform.md",3282,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Freferences\u002Fcross-platform.md",{"path":76,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fweb.md",3398,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Freferences\u002Fweb.md",{"path":80,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":81,"sourceHtmlUrl":82},"rules\u002Fannouncements.md",2236,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fannouncements.md",{"path":84,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":85,"sourceHtmlUrl":86},"rules\u002Fcontrast-color.md",2278,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fcontrast-color.md",{"path":88,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":89,"sourceHtmlUrl":90},"rules\u002Fforms.md",3023,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fforms.md",{"path":92,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":93,"sourceHtmlUrl":94},"rules\u002Fkeyboard-focus.md",2403,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fkeyboard-focus.md",{"path":96,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":97,"sourceHtmlUrl":98},"rules\u002Fmedia.md",2035,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fmedia.md",{"path":100,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":101,"sourceHtmlUrl":102},"rules\u002Fmotion-time.md",2497,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fmotion-time.md",{"path":104,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":105,"sourceHtmlUrl":106},"rules\u002Fsemantics.md",2619,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Fsemantics.md",{"path":108,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":109,"sourceHtmlUrl":110},"rules\u002Ftargets-gestures.md",2316,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Ftargets-gestures.md",{"path":112,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":113,"sourceHtmlUrl":114},"rules\u002Ftext-alternatives.md",2085,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Ftext-alternatives.md",{"path":116,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":117,"sourceHtmlUrl":118},"rules\u002Ftext-scaling.md",2248,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftartinerlabs\u002Fskills\u002Fskills\u002Faccessibility\u002Frules\u002Ftext-scaling.md",[120,132,142,154,169,180],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":29},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[127,128,129,130,23,131],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":29},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[139,140,141,131,129,23],"deck install valid","deck","install",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":29},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[149,150,151,131,152,153,129,23],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":165,"publishedAt":29},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":163,"taxonomyTypeDesc":164},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[166,167,131,152,23,168,129],"codex missing skill valid","missing","fallback",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":29},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[175],{"categoryNo":161,"categoryName":162,"taxonomyType":163,"taxonomyTypeDesc":164},[131,152,168,177,178,179,23,129],"base skill","codex base skill fallback valid","base",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":29},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[131,151,150,187,153,23,129],"claude pack guard valid"]