full-send

Files (5)

• SKILL.md
• bot-review.md
• evidence.md
• implement-loop.md
• repos.md

SKILL.md (first lines)

# full-send

## Input

The invocation input holds an optional leading **mode keyword**, then a ticket ID (e.g. `AP-1234`) or free-text
describing the work. Parse them in this order:

1. **Mode keyword** (optional, first token):
   - `interactive` / `ask` / `careful` → **interactive mode** (front-load a grill, see Phase 0.5).
   - `auto` → explicit **autonomous mode** (the default).
   - No keyword → **autonomous mode**.
   - `loop` (orthogonal, combines with any of the above) → force the Phase 3B serial loop
     regardless of size.
   - `fan` (orthogonal, combines with any of the above) → force the Phase 3C parallel waves
     regardless of size. Without either keyword, the implement path is gated in Phase 3.0.
2. **Remaining invocation input:**
   - A ticket ID (e.g. `AP-1234`) → fetch it (Phase 0).
   - Free-text with no ticket ID → treat as a **raw idea/spec** and synthesize a ticket (Phase 0).
   - Empty → ask once for a ticket ID or an idea before starting.

### Modes

Autonomous is the default and takes zero stops.

**Interactive** takes exactly **one** stop: the up-front grill (Phase 0.5).

**When the up-front grill (Phase 0.5) runs.** Resolve the case from this table. "Attended" means a
human is present to answer. Any non-interactive CLI run or scheduled routine is unattended.

| Input | Attendedness | Grill runs? | Assumptions block? |
|-------|--------------|-------------|--------------------|
| Ticket ID, no `interactive` keyword | attended | no (the ticket carries the spec) | yes |
| Ticket ID, `interactive` keyword | attended | yes | no, the grill resolves it |
| Raw idea / spec (no ticket ID) | attended | yes (highest-ambiguity input, no human-authored ticket to anchor on) | no, the grill resolves it |
| Anything, including `interactive` | unattended | no (nobody to answer) | yes |

When the grill is skipped: pick the most reasonable interpretation, proceed, and record it in an
**Assumptions** block carried onto the PR (Phase 6) and the Done summary (Phase 9).

### Bail-out (the one exception to zero-stops)

"Zero stops" means do not pause for preferences. It does **not** mean ship broken code. **Stop and
report** instead of proceeding when the run hits an **unrecoverable** state, specifically:

- Typecheck, lint, or tests cannot be made green after a genuine fix attempt, and the failure is
  caused by this change (not pre-existing).
- The implementation cannot satisfy the acceptance criteria (the ticket is wrong, blocked, or
  needs a decision only a human can make).
- A `git` rebase/push conflict cannot be resolved cleanly.

On bail-out:

1. Commit or stash what is safe.
2. Leave the branch intact.
3. Report exactly where the run stopped, why, and what is needed to continue.

**Do not** open or finalize a PR around known-broken code. A trivial or blocked ambiguity is not a
bail-out. Record an assumption and keep going.

---

## Writing style

Copied verbatim from `~/.claude/CLAUDE.md`, which a headless run never loads.
Binding on commits, the PR body, review replies, recorded assumptions, and the final
report.

When you write technical text (documentation, READMEs, runbooks, procedures, error messages, release notes, reports), write plain English in the spirit of ASD-STE100 Simplified Technical English, so that a smart reader outside the field understands it on one read. Obey these rules:

CLASSIFY FIRST. Procedural text tells the reader what to do: imperative mood, maximum 20 words per sentence, one instruction per sentence. Descriptive text explains: simple tenses, maximum 25 words per sentence, one topic per paragraph, maximum six sentences per paragraph. Never mix the two in one passage.

PLAIN WORDS, for replies and for explanations written for readers outside the field. Use the common word when one exists ("use", not "utilize"). Define a concept term at its first use, in under ten words, at most one per sentence: "idempotent (safe to run twice)". Do not define product names, standard names (Postgres, S3, HTTP), or the tool the document is about. Address the reader as "you". Lead with the point. Procedures and reference documents follow the rules above alone.

