Project Development

Use the requested stages of the author's development workflow. Read only the stage guidance and dependencies needed for the current task.

Language modes

Use this English entrypoint and the English guides under references/ as the shared operating instructions for both output modes. Traditional Chinese guide and references/zh-TW/ are human-readable translations, not a separately installed skill. Do not load both editions by default.

• Resolve output_language from the user's explicit choice for the current work, then the project's recorded preference, then the default zh-TW. Supported modes are Traditional Chinese (zh-TW) and English (en). Carry an explicit selection forward until the user changes it; support another requested language without overriding the user.
• Follow the English operating instructions for analysis and checks. This specifies instruction language, not a guarantee about private reasoning language. Do not request or expose private chain of thought; deliver conclusions, evidence, assumptions and verification results.
• Apply the selected language to replies, profile summaries, analysis/design/planning documents, review records, diagram explanations and visible HTML controls. Preserve code identifiers, API/DB fields, commands, paths and verbatim source quotations. Code comments follow the project's conventions unless the user requests translation.
• Record an explicitly chosen persistent project preference in its context document. Do not infer a project-wide preference from one translated quotation. Do not translate all existing project documents or create a second work document just because the output mode changes.
• Use Chinese HTML template for zh-TW and English HTML template for en; they share the same data schema and behavior. Replace example content in the selected language.
• Maintain both documentation editions when changing workflow requirements. English is the maintained execution edition; resolve translation discrepancies against it without introducing a different workflow.

Examples: "Use project-development with English output"; "使用 project-development，輸出用繁體中文".

Integrate project context first

On first entry, follow project context to create or refresh a project-local profile: architecture, module conventions, data and interfaces, requirements/document units, development and delivery flow, verification and tool dependencies. Subsequent stages use that profile and its primary sources to preserve the user's development logic.

Reuse an existing profile and check only relevant rules and changes. Context integration permits reading and documentation, not product construction or external actions. Missing unrelated information does not block the requested stage.

Stages

Add further delivery stages only when needed and confirmed; do not create empty workflows or assumed policies.

Build implementation diagrams, including file walkthrough progress, from the selected language template using architecture diagram. For repeated inventory, coverage, structure and local-link checks, use automation when needed; scripts cannot replace requirements or semantic code review.

Selection and handoffs

• Analysis-only requests use issue-analysis; construction requests use project-scaffold with sufficient requirements/architecture evidence.
• Continue across stages within existing authorization. Completing one stage does not independently authorize the next, and prior authorization does not need to be requested again.
• Requests to understand or discuss a design stay in explanation/proposal mode. Do not infer construction permission from a discussion or preview.
• Unresolved choices affecting the framework, core model, permissions or writes block their dependent work, not independent work.
• Reuse the real framework and upgrade mechanism in existing projects. Evaluate frameworks for new projects; this skill does not imply rebuilding, adding tables or expanding scope.
• Document units follow project context. An issue-based project may use one document per issue, updated throughout the work. A guide's "issue/work document" means the current project's chosen unit; do not impose another project's platform, numbering or directory.
• Reuse confirmed unchanged design; do not reanalyze the whole issue or demand every preceding artifact at each stage.
• Maintain requirements → design/tasks → implementation locations → acceptance cases/results in the original work document. Each in-scope requirement has a destination; each change has a requirement or necessary technical basis. Address omissions and scope drift without inventing requirements.
• Shared checks are defined in the relevant guide and referenced elsewhere. Keep responsibility, authorization and links consistent. Design confirmed, code written, tests passed and ready to publish are different states.

Examples: use issue-analysis for #101; use project-scaffold to build the modules and migration files needed by confirmed requirements.

Locate this skill's scripts and assets from its actual loaded directory, not a fixed .claude/skills path. See README for packaging and evaluation.