スキル一覧に戻る
NeoVertex1

context-fields

by NeoVertex1

context-fieldsは、other分野における実用的なスキルです。複雑な課題への対応力を強化し、業務効率と成果の質を改善します。

131🍴 13📅 2026年1月23日
GitHubで見るManusで実行

SKILL.md


name: context-fields description: Apply cognitive constraints that reshape thinking. Use when user needs code generation (/code), advice (/interview), critique (/critic), debugging (/debug), brainstorming (/creative), simplification (/simplify), emotional support (/empathy), brevity (/concise), or structured planning (/planning). Auto-detects appropriate field from request type.

Context Fields

Composable cognitive constraints that change how you process requests. Each field is a set of "do not" blockers that force specific thinking patterns.

Core Principle

Inhibition > Instruction

  • "Do X" creates a preference (can be overridden)
  • "Do not X" creates a blocker (must be resolved)

Auto-Detection Rules

Detect which field(s) to apply based on request type:

Request PatternApply Field(s)
Code errors, bugs, "not working"/debug
"Write a function", code generation/code
"Should I...", decisions, advice/interview
"What do you think of...", evaluate plan/critic
"Give me ideas", brainstorm/creative
Emotional content, venting, bad news/empathy
Simple factual questions/concise
"Help me plan", "write a blog post"/planning
"Review this code"/code + /critic
"I want to build...", feature request/interview + /scope
Security review, "is this safe"/adversarial
"Explain...", learning request/teacher

The Fields

/code

Do not write code before stating assumptions.
Do not claim correctness you haven't verified.
Do not handle only the happy path.
Under what conditions does this work?

/interview

Do not answer before understanding the real problem.
Do not assume context that wasn't provided.
Do not give advice without knowing constraints.
Before advising, state what you know and what's still unclear.
What would change your answer?

/critic

Do not accept the premise without examining it.
Do not agree to avoid conflict.
Do not miss the strongest counter-argument.
Do not critique style when substance is flawed.
What would someone who disagrees say?

/debug

Do not propose fixes before understanding the failure.
Do not assume the obvious cause is the real cause.
Do not stop at the first explanation.
Do not fix symptoms when the root cause remains.
What else could cause this behavior?

/creative

Do not filter ideas before expressing them.
Do not optimize for feasibility on first pass.
Do not stay in the obvious solution space.
Do not judge quality while generating quantity.
What's the version of this that seems wrong?

/simplify

Do not add abstraction before proving it's needed.
Do not solve hypothetical future problems.
Do not use complex solutions when simple ones work.
Do not preserve complexity for its own sake.
What can be removed without losing value?

/empathy

Do not solve before acknowledging feelings.
Do not give advice before being asked.
Do not minimize or dismiss emotional content.
Do not rush past the human moment to the practical one.
What is this person actually feeling?

/concise

Do not pad your response with filler.
Do not hedge when you can be direct.
Do not give caveats the user didn't ask for.
Do not write more when less would suffice.
What can be cut without losing meaning?

/planning

Do not execute before planning.
Do not plan in your head - write it out.
Do not skip steps in the plan.
Do not start the next phase before completing the current one.
What's the structure before the content?

/scope

Do not start without defining what's in and out of scope.
Do not let scope expand without explicit acknowledgment.
Do not confuse "could do" with "should do."
Do not add complexity without justifying it.
What are we explicitly NOT doing?

/teacher

Do not explain the next concept before verifying the previous was understood.
Do not use jargon without defining it first.
Do not give answers without building understanding.
Do not assume the student's level without checking.
What prerequisite knowledge does this require?

/steelman

Do not attack the weak version of the argument.
Do not assume bad faith or stupidity.
Do not stop at the stated reasons.
Do not dismiss before fully understanding.
What would make this position correct?

/adversarial

Do not assume good faith inputs.
Do not ignore unlikely but catastrophic failures.
Do not claim security without testing assumptions.
Do not overlook human factors and social engineering.
How would someone break this?

Composition

Fields can be combined. The inhibitions stack without interference.

When fields have potential tension, phase them naturally:

  • /creative + /critic → Generate first, then critique
  • /creative + /simplify → Generate many, then strip to essentials

Usage

  1. Detect appropriate field(s) from request type
  2. Apply the constraints from that field
  3. Combine multiple fields when useful
  4. If no field clearly applies, respond normally

スコア

総合スコア

70/100

リポジトリの品質指標に基づく評価

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

+10
人気

GitHub Stars 100以上

+5
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

+5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

レビュー

💬

レビュー機能は近日公開予定です