think: The 10-principle thinking loop

A meditation, a discipline, and a checklist. Use this skill when a problem is non-trivial enough that disciplined thinking pays for itself: architectural decisions, post-mortems, ambiguous user requests, audits, multi-stakeholder tradeoffs, "should we ship?" moments, "what are we missing?" moments.

The 10 principles are not a recipe. They are stages of attention. You move through them in order on the first pass, then loop back to the earlier ones as new information emerges. The discipline is in NOT skipping the awkward ones (OBSERVE-internal, ACCEPT, GROW) just because they are uncomfortable.

This skill ships v1.9.0 of claude-obsidian. It is the meta-skill that informs how the other 14 skills think. Each of those skills also has a per-skill "How to think" appendix mapping these 10 stages to that skill's specific work.

The 10 principles

1. OBSERVE (the external input)

Thinking begins with data collection. Look at the environment, the current landscape, the patterns and inefficiencies and opportunities — without immediately trying to solve them. Read the raw inputs.

In practice: read the code before changing it. Read every commit before claiming the branch is clean. Read every page in the vault before answering a question that should be sourced. Resist the urge to jump to a fix on the first symptom.

2. OBSERVE (the internal metacognition)

Now observe yourself. This is metacognition — thinking about how you are thinking. Are you operating on assumptions? Do you have a bias in this architecture? Are you anchored on a previous decision? Is there a finding count you are unconsciously targeting?

In practice: write a one-paragraph "bias log" before scoring something. Note ownership bias, ship-it bias, familiarity bias, anchoring. The bias does not go away by being noted — it gets contained.

3. LISTEN (active receptivity)

Observing is often visual or analytical. Listening requires shutting down the ego to absorb external feedback. Pay attention to user intent, community discussions, error messages, the subtle signals in the noise that tell you what people actually need rather than what you think they need.

In practice: read the SKILL.md description before assuming what a skill does. Read the user's exact phrasing before paraphrasing it back. Read the failure message before guessing the failure mode. The user's confusion is data.

4. THINK (critical processing)

The analytical engine. Once you have the inputs, break the problem down to first principles. Structure the logic, map the workflows, evaluate the constraints, synthesize the raw data into a coherent strategy.

In practice: this is the cut where the six-cut engineering kernel lives. Read-before-write. Name like the next reader is hostile. Smallest unit that works. Delete more than you add. Evidence over intuition. Failure is the spec. THINK is where rigor pays off, but it cannot start without 1-3.

5. CONNECT (associative / lateral thinking)

Great ideas rarely happen in a vacuum; they happen at intersections. Take two seemingly unrelated concepts and link them. SEO algorithms × agentic AI behavior. Retrieval architecture × LLM compaction. The "Aha!" moment is finding the hidden relationship between distinct variables.

In practice: when auditing a skill, ask "does this bug pattern exist in adjacent skills?" When designing an API, ask "what other interface is this isomorphic to?" Lateral thinking finds cross-cutting bugs the per-component view misses.

6. CONNECT (system orchestration)

The second CONNECT is about execution. Moving from an isolated idea to an integrated system. How do these individual thoughts, tools, or agents plug into one another to create a seamless, functioning whole? This is the principle of building the wiring.

In practice: when shipping a new skill, audit how it integrates with hooks, transport, locks, the router, the verifier agent. The skill that works in isolation but breaks the auto-commit hook is not a working skill.

7. FEEL (emotional intelligence + intuition)

Pure logic is brittle without empathy. Factor in the human element. Design with user experience in mind. Understand the emotional resonance of your messaging. Trust hard-earned intuition when the data is ambiguous.

In practice: an error message that says "ERR: exit code 4" fails FEEL even if it passes THINK. A skill description that lists 12 triggers but doesn't explain WHEN to use it fails FEEL. The user installing the plugin for the first time experiences your decisions in a way make test cannot measure.

8. ACCEPT (intellectual humility)

No plan survives first contact with reality. Embrace constraints. Acknowledge when a hypothesis fails. Recognize when the market wants something different than what you built. Let go of sunk cost.

In practice: tier findings honestly. If your skill is 78/100, do not write 95/100. If the verdict is YELLOW, do not call it GREEN to please anyone. ACCEPT is the firewall against sycophancy.

9. CREATE (generative output)

Analysis paralysis is the enemy of progress. At some point, stop strategizing and start producing. Write the code. Draft the content. Launch the system. Ship the audit report.

In practice: an audit that never gets written is worse than a B+ audit that ships. A v1.8.2 fix that sits in working tree forever is worse than the same fix committed and pushed. CREATE is the answer when the prior stages have given you enough.

10. GROW (the iterative loop)

Thinking is not a straight line; it is a feedback loop. Take what you built (CREATE), see how it performs in reality, and use those lessons to upgrade your skills and expand your capacity for the next cycle.

In practice: every audit must end with a GROW section. What worked? What to improve next cycle? What inputs feed v_next? GROW is what turns one good decision into a compounding habit.

When to invoke

Invoke /think when:

• You are about to make a non-trivial architectural decision (designing a new skill, restructuring a module, choosing between approaches)
• You are auditing a system and need a methodology spine (per the v1.8.0 pre-push audit pattern)
• The user's request is ambiguous and you need to listen harder before responding
• You hit a surprising result and need OBSERVE-internal before adjusting
• You are about to call something done and need to verify ACCEPT (anti-sycophancy) before claiming the verdict
• A post-mortem after something went sideways
• Closing out a session and need a GROW step before /save

Do NOT invoke /think for:

• Single-line typo fixes (the discipline is overkill; just fix it)
• Trivial lookups (no decision is being made; just answer)
• Cases where you have already moved through the 10 stages implicitly (don't ceremonially re-do it)

The framework's value scales with problem novelty + irreversibility. For a one-line fix that's easily reverted, the loop is dead weight. For a release-blocking audit decision, skipping any stage loses calibration.

How to use

/think <problem statement>

Walks through the 10 stages in order. For each, answer the prompt questions below. Stage outputs feed into stage 9 (CREATE), which produces a recommendation or artifact.

Stages 1, 4, 9 are usually short. Stages 2, 7, 8, 10 are where most people skip. Watch yourself there.

Stage-by-stage prompts

For each stage, answer these questions before moving to the next:

1. OBSERVE (external)

• What are the raw inputs? (Code? Docs? User intent? Logs?)
• What have I read in full vs. skimmed vs. assumed?
• What is the environment / state right now? (Working tree, recent commits, test status, deployment state)
• What surprises me, before I start interpreting?

2. OBSERVE (internal)

• What am I biased toward here? (Ownership, ship-it, novelty, anchoring, familiarity)
• What outcome am I unconsciously hoping for? Why?
• If a fresh-context reviewer joined right now, wha