starting-the-task

Étoiles2

Forks1

Mis à jour27 novembre 2025 à 06:42

A short checklist for kicking off work effectively: plan, branch, track with bd, and set up validation.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

lambdamechanic

lambdamechanic/skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	starting-the-task
description	A short checklist for kicking off work effectively: plan, branch, track with bd, and set up validation.

Starting the Task

Use this checklist any time you begin work on a bd issue (or whenever the user says “start working on …”). It ensures the effort is grounded, observable, and reversible.

Understand the Task
- Read the bd issue (and any linked discoveries or docs) end-to-end.
- Confirm acceptance criteria, dependencies, and blockers. Ask clarifying questions before touching code.
Environment Readiness
- Run cargo test (or the project’s canonical smoke suite) on main to ensure the baseline is green before you diverge.
- If tests fail, stop and coordinate—don’t start stacking new work on a broken branch.
Branch & Tracking
- Create a fresh branch for the effort, even if you expect a small change.
```
git checkout -b <short-task-name>
```
- bd update <id> --status in_progress --notes "Starting work" so the tracker reflects the new ownership/status.
- If multiple repos are involved, repeat for each.
Open a Draft PR (immediately)
- As soon as you create the branch, open a draft PR so CI runs and stakeholders can track progress. If a PR already exists for the parent effort, continue on that one.
- Source the PR title/description from the bd issue: include its summary, acceptance criteria, and a link/reference to the bd id.
- Preferred command (uses GitHub CLI):
```
scripts/pr-draft.sh "<short title incl. bd id>" [body.md]
```
  Fallback: gh pr create --draft --title "..." --body-file body.md after git push -u origin <branch>.
Sync & Tooling
- Ensure git pull --rebase (or equivalent) so you’re working from the latest remote main.
- Verify gh auth status so PR creation won’t fail later.
Plan Tests Early
- Decide how you’ll prove the change works (unit tests, integration, manual steps). Capture this in notes or the eventual PR description so reviewers know what to expect.

Only after these steps are complete should you begin coding. If circumstances prevent any step (e.g., CI down, baseline broken), note it explicitly in bd and get confirmation before proceeding.

Plus depuis ce dépôt

même dépôt

pr-watch

lambdamechanic/skills

Use the local pr-watch CLI/daemon to watch GitHub pull request activity, wait for PR changes, and fetch normalized event deltas without manually managing webhook forwarding or event subscriptions.

2026-03-112

lambda-workflow

lambdamechanic/skills

One lifecycle for Lambda repos: choose a bd task, start work, land the PR, and watch GitHub via Dumbwaiter MCP until it merges.

2025-12-242

python

lambdamechanic/skills

Default Python stack for Lambda: uv + Astral tools, typed code, schemas, and Hypothesis.

2025-12-232

bd-workflow

lambdamechanic/skills

How to use bd (beads) for issue tracking, ready work, status updates, and comments in this repo.

2025-12-052

zfc

lambdamechanic/skills

Zero Framework Cognition Principles

2025-12-042

dumbwaiter-mcp

lambdamechanic/skills

Provider-agnostic wait-for-change skill that uses the Dumbwaiter MCP server to wait on PR events (GitHub first) via wait.start/status/cancel/await, with progress notifications and durable state.

2025-11-292

Starting the Task

Use this checklist any time you begin work on a bd issue (or whenever the user says “start working on …”). It ensures the effort is grounded, observable, and reversible.

Understand the Task

Read the bd issue (and any linked discoveries or docs) end-to-end.
Confirm acceptance criteria, dependencies, and blockers. Ask clarifying questions before touching code.

Environment Readiness

Run cargo test (or the project’s canonical smoke suite) on main to ensure the baseline is green before you diverge.
If tests fail, stop and coordinate—don’t start stacking new work on a broken branch.

Branch & Tracking

Create a fresh branch for the effort, even if you expect a small change.
```
git checkout -b <short-task-name>
```
bd update <id> --status in_progress --notes "Starting work" so the tracker reflects the new ownership/status.
If multiple repos are involved, repeat for each.

Open a Draft PR (immediately)

As soon as you create the branch, open a draft PR so CI runs and stakeholders can track progress. If a PR already exists for the parent effort, continue on that one.
Source the PR title/description from the bd issue: include its summary, acceptance criteria, and a link/reference to the bd id.
Preferred command (uses GitHub CLI):
```
scripts/pr-draft.sh "<short title incl. bd id>" [body.md]
```
Fallback: gh pr create --draft --title "..." --body-file body.md after git push -u origin <branch>.

Sync & Tooling

Ensure git pull --rebase (or equivalent) so you’re working from the latest remote main.
Verify gh auth status so PR creation won’t fail later.

Plan Tests Early

Decide how you’ll prove the change works (unit tests, integration, manual steps). Capture this in notes or the eventual PR description so reviewers know what to expect.

Only after these steps are complete should you begin coding. If circumstances prevent any step (e.g., CI down, baseline broken), note it explicitly in bd and get confirmation before proceeding.