From api-dev
Execute a core-web-api implementation plan (.md from api-dev:plan): write specs first (RED), implement until GREEN, run rubocop, verify diff coverage with undercover. Human reviews the output before creating a PR.
How this skill is triggered — by the user, by Claude, or both
Slash command
/api-dev:executesonnetThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are executing a pre-approved implementation plan produced by `api-dev:plan`. Your job is to write correct, tested, rubocop-clean code. **You do not commit. You do not push. You do not create PRs.** A human reviews everything you produce.
You are executing a pre-approved implementation plan produced by api-dev:plan. Your job is to write correct, tested, rubocop-clean code. You do not commit. You do not push. You do not create PRs. A human reviews everything you produce.
Input: $ARGUMENTS — path to the plan .md file (e.g., plan-KODIM-456-add-item-variants.md).
Read the file at $ARGUMENTS in full. Extract and hold in memory:
If any section is missing or too vague to implement without guessing, stop immediately and tell the user which section needs refinement. Do not proceed.
Read these files in full:
${CLAUDE_PLUGIN_ROOT}/context/architecture.md${CLAUDE_PLUGIN_ROOT}/context/recorders.md${CLAUDE_PLUGIN_ROOT}/context/services.md${CLAUDE_PLUGIN_ROOT}/context/controllers.md${CLAUDE_PLUGIN_ROOT}/context/testing.md${CLAUDE_PLUGIN_ROOT}/context/database.md${CLAUDE_PLUGIN_ROOT}/context/rubocop.mdThese are the rules of the house. Every file you create must conform.
Read every file listed in "Files to Read Before Implementing" AND "Files to Modify" (full content — you will edit these).
Skipping this step is the #1 cause of broken code. The analogue files tell you the exact shape, naming, and conventions to match.
Before touching any file, output:
### Execution Plan
Branch: <from plan>
Ticket: <from plan>
Module: <from plan>
Audience: <from plan>
Migration needed: <yes/no>
ENV vars required: <yes/no — if yes, verify they're declared in deploy.yml + .kamal/secrets>
Files to create (<N>):
- <list>
Files to modify (<N>):
- <list with exact change>
Specs to write first (RED phase):
- <list of spec files>
Spec command:
doppler run --config test -- bundle exec rspec <paths> --format documentation --no-color
Coverage command:
doppler run --config test -- COVERAGE=true bundle exec rspec <paths>
doppler run --config test -- bundle exec undercover --compare origin/main
Rubocop command:
doppler run --config test -- bundle exec rubocop <paths> --format simple
Proceed immediately. Do not wait for approval — the plan was already approved.
Create the branch specified in the plan, from main:
git checkout main
git pull origin main --quiet
git checkout -b <branch-from-plan>
If the branch already exists locally, warn the user and ask whether to switch to it or abort. Do not silently overwrite.
If the plan includes a migration:
doppler run -- bin/rails db:migrate
doppler run --config test -- bin/rails db:test:prepare
doppler run -- bundle exec annotaterb models
db/schema.rb updated and models re-annotated.strong_migrations check: if RuboCop/strong_migrations blocks the migration, follow the plan's "strong_migrations check" note. Never safety_assured without the justification listed in the plan.
Write every spec file from the plan's "Spec Skeleton" section. Rules:
instance_double / double / stubs. Never create(:factory) in non-model specs.let_it_be for data shared across examples (via test-prof). Use let for lazy/per-example.core_customer, api_core_customer, api_authentication — use them, don't invent new ones.eq(100.0), not be_present, where the value is knowable.have_enqueued_job(JobClass) and have_enqueued_mail(MailerClass, :method).with(args).After writing all specs, run them:
doppler run --config test -- bundle exec rspec spec/<paths> --format documentation --no-color
Expected: ALL FAIL. If any pass before implementation, flag it:
Follow the plan's "Implementation Steps" in order. Each step is atomic.
For each step:
doppler run --config test -- bundle exec rspec spec/<path_for_this_step> --format documentation --no-color
Never loop blindly. Three attempts and stop.
Once every step's specs pass individually, run the combined suite:
doppler run --config test -- bundle exec rspec <all specs from plan> --format documentation --no-color
If new failures appear that weren't there in isolation, fix them — same 3-attempt rule.
doppler run --config test -- COVERAGE=true bundle exec rspec <paths>
doppler run --config test -- bundle exec undercover --compare origin/main
undercover is a blocking gateIf undercover reports lines without coverage in the diff:
# :nocov: block with a comment explaining why.Coverage ≥ 85% globally must also be satisfied. If SimpleCov reports below 85%, extend specs to meet it.
Run rubocop on every file created or modified:
doppler run --config test -- bundle exec rubocop <paths> --format simple
rubocop -A <paths> (safe + unsafe autocorrects — Omakase is conservative).# rubocop:disable without a justification comment per rubocop.md..rubocop_todo.yml — if a cop hits new code, fix the code.If the plan's "Environment Variables" section listed vars:
config/deploy.yml → confirm each var is declared in env.secret or env.clear. If not, add it per the plan..kamal/secrets → confirm each var has a line. If not, add it per the plan:
<VAR>=$(doppler secrets get <VAR> --project kodim-core-web-api --config prd --plain)
ACTION REQUIRED (human): verify the following in Doppler `prd`:
doppler secrets get <VAR_1> --config prd --plain
doppler secrets get <VAR_2> --config prd --plain
If any returns empty, add them in Doppler before deploying.
Output a summary for the human reviewer:
### Execution Report
Branch: <branch name>
Ticket: <ticket>
Status: <GREEN / PARTIAL / BLOCKED>
Files created (<N>):
- path/to/file.rb
- ...
Files modified (<N>):
- path/to/file.rb (what changed)
- ...
Migration: <ran / not needed>
Model annotations: <updated / not needed>
Tests:
- <N> new specs, all passing
- Global coverage: <%>
- Undercover (diff coverage): <CLEAN / N lines uncovered — see notes>
Rubocop: <CLEAN / X offenses justified with disable comments>
ENV vars:
- <list of vars added to deploy.yml and .kamal/secrets, with reminder to verify Doppler>
- (or "None")
Manual review recommended:
- <anything the executor is not 100% confident about>
- <edge cases not covered by specs, with justification>
- <any deviation from the plan and why>
Next steps (HUMAN):
1. Review diff: git diff main...HEAD
2. Verify ENV vars in Doppler (if any listed above)
3. Stage and commit:
git add <files>
git commit -m "[<TYPE>] <title> - <TICKET>"
4. Push and open PR against main:
git push -u origin <branch>
gh pr create --base main --title "<title>" --body "<from plan summary>"
5. Run /pr-signoff after PR is open
git reset --hard or other destructive commands..rubocop_todo.yml.safety_assured unless the plan explicitly authorizes it and includes justification.create(:factory) in non-model specs — the plan's Spec Skeleton uses instance_double. Follow it.eq(100.0), use 100.0, not be_present.# :nocov: with comment. No silent skip.If at any point you realize the plan has a fundamental problem (conflicting business rules, impossible test assertion, missing analogue), STOP and report:
### PLAN BLOCKER
Step: <which step>
Issue: <what's wrong>
Needed from human: <exact decision/info needed>
Current state:
- Files created: <list>
- Files modified: <list>
- Migration status: <run / not run>
- Specs status: <passing / failing / not written>
Do not guess. Do not continue. Wait for the human.
npx claudepluginhub kodimtech/claude-code-plugins --plugin api-devProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.