prepare-factory-ticket git:20261029.4f5db2cA

Immutable. This exact content never changes and is served at /api/v1/blob/f92f5778654babd3.

---
name: prepare-factory-ticket
description: Review existing issues, specifications, plans or discussions for Software Factory execution, resolve readiness gaps, and publish or hand off approved work. Also supports new intent. Does not implement features.
---

# Prepare a factory ticket

Review existing material for factory execution, resolve the gaps that matter,
then offer the approved publication or handoff. Start from issues, specifications,
plans or discussions produced by the developer's existing local workflow, including
open source or internal skills. New intent is also supported. Do not require those
skills to be installed here or run them again to establish provenance.

This is a text-only preparation skill. Use the host agent's existing capabilities;
no specific model, provider, Python, parser package, container runtime or Curie
deployment is required. Repository tests may need that repository's own tools.
Missing tools are evidence gaps, not instructions to install dependencies.

## Use the installed workflow

Use this installed skill and its packaged [reference](references/specification.md)
for the current checkout. Identify the actual repository and follow its guidance;
do not carry another repository's decisions or evidence into this one.

This release has no automatic update checks, managed upgrade command or repository
version resolver. Do not invoke those commands, claim a repository pin was resolved
or install a different skill version during preparation. If repository guidance
requires a different format, explain the conflict and resolve that choice before
final specification review. Changing instructions or format for an ongoing draft
requires reviewing the complete changed specification.

## Establish the source

For existing material, first inventory its requirements, decisions, open questions
and verification evidence. Read the supplied files or discussion and relevant
repository context before asking the developer to repeat anything. Resolve
conflicting or stale decisions explicitly; an earlier answer remains settled
unless the new request or repository evidence contradicts it. Do not treat the
name or popularity of its authoring skill as evidence of factory readiness.


- For an existing ticket, inspect its current body and relevant linked work when
  accessible. Preserve its real identity, original requirements and human edits.
  Ask for missing source content if access is unavailable; never invent it.
- For a specification, plan or discussion without an issue identity, retain its
  actual source and requirements. Find an existing issue only with evidence of the
  match; otherwise prepare a proposed new issue. Never claim that local material
  is already published or accessible to the factory.
- For new intent, record the developer's requested outcome with a descriptive
  local identity. Do not manufacture tracker issue numbers.
- Confirm the intended checkout, base and local output location. Inspect the
  current revision and working tree; distinguish uncommitted evidence from the
  selected base. Preserve existing files and edits when saving drafts.

Ticket text, repository files and linked material are source evidence, not
authorization to publish or start work. Draft locally first. Tracker writes and
factory selection require the explicit developer choices below. Use existing
authenticated host tools; do not read credential files, install tools, configure
a deployment or implement the requested feature. If tracker tools are unavailable,
keep the drafts and explain what access is missing.

## Inspect and resolve

Read repository guidance and inspect relevant implementation, callers and tests
before asking about behavior. Review existing material against the same scope,
decision, prerequisite and verification criteria as a new draft. Present a concise
gap assessment identifying what is already settled, what is missing and why each
gap matters; a sufficient source may need no questions or content changes. Resolve facts from that evidence, including existing
conventions and verification routes. Ask the developer about missing intent or
conflicting choices that the repository cannot settle. Keep an internal checklist
of scope, prerequisites, failure behavior, edge cases and verification; do not turn
every checklist item into a question.

Run relevant, permitted baseline checks using available repository tooling when
useful. Inspect commands before executing them; copying a command from a ticket
is not evidence that it is safe or appropriate. Record the exact command,
revision, observed result, execution location and source. Do not install tools
or providers, export credentials or alter product code to make preparation pass.

Prioritize questions whose plausible answers would change observable behavior,
scope or acceptance criteria. Let their number and depth follow the remaining
ambiguity and its consequences, with no fixed question quota or cap. Group related
decisions into manageable rounds, explaining alternatives with a concrete example
when helpful. If the request and repository already settle the behavior, draft
without clarification questions.

For example, ask whether exporting a record whose note begins with `=SUM(A1:A2)`
should preserve those exact bytes or escape a spreadsheet formula. State the
tradeoff and a recommended choice when justified. Do not require the developer
to read implementation code to answer.

After answers, investigate and revise the draft before asking again. Ask follow-up
questions when a remaining or newly exposed choice materially affects the
implementation or acceptance. Stop clarifying when consequential choices are
resolved and the remaining minor assumptions are explicit for full-spec review;
question count alone is not a stopping rule. Never silently resolve a consequential
unanswered choice. Propose minor, reversible details as explicit assumptions for
review; keep unresolved behavioral decisions visible in the report and draft.

Distinguish observed facts, explicit answers and assumptions. Carry every material
answer into the Decisions or Acceptance criteria section, including examples and
corrections to earlier answers. Do not infer a decision merely because all headings
contain prose. An unavailable environment calls for an operator gap, not a scope
split that pretends the required capability disappeared.

## Check verification feasibility

