shipmyidea

name

shipmyidea

description

Turn a product or feature idea into working software while deriving applicable engineering guards before code, implementing complete vertical journeys, and producing fresh local evidence. Use for greenfield apps, MVPs, prototypes intended to become real products, and substantial end-to-end features in existing repositories. Trigger for requests such as build my app, turn this idea into code, implement this feature completely, make this MVP, vibe-code this properly, 把想法落地, 从零做一个, 做成能用的产品, or equivalent implementation intent. Do not use for explanation-only, review-only, tiny isolated edits, or independent release verdicts.

ShipMyIdea

Turn the user's desired outcome into a bounded, working product increment. Infer routine engineering obligations yourself; do not make the user know which guards to request.

Read references/build-contract.md and references/guard-selection.md for every build. Load only the guard references selected by the actual effect surfaces:

• Read references/guards-frontend.md for browser state, forms, components, Hooks, subscriptions, timers, or other client lifecycle work.
• Read references/guards-backend-data.md for APIs, authentication, authorization, durable state, queues, migrations, webhooks, payments, or other server-side effects.
• Read references/guards-agent-tools.md for LLM, RAG, memory, agent, tool-calling, approval, or autonomous side-effect behavior.

Use scripts/build_contract.py to validate the generated build contract and obtain the completion summary.

Invariants

1. Treat the user's idea as the product outcome, not as a complete technical specification. Infer ordinary implementation details and guards from the artifact and its effects.
2. Ask only when an answer would materially change product behavior, irreversible effects, the data model, identity or permission boundaries, cost, or an external commitment. Consolidate necessary questions once; otherwise state a reversible assumption and continue.
3. Derive applicable guards and their failure checks before writing the code they govern. Never invent them after implementation merely to justify what was built.
4. Map every planned and newly created effect surface to at least one guard, or record a concrete not-applicable reason. Keyword search is not proof of structural coverage.
5. Complete one vertical user journey at a time. A file existing, a component rendering, or a happy-path test passing is not completion when the journey's applicable failure behavior remains unprotected.
6. Bind evidence to the exact candidate. Any later code change makes earlier evidence stale until the affected checks run again.
7. Let the builder report only derived, implemented, locally-evidenced, or blocked. Never let it declare its own work independently verified, production-ready, or safe to launch.
8. Keep the current milestone bounded. Do not add fashionable architecture, infrastructure, or guards without an effect that requires them.
9. Preserve user authority. Do not deploy, charge money, message people, delete durable data, weaken access controls, or mutate an unrelated external system unless the request authorizes that action.
10. Keep the contract and evidence safe to share. Never copy credentials, tokens, raw private content, or unnecessary personal data into either one; record redacted structural facts and reproducible locators instead.

Workflow

1. Resolve the outcome and workspace

Determine whether this is a greenfield build or a feature in an existing product. Inspect the available project, its conventions, supported runtime, and current behavior before choosing an implementation. When starting from only an idea, create the smallest coherent project that can exercise its critical journey rather than an architecture for hypothetical scale.

Write the current milestone as one product promise and one to three critical journeys. Record necessary assumptions and explicit non-goals. Infer the working stakes from the request and artifact: controlled demo, real users, money or sensitive data, or consequential autonomous effects. Ask once only if an unresolved choice changes the safe design; do not ask the user whether standard cleanup, validation, ownership, or retry guards should exist.

2. Create the build contract before implementation

Create or update .shipmyidea/build-contract.json according to references/build-contract.md. Inventory planned effect surfaces structurally — for example every state-changing route, persistent write path, effectful Hook, subscription, or registered Agent tool — and assign stable S-### identifiers.

For each applicable risk, create a G-### guard before its governed code is written. State:

• the invariant it protects;
• the exact surface and consequence that triggered it;
• the intended enforcement point;
• one falsifiable failure check;
• its current lifecycle status.

Keep routine mechanics internal. Show the contract to the user only when a product decision or blocker needs their input.

3. Establish chokepoints, then build vertically

Prefer one enforcement point over repeated caller discipline: a server-side ownership predicate, schema constraint, idempotent command boundary, shared async lifecycle helper, typed tool dispatcher, or canonical source of truth. Build the smallest end-to-end journey through that boundary, including its relevant failure and recovery state.

Follow the repository's existing conventions unless they violate a recorded invariant. Avoid unrelated refactors. Add or update tests alongside the behavior rather than after the milestone has expanded.

4. Reconcile the code with the plan after every batch

Re-inventory the actual code after each coherent edit batch. Add newly introduced surfaces and derive any guards they trigger. Never silently remove a planned surface or downgrade a guard because the implementation made it inconvenient. Mark an inapplicable surface only with a concrete reason tied to the current artifact.

When a repeated mechanism is required, enumerate the structural population — router registry, tool registry, schema tables, exported effectful Hooks, or another code-defined set — instead of counting one spelling of the symptom. If no reliable population exists, say coverage is unknown rather than claiming completeness.

5. Produce fresh local evidence

Run the narrow failure check for every guard, then the repository's relevant deterministic checks and the critical journey when safely runnable. Prefer observable outcomes: exit status, response and durable state, browser behavior, test result, log, or trace. A code diff or test file existing is not passing evidence.

Before marking a runtime check unavailable, try the repository's configured harness and safe capabilities already present on the host. For browser journeys, this includes an existing browser-control surface or installed browser executable with a temporary profile outside candidate scope. Do not install new tooling solely to manufacture evidence.

Freeze the candidate identity only after the batch is complete. Attach every evidence record to that identity and update a guard to locally-evidenced only when its current failure check passes. Leave unavailable proof blocked; do not manufacture a green result.

Validate the contract:

python3 <skill-directory>/scripts/build_contract.py validate .shipmyidea/build-contract.json

Do not call the milestone locally complete while the summary reports candidate_frozen: false, an unmapped surface, open guard, unproven guard, or stale evidence.

6. Challenge the frozen candidate

When an independent agent or fresh context is available, give it the original product promise and frozen candidate first. Have it derive the relevant risks independently before showing it the builder's guard list, then compare the two sets and exercise any omitted critical path. This reduces anchoring on the builder's own classification.

If an independent reviewer finds a missed applicable guard, reopen the contract, implement one bounded repair batch, freeze a new candidate, and rerun affected evidence. Do not recurse indefinitely: after two materially different failed attempts at the same guard, name the blocker and the smallest decision or evidence needed to proceed.

Use RateMyCode as an optional separate release audit when it is available and the user requests a ship/no-ship judgment. ShipMyIdea may prepare and repair a candidate; it never substitutes its own local checks for that independent verdict.

7. Deliver the outcome

Lead with what now works. Name the critical journey exercised, the exact checks that passed, and any remaining blocked or locally unverified guard. Keep implementation bookkeeping out of the user's way unless it changes what they can safely do next.

Say locally evidenced for builder-produced proof. Say independently verified only when a genuinely independent pass ran against the same frozen candidate. Never claim public-launch readiness from repository checks alone.

Resource index

• references/build-contract.md — canonical lightweight contract, status rules, candidate identity, evidence, and stop conditions.
• references/guard-selection.md — effect-surface inventory, structural coverage, two-pass guard selection, and reference routing.
• references/guards-frontend.md — frontend, browser, form, Hook, and async-lifecycle guards.
• references/guards-backend-data.md — API, identity, durable-state, concurrency, migration, and external-effect guards.
• references/guards-agent-tools.md — Agent, LLM, RAG, memory, tool, approval, retry, and eval guards.
• scripts/build_contract.py — deterministic build-contract validator and machine-readable completion summary.