메뉴
Use when asked for an adversarial go/no-go review or whether an issue is worth implementing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Rewrite an issue's Implementation Steps, Acceptance Criteria, and Files to Modify in place from its own accumulated research findings, without appending or bulldozing human prose
Use when asked to audit documentation accuracy, coverage, or find documentation gaps.
Use when asked about project health, velocity, bug trends, or whether we're making progress.
Use when asked to manually compact a session's memory, trigger session summarization, or reduce a long session's context footprint.
Use when asked to manually compact a session's memory, trigger session summarization, or reduce a long session's context footprint.
Use when asked to detect conflicting requirements or incompatible decisions across open issues.
| name | go-no-go |
| description | Use when asked for an adversarial go/no-go review or whether an issue is worth implementing. |
| model | sonnet |
| allowed-tools | ["Read","Glob","Grep","Bash(find:*)","Bash(ls:*)","Bash(cat:*)","Bash(git:*)","Agent","Edit","AskUserQuestion","Bash(ll-history-context:*)","Bash(ll-issues:*)"] |
| metadata | {"short-description":"Use when asked for an adversarial go/no-go review or whether an issue is worth i"} |
Evaluate whether one or more issues should be implemented by staging an adversarial debate between two research agents, with a neutral judge agent rendering a final GO/NO-GO verdict.
/ll:go-no-go [<issue-id>[,<issue-id>...] | <sprint-name>] [--check] [--auto]
| Flag | Meaning |
|---|---|
--check | Exit 0 on all GO, exit 1 on any NO-GO (FSM evaluate: type: exit_code gating) |
--auto | Non-interactive mode (implied by --dangerously-skip-permissions) |
Examples:
/ll:go-no-go # evaluate highest-priority open issue
/ll:go-no-go FEAT-808 # evaluate single issue
/ll:go-no-go FEAT-808,ENH-712 # evaluate multiple issues
/ll:go-no-go sprint-improvements # evaluate all issues in named sprint
/ll:go-no-go FEAT-808 --check # exit 0 on GO, exit 1 on NO-GO
ISSUE_TOKENS = [] # raw issue ID or sprint name tokens from args
ISSUE_IDS = [] # resolved list of issue IDs to evaluate
CHECK_MODE = false
AUTO_MODE = false
# Auto-enable in automation contexts
if ARGUMENTS contains "--dangerously-skip-permissions" or env LL_NON_INTERACTIVE is set or env DANGEROUSLY_SKIP_PERMISSIONS is set: AUTO_MODE = true
# Explicit flags
if ARGUMENTS contains "--auto": AUTO_MODE = true
if ARGUMENTS contains "--check": CHECK_MODE = true; AUTO_MODE = true
# Extract non-flag tokens
for token in ARGUMENTS:
if token starts with "--": skip
else if token contains ",": ISSUE_TOKENS = token.split(",")
else if token is non-empty: ISSUE_TOKENS = [token]
Token classification: Each token is either an issue ID (e.g., FEAT-808) or a sprint name (e.g., sprint-improvements). Issue IDs match the pattern [A-Z]+-\d+. Sprint names do not match this pattern.
Determine the final list of issue files to evaluate.
For each issue ID in ISSUE_TOKENS that matches [A-Z]+-\d+:
FILE=$(ll-issues path "${ID}" 2>/dev/null)
if [ -z "$FILE" ]:
print "Error: Issue $ID not found"
exit 1
For each token that does NOT match the issue ID pattern, treat it as a sprint name:
SPRINT_FILE=".sprints/${SPRINT_NAME}.yaml"
if [ ! -f "$SPRINT_FILE" ]:
print "Error: Sprint '$SPRINT_NAME' not found at $SPRINT_FILE"
exit 1
# Read the sprint YAML and parse the `issues:` list
cat "$SPRINT_FILE"
# The issues: key contains a list of issue IDs (e.g., ENH-175, FEAT-808)
# Resolve each ID to its file path
Find the highest-priority open issue across all active categories:
for P in P0 P1 P2 P3 P4 P5; do
for dir in .issues/{bugs,features,enhancements}/; do
FILE=$(ls "$dir"/$P-*.md 2>/dev/null | sort | head -1)
if [ -n "$FILE" ]; then break 2; fi
done
done
if [ -z "$FILE" ]:
print "Error: No open issues found"
exit 1
For each resolved issue file, perform the following steps sequentially.
Read the issue file completely. Extract and note:
After loading the issue file, query the history database for prior corrections:
HIST=$(ll-history-context {{issue_id}} 2>/dev/null || true)
If HIST is non-empty, include it as a ## Historical Context section in the evaluation context. Resolve the correction penalty via PENALTY=$(ll-config get history.go_no_go.correction_penalty) (default -0.2) and apply it as a signal on the GO/NO-GO verdict confidence — a match on HIST should shift the verdict toward NO-GO in proportion to the resolved PENALTY value. Surface any matched corrections as explicit "prior concerns" in the output and weigh them in the judge agent's prompt.
If .ll/history.db is absent or the query fails, proceed normally without historical context.
Before launching adversarial agents, check if the issue has a learning_tests_required frontmatter field. If present and non-empty, run ll-learning-tests check "<target>" for each declared target and collect results. Build a Learning Test Context block to inject into subsequent prompts:
## Learning Test Context
The following external API assumptions are declared in this issue's frontmatter:
| Target | Status | Notes |
|--------|--------|-------|
| "<target>" | proven/stale/refuted/missing | [refutation summary if refuted] |
If learning_tests_required is absent or empty, omit this block entirely (do not inject a placeholder).
In a single message, launch both agents concurrently using the Agent tool with run_in_background: true.
IMPORTANT: Both agent calls MUST appear in the same message to run concurrently. Do not send them in separate messages.
Use this prompt for the pro-implementation agent, substituting the actual issue content:
You are a pro-implementation advocate for [ISSUE-ID]: "[ISSUE-TITLE]".
Your task is to research the codebase and build the strongest possible argument FOR implementing this issue right now.
Issue Summary:
[ISSUE-SUMMARY]
Acceptance Criteria:
[ACCEPTANCE-CRITERIA]
Motivation:
[MOTIVATION]
[LEARNING TEST CONTEXT — include this section only if learning_tests_required is present in the issue]
[LEARNING TEST CONTEXT BLOCK]
Research the codebase thoroughly to ground your argument. Use Read, Glob, Grep, and Bash tools to find relevant files. Look for:
1. How well this fits existing patterns and architecture
2. Existing code that makes implementation straightforward
3. Gaps or pain points in the current codebase that this issue addresses
4. How acceptance criteria map to concrete, achievable changes
5. Evidence that risk is low (additive changes, no regressions, well-scoped)
6. Precedents — similar issues that were successfully implemented
Produce a structured argument with these exact sections:
**IMPLEMENTATION FEASIBILITY**: How straightforward is implementation? Cite specific files, functions, and line numbers showing where changes would go.
**PATTERN FIT**: Does this align with existing architecture and conventions? Reference specific files that establish the pattern this would follow.
**CLEAR VALUE**: What concrete problem does this solve? Quantify the benefit where possible.
**LOW RISK**: Why is the risk acceptable? Show that changes are additive, reversible, or well-scoped.
**TOP 3 REASONS TO IMPLEMENT**:
1. [Most compelling reason with codebase evidence]
2. [Second reason with evidence]
3. [Third reason with evidence]
Be thorough. Cite specific files and line numbers. Argue forcefully for implementation — do not hedge.
Use this prompt for the con-implementation agent, substituting the actual issue content:
You are a devil's advocate for [ISSUE-ID]: "[ISSUE-TITLE]".
Your task is to research the codebase and build the strongest possible argument AGAINST implementing this issue right now.
Issue Summary:
[ISSUE-SUMMARY]
Acceptance Criteria:
[ACCEPTANCE-CRITERIA]
Motivation:
[MOTIVATION]
[LEARNING TEST CONTEXT — include this section only if learning_tests_required is present in the issue]
[LEARNING TEST CONTEXT BLOCK]
Research the codebase thoroughly to ground your argument. Use Read, Glob, Grep, and Bash tools to find relevant files. Look for:
1. Existing functionality that already covers this need (or could with minor changes)
2. Implementation complexity hidden behind the issue's description
3. Risks: regressions, scope creep, maintenance burden, premature abstraction
4. Poor timing: dependencies not satisfied, competing priorities, incomplete prerequisites
5. Ambiguity or under-specification that would cause implementation churn
6. Whether the effort/value ratio is poor given other priorities
Produce a structured argument with these exact sections:
**EXISTING COVERAGE**: Is there already something that covers this need? Cite specific files, functions, or features that overlap.
**HIDDEN COMPLEXITY**: What complications will emerge during implementation? Show specific areas where the description understates difficulty.
**RISK FACTORS**: What could go wrong or cause regression? Name specific files or systems at risk.
**POOR TIMING**: Why is now not the right time? What prerequisites are missing or competing?
**TOP 3 REASONS NOT TO IMPLEMENT**:
1. [Most compelling reason with codebase evidence]
2. [Second reason with evidence]
3. [Third reason with evidence]
Be thorough. Cite specific files and line numbers. Argue forcefully against implementation — do not hedge.
Wait until both background agents have completed and returned their full outputs. Do not proceed until both have finished.
Launch a foreground judge agent (no run_in_background) using the Agent tool. Inject both argument texts as context in the prompt:
You are an impartial judge evaluating whether issue [ISSUE-ID]: "[ISSUE-TITLE]" should be implemented.
You have received arguments from two independent research agents who examined the codebase:
---
## FOR (Pro-Implementation Argument)
[FULL PRO-AGENT OUTPUT]
---
## AGAINST (Con-Implementation Argument)
[FULL CON-AGENT OUTPUT]
---
[LEARNING TEST CONTEXT — include this section only if learning_tests_required is present in the issue]
[LEARNING TEST CONTEXT BLOCK]
---
Your task: Render an impartial GO or NO-GO verdict based on the evidence presented.
Evaluate these dimensions:
1. **Evidence quality**: Which side has stronger codebase-grounded evidence?
2. **Argument validity**: Are the arguments logically sound? Do they address real concerns?
3. **Risk/value balance**: Does the value justify the risk and effort?
4. **Timing**: Is this the right time given the codebase state?
5. **Proven assumptions**: Are the external API assumptions declared in this issue proven? Refuted or missing assumptions are a hard signal against GO.
Produce your verdict in this EXACT format (do not add any other text):
VERDICT: [GO | NO-GO]
NO-GO REASON: [CLOSE | REFINE | SKIP]
RATIONALE:
[2-4 sentences explaining why you reached this verdict, referencing the strongest arguments from both sides]
KEY ARGUMENTS FOR:
- [Most compelling pro argument with any codebase evidence]
- [Second most compelling pro argument]
KEY ARGUMENTS AGAINST:
- [Most compelling con argument with any codebase evidence]
- [Second most compelling con argument]
DECIDING FACTOR:
[Single most important consideration that tipped the verdict in this direction]
`NO-GO REASON` rules:
- Include this line ONLY when VERDICT is NO-GO. Omit it entirely when VERDICT is GO.
- `CLOSE` — The issue is invalid, already covered by existing functionality, or fundamentally misdirected. Recommended next action: close or archive the issue.
- `REFINE` — The issue is valid but under-specified, ambiguous, or needs additional research before it can be implemented. Recommended next action: run `/ll:refine-issue` or `/ll:ready-issue`.
- `SKIP` — The issue is good but poorly timed: competing priorities, missing prerequisites, or lower value relative to other active work. Recommended next action: keep open, deprioritize, or remove from sprint.
Be decisive. Output ONLY the structured verdict above.
After receiving the judge's output, parse the VERDICT line and, when the verdict is NO-GO, also parse the NO-GO REASON line immediately following it. Display using the = separator convention:
================================================================================
GO/NO-GO: [ISSUE-ID] — [ISSUE-TITLE]
================================================================================
### For (Pro-Implementation)
[Condensed pro arguments — 3-5 bullet points from KEY ARGUMENTS FOR and TOP 3 REASONS]
### Against (Con-Implementation)
[Condensed con arguments — 3-5 bullet points from KEY ARGUMENTS AGAINST and TOP 3 REASONS]
### Judge Verdict: GO ✓ (when verdict is GO)
### Judge Verdict: NO-GO ✗ (CLOSE | REFINE | SKIP) (when verdict is NO-GO — show the parsed reason)
**Rationale**: [RATIONALE from judge]
**Deciding Factor**: [DECIDING FACTOR from judge]
================================================================================
Store both the verdict (GO or NO-GO) and, when applicable, the reason (CLOSE, REFINE, or SKIP) for each issue for use in Phase 4 and Phase 5.
Skip this phase if: CHECK_MODE is true (no writes in check mode).
After displaying the verdict, determine whether there are significant findings to write back. Track HAS_FINDINGS=false; set to true if the judge output contains specific files, functions, or concrete evidence in KEY ARGUMENTS FOR or KEY ARGUMENTS AGAINST that are not already present in the issue body.
Novelty heuristic: Findings are significant if they mention specific file paths, function names, or concrete risks/feasibility points not already referenced in the issue body text.
Interactive mode (AUTO_MODE is false):
If HAS_FINDINGS is true, use AskUserQuestion to ask:
"Should I update the issue file with the go/no-go findings (verdict rationale, key arguments, and deciding factor)?"
Options: Yes / No
Auto mode bypass: When AUTO_MODE is true and HAS_FINDINGS is true, skip the AskUserQuestion prompt and proceed automatically.
No findings case: When HAS_FINDINGS is false (judge output contains no novel file/function references beyond what the issue already documents): Skip (no update needed).
If the user confirms (interactive) or AUTO_MODE is true with findings, use the Edit tool to insert a ## Go/No-Go Findings section into the issue file. Insert before ## Session Log (or before ## Status if no session log section exists):
## Go/No-Go Findings
_Added by `/ll:go-no-go` on [YYYY-MM-DD]_ — **[GO | NO-GO]**
**Deciding Factor**: [DECIDING FACTOR from judge]
### Key Arguments For
- [bullet from KEY ARGUMENTS FOR]
### Key Arguments Against
- [bullet from KEY ARGUMENTS AGAINST]
### Rationale
[RATIONALE from judge]
After writing findings (or skipping), stage the updated issue file:
git add "[issue-file-path]"
Append a decision entry to the log (silent no-op when the decisions log is absent or when CHECK_MODE is true). Storage is hybrid — a legacy .ll/decisions.yaml flat file and/or .ll/decisions.d/*.json fragments — so gate on either (a fresh, never-compacted install has only the fragment dir):
if [ "$CHECK_MODE" != "true" ] && { [ -f .ll/decisions.yaml ] || [ -d .ll/decisions.d ]; }; then
ll-issues decisions add \
--type=decision \
--category="implementation" \
--issue="{{issue_id}}" \
--rule="$VERDICT" \
--rationale="$RATIONALE" \
--enforcement=advisory \
2>/dev/null || true
fi
When more than one issue was evaluated, append a summary table after all individual verdict blocks:
================================================================================
GO/NO-GO SUMMARY
================================================================================
| Issue ID | Title (truncated to 40 chars) | Verdict | Deciding Factor |
|----------|-------------------------------|------------------|-----------------|
| FEAT-808 | go-no-go skill adversarial... | GO ✓ | Fits patterns |
| ENH-712 | ... | NO-GO ✗ (CLOSE) | Already covered |
================================================================================
When CHECK_MODE is true, after all verdicts are displayed:
IF any issue received NO-GO:
for each NO-GO issue:
print "[ID] no-go ([REASON]): [deciding factor from judge]"
# REASON is the parsed NO-GO REASON value: CLOSE, REFINE, or SKIP
print "[N] issue(s) received NO-GO verdict"
exit 1
IF all issues received GO:
print "All [N] issue(s) received GO verdict"
exit 0
This integrates with FSM evaluate: type: exit_code routing (0=success, 1=failure, 2+=error).
After completing all evaluations, append a session log entry to each evaluated issue file.
Locate the session JSONL: Search ~/.claude/projects/ for the directory whose name encodes the current working directory path (separators replaced by dashes). Find the most recently modified .jsonl file that does NOT start with agent-.
Append to ## Session Log in each issue file:
- `/ll:go-no-go` - [ISO timestamp] - `[path to session JSONL]`
If ## Session Log does not exist in the issue file, insert it before ## Status.
Use the Edit tool to append the session log entry. Use Bash(git log --format="%ai" -1) to get the current timestamp if needed, or use the current date in ISO 8601 format.