About arojinle
Àròjinlẹ̀ is a skill for clarifying project decisions through structured interviews and a dependency-aware decision tree. It helps callers surface unresolved assumptions and reach shared understanding without taking over the decisions or executing delivery.
Key features
- 01Map decisions and dependencies
- 02Ask answerable questions in rounds
- 03Research bounded facts and prerequisites
- 04Compare options with decision-specific criteria
- 05Maintain a living HTML plan
- 06Record assumptions and deferrals
Use cases
- 01Clarify project goals and success measures
- 02Resolve decisions with dependent branches
- 03Compare credible options against key criteria
- 04Prepare a confirmed plan for handoff
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ quantipixels/ skills --skill arojinleAfter installing, type/arojinlein Claude Code to confirm it loaded.
Bundled filesagents/openai.yaml
Details
From the project READMEÀròjinlẹ̀
An articulated mechanism is not necessarily an established desire. Clarify the need, beneficiary, observable success and consequential trade-offs only where they remain unsettled. Reuse complete briefs and accepted constraints; do not manufacture alternatives or re-interview settled choices. A single already-understood bounded choice can remain with its caller.
Use amose when unresolved project-specific meaning—terms, identities, boundaries, relationships, ownership, or invariants—can materially change the decision tree.
Interview the user relentlessly until shared understanding is reached and no consequential branch remains silently assumed. Map it as a decision tree: every decision branches into the decisions that depend on it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled. Ask the whole answerable frontier in one round, then wait for the user's answers before starting the next.
Use this question card, rendered as Markdown rather than showing the template fence. Keep question numbers stable across rounds; label choices when that makes answers unambiguous.
❓ **Q1** — **<question title>**: <question and choices, as needed>
💡 <brief context, evidence, trade-off or example, only when it makes the decision clearer>
➡️ <recommended answer and why>
Each round reshapes the tree. Recompute the material frontier from confirmed answers before asking the next round; answers may create, remove, merge, split, or reframe dependent branches. Do not merely continue the previously imagined tree.
When the user cannot judge abstract alternatives, make the choice concrete with a small example or use adanwo for direct experience, then resume from their reactions. Repeated questioning cannot supply experience they do not yet have. Keep proposed interpretations tentative until confirmed.
Do not ask a question whose answer depends on another still-open question in the same round.
Finding facts is your job, never the user's. Resolve bounded facts directly. While bounded independent work investigates a prerequisite, ask independent frontier questions now; only questions depending on that evidence wait. When genuinely non-discoverable third-party input controls a material frontier, name the missing input and continue independent questions. If collecting it is in scope, return answerable questions directly or use oro when available and materially helpful for recipient-facing drafting. Drafting does not authorize sending or turn replies into approval.
Delegate bounded analysis, research, or expert work only when separate expertise or context materially repays coordination cost; return concise findings and evidence links.
Use iwadi for substantive prerequisite research and the applicable project or host capability for source acquisition. Continue the same interview; incomplete evidence does not settle a dependent prerequisite.
When a frontier choice has several credible alternatives and at least two independent criteria can materially change the recommendation, use a compact decision-specific rubric. Apply hard gates first; derive only the criteria that matter to this decision; show the decisive factor, strongest credible alternative, and material counterevidence. Do not manufacture scores for a trivial/already-determined choice or let an average hide a gate. The rubric supports the recommendation; the decision remains the user's.
Use atona in exploration mode when initiative exploration or direction shaping is the needed result. Use adanwo when a disposable prototype can clarify a concrete choice.
The decisions remain the user's. Do not silently convert a recommendation, generated option, comparative grade, or prototype observation into confirmation.
Make shared understanding visible
For a plan or proposed direction, use html-artifact from the first meaningful proposal. Reuse the initiative’s living view through its owner; otherwise maintain one for handoff. Keep questions in the conversation. Other bounded decisions use visual support as needed.
After material changes, update the decisions and their presentation in the same HTML plan before dependent questions; do not create an equivalent Markdown companion. Preserve alternatives, hard gates, uncertainty, and counterevidence. Present the consolidated view before final confirmation. If it is unavailable, report the gap and continue independent fact-finding.
Before declaring the material frontier empty, challenge the current tree for consequential assumptions, missing branches, contradictory decisions, and dependencies that were never made explicit.
Finish only when that challenge leaves no unresolved material branch, any required view is current, and the user confirms shared understanding. Return confirmed decisions, material assumptions/evidence, decision-changing alternatives/criteria when they constrained the choice, explicit deferrals/re-entry conditions, and the next outcome boundary to the same caller. Pass the plan’s HTML locator and revision. Return newly exposed domain, factual or technical gaps without starting a competing workflow. Do not execute delivery inside arojinle.