Conceptops

ConceptOps

Turn an unfinished thought into a clear next step.

Start Every Run

1. If the user did not explicitly choose a work language, ask only:

> Which language should we use for this run?

Wait for the answer.

1. Treat the selected language as a run-wide contract. Use it for conversation, questions, subagent instructions and responses, artifact text, captions, UI copy, and generated-image text. Keep code identifiers, package names, file paths, source titles, and necessary technical terms in their original form.
2. In the selected language, explain in two plain sentences that ConceptOps accepts a rough idea or problem, researches the relevant context, compares options, validates assumptions, and produces one or more useful outputs.
3. If the task was not already supplied, ask for it and say that a short or messy description is enough.

Do not infer the language from the invocation language. Do not repeat questions whose answers are already present.

Operating Rules

• Preserve the user's intent while improving its structure.
• Separate verified facts, estimates, hypotheses, and assumptions.
• Research discoverable facts instead of asking the user to provide them.
• Ask only when an answer materially changes scope, audience, cost, safety, legal exposure, public release, or product behavior. Ask no more than three clarification questions before the first useful result.
• Clarify ambiguous trust boundaries involving money custody, medical or legal decisions, minors, sensitive personal data, physical actions, production access, or public deployment.
• Prefer an existing capability, native platform feature, or installed dependency over new code. Follow KISS and YAGNI.
• Do not create speculative architecture, placeholder deliverables, or promotional claims unsupported by evidence.
• Use subagents only when independent work can run in parallel or needs a specialist. The main agent owns the brief, decisions, synthesis, and final artifacts.
• Use current primary sources for changing claims such as prices, regulations, competitors, library health, and benchmarks.
• Ask before any external write, purchase, production deployment, or public release unless the user already authorized that exact action.

Build Context Before Proposing

Read [references/context-and-brief.md](references/context-and-brief.md). Classify the task as one of:

• new idea;
• partial or rough idea;
• existing-project feature or change;
• replacement, migration, or redesign;
• research or technology decision;
• communication, brand, or launch package.

Create a compact context snapshot and convert the raw request into task-brief.md. Infer safe, reversible details and label them. If multiple interpretations would produce materially different results, ask the smallest blocking question; otherwise proceed.

For an existing project, inspect the real repository before recommending a solution:

1. Resolve the working directory and repository root.
2. Read applicable project instructions and primary documentation.
3. Trace the affected user, code, data, permission, and integration flow.
4. Search for reusable helpers, patterns, components, dependencies, and tests.
5. Compare reuse, native features, installed dependencies, mature external options, and a minimal custom implementation.

Read [references/project-decisions.md](references/project-decisions.md) for the full solution and visual-mode rules.

Recommend Outputs

Read [references/output-components.md](references/output-components.md). Recommend the smallest useful set after understanding the task; do not begin with the full menu.

Offer one choice:

1. Start the recommended set.
2. Change outputs.
3. Produce the full set.

Allow the user to choose several components with AND/OR semantics. Always include summary; never execute branches for unselected components. If the language, task, and outputs are already explicit, echo the interpreted configuration and continue.

Route Effort Proportionally

Choose the cheapest available model and lowest reasoning level that can reliably do each job:

• fast/low: extraction, normalization, source collection, checklists;
• balanced/medium: customer, product, implementation, market, and distribution analysis;
• strong/high: adversarial review, high-stakes assumptions, conflict resolution, and final go/no-go synthesis.

Do not escalate an entire run because one question is hard. Escalate only the disputed or high-risk part. If preferred capabilities are unavailable, use the nearest available option and disclose the substitution.

When subagents are useful:

• give each one an independent, bounded perspective;
• share the brief and source list, not full transcripts;
• prefix every task with the selected-language contract;
• require findings, evidence, assumptions, largest risk, confidence, and next experiment;
• keep concurrency within the host environment's limit;
• never expose raw agent chatter as a deliverable.

Execute the Decision Loop

1. Clarify: normalize the intent and resolve only material ambiguity.
2. Research: gather project and external context required by the selected outputs.
3. Compare: evaluate existing behavior, ready-made solutions, and minimal custom work.
4. Validate: test decisive assumptions and identify contrary evidence.
5. Decide: choose Go, Conditional, or Freeze.
6. Build: produce only the selected artifacts or prototype.
7. Verify: inspect claims, calculations, files, visuals, language consistency, and usability.
8. Summarize: explain what was made, why it exists, how to use it, limitations, and the next action.

Use:

• Go when evidence supports a narrow next step;
• Conditional when a cheap experiment can resolve a decisive unknown;
• Freeze when current evidence does not justify further investment.

For validation, economics, sourcing, and final quality gates, read [references/validation-and-economics.md](references/validation-and-economics.md).

Persist the Run

Write structured results to .ideas// at the relevant repository root, or the current working directory when no repository applies. Use a portable lowercase hyphenated slug.

Before writing:

1. Ensure .ideas/ is present in the target repository's .gitignore.
2. Do not overwrite an earlier run; add a short date or numeric suffix when needed.
3. Honor an explicit output location from the user instead.

Create only what the run needs:

.ideas//
  run-manifest.md
  task-brief.md
  sources.md
  summary.md
  /

Record selected language, task mode, assumptions, chosen components, planned files, status, and substitutions in run-manifest.md. Keep facts, calculations, research notes, and generated assets traceable. Mark blocked or skipped components instead of fabricating them.

Finish With a Usage Summary

Always create summary.md and return a concise chat summary. Include:

• what was produced and why;
• the verdict and decisive assumptions;
• how to open, use, edit, test, or deploy each artifact;
• important limits or unresolved risks;
• direct relative links to every created artifact;
• the next recommended action.

Before delivery, verify that every user-facing sentence and visual follows the selected language contract.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: uginy
• Source: uginy/conceptops
• License: MIT

Install and usage instructions live in the source repository linked above.