git:20261004.00bb0c5 to git:20261007.b35fc4b

30 added, 18 removed. Audit A to A.

---

name: create-feasibility

description: Assess technical, financial, and operational viability of a feature before committing to requirements.

argument-hint: "[issue-url or feature-name]"

---

# Create Feasibility Assessment

- Produces a structured feasibility assessment for a proposed feature, evaluating technical, financial, and operational viability before the project invests in full requirements gathering. Acts as a go/no-go gate.

+ Produces a structured feasibility assessment for a proposed feature, evaluating technical, financial, and operational viability before the project invests in full requirements gathering.

+ Acts as a go/no-go gate.

## Prerequisites

- Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`.

- If no argument is provided, use `$ISSUE_TITLE` and `$ISSUE_BODY` as the feature description (and `$ISSUE_NUMBER` to link the feature).

- A reviewed, prioritized GitHub issue or feature description provided as `$1`

- `.sdlc/features/N-<slug>/requirements.md`, `existing-solutions.md`, and `codebase-analysis.md` when available: the codebase analysis in particular provides input to the cost and risk of changing existing code

- Read any files present under `.sdlc/context/` (`project-overview.md`, `architecture.md`, `conventions.md`) for project-level context

- Apply any artifact style rules found in `conventions.md` to the produced document

## Steps

- 1. Read the issue or feature description. Fetch from GitHub if a URL is provided.

+ 1. Read the issue or feature description.

+ Fetch from GitHub if a URL is provided.

2. Read `.sdlc/context/architecture.md` to understand the current system and technology stack.

3. Read `.sdlc/context/project-overview.md` to understand project scope and constraints.

4. Read `.sdlc/features/N-<slug>/codebase-analysis.md` when available, and carry its changeability assessments and migration risks into the technical and effort estimates below.

- 5. Assess **technical feasibility**: can the feature be built with the current stack and integrations? Are there unknowns that require a spike?

- 6. Assess **financial feasibility**: what is the estimated effort (S/M/L/XL)? Are there infrastructure, licensing, or third-party costs?

- 7. Assess **operational feasibility**: does the team have the skills and availability? Does it fit the roadmap? What is the maintenance burden?

+ 5. Assess **technical feasibility**: can the feature be built with the current stack and integrations?

+ Are there unknowns that require a spike?

+ 6. Assess **financial feasibility**: what is the estimated effort (S/M/L/XL)?

+ Are there infrastructure, licensing, or third-party costs?

+ 7. Assess **operational feasibility**: does the team have the skills and availability?

+ Does it fit the roadmap?

+ What is the maintenance burden?

8. For each dimension, assign a verdict: Feasible / Feasible with conditions / Not feasible.

- 9. Record assumptions that the feasibility assessment depends on but has not verified. For each assumption that carries meaningful risk (e.g., "the existing ORM supports this query pattern", "the third-party API has no rate limits below our expected volume", "the team has the required expertise"), promote it via `/create-assumption` so it is tracked and can be validated before implementation.

- 10. Derive the overall go/no-go decision. If any dimension is "Not feasible", the overall verdict is "No-go". If any dimension is "Feasible with conditions", list the conditions.

- 11. Derive the feature directory name `N-<slug>` following the Feature Directory Naming convention in `skills/sdlc/references/shared.md`: use the issue number as `N` when one is available, otherwise a `p`-prefixed sequence number (`p1`, `p2`, ...) marking the feature as pending a placeholder issue. Record the related issue number in the frontmatter `issue` field only when an issue exists.

+ 9. Record assumptions that the feasibility assessment depends on but has not verified.

+ For each assumption that carries meaningful risk (e.g., "the existing ORM supports this query pattern", "the third-party API has no rate limits below our expected volume", "the team has the required expertise"), promote it via `/create-assumption` so it is tracked and can be validated before implementation.

+ 10. Derive the overall go/no-go decision.

+ If any dimension is "Not feasible", the overall verdict is "No-go".

+ If any dimension is "Feasible with conditions", list the conditions.

+ 11. Derive the feature directory name `N-<slug>` following the Feature Directory Naming convention in `skills/sdlc/references/shared.md`: use the issue number as `N` when one is available, otherwise a `p`-prefixed sequence number (`p1`, `p2`, ...) marking the feature as pending a placeholder issue.

+ Record the related issue number in the frontmatter `issue` field only when an issue exists.

12. Write the output to `.sdlc/features/N-<slug>/feasibility.md`, creating the directory if it does not exist.

## Output Format

- Use the template at `skills/sdlc/templates/features/feasibility.md` (copied to `.sdlc/templates/features/feasibility.md` by `/initialize-sdlc-directory`; use the project's customized copy if present). Write the result to the artifact path named in the steps above.

+ Use the template at `skills/sdlc/templates/features/feasibility.md` (copied to `.sdlc/templates/features/feasibility.md` by `/initialize-sdlc-directory`; use the project's customized copy if present).

+ Write the result to the artifact path named in the steps above.

## Handling No-Go Verdicts

If the overall verdict is **No-go**:

- Update the issue with the feasibility findings and the rejection rationale.

- Do not create the feature directory or proceed to requirements.

- The issue may be revisited if conditions change (new budget, new technology, reprioritized roadmap).

## Outcome

If `$OUTCOME_YAML` is set, emit your verdict there per `skills/sdlc/references/shared.md`:

| Verdict | Overall go/no-go |

|---|---|

| `approved` | Go or Go with conditions |

| `rejected` | No-go (see Handling No-Go Verdicts) |

In the same emission, list the artifact under `artifacts:` (`.sdlc/features/N-<slug>/feasibility.md`); omit the key when nothing was written (rejected writes no artifact).

## Example Usage

- **Scenario 1: Straightforward feature**

- User describes "add CSV export to the dashboard."

- Current stack already handles file generation. Low effort, no new dependencies. Verdict: Go.

+ **Scenario 1: Straightforward feature** User describes "add CSV export to the dashboard."

+ Current stack already handles file generation.

+ Low effort, no new dependencies.

+ Verdict: Go.

- **Scenario 2: Feature with unknowns**

- User describes "add real-time collaboration like Google Docs."

- Requires WebSocket infrastructure not currently in the stack, high effort, significant operational burden. Verdict: Feasible with conditions (requires infrastructure spike and dedicated team).

+ **Scenario 2: Feature with unknowns** User describes "add real-time collaboration like Google Docs."

+ Requires WebSocket infrastructure not currently in the stack, high effort, significant operational burden.

+ Verdict: Feasible with conditions (requires infrastructure spike and dedicated team).

Assumptions promoted: "the existing load balancer supports WebSocket upgrades" (Medium risk, validate via spike), "the database can handle the expected write throughput of concurrent edits" (High risk, validate via load test).

- **Scenario 3: Clear no-go**

- User describes "migrate the entire platform to a different cloud provider in 2 weeks."

- Not operationally feasible given team size and timeline. Verdict: No-go.

+ **Scenario 3: Clear no-go** User describes "migrate the entire platform to a different cloud provider in 2 weeks."

+ Not operationally feasible given team size and timeline.

+ Verdict: No-go.

## Completion Checklist

Before handing off to review, confirm:

- [ ] Effort sized (S/M/L/XL), with conditions and risks listed for any "Feasible with conditions" verdict

- [ ] Overall go/no-go stated, with No-go if any dimension is Not feasible

- [ ] Risky assumptions promoted via `/create-assumption`

Self-check the draft against the [`review-feasibility` checklist](../review-feasibility/SKILL.md) and fix what you can, so review finds less to flag.

## Next Step

A review subagent is dispatched automatically to run `/review-feasibility` to audit the assessment for completeness, risk coverage, and soundness of the go/no-go decision.

If approved, continue with `/create-specifications`.

## Useful Commands Reference

| Command | Description |

|---|---|

| `gh issue view <url> --comments` | Fetch issue details and comments (cached) |