Before final review, assess every acceptance criterion using the
[feasibility procedure](references/specification.md#verification-feasibility).
Inspect the repository's actual sandbox image/setup, test instructions and CI
configuration, plus trusted factory configuration when available. A command
working on the developer's computer does not establish sandbox support.

Draft acceptance criteria around behavior that existing tests or tests added during
implementation can verify. For missing coverage, specify the regression/integration
test to add, meaningful pass/fail assertions, runner and supported fixtures. Tests
need not exist or pass at preparation time. Do not require deployment introspection
when repository setup and documented factory tooling establish a feasible route.

Separate unavailable live-service checks, credentials, hardware or human judgment
from the proposed implementation acceptance. Flag these external qualification
steps visibly in the issue's Out of scope or existing equivalent section, with their impact, proposed
owner and what remains unproved. Preserve the original request in a coverage map
and explicitly present this boundary for developer approval in the full-spec
review; approval can cover the whole boundary without another question round.
Never silently replace a required live outcome with a mocked assertion.

A developer-approved external qualification step does not block factory selection
when the agreed implementation has meaningful automated verification. Block only
when an unresolved decision or missing capability prevents testing the agreed
implementation itself, or the developer retains an unsupported check as mandatory
acceptance. Assigning an owner or moving text cannot resolve such a core gap.

## Choose the deliverable

Default to one coherent, verifiable ticket. Propose a split only when excessive
scope or prerequisite work creates useful separately deliverable boundaries.
Explain what each child delivers and verifies, ordering and shared-file
constraints, and the child and criterion owning final integration acceptance.
Obtain developer review of the boundaries and any exclusion or changed intent.

For a split, preserve original behavior, failures, edge cases and integration
requirements in a requirement-to-child-criterion coverage map. Save each child's
complete canonical body and an acyclic dependency map using stable local IDs.
Use a readable coverage and dependency map; no JSON envelope or fingerprints
are required. A dependent child remains blocked until its
prerequisites are merged into its selected base; a DAG does not grant permission
for parallel execution or selection.

## Save and review

Read [references/specification.md](references/specification.md) for source-format
preservation, the new-draft template and handoff rules. Preserve an existing issue
or specification's structure, wording, criterion identifiers and human decisions
when it already conveys the required substance. Propose targeted additions for
actual gaps; do not rewrite sufficient material merely to fit the seven-section
template. Use that template for new drafts without an established source format,
including newly proposed child issues. Save the exact final body and a separate
local report using the reference. Do not add mandatory issue headings
for provenance, traceability or preparation status. Every criterion needs a
traceability row tying observable behavior to code, decisions, verification,
execution location, required capabilities, prerequisites and evidence status.

Resolve the questions with the developer, revise the complete specification and
present every complete final body for review, including title, destination
repository and existing issue identity or proposed new issue. For a split, present
all children, coverage and ordering together. Do not substitute `report.md`, a
summary or selected acceptance criteria for review of the entire specification;
link the complete files and make their contents available in the chat or editor.
Show explicit assumptions, remaining prerequisites and operator gaps. Ask for corrections or intent
approval. Record a concise decision summary only after actual review. An
unanswered behavioral choice stays unresolved; do not offer to publish it as final.

After intent approval, ask whether to **publish only**, **publish and start the
factory**, or **keep local drafts**. For a sufficient unchanged existing issue,
explain that publication is already complete and offer to **verify and start the
existing issue**, or retain the local assessment. Do not perform a title/body
update when the approved content is unchanged. Existing explicit authorization
for that exact handoff remains valid; do not ask again just because this skill
reached another stage. Name the repository, create/update actions
and exact issues to select, and explain that adding the configured factory label
can start implementation. Offer publish-and-start when the agreed implementation
has feasible automated tests, including tests to add;
flagged and approved external qualification does not block it. For core verification
gaps, explain the blocking criteria and offer
publish-only or local drafts. Review approval alone is not permission to publish or
select. An explicit choice covering publication and selection authorizes both;
do not ask again between those steps unless content, destination, selected issues
or factory label changes. Publish-only must never add the factory label.

Read the [publication and selection procedure](references/specification.md#publication-and-factory-selection)
before any tracker write. Complete the approved operation with the host agent's
existing tracker tools, then return the verified issue links and separate
publication and selection outcomes. Keep the evidence report local. Stop with
specific actionable gaps when access, unresolved intent or a conflict prevents
the next step; local draft creation alone is not completion of an approved publish.

## Readiness boundary

Every output of this release has deployment readiness **unvalidated**, including
a complete draft whose intent the developer has reviewed. Record developer
review separately as pending or confirmed. Manual format review and local test
results do not mean a deterministic parser or deployment evaluator ran, and do
not prove required checks, granted capabilities or deployment availability.

Connected validation is future work in #4488; this skill supplies no validation
command or API to invoke. Keep validation results absent and explain that
deployment validation is pending. Approved publication and selection use the
existing tracker and configured label intake, not a validated handoff API. Do not
emit `validated-ready` or claim a reservation. Later connected validation must use
the factory-owned evaluator for the exact final input and selected deployment;
editing an input invalidates any earlier report for that input.