SF ShipGlows
Menu Open navigation menu Close navigation menu

ShipGlows Blog

How to keep your project pitches current for ShipGlows

A short refresh at the right time is enough to keep your project corpus usable for ShipGlows.

2026-07-08 5 min governance / projects / pitches / workflow

Once a project has been introduced into ShipGlows, keep its pitch current. If the fiche grows stale, the system ends up reasoning from an outdated version of the project.

The goal is not to rewrite the whole presentation every time. The goal is to keep a simple reference card that stays unambiguous about:

  • what the project is
  • who it is for
  • what problem it solves
  • what angle it takes
  • where the source of truth lives

Why the refresh matters

Projects change quickly. A first pitch version can work at launch, but it becomes incomplete as soon as the product, audience, or positioning moves.

When you keep the pitch current, ShipGlows can:

  • classify the project more accurately
  • avoid reasoning from an outdated version
  • recognize useful overlaps between projects
  • propose better routes for sources, emails, or content ideas

What to update

A good project pitch fits into a few elements:

  1. project name
  2. reference URL
  3. audience
  4. business angle
  5. internal framing note
  6. status

That format is intentionally short. It carries enough information without bloating the fiche.

When to refresh

Refresh the pitch when:

  • the audience changed
  • the product promise changed
  • the angle changed
  • the file is a few months old
  • ShipGlows still seems to reason from the older version

In that case, do not rewrite everything. Update the existing fiche.

The simple principle

A well-kept project corpus means:

  • one pitch per project
  • one current version
  • one explicit source of truth
  • one refresh when the project evolves

With that in place, ShipGlows does not need to guess. It can classify, compare, and route against a clean base.

Read Next

Keep the editorial thread going.

Why ShipGlows should be fed with project pitches

ShipGlows understands your project corpus better when each project has a short pitch that is easy to update.

Open article

Why ShipGlows should not rush global primitives for profiles and tags

Global primitives look elegant, but they hard-freeze semantics, debugging posture, and runtime obligations earlier than ShipGlows can safely support.

Open article

Why ShipGlows keeps public code and private data in separate repositories

ShipGlows separates framework code from durable private operator data so versioning, backups, and privacy boundaries stay coherent.

Open article