Menu
Implement a feature from its spec written by gini-spec-feature. Pass the ticket id as argument (e.g. PP-1234, IPC-42) โ the spec must already exist in specs/.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Guide a module release end-to-end per RELEASE.md โ ask the user for the list of modules with their new versions, create the Jira RC ticket(s), bump versions in dependency order with correctly formatted commits, and gate the tag push (tags trigger the release workflows). Use when asked to "release <module>", "bump versions for a release", or "prepare an RC".
Fetch a ticket, clarify open questions, and write a feature spec before any code. Pass the ticket id as argument (e.g. PP-1234, IPC-42 โ any board).
Diagnose and fix a non-trivial bug ticket - reproduce it, find the root cause, write the diagnosis to specs/, then implement the fix with a regression test. Pass the ticket id as argument (e.g. PP-1234, IPC-42 - any board).
Run the CI check suite (testDebugUnitTest, lint, detekt, ktlintCheck) locally for the modules affected by the current changes, expanding through the inter-module dependency chain. Use before pushing, or when asked to "run the checks" / "verify CI will pass". Accepts optional explicit module paths as arguments (e.g. "bank-sdk:sdk").
Run the CI steps that /gini-check omits โ instrumented tests (connectedCheck) on a device/emulator, plus optional Jacoco coverage and Sonar analysis โ for the modules affected by the current changes. Use after /gini-check passes, or when asked to "run the instrumented tests" / "run connectedCheck locally". Accepts optional explicit module paths as arguments (e.g. "bank-api-library:library").
| name | gini-build |
| description | Implement a feature from its spec written by gini-spec-feature. Pass the ticket id as argument (e.g. PP-1234, IPC-42) โ the spec must already exist in specs/. |
You are implementing ticket $ARGUMENTS from its spec. The spec is the contract: you build what it says, nothing more, and every requirement ends up tested.
Read platform.md in this skill's directory. It defines how to build and
verify in this repository (check suite, test commands), where code and tests
live, and the commit conventions. Every platform-specific decision below MUST
come from that file, never from your own defaults. If the file is missing,
stop and tell the user this repository is not set up for the shared build
workflow.
Read specs/$ARGUMENTS-feature.md, or โ for a bug diagnosed with
/gini-fix โ specs/$ARGUMENTS-bug.md. If neither exists, stop and tell
the user to run /gini-spec-feature $ARGUMENTS (features) or
/gini-fix $ARGUMENTS (bugs) first โ do not improvise a spec from the
ticket.
From a feature spec, internalize: the numbered requirements, the affected modules, the public API impact, the technical conventions, the design, the test plan, and โ just as important โ the "Out of scope" section. From a bug diagnosis: the root cause, the proposed fix, and the regression test plan (the regression test must fail before the fix and pass after). If the "Open questions" section is non-empty, surface those questions to the user with AskUserQuestion before writing any code.
Read the code the spec's Design section references. Code may have drifted since the spec was written. If reality contradicts the spec (a class was renamed, a precedent was removed, an approach is no longer viable), stop and show the user the conflict โ let them decide whether to update the spec or proceed differently. Do not silently deviate from the spec.
Produce an ordered list of changes, each mapped to the spec requirement(s) it satisfies. Order it so tests can be written first and the build stays green at every step. Keep the plan within the spec's affected modules; if you discover a module not listed in the spec must change, tell the user before touching it.
Work through the plan requirement by requirement:
platform.md), then
write the code that makes them pass.Run the verification steps defined in platform.md for the affected modules.
Fix what fails and re-run until clean. Report results honestly โ if something
still fails or was skipped, say so explicitly.
Status: line from draft to implemented (feature)
or fixed (bug).platform.md, but do
not commit or push unless the user asks.