Listen to the request in the user's own words. Do not write spec.md. Do not implement.
Classify the request as a change, research-only, or assessment-only before allocating a number. If the request is too vague or ambiguous to classify, ask the user using the host interactive ask pattern (capped at three focused questions in that pass).
If the request is purely investigative ("pesquise", "investigue") or evaluative ("avalie", "audite") and does not describe a desired state change in the system, route the request to fast-track-ai-research or fast-track-ai-assess as a direct call. Create no track directory and no intent.md. Stop there.
For a change request, find the next free number under fast-track-ai/tracks/ in the target repo. Format NNN-slug, kebab-case slug of what was asked.
If the change request is too vague to draft an intent, ask the user using the host interactive ask pattern. Cap: three focused questions in that pass. Each question must explain why it matters and which decision it unlocks. Write answers into the intent body, not as disconnected conversation. Leave unresolved items under Open questions. Do not run an unbounded grill. If already decided, skip the questions.
Check for autonomous artifact triggers before drafting. Inform the user in one sentence before each invocation; do not ask permission. Invoke research and assessment triggers as an auxiliary step for change requests only:
- Research: a scope, design, or acceptance decision in the intent depends on an external fact (version behavior, API contract, configuration, limit, license, or price) that is not verified in the repository or in sources already read in this session. Familiarity with a technology does not waive the trigger when the decision depends on such a fact. Invoke fast-track-ai-research as an auxiliary step and cite the research slug in research:.
- Ref: the user supplies a URL, document, or external code snippet that materially grounds the intent. Capture it at fast-track-ai/refs/<slug>.md from ./assets/ref.md and cite the slug in refs:. The ref template is a shape; these capture rules live here:
  - Maximum size of the entire ref file, including frontmatter, headings, and notes: 500 KB. type, captured, owner, sha256, and content_license are required for both types. content_license is the source-content license, or unknown when no explicit license is available.
  - Write only the body section for the chosen type: keep ## Source content for an inline ref and delete ## Locator; keep ## Locator for a pointer ref and delete ## Source content.
  - inline: omit source, pin, and retrieved_at. Store the exact redistributable source after ## Source content. Normalize it to UTF-8 with LF line endings and exactly one terminal LF. sha256 covers only those normalized source bytes observed at capture time, not frontmatter, headings, or capture notes. Use inline only for redistributable normalized text that fits within the whole-file limit.
  - pointer: require a canonical source. Use pin when the upstream exposes an immutable version, release, commit, or content identifier; otherwise replace pin with retrieved_at: YYYY-MM-DDTHH:MM:SSZ. sha256 covers the source payload actually observed at capture time, never the URL, path, locator text, or this Markdown file. Use pointer for large, binary, stable-upstream, restricted, or unknown-license content.
  - Before writing, compare the hash with existing refs so duplicate content reuses the existing slug and file instead of creating a duplicate. Source identity is immutable: changed source bytes require a new ref, while schema-only metadata may be enriched without changing source identity or hash.
  - If the source cannot be retrieved or supplied after one direct request, create no ref or synthetic hash and do not hash a URL or locator stub as if it were source content; record the missing basis under Open questions or Assumed state.
- ADR: an answer to a clarifying question meets the qualifying criteria (durable, costly to reverse, surprising without context, or resolves a meaningful trade-off). Create the next numbered fast-track-ai/decisions/<NNN-slug>.md from ../fast-track-ai-spec/assets/decisions.md and cite its slug in the intent decisions: list. Cite supporting refs, research, or assessments when available. Do not create an ADR for a local, easily reversible, or obvious implementation choice.
- Assessment: the intended change depends on the current condition of a system you can inspect. Run the fast-track-ai-assess skill as an auxiliary step and cite the assessment slug in assessments:.
Draft fast-track-ai/tracks/NNN-slug/intent.md from ./assets/intent.md bundled in this skill. Fill Assumed state by provenance, placing each premise in exactly one list: Stated by the user for facts the user asserted, Unverified assumptions for premises adopted without checking, and Access limits for sources or systems you could not reach. Do not present an unverified assumption as a stated fact. Reference external research by slug in research:. Cite inward evaluations from fast-track-ai/assessments/ in assessments:, never in research:. Cite Architecture Decision Records from fast-track-ai/decisions/ in decisions:.
Regenerate fast-track-ai/INDEX.md with ../fast-track-ai-init/scripts/fast-track-ai-index.sh <target> using the owner copy and report any validation error instead of presenting the summary as complete.
Present a post-phase summary. Format:

fast-track-ai-intent