القائمة
Time-boxed throwaway investigation to answer one hard question. Use when facing technical uncertainty before committing to a frontier item or scoped slice — the output is knowledge, not production code.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Author a completed-spec fixture — a seeded intent graph plus a believable four-phase interview transcript — for a brunch feature, so it can feed any downstream tooling that consumes a completed spec or dogfood the UI. Use when you need a real completed specification in .brunch/brunch.db for testing or demo: pick a feature from memory/SPEC.md (or a free description), choose a stress profile (coverage|clean), and produce a registered scenario seed + an interview-questions doc that match exactly.
Review someone else's PR through an architectural/strategic lens — does it shift design, raise complexity, or quietly change precedent? Drives a brief reflective discussion with the user, then posts a concise review comment via `gh`. Defers line-level and bug-hunting concerns to AI review bots and the PR author.
Crystallize shared understanding into a reviewable spec, or update an existing one. Use when the problem needs a written specification, when assumptions or decisions have changed, or when the user says 'write a spec'.
Lightweight triage for the ln-* skill set. Use when unsure which ln skill to use next, starting work on something new, or when the user asks for guidance on their development process.
Explore radically different module shapes before committing to one. Use when choosing an API surface, deciding what a module hides vs exposes, or when the user says 'design it twice'.
Collapse meaningful ambiguity with contrastive examples. Use when a plan/design has several plausible meanings, requirements feel vague, examples would clarify intent faster than grilling, or the user asks to disambiguate, find ambiguity, use behavioral kernels, or ask contrastive questions.
| name | ln-spike |
| description | Time-boxed throwaway investigation to answer one hard question. Use when facing technical uncertainty before committing to a frontier item or scoped slice — the output is knowledge, not production code. |
| argument-hint | [question to answer and what you'll try] |
Retire one uncertainty. Output is knowledge, not code — spike code is throwaway, never promoted directly (Beck, XP). One question per spike; if multiple unknowns exist, run multiple spikes.
Spike notes are temporary. Reconcile durable findings into memory/SPEC.md and memory/PLAN.md instead of inventing standalone investigation docs unless the user explicitly asks for one.
The question and approach: $ARGUMENTS
## Question
[The question]
## Approach
[What was tried]
## Verdict
[Answer: yes/no/partially, with evidence]
## Recommendation
[Proceed with ln-scope, try a different approach, or abandon]
After the verdict, do all of these before presenting routing options:
done in memory/PLAN.md if the spike itself was tracked as a frontier item, or update the affected frontier definition if it was a proving step inside a frontiermemory/SPEC.md §Assumptions — set Status to validated or invalidated as evidence warrants, update Confidence if the evidence changed it, and flag implicated frontier items in memory/PLAN.mdmemory/SPEC.md §Decisions, new assumptions to §Assumptionsmemory/PLAN.mdThese are bookkeeping steps, not optional. Routing comes after.
After traceability is complete, present these options to the user (use tool-ask-question):
| # | Label | Target | Why |
|---|---|---|---|
| 1 | Scope a slice | ln-scope | Question answered — ready to define the next scoped slice |
| 2 | Spike again | ln-spike | New question emerged, needs another investigation |
| 3 | Revise spec | ln-spec | Verdict revealed the spec needs structural revision |
| 4 | Revise plan | ln-plan | Verdict changes what frontier items or slices are needed |
| 5 | Back to triage | ln-consult | Verdict changes the overall direction |
Recommended: 1 if the spike validated. If it invalidated an architectural or requirement-level assumption, prefer 3; if it mainly changes frontier/slice feasibility, ordering, or dependencies, prefer 4.