Generate SDLC Plan from Context
plan_from_contextGenerate a structured SDLC plan from a goal and repo context, producing tailored phase-by-phase strategies and issue drafts for docs, features, bugfixes, and other work types.
Instructions
Generate a structured Agentic SDLC plan (Plan->Create->Test->Review->Optimize->Secure) from a goal and repo context. The plan is tailored to a workType (docs/feature/bugfix/refactor/security/release/infra) -- e.g. docs tasks do not default to requiring code unit tests, while bugfix tasks always include repro + regression tests.
Template-based -- no LLM call needed. Reads basic repo metadata (and the repo's actual label list, to avoid inventing labels that don't exist) to enrich the plan.
Args:
goal (string): The user's goal or feature description (required).
owner, repo: Repo coordinates (fall back to env vars).
workType (string?): Explicit task category. If omitted, inferred from goal + acceptanceCriteria -- check the output's
confidence/needsClarificationrather than assuming the guess is correct.constraints (string[]?): Technical or business constraints.
acceptanceCriteria (string[]?): Explicit acceptance criteria.
Returns: Phase-by-phase SDLC plan tailored to the (inferred or explicit) work type, plus structured output including workType/confidence/reasoning/needsClarification, and issueDrafts -- structured issue drafts (title/body/labels/phase/acceptanceCriteria/riskLevel) directly usable as create_issue_set's issues input.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | The user goal or feature request to plan around. | |
| repo | No | GitHub repo. Falls back to GITHUB_REPO. | |
| owner | No | GitHub owner. Falls back to GITHUB_OWNER. | |
| workType | No | Explicit task category: docs, feature, bugfix, refactor, security, release, or infra. If omitted, it is inferred from `goal` + `acceptanceCriteria` -- check the output's `confidence` and `needsClarification` fields rather than assuming the guess is correct. | |
| constraints | No | Technical or business constraints. | |
| acceptanceCriteria | No | Acceptance criteria the implementation must satisfy. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| repo | Yes | ||
| risks | Yes | ||
| phases | Yes | ||
| language | Yes | ||
| workType | Yes | ||
| reasoning | Yes | ||
| confidence | Yes | ||
| constraints | Yes | ||
| issueDrafts | Yes | ||
| policyDigest | No | ||
| policyErrors | Yes | ||
| defaultBranch | Yes | ||
| policySources | Yes | ||
| policyDegraded | Yes | ||
| suggestedIssues | Yes | ||
| acceptanceCriteria | Yes | ||
| appliedPolicyRules | Yes | ||
| needsClarification | Yes |