backend-implement
Skill1 starsChanged 11 days agoMITView on GitHub
Phase 4 (backend tasks). Implements one PLAN.md task in Python/FastAPI following the layer pattern and edge-case checklist. Use for each unticked backend task after the plan is approved.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/00-ticket-workflow.mdcCursor rule
- .cursor/rules/10-general-standards.mdcCursor rule
- .cursor/rules/20-backend-standards.mdcCursor rule
- .cursor/rules/30-frontend-standards.mdcCursor rule
- .cursor/rules/40-database-standards.mdcCursor rule
- .cursor/rules/50-testing-standards.mdcCursor rule
- chatSkill
- codebase-exploreSkill
- db-migrationSkill
- frontend-implementSkill
- gitlab-mrSkill
- implementation-planSkill
- jira-createSkill
- mr-feedbackSkill
- mr-reviewSkill
- quick-fixSkill
- run-checksSkill
- self-reviewSkill
- ticket-intakeSkill
- ticket-qaSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 7
Do ONE task at a time. Max 3 tasks per chat.
- Distinctive: line 10
Read PROGRESS.md and PLAN.md.
- Very specific: line 16
Write the smallest code that makes this task's tests pass, in layer order: schema → repository → service → route.
- Very specific: line 35
Verify on touched files (from backend/): ruff check <files> && ruff format <files> && mypy --follow-imports=silent <files> Fix all errors.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Backend implement (phase 4, backend tasks)
Do ONE task at a time. Max 3 tasks per chat.
Steps
- Read PROGRESS.md and PLAN.md. Pick the next unticked backend task. Confirm the branch:
git branch --show-currentmust match PROGRESS.md. The task's tests must already be red (PROGRESS.md has their red lines); if not, run /write-tests for it first. - Open the pattern source files from "Codebase notes". Copy their structure, imports, naming, dependency injection and error handling. Do not invent a new style.
wc -leach file you will edit. If the change would pass 200 lines, do the split first.- Write the smallest code that makes this task's tests pass, in layer order: schema → repository → service →
route. Before using any function, class or setting, confirm it exists:
rg -n "def <name>|class <name>" backend/app. A library API the codebase doesn't use yet: check the installed version (pyproject.tomlor the lock file) and follow that version's docs; can't verify → say so in PROGRESS.md. - Edge-case checklist. Handle each one, or write
N/A: <reason>in the PROGRESS.md log:- New route requires the auth dependency (public only if PLAN.md's API table says so)
Create/Updateschemas have no server-owned fields (id, owner id,role,is_admin, timestamps)- Not found → project's not-found error (404)
- Belongs to another user / wrong role → forbidden error (403), checked in the service
- Duplicate → catch
IntegrityError→ conflict error (409) - Invalid input →
Fieldconstraints in the schema (422); max lengths = DB column lengths - Optional/nullable fields handled in service and response
- Empty list returns
[](+ pagination info), never 404 - Pagination: default 20, max 100, stable
order_by - Multi-write operations in one transaction
- No N+1: relations in the response are eager-loaded
- UTC datetimes,
Decimalmoney - No secrets or personal data in logs or responses
- Register new routers the same way the pattern source does (find with
rg -n "include_router" backend/app). - Verify on touched files (from
backend/):ruff check <files> && ruff format <files> && mypy --follow-imports=silent <files>Fix all errors. No# noqa/# type: ignore. Then run this task's tests: all green (mark their Test plan rows ✅). Still red while the code looks right → re-check the expected value against REQUIREMENTS.md before changing more code. - Tick the task in PLAN.md. Append to PROGRESS.md log: task id, files changed, edge cases N/A with reasons.
Done when
- Task ticked, every file ≤ 200 lines
- ruff and mypy output shown clean in this chat
- This task's tests shown red before the code and green after
- Every checklist item handled or marked N/A with a reason
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

