aimship 0.0.0-stage → 0.1.0-preview.4

package/skills/aimship/references/stages/prototype.md

@@ -0,0 +1,19 @@
+# Design interaction
+
+## Basis
+
+Read current requirements, applicable design conventions and any supplied prototype or UI images.
+
+## Work and result
+
+Describe or build the relevant flow, screens, key loading/empty/error/success and permission states, feedback and responsive behavior where relevant. Link each part to its requirement. Visually inspect/operate actual HTML when claiming layout or interaction validation, with available tools.
+
+## Continue when
+
+The relevant interactions and states are clear and consistent with current requirements. A saved image or HTML source is not evidence of visual inspection.
+
+## Decisions and blockers
+
+Missing visual/browser tools require an explicit unverified scope. Resolve contradictory behavior through requirements/Scope; do not silently alter external prototypes.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/requirements.md

@@ -0,0 +1,19 @@
+# Define requirements
+
+## Basis
+
+Read the preserved original input, problem findings, adopted material and current decisions.
+
+## Work and result
+
+Write the current requirements, important rules, normal/error/boundary behavior, constraints and observable acceptance criteria. Include context and scope, not just a checklist. Link sources; external material is adopted through Scope rather than rewritten.
+
+## Continue when
+
+The requirements are adequate for the commissioned next work and material ambiguities affecting it are resolved. Reuse adequate requirements without claiming they were newly produced.
+
+## Decisions and blockers
+
+Ask for business behavior, compatibility or endpoint choices that cannot be inferred. Do not invent user acceptance.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/review.md

@@ -0,0 +1,19 @@
+# Review actual changes
+
+## Basis
+
+Read the applicable requirements, design/contract, batch or overall scope and exact change objects.
+
+## Work and result
+
+Fix the object basis before review: commit plus relevant working differences/untracked paths, or document sections and digests/old excerpts. Check consistency, defects, omissions and scope. Record findings, dispositions and reviewer source. Batch review precedes next batch; overall review checks integration after all batches. Single-batch review may cover both explicitly.
+
+## Continue when
+
+The agreed scope has actually been examined and issues blocking progression are resolved or handled by an explicit change. Keep old conclusions for their old objects.
+
+## Decisions and blockers
+
+Do not replace an agreed human review with agent review. Review cannot be reported as a running test; unrelated work need not be re-reviewed.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/scope.md

@@ -0,0 +1,19 @@
+# Align this delivery
+
+## Basis
+
+Read the user commission, current/adopted requirements, source versions and proposed engineering objects.
+
+## Work and result
+
+Record this goal, included/excluded requirements, source mappings, endpoint, authorization boundaries and acceptance. Explain external conflicts and adoption decisions. After associating or changing code scope, use the [recorded-overlap check](../core.md#independent-deliveries-and-recorded-overlap). Record actual checkout locations and read-only versus intended write scope. Agree the ordered stages based on gaps; keep stage progress only in state. Self-owned requirements may carry this information.
+
+## Continue when
+
+The goal, authority and scope are clear enough for the selected next work, with relevant decisions resolved or dependent work held.
+
+## Decisions and blockers
+
+Material conflicting sources or uncertain authority needs clarification; format differences alone do not. Never choose source priority by filename or date.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/tech-design.md

@@ -0,0 +1,19 @@
+# Design the implementation
+
+## Basis
+
+Read current requirements/Scope, relevant engineering instructions, architecture, schema and diagnosis.
+
+## Work and result
+
+Choose an approach with concrete components, dependencies, errors/recovery, compatibility and tradeoffs. Link authoritative contracts instead of duplicating them. For database changes create separate delivery-local SQL and explain dialect/version, existing schema basis, conditions and sequence. Do not edit migration files or execute SQL without that commission.
+
+## Continue when
+
+The design can guide the agreed next work and correctness-affecting issues have a clear disposition. Explain the approach and outstanding choices to the user.
+
+## Decisions and blockers
+
+Missing schema/dialect or material compatibility/data decisions block dependent design claims. An explicitly revised conceptual-design endpoint must retain these limitations.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/test-design.md

@@ -0,0 +1,19 @@
+# Design verification
+
+## Basis
+
+Read current acceptance criteria, constraints, design/contracts, independent SQL and identified risks.
+
+## Work and result
+
+Map each goal/risk to observable checks: normal behavior, relevant errors/boundaries and regression. Identify commands/tools, environment, accounts/data and authorization needs. Preserve checks whose conditions are absent; distinguish what must be verified from what can run now.
+
+## Continue when
+
+The goal and material risks have appropriate checks and missing execution conditions are explicit. Simple checklists may share a later report.
+
+## Decisions and blockers
+
+Missing tools or execution authority do not justify deleting a valid case. Clarify acceptance omissions through current requirements rather than measuring only test count.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.

package/skills/aimship/references/stages/verify.md

@@ -0,0 +1,19 @@
+# Execute verification
+
+## Basis
+
+Read current acceptance criteria, the verification plan, actual reviewed results and execution conditions.
+
+## Work and result
+
+Execute the agreed checks on identified objects. Preserve commands/operations, environment/data, expected assertions, actual results and sufficient evidence. Separate pass/fail/not-run/unknown. On defects repair the affected implementation, review the repair, then retest affected cases; append the new result and retain the old failure.
+
+## Continue when
+
+The agreed execution work is accounted for with traceable results. This run can end with failure or gaps; that does not make the development goal met.
+
+## Decisions and blockers
+
+Unavailable environment or authority stays explicit with a recovery action. Do not lower criteria, skip assertions or mark a case passed because a command exited successfully.
+
+Use [the shared core](../core.md) for state, evidence and continuation rules. Record meaningful results in an artifact or referenced section; a file alone is not completion.