How do I install the Starting The Task skill?

Run npx skillmds add majiayu000/starting-the-task in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Starting The Task safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Starting The Task?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Starting The Task free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Starting The Task?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Starting The Task by majiayu000 — Agent Skill

Name: Starting The Task
Rating: 4.2 (5 reviews)
Author: majiayu000

File contents

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.

---name: starting-the-taskdescription: 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. 1. **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. 2. **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. 3. **Branch & Tracking** - Create a fresh branch for the effort, even if you expect a small change. ```bash 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. 4. **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): ```bash 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>`. 5. **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. 6. **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.

Frequently asked questions