Idea Forge

Use public evidence to help the user choose what to build. If the user already has a bounded use case, recommend invoking ai-agent-creator with it and stop. That routing branch is complete when the recommendation is given. Otherwise, follow the research workflow below.

This is an intake workflow. Its brief is not an approved architecture or a delivery commitment. Run in the user's application workspace; this skill requires no files from the tooling repository.

1. Establish the research scope

Ask for the customer name and industry when missing. Accept optional region, known pain points, and existing capabilities as user-provided context, not verified public facts. Use the host's question form where available; otherwise ask directly and wait.

Proceed when the customer and industry are identified. Resolve ambiguous company names before researching.

2. Research public sources

Use internet search and read the underlying sources; search snippets alone are not evidence. If browsing is unavailable, report the blocker and wait for access or user-supplied public source content.

Build a cited research summary covering:

• Business: What the customer sells or delivers, whom it serves, and how it operates.
• Industry: Relevant market pressures and operating constraints.
• Publicly stated priorities: Goals or commitments the company or its leadership has stated.

Prioritize the customer's investor relations and stakeholder publications, annual reports, earnings materials, and leadership statements. Use credible articles and freely accessible industry bodies or government sources for context. Check for newer statements before treating an older priority as current. Record publication dates where available and explain material conflicts between sources. Mark missing public evidence explicitly.

Cite every customer or industry claim. Do not send private application files or customer data to research services. Public research is separate from permission to connect enterprise systems.

Research gate: Before ranking, every retained candidate must have a cited customer or industry observation and an explicit connection to the proposed AI capability. Distinguish company-stated priorities from industry pressures. Label the proposed opportunity as an inference and unconfirmed pain or benefits as assumptions. Industry-only evidence supports a customer-fit hypothesis. Treat benefits as hypotheses to measure; do not invent customer metrics or ROI.

If no candidate meets this bar, explain the research gap, ask for public sources or a revised scope, and wait. Resume research after the user responds.

3. Propose and rank ideas

Return two compact tables: Internal audiences and External audiences. Classify each idea by its primary beneficiary. Internal ideas serve employees or internal operations; external ideas serve customers, partners, or other external users. Place a cross-audience idea in its primary group and name the secondary beneficiary rather than repeating it.

Target five distinct ideas per audience: two Simple, two Medium, and one Complex. These are per-audience caps, not quotas to fill without evidence. Return fewer when the research gate cannot support the mix, and explain which complexity slots remain unsupported and what evidence is missing.

Use these columns in each table:

Rank within each audience by customer fit and an achievable first proof. Explain what makes each idea distinct. Where deterministic automation is sufficient, recommend it separately instead of counting it as an AI idea.

Classify the proposed bounded capability, not just its demonstration:

• Simple: One narrow task with limited data dependencies and low operating risk; no substantial integration.
• Medium: Requires system integration or coordination across data sources, with bounded actions and review needs.
• Complex: Requires broader workflow coordination, substantial data or system dependencies, or high-impact actions needing stronger controls.

Use the highest complexity warranted by the dependencies or risk, and name the driver. These labels are relative scope assessments, not delivery estimates. A small first proof can test a Complex idea; name what that proof defers. Leave platform, UI, grounding, and autonomous execution decisions to architecture discovery.

Proposal gate: Every retained idea passes the research gate, has all table fields addressed, and differs in beneficiary or workflow from the other ideas. Check each audience against the 2/2/1 mix and explain every unsupported slot before asking the user to select.

4. Let the user select

Return the cited research summary and both tables from step 3. Recommend the strongest candidate overall and explain its fit. Ask the user to choose an idea, request shortlist details, or revise the direction, then wait. A ranking is not the user's approval.

If the user requests more detail, expand only the named candidates using the field table in step 5. Label these as candidate details and keep selection pending. Ask the user to select or revise, then wait.

5. Hand off the selected idea

After the user selects an idea, prepare a brief in the conversation labelled Unapproved idea brief:

Tell the user to invoke ai-agent-creator with this brief in their application repository. Do not invoke it automatically, select an architecture, or create implementation work. The creator owns discovery confirmation and architecture approval.

The research workflow is complete when the user has selected an idea and received the unapproved brief with every field above addressed. Mark unknowns explicitly.