justin
3221f7abe8
CI / check (pull_request) Successful in 7s
Most current systems (default Debian/Ubuntu, recent macOS) install Python only as `python3`, with no bare `python` on PATH, so learners who copied `python cli.py ...` into their host shell hit "command not found". Convert host-shell `python <cmd>` -> `python3 <cmd>` across module/lab READMEs, lab `.py` docstrings & usage strings, blog posts, lab prompt and instruction files, the M04 verify.sh message, and the M10/M24 lab patches. Module 01's convention note (and its blog/02 mirror) is rewritten so `python3` is canonical and `python` is the documented fallback. Stop-lines respected: Docker image tags (`python:3.12-slim`), `.venv/.../python` and `...\.venv\Scripts\python.exe` paths, the M20 `"command": "python"` teaching example and surrounding venv prose, container-internal invocations (M16/M18 Dockerfiles, M16 README `docker run` examples), and CI-workflow `run:` steps fed by `actions/setup-python` / `image: python:3.12` are left as `python` on purpose. pip was left out of scope: most occurrences are prose or CI/container-internal, and `pip3` does not fix the PEP 668 externally-managed-environment refusal that the course already addresses with venvs. The M01 note is worded to stay consistent with bare `pip` (use whichever pip pairs with your Python). Build (tools/build_wiki.py) and tools/check.sh both pass. Closes #104 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GAEzanEoGJT5o1VizQar47
68 lines
3.3 KiB
Markdown
68 lines
3.3 KiB
Markdown
# Skill: Add a new tasks-app command, end to end
|
|
|
|
> A reusable playbook. Don't paste this whole file into a chat and hope. Point your agentic tool at
|
|
> it by name ("follow `add-command.md` to add a `clear` command"), or drop it wherever your tool
|
|
> auto-discovers procedures (a skills/commands folder). The steps are the same either way.
|
|
|
|
## When to use this
|
|
|
|
Invoke this whenever the task is **"add a new subcommand to the `tasks-app` CLI."** It exists so a
|
|
new command lands the *same* way every time: real code, a real test, a changelog line, and a clean
|
|
commit; never just the code with the rest forgotten.
|
|
|
|
If the task is *not* "add a CLI command" (a bug fix, a refactor, a docs change), this skill does not
|
|
apply. Don't force it.
|
|
|
|
## Inputs you need before starting
|
|
|
|
Ask for these if they weren't given:
|
|
|
|
- `COMMAND_NAME`: the subcommand word, e.g. `clear`.
|
|
- `WHAT_IT_DOES`: one sentence of intended behavior, e.g. "remove all tasks."
|
|
|
|
## Project facts (so you don't have to rediscover them)
|
|
|
|
- Core logic lives in `tasks.py` (the `TaskList` class). The CLI front end is `cli.py`. State
|
|
persists to `tasks.json`. **Never edit `tasks.json` by hand; it's generated.**
|
|
- Tests live in `test_tasks.py` and run with `python3 -m unittest`. Standard library only; no
|
|
third-party packages, no new dependencies.
|
|
- The human-facing change log is `CHANGELOG.md`, newest entry on top.
|
|
|
|
## Procedure: do these in order, do not skip
|
|
|
|
1. **Core logic in `tasks.py`.** If the command needs new behavior on the task list, add a small
|
|
method to `TaskList` (e.g. `clear()`). Keep it minimal; match the existing style. If the command
|
|
only reads existing state, skip to step 2.
|
|
|
|
2. **Wire the CLI in `cli.py`.** Add a branch to `main()` for `COMMAND_NAME`, call into `tasks.py`,
|
|
`save()` if it mutated state, and print a short confirmation. Add the command to the `usage:`
|
|
string so it's discoverable.
|
|
|
|
3. **Add a real test in `test_tasks.py`.** Test the *behavior you intended*, not just "it doesn't
|
|
crash." Assert the end state (e.g. after `clear()`, `len(tasks) == 0` and `pending()` is empty).
|
|
A test that passes against a broken implementation is worse than no test.
|
|
|
|
4. **Run the tests.** `python3 -m unittest` from the project root. Do not claim success until it's
|
|
green. If it fails, fix the code, not the test, and run again.
|
|
|
|
5. **Smoke-test the CLI.** Actually run it: `python3 cli.py COMMAND_NAME`, then `python3 cli.py list`
|
|
to confirm the visible result. Paste what you ran and what it printed.
|
|
|
|
6. **Add a `CHANGELOG.md` entry.** One line under the top heading, present tense:
|
|
`- Add \`COMMAND_NAME\` command: WHAT_IT_DOES.` Newest on top.
|
|
|
|
7. **Commit as one logical change.** Stage code + test + changelog together and commit with a
|
|
message that names the command: `git add tasks.py cli.py test_tasks.py CHANGELOG.md && git commit
|
|
-m "Add COMMAND_NAME command"`. Do **not** stage `tasks.json`.
|
|
|
|
## Done when
|
|
|
|
- `python3 -m unittest` is green and includes a new test that actually exercises `COMMAND_NAME`.
|
|
- `python3 cli.py COMMAND_NAME` does `WHAT_IT_DOES` and you've shown the output.
|
|
- `CHANGELOG.md` has a new top line for the command.
|
|
- One commit contains the code, the test, and the changelog line, and nothing else (no
|
|
`tasks.json`, no unrelated reformatting).
|
|
|
|
If any of those is missing, the skill isn't finished. Report which step failed and stop; don't
|
|
paper over it.
|