Feasibility analysis from first principles. Use when: evaluating solutions before tech-spec, comparing approaches, risk assessment. Not for: implementation (use feature-dev), architecture advice (use codex-architect). Output: quantitative comparison + recommendation.
For each solution option, dispatch background exploration:
Agent({
description: "Explore feasibility of solution option",
subagent_type: "feasibility-analyst",
prompt: Research the feasibility of: <solution description> Evaluate technical feasibility, effort, risk, extensibility, and maintenance cost.
})
/deep-analyze)/codex-implement)/codex-explain or /codex-architect)Resolve → Decompose → Constraints → Code research → Solutions → Codex discussion → Decision → Report
The sets Phase 1 reads have to come from somewhere, and this skill is invoked directly
(/feasibility-study <topic>) as often as it is invoked from another skill — so it resolves them
itself rather than assuming a caller supplied them:
# The node entrypoint. The shell wrapper's own header tells skills to prefer this one once they hold
# `Bash(node:*)` — and this skill now does, for its transport dispatches. The wrapper was named here
# only while that grant was absent; keeping it afterwards would have instructed a second-choice
# entrypoint for a reason that had stopped being true.
node scripts/resolve-feature.js [--feature <key>]
The reply is one JSON document. What this skill reads out of it: scan_error first — the gate
below decides whether anything else in the payload means what it says — then current_authority
(what the system does today) and the design_records entries — design records carry the rationale;
it is the type: requirements subset of them that states what was asked for, which is why
Phase 1 filters before it selects. Each entry is
{ file, type, namespace, confidence, is_canonical, role }, file relative to docs_path. An empty or non-JSON reply is a failure too — node may be
unavailable, which the shim cannot report as a payload. Treat it exactly as scan_error !== false
below.
Input source priority:
design_records → consume as the authoritative statement of
what was asked for, validate via 5-Why. It is a design record, not a description of current
behaviour: for "what does the system do today", read code, rules/ and current_authoritydesign_records is an array, so "a requirements doc" needs a rule rather than an assumption — a
split or variant-backed phase contributes more than one. Filter to type: requirements first, then:
| # | Candidates (design_records where type: requirements) | Result |
|---|--------------------------------------------------------|--------|
| 1 | none | Path 2 — extract from user input. A feature with no requirements doc is a normal state, not an exit |
| 2 | exactly one | that one |
| 3 | two or more, exactly one with is_canonical: true | that one |
| 4 | two or more, and none or several canonical | Gate: Need Human, naming the candidates |
Rows 1 and 4 are different answers: "there is none" is acted on, "there are two" must not be
resolved by picking. The same order /architecture applies to its tech-spec candidates.
scan_errorgate. Gate onscan_error !== false, not onscan_error === true. When it is not exactlyfalsethe four source sets are unknown, not empty — the corpus could not be enumerated (unreadable directory, broken taxonomy, no repository), or the resolver never ran and a shell fallback supplied a payload with no such field at all.{}is the shape that made the stricter test useless: it has noscan_error, so=== trueis false and the gate passes a payload that contains nothing. Do not proceed as though the feature has no authority documents — report and take the ⚠️ Need Human exit. Akeymay still be present, so a non-nullkeyis not evidence the sets are complete.
Use "5 Why" to uncover essence:
Inventory constraints by type (Technical, Business, Resource, Compatibility) with flexibility rating.
Research existing codebase:
Brainstorm 2-3+ solutions, each with:
references/analysis-phases.md)⚠️ Core step — not optional (unless --no-codex) ⚠️
See references/codex-discussion-guide.md for full rules and examples.
| Tool | Purpose | When |
|------|---------|------|
| /codex-brainstorm | Enumerate all options | At start |
| /codex-architect | Evaluate design | After proposal forms |
| @skills/codex-code-review/references/codex-transport.md § Resume | Ask details | Anytime |
Side-by-side comparison → recommendation + backup + open questions.
| Dimension | Green | Yellow | Red | | --------------------- | ----- | ------ | --- | | Technical Feasibility | Has existing patterns | Needs adaptation | Major innovation | | Effort | < 3 person-days | 3-10 person-days | > 10 person-days | | Risk | Small scope | Some uncertainty | Many unknowns | | Extensibility | Easy to extend | Needs refactoring | Hard to extend | | Maintenance Cost | Clean, easy | Some complexity | Complex |
## Feasibility Study: <title>
### Quantitative Comparison
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
### Recommendation
<selected option with rationale>
--no-codex)references/analysis-phases.mdreferences/codex-discussion-guide.mdreferences/output-template.md/feasibility-study → /tech-spec → /deep-analyze → /codex-implement
Input: /feasibility-study "Add user quota management"
Action: 5 Why → constraints → code research → 3 solutions → Codex discussion → recommendation
Input: /feasibility-study "Optimize cache" --context src/service/cache.ts
Action: Read cache code → constraints → solutions → Codex brainstorm → comparison → report
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer