القائمة
Create a well-thought-out plan covering problem statement, goals, technical approach, and verification criteria. Use while planning / before implementing any non-trivial feature.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Break a feature spec into intentional waves and bite-sized tasks grouped by dependency. Use after a spec is written to prepare for easy-to-track implementation.
Review a code change (diff or PR) for ship-readiness before merge. Use when reviewing your own or someone else's changes prior to committing/merging/etc.
Make sure your code is ready to commit, then stage changes into clean, atomic commit. Use before committing.
Full review of a plan or spec to be sure there are no surprises, gaps, or mistakes. Use to harden a spec before implementation.
Audit a test suite to find tests that give false confidence — tests that encode bugs, duplicate coverage, or are so heavily mocked they can't catch real regressions. Use to improve robustness, audit coverage, or harden a risky area.
| name | gjalla-spec |
| description | Create a well-thought-out plan covering problem statement, goals, technical approach, and verification criteria. Use while planning / before implementing any non-trivial feature. |
The best, most elegant and effective software systems are ones that are well-informed, well-planned, and verifiable. The final output is a plan/spec that can act as a reference doc, covering the problem/motivation, technical approach, deltas (what properties of the system will change once implemented), and verification criteria. The first step is always understanding the current state. Use gjalla (CLI or MCP) to fetch the relevant parts of the master spec, including the architecture, capabilities, data flows, etc that are relevant to this problem/solution space. Also fetch the gjalla rules so you know what boundaries there are on your final solution. Once you undersatnd the relevant properties and constraints, identify any specific details that you need from the source code and gather them. Now you have everything you can find yourself. Are there any outstanding questions that will affect the specifics of the solution you propose? If so, ask the user for input.
When you have everything you need, go ahead and use gjalla spec new which will scaffold a change spec for you to edit. This is necessary for workflows where specs are artifacts are canonical, and the gjalla platform will facilitate verifying and merging changes into the master spec once implementation is complete.
The user may prefer that you present the plan as a Claude Plan or a Cursor Plan (or another alternative based on your identity as an agent)... that's fine. Once the plan is approved for implementation, write the approved information into a gjalla spec and continue on.
The information needed for a production-grade spec / reference doc includes the following:
