Menu
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).
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".
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/.
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-spec-feature |
| description | 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). |
You are writing a feature spec for ticket $ARGUMENTS. Do NOT implement anything — this command ends when the spec file is written and the user has confirmed it.
Read platform.md in this skill's directory. It defines this repository's
module map, architecture patterns, language rules, wiring conventions, test
stack, and the conventions checklist the spec must cover. 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 spec workflow.
Fetch $ARGUMENTS from Jira (any board — PP or otherwise). Read the summary, description, acceptance criteria, comments, and linked issues. If the ticket cannot be fetched, ask the user to paste its content instead of guessing.
Identify which modules are affected, using the module map in platform.md.
Read the relevant existing code so your questions and spec are grounded in
how things actually work today. In particular, establish:
platform.md prescribes for this repository.platform.md lists the patterns in use and where. The spec must name the
pattern for new code and it must match a precedent that actually exists in
the touched module — don't prescribe a pattern the module doesn't use.platform.md
for the frameworks in use).platform.md.Use the AskUserQuestion tool. Never skip this step, even if the ticket seems clear. Ask about the things the ticket leaves open, for example:
Only ask questions whose answers change the spec. If a second round of questions is needed after the first answers, ask again.
Write the answers and your analysis into specs/$ARGUMENTS-feature.md
(create the specs/ directory if it doesn't exist) with this structure:
# <Ticket ID>: <Title>
Status: draft
Ticket: <link to the Jira ticket>
## Problem
What the user/integrator needs and why. In your own words, not a ticket copy-paste.
## Requirements
Numbered, testable statements. Include decisions from the clarifying questions.
## Affected modules
Which modules change and how they relate.
## Public API impact
Changes to integrator-visible declarations per module, or "none". Note whether
changes are additive or breaking. Assess visibility as prescribed by platform.md.
## Technical conventions
Concrete, repo-grounded rules /gini-build must follow. Cover every item in the
conventions checklist in platform.md, grounded in the modules actually touched.
## Design
How it will work: key classes, data flow, integration points. Reference
existing code with file paths.
## Test plan
Which tests prove each requirement. Name test classes/locations AND the test
stack to use — match neighboring tests in the module (see platform.md). State
the expectation that every new class gets a unit test, and list what is left
to manual QA.
## Out of scope
Explicitly excluded work, so /gini-build doesn't drift into it.
## Open questions
Anything still unresolved (should be empty or short after step 3).
Show the user a short summary of the spec and where it was written. Remind
them to review/edit it, then run /gini-build $ARGUMENTS (ideally in a fresh
session) to build it. Do not start implementing yourself.