plastic-continuing

Continuing

plastic-continuing continues work. It presents the latest state via the dashboard and offers choices, then stops. It does NOT execute work autonomously (that is plastic-auto) and does NOT render the dashboard itself (it only invokes it).

Boot is not this skill's job. The hook-session-start hook already runs by construction on every session start: it runs the core health check (doctor --core), primes PLASTIC.md + store/project state, and prints the Plastic Core loaded — v{version} banner. The plastic-statusline hook sets the statusline. So by the time this skill runs, core is loaded and healthy (or the banner already warned otherwise). This skill picks up from there and continues work. This is the seam future continue-flags build on (see [[39]]).

When to Use

• UserPromptSubmit hook detects "continue" (automatic)
• User says "continue", "resume", or "pick up where we left off"
• Starting a new session and you want to resume work with the latest context

Determine Store

1. Global store — ~/.plastic/INDEX.md exists → global mode.
2. Local store — a project store under ~/.plastic/projects/{slug}/ whose registered path (in ~/.plastic/projects.yml) matches the current working directory → project mode. The SessionStart hook already detects this; here you only need the slug to scope the dashboard.
3. If neither exists → announce "No Plastic store found. Run /plastic-install."

Continue (present the dashboard)

Land on the Markdown board via the plastic-dashboard skill. Rendering belongs there, not here — run the data payload and fill + present the matching template:

• Project loaded → ruby ~/.plastic/scripts/dashboard.rb project <slug> --data
• Otherwise → ruby ~/.plastic/scripts/dashboard.rb continue --data

Fill the matching template from this skill's templates/ and present the filled Markdown in your reply (every time). See plastic-dashboard for the fill rules and entry flow.

The board load runs the scoped store check on every load (doctor --store <scope>): the global board runs --store global and a project board runs --store <slug>. The result arrives in the payload as store_health; surface it as a one-line store-health note. It is non-fatal (a warn or fail is shown as data, it does not block continuing).

Then stop

Present "here is the state, what next?" and wait. Offer active intents first, then future intents. Do not start executing work. The branches below are the only follow-ups:

• User/agent names a specific intent to continue → Conditional ledger-resume (below).
• User says "auto" / an agent is instructed to deliver → hand to plastic-auto.

Conditional Ledger-Resume

Fires ONLY when the user explicitly asks to continue a SPECIFIC intent, or an agent is instructed to continue one. It is not part of every boot. For that intent's directory:

1. Read savepoint.md. It is a deterministic, append-only stage ledger (one line per milestone, newest at the bottom): {utc-iso8601} {Stage} {milestone}. The last line = current stage.
2. Verify the stage file. Confirm the file the ledger names exists and is non-empty (ledger How plan.md created → plan.md must be present and non-empty).
3. Drift handling. If the ledger's last line disagrees with files-on-disk, rebuild the ledger from filesystem state and note the correction:

   ruby -r ~/.plastic/scripts/lib/bridge -e 'Bridge.rebuild_savepoint("<intent_dir>")'
   

4. Derive the next step:
   • First unchecked item in checklist.md if it exists, else
   • "advance to the next lifecycle stage" (e.g. ledger shows Why/spec.md → next is How).
   • The newest ## Insights entry supplies human-readable context (Insights are append-only, newest at the bottom).
5. Announce and stop:

   Resuming intent [ID] — [name]
   Store: [global | project:<slug> | local]
   Stage: [from ledger last line]
   Next step: [first unchecked checklist item | advance to <stage>]
   Context: [newest ## Insights entry]
   Drift: [none | ledger rebuilt from filesystem]
   

   Then proceed with the next step. Autonomy is plastic-auto's job — if the intent's ## Insights contains (autonomous) entries, it was being delivered autonomously; hand to plastic-auto to continue from the current stage.

Priority Order

1. Active intents first — surface work in progress.
2. Project context — if in a registered project, show governing + tactical intents.
3. Stale future intents — surface for triage (see below).
4. Fresh future intents — offer as next work.

Stale Future Intents

If a future intent's created date is older than the configured stale_threshold_days (default 3), surface it for triage without taking action:

Stale future intents (no action taken):

- [ID — name] (X days old)
  a) Activate — start working on it now
  b) Abandon — mark as abandoned
  c) Defer to agent: implement | research | ideate
  d) Auto — go fully autonomous (invokes plastic-auto)

When the user activates a future intent, move it to ## Active in INDEX.md and auto-commit.

References

• Read references/context-management.md for the full save/continue protocol and for debugging the resume flow.