[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAW9W7MC49WHVBADMHTGEJ":3,"skill-same:01M6DAW9W7MC49WHVBADMHTGEJ":160},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":13,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6DAW9W7MC49WHVBADMHTGEJ","project-direction",null,"Use when deciding what a project should work on next, comparing competing priorities, deriving a milestone from VISION, brainstorming new feature candidates that fit the project's doctrine, judging whether a project's goals and requirements are settled enough to begin authoring specifications, sequencing an approved specification into an execution graph, or deciding what to do about already-confirmed spec drift. Triggers on \"what should we work on next\", \"prioritize features\", \"is this roadmap aligned\", \"what's highest leverage\", \"what's the next milestone\", \"should we build this or Y\", \"are we ready to write specs\", \"break this approved spec down\", \"brainstorm features\", \"what could we build\".","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"project direction","project","direction","break","prioritize features","when","sequencing","active","next","work","milestone","specification","drift","spec drift","roadmap","brainstorm","work on","openai codex","ready","leverage","2026-11-10 10:12:30",false,"---\nname: project-direction\ndescription: Use when deciding what a project should work on next, comparing competing priorities, deriving a milestone from VISION, brainstorming new feature candidates that fit the project's doctrine, judging whether a project's goals and requirements are settled enough to begin authoring specifications, sequencing an approved specification into an execution graph, or deciding what to do about already-confirmed spec drift. Triggers on \"what should we work on next\", \"prioritize features\", \"is this roadmap aligned\", \"what's highest leverage\", \"what's the next milestone\", \"should we build this or Y\", \"are we ready to write specs\", \"break this approved spec down\", \"brainstorm features\", \"what could we build\".\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n    - Claude Fable 5.1\n    - OpenAI Codex\n  status: active\n  last_reviewed: \"2026-10-03\"\n---\n\n# Project Direction\n\nDecide what a project works on next. Ground every decision in specs, repo evidence, and implementation reality. Optimize for spec alignment, tractability, leverage, low-churn execution — not feature count.\n\nDo not use when:\n- One concrete new feature, idea → spec → `..\u002Fproject-feature-request\u002FSKILL.md`.\n- Score repo health \u002F confirm findings → `..\u002Fproject-review\u002FSKILL.md` (hands its packet here).\n- Exhaustive spec↔code reconciliation, or \"does code match spec?\" before any drift is confirmed → `..\u002Fspec-concretization\u002FSKILL.md`.\n- Backlog mechanics only, no direction analysis → `\u002Fbeads-orchestration` (beads-writer).\n- Recurring orchestrated pursuit loop (lane-sequenced surface audits + ideation at\n  scale + gated work plan) → `..\u002Frelentless-vision-pursuit\u002FSKILL.md`;\n  ideation here is the inline single-brief mode it builds on.\n\n## Core Rules\n\n1. **Ground work in its governing contract** — use the proportional\n   [work-allocation contract](..\u002F..\u002Freferences\u002Fwork-allocation.md#governing-contract).\n   Routine settled fixes go directly to beads-writer; this project-direction\n   lifecycle governs work that actually needs direction or specification.\n2. **Honor actual signoff gates** — new or unresolved behavior follows its\n   applicable spec\u002Fapproval path; repository-mandated requirements remain binding.\n3. **Evidence over assumption** — cite files, functions, spec sections. Label claims [Observed] \u002F [Inferred] \u002F [Unknown].\n4. **Push back** — flag misaligned, premature, unrealistic, infeasible work directly.\n5. **Minimize churn** — remove dead paths over back-compat shims (`\u002Fth-engineering` cruft-cleanup is the bar); serialize conflicting work.\n6. **Rigor where truth changes** — deep reconciliation guards *changes to normative artifacts*; consuming them is one verification pass, not four.\n7. **VISION is continuous** — every candidate, spec delta, bead, discovery, and\n   closeout cites the doctrine mandate it advances. Revalidate when the recorded\n   baseline commit changes; never treat a past doctrine check as permanent.\n8. **Relentless, bounded progress** — resolve non-blocking gaps in scope, create\n   explicit investigation\u002Fspec-first work for real unknowns, and keep moving to\n   the next unblocked spec outcome. Never hide work in TODOs or smuggle adjacent\n   ideas into the active graph.\n9. **Readiness before authoring** — a project about to write its *first* specs\n   passes the launch gate ([`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md))\n   first. Readiness is a verdict with cited evidence, never a feeling; a\n   non-empty reopen-list means shape work, not spec work.\n\n## Workflow\n\n### Preflight: Gather Context\n\nInfer from the repo. Ask only for a parameter the repo cannot answer and whose\nvalue changes the plan; otherwise state the assumption and proceed:\n\n| Parameter | Values | Default |\n|-----------|--------|---------|\n| Project type | library, SDK, backend, SaaS, frontend, CLI, mobile, monorepo, ML\u002Fdata, internal tool, IaC | Infer |\n| Primary user | developers, end users, internal team, enterprises | Infer |\n| Maturity | prototype, beta, production, mission-critical | Infer |\n| Spec location | openspec\u002F, spec\u002F, docs\u002Fdesign\u002F, or none | Infer from scan |\n| Focus | full direction, launch gate, feature evaluation, spec-drift check, work decomposition | Full |\n| Inputs on hand | project-review packet, feature-request spec delta, spec-concretization report, cold start | Cold start |\n\nThen check for upstream inputs — they change how much of each phase runs (Receiver Protocol below).\n\n### Receiver Protocol: Consume Upstream Packets, Don't Re-Derive\n\n**From `..\u002Fproject-review\u002F` (handoff packet).** Read the newest\n`docs\u002Freviews\u002F*-packet.md` (the shared packet home — review writes it, this\nsubskill consumes it; ask before using anything older than the latest). Fresh\n= repo HEAD matches the packet's recorded commit SHA, or user accepts\nstaleness. Fresh packet:\n- Adopt its Phase 0 baseline (pillar maturity, source-of-truth order, normative requirements, contradictions) → Phase 1 = doctrine *check*, not re-derivation.\n- Confirmed findings = Phase 2 evidence. Agent C skips review-scored dimensions (test confidence, observability, delivery readiness) → narrows to architectural fitness *for the proposed direction*.\n- Feed sequencing constraints, dependency hints, deprioritized items to Agent D + Phase 3.\n- Findings flagged as needing doctrine\u002Fspec updates → Phase 1\u002F2 work items, not re-investigation.\n\n**From `..\u002Fproject-feature-request\u002F` (signed-off spec delta).** Funnel already\ndid doctrine, topology, design, spec work — do not re-run while its recorded\ndoctrine\u002Fspec commit still matches. If the baseline changed, revalidate only the\naffected mandates. Phase 2 narrows to integrating the delta; Phase 3 sequences\nit against existing work.\n\n**From `..\u002Fspec-concretization\u002F` (run report).** Read the newest\n`docs\u002Freviews\u002F*-spec-concretization.md`; fresh = its `Concretized:` SHA\nmatches HEAD. Its Escalations section is the input: architecture\u002Ftrust\u002F\nmigration gaps enter Phase 2 as design work; sequencing questions arrive with\ntheir beads already filed — Phase 3 orders them, it does not re-create them.\n\n**Cold start.** No packet, no delta → run phases as written.\n\n### Reconciliation Protocol: Proportional to Risk\n\nReconciliation passes = subagent-driven deep-dive reviews of generated artifacts. Same brief every pass (fill only the braces); it states the stakes and the evidence contract instead of a persona:\n\n```text\nReconcile the artifacts below against their sources of truth. They are\nnormative for this project: downstream agents implement whatever they say,\nso an error that survives this review multiplies.\n\nPhase: {phase, what it changed, its acceptance criteria}\nArtifacts under review: {paths}\nSources of truth: {doctrine \u002F lore \u002F spec \u002F code paths}\n\nYou have not seen how these artifacts were produced; treat them as neither\ncorrect nor incorrect. Look for contradictions, omissions, requirement\ndrift, weak assumptions, and unverifiable claims. Report every finding you\ncan evidence, including minor and low-confidence ones. For each: the\nfile\u002Fsection reference, the acceptance criterion it affects, severity,\nconfidence, and the minimum precise change that resolves it. The\norchestrator ranks and filters, so leave nothing out for seeming small.\nWhere an area is clean, say what you checked. End with a verdict:\nacceptance criteria met or not met, naming the findings that block\nacceptance. Read-only: propose changes, do not apply them.\n```\n\nTwo tiers, chosen per phase by what the phase did; change-tier depth scales\nwith blast radius (same sizing vocabulary as\n`..\u002Fproject-feature-request\u002FSKILL.md`):\n\n| Tier | When | Protocol |\n|------|------|----------|\n| **Change-tier, small** | Modified one spec's requirements; no doctrine\u002Flore edits, no cross-boundary contracts | 1 pass, fixes applied, 1 confirming pass |\n| **Change-tier, medium** | Several specs, new external surface, or lore edits | 2 passes + confirming pass |\n| **Change-tier, large** | Doctrine edits, new subsystem, or cross-boundary contract changes | ≥4 dedicated passes (`R1`-`R4`), fresh subagent each, fixes applied between passes; continue while acceptance criteria unmet |\n| **Verify-tier** | Phase only *consumed* normative artifacts: doctrine checks, drift analysis, graph from approved changeset | One verification pass; escalate to change-tier only if it finds the consumed artifacts need modification |\n\nA pass converges when no acceptance-blocking finding remains; other findings\nare fixed or recorded without spending another pass on them.\n\nEvery change-tier pass uses a fresh subagent regardless of size — size sets\nthe pass count, never self-review. Run\n`uv run \u003Cth-projects>\u002Fscripts\u002Fspec-trace-check.py \u003Crepo-root> --authoring` before the\nfirst pass; mechanical findings are fixed directly, not spent on subagents.\n\nMechanical validations (cycle checks, spec-link coverage, mandate coverage) = scripts-and-checklists — run directly; not passes, no subagents.\n\n**Convergence ceiling**: artifact set still failing after 6 passes → stop, summarize unresolved findings with evidence, present disagreement to user, do not proceed on an unconverged artifact.\n\n**Commit discipline**: commit normative changes when their phase converges (later phases build on a fixed base). Read-only runs (no normative artifact changed) make no commits, need no push gates. Push per repo convention, at end of run.\n\n### Phase 1: Doctrine Alignment (project-shape Baseline)\n\nJudge proposed work against the project's actual doctrine.\n\n1. Obtain shape baseline: adopt a fresh review packet's baseline, or run `..\u002Fproject-shape\u002Fscripts\u002Fshape-scan.sh` and read `about\u002Fheart-and-soul\u002F` + `about\u002Flegends-and-lore\u002F`.\n2. Map each proposed feature\u002Finitiative to baseline; flag doctrine conflicts.\n3. Doctrine\u002Flore docs need editing (contradictions, blocking gaps) → edit and run **change-tier** on them.\n4. Docs sound, merely consumed → **verify-tier** (one pass over feature-to-doctrine mapping).\n\nAcceptance: every proposed feature explicitly aligned\u002Frejected\u002Fescalated against doctrine, with citations; any doctrine\u002Flore edits reconciled (change-tier) and committed before Phase 2.\n\n### Phase 2: Specification Scan + Fitness\u002FGap Synthesis\n\n1. Run spec scan: `bash \u003Cskill_dir>\u002Fscripts\u002Fspec-scan.sh \u003Crepo_root>`\n2. Parallel investigation (A, B, C) then synthesis (D) — roles + dispatch in `references\u002Fsubagent-template.md`. Assign one primary evidence owner per concern; pass artifact paths plus a compact baseline manifest, not duplicated full documents:\n\n| Agent | Role | Input | Output |\n|-------|------|-------|--------|\n| A | Doctrine\u002Fspec intent validation | Phase 1 baseline + scan + specs | Intent model, mandate checks, requirement fidelity |\n| B | Spec adherence & workflows | Scan + specs | Spec drift inventory, workflow completeness |\n| C | Implementation fitness | Scan + code (minus dimensions a fresh packet covered) | Test confidence, observability, delivery readiness, architectural fitness |\n| D | Alignment & gap synthesis | A + B + C (+ packet constraints) | Alignment matrix, gaps, push-back list, spec deltas |\n\n3. Synthesize into an OpenSpec changeset per `references\u002Fopenspec-changeset.md` (tool-agnostic `openspec` CLI loop; `\u002Fopsx:ff` = Codex accelerator for the same procedure).\n4. **Change-tier** reconciliation on the changeset (normative artifact). No changeset produced (pure analysis) → **verify-tier** on the analysis.\n\nAcceptance: spec intent, implemented spine, gap analysis coherent and actionable; any changeset complete, internally consistent, traceable to doctrine + implementation evidence, reconciled, and committed before Phase 3.\n\n### Phase 3: Beads Generation (Planning Graph Only)\n\nCall `\u002Fbeads-orchestration` (beads-writer) to build a full acyclic dependency\ngraph from the approved changeset — approval recorded as the\n`Sign-off: \u003Cidentity> \u003Cdate>` line in its `proposal.md`\n([spec-format § Sign-off marker](..\u002F..\u002Freferences\u002Fspec-format.md#sign-off-marker)). Load\n[`references\u002Fwork-allocation.md`](..\u002F..\u002Freferences\u002Fwork-allocation.md) before\ndecomposing: preserve one finite accepted owner outcome and distinguish tracking\nfrom coherent delivery packages. Existing related beads may share one owner,\nbranch, PR, and review cycle while retaining member acceptance.\n\n1. Reuse or generate finite accepted outcomes and member tracking, with real\n   dependencies and no cycles or overlapping implementation owners. Identify\n   shared prerequisites once rather than cloning substrate work across epics.\n2. Run the allocation contract's dedupe and cohesion scan across open\u002Frecently\n   closed beads, active PRs, and the proposed graph. Propose cohesive packages\n   among existing beads or serialize shared decisions; keep independent rollback\n   paths separate. Do not split into sub-epics to satisfy child-count targets.\n3. Populate every implementation bead's **Current Operative Packet** in its\n   structured description\u002Fdesign\u002Facceptance fields, using concise current\n   instructions and exact authority\u002Fhistory references. Approved direction,\n   adopted behavior, packet-complete scope, and runnable-now are distinct;\n   settle a changed shared interface and source assumptions before releasing\n   its dependents, once at that contract rather than once per child.\n4. Map every in-scope `v1-mandatory` requirement to an implementation bead and\n   verification path; one cohesive bead may cover several adjacent requirements.\n5. Triage gaps, TODOs, unknowns, and expanded ideas through the allocation\n   contract; keep corrections\u002Flocal debt in scope, route boundary\u002Fspec changes\n   back to feature-request, and capture adjacent scope separately.\n6. Sequence tightened cross-cutting contracts as representation → propagation →\n   enforcement when that creates independently safe rollout and rollback points.\n7. Preserve the accepted outcome through foundation\u002Fdark merges and use one\n   finite cross-child closeout path where needed: its checklist, an existing\n   report, or one justified bead. Reuse it when gaps remain; do not create\n   recursive reconciliation generations. Report beads may use\n   `scripts\u002Fepic-report-scaffold.sh` (see `references\u002Fepic-report.md`).\n8. Add a milestone-close callback that refreshes VISION mandate coverage and\n   re-enters milestone synthesis when uncovered mandates remain.\n9. Run mechanical graph validations (cycle check, complete mandatory-mandate\n   coverage, spec-link coverage), then **verify-tier**.\n\nAcceptance: graph acyclic, prioritized, spec-traceable, and honest about runnable\nscope versus real waits. Accepted outcomes, proposed delivery packages, and\nmember criteria are explicit. Execution belongs to `\u002Fbeads-orchestration`\n(outcome-owning looper or coordinator), not this planning phase.\n\n### Handoff Output (No Delivery Ownership)\n\nOutput the direction report per `references\u002Fwork-plan-template.md`:\n- Project's real direction?\n- What to work on next?\n- What to stop pretending it can do?\n- Which beads graph was generated and why it's coherent with doctrine\u002Flore\u002Fspec.\n\nDo not execute\u002Fdeliver the beads plan here — hand off explicitly to an outcome-owning looper or beads coordinator.\n\n## Adapting to Focus\n\nFocus modes change which phases do real work and which tier applies — the phase *questions* are always answered, even if one line backed by a citation.\n\n- **Full direction analysis** (default): all phases as written; change-tier wherever normative artifacts change.\n- **Launch gate** (pre-specification readiness: \"are we ready to write specs\", \"is the vision settled enough to specify from\", or any run that would author a project's *first* spec): administer the readiness question series to a **fresh-context reviewer subagent** — closed verdict vocabulary, cited evidence, falsification first. Phase 1 supplies the doctrine baseline and the parameter block; the gate replaces Phase 2 until it returns READY. `NOT READY` → a remediation brief routed by finding class (doctrine → project-shape, design contract → feature-request), no Phase 3. Read [`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md).\n- **Milestone synthesis** (vision-generative: \"what next\" with no proposals on hand, or a milestone just closed): doctrine *produces* the candidates instead of judging proposed ones — mandate coverage matrix, ideas-ledger unparking, ranked milestone brief; user selects before anything enters Phases 2-3. Read [`references\u002Fmilestone-synthesis.md`](references\u002Fmilestone-synthesis.md).\n- **Ideation** (vision-generative, divergent: \"brainstorm what we could build\", \"what features would fit this project\"): milestone synthesis's divergent twin — doctrine *grounds* new candidates instead of gating proposed ones. Mandate citation relaxes to a fit trace; candidates classed mandate-grounded vs vision-extending; user triages the brief (pursue → feature-request funnel, park → ledger, discard). No Phases 2-3 from this mode — pursued candidates re-enter via the funnel. Read [`references\u002Fideation.md`](references\u002Fideation.md).\n- **Feature evaluation** (\"should we build X?\"): a *new, single* request routes to `..\u002Fproject-feature-request\u002FSKILL.md` (its funnel returns a spec delta here). Run this mode only for portfolio questions (X vs competing priorities): Phase 1 verify-tier doctrine check on X, Phase 2 narrowed to the 8-dimension evaluation in `references\u002Falignment-review.md`, Phase 3 only if X is approved. No commits unless specs changed.\n- **Spec-drift check** (already-confirmed drift, e.g. from a review or spec-concretization packet; the inventory itself is `..\u002Fspec-concretization\u002F`): Phase 1 verify-tier (doctrine consumed). Phase 2 emphasizes B + C + D; produce a corrective changeset (change-tier) only for confirmed drift the user wants fixed — else deliver the drift inventory read-only. Phase 3 only when a changeset was produced.\n- **Work decomposition** (\"break this down\"): assumes an approved spec. Phase 1 skipped unless the spec lacks a doctrine link. Phase 2 = one verify-tier pass confirming implementability. Phase 3 is the primary artifact (mechanical validations + verify-tier pass).\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| No specs exist | Launch gate first (Core Rule 9) — Phase 1 doctrine check, then `references\u002Flaunch-gate.md`. READY → Phase 2 creates the initial changeset via `references\u002Fopenspec-changeset.md`. NOT READY → remediation brief, no changeset. |\n| No specs *and* no doctrine | The gate has nothing to administer against. Route to `..\u002Fproject-shape\u002F` bootstrap; return here once doctrine is adopted. |\n| `openspec` CLI unavailable | Stop changeset synthesis, report it; deliver analysis + drift inventory, recommend installing the CLI. Do NOT hand-write changeset scaffolds. |\n| Specs outdated | Agent B catalogs drift; Phase 2 must produce a corrective changeset before Phase 3. |\n| No clear direction | State it directly. Recommend a direction-setting workshop or `..\u002Fproject-shape\u002F` bootstrap before feature work. |\n| Conflicting specs | Flag each contradiction with evidence from both sides. Do not resolve — escalate to user. |\n| Reconciliation won't converge | Convergence ceiling (6 passes): stop, present unresolved findings, await user judgment. |\n| Massive spec surface (>50 sections) | Shard the inventory by non-overlapping capability slice. Never sample `v1-mandatory` requirements or active deltas; sample only explicitly post-v1\u002Fadvisory material and label it. |\n\n## Sample Triggers\n\n- \"What should we work on next in this repo?\"\n- \"Are we ready to start writing specifications?\"\n- \"Does the code actually match the spec?\"\n- \"Should we build X, or is it a distraction?\"\n- \"Break this approved spec into sequenced chunks.\"\n- \"Is our roadmap aligned with what the project really is?\"\n\n## References\n\n| File | Read when | Content |\n|------|-----------|---------|\n| [`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md) | Launch-gate focus mode; before authoring a project's first spec | Pre-specification readiness question series, administration protocol, verdict rule, record + trend log, parameter block |\n| [`references\u002Fmilestone-synthesis.md`](references\u002Fmilestone-synthesis.md) | Milestone-synthesis focus mode | Deriving candidates from doctrine: mandate coverage matrix, ledger unparking, milestone brief format |\n| [`references\u002Fideation.md`](references\u002Fideation.md) | Ideation focus mode | Divergence lenses, fit-trace classing, mandate-grounded vs vision-extending routing, ideation brief format |\n| [`references\u002Fdirection-model.md`](references\u002Fdirection-model.md) | Phase 2 (agents A, B, C) | Analysis dimensions: project spirit, requirement classification, current-state assessment |\n| [`references\u002Falignment-review.md`](references\u002Falignment-review.md) | Phase 2 (agent D); feature evaluation | 8-dimension evaluation, classification buckets, push-back checklist, gap analysis |\n| [`references\u002Fopenspec-changeset.md`](references\u002Fopenspec-changeset.md) | Phase 2 step 3 | How to synthesize an OpenSpec changeset via the `openspec` CLI |\n| [`references\u002Fwork-plan-template.md`](references\u002Fwork-plan-template.md) | Handoff output | Output format, chunk\u002Fsequencing presentation, reconciliation reporting |\n| [`..\u002F..\u002Freferences\u002Fwork-allocation.md`](..\u002F..\u002Freferences\u002Fwork-allocation.md) | Phase 3 decomposition and discovery triage | Cohesive bead boundaries, overhead test, ownership, mandatory coverage, gap\u002FTODO\u002Funknown routing |\n| [`references\u002Fsubagent-template.md`](references\u002Fsubagent-template.md) | Phases 1-3 (reconciliation + dispatch) | Agent roles, dispatch template, depth limits, per-agent notes |\n| [`references\u002Fepic-report.md`](references\u002Fepic-report.md) | Phase 3 (report bead structure) | Report bead template\u002Fexecution, diagram integration, spec compliance matrix |\n\n## Scripts\n\n- [`scripts\u002Fspec-scan.sh`](scripts\u002Fspec-scan.sh) `\u003Crepo_root>` — discovers specs, design docs, roadmap, agent context, issue tracking, git activity by area. Run in Phase 2.\n- [`scripts\u002Fepic-report-scaffold.sh`](scripts\u002Fepic-report-scaffold.sh) `\u003Cepic-id> [repo_root]` — used by Phase 3 report-bead executors; bootstraps report markdown from beads epic data, creates `docs\u002Freports\u002F` with metadata pre-filled.\n\n## Diagrams\n\nWorkflow visuals (each `.svg` has an editable `.excalidraw` source alongside; regenerate with `\u002Fth-engineering` (excalidraw-diagram), `--format svg`):\n\n| Diagram | Shows |\n|---------|-------|\n| [`references\u002Fdiagrams\u002Fproject-direction-workflow.svg`](references\u002Fdiagrams\u002Fproject-direction-workflow.svg) ([source](references\u002Fdiagrams\u002Fproject-direction-workflow.excalidraw)) | Phase-by-phase workflow, preflight through handoff |\n| [`references\u002Fdiagrams\u002Fproject-direction-artifacts.svg`](references\u002Fdiagrams\u002Fproject-direction-artifacts.svg) ([source](references\u002Fdiagrams\u002Fproject-direction-artifacts.excalidraw)) | Analysis-agent and report-bead artifact flow |\n","# Project Direction\n\nDecide what a project works on next. Ground every decision in specs, repo evidence, and implementation reality. Optimize for spec alignment, tractability, leverage, low-churn execution — not feature count.\n\nDo not use when:\n- One concrete new feature, idea → spec → `..\u002Fproject-feature-request\u002FSKILL.md`.\n- Score repo health \u002F confirm findings → `..\u002Fproject-review\u002FSKILL.md` (hands its packet here).\n- Exhaustive spec↔code reconciliation, or \"does code match spec?\" before any drift is confirmed → `..\u002Fspec-concretization\u002FSKILL.md`.\n- Backlog mechanics only, no direction analysis → `\u002Fbeads-orchestration` (beads-writer).\n- Recurring orchestrated pursuit loop (lane-sequenced surface audits + ideation at\n  scale + gated work plan) → `..\u002Frelentless-vision-pursuit\u002FSKILL.md`;\n  ideation here is the inline single-brief mode it builds on.\n\n## Core Rules\n\n1. **Ground work in its governing contract** — use the proportional\n   [work-allocation contract](..\u002F..\u002Freferences\u002Fwork-allocation.md#governing-contract).\n   Routine settled fixes go directly to beads-writer; this project-direction\n   lifecycle governs work that actually needs direction or specification.\n2. **Honor actual signoff gates** — new or unresolved behavior follows its\n   applicable spec\u002Fapproval path; repository-mandated requirements remain binding.\n3. **Evidence over assumption** — cite files, functions, spec sections. Label claims [Observed] \u002F [Inferred] \u002F [Unknown].\n4. **Push back** — flag misaligned, premature, unrealistic, infeasible work directly.\n5. **Minimize churn** — remove dead paths over back-compat shims (`\u002Fth-engineering` cruft-cleanup is the bar); serialize conflicting work.\n6. **Rigor where truth changes** — deep reconciliation guards *changes to normative artifacts*; consuming them is one verification pass, not four.\n7. **VISION is continuous** — every candidate, spec delta, bead, discovery, and\n   closeout cites the doctrine mandate it advances. Revalidate when the recorded\n   baseline commit changes; never treat a past doctrine check as permanent.\n8. **Relentless, bounded progress** — resolve non-blocking gaps in scope, create\n   explicit investigation\u002Fspec-first work for real unknowns, and keep moving to\n   the next unblocked spec outcome. Never hide work in TODOs or smuggle adjacent\n   ideas into the active graph.\n9. **Readiness before authoring** — a project about to write its *first* specs\n   passes the launch gate ([`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md))\n   first. Readiness is a verdict with cited evidence, never a feeling; a\n   non-empty reopen-list means shape work, not spec work.\n\n## Workflow\n\n### Preflight: Gather Context\n\nInfer from the repo. Ask only for a parameter the repo cannot answer and whose\nvalue changes the plan; otherwise state the assumption and proceed:\n\n| Parameter | Values | Default |\n|-----------|--------|---------|\n| Project type | library, SDK, backend, SaaS, frontend, CLI, mobile, monorepo, ML\u002Fdata, internal tool, IaC | Infer |\n| Primary user | developers, end users, internal team, enterprises | Infer |\n| Maturity | prototype, beta, production, mission-critical | Infer |\n| Spec location | openspec\u002F, spec\u002F, docs\u002Fdesign\u002F, or none | Infer from scan |\n| Focus | full direction, launch gate, feature evaluation, spec-drift check, work decomposition | Full |\n| Inputs on hand | project-review packet, feature-request spec delta, spec-concretization report, cold start | Cold start |\n\nThen check for upstream inputs — they change how much of each phase runs (Receiver Protocol below).\n\n### Receiver Protocol: Consume Upstream Packets, Don't Re-Derive\n\n**From `..\u002Fproject-review\u002F` (handoff packet).** Read the newest\n`docs\u002Freviews\u002F*-packet.md` (the shared packet home — review writes it, this\nsubskill consumes it; ask before using anything older than the latest). Fresh\n= repo HEAD matches the packet's recorded commit SHA, or user accepts\nstaleness. Fresh packet:\n- Adopt its Phase 0 baseline (pillar maturity, source-of-truth order, normative requirements, contradictions) → Phase 1 = doctrine *check*, not re-derivation.\n- Confirmed findings = Phase 2 evidence. Agent C skips review-scored dimensions (test confidence, observability, delivery readiness) → narrows to architectural fitness *for the proposed direction*.\n- Feed sequencing constraints, dependency hints, deprioritized items to Agent D + Phase 3.\n- Findings flagged as needing doctrine\u002Fspec updates → Phase 1\u002F2 work items, not re-investigation.\n\n**From `..\u002Fproject-feature-request\u002F` (signed-off spec delta).** Funnel already\ndid doctrine, topology, design, spec work — do not re-run while its recorded\ndoctrine\u002Fspec commit still matches. If the baseline changed, revalidate only the\naffected mandates. Phase 2 narrows to integrating the delta; Phase 3 sequences\nit against existing work.\n\n**From `..\u002Fspec-concretization\u002F` (run report).** Read the newest\n`docs\u002Freviews\u002F*-spec-concretization.md`; fresh = its `Concretized:` SHA\nmatches HEAD. Its Escalations section is the input: architecture\u002Ftrust\u002F\nmigration gaps enter Phase 2 as design work; sequencing questions arrive with\ntheir beads already filed — Phase 3 orders them, it does not re-create them.\n\n**Cold start.** No packet, no delta → run phases as written.\n\n### Reconciliation Protocol: Proportional to Risk\n\nReconciliation passes = subagent-driven deep-dive reviews of generated artifacts. Same brief every pass (fill only the braces); it states the stakes and the evidence contract instead of a persona:\n\n```text\nReconcile the artifacts below against their sources of truth. They are\nnormative for this project: downstream agents implement whatever they say,\nso an error that survives this review multiplies.\n\nPhase: {phase, what it changed, its acceptance criteria}\nArtifacts under review: {paths}\nSources of truth: {doctrine \u002F lore \u002F spec \u002F code paths}\n\nYou have not seen how these artifacts were produced; treat them as neither\ncorrect nor incorrect. Look for contradictions, omissions, requirement\ndrift, weak assumptions, and unverifiable claims. Report every finding you\ncan evidence, including minor and low-confidence ones. For each: the\nfile\u002Fsection reference, the acceptance criterion it affects, severity,\nconfidence, and the minimum precise change that resolves it. The\norchestrator ranks and filters, so leave nothing out for seeming small.\nWhere an area is clean, say what you checked. End with a verdict:\nacceptance criteria met or not met, naming the findings that block\nacceptance. Read-only: propose changes, do not apply them.\n```\n\nTwo tiers, chosen per phase by what the phase did; change-tier depth scales\nwith blast radius (same sizing vocabulary as\n`..\u002Fproject-feature-request\u002FSKILL.md`):\n\n| Tier | When | Protocol |\n|------|------|----------|\n| **Change-tier, small** | Modified one spec's requirements; no doctrine\u002Flore edits, no cross-boundary contracts | 1 pass, fixes applied, 1 confirming pass |\n| **Change-tier, medium** | Several specs, new external surface, or lore edits | 2 passes + confirming pass |\n| **Change-tier, large** | Doctrine edits, new subsystem, or cross-boundary contract changes | ≥4 dedicated passes (`R1`-`R4`), fresh subagent each, fixes applied between passes; continue while acceptance criteria unmet |\n| **Verify-tier** | Phase only *consumed* normative artifacts: doctrine checks, drift analysis, graph from approved changeset | One verification pass; escalate to change-tier only if it finds the consumed artifacts need modification |\n\nA pass converges when no acceptance-blocking finding remains; other findings\nare fixed or recorded without spending another pass on them.\n\nEvery change-tier pass uses a fresh subagent regardless of size — size sets\nthe pass count, never self-review. Run\n`uv run \u003Cth-projects>\u002Fscripts\u002Fspec-trace-check.py \u003Crepo-root> --authoring` before the\nfirst pass; mechanical findings are fixed directly, not spent on subagents.\n\nMechanical validations (cycle checks, spec-link coverage, mandate coverage) = scripts-and-checklists — run directly; not passes, no subagents.\n\n**Convergence ceiling**: artifact set still failing after 6 passes → stop, summarize unresolved findings with evidence, present disagreement to user, do not proceed on an unconverged artifact.\n\n**Commit discipline**: commit normative changes when their phase converges (later phases build on a fixed base). Read-only runs (no normative artifact changed) make no commits, need no push gates. Push per repo convention, at end of run.\n\n### Phase 1: Doctrine Alignment (project-shape Baseline)\n\nJudge proposed work against the project's actual doctrine.\n\n1. Obtain shape baseline: adopt a fresh review packet's baseline, or run `..\u002Fproject-shape\u002Fscripts\u002Fshape-scan.sh` and read `about\u002Fheart-and-soul\u002F` + `about\u002Flegends-and-lore\u002F`.\n2. Map each proposed feature\u002Finitiative to baseline; flag doctrine conflicts.\n3. Doctrine\u002Flore docs need editing (contradictions, blocking gaps) → edit and run **change-tier** on them.\n4. Docs sound, merely consumed → **verify-tier** (one pass over feature-to-doctrine mapping).\n\nAcceptance: every proposed feature explicitly aligned\u002Frejected\u002Fescalated against doctrine, with citations; any doctrine\u002Flore edits reconciled (change-tier) and committed before Phase 2.\n\n### Phase 2: Specification Scan + Fitness\u002FGap Synthesis\n\n1. Run spec scan: `bash \u003Cskill_dir>\u002Fscripts\u002Fspec-scan.sh \u003Crepo_root>`\n2. Parallel investigation (A, B, C) then synthesis (D) — roles + dispatch in `references\u002Fsubagent-template.md`. Assign one primary evidence owner per concern; pass artifact paths plus a compact baseline manifest, not duplicated full documents:\n\n| Agent | Role | Input | Output |\n|-------|------|-------|--------|\n| A | Doctrine\u002Fspec intent validation | Phase 1 baseline + scan + specs | Intent model, mandate checks, requirement fidelity |\n| B | Spec adherence & workflows | Scan + specs | Spec drift inventory, workflow completeness |\n| C | Implementation fitness | Scan + code (minus dimensions a fresh packet covered) | Test confidence, observability, delivery readiness, architectural fitness |\n| D | Alignment & gap synthesis | A + B + C (+ packet constraints) | Alignment matrix, gaps, push-back list, spec deltas |\n\n3. Synthesize into an OpenSpec changeset per `references\u002Fopenspec-changeset.md` (tool-agnostic `openspec` CLI loop; `\u002Fopsx:ff` = Codex accelerator for the same procedure).\n4. **Change-tier** reconciliation on the changeset (normative artifact). No changeset produced (pure analysis) → **verify-tier** on the analysis.\n\nAcceptance: spec intent, implemented spine, gap analysis coherent and actionable; any changeset complete, internally consistent, traceable to doctrine + implementation evidence, reconciled, and committed before Phase 3.\n\n### Phase 3: Beads Generation (Planning Graph Only)\n\nCall `\u002Fbeads-orchestration` (beads-writer) to build a full acyclic dependency\ngraph from the approved changeset — approval recorded as the\n`Sign-off: \u003Cidentity> \u003Cdate>` line in its `proposal.md`\n([spec-format § Sign-off marker](..\u002F..\u002Freferences\u002Fspec-format.md#sign-off-marker)). Load\n[`references\u002Fwork-allocation.md`](..\u002F..\u002Freferences\u002Fwork-allocation.md) before\ndecomposing: preserve one finite accepted owner outcome and distinguish tracking\nfrom coherent delivery packages. Existing related beads may share one owner,\nbranch, PR, and review cycle while retaining member acceptance.\n\n1. Reuse or generate finite accepted outcomes and member tracking, with real\n   dependencies and no cycles or overlapping implementation owners. Identify\n   shared prerequisites once rather than cloning substrate work across epics.\n2. Run the allocation contract's dedupe and cohesion scan across open\u002Frecently\n   closed beads, active PRs, and the proposed graph. Propose cohesive packages\n   among existing beads or serialize shared decisions; keep independent rollback\n   paths separate. Do not split into sub-epics to satisfy child-count targets.\n3. Populate every implementation bead's **Current Operative Packet** in its\n   structured description\u002Fdesign\u002Facceptance fields, using concise current\n   instructions and exact authority\u002Fhistory references. Approved direction,\n   adopted behavior, packet-complete scope, and runnable-now are distinct;\n   settle a changed shared interface and source assumptions before releasing\n   its dependents, once at that contract rather than once per child.\n4. Map every in-scope `v1-mandatory` requirement to an implementation bead and\n   verification path; one cohesive bead may cover several adjacent requirements.\n5. Triage gaps, TODOs, unknowns, and expanded ideas through the allocation\n   contract; keep corrections\u002Flocal debt in scope, route boundary\u002Fspec changes\n   back to feature-request, and capture adjacent scope separately.\n6. Sequence tightened cross-cutting contracts as representation → propagation →\n   enforcement when that creates independently safe rollout and rollback points.\n7. Preserve the accepted outcome through foundation\u002Fdark merges and use one\n   finite cross-child closeout path where needed: its checklist, an existing\n   report, or one justified bead. Reuse it when gaps remain; do not create\n   recursive reconciliation generations. Report beads may use\n   `scripts\u002Fepic-report-scaffold.sh` (see `references\u002Fepic-report.md`).\n8. Add a milestone-close callback that refreshes VISION mandate coverage and\n   re-enters milestone synthesis when uncovered mandates remain.\n9. Run mechanical graph validations (cycle check, complete mandatory-mandate\n   coverage, spec-link coverage), then **verify-tier**.\n\nAcceptance: graph acyclic, prioritized, spec-traceable, and honest about runnable\nscope versus real waits. Accepted outcomes, proposed delivery packages, and\nmember criteria are explicit. Execution belongs to `\u002Fbeads-orchestration`\n(outcome-owning looper or coordinator), not this planning phase.\n\n### Handoff Output (No Delivery Ownership)\n\nOutput the direction report per `references\u002Fwork-plan-template.md`:\n- Project's real direction?\n- What to work on next?\n- What to stop pretending it can do?\n- Which beads graph was generated and why it's coherent with doctrine\u002Flore\u002Fspec.\n\nDo not execute\u002Fdeliver the beads plan here — hand off explicitly to an outcome-owning looper or beads coordinator.\n\n## Adapting to Focus\n\nFocus modes change which phases do real work and which tier applies — the phase *questions* are always answered, even if one line backed by a citation.\n\n- **Full direction analysis** (default): all phases as written; change-tier wherever normative artifacts change.\n- **Launch gate** (pre-specification readiness: \"are we ready to write specs\", \"is the vision settled enough to specify from\", or any run that would author a project's *first* spec): administer the readiness question series to a **fresh-context reviewer subagent** — closed verdict vocabulary, cited evidence, falsification first. Phase 1 supplies the doctrine baseline and the parameter block; the gate replaces Phase 2 until it returns READY. `NOT READY` → a remediation brief routed by finding class (doctrine → project-shape, design contract → feature-request), no Phase 3. Read [`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md).\n- **Milestone synthesis** (vision-generative: \"what next\" with no proposals on hand, or a milestone just closed): doctrine *produces* the candidates instead of judging proposed ones — mandate coverage matrix, ideas-ledger unparking, ranked milestone brief; user selects before anything enters Phases 2-3. Read [`references\u002Fmilestone-synthesis.md`](references\u002Fmilestone-synthesis.md).\n- **Ideation** (vision-generative, divergent: \"brainstorm what we could build\", \"what features would fit this project\"): milestone synthesis's divergent twin — doctrine *grounds* new candidates instead of gating proposed ones. Mandate citation relaxes to a fit trace; candidates classed mandate-grounded vs vision-extending; user triages the brief (pursue → feature-request funnel, park → ledger, discard). No Phases 2-3 from this mode — pursued candidates re-enter via the funnel. Read [`references\u002Fideation.md`](references\u002Fideation.md).\n- **Feature evaluation** (\"should we build X?\"): a *new, single* request routes to `..\u002Fproject-feature-request\u002FSKILL.md` (its funnel returns a spec delta here). Run this mode only for portfolio questions (X vs competing priorities): Phase 1 verify-tier doctrine check on X, Phase 2 narrowed to the 8-dimension evaluation in `references\u002Falignment-review.md`, Phase 3 only if X is approved. No commits unless specs changed.\n- **Spec-drift check** (already-confirmed drift, e.g. from a review or spec-concretization packet; the inventory itself is `..\u002Fspec-concretization\u002F`): Phase 1 verify-tier (doctrine consumed). Phase 2 emphasizes B + C + D; produce a corrective changeset (change-tier) only for confirmed drift the user wants fixed — else deliver the drift inventory read-only. Phase 3 only when a changeset was produced.\n- **Work decomposition** (\"break this down\"): assumes an approved spec. Phase 1 skipped unless the spec lacks a doctrine link. Phase 2 = one verify-tier pass confirming implementability. Phase 3 is the primary artifact (mechanical validations + verify-tier pass).\n\n## Edge Cases\n\n| Situation | Handling |\n|-----------|----------|\n| No specs exist | Launch gate first (Core Rule 9) — Phase 1 doctrine check, then `references\u002Flaunch-gate.md`. READY → Phase 2 creates the initial changeset via `references\u002Fopenspec-changeset.md`. NOT READY → remediation brief, no changeset. |\n| No specs *and* no doctrine | The gate has nothing to administer against. Route to `..\u002Fproject-shape\u002F` bootstrap; return here once doctrine is adopted. |\n| `openspec` CLI unavailable | Stop changeset synthesis, report it; deliver analysis + drift inventory, recommend installing the CLI. Do NOT hand-write changeset scaffolds. |\n| Specs outdated | Agent B catalogs drift; Phase 2 must produce a corrective changeset before Phase 3. |\n| No clear direction | State it directly. Recommend a direction-setting workshop or `..\u002Fproject-shape\u002F` bootstrap before feature work. |\n| Conflicting specs | Flag each contradiction with evidence from both sides. Do not resolve — escalate to user. |\n| Reconciliation won't converge | Convergence ceiling (6 passes): stop, present unresolved findings, await user judgment. |\n| Massive spec surface (>50 sections) | Shard the inventory by non-overlapping capability slice. Never sample `v1-mandatory` requirements or active deltas; sample only explicitly post-v1\u002Fadvisory material and label it. |\n\n## Sample Triggers\n\n- \"What should we work on next in this repo?\"\n- \"Are we ready to start writing specifications?\"\n- \"Does the code actually match the spec?\"\n- \"Should we build X, or is it a distraction?\"\n- \"Break this approved spec into sequenced chunks.\"\n- \"Is our roadmap aligned with what the project really is?\"\n\n## References\n\n| File | Read when | Content |\n|------|-----------|---------|\n| [`references\u002Flaunch-gate.md`](references\u002Flaunch-gate.md) | Launch-gate focus mode; before authoring a project's first spec | Pre-specification readiness question series, administration protocol, verdict rule, record + trend log, parameter block |\n| [`references\u002Fmilestone-synthesis.md`](references\u002Fmilestone-synthesis.md) | Milestone-synthesis focus mode | Deriving candidates from doctrine: mandate coverage matrix, ledger unparking, milestone brief format |\n| [`references\u002Fideation.md`](references\u002Fideation.md) | Ideation focus mode | Divergence lenses, fit-trace classing, mandate-grounded vs vision-extending routing, ideation brief format |\n| [`references\u002Fdirection-model.md`](references\u002Fdirection-model.md) | Phase 2 (agents A, B, C) | Analysis dimensions: project spirit, requirement classification, current-state assessment |\n| [`references\u002Falignment-review.md`](references\u002Falignment-review.md) | Phase 2 (agent D); feature evaluation | 8-dimension evaluation, classification buckets, push-back checklist, gap analysis |\n| [`references\u002Fopenspec-changeset.md`](references\u002Fopenspec-changeset.md) | Phase 2 step 3 | How to synthesize an OpenSpec changeset via the `openspec` CLI |\n| [`references\u002Fwork-plan-template.md`](references\u002Fwork-plan-template.md) | Handoff output | Output format, chunk\u002Fsequencing presentation, reconciliation reporting |\n| [`..\u002F..\u002Freferences\u002Fwork-allocation.md`](..\u002F..\u002Freferences\u002Fwork-allocation.md) | Phase 3 decomposition and discovery triage | Cohesive bead boundaries, overhead test, ownership, mandatory coverage, gap\u002FTODO\u002Funknown routing |\n| [`references\u002Fsubagent-template.md`](references\u002Fsubagent-template.md) | Phases 1-3 (reconciliation + dispatch) | Agent roles, dispatch template, depth limits, per-agent notes |\n| [`references\u002Fepic-report.md`](references\u002Fepic-report.md) | Phase 3 (report bead structure) | Report bead template\u002Fexecution, diagram integration, spec compliance matrix |\n\n## Scripts\n\n- [`scripts\u002Fspec-scan.sh`](scripts\u002Fspec-scan.sh) `\u003Crepo_root>` — discovers specs, design docs, roadmap, agent context, issue tracking, git activity by area. Run in Phase 2.\n- [`scripts\u002Fepic-report-scaffold.sh`](scripts\u002Fepic-report-scaffold.sh) `\u003Cepic-id> [repo_root]` — used by Phase 3 report-bead executors; bootstraps report markdown from beads epic data, creates `docs\u002Freports\u002F` with metadata pre-filled.\n\n## Diagrams\n\nWorkflow visuals (each `.svg` has an editable `.excalidraw` source alongside; regenerate with `\u002Fth-engineering` (excalidraw-diagram), `--format svg`):\n\n| Diagram | Shows |\n|---------|-------|\n| [`references\u002Fdiagrams\u002Fproject-direction-workflow.svg`](references\u002Fdiagrams\u002Fproject-direction-workflow.svg) ([source](references\u002Fdiagrams\u002Fproject-direction-workflow.excalidraw)) | Phase-by-phase workflow, preflight through handoff |\n| [`references\u002Fdiagrams\u002Fproject-direction-artifacts.svg`](references\u002Fdiagrams\u002Fproject-direction-artifacts.svg) ([source](references\u002Fdiagrams\u002Fproject-direction-artifacts.excalidraw)) | Analysis-agent and report-bead artifact flow |\n",{"name":5,"metadata":43,"description":7},{"owner":44,"status":25,"authors":45,"last_reviewed":49},"tze",[44,46,47,48],"Claude Fable 5","Claude Fable 5.1","OpenAI Codex","2026-10-03","main","ac0f8a90dbdbae93825f4db9614ade0d6872c26d","skills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill project-direction",{"tool":62,"command":63},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill project-direction",{"tool":65,"command":66},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill project-direction","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002FSKILL.md",true,[70,76,80,84,90,94,98,102,106,110,114,118,122,126,130,136,140,144,148,152,156],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"agents\u002Fopenai.yaml","REFERENCE","参考文档",285,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Fagents\u002Fopenai.yaml",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Falignment-review.md",5787,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Falignment-review.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fdiagrams\u002Fproject-direction-artifacts.excalidraw",18826,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fdiagrams\u002Fproject-direction-artifacts.excalidraw",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fdiagrams\u002Fproject-direction-artifacts.svg","ASSET","资产文件",29153,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fdiagrams\u002Fproject-direction-artifacts.svg",{"path":91,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fdiagrams\u002Fproject-direction-workflow.excalidraw",18415,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fdiagrams\u002Fproject-direction-workflow.excalidraw",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fdiagrams\u002Fproject-direction-workflow.svg",28968,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fdiagrams\u002Fproject-direction-workflow.svg",{"path":99,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fdirection-model.md",7302,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fdirection-model.md",{"path":103,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fepic-report.md",7621,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fepic-report.md",{"path":107,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fideation.md",5175,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fideation.md",{"path":111,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Flaunch-gate.md",27837,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Flaunch-gate.md",{"path":115,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fmilestone-synthesis.md",3893,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fmilestone-synthesis.md",{"path":119,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fopenspec-changeset.md",3675,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fopenspec-changeset.md",{"path":123,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fsubagent-template.md",6236,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fsubagent-template.md",{"path":127,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Fwork-plan-template.md",8571,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Freferences\u002Fwork-plan-template.md",{"path":131,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fepic-report-scaffold.sh","SCRIPT","脚本",8613,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Fscripts\u002Fepic-report-scaffold.sh",{"path":137,"resourceType":132,"resourceTypeDesc":133,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fspec-scan.sh",7506,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Fscripts\u002Fspec-scan.sh",{"path":141,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":142,"sourceHtmlUrl":143},"tests\u002Ffixtures\u002Fambiguous-spec-drift\u002Faction-after-confirmed-drift\u002FFIXTURE.md",2399,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Ftests\u002Ffixtures\u002Fambiguous-spec-drift\u002Faction-after-confirmed-drift\u002FFIXTURE.md",{"path":145,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":146,"sourceHtmlUrl":147},"tests\u002Ffixtures\u002Fambiguous-spec-drift\u002Fdecompose-approved-spec\u002FFIXTURE.md",2266,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Ftests\u002Ffixtures\u002Fambiguous-spec-drift\u002Fdecompose-approved-spec\u002FFIXTURE.md",{"path":149,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":150,"sourceHtmlUrl":151},"tests\u002Ffixtures\u002Fambiguous-spec-drift\u002Fread-only-audit\u002FFIXTURE.md",1720,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Ftests\u002Ffixtures\u002Fambiguous-spec-drift\u002Fread-only-audit\u002FFIXTURE.md",{"path":153,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":154,"sourceHtmlUrl":155},"tests\u002Ffixtures\u002Flaunch-gate\u002Fmissing-doctrine\u002FFIXTURE.md",1614,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Ftests\u002Ffixtures\u002Flaunch-gate\u002Fmissing-doctrine\u002FFIXTURE.md",{"path":157,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":158,"sourceHtmlUrl":159},"tests\u002Ffixtures\u002Flaunch-gate\u002Fready-to-specify\u002FFIXTURE.md",2200,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-projects\u002Fsubskills\u002Fproject-direction\u002Ftests\u002Ffixtures\u002Flaunch-gate\u002Fready-to-specify\u002FFIXTURE.md",[161,187,213,228,247,258],{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":38},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[168,169,170,171,172,173,174,175,176,177,25,178,179,180,181,182,183,184,185,186],"user run","user","run","docker","logs","use","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":188,"name":189,"nameZh":6,"description":190,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":191,"categories":192,"keywords":203,"publishedAt":38},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[193,198],{"categoryNo":194,"categoryName":195,"taxonomyType":196,"taxonomyTypeDesc":197},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":199,"categoryName":200,"taxonomyType":201,"taxonomyTypeDesc":202},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[204,205,206,207,27,208,25,209,210,173,211,212],"requesting code review","code","review","code review","requirements","upstream","superpowers","verify","tasks",{"skillNo":214,"name":215,"nameZh":6,"description":216,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":217,"categories":218,"keywords":221,"publishedAt":38},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[219,220],{"categoryNo":194,"categoryName":195,"taxonomyType":196,"taxonomyTypeDesc":197},{"categoryNo":199,"categoryName":200,"taxonomyType":201,"taxonomyTypeDesc":202},[222,205,206,207,25,209,223,210,173,224,225,226,227],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":234,"publishedAt":38},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[235,236,237,238,173,239,27,240,241,242,210,243,244,245,25,209,246,223],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":248,"name":249,"nameZh":6,"description":250,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":251,"categories":252,"keywords":253,"publishedAt":38},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[254,255,256,206,257,25,209,223,210,173,181],"plans","executing plans","plan","execute",{"skillNo":259,"name":260,"nameZh":6,"description":261,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":262,"categories":263,"keywords":264,"publishedAt":38},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[265,266,267,173,210,209,268,25,269,212,270],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]