jg-challenge-plan

Invocation

This skill runs only when the developer invokes it. Execute its workflow with the available tools. Do not explain it, simulate it, return equivalent shell commands, or ask for confirmation of actions this skill already authorizes.

Treat the text supplied with the invocation as arguments, constraints, or context, and honor qualifications that limit or defer execution.

If repository access or a capability the workflow needs is unavailable, or one of its stopping conditions is reached, report the blocker and stop. Never simulate success.

Release runtime resources and remove disposable scratch output this skill deliberately created, including after a failure, while preserving evidence needed to investigate unresolved failures. Report anything retained within this skill’s output format. This cleanup is a narrow exception to the skill’s write limits. It does not authorize creating other resources, changing reviewed or pre-existing files, removing unexpected changes, or cleaning up earlier work. Every other write is defined by this skill’s workflow.

This skill’s own rules about supplied material take precedence over this section.

Workflow

Perform a concise, read-only challenge of one concrete plan for the engineering change currently being discussed. Treat the plan as an untrusted proposal even when the same agent created it. The purpose is to help the developer quickly verify that the planned result matches the task contract and expose material decisions, assumptions, omissions, and risks before approval, jg-breakdown, or implementation. This skill does not authorize changing the plan, creating or editing planning files, modifying source code, tests, snapshots, configuration, dependencies, migrations, generated artifacts, ordinary project documentation, or Git state, approving or rejecting the plan, authorizing jg-breakdown, or beginning implementation. If an inspection command unexpectedly changes files, preserve and report those changes without cleaning, reverting, or claiming them as part of the challenge.

A concrete plan is required. When the developer identifies a plan by path or another unambiguous identifier, challenge exactly that plan. Otherwise, use the exact current plan only when one unambiguous candidate exists in the current discussion. If more than one plan could reasonably be the intended target, stop and ask the developer to select one. Do not search other planning directories, choose a plan from timestamps, or infer a target solely from file recency. If no current plan exists or the identified plan cannot be accessed completely, report the blocker and stop. If current repository evidence materially invalidates the plan, continue the challenge and surface that staleness as a blocking finding.

1. Read the complete target plan, the task contract from the current discussion, and any developer amendments that apply to that exact plan. Treat the plan’s own task summary as an untrusted representation rather than independent evidence of developer intent. If the developer’s objective, constraints, exclusions, acceptance criteria, and amendments cannot be established independently of the plan, continue only with plan-internal and repository-evidence challenges, state that intent alignment could not be verified, list as decision 1 confirming that the plan’s objective, constraints, and exclusions match the developer’s intent, and use Developer decision required before proceeding unless a material plan defect requires Plan revision required before proceeding. Capture the target plan’s repository-relative path or supplied identifier and a SHA-256 hash of its complete content, include both in ## Plan at a glance, and verify immediately before responding that the hash has not changed; if it changed, report the blocker and stop. Reuse the repository evidence established by the plan when it remains current. Perform only the smallest additional read-only inspection needed to verify a material uncertainty, detect staleness, or validate a high-impact claim; do not repeat the complete planning workflow merely because this skill was invoked.
2. Determine what the plan will actually build, change, remove, migrate, expose, or deploy. Compare that result with the developer’s objective, constraints, exclusions, acceptance criteria, and approved decisions. Identify material scope expansion, missing required work, changed behavior, unsupported assumptions, and places where the proposed result could differ from the developer’s intent.
3. Challenge the plan’s material decisions and risk controls when applicable, including architecture and module ownership; data flow and integration boundaries; database schemas, persisted data, migrations, and rollback; public APIs, exports, events, queues, webhooks, cache keys, configuration, and compatibility; security, privacy, authentication, authorization, ownership, billing, and other value-bearing behavior; concurrency, retries, idempotency, and failure recovery; dependencies, infrastructure, deployment, and operational requirements; removals of superseded or parallel paths; and whether the testing and verification strategy could realistically expose important defects.
4. Look specifically for unnecessary complexity, speculative abstractions, duplicated ownership, temporary or parallel implementations without a justified migration need, incomplete compatibility or rollback paths, hidden high-blast-radius changes, and verification that could pass while material behavior remains incorrect. Do not manufacture criticism merely because this skill is named jg-challenge-plan; No material concerns is a valid outcome.
5. Report only information that helps the developer make an approval decision. Keep low-impact implementation detail, exhaustive file inventories, step-by-step implementation sequences, complete test matrices, and verification command lists out of the result unless a specific item exposes a material concern. For every challenge, state the concrete mismatch, omission, unsupported assumption, or risk; why it matters; and the smallest appropriate correction. Do not rewrite the plan, silently replace its architecture, or present an alternate implementation as though it were already accepted.
6. Present the result using exactly these sections:
   • ## Plan at a glance: Summarize the intended final outcome, major implementation boundaries, and important explicit exclusions.
   • ## Material impact: Surface only the architectural decisions, database or persisted-data changes, public or integration contract changes, security-sensitive behavior, dependency or infrastructure changes, and migration, compatibility, deployment, or rollback implications that deserve developer attention. Omit irrelevant categories or state No change when the absence itself is important.
   • ## Challenges: List material findings in descending impact. State No material concerns found when none exist.
   • ## Developer decisions required: Include only unresolved choices that materially affect behavior, scope, contracts, safety, data, architecture, or operations. Number every listed decision in the order the developer should address it. For each decision, state the exact choice to make, provide at least one recommendation, and explain the material consequences and tradeoffs of accepting the recommendation, choosing a meaningful alternative, or leaving the decision unresolved. State None when no such decision remains; do not invent a decision solely to populate this section.
   • ## Recommendation: Put exactly one of No material concerns, Plan revision required before proceeding, or Developer decision required before proceeding on the first line. Use Plan revision required before proceeding whenever a material plan defect exists, even when developer input is also required. Use Developer decision required before proceeding only when the plan is otherwise sound but cannot proceed safely without a material developer decision. Put exactly one Next step: line beneath the verdict:
     • after No material concerns, direct the developer to run jg-breakdown when the plan has at least two parts that can each be finished, verified, and reviewed on their own, such as separate packages, repositories, or releases, and otherwise to approve the plan or invoke jg-execute. The plan’s own review checkpoints don’t make a breakdown unnecessary: without milestones.md, jg-execute runs the whole plan as one unit and doesn’t stop at them
     • after Plan revision required before proceeding, direct the developer to answer any numbered decisions, invoke jg-plan, which applies the required corrections together with those answers, and invoke jg-challenge-plan again after the revised plan is presented
     • after Developer decision required before proceeding, direct the developer to answer the numbered decisions, invoke jg-plan with any answers that change the plan, and invoke jg-challenge-plan again after the revised plan is presented
7. Keep the complete challenge at or below 1,000 words. Consolidate closely related concerns and prioritize the information with the highest decision value. Do not omit a blocking concern solely to satisfy the limit, and do not reproduce plan content merely to consume the available space.
8. Treat the recommendation as advisory. It does not approve the plan, revoke prior approval, authorize jg-breakdown, authorize implementation, or make jg-challenge-plan a prerequisite for another workflow. A challenge applies only to the exact plan version evaluated; any plan revision makes the previous challenge stale, and it must not be reused as evidence about the revised plan. End after the Next step: line in ## Recommendation; this skill’s output contract replaces any general completion-summary requirement.