📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,5 @@
|
||||
---
|
||||
description: Display current session ID
|
||||
---
|
||||
|
||||
`${CLAUDE_SESSION_ID}`
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
description: Collaborative Q&A to clarify unclear requirements and reach a clear path
|
||||
argument-hint: [topic, problem, or feature to explore]
|
||||
---
|
||||
|
||||
# Pathfinding
|
||||
|
||||
Adaptive Q&A workflow to clarify requirements and build confidence before delivering.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Load** — Use the Skill tool to load the **outfitter:pathfinding** skill
|
||||
2. **Consider** — Assess the context below and recent conversation. Ultrathink.
|
||||
3. **Execute** — Begin the pathfinding workflow per the skill
|
||||
|
||||
## Guidance
|
||||
|
||||
- This may be greenfield exploration — help shape the idea, not just refine it
|
||||
- Use EnterPlanMode for questions (enables keyboard selection)
|
||||
- Ask about literally anything: scope, constraints, tradeoffs, UX, technical approach, concerns
|
||||
- Make sure questions are non-obvious — don't re-ask what's already clear from context
|
||||
- Be persistent — continue until confidence level 5 or user requests early delivery
|
||||
|
||||
## Context
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
description: Orchestrate multiple agents for complex multi-domain tasks
|
||||
argument-hint: [task description requiring coordination]
|
||||
---
|
||||
|
||||
# Agent Dispatch
|
||||
|
||||
Coordinate multiple agents to accomplish a complex task requiring different expertise areas.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Consider the recent conversation history, your context, and the task to be accomplished.
|
||||
- Specific user instructions should be followed unless they are contradictory to the task at hand. $ARGUMENTS
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Load Skills** — Use the Skill tool to load:
|
||||
- **outfitter:subagents** — agent routing and orchestration patterns
|
||||
- **outfitter:context-management** — for long-running tasks, teaches Task state persistence
|
||||
2. **Consider** — Ultrathink and analyze the task, consider the complexity, sequence of steps, and agent requirements.
|
||||
3. **Planning** — Use the **Plan subagent** to research the codebase and design an orchestration strategy
|
||||
4. **Report** — Present the orchestration plan (which agents, what sequence, expected handoffs)
|
||||
- **IMPORTANT**: After presenting the orchestration plan, proceed directly to execution.
|
||||
- Do not wait for approval unless the task is high-risk (destructive changes, production deployment, security-sensitive).
|
||||
5. **Execute** — Dispatch agents according to the plan, passing context between them
|
||||
6. **Persist** — Update Tasks throughout with agent IDs, decisions, and progress (survives compaction)
|
||||
|
||||
## Planning Process
|
||||
|
||||
Ensure you've loaded the **outfitter:subagents** skill. Then coordinate with the **Plan subagent** to design the orchestration plan. Task the **Plan subagent** to:
|
||||
|
||||
1. Explore the relevant parts of the codebase
|
||||
2. Identify which roles are needed (coding, reviewing, research, testing, etc.)
|
||||
3. Determine the best available agents for each role
|
||||
4. Design the execution sequence (sequential, parallel, or hybrid)
|
||||
5. Return a concise orchestration plan
|
||||
|
||||
After receiving the plan, think about if you agree with it, make adjustments where necessary, and proceed with the next steps mentioned above.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
description: Systematic debugging with root cause investigation - no random trial-and-error
|
||||
argument-hint: [bug description or error message]
|
||||
---
|
||||
|
||||
# Systematic Debugging
|
||||
|
||||
Start a methodical debugging session using the four-stage investigation framework with iterative review.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Consider the recent conversation history, your context, and the problem to be debugged.
|
||||
- Specific user instructions should be followed unless they are contradictory to the task at hand. $ARGUMENTS
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Load** — Use the Skill tool and load the **outfitter:debugging** skill
|
||||
2. **Consider** — Ultrathink and analyze the problem, consider available evidence, potential causes, and investigation approach
|
||||
3. **Dispatch or Execute** — Choose execution path based on available tools:
|
||||
- **If Task tool available**: Run the debug loop (see below)
|
||||
- **If Task tool unavailable**: Execute the debugging methodology directly using the loaded skill
|
||||
|
||||
## Debug Loop (when Task tool available)
|
||||
|
||||
Run iterative cycles until the issue is resolved:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 1. INVESTIGATE — Dispatch outfitter:debugger │
|
||||
│ └─ Collect evidence, form hypothesis, propose fix │
|
||||
│ ↓ │
|
||||
│ 2. REVIEW — Dispatch outfitter:reviewer │
|
||||
│ └─ Validate fix, check for regressions, verify │
|
||||
│ root cause addressed (not just symptoms) │
|
||||
│ ↓ │
|
||||
│ 3. EVALUATE — Check review outcome │
|
||||
│ └─ If approved → Done │
|
||||
│ └─ If issues found → Back to step 1 with feedback │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Loop Execution
|
||||
|
||||
1. **Dispatch debugger** (background) — Pass error context, evidence, any prior feedback
|
||||
2. **Retrieve results** — Use TaskOutput to get proposed fix and rationale
|
||||
3. **Dispatch reviewer** (background) — Pass the proposed fix and debugger's findings for code review
|
||||
4. **Retrieve review** — Use TaskOutput to get validation results
|
||||
5. **Evaluate**:
|
||||
- **Approved**: Report success, document root cause and fix
|
||||
- **Issues found**: Loop back to debugger with reviewer feedback
|
||||
- **Max iterations (3)**: Escalate to user with findings so far
|
||||
|
||||
### Context Accumulation
|
||||
|
||||
Each loop iteration passes forward:
|
||||
- Original error context
|
||||
- Investigation findings from debugger
|
||||
- Review feedback from reviewer
|
||||
- Cumulative hypotheses tested
|
||||
|
||||
## The Iron Law
|
||||
|
||||
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
|
||||
|
||||
If you catch yourself wanting to "just try something" — stop. Return to investigation.
|
||||
|
||||
## Context Handoff (for initial dispatch)
|
||||
|
||||
When dispatching to the debugger subagent, include:
|
||||
- Exact error messages or unexpected behavior
|
||||
- Stack traces if available
|
||||
- Recent changes (git diff context)
|
||||
- Reproduction steps if known
|
||||
- Any hypotheses already formed
|
||||
- Prior loop feedback (if iterating)
|
||||
@@ -0,0 +1,87 @@
|
||||
---
|
||||
description: Audit plugin and optionally apply auto-fixes
|
||||
argument-hint: [plugin path]
|
||||
allowed-tools: Read Write Edit Grep Glob Bash Task Skill
|
||||
---
|
||||
|
||||
# Plugin Audit
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## Steps
|
||||
|
||||
1. Delegate by loading the `outfitter:claude-plugin-audit` skill for plugin analysis
|
||||
2. Review findings and identify auto-fixable issues
|
||||
3. If auto-fixable issues exist, offer to apply fixes
|
||||
4. For applied fixes, verify each change
|
||||
5. Enter Plan mode
|
||||
6. Present remaining issues that need manual attention with the `AskUserQuestion`
|
||||
|
||||
## Workflow
|
||||
|
||||
### Stage 1: Audit
|
||||
|
||||
Run the plugin audit skill on the target path. If no path provided, use current directory.
|
||||
|
||||
Capture:
|
||||
- Critical issues (blocking)
|
||||
- Warnings (should fix)
|
||||
- Info (suggestions)
|
||||
- Which issues are auto-fixable
|
||||
|
||||
### Stage 2: Auto-Fix Decision
|
||||
|
||||
If auto-fixable issues found:
|
||||
|
||||
```text
|
||||
Found {N} auto-fixable issues:
|
||||
- {issue 1}
|
||||
- {issue 2}
|
||||
|
||||
Apply automatic fixes? (will show each change)
|
||||
```
|
||||
|
||||
Use `AskUserQuestion` with options:
|
||||
1. Apply all auto-fixes
|
||||
2. Review each fix individually
|
||||
3. Skip auto-fixes, show manual issues only
|
||||
|
||||
### Stage 3: Apply Fixes
|
||||
|
||||
For each auto-fix:
|
||||
1. Show the proposed change
|
||||
2. Apply the fix
|
||||
3. Verify the fix worked
|
||||
|
||||
Use Tasks to what was fixed vs what remains.
|
||||
|
||||
### Stage 4: Follow-Up
|
||||
|
||||
Present remaining issues that need manual attention:
|
||||
|
||||
```text
|
||||
## Remaining Issues
|
||||
|
||||
### Critical (must fix manually)
|
||||
- {issue with guidance}
|
||||
|
||||
### Warnings (recommended)
|
||||
- {issue with guidance}
|
||||
|
||||
## Next Steps
|
||||
- {specific action items}
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
Final summary:
|
||||
|
||||
```text
|
||||
# Plugin Audit Complete
|
||||
|
||||
**Plugin**: {name}
|
||||
**Auto-fixes applied**: {N}
|
||||
**Remaining issues**: {N} critical, {N} warnings
|
||||
|
||||
{next steps or "Plugin is ready for distribution"}
|
||||
```
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
description: Check open PR status, review comments, and CI status
|
||||
argument-hint: [--repo org/repo]
|
||||
---
|
||||
|
||||
# PR Check
|
||||
|
||||
Display status of open pull requests including draft state, CI checks, review status, and unresolved comments.
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
/pr:check # Check current repo
|
||||
/pr:check --repo org/repo # Check specific repo
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- Number of open PRs
|
||||
- PR number, title, author
|
||||
- Draft vs ready status
|
||||
- CI check status (passing/failing/pending)
|
||||
- Review decision (approved/changes requested/pending)
|
||||
- Count of unresolved review threads
|
||||
- Preview of unresolved comments
|
||||
|
||||
---
|
||||
|
||||
Run the PR status script:
|
||||
|
||||
```bash
|
||||
bun ${CLAUDE_PLUGIN_ROOT}/commands/pr/scripts/pr-status.ts $ARGUMENTS
|
||||
```
|
||||
|
||||
Present the output to the user. If there are unresolved review comments, offer to help address them.
|
||||
@@ -0,0 +1,306 @@
|
||||
#!/usr/bin/env bun
|
||||
/**
|
||||
* PR Status Script
|
||||
* Fetches open PRs for a repository with review comments and status info.
|
||||
*
|
||||
* Usage:
|
||||
* bun pr-status.ts [--repo org/repo]
|
||||
*
|
||||
* If --repo is omitted, uses the current repository.
|
||||
*/
|
||||
|
||||
import { $ } from "bun";
|
||||
|
||||
/**
|
||||
* A PR review thread with resolution status.
|
||||
*/
|
||||
interface ReviewThread {
|
||||
/** Whether the thread has been resolved */
|
||||
isResolved: boolean;
|
||||
/** Comments in the thread */
|
||||
comments: { body: string; author: { login: string } }[];
|
||||
}
|
||||
|
||||
/**
|
||||
* Normalized pull request data for display.
|
||||
*/
|
||||
interface PR {
|
||||
/** PR number */
|
||||
number: number;
|
||||
/** PR title */
|
||||
title: string;
|
||||
/** URL to the PR on GitHub */
|
||||
url: string;
|
||||
/** Whether PR is in draft state */
|
||||
isDraft: boolean;
|
||||
/** PR author info */
|
||||
author: { login: string };
|
||||
/** Branch name */
|
||||
headRefName: string;
|
||||
/** ISO timestamp of creation */
|
||||
createdAt: string;
|
||||
/** ISO timestamp of last update */
|
||||
updatedAt: string;
|
||||
/** Review decision (APPROVED, CHANGES_REQUESTED, etc.) */
|
||||
reviewDecision: string | null;
|
||||
/** CI/CD check status rollup */
|
||||
statusCheckRollup: {
|
||||
state: string;
|
||||
contexts: { name: string; state: string; conclusion: string | null }[];
|
||||
} | null;
|
||||
/** Review comment threads */
|
||||
reviewThreads: { nodes: ReviewThread[] };
|
||||
}
|
||||
|
||||
/**
|
||||
* Raw PR response structure from GitHub GraphQL API.
|
||||
*/
|
||||
interface PRResponse {
|
||||
/** PR number */
|
||||
number: number;
|
||||
/** PR title */
|
||||
title: string;
|
||||
/** URL to the PR */
|
||||
url: string;
|
||||
/** Draft state */
|
||||
isDraft: boolean;
|
||||
/** Author info */
|
||||
author: { login: string };
|
||||
/** Branch name */
|
||||
headRefName: string;
|
||||
/** Creation timestamp */
|
||||
createdAt: string;
|
||||
/** Last update timestamp */
|
||||
updatedAt: string;
|
||||
/** Review decision */
|
||||
reviewDecision: string | null;
|
||||
/** Commits with status checks */
|
||||
commits: {
|
||||
nodes: {
|
||||
commit: {
|
||||
statusCheckRollup: {
|
||||
state: string;
|
||||
contexts: {
|
||||
nodes: { name: string; state: string; conclusion: string | null }[];
|
||||
};
|
||||
} | null;
|
||||
};
|
||||
}[];
|
||||
};
|
||||
/** Review threads */
|
||||
reviewThreads: { nodes: ReviewThread[] };
|
||||
}
|
||||
|
||||
function parseArgs(): { repo: string | null } {
|
||||
const args = process.argv.slice(2);
|
||||
let repo: string | null = null;
|
||||
|
||||
for (let i = 0; i < args.length; i++) {
|
||||
if (args[i] === "--repo" && args[i + 1]) {
|
||||
repo = args[i + 1];
|
||||
i++;
|
||||
}
|
||||
}
|
||||
|
||||
return { repo };
|
||||
}
|
||||
|
||||
async function getRepo(specified: string | null): Promise<string> {
|
||||
if (specified) return specified;
|
||||
|
||||
const result =
|
||||
await $`gh repo view --json nameWithOwner -q '.nameWithOwner'`.text();
|
||||
return result.trim();
|
||||
}
|
||||
|
||||
async function fetchPRs(repo: string): Promise<PR[]> {
|
||||
const query = `
|
||||
query($repo: String!, $owner: String!) {
|
||||
repository(name: $repo, owner: $owner) {
|
||||
pullRequests(first: 50, states: OPEN, orderBy: {field: UPDATED_AT, direction: DESC}) {
|
||||
nodes {
|
||||
number
|
||||
title
|
||||
url
|
||||
isDraft
|
||||
author { login }
|
||||
headRefName
|
||||
createdAt
|
||||
updatedAt
|
||||
reviewDecision
|
||||
commits(last: 1) {
|
||||
nodes {
|
||||
commit {
|
||||
statusCheckRollup {
|
||||
state
|
||||
contexts(first: 20) {
|
||||
nodes {
|
||||
... on CheckRun {
|
||||
name
|
||||
conclusion
|
||||
status
|
||||
}
|
||||
... on StatusContext {
|
||||
context
|
||||
state
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
reviewThreads(first: 50) {
|
||||
nodes {
|
||||
isResolved
|
||||
comments(first: 1) {
|
||||
nodes {
|
||||
body
|
||||
author { login }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
`;
|
||||
|
||||
const [owner, name] = repo.split("/");
|
||||
const result =
|
||||
await $`gh api graphql -f query=${query} -f owner=${owner} -f repo=${name}`.json();
|
||||
|
||||
const prs = result.data.repository.pullRequests.nodes as PRResponse[];
|
||||
|
||||
return prs.map((pr) => ({
|
||||
number: pr.number,
|
||||
title: pr.title,
|
||||
url: pr.url,
|
||||
isDraft: pr.isDraft,
|
||||
author: pr.author,
|
||||
headRefName: pr.headRefName,
|
||||
createdAt: pr.createdAt,
|
||||
updatedAt: pr.updatedAt,
|
||||
reviewDecision: pr.reviewDecision,
|
||||
statusCheckRollup: pr.commits.nodes[0]?.commit.statusCheckRollup
|
||||
? {
|
||||
state: pr.commits.nodes[0]!.commit.statusCheckRollup!.state,
|
||||
contexts:
|
||||
pr.commits.nodes[0]!.commit.statusCheckRollup!.contexts.nodes.map(
|
||||
(ctx: Record<string, unknown>) => ({
|
||||
name: (ctx.name as string) || (ctx.context as string) || "",
|
||||
state: (ctx.status as string) || (ctx.state as string) || "",
|
||||
conclusion: (ctx.conclusion as string) || null,
|
||||
}),
|
||||
),
|
||||
}
|
||||
: null,
|
||||
reviewThreads: pr.reviewThreads,
|
||||
}));
|
||||
}
|
||||
|
||||
function formatStatus(pr: PR): string {
|
||||
if (!pr.statusCheckRollup) return "none";
|
||||
|
||||
const state = pr.statusCheckRollup.state;
|
||||
switch (state) {
|
||||
case "SUCCESS":
|
||||
return "passing";
|
||||
case "FAILURE":
|
||||
case "ERROR":
|
||||
return "failing";
|
||||
case "PENDING":
|
||||
return "pending";
|
||||
default:
|
||||
return state.toLowerCase();
|
||||
}
|
||||
}
|
||||
|
||||
function formatReviewDecision(decision: string | null): string {
|
||||
if (!decision) return "pending";
|
||||
switch (decision) {
|
||||
case "APPROVED":
|
||||
return "approved";
|
||||
case "CHANGES_REQUESTED":
|
||||
return "changes requested";
|
||||
case "REVIEW_REQUIRED":
|
||||
return "review required";
|
||||
default:
|
||||
return decision.toLowerCase();
|
||||
}
|
||||
}
|
||||
|
||||
function countUnresolvedThreads(pr: PR): number {
|
||||
return pr.reviewThreads.nodes.filter((t) => !t.isResolved).length;
|
||||
}
|
||||
|
||||
function formatOutput(repo: string, prs: PR[]): void {
|
||||
console.log(`\n## PR Status: ${repo}\n`);
|
||||
console.log(`**Open PRs:** ${prs.length}\n`);
|
||||
|
||||
if (prs.length === 0) {
|
||||
console.log("No open pull requests.");
|
||||
return;
|
||||
}
|
||||
|
||||
console.log(
|
||||
"| # | Title | Author | State | Checks | Review | Unresolved |",
|
||||
);
|
||||
console.log(
|
||||
"|---|-------|--------|-------|--------|--------|------------|",
|
||||
);
|
||||
|
||||
for (const pr of prs) {
|
||||
const title =
|
||||
pr.title.length > 40 ? `${pr.title.slice(0, 37)}...` : pr.title;
|
||||
const state = pr.isDraft ? "draft" : "ready";
|
||||
const unresolved = countUnresolvedThreads(pr);
|
||||
const unresolvedStr = unresolved > 0 ? `${unresolved}` : "-";
|
||||
|
||||
console.log(
|
||||
`| [#${pr.number}](${pr.url}) | ${title} | @${pr.author.login} | ${state} | ${formatStatus(pr)} | ${formatReviewDecision(pr.reviewDecision)} | ${unresolvedStr} |`,
|
||||
);
|
||||
}
|
||||
|
||||
// Detailed unresolved comments section
|
||||
const prsWithUnresolved = prs.filter(
|
||||
(pr) => countUnresolvedThreads(pr) > 0,
|
||||
);
|
||||
if (prsWithUnresolved.length > 0) {
|
||||
console.log("\n### Unresolved Review Comments\n");
|
||||
for (const pr of prsWithUnresolved) {
|
||||
const threads = pr.reviewThreads.nodes.filter((t) => !t.isResolved);
|
||||
console.log(`**#${pr.number}** - ${threads.length} unresolved:`);
|
||||
for (const thread of threads.slice(0, 5)) {
|
||||
const comment = thread.comments.nodes[0];
|
||||
if (comment) {
|
||||
const preview =
|
||||
comment.body.length > 80
|
||||
? `${comment.body.slice(0, 77)}...`
|
||||
: comment.body;
|
||||
console.log(` - @${comment.author.login}: ${preview}`);
|
||||
}
|
||||
}
|
||||
if (threads.length > 5) {
|
||||
console.log(` - ... and ${threads.length - 5} more`);
|
||||
}
|
||||
console.log();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
async function main() {
|
||||
const { repo: specifiedRepo } = parseArgs();
|
||||
|
||||
try {
|
||||
const repo = await getRepo(specifiedRepo);
|
||||
const prs = await fetchPRs(repo);
|
||||
formatOutput(repo, prs);
|
||||
} catch (error) {
|
||||
console.error("Error fetching PR status:", error);
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
main();
|
||||
@@ -0,0 +1,126 @@
|
||||
---
|
||||
description: Challenge complexity and find simpler alternatives before implementing
|
||||
argument-hint: [proposed solution or approach to evaluate]
|
||||
---
|
||||
|
||||
# Challenge Complexity
|
||||
|
||||
Evaluate the proposed solution for unnecessary complexity before committing to it.
|
||||
|
||||
## Instructions
|
||||
|
||||
- Consider the recent conversation history, your context, and the proposal to be evaluated.
|
||||
- Specific user instructions should be followed unless they are contradictory to the task at hand. $ARGUMENTS
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Load** — Use the Skill tool and load the **outfitter:simplify** skill
|
||||
2. **Consider** — Ultrathink and analyze the proposal, identify initial complexity concerns
|
||||
3. **Dispatch or Execute** — Choose execution path based on available tools:
|
||||
- **If Task tool available**: Run the simplify loop (see below)
|
||||
- **If Task tool unavailable**: Execute the complexity analysis methodology directly using the loaded skill
|
||||
|
||||
## Simplify Loop (when Task tool available)
|
||||
|
||||
Run iterative cycles with a persistent skeptic agent until complexity is resolved:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 1. ANALYZE — Dispatch outfitter:skeptic │
|
||||
│ └─ Examine proposal, identify complexity triggers, │
|
||||
│ generate alternatives, return structured findings │
|
||||
│ ↓ │
|
||||
│ 2. PRESENT — Share findings with user │
|
||||
│ └─ Escalation level, alternatives, probing questions │
|
||||
│ ↓ │
|
||||
│ 3. DISCUSS — Gather user response │
|
||||
│ └─ User provides context, answers questions, │
|
||||
│ or asks skeptic to dig deeper │
|
||||
│ ↓ │
|
||||
│ 4. EVALUATE — Determine next action │
|
||||
│ └─ If resolved → Document decision │
|
||||
│ └─ If more analysis needed → Resume skeptic (step 1) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Loop Execution
|
||||
|
||||
1. **Initial dispatch** — Pass proposal, context, requirements to skeptic
|
||||
2. **Retrieve results** — Use TaskOutput to get structured JSON analysis
|
||||
3. **Present to user** — Share escalation level, alternatives, and probing questions
|
||||
4. **Gather feedback** — User may:
|
||||
- Answer probing questions (pass answers back to skeptic)
|
||||
- Ask skeptic to examine specific aspects deeper
|
||||
- Accept an alternative and proceed
|
||||
- Justify complexity with evidence (skeptic validates)
|
||||
5. **Resume or conclude**:
|
||||
- **More analysis needed**: Resume same skeptic agent with `resume: {agentId}` and new context
|
||||
- **Decision reached**: Document outcome (proceed with simple, proceed with justified complexity, or revisit approach)
|
||||
|
||||
### Resumable Skeptic Pattern
|
||||
|
||||
The skeptic maintains context across invocations via the `resume` parameter:
|
||||
|
||||
```
|
||||
Initial dispatch:
|
||||
→ skeptic analyzes proposal
|
||||
→ returns findings + agentId: "abc123"
|
||||
|
||||
User provides additional context:
|
||||
→ resume skeptic with { resume: "abc123" }
|
||||
→ skeptic refines analysis with new information
|
||||
|
||||
User asks about specific concern:
|
||||
→ resume skeptic with { resume: "abc123" }
|
||||
→ skeptic digs deeper on that aspect
|
||||
```
|
||||
|
||||
This preserves the skeptic's understanding of the proposal through multiple rounds of refinement.
|
||||
|
||||
## The Framework
|
||||
|
||||
1. IDENTIFY — what complexity is being proposed?
|
||||
2. ALTERNATIVE — what's the simplest thing that could work?
|
||||
3. QUESTION — why isn't the simple approach sufficient?
|
||||
4. DOCUMENT — if complexity is justified, record why
|
||||
|
||||
## Context Handoff (for initial dispatch)
|
||||
|
||||
When dispatching to the skeptic subagent, include:
|
||||
- The proposed solution or approach
|
||||
- Current requirements and constraints
|
||||
- Any justifications already offered
|
||||
- Team/project context if relevant
|
||||
|
||||
When resuming the skeptic, include:
|
||||
- User's answers to probing questions
|
||||
- Additional context or constraints revealed
|
||||
- Specific areas to examine further
|
||||
- Evidence offered to justify complexity
|
||||
|
||||
## Red Flag Rationalizations
|
||||
|
||||
Watch for these justifications — they usually indicate unjustified complexity:
|
||||
|
||||
- "We might need this later"
|
||||
- "It's more flexible this way"
|
||||
- "This is how X company does it"
|
||||
- "It's the industry standard"
|
||||
- "We should do it right the first time"
|
||||
|
||||
## Verdicts and Outcomes
|
||||
|
||||
The skeptic returns one of three verdicts:
|
||||
|
||||
| Verdict | Meaning | Action |
|
||||
|---------|---------|--------|
|
||||
| **proceed** | Complexity is minor (◇) | Note alternatives, continue |
|
||||
| **caution** | Complexity is moderate (◆) | Discuss before proceeding |
|
||||
| **block** | Complexity is high risk (◆◆) | Address concerns first |
|
||||
|
||||
After discussion, document the outcome:
|
||||
- **Simplified**: Chose simpler alternative
|
||||
- **Justified**: Complexity validated with evidence, documented in ADR
|
||||
- **Deferred**: Needs more investigation, created follow-up task
|
||||
|
||||
The goal is NOT to reject all complexity — it's to ensure complexity is justified by evidence, not speculation.
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
description: Generate comprehensive status report across VCS, PRs, issues, and CI/CD
|
||||
argument-hint: [time range and/or services: graphite, github, linear, beads, all]
|
||||
---
|
||||
|
||||
# Situation Report
|
||||
|
||||
Generate a scannable status report for the current project.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Detect** — Load the `check-status` skill and run the detection script.
|
||||
2. **Consider** — Parse the context below for time range and service filters. Ultrathink.
|
||||
3. **Dispatch** — Launch the **outfitter:scout** agent via Task tool with detected services and context
|
||||
4. **Retain** — Keep the agent ID for follow-up questions (use `resume` parameter)
|
||||
|
||||
## Guidance
|
||||
|
||||
- Pass detected services to scout so it knows what to query
|
||||
- Default time range: 24 hours if not specified
|
||||
- Lead with attention-needed items (blockers, failing CI, stale branches)
|
||||
- Present for quick scanning — user should gain situational awareness in 30 seconds
|
||||
|
||||
## Context
|
||||
|
||||
- $ARGUMENTS
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
description: Check available CLI tools and get recommendations
|
||||
argument-hint: [category: search|json|viewers|navigation|http]
|
||||
---
|
||||
|
||||
# Tool Check
|
||||
|
||||
Detect available modern CLI tools and get recommendations for your environment.
|
||||
|
||||
## Quick Check
|
||||
|
||||
Run the detection script:
|
||||
|
||||
```bash
|
||||
bun outfitter/skills/which-tool/scripts/index.ts
|
||||
```
|
||||
|
||||
Filter by category:
|
||||
|
||||
```bash
|
||||
bun outfitter/skills/which-tool/scripts/index.ts -c search
|
||||
```
|
||||
|
||||
## Context
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
---
|
||||
|
||||
Load the **which-tool** skill and:
|
||||
|
||||
1. Run the tool detection script (with category filter if provided)
|
||||
2. Report which tools are available vs missing
|
||||
3. For missing tools, note install commands if user wants them
|
||||
4. If selecting a tool for a task, use the selection matrix from the skill
|
||||
|
||||
Use modern tools when available. Fall back gracefully when not.
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: Create a handoff note for session continuity
|
||||
allowed-tools: Read Edit
|
||||
---
|
||||
|
||||
# Handoff
|
||||
|
||||
Creating handoff note for this session.
|
||||
|
||||
!`bun ${CLAUDE_PLUGIN_ROOT}/skills/trails/scripts/handoff.ts --session "${CLAUDE_SESSION_ID}"`
|
||||
|
||||
Read the created handoff file and fill in the sections:
|
||||
|
||||
- **Done**: What was accomplished this session
|
||||
- **State**: Current state of work (in progress, blocked, etc.)
|
||||
- **Next**: What should happen next (use checkboxes)
|
||||
|
||||
Keep entries scannable — someone should grasp the session in 30 seconds.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
description: Create a timestamped log note
|
||||
argument-hint: <slug>
|
||||
allowed-tools: Read Edit
|
||||
---
|
||||
|
||||
# Log
|
||||
|
||||
Creating log note with slug: **$ARGUMENTS**
|
||||
|
||||
!`bun ${CLAUDE_PLUGIN_ROOT}/skills/trails/scripts/log.ts --slug "$ARGUMENTS" --session "${CLAUDE_SESSION_ID}"`
|
||||
|
||||
Read the created log file. This is a freeform note for capturing:
|
||||
|
||||
- Research findings
|
||||
- Technical discoveries
|
||||
- Meeting notes
|
||||
- Ideas and observations
|
||||
|
||||
Add relevant content and tags as needed.
|
||||
@@ -0,0 +1,18 @@
|
||||
---
|
||||
description: Read recent trail notes
|
||||
argument-hint: "[handoff|log] [--days N]"
|
||||
allowed-tools: Bash
|
||||
---
|
||||
|
||||
# Read Trail
|
||||
|
||||
Reading recent trail notes.
|
||||
|
||||
Arguments: $ARGUMENTS
|
||||
|
||||
```bash
|
||||
!bun ${CLAUDE_PLUGIN_ROOT}/skills/trails/scripts/read.ts $ARGUMENTS --no-frontmatter
|
||||
```
|
||||
|
||||
Use `--type handoff` for handoffs only, `--type log` for logs only.
|
||||
Use `--days N` to read more history (default: 1 day).
|
||||
Reference in New Issue
Block a user