VERBS. Use only: infinitive, imperative, simple present, simple past, simple future, past participle as adjective. No present perfect ("has completed" → "completed"). No "-ing" verb forms ("making it easy" → new sentence). Active voice; passive only in descriptions when the agent is unknown. Approved modals: can, will, must. Banned: should, would, may, might, could. For "should": write "must" if required, delete if optional.

SENTENCES. Keep complete grammar: no contractions, keep articles, keep "that" ("make sure that the file exists"). Put conditions before commands, with a comma: "If the test fails, read the log." No semicolons: write two sentences. No em-dashes: an em-dash hides the logic between two statements. Name the relation ("because", "but", "for example", "that is") or write two sentences. Use a vertical list for more than two items or steps.

WORDS. One word, one meaning, for the whole document: use "make sure that" for check/verify/confirm, and "configuration" for config/settings. Noun chains of maximum three words. Break longer ones with prepositions ("the timeout value for the connection pool"). Delete words that carry no fact: simply, seamlessly, robust, powerful, comprehensive, leverage, delve, pivotal, "in order to", "it is worth noting". Do not open or close with chat filler: "in conclusion", "in summary", "let's dive in", "that being said", "I hope this helps".

AVOID THE AI DRIFTS. Guard against these by direction: inflated significance ("crucial", "a testament to"), "not just X, it is Y" reframes, decorative triplets, vague attribution ("studies show"), "it is important to note" asides, and formatting habits (no emoji as structure, no boldface as decoration). State the fact. The fact carries itself. Replace: utilize → use, prior to → before, in the event that → if, e.g. → for example. American spelling.

WARNINGS. Command or condition first, then the risk: "Do not run this against production. The command deletes rows."

NEVER TOUCH. Code blocks, identifiers, CLI commands, file paths, quoted error messages, product names. Each counts as one word toward sentence limits. Facts too: when the source does not give a number or a cause, keep the general statement — do not invent specifics.

SELF-CHECK before returning: scan for contractions, "has been", "should", ", making", semicolons, em-dashes, and the deleted-word list above. Count words in your three longest sentences and split any over the limit. Collapse synonym rotation.

REPLIES TO THE USER. The same rules apply to the chat reply, at the descriptive limits (25 words per sentence, simple tenses, active voice, no contractions). Start with the answer or the result. If a concept term is necessary, define it in a few words. Do not restate the request. Keep the whole reply to 5 sentences or fewer, code and lists excluded. Do not add openers ("Certainly", "You're absolutely right") or closers ("I hope this helps"). Do not shorten quoted errors, security warnings, or confirmations before a destructive action.

STRICT MODE. If the user names STE, ASD-STE100, or compliance, also apply the STE dictionary to the document: "make sure that" for check/verify/confirm, "operate" for run, "do" for execute, "show" for display, "but" for however, "because" for since. Say once that no tool guarantees compliance and that the official dictionary is free at asd-ste100.org.

Do not apply these rules to marketing copy or brand writing.

In any markdown that will be rendered (chat responses, PR/issue bodies, reports, docs),
escape delimiter characters used literally, since two of them in one paragraph silently
corrupt everything between: `\~` for "approximately" tildes (`~...~` is strikethrough in
GFM) and `\$` for dollar amounts (`$...$` is inline LaTeX math in GitHub and VSCode
preview). Literal `~`/`$` in code stay inside backticks instead.

---

## Run variables

Shell state does not persist between Bash calls. Re-assign whichever of these a call needs, at the
top of that call:

| Variable | Assigned in | Value |
|----------|-------------|-------|
| `$TICKET_ID` | Phase 0 | The Linear identifier, original casing (`AP-1234` in `codebase`, `HYZ-12` in `neema-simple-hyzl`) |
| `$TICKET_TITLE` | Phase 0 | The Linear ticket title, verbatim |
| `$BASE` | Phase 1 | `git remote show origin \| sed -n 's/.*HEAD branch: //p'` |
| `$REPO` | Resume | `gh repo view --json nameWithOwner --jq '.nameWithOwner'` |
| `$PR_NUMBER` | Resume (existing PR) or Phase 6 (after create) | The PR number |

---

## Preflight: dependency check (runs first)

Check the tools this run will use before any other work. Print a **readiness summary**.

From ptrandev/agent-skills, MIT.

More from ptrandev/agent-skills