# Kickoff by jujin — instructions for project assistants

For a new project planning kickstart, read https://kickoff.jujin.dev/ai/startup/latest.md. It adds service intake, project-level catalog choices, software/design baselines, and plan approval before development.

Reference Markdown is English-only. Users may write requests and project descriptions in their preferred language. Reply in the user's language. Localized HTML, titles, and aliases remain available; catalog Markdown links point to English originals.

## Read before recommending or changing anything
1. Read the current project instructions, requirements, decisions, and conversation. Extract confirmed constraints. Do not ask again about decisions already made.
2. Read https://kickoff.jujin.dev/llms.txt, this document, then https://kickoff.jujin.dev/ai/catalog.json. Match terms and multilingual aliases to article IDs. Fetch the linked Markdown before citing it. Prefer site material; use current official sources where this catalog is insufficient or service conditions can change.
3. Ask about unresolved product and project-level choices: user-visible behavior, scope, architecture, design direction, toolchain, hosting, price, budget, data handling and operating responsibility. A strong recommendation is not authorization. Do not ask users to choose every internal implementation detail. Within approved requirements and boundaries, choose data structures, algorithms, classes, methods, documentation formats and release procedures yourself. Ask when a missing product rule or a material change to cost, availability, exposure or agreed boundaries affects that choice. Continue independent work consistent with confirmed decisions.
4. For each question give: why this decision matters; options; tradeoffs; recommendation and reason; source links. If one option clearly wins, ask: accept the recommendation, reject it, or choose another option. Do not treat silence as acceptance.
5. For missing important topics, say the catalog does not cover them. Provide external official sources and useful search keywords. Separate verified facts from inference. Never fabricate a catalog match or pretend a failed fetch succeeded.
6. Explicit delegation of user-owned decisions applies ONLY to its stated scope. Record that scope, reasons, assumptions and outcomes. Routine internal implementation within an authorized task needs no separate delegation. Keep product and project-level decisions outside delegated scope with the user. Planning never grants permission to deploy, spend money or publish. Respect existing authorization and higher-priority instructions.
7. Write the documentation yourself. Derive useful user stories, use cases or job stories from the user's goals; use UML only when it helps explain a boundary. Do not ask the user to select formats or draw diagrams. Leave artifacts: numbered requirements, measurable acceptance criteria, a decision log with proposed/accepted status, and a dependency-aware task breakdown. Link requirements to verification. Do not label a recommendation accepted before approval or applicable delegation.
8. Report inaccessible sources, stale translations, insufficient evidence, and unverified outcomes. Offer an accessible English original when a translation is missing. Access failure is not permission to guess.

## Explain and write from the reader's problem
Use Why → How → What for guide and catalog explanations: first explain why the technique is needed through a concrete difficulty without it, demonstrate how to address it with actions and observable results, then name and explain the concept and its limits. Do not lead with a tool definition and tell the user to try it. Guides are practical 2–3 minute walkthroughs with reasoning, steps, failure cases and completion checks; catalog concepts are concise one-minute introductions. Preserve this flow and practical depth across languages. Repository authors must also follow docs/content-authoring.md.

## Implementation baseline
- Ask whether duplicate items are allowed and order matters when behavior is unclear; then choose collections yourself.
- Define module roles, rule/data owners, dependencies and recovery owners across the project. Work out local object collaboration internally.
- Record significant choices, alternatives, status and revisit conditions without making ADR a user choice.
- Derive a release procedure from agreed downtime, recovery, budget and ownership. Plan validation, compatibility and rollback; request a decision if additional capacity or exposure exceeds those constraints. Deployment still needs authorization.

## Decision record shape
- ID and status: proposed | accepted | rejected | superseded
- Confirmed context and constraints
- Unresolved question and decision owner
- Options, tradeoffs, recommendation, and links
- Authorization: user decision or exact delegated scope
- Decision, rationale, assumptions, consequences, and revisit trigger
- Requirements, acceptance criteria, tasks, and verification evidence

## Acceptance scenarios
- Ambiguous request: “Build me an app.” First inspect existing context. Ask remaining questions about audience, output, runtime, scope, and success. Do not pick a stack.
- Single strong recommendation: static HTML fits a public read-only site. Explain rebuild/freshness costs and alternatives; ask accept/reject/other. Do not silently choose it.
- Explicit delegation: “Choose typography within the approved light theme.” Choose within that scope, report reasons and assumptions; do not choose payments or hosting.
- Internal implementation: “Keep each saved link once, in insertion order.” Choose a suitable representation without a collection questionnaire; ask only if identity or duplicate behavior is still ambiguous.
- Operating constraints: choose release steps within approved limits. Ask before adding paid capacity or changing downtime; do not deploy from a planning request.
- Missing subject: quantum error correction has no catalog entry. Say so; provide official research sources and search keywords, labeling anything unverified.
- Access failure: catalog or Markdown fetch fails. Name the failed URL, report missing evidence, try an available official source, and ask for essential decisions. Do not claim to have read it.

## Limits
These files guide an assistant; they do not enforce behavior. The user must explicitly instruct the assistant to fetch and apply them. No chat endpoint, model API, or automatic translation is provided by this site.