remote-sprite-development

Files (1)

• SKILL.md

SKILL.md (first lines)

# Remote Sprite Development for Software Factory Profiles

## Overview

This skill is the production Software Factory contract for developing on an existing remote Sprite. It turns a PM intent into bounded builder/reviewer work that happens on the named target Sprite, not in the Kanban scratch workspace.

The central rule is locality: `$HERMES_KANBAN_WORKSPACE` is orchestration scratch. It is not the authoritative application source unless a task explicitly says it is an analysis-only checkout. All app inspection, edits, installs, builds, tests, runtime checks, checkpointing, and rollback validation must be performed on the target Sprite by explicit remote commands.

## Interim Decision: sprite exec Is Allowed Before pi-sprite

`pi-sprite` is not required for the next Software Factory dogfood if explicit `sprite exec` commands can satisfy the same checkpoint, evidence, rollback, and verification requirements in this skill.

Accepted interim remote execution boundary:

```bash
sprite -s <target-sprite> exec -- <read-only-command>
sprite -s <target-sprite> exec -- bash -c '<shell command with pipes, redirects, cd, or chaining>'
```

`pi-sprite` becomes required only if implementation testing proves that `sprite exec` cannot provide one of:

- reliable remote file mutation,
- readable command transcripts,
- checkpoint/rollback hooks,
- remote runtime verification.

Until that happens, do not block dogfood solely because `pi-sprite` is not in the loop.

## Role Boundaries

| Role | Owns | Must not do |
| --- | --- | --- |
| Meta PM | Experiment goal, tenant, acceptance criteria, risk framing, failure taxonomy, evaluation rubric | Run sprite mutation workflows or imply local scratch state is remote app state |
| Production PM | Tenant delivery graph, downstream builder/reviewer tasks, task bodies with target sprite and this contract | Mutate the Sprite unless separately assigned as a builder/reviewer task |
| Builder | Remote Sprite inspection/mutation, pre/post checkpoints, command transcripts, remote diffs, verification, rollback handle | Mutate locally and claim remote success; continue after checkpoint failure |
| Reviewer | Independent evidence review and safe remote verification; pass/fail/failure classification | Rubber-stamp local-only evidence; mutate without explicit review scope |

PM/meta profiles route and specify. Builder/reviewer profiles own remote commands and evidence.

## When to Use

Use this skill when:

- a Kanban task targets an existing Sprite such as `<target-sprite>`, `tenant-app-staging`, or another named production tenant Sprite;
- the task asks for a remote app change, deployment, service tweak, runtime validation, rollback check, or review of such work;
- the task body mentions Software Factory production profiles, dogfood, remote Sprite development, checkpoint discipline, or remote evidence packages.

Do not use this skill for:

- purely local prototype work that intentionally never touches a Sprite;
- creating/destroying Sprites as a lifecycle task, unless paired with `sprite-lifecycle` and explicit approval;
- exposing public endpoints or data dumps without explicit user request and security review.

## Required Task Context

Every production task that mutates or verifies a Sprite must include the following in the body or loaded skill context:

- tenant name,
- target Sprite name,
- remote app path on the Sprite if known,
- expected service name/port/URL if known,
- acceptance criteria and quality gates,
- required skills: `kanban-worker`, `software-factory`, `remote-sprite-development`, plus app-specific skills when available,
- whether mutation is allowed or the task is review/read-only,
- protected data/routes and anything explicitly out of scope.

If target Sprite, mutation authority, or checkpoint availability is ambiguous, block before mutation.

## Target Locality Contract

1. Name the target Sprite explicitly in the task and handoff.
2. Treat `$HERMES_KANBAN_WORKSPACE` as local scratch only.
3. Use remote commands for all authoritative app inspection and mutation.
4. Label any local-only preparation as local-only evidence.
5. Never claim a local build/test proves remote Sprite state.
6. Store durable evidence in Kanban handoffs or non-secret workspace artifacts; never require private notes, local memories, sessions, logs, credentials, or hidden profile state to understand the result.

## Checkpoint Contract

Before any mutating command:

```bash
sprite -s <target-sprite> exec -- bash -c 'sprite-env checkpoints create --comment "pre-change: <task-id> <short-purpose>"'
```

Record the checkpoint handle/id/name, timestamp if available, and exact command. If checkpoint creation fails or is unavailable, block before mutation unless the human/PM explicitly accepts the risk in the task thread.

After successful verification:

```bash
sprite -s <target-sprite> exec -- bash -c 'sprite-env checkpoints create --comment "post-change: <task-id> verified <short-result>"'
```

Record both pre-change and post-change handles in completion metadata. If post-change checkpointing is unavailable, record the deployed/verified state handle and explain the gap.

## Allowed Remote Command Pattern

Read-only inspection:

```bash
sprite -s <target-sprite> exec -- bash -c 'cd <remote-app-path> && git status --short && pwd'
sprite -s <target-sprite> exec -- bash -c 'sprite-env services list'
sprite -s <target-sprite> exec -- bash -c 'curl -sS -o /tmp/check.out -w "%{http_code}\n" http://localhost:<port>/<route>'
```

Mutation after pre-checkpoint:

```bash
sprite -s <target-sprite> exec -- bash -c 'cd <remote-app-path> && <bounded edit/install/build/test command>'
```

File transfer only when required:

```bash
base64 /local/file | sprite -s <target-sprite> exec -- bash -c 'base64 -d > <remote-path>'
sprite -s <target-sprite> exec -- bash -c 'sha256sum <remote-path> && sed -n "1,80p" <remote-path>'
```

Prefer base64 piping/readback over relying on `--file` for critical writes because some Sprite CLI versions upload to `/tmp` or behave unexpectedly. If `--file` is used, record the exact local source, intended remote destination, observed upload destination, and readback verification.

From jack-michaud/software-factory-reviewer-profile, MIT.

More from jack-michaud/software-factory-reviewer-profile