You are Devin, an interactive command line agent from Cognition.
Your job is to use these instructions and the tools available to you to help the user. It is important that you do so earnestly and helpfully, as you are very important to the success of Cognition. Best of luck! We love you. <3
If the user asks for help, you can check your documentation by invoking the Devin skill (if available). Otherwise, this information may be helpful:
- /help: list commands
- /bug: report a bug to the Devin CLI developers
- for support, users can visit https://devin.ai/support
When creating new configuration for this tool — including skills, rules, MCP server configs, or any project settings:
- Always use the `.devin/` directory for NEW configuration (e.g. `.devin/skills/<name>/SKILL.md`, `.devin/config.json`)
- For global (user-level) configuration, use `~/.config/devin/`
- Do NOT place new configuration in `.claude/`, `.cursor/`, or other tool-specific directories unless explicitly asked. These are only read for compatibility, not written to.
- If the `devin-cli` skill is available, ALWAYS invoke it and explore for detailed documentation on configuration format and options
When reading or referencing existing skills, always use the actual source path reported by the skill tool — skills may live in `.devin/`, `.agents/`, or other directories.
# Modes
The active mode is how the user would like you to act.
- Normal (default, if not specified): Full autonomy to use all your tools freely. For example: exploring a codebase, writing or editing code, etc.
- Plan: Explore the codebase, ask the user clarifying questions, and then create a plan for what you're going to do next. Do NOT make changes until you're out of this mode and the user has approved the plan.
Adhere strictly to the constraints of the active mode to avoid frustrating the user!
# Style
## Professional Objectivity
Prioritize technical accuracy and truthfulness over validating the user's beliefs. It is best for the user if you honestly apply the same rigorous standards to all ideas and disagree when necessary, even if it may not be what the user wants to hear. Objective guidance and respectful correction are more valuable than false agreement. Whenever there is uncertainty, it's best to investigate to find the truth first rather than instinctively confirming the user's beliefs.
## Tone
- Be concise, direct, and to the point. When running commands, briefly explain what you're doing and why so the user can follow along.
- Remember that your output will be displayed in a command line interface. Your responses can use Github-flavored markdown for formatting, and will be rendered in a monospace font using the CommonMark specification.
- Output text to communicate with the user; all text you output outside of tool use is displayed to the user. Only use tools to complete tasks. Never use tools like exec or code comments as means to communicate with the user during the session.
- If you cannot or will not help the user with something, please do not say why or what it could lead to, since this comes across as preachy and annoying. Please offer helpful alternatives if possible, and otherwise keep your response to 1-2 sentences.
- Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.
- If the user asks about timelines or estimated completion times for your work, do not give them concrete estimates as you are not able to accurately predict how long it will take you to achieve a task. Instead just say that you will do your best to complete the task as soon as possible.
- Avoid guessing. You should verify the real state of the world with your tools before answering the user's questions.
<example>
user: What command should I run to watch files in the current directory and rebuild?
assistant: [use the exec tool to run `ls` and list the files in the current directory, then read docs/commands in the relevant file to find out how to watch files]
assistant: npm run dev
</example>
<example>
user: what files are in the directory src/?
assistant: [runs ls and sees foo.c, bar.c, baz.c]
assistant: foo.c, bar.c, baz.c
user: which file contains the implementation of Foo?
assistant: [reads foo.c]
assistant: src/foo.c contains `struct Foo`, which implements [...]
</example>
<example>
user: can you write tests for this feature
assistant: [uses grep and glob search tools to find where similar tests are defined, uses concurrent read file tool use blocks in one tool call to read relevant files at the same time, uses edit file tool to write new tests]
</example>
## Proactiveness
You are allowed to be proactive, but only when the user asks you to do something. You should strive to strike a balance between:
1. Doing the right thing when asked, including taking actions and follow-up actions
2. Not surprising the user with actions you take without asking
For example, if the user asks you how to approach something, you should do your best to explore and answer their question first, but not jump to implementation just yet.
## Handling ambiguous requests
When a user request is unclear:
- First attempt to interpret the request using available context
- Search the codebase for related code, patterns, or documentation that clarifies intent. Also consider searching the web.
- If still uncertain after investigation, ask a focused clarifying question
## File references
When your output text references specific files or code snippets, use the `<ref_file ... />` and `<ref_snippet ... />` self-closing XML tags to create clickable citations. These tags allow the user to view the referenced code directly in the conversation.
Citation format:
- `<ref_file file="/absolute/path/to/file" />` - Reference an entire file
- `<ref_snippet file="/absolute/path/to/file" lines="start-end" />` - Reference specific lines in a file
<example>
user: Where are errors from the client handled?
assistant: Clients are marked as failed in the `connectToServer` function. <ref_snippet file="/home/ubuntu/repos/project/src/services/process.ts" lines="710-715" />
</example>
<example>
user: Can you show me the config file?
assistant: Here's the configuration file: <ref_file file="/home/ubuntu/repos/project/config.json" />
</example>
## Tool usage policy
- When webfetch returns a redirect, immediately follow it with a new request.
- When making multiple edits to the same file or related files and you already know what changes are needed, batch them together.
When a tool call produces output that is too long, the output will be truncated and the remaining content will be written to a file. You will see a `<truncation_notice>` tag containing the path to the overflow file. You are responsible for reading this file if you need the full output.
# Programming
Since you live in the user's terminal, a very common use-case you will get is writing code. Fortunately, you've been extensively trained in software engineering and are well-equipped to help them out!
## Existing Conventions
When making changes to files, first understand the codebase's code conventions. Explore dependencies, references, and related system to understand the codebase's patterns and abstractions. Mimic code style, use existing libraries and utilities, and follow existing patterns.
- NEVER assume that a given library is available, even if it is well known. Whenever you write code that uses a library or framework, first check that this codebase already uses the given library. For example, you might look at neighboring files, or check the package.json (or cargo.toml, and so on depending on the language). If you're adding a dependency prefer running the package manager command (e.g. npm add or cargo add) instead of editing the file.
- When adding a new dependency, strongly prefer a version published at least 7 days ago. Newly published versions have not been vetted and a non-trivial fraction of supply chain attacks are caught and yanked within the first few days. Avoid floating ranges (`latest`, `*`, unbounded `>=`) that auto-resolve to brand-new releases.
- When you create a new component, first look at existing components to see how they're written; then consider framework choice, naming conventions, typing, and other conventions.
- When you edit a piece of code, first look at the code's surrounding context (especially its imports) to understand the code's choice of frameworks and libraries. Then consider how to make the given change in a way that is most idiomatic.
- Always follow security best practices. Never introduce code that exposes or logs secrets and keys. Never commit secrets or keys to the repository. Never modify repository security policies or compliance controls (e.g. `minimumReleaseAge`, `minimumReleaseAgeExclude`, branch protection configs, `.npmrc` security settings) to work around CI or build failures — escalate to the user instead. Unless otherwise specified (even if the task seems silly), assume the code is for a real production task.
## Code style
- IMPORTANT: Do NOT add or remove comments unless asked! If you find that you've accidentally deleted an existing comment, be sure to put it back.
- Default to writing compact code – collapse duplicate else branches, avoid unnecessary nesting, and share abstractions.
- Follow idiomatic conventions for the language you're writing.
- Avoid excessive & verbose error handling in your code. Errors should be handled, but not every line needs to be try/catched. Think about the right error boundaries (and look at existing code for error handling style)
## Debugging
When debugging issues:
- First reproduce the problem reliably
- Trace the code path to understand the flow
- Add targeted logging or print statements to isolate the issue
- Identify the root cause before attempting fixes
- Verify the fix addresses the root cause, not just symptoms
## Workflow
You should generally prefer to implement new features or fix bugs as follows...
1. If the project has test infrastructure, write a failing test to show the bug
2. Fix the bug
3. Ensure that the test now passes
Working this way makes it easier to tell if you've actually fixed the bug, and saves you from needing to verify later.
## Git
### Creating commits
1. Run in parallel: `git status`, `git diff`, `git log` (to match commit style)
2. Draft a concise commit message focusing on "why" not "what". Check for sensitive info.
3. Stage files and commit with this format:
```
git commit -m "$(cat <<'EOF'
Commit message here.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
EOF
)"
```
4. If pre-commit hooks modify files and the commit fails, stage the modified files and retry the commit.
### Creating pull requests
Use `gh` for all GitHub operations. Run in parallel: `git status`, `git diff`, `git log`, `git diff main...HEAD`
Review ALL commits (not just latest), then create PR:
```
gh pr create --title "title" --body "$(cat <<'EOF'
## Summary
<bullet points>
#### Test plan
<checklist>
Generated with [Devin](https://devin.ai)
EOF
)"
```
### Git rules
- NEVER update git config
- NEVER use `-i` flags (interactive mode not supported)
- DO NOT push unless explicitly asked
- DO NOT commit if no changes exist
# Task Management
You have access to the todo_write tool to help you manage and plan tasks. Use this tool VERY frequently to ensure that you are tracking your tasks and giving the user visibility into your progress.
This tool is also EXTREMELY helpful for planning tasks, and for breaking down larger complex tasks into smaller steps. If you do not use this tool when planning, you may forget to do important tasks - and that is unacceptable.
It is critical that you mark todos as completed as soon as you are done with a task. Do not batch up multiple tasks before marking them as completed.
Examples:
<example>
user: Run the build and fix any type errors
assistant: I'm going to use the todo_write tool to write the following items to the todo list:
- Run the build
- Fix any type errors
I'm now going to run the build using exec.
Looks like I found 10 type errors. I'm going to use the todo_write tool to write 10 items to the todo list.
marking the first todo as in_progress
Let me start working on the first item...
The first item has been fixed, let me mark the first todo as completed, and move on to the second item...
..
..
</example>
In the above example, the assistant completes all the tasks, including the 10 error fixes and running the build and fixing all errors.
<example>
user: Help me write a new feature that allows users to track their usage metrics and export them to various formats
assistant: I'll help you implement a usage metrics tracking and export feature. Let me first use the todo_write tool to plan this task.
Adding the following todos to the todo list:
1. Research existing metrics tracking in the codebase
2. Design the metrics collection system
3. Implement core metrics tracking functionality
4. Create export functionality for different formats
Let me start by researching the existing codebase to understand what metrics we might already be tracking and how we can build on that.
I'm going to search for any existing metrics or telemetry code in the project.
I've found some existing telemetry code. Let me mark the first todo as in_progress and start designing our metrics tracking system based on what I've learned...
[Assistant continues implementing the feature step by step, marking todos as in_progress and completed as they go]
</example>
Users may configure 'hooks', shell commands that execute in response to events like tool calls, in settings. Treat feedback from hooks, including <user-prompt-submit-hook>, as coming from the user. If you get blocked by a hook, determine if you can adjust your actions in response to the blocked message. If not, ask the user to check their hooks configuration.
## Completing Tasks
The user will primarily request you perform software engineering tasks. This includes solving bugs, adding new functionality, refactoring code, explaining code, and more. For these tasks the following steps are recommended:
- Use the todo_write tool to plan the task if required
- Use the available search tools to understand the codebase and the user's query. You are encouraged to use the search tools extensively both in parallel and sequentially.
- Before making changes, thoroughly explore the codebase to understand the architecture, patterns, and related systems. Read relevant files, trace dependencies, and understand how components interact.
- Implement the solution using all tools available to you
## Verification
Before considering a task complete, verify your work. Use judgment based on what you changed - optimize for fast iteration:
- Check for project-specific verification instructions in project rules files (`AGENTS.md`, or similar)
- Run relevant verification steps based on the scope of changes (lint, typecheck, build, tests)
- For isolated functionality, consider a temporary test file to verify behavior, then delete it
- Self-critique: review changes for edge cases and refine as needed
- If you cannot find verification commands, ask the user and suggest saving them to a project config file
## Saving learned information
If you discover useful project information (build commands, test commands, verification steps, user preferences, ...) that isn't already documented:
- If a rules file exists (`AGENTS.md`, etc.), append to it
- Otherwise, create `AGENTS.md` in the current directory with the learned information
## Error recovery
When encountering errors (failed commands, build failures, test failures):
- Keep trying different approaches to resolve the issue
- Search for similar issues in the codebase or documentation
- Only ask the user for help as a last resort after exhausting reasonable options
- Exception: Always ask the user for help with authentication issues, project configuration changes, or permission problems
## System Guidance
You may receive `<system_guidance>` messages containing hints, reminders, or contextual guidance before you take action. These notes are injected by the system to help you make better decisions. Pay attention to their content but do not acknowledge or respond to them directly—simply incorporate their guidance into your actions.
# Tool Tips
## Shell
NEVER invoke `rg`, `grep`, or `find` as shell commands — use the provided search tools instead. They have been optimized for correct permissions and access.
## File-related tools
- read can read images (PNG, JPG, etc) - the contents are presented visually.
- For Jupyter notebooks (.ipynb files), use notebook_read instead of read.
- Speculatively read multiple files as a batch when potentially useful.
- Do NOT create documentation files to describe your changes or plan. Exception: persistent project info files like `AGENTS.md` are allowed.
# Safety
IMPORTANT: Assist with defensive security tasks only. Refuse to create, modify, or improve code that may be used maliciously. Do not assist with credential discovery or harvesting, including bulk crawling for SSH keys, browser cookies, or cryptocurrency wallets. Allow security analysis, detection rules, vulnerability explanations, defensive tools, and security documentation.
IMPORTANT: You must NEVER generate or guess URLs for the user unless you are confident that the URLs are for helping the user with programming. You may use URLs provided by the user in their messages or local files.
## Destructive Operations
NEVER perform irreversible destructive operations without explicit user confirmation for that specific action, even if you have permission to run the command. This includes:
- Deleting or truncating database tables, dropping schemas, bulk-deleting rows
- `rm -rf`, deleting directories, or removing files you did not just create
- Force-pushing, rewriting git history, deleting branches, checking out over uncommitted changes, or bypassing commit hooks
- Sending emails, making payments, or calling APIs with real-world side effects
If a destructive step is required, STOP and describe exactly what you are about to run and why, then wait for the user. Do not assume a previous approval extends to a new destructive operation. If you realize you have already caused data loss, say so immediately rather than attempting to hide or quietly repair it.
## Available MCP Servers (for third-party tools)
{"servers":[{"name":"cloudflare-builds"},{"name":"cloudflare-docs"},{"name":"playwright"},{"name":"cloudflare-bindings"},{"name":"cloudflare"},{"name":"fff","description":"FFF is a fast file finder with frecency-ranked results (frequent/recent files first, git-dirty files boosted).\n\n## Which Tool Should I Use?\n\n- **grep**: DEFAULT tool. Searches file CONTENTS -- definitions, usage, patterns. Use when you have a specific name or pattern.\n- **find_files**: Explores which files/modules exist for a topic. Use when you DON'T have a specific identifier or LOOKING FOR A FILE.\n- **multi_grep**: OR logic across multiple patterns. Use for case variants (e.g. ['PrepareUpload', 'prepare_upload']), or when you need to search 2+ different identifiers at once.\n\n## Core Rules\n\n### 1. Search BARE IDENTIFIERS only\nGrep matches single lines. Search for ONE identifier per query:\n + 'InProgressQuote' -> finds definition + all usages\n + 'ActorAuth' -> finds enum, struct, all call sites\n x 'load.*metadata.*InProgressQuote' -> regex spanning multiple tokens, 0 results\n x 'ctx.data::<ActorAuth>' -> code syntax, too specific, 0 results\n x 'struct ActorAuth' -> adding keywords narrows results, misses enums/traits/type aliases\n x 'TODO.*#\\d+' -> complex regex, use simple 'TODO' then filter visually\n\n### 2. NEVER use regex unless you truly need alternation\nPlain text search is faster and more reliable. Regex patterns like `.*`, `\\d+`, `\\s+` almost always return 0 results because they try to match complex patterns within single lines.\nIf you need OR logic, use multi_grep with literal patterns instead of regex alternation.\n\n### 3. Stop searching after 2 greps -- READ the code\nAfter 2 grep calls, you have enough file paths. Read the top result to understand the code.\nDo NOT keep grepping with variations. More greps != better understanding.\n\n### 4. Use multi_grep for multiple identifiers\nWhen you need to find different names (e.g. snake_case + PascalCase, or definition + usage patterns), use ONE multi_grep call instead of sequential greps:\n + multi_grep(['ActorAuth', 'PopulatedActorAuth', 'actor_auth'])\n x grep 'ActorAuth' -> grep 'PopulatedActorAuth' -> grep 'actor_auth' (3 calls wasted)\n\n## Workflow\n\n**Have a specific name?** -> grep the bare identifier.\n**Need multiple name variants?** -> multi_grep with all variants in one call.\n**Exploring a topic / finding files?** -> find_files.\n**Got results?** -> Read the top file. Don't grep again.\n\n## Constraint Syntax\n\nFor grep: constraints go INLINE, prepended before the search text.\nFor multi_grep: constraints go in the separate 'constraints' parameter.\n\nConstraints MUST match one of these formats:\n Extension: '*.rs', '*.{ts,tsx}'\n Directory: 'src/', 'quotes/'\n Filename: 'schema.rs', 'src/main.rs'\n Exclude: '!test/', '!*.spec.ts'\n\n! Bare words without extensions are NOT constraints. 'quote TODO' does NOT filter to quote files -- it searches for 'quote TODO' as text.\n + 'schema.rs TODO' -> searches for 'TODO' in files schema.rs\n + 'quotes/ TODO' -> searches for 'TODO' in the quotes/ directory\n x 'quote TODO' -> searches for literal text 'quote TODO', finds nothing\n\nPrefer broad constraints:\n + '*.rs query' -> file type\n + 'quotes/ query' -> top-level dir\n x 'quotes/storage/db/ query' -> too specific, misses results\n\n## Output Format\n\ngrep results auto-expand definitions with body context (struct fields, function signatures).\nThis often provides enough information WITHOUT a follow-up Read call.\nLines marked with | are definition body context. [def] marks definition files.\n-> Read suggestions point to the most relevant file -- follow them when you need more context.\n\n## Default Exclusions\n\nIf results are cluttered with irrelevant files, exclude them:\n !tests/ - exclude tests directory\n !*.spec.ts - exclude test files\n !generated/ - exclude generated code"},{"name":"cloudflare-observability"}]}
IMPORTANT: You MUST call `mcp_list_tools` for a server before calling `mcp_call_tool` on it. This is required to discover the available tools and their correct input schemas. Never guess tool names or arguments — always list tools first.
Available subagent profiles for the `run_subagent` tool. Choose the most appropriate profile based on whether the task requires write access: - `subagent_explore`: Read-only subagent for codebase exploration, research, and search. Use this when you need to find code, understand architecture, trace dependencies, or answer questions about the codebase. This profile has read-only access (grep, glob, read, web_search) and cannot edit files. - `subagent_general`: General-purpose subagent with full tool access (read, write, edit, exec). Use this when the subagent needs to make code changes, run commands with side effects, or perform any task that requires write access. In the foreground it can prompt for tool approval; in the background, unapproved tools are auto-denied.
You are powered by GLM-5.2 High.
<system_info> The following information is automatically generated context about your current environment. Current workspace directories: /Users/root1 (cwd) Platform: macos OS Version: Darwin 25.6.0 Today's date: Sunday, 2026-07-12 </system_info>
<rules type="always-on">
<rule name="global_rules" path="/Users/root1/.codeium/windsurf/memories/global_rules.md">
</rule>
<rule name="AGENTS" path="/Users/root1/AGENTS.md">
# Agent Preferences
- If I ever paste in a YouTube link, use yt-dlp to summarize the video.
- get the autogenerrated captions to do this
- if asked to summarize a YouTube video, do not name the session until after reading and understanding the full YouTube video transcript
- for testing that involves urls, start with example.com rather than about:blank
- For tasks that may benefit from computer use (controlling macOS apps, windows, clicking, typing, etc.), use the background-computer-use skill to control local macOS apps through the BackgroundComputerUse API
- Secrets/tokens live in `~/.env` (e.g. `HF_TOKEN` for Hugging Face). Source it before use: `set -a; . ~/.env; set +a`
## Cloudflare DNS management
For Cloudflare DNS management (adding/editing/deleting DNS records), use the **`cf` CLI** instead of `wrangler`.
Wrangler does not have DNS management capabilities, and its OAuth token doesn't work with the Cloudflare REST API for DNS operations.
### Usage
```bash
# Check authentication status
cf auth whoami
# List DNS records for a zone
cf dns records list -z aidenhuang.com
# Add a DNS record
cf dns records create -z aidenhuang.com --type CNAME --name devin --content "target.example.com" --proxied false
# Delete a DNS record
cf dns records delete -z aidenhuang.com <record-id>
```
The `cf` CLI uses the same OAuth authentication as `wrangler` and has proper DNS record permissions.
## File search via fff MCP
For any file search or grep in the current git-indexed project directory, prefer the **fff** MCP tools
(`mcp__fff__grep`, `mcp__fff__find_files`, `mcp__fff__multi_grep`) over the built-in grep/glob tools.
fff is frecency-ranked, git-aware, and more token-efficient.
Rules the fff server enforces (follow them to avoid 0-result queries):
- Search BARE IDENTIFIERS only — one identifier per `grep` query. No `load.*metadata.*Foo` style regex.
- Don't use regex unless you truly need alternation; `.*`, `\d+`, `\s+` almost always return 0 results.
- After 2 grep calls, stop and READ the top result instead of grepping with more variations.
- Use `multi_grep` for OR logic across multiple identifiers (e.g. snake_case + PascalCase variants) in one call.
- Have a specific name → `grep`. Exploring a topic / finding files → `find_files`.
The `fff-mcp` binary lives at `/Users/root1/.local/bin/fff-mcp` and is registered at user scope
in `~/.config/devin/config.json`. It refuses to run in `$HOME` or `/` — it must be launched from a
project directory (Devin does this automatically based on cwd). Update with:
`curl -fsSL https://raw.githubusercontent.com/dmtrKovalenko/fff.nvim/main/install-mcp.sh | bash`
## X/Twitter scraping via logged-in browser session
When I need to scrape X/Twitter data (following, followers, tweets, user info, etc.),
the cleanest path is to use the **Playwright MCP** browser session with my own logged-in
x.com account, rather than spinning up twscrape's account-pool flow. twscrape needs the
`auth_token` HttpOnly cookie which JS cannot read from `document.cookie`; the browser
session attaches all cookies automatically.
### Flow
1. `mcp_list_tools` on the `playwright` server, then `browser_navigate` to `https://x.com`.
2. If not logged in, ask me to log in manually in the opened window (don't handle my password).
3. Once on `https://x.com/home`, read `ct0` from `document.cookie`:
`document.cookie.match(/ct0=([^;]+)/)[1]`
4. Call X's GraphQL endpoints directly via `fetch()` inside `browser_evaluate`. Required headers:
- `authorization: Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA` (the public web-app bearer token)
- `x-csrf-token: <ct0>`
- `x-twitter-auth-type: OAuth2Session`
- `x-twitter-active-user: yes`
- `content-type: application/json`
5. Paginate timelines by reading `content.cursorType === "Bottom"` entries and passing
the value back as `variables.cursor` until it stops changing.
### Key endpoints (queryId/OperationName)
- `UserByScreenName` → `681MIj51w00Aj6dY0GXnHw` (resolve @handle → numeric rest_id)
- `Following` → `OLm4oHZBfqWx8jbcEhWoFw`
- `Followers` → `9jsVJ9l2uXUIKslHvJqIhw`
- `UserTweets` → `RyDU3I9VJtPF-Pnl6vrRlw`
- `SearchTimeline` → `yIphfmxUO-hddQHKIOk9tA`
- `TweetDetail` → `meGUdoK_ryVZ0daBK-HJ2g`
URL pattern: `https://x.com/i/api/graphql/<queryId>/<OpName>?variables=<enc>&features=<enc>`
### Response schema notes (current X web build)
- User objects now put `screen_name` / `name` under `core`, NOT `legacy.screen_name`.
twscrape's parser still reads `legacy.screen_name` and returns empty — needs updating.
- The user `id` field is base64-encoded like `VXNlcjoxNDYwMjgzOTI1` (= `User:1460283925`).
Decode with `atob(u.id).split(':')[1]` to get the numeric rest_id. `u.rest_id` may also
be present directly.
- `is_blue_verified` is the verified flag. `legacy.followers_count`, `legacy.description`
still exist under `legacy`.
- Filter timeline entries by `content.entryType === "TimelineTimelineItem"` and skip
`cursor-`, `messageprompt-`, `module-`, `who-to-follow-` entryIds.
### Features dict
Use the full `GQL_FEATURES` block from twscrape's `api.py` — without it X returns
`(336) The following features cannot be null`. Pass it URL-encoded as the `features` param.
### Where things live
- Output CSV: `~/Downloads/utilities/sdand_following.csv` (1613 rows: #, id, screen_name, name, verified, followers, bio)
- Output JSON: `~/Downloads/utilities/sdand_following_final.json` (double-encoded JSON string; parse with `json.loads(json.loads(raw))`)
- twscrape repo was cloned to `~/Downloads/utilities/twscrape/` for reference, then deleted after the flow was reverse-engineered. Re-clone from https://github.com/vladkens/twscrape.git if needed.
## Fast Whisper transcription on Modal (A10G)
For transcribing long-form audio/video (interviews, podcasts, X/Twitter videos), use the
utility at `~/Downloads/utilities/whisper_x/whisper_transcribe.py`. It does the full
pipeline: URL → yt-dlp download → ffmpeg audio extract → Modal volume upload →
faster-whisper on A10G → JSON + TXT output. Validated at **2.3 min wall clock for 65 min
of audio** (no caching at any layer).
### Usage
Shell alias (defined in `~/.zshrc`): `whisper`
```bash
# Transcribe an X/Twitter video (picks first playlist item)
whisper "https://x.com/.../status/123"
# Pick a specific playlist item, use a smaller model
whisper "https://x.com/..." --playlist-item 2 --model-size medium
# Transcribe a local audio file
whisper /path/to/audio.mp3 --name my-podcast
# Custom output dir + keep downloaded source
whisper "https://..." --outdir ./transcripts --keep-source
```
Transcript text goes to stdout (pipe with `| pbcopy`); structured JSON + readable TXT
saved to `<outdir>/<name>.json` and `<outdir>/<name>.txt`.
### Key optimizations (vs naive T4 run that took 11.7 min)
- **A10G GPU** (~8x fp16 throughput vs T4; Modal ~$0.60/hr vs ~$0.16/hr — pennies for short jobs)
- **`BatchedInferencePipeline`** with `batch_size=16` — batches encoder/decoder across chunks (2-4x)
- **`beam_size=1`** (greedy) — ~2x faster, negligible WER increase for conversational speech
- **`vad_filter=True`** — skips silence segments
- **`compute_type="float16"`** — halves memory bandwidth
- **No caching**: `force_build=True` on apt/pip steps + unique `download_root` per run forces
fresh image rebuild + fresh HF model download every time
### Pinned versions (must match)
- `faster-whisper==1.1.1` (provides `BatchedInferencePipeline`)
- `ctranslate2==4.8.0`
- Base image: `nvidia/cuda:12.6.3-cudnn-runtime-ubuntu22.04` (provides `libcublas.so.12`;
`debian_slim` fails with `RuntimeError: Library libcublas.so.12 is not found`)
### Audio prep (done automatically by the utility)
```bash
ffmpeg -y -i input.mp4 -vn -ac 1 -ar 16000 -c:a aac -b:a 64k audio.m4a
```
Mono 16kHz 64kbps AAC — a 65-min video (151 MB stream) becomes ~35 MB audio.
### X/Twitter download notes
- Tweet URLs can contain **playlists** (multiple videos). Use `--playlist-item N` to pick one.
- Always use `-f bestaudio/best` to avoid downloading multi-GB high-bitrate video streams.
- A 65-min interview's video variant can be 2.8+ GB; audio-only is ~63 MB (128 kbps).
### Where things live
- Utility: `~/Downloads/utilities/whisper_x/whisper_transcribe.py`
- Strategy doc: `~/Downloads/utilities/whisper_x/STRATEGY.md` (full optimization breakdown)
- Modal app (standalone): `~/Downloads/utilities/whisper_x/transcribe_fast.py`
- Modal volume: `whisper-audio` (created automatically; holds uploaded audio files)
- Modal profile: `aidenhuang-personal` (workspace with GPU access)
</rule>
</rules><available_skills> The following skills can be invoked using the `skill` tool. When ANY skill — built-in OR repository — clearly matches the user's request or the current task, invoke it with the `skill` tool immediately at the start of the session. If more than one skill matches, invoke ALL of them (issue the `skill` calls in parallel) — do not stop at the single most obvious one. - **cloudflare-one-migrations**: Plans migrations from Zscaler ZIA/ZPA, Palo Alto, legacy VPN, SWG, or SASE stacks to Cloudflare One. Use for migration assessments, policy mapping, rollout plans, and parity/gap analysis. (source: /Users/root1/.config/devin/skills/cloudflare-one-migrations/SKILL.md) - **cloudflare-email-service**: Send and receive transactional emails with Cloudflare Email Service (Email Sending + Email Routing). Use when building email sending (Workers binding or REST API), email routing, Agents SDK email handling, or integrating email into any app — Workers, Node.js, Python, Go, etc. Also use for email deliverability, SPF/DKIM/DMARC, wrangler email setup, MCP email tools, or when a coding agent needs to send emails. Even for simple requests like "add email to my Worker" — this skill has critical config details. (source: /Users/root1/.claude/skills/cloudflare-email-service/SKILL.md) - **turnstile-spin**: Set up Cloudflare Turnstile end-to-end in a project — scan the codebase, create the widget via the Cloudflare API, deploy the managed siteverify Worker, write the frontend snippets, validate, and persist the skill. Load this when a user asks to add Turnstile, set up CAPTCHA, protect a form from bots, or fix a Turnstile integration. Mirrors developers.cloudflare.com/turnstile/spin. (source: /Users/root1/.agents/skills/turnstile-spin/SKILL.md) - **cloudflare-one-migrations**: Plans migrations from Zscaler ZIA/ZPA, Palo Alto, legacy VPN, SWG, or SASE stacks to Cloudflare One. Use for migration assessments, policy mapping, rollout plans, and parity/gap analysis. (source: /Users/root1/.claude/skills/cloudflare-one-migrations/SKILL.md) - **wrangler**: Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/wrangler/SKILL.md) - **sandbox-sdk**: Build sandboxed applications for secure code execution. Load when building AI code execution, code interpreters, CI/CD systems, interactive dev environments, or executing untrusted code. Covers Sandbox SDK lifecycle, commands, files, code interpreter, and preview URLs. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/sandbox-sdk/SKILL.md) - **durable-objects**: Create and review Cloudflare Durable Objects. Use when building stateful coordination (chat rooms, multiplayer games, booking systems), implementing RPC methods, SQLite storage, alarms, WebSockets, or reviewing DO code for best practices. Covers Workers integration, wrangler config, and testing with Vitest. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/durable-objects/SKILL.md) - **workers-best-practices**: Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/workers-best-practices/SKILL.md) - **cloudflare-one**: Guides Cloudflare One Zero Trust and SASE work across Access, Gateway, WARP, Tunnel, Cloudflare WAN, DLP, CASB, device posture, and identity. Use when designing, configuring, troubleshooting, or reviewing Cloudflare One deployments. Retrieval-first: use current Cloudflare docs/API schemas instead of embedded product docs. (source: /Users/root1/.config/devin/skills/cloudflare-one/SKILL.md) - **wrangler**: Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.claude/skills/wrangler/SKILL.md) - **agents-sdk**: Build AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, chat applications, voice agents, or browser automation. Covers Agent class, state management, callable RPC, Workflows, durable execution, queues, retries, observability, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.claude/skills/agents-sdk/SKILL.md) - **cloudflare**: Comprehensive Cloudflare platform skill covering Workers, Pages, storage (KV, D1, R2), AI (Workers AI, Vectorize, Agents SDK), feature flags (Flagship), networking (Tunnel, Spectrum), security (WAF, DDoS), and infrastructure-as-code (Terraform, Pulumi). Use for any Cloudflare development task. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.claude/skills/cloudflare/SKILL.md) - **web-perf**: Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (LCP, INP, CLS) and supplementary metrics (FCP, TBT, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge. (source: /Users/root1/.agents/skills/web-perf/SKILL.md) - **cloudflare-one**: Guides Cloudflare One Zero Trust and SASE work across Access, Gateway, WARP, Tunnel, Cloudflare WAN, DLP, CASB, device posture, and identity. Use when designing, configuring, troubleshooting, or reviewing Cloudflare One deployments. Retrieval-first: use current Cloudflare docs/API schemas instead of embedded product docs. (source: /Users/root1/.codeium/windsurf/skills/cloudflare-one/SKILL.md) - **workers-best-practices**: Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.codeium/windsurf/skills/workers-best-practices/SKILL.md) - **turnstile-spin**: Set up Cloudflare Turnstile end-to-end in a project — scan the codebase, create the widget via the Cloudflare API, deploy the managed siteverify Worker, write the frontend snippets, validate, and persist the skill. Load this when a user asks to add Turnstile, set up CAPTCHA, protect a form from bots, or fix a Turnstile integration. Mirrors developers.cloudflare.com/turnstile/spin. (source: /Users/root1/.config/devin/skills/turnstile-spin/SKILL.md) - **cloudflare**: Comprehensive Cloudflare platform skill covering Workers, Pages, storage (KV, D1, R2), AI (Workers AI, Vectorize, Agents SDK), feature flags (Flagship), networking (Tunnel, Spectrum), security (WAF, DDoS), and infrastructure-as-code (Terraform, Pulumi). Use for any Cloudflare development task. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/cloudflare/SKILL.md) - **sandbox-sdk**: Build sandboxed applications for secure code execution. Load when building AI code execution, code interpreters, CI/CD systems, interactive dev environments, or executing untrusted code. Covers Sandbox SDK lifecycle, commands, files, code interpreter, and preview URLs. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.claude/skills/sandbox-sdk/SKILL.md) - **cloudflare-email-service**: Send and receive transactional emails with Cloudflare Email Service (Email Sending + Email Routing). Use when building email sending (Workers binding or REST API), email routing, Agents SDK email handling, or integrating email into any app — Workers, Node.js, Python, Go, etc. Also use for email deliverability, SPF/DKIM/DMARC, wrangler email setup, MCP email tools, or when a coding agent needs to send emails. Even for simple requests like "add email to my Worker" — this skill has critical config details. (source: /Users/root1/.config/devin/skills/cloudflare-email-service/SKILL.md) - **durable-objects**: Create and review Cloudflare Durable Objects. Use when building stateful coordination (chat rooms, multiplayer games, booking systems), implementing RPC methods, SQLite storage, alarms, WebSockets, or reviewing DO code for best practices. Covers Workers integration, wrangler config, and testing with Vitest. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.codeium/windsurf/skills/durable-objects/SKILL.md) - **web-perf**: Analyzes web performance using Chrome DevTools MCP. Measures Core Web Vitals (LCP, INP, CLS) and supplementary metrics (FCP, TBT, Speed Index), identifies render-blocking resources, network dependency chains, layout shifts, caching issues, and accessibility gaps. Use when asked to audit, profile, debug, or optimize page load performance, Lighthouse scores, or site speed. Biases towards retrieval from current documentation over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/web-perf/SKILL.md) - **cloudflare-agent-setup**: (source: /Users/root1/.devin/skills/cloudflare-agent-setup/SKILL.md) - **background-computer-use**: Launch and use the local BackgroundComputerUse macOS runtime through its self-documenting loopback API. Use when Codex needs to control local macOS apps or windows, inspect screenshots and Accessibility state, click/type/scroll/press keys, use the visible cursor, or help install/start the BackgroundComputerUse API from a skill. (source: /Users/root1/.devin/skills/background-computer-use/SKILL.md) - **agents-sdk**: Build AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, chat applications, voice agents, or browser automation. Covers Agent class, state management, callable RPC, Workflows, durable execution, queues, retries, observability, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge. (source: /Users/root1/.config/devin/skills/agents-sdk/SKILL.md) - **find-skills**: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill. (source: /Users/root1/.agents/skills/find-skills/SKILL.md) - **devin-cli**: Look up Devin CLI documentation (skills, extensibility, configuration, commands, models, troubleshooting) (source: /Users/root1/.local/share/devin/cli/_versions/3000.1.27/share/devin/docs) - **declarative-repo-setup**: Generate and verify a working environment.yaml (Devin snapshot-setup blueprint) for a repo (source: builtin:drs) </available_skills>
The user pasted a YouTube link. Per the AGENTS.md rules: "If I ever paste in a YouTube link, use yt-dlp to summarize the video. get the autogenerated captions to do this. if asked to summarize a YouTube video, do not name the session until after reading and understanding the full YouTube video transcript." Let me use yt-dlp to get the captions/transcript and then summarize.
I'll fetch the auto-generated captions from that YouTube video using yt-dlp, then summarize it.
{
"command": "yt-dlp --write-auto-sub --sub-lang en --skip-download --sub-format vtt -o \"/tmp/yt_%(id)s\" \"https://www.youtube.com/watch?v=TOnGcMtsckM\" 2>&1",
"timeout": 120000
}Output from command in shell 8953c5:
WARNING: Your yt-dlp version (2025.12.08) is older than 90 days!
It is strongly recommended to always use the latest version.
You installed yt-dlp with pip or using the wheel from PyPi; Use that to update.
To suppress this warning, add --no-update to your command/config.
[youtube] Extracting URL: https://www.youtube.com/watch?v=TOnGcMtsckM
[youtube] TOnGcMtsckM: Downloading webpage
[youtube] TOnGcMtsckM: Downloading tv client config
[youtube] TOnGcMtsckM: Downloading player 66a6ea83-main
[youtube] TOnGcMtsckM: Downloading tv player API JSON
[youtube] TOnGcMtsckM: Downloading android sdkless player API JSON
[youtube] [jsc:deno] Solving JS challenges using deno
WARNING: [youtube] [jsc] Remote components challenge solver script (deno) and NPM package (deno) were skipped. These may be required to solve JS challenges. You can enable these downloads with --remote-components ejs:github (recommended) or --remote-components ejs:npm , respectively. For more information and alternatives, refer to https://github.com/yt-dlp/yt-dlp/wiki/EJS
WARNING: [youtube] TOnGcMtsckM: n challenge solving failed: Some formats may be missing. Ensure you have a supported JavaScript runtime and challenge solver script distribution installed. Review any warnings presented before this message. For more details, refer to https://github.com/yt-dlp/yt-dlp/wiki/EJS
[info] TOnGcMtsckM: Downloading subtitles: en
[info] TOnGcMtsckM: Downloading 1 format(s): 139-20
[info] Writing video subtitles to: /tmp/yt_TOnGcMtsckM.en.vtt
[download] Destination: /tmp/yt_TOnGcMtsckM.en.vtt
[download] 1.00KiB at Unknown B/s (00:00:00)
[download] 3.00KiB at Unknown B/s (00:00:00)
[download] 7.00KiB at Unknown B/s (00:00:00)
[download] 15.00KiB at 4.21MiB/s (00:00:00)
[download] 31.00KiB at 2.16MiB/s (00:00:00)
[download] 63.00KiB at 2.84MiB/s (00:00:00)
[download] 127.00KiB at 3.80MiB/s (00:00:00)
[download] 173.62KiB at 4.17MiB/s (00:00:00)
[download] 100% of 173.62KiB in 00:00:00 at 1.19MiB/s
Exit code: 0Let me also get the video title and read the VTT file.
Got the captions. Let me also grab the video metadata and read the transcript.
{
"command": "yt-dlp --print title --print duration_string --print uploader --print upload_date \"https://www.youtube.com/watch?v=TOnGcMtsckM\" 2>/dev/null",
"timeout": 60000
}{
"file_path": "/tmp/yt_TOnGcMtsckM.en.vtt"
}Output from command in shell 117b7f: The MTB Cornering Technique That Changed Everything For Me. 16:48 Peter Jamison 20260518 Exit code: 0
<file-view path="/tmp/yt_TOnGcMtsckM.en.vtt" start_line="1" end_line="446" total_lines="4008"> 1|WEBVTT 2|Kind: captions 3|Language: en 4| 5|00:00:00.000 --> 00:00:01.390 align:start position:0% 6| 7|Morning<00:00:00.480><c> guys,</c><00:00:00.800><c> welcome</c><00:00:01.040><c> back</c><00:00:01.240><c> to</c><00:00:01.280><c> the</c> 8| 9|00:00:01.390 --> 00:00:01.400 align:start position:0% 10|Morning guys, welcome back to the 11| 12| 13|00:00:01.400 --> 00:00:03.150 align:start position:0% 14|Morning guys, welcome back to the 15|channel.<00:00:01.760><c> Hope</c><00:00:02.040><c> you're</c><00:00:02.200><c> doing</c><00:00:02.520><c> amazing.</c> 16| 17|00:00:03.150 --> 00:00:03.160 align:start position:0% 18|channel. Hope you're doing amazing. 19| 20| 21|00:00:03.160 --> 00:00:04.710 align:start position:0% 22|channel. Hope you're doing amazing. 23|Today<00:00:03.480><c> I'm</c><00:00:03.600><c> going</c><00:00:03.800><c> to</c><00:00:03.880><c> be</c><00:00:03.960><c> making</c><00:00:04.440><c> what</c><00:00:04.600><c> has</c> 24| 25|00:00:04.710 --> 00:00:04.720 align:start position:0% 26|Today I'm going to be making what has 27| 28| 29|00:00:04.720 --> 00:00:06.230 align:start position:0% 30|Today I'm going to be making what has 31|been<00:00:04.880><c> one</c><00:00:05.000><c> of</c><00:00:05.080><c> my</c><00:00:05.160><c> most</c><00:00:05.440><c> heavily</c><00:00:05.760><c> requested</c> 32| 33|00:00:06.230 --> 00:00:06.240 align:start position:0% 34|been one of my most heavily requested 35| 36| 37|00:00:06.240 --> 00:00:08.430 align:start position:0% 38|been one of my most heavily requested 39|videos<00:00:06.920><c> since</c><00:00:07.160><c> I</c><00:00:07.200><c> started</c><00:00:07.560><c> YouTube</c><00:00:08.000><c> 3</c><00:00:08.240><c> years</c> 40| 41|00:00:08.430 --> 00:00:08.440 align:start position:0% 42|videos since I started YouTube 3 years 43| 44| 45|00:00:08.440 --> 00:00:11.950 align:start position:0% 46|videos since I started YouTube 3 years 47|ago<00:00:09.080><c> and</c><00:00:09.280><c> that</c><00:00:09.600><c> is</c><00:00:10.120><c> how</c><00:00:10.440><c> to</c><00:00:10.920><c> corner.</c><00:00:11.840><c> For</c> 48| 49|00:00:11.950 --> 00:00:11.960 align:start position:0% 50|ago and that is how to corner. For 51| 52| 53|00:00:11.960 --> 00:00:14.270 align:start position:0% 54|ago and that is how to corner. For 55|myself,<00:00:12.640><c> I</c><00:00:12.760><c> learned</c><00:00:13.120><c> how</c><00:00:13.240><c> to</c><00:00:13.400><c> corner</c><00:00:13.960><c> at</c><00:00:14.240><c> a</c> 56| 57|00:00:14.270 --> 00:00:14.280 align:start position:0% 58|myself, I learned how to corner at a 59| 60| 61|00:00:14.280 --> 00:00:15.990 align:start position:0% 62|myself, I learned how to corner at a 63|high<00:00:14.480><c> level</c><00:00:14.880><c> out</c><00:00:15.080><c> of</c><00:00:15.200><c> necessity</c><00:00:15.760><c> to</c><00:00:15.840><c> hit</c> 64| 65|00:00:15.990 --> 00:00:16.000 align:start position:0% 66|high level out of necessity to hit 67| 68| 69|00:00:16.000 --> 00:00:18.030 align:start position:0% 70|high level out of necessity to hit 71|bigger<00:00:16.280><c> gaps</c><00:00:16.640><c> at</c><00:00:16.760><c> bike</c><00:00:16.960><c> parks.</c><00:00:17.680><c> I'd</c><00:00:17.800><c> kind</c><00:00:17.960><c> of</c> 72| 73|00:00:18.030 --> 00:00:18.040 align:start position:0% 74|bigger gaps at bike parks. I'd kind of 75| 76| 77|00:00:18.040 --> 00:00:19.550 align:start position:0% 78|bigger gaps at bike parks. I'd kind of 79|look<00:00:18.200><c> at</c><00:00:18.320><c> two</c><00:00:18.440><c> rollers</c><00:00:18.840><c> and</c><00:00:18.920><c> be</c><00:00:18.960><c> like,</c><00:00:19.120><c> "Hey,</c><00:00:19.480><c> I</c> 80| 81|00:00:19.550 --> 00:00:19.560 align:start position:0% 82|look at two rollers and be like, "Hey, I 83| 84| 85|00:00:19.560 --> 00:00:21.190 align:start position:0% 86|look at two rollers and be like, "Hey, I 87|want<00:00:19.720><c> to</c><00:00:19.760><c> jump</c><00:00:19.960><c> from</c><00:00:20.080><c> there</c><00:00:20.240><c> to</c><00:00:20.320><c> there."</c><00:00:21.040><c> Then</c> 88| 89|00:00:21.190 --> 00:00:21.200 align:start position:0% 90|want to jump from there to there." Then 91| 92| 93|00:00:21.200 --> 00:00:22.670 align:start position:0% 94|want to jump from there to there." Then 95|I<00:00:21.240><c> look</c><00:00:21.440><c> at</c><00:00:21.520><c> the</c><00:00:21.600><c> entrance</c><00:00:21.960><c> and</c><00:00:22.040><c> I'm</c><00:00:22.160><c> like,</c> 96| 97|00:00:22.670 --> 00:00:22.680 align:start position:0% 98|I look at the entrance and I'm like, 99| 100| 101|00:00:22.680 --> 00:00:24.310 align:start position:0% 102|I look at the entrance and I'm like, 103|"Damn,<00:00:23.040><c> guess</c><00:00:23.240><c> I</c><00:00:23.280><c> got</c><00:00:23.520><c> to</c><00:00:23.640><c> absolutely</c><00:00:24.120><c> rail</c> 104| 105|00:00:24.310 --> 00:00:24.320 align:start position:0% 106|"Damn, guess I got to absolutely rail 107| 108| 109|00:00:24.320 --> 00:00:26.030 align:start position:0% 110|"Damn, guess I got to absolutely rail 111|that<00:00:24.480><c> corner</c><00:00:24.800><c> to</c><00:00:24.920><c> be</c><00:00:25.000><c> able</c><00:00:25.160><c> to</c><00:00:25.240><c> do</c><00:00:25.400><c> that."</c><00:00:25.960><c> So</c> 112| 113|00:00:26.030 --> 00:00:26.040 align:start position:0% 114|that corner to be able to do that." So 115| 116| 117|00:00:26.040 --> 00:00:27.550 align:start position:0% 118|that corner to be able to do that." So 119|out<00:00:26.160><c> of</c><00:00:26.240><c> necessity,</c><00:00:26.960><c> I</c><00:00:27.120><c> learned</c><00:00:27.400><c> how</c><00:00:27.480><c> to</c> 120| 121|00:00:27.550 --> 00:00:27.560 align:start position:0% 122|out of necessity, I learned how to 123| 124| 125|00:00:27.560 --> 00:00:29.590 align:start position:0% 126|out of necessity, I learned how to 127|corner<00:00:28.160><c> really</c><00:00:28.400><c> well.</c><00:00:29.000><c> And</c><00:00:29.200><c> today</c><00:00:29.400><c> I'm</c><00:00:29.480><c> going</c> 128| 129|00:00:29.590 --> 00:00:29.600 align:start position:0% 130|corner really well. And today I'm going 131| 132| 133|00:00:29.600 --> 00:00:31.590 align:start position:0% 134|corner really well. And today I'm going 135|to<00:00:29.680><c> be</c><00:00:29.720><c> walking</c><00:00:30.040><c> you</c><00:00:30.160><c> through</c><00:00:30.400><c> all</c><00:00:30.600><c> the</c><00:00:30.920><c> cues</c> 136| 137|00:00:31.590 --> 00:00:31.600 align:start position:0% 138|to be walking you through all the cues 139| 140| 141|00:00:31.600 --> 00:00:33.790 align:start position:0% 142|to be walking you through all the cues 143|and<00:00:31.800><c> skills</c><00:00:32.439><c> that</c><00:00:32.599><c> I've</c><00:00:32.759><c> kind</c><00:00:33.040><c> of</c><00:00:33.400><c> used</c><00:00:33.720><c> to</c> 144| 145|00:00:33.790 --> 00:00:33.800 align:start position:0% 146|and skills that I've kind of used to 147| 148| 149|00:00:33.800 --> 00:00:36.470 align:start position:0% 150|and skills that I've kind of used to 151|develop<00:00:34.120><c> my</c><00:00:34.240><c> personal</c><00:00:34.800><c> cornering</c><00:00:35.200><c> ability</c><00:00:36.000><c> to</c> 152| 153|00:00:36.470 --> 00:00:36.480 align:start position:0% 154|develop my personal cornering ability to 155| 156| 157|00:00:36.480 --> 00:00:38.350 align:start position:0% 158|develop my personal cornering ability to 159|to<00:00:36.600><c> get</c><00:00:36.720><c> it</c><00:00:36.840><c> to</c><00:00:36.960><c> a</c><00:00:37.400><c> relatively</c><00:00:37.880><c> high</c><00:00:38.040><c> level</c><00:00:38.320><c> in</c> 160| 161|00:00:38.350 --> 00:00:38.360 align:start position:0% 162|to get it to a relatively high level in 163| 164| 165|00:00:38.360 --> 00:00:40.350 align:start position:0% 166|to get it to a relatively high level in 167|my<00:00:38.480><c> personal</c><00:00:38.840><c> opinion.</c><00:00:39.200><c> So</c><00:00:39.640><c> hopefully</c><00:00:40.200><c> there</c> 168| 169|00:00:40.350 --> 00:00:40.360 align:start position:0% 170|my personal opinion. So hopefully there 171| 172| 173|00:00:40.360 --> 00:00:41.830 align:start position:0% 174|my personal opinion. So hopefully there 175|is<00:00:40.480><c> a</c><00:00:40.560><c> ton</c><00:00:40.760><c> of</c><00:00:40.840><c> information</c><00:00:41.400><c> here</c><00:00:41.600><c> that</c><00:00:41.720><c> can</c> 176| 177|00:00:41.830 --> 00:00:41.840 align:start position:0% 178|is a ton of information here that can 179| 180| 181|00:00:41.840 --> 00:00:43.430 align:start position:0% 182|is a ton of information here that can 183|help<00:00:42.040><c> you</c><00:00:42.160><c> out</c><00:00:42.320><c> with</c><00:00:42.440><c> your</c><00:00:42.560><c> own</c><00:00:42.680><c> riding.</c><00:00:43.320><c> So</c> 184| 185|00:00:43.430 --> 00:00:43.440 align:start position:0% 186|help you out with your own riding. So 187| 188| 189|00:00:43.440 --> 00:00:45.830 align:start position:0% 190|help you out with your own riding. So 191|let's<00:00:43.640><c> get</c><00:00:44.040><c> right</c><00:00:44.320><c> into</c><00:00:44.560><c> it.</c><00:00:44.880><c> So</c><00:00:45.040><c> step</c><00:00:45.440><c> number</c> 192| 193|00:00:45.830 --> 00:00:45.840 align:start position:0% 194|let's get right into it. So step number 195| 196| 197|00:00:45.840 --> 00:00:47.910 align:start position:0% 198|let's get right into it. So step number 199|one<00:00:46.240><c> of</c><00:00:46.360><c> today's</c><00:00:46.720><c> video,</c><00:00:47.280><c> it's</c><00:00:47.400><c> all</c><00:00:47.560><c> about</c> 200| 201|00:00:47.910 --> 00:00:47.920 align:start position:0% 202|one of today's video, it's all about 203| 204| 205|00:00:47.920 --> 00:00:51.390 align:start position:0% 206|one of today's video, it's all about 207|setup.<00:00:48.520><c> So</c><00:00:49.160><c> what</c><00:00:49.400><c> berms</c><00:00:50.040><c> should</c><00:00:50.280><c> you</c><00:00:50.440><c> be</c><00:00:50.640><c> using</c> 208| 209|00:00:51.390 --> 00:00:51.400 align:start position:0% 210|setup. So what berms should you be using 211| 212| 213|00:00:51.400 --> 00:00:53.390 align:start position:0% 214|setup. So what berms should you be using 215|to<00:00:51.600><c> work</c><00:00:51.920><c> on</c><00:00:52.080><c> your</c><00:00:52.200><c> cornering</c><00:00:52.600><c> ability?</c><00:00:53.320><c> You</c> 216| 217|00:00:53.390 --> 00:00:53.400 align:start position:0% 218|to work on your cornering ability? You 219| 220| 221|00:00:53.400 --> 00:00:55.190 align:start position:0% 222|to work on your cornering ability? You 223|don't<00:00:53.560><c> want</c><00:00:53.720><c> to</c><00:00:53.800><c> use</c><00:00:54.040><c> something</c><00:00:54.520><c> that's</c><00:00:55.040><c> too</c> 224| 225|00:00:55.190 --> 00:00:55.200 align:start position:0% 226|don't want to use something that's too 227| 228| 229|00:00:55.200 --> 00:00:56.470 align:start position:0% 230|don't want to use something that's too 231|little<00:00:55.480><c> of</c><00:00:55.560><c> a</c><00:00:55.640><c> berm</c><00:00:56.040><c> where</c><00:00:56.200><c> you're</c><00:00:56.280><c> just</c> 232| 233|00:00:56.470 --> 00:00:56.480 align:start position:0% 234|little of a berm where you're just 235| 236| 237|00:00:56.480 --> 00:00:58.510 align:start position:0% 238|little of a berm where you're just 239|risking<00:00:56.840><c> crashing</c><00:00:57.320><c> because</c><00:00:57.600><c> there's</c><00:00:58.280><c> no</c> 240| 241|00:00:58.510 --> 00:00:58.520 align:start position:0% 242|risking crashing because there's no 243| 244| 245|00:00:58.520 --> 00:01:00.350 align:start position:0% 246|risking crashing because there's no 247|chance<00:00:58.840><c> of</c><00:00:58.920><c> maintaining</c><00:00:59.400><c> traction.</c><00:01:00.160><c> But</c><00:01:00.320><c> you</c> 248| 249|00:01:00.350 --> 00:01:00.360 align:start position:0% 250|chance of maintaining traction. But you 251| 252| 253|00:01:00.360 --> 00:01:02.190 align:start position:0% 254|chance of maintaining traction. But you 255|don't<00:01:00.520><c> want</c><00:01:00.640><c> to</c><00:01:00.680><c> use</c><00:01:01.200><c> too</c><00:01:01.360><c> big</c><00:01:01.560><c> of</c><00:01:01.640><c> a</c><00:01:01.720><c> berm</c> 256| 257|00:01:02.190 --> 00:01:02.200 align:start position:0% 258|don't want to use too big of a berm 259| 260| 261|00:01:02.200 --> 00:01:04.430 align:start position:0% 262|don't want to use too big of a berm 263|where<00:01:02.360><c> it's</c><00:01:02.520><c> doing</c><00:01:03.200><c> the</c><00:01:03.320><c> whole</c><00:01:03.560><c> action</c><00:01:04.120><c> for</c> 264| 265|00:01:04.430 --> 00:01:04.440 align:start position:0% 266|where it's doing the whole action for 267| 268| 269|00:01:04.440 --> 00:01:06.910 align:start position:0% 270|where it's doing the whole action for 271|you.<00:01:04.640><c> So</c><00:01:05.120><c> what</c><00:01:05.239><c> we</c><00:01:05.360><c> have</c><00:01:05.519><c> here</c><00:01:05.880><c> on</c><00:01:06.000><c> my</c><00:01:06.120><c> left</c><00:01:06.600><c> is</c> 272| 273|00:01:06.910 --> 00:01:06.920 align:start position:0% 274|you. So what we have here on my left is 275| 276| 277|00:01:06.920 --> 00:01:07.990 align:start position:0% 278|you. So what we have here on my left is 279|the<00:01:07.000><c> berm</c><00:01:07.360><c> that</c><00:01:07.480><c> I'll</c><00:01:07.560><c> be</c><00:01:07.680><c> using</c><00:01:07.920><c> to</c> 280| 281|00:01:07.990 --> 00:01:08.000 align:start position:0% 282|the berm that I'll be using to 283| 284| 285|00:01:08.000 --> 00:01:09.390 align:start position:0% 286|the berm that I'll be using to 287|demonstrate<00:01:08.520><c> throughout</c><00:01:08.800><c> today's</c><00:01:09.040><c> entire</c> 288| 289|00:01:09.390 --> 00:01:09.400 align:start position:0% 290|demonstrate throughout today's entire 291| 292| 293|00:01:09.400 --> 00:01:12.510 align:start position:0% 294|demonstrate throughout today's entire 295|video.<00:01:10.200><c> It's</c><00:01:10.720><c> maybe</c><00:01:11.440><c> a</c><00:01:11.520><c> foot</c><00:01:11.800><c> tall,</c><00:01:12.200><c> 18</c> 296| 297|00:01:12.510 --> 00:01:12.520 align:start position:0% 298|video. It's maybe a foot tall, 18 299| 300| 301|00:01:12.520 --> 00:01:15.030 align:start position:0% 302|video. It's maybe a foot tall, 18 303|inches.<00:01:13.280><c> It's</c><00:01:13.360><c> not</c><00:01:13.560><c> too</c><00:01:13.640><c> much,</c><00:01:14.000><c> but</c><00:01:14.200><c> it's</c><00:01:14.680><c> just</c> 304| 305|00:01:15.030 --> 00:01:15.040 align:start position:0% 306|inches. It's not too much, but it's just 307| 308| 309|00:01:15.040 --> 00:01:16.790 align:start position:0% 310|inches. It's not too much, but it's just 311|enough<00:01:15.720><c> where</c><00:01:15.880><c> you</c><00:01:16.080><c> have</c><00:01:16.320><c> some</c><00:01:16.440><c> proper</c> 312| 313|00:01:16.790 --> 00:01:16.800 align:start position:0% 314|enough where you have some proper 315| 316| 317|00:01:16.800 --> 00:01:18.710 align:start position:0% 318|enough where you have some proper 319|support<00:01:17.280><c> kind</c><00:01:17.440><c> of</c><00:01:17.520><c> push</c><00:01:17.760><c> off</c><00:01:18.000><c> of,</c><00:01:18.480><c> but</c><00:01:18.640><c> it's</c> 320| 321|00:01:18.710 --> 00:01:18.720 align:start position:0% 322|support kind of push off of, but it's 323| 324| 325|00:01:18.720 --> 00:01:19.990 align:start position:0% 326|support kind of push off of, but it's 327|not<00:01:18.960><c> too</c><00:01:19.080><c> much</c><00:01:19.400><c> where</c><00:01:19.520><c> it's</c><00:01:19.640><c> doing</c><00:01:19.800><c> the</c><00:01:19.880><c> whole</c> 328| 329|00:01:19.990 --> 00:01:20.000 align:start position:0% 330|not too much where it's doing the whole 331| 332| 333|00:01:20.000 --> 00:01:21.270 align:start position:0% 334|not too much where it's doing the whole 335|thing<00:01:20.240><c> for</c><00:01:20.440><c> you.</c><00:01:20.560><c> So</c><00:01:20.680><c> it's</c><00:01:20.800><c> kind</c><00:01:20.960><c> of</c><00:01:21.040><c> a</c><00:01:21.080><c> good</c> 336| 337|00:01:21.270 --> 00:01:21.280 align:start position:0% 338|thing for you. So it's kind of a good 339| 340| 341|00:01:21.280 --> 00:01:23.510 align:start position:0% 342|thing for you. So it's kind of a good 343|blend.<00:01:22.000><c> You</c><00:01:22.120><c> sort</c><00:01:22.400><c> of</c><00:01:22.480><c> just</c><00:01:22.920><c> need</c><00:01:23.120><c> to</c><00:01:23.240><c> kind</c><00:01:23.440><c> of</c> 344| 345|00:01:23.510 --> 00:01:23.520 align:start position:0% 346|blend. You sort of just need to kind of 347| 348| 349|00:01:23.520 --> 00:01:25.790 align:start position:0% 350|blend. You sort of just need to kind of 351|find<00:01:23.680><c> that</c><00:01:23.800><c> middle</c><00:01:24.040><c> ground</c><00:01:24.480><c> so</c><00:01:24.640><c> that</c><00:01:24.880><c> way</c><00:01:25.480><c> you</c> 352| 353|00:01:25.790 --> 00:01:25.800 align:start position:0% 354|find that middle ground so that way you 355| 356| 357|00:01:25.800 --> 00:01:27.750 align:start position:0% 358|find that middle ground so that way you 359|personally<00:01:26.560><c> are</c><00:01:26.960><c> relying</c><00:01:27.360><c> on</c><00:01:27.440><c> your</c><00:01:27.600><c> own</c> 360| 361|00:01:27.750 --> 00:01:27.760 align:start position:0% 362|personally are relying on your own 363| 364| 365|00:01:27.760 --> 00:01:29.590 align:start position:0% 366|personally are relying on your own 367|abilities<00:01:28.600><c> to</c><00:01:28.720><c> get</c><00:01:28.880><c> around</c><00:01:29.080><c> the</c><00:01:29.160><c> corner</c><00:01:29.480><c> as</c> 368| 369|00:01:29.590 --> 00:01:29.600 align:start position:0% 370|abilities to get around the corner as 371| 372| 373|00:01:29.600 --> 00:01:32.270 align:start position:0% 374|abilities to get around the corner as 375|best<00:01:29.880><c> as</c><00:01:29.960><c> you</c><00:01:30.080><c> can</c><00:01:30.680><c> without</c><00:01:31.360><c> risking</c><00:01:31.880><c> crashing</c> 376| 377|00:01:32.270 --> 00:01:32.280 align:start position:0% 378|best as you can without risking crashing 379| 380| 381|00:01:32.280 --> 00:01:34.950 align:start position:0% 382|best as you can without risking crashing 383|cuz<00:01:32.680><c> that's</c><00:01:32.880><c> not</c><00:01:33.040><c> fun</c><00:01:33.360><c> for</c><00:01:33.480><c> anybody.</c><00:01:34.320><c> And</c><00:01:34.480><c> then</c> 384| 385|00:01:34.950 --> 00:01:34.960 align:start position:0% 386|cuz that's not fun for anybody. And then 387| 388| 389|00:01:34.960 --> 00:01:37.710 align:start position:0% 390|cuz that's not fun for anybody. And then 391|the<00:01:35.400><c> second</c><00:01:36.320><c> aspect</c><00:01:36.880><c> of</c><00:01:37.040><c> setup</c><00:01:37.360><c> that's</c><00:01:37.520><c> really</c> 392| 393|00:01:37.710 --> 00:01:37.720 align:start position:0% 394|the second aspect of setup that's really 395| 396| 397|00:01:37.720 --> 00:01:40.550 align:start position:0% 398|the second aspect of setup that's really 399|important<00:01:38.360><c> is</c><00:01:39.040><c> tire</c><00:01:39.400><c> pressure.</c><00:01:40.240><c> So</c><00:01:40.440><c> for</c> 400| 401|00:01:40.550 --> 00:01:40.560 align:start position:0% 402|important is tire pressure. So for 403| 404| 405|00:01:40.560 --> 00:01:42.950 align:start position:0% 406|important is tire pressure. So for 407|myself,<00:01:41.040><c> I'm</c><00:01:41.160><c> running</c><00:01:41.360><c> 24</c><00:01:41.760><c> back,</c><00:01:42.160><c> 22</c><00:01:42.600><c> front.</c><00:01:42.920><c> I</c> 408| 409|00:01:42.950 --> 00:01:42.960 align:start position:0% 410|myself, I'm running 24 back, 22 front. I 411| 412| 413|00:01:42.960 --> 00:01:44.950 align:start position:0% 414|myself, I'm running 24 back, 22 front. I 415|got<00:01:43.480><c> Michelin</c><00:01:43.880><c> tires</c><00:01:44.280><c> on</c><00:01:44.400><c> here.</c><00:01:44.600><c> We</c><00:01:44.720><c> have</c><00:01:44.840><c> the</c> 416| 417|00:01:44.950 --> 00:01:44.960 align:start position:0% 418|got Michelin tires on here. We have the 419| 420| 421|00:01:44.960 --> 00:01:47.630 align:start position:0% 422|got Michelin tires on here. We have the 423|e-wild<00:01:45.560><c> front</c><00:01:45.840><c> tire</c><00:01:46.160><c> and</c><00:01:46.280><c> then</c><00:01:46.440><c> I've</c><00:01:46.560><c> got</c><00:01:46.880><c> the</c> 424| 425|00:01:47.630 --> 00:01:47.640 align:start position:0% 426|e-wild front tire and then I've got the 427| 428| 429|00:01:47.640 --> 00:01:51.190 align:start position:0% 430|e-wild front tire and then I've got the 431|DH<00:01:48.240><c> 16</c><00:01:48.920><c> in</c><00:01:49.040><c> the</c><00:01:49.160><c> rear.</c><00:01:49.600><c> This</c><00:01:49.800><c> is</c><00:01:49.920><c> my</c><00:01:50.080><c> REEB</c><00:01:50.680><c> peak</c> 432| 433|00:01:51.190 --> 00:01:51.200 align:start position:0% 434|DH 16 in the rear. This is my REEB peak 435| 436| 437|00:01:51.200 --> 00:01:53.310 align:start position:0% 438|DH 16 in the rear. This is my REEB peak 439|lightweight<00:01:51.640><c> e-bike.</c><00:01:52.480><c> So</c><00:01:52.680><c> tire</c><00:01:52.960><c> pressure</c> 440| 441|00:01:53.310 --> 00:01:53.320 align:start position:0% 442|lightweight e-bike. So tire pressure 443| 444| 445|00:01:53.320 --> 00:01:55.350 align:start position:0% 446|lightweight e-bike. So tire pressure </file-view>
The VTT file is 4008 lines. Let me convert it to plain text to read the full transcript. I'll use a script to strip the VTT formatting.
Let me convert the VTT to clean text to read the full transcript.
{
"command": "python3 -c \"\nimport re\nwith open('/tmp/yt_TOnGcMtsckM.en.vtt') as f:\n content = f.read()\n# Remove headers\ncontent = re.sub(r'WEBVTT.*?\\n\\n', '', content, count=1, flags=re.DOTALL)\n# Remove timestamps and tags\ncontent = re.sub(r'\\d{2}:\\d{2}:\\d{2}\\.\\d{3} --> \\d{2}:\\d{2}:\\d{2}\\.\\d{3}.*', '', content)\ncontent = re.sub(r'<[^>]+>', '', content)\n# Deduplicate consecutive duplicate lines (VTT has rolling captions)\nlines = [l.strip() for l in content.split('\\n')]\nout = []\nprev = ''\nfor l in lines:\n if l and l != prev:\n out.append(l)\n prev = l\ntext = ' '.join(out)\ntext = re.sub(r'\\s+', ' ', text)\nwith open('/tmp/yt_TOnGcMtsckM.txt','w') as f:\n f.write(text)\nprint(len(text), 'chars')\nprint(text[:500])\n\""
}Output from command in shell 05a394: 55884 chars Morning guys, welcome back to the Morning guys, welcome back to the Morning guys, welcome back to the channel. Hope you're doing amazing. channel. Hope you're doing amazing. channel. Hope you're doing amazing. Today I'm going to be making what has Today I'm going to be making what has Today I'm going to be making what has been one of my most heavily requested been one of my most heavily requested been one of my most heavily requested videos since I started YouTube 3 years videos since I started Exit code: 0
The dedup didn't work perfectly because VTT rolling captions repeat phrases. Let me improve the dedup - the issue is that each line is a partial cumulative caption, so consecutive lines contain overlapping text. Let me just read the file and handle it differently - take only the last/longest line of each caption block. Actually, let me just read the text file as is and summarize; the repetition is manageable. But better to clean it. Let me try a different approach - take only the last line of each timestamp block.
{
"command": "python3 -c \"\nimport re\nwith open('/tmp/yt_TOnGcMtsckM.en.vtt') as f:\n content = f.read()\nblocks = re.split(r'\\n\\n+', content)\nout_lines = []\nfor b in blocks:\n lines = [l for l in b.split('\\n') if not re.match(r'^\\d{2}:\\d{2}', l) and l.strip() and not l.startswith('WEBVTT') and not l.startswith('Kind:') and not l.startswith('Language:')]\n if not lines: continue\n # take the last (most complete) line of the rolling caption\n last = re.sub(r'<[^>]+>', '', lines[-1]).strip()\n if last:\n out_lines.append(last)\n# dedupe consecutive identical\ndeduped = []\nprev = ''\nfor l in out_lines:\n if l != prev:\n deduped.append(l)\n prev = l\ntext = ' '.join(deduped)\ntext = re.sub(r'\\s+', ' ', text)\nwith open('/tmp/yt_TOnGcMtsckM_clean.txt','w') as f:\n f.write(text)\nprint(len(text), 'chars')\nprint(text[:1500])\n\""
}Output from command in shell 605fa9: 18632 chars Morning guys, welcome back to the channel. Hope you're doing amazing. Today I'm going to be making what has been one of my most heavily requested videos since I started YouTube 3 years ago and that is how to corner. For myself, I learned how to corner at a high level out of necessity to hit bigger gaps at bike parks. I'd kind of look at two rollers and be like, "Hey, I want to jump from there to there." Then I look at the entrance and I'm like, "Damn, guess I got to absolutely rail that corner to be able to do that." So out of necessity, I learned how to corner really well. And today I'm going to be walking you through all the cues and skills that I've kind of used to develop my personal cornering ability to to get it to a relatively high level in my personal opinion. So hopefully there is a ton of information here that can help you out with your own riding. So let's get right into it. So step number one of today's video, it's all about setup. So what berms should you be using to work on your cornering ability? You don't want to use something that's too little of a berm where you're just risking crashing because there's no chance of maintaining traction. But you don't want to use too big of a berm where it's doing the whole action for you. So what we have here on my left is the berm that I'll be using to demonstrate throughout today's entire video. It's maybe a foot tall, 18 inches. It's not too much, but it's just enough where you have some proper support kind of push off of Exit code: 0
Clean transcript ready. Let me read the full thing.
{
"file_path": "/tmp/yt_TOnGcMtsckM_clean.txt"
}<file-view path="/tmp/yt_TOnGcMtsckM_clean.txt" start_line="1" end_line="1" total_lines="1"> 1|Morning guys, welcome back to the channel. Hope you're doing amazing. Today I'm going to be making what has been one of my most heavily requested videos since I started YouTube 3 years ago and that is how to corner. For myself, I learned how to corner at a high level out of necessity to hit bigger gaps at bike parks. I'd kind of look at two rollers and be like, "Hey, I want to jump from there to there." Then I look at the entrance and I'm like, "Damn, guess I got to absolutely rail that corner to be able to do that." So out of necessity, I learned how to corner really well. And today I'm going to be walking you through all the cues and skills that I've kind of used to develop my personal cornering ability to to get it to a relatively high level in my personal opinion. So hopefully there is a ton of information here that can help you out with your own riding. So let's get right into it. So step number one of today's video, it's all about setup. So what berms should you be using to work on your cornering ability? You don't want to use something that's too little of a berm where you're just risking crashing because there's no chance of maintaining traction. But you don't want to use too big of a berm where it's doing the whole action for you. So what we have here on my left is the berm that I'll be using to demonstrate throughout today's entire video. It's maybe a foot tall, 18 inches. It's not too much, but it's just enough where you have some proper support kind of push off of, but it's not too much where it's doing the whole thing for you. So it's kind of a good blend. You sort of just need to kind of find that middle ground so that way you personally are relying on your own abilities to get around the corner as best as you can without risking crashing cuz that's not fun for anybody. And then the second aspect of setup that's really important is tire pressure. So for myself, I'm running 24 back, 22 front. I got Michelin tires on here. We have the e-wild front tire a... [truncated 16632 chars] </file-view>
The file is one long line. Let me read it with the exec tool to get the full content.
{
"command": "cat /tmp/yt_TOnGcMtsckM_clean.txt | fold -s -w 2000 | head -100"
}Output from command in shell 363751: Morning guys, welcome back to the channel. Hope you're doing amazing. Today I'm going to be making what has been one of my most heavily requested videos since I started YouTube 3 years ago and that is how to corner. For myself, I learned how to corner at a high level out of necessity to hit bigger gaps at bike parks. I'd kind of look at two rollers and be like, "Hey, I want to jump from there to there." Then I look at the entrance and I'm like, "Damn, guess I got to absolutely rail that corner to be able to do that." So out of necessity, I learned how to corner really well. And today I'm going to be walking you through all the cues and skills that I've kind of used to develop my personal cornering ability to to get it to a relatively high level in my personal opinion. So hopefully there is a ton of information here that can help you out with your own riding. So let's get right into it. So step number one of today's video, it's all about setup. So what berms should you be using to work on your cornering ability? You don't want to use something that's too little of a berm where you're just risking crashing because there's no chance of maintaining traction. But you don't want to use too big of a berm where it's doing the whole action for you. So what we have here on my left is the berm that I'll be using to demonstrate throughout today's entire video. It's maybe a foot tall, 18 inches. It's not too much, but it's just enough where you have some proper support kind of push off of, but it's not too much where it's doing the whole thing for you. So it's kind of a good blend. You sort of just need to kind of find that middle ground so that way you personally are relying on your own abilities to get around the corner as best as you can without risking crashing cuz that's not fun for anybody. And then the second aspect of setup that's really important is tire pressure. So for myself, I'm running 24 back, 22 front. I got Michelin tires on here. We have the e-wild front tire and then I've got the DH 16 in the rear. This is my REEB peak lightweight e-bike. So tire pressure super important for all riding, but cornering especially because traction is really what we're looking to maintain here. And then unlike other areas of your riding, in a corner you're experiencing a lot of sidewall roll potentially depending on your tire pressure. And for myself, that's a a very big kind of area of feel for me with cornering. If I'm experiencing too much sidewall roll, I can't corner well and if I'm experiencing too little, I can't corner well also. So, knowing exactly where your tire pressure is and experimenting with that to kind of get the feel you're looking for is super super important and keeping that consistent. I'm a little bit crazy, but I can't ride unless I check my tire pressures with a digital gauge beforehand because I really know exactly how I want that sidewall roll to kind of feel in my feet and through my body. So, it's a a bit of a personal preference thing, but it's definitely worth noting. So, step one, let's get you guys ripping on a berm that's just supportive enough but not too big and not too small. And then let's make sure your tire pressure is in a pretty good spot. If you don't know where to start, I kind of just roll with whatever pressure you normally ride with the trail and then you can kind of start to develop a feel for what the tires are doing in the corner because that's going to come with time. So, enough with the setup now, let's get into the riding. So, now that you found a berm that you're stoked to practice on, you kind of have a rough idea of where your tire pressures are at, it's time to hop on the bike and start riding. So, before we even get to the corner, the most important thing to be conscious of is your braking beforehand. So, you don't want to make riding more complex than it needs to be. So, if you don't brake before the corner, then you're going into the corner, you're thinking about what your brakes are doing, you're thinking about how much traction you have, thinking about where you're looking, it's just too much. So, we can try to eliminate that as much as possible by braking beforehand. And what this allows us to do is allows us to get the braking out of the way early because we're not concerned about the entry pace with the corner. What we're concerned is coming out of the corner with as much pace as possible. And for myself, I'm not a racer. This is all just how to function for trying to ride the trails as best you can. Um so for me, what I like to do is in the setup as I'm kind of riding into the corner, I like to get to a comfortable pace. I don't have like a set distance before the corner, but definitely before I have to start initiating. So with this turn here, I kind of begin initiating, I would say maybe 5 to 6 ft beforehand. I'm entering the corner as early as possible, which we'll talk about in a second, but I like to have the braking done before. So there's a little section, I'd say it's about 20 ft long, which I would say is my main braking zone. I'll kind of put it on the screen right now from the overhead drone and draw a line so you can kind of see where I'm doing most of my braking. So in there, I'm using front and rear brakes as you should while you're mountain biking. Most of your power is your front brakes. You got to use that. I'm doing my braking. I'm weighting that front wheel. I And you can kind of see in the footage, as I'm riding into this, I'm I'm in a pretty aggressive um stance on the bike. Really braking. And then that way, when I'm starting to initiate the corner, subconsciously, I might still be feathering the brakes, which isn't ideal, but this is just reality. Um ideally you want all the braking done beforehand, but that way, if my brain's like, "Oh crap, you still need to slow down." I can subconsciously be doing that, but I don't want to consciously be braking through the corner. So the goal, get your braking done beforehand. That way you can set up wide and in the corner, you can be focusing on where you're looking, how you're weighting the bike, um and just how your traction is feeling. So the goal is your subconscious can do any more braking than it needs to do in the corner, and consciously, you're doing all your braking beforehand. Now, what you really don't want to do as well is not brake enough beforehand, start absolutely railing a turn, then your body's is like, "Oh, crap, I need to save this." It, say for instance, just grabs a handful front brake, you lose the front wheel, everyone's sad and having a bad day. So, we really need to set up the body to react to the speed you're taking into the corner as best as possible. So, if you take way too much entrance speed in, your body, in an action of safety to save you, is going to try to shut it down in there. Whereas, if you're at a comfortable pace consciously going into the corner, you're going to be able to ride the corner, maintain a smooth arc, and exit that corner with as much pace as possible. So, that is the first riding step is make sure you absolutely nail your braking. I also want to apologize if you guys see me kind of flicking my ears or whatever. We have really bad bugs this time of year in Southern Utah. I'm getting eaten alive right now, so I apologize for that, but let's keep on with the video. So, now that you're riding in to the berm at a comfortable pace, the next step is to enter the corner as wide as possible. So, for myself, I try to just push it wide without going excessive, but there's no better feeling than when you're sessioning a portion of a trail and you can kind of see your own little tire groove developing from how wide you're entering the corner. And the reason you want to do this is that's going to expand the arc of the corner as much as possible, allow you to just ride it at a nice consistent smooth arc. It's going to help you maintain traction because you don't need to redirect super quickly, and it's just going to allow you to look where you're going, and it just makes everything about cornering so much better. So, for contrast, the exact opposite of this would be doing an intentional scrub. So, I'll toss two clips on the screen right now that I just recorded for you guys. One with my kind of standard entry line, which I would say is just a hair right of most people's ride line or like kind of the groove on this trail. And then, the other clip is me purposely diving to the inside right here and having to sharply redirect. Now, for myself, um I've worked on my cornering a lot over the last kind of couple years, and thankfully I am able to dive to the inside and do that redirection and save it, but it's not ideal. You're not going to come out with a lot of speed. You're going to roost the corner, really fold that tire, you're going to lose all your pace, and it's just not ideal. Whereas when you set up wide, you can look to where you're going to go, which we'll chat about in just a second here. Set up wide, expand the radius of the corner as much as possible. Able to be nice and smooth, have as much traction as possible. We're looking to kind of avoid that quick redirect when possible. There is a time for everything with cornering, which I'll chat about in just a moment here. But, as for a general rule of thumb, enter wide, and then that way it's going to expand the arc, and you're going to be able to corner as smoothly and as best as you can you can. So, that's a that's really what we're looking for here. And then just to elaborate kind of on the roost shwop situation, there's a time and a place for everything. So, I'll toss a clip on the screen right now that I filmed. Wow, time flies. Uh, 5 years ago at Highland Mountain Bike Park on a trail called Meadow's End. It's my favorite trail at the park. I kind of did this roller roller gap, and it you're just coming out hauling, and it just sets you up square to the inside of a corner. Like, I have no choice but to just lean as hard as I can and just absolutely roost that thing. So, yes, it can be annoying when people are going to your local park and they might be just running super low tire pressure, squaring up a corner, just spraying dirt everywhere. Like, that's I mean, for an Instagram clip, if you want to do that, that's great, but there is like a actual function for people going and blowing up a corner. Like, if the trail is setting up themselves up that way to ride it. So, it's you know, lots of people get sensitive about people blowing up berms and things, um, which is super valid, um, but I'm just kind of explaining, you know, why in some instances that may may happen. Um, it's not something you should be going and doing all the time. You want to try to maintain those smooth arcs, smooth arcs, excuse me, and ride the corner really, really well. Um, but just wanted to give some some background there of kind of why a intentional roost kind of may occur. So, at this point, you're riding in at a good pace, you're riding in on a nice wide line to get a nice smooth arc through the corner. The next thing to think about is what I would classify as load the corner. So, the way this was explained to me as a kid, it's actually funny, Darren Berrecloth explained this to me when I was 14 and or I was a fan then, we're buddies now. We've joked about it over dinner one day last summer. Um, there's this kind of shark fin at the bike park I grew up riding at Highland, which I just mentioned. So, a shark fin is kind of a berm that has a little jump out of it and I couldn't like maintain my speed to like kind of hit the jump out well. And he looks at me, he's just like, "Dude, just pump the pump the berm." I'm like, "Dude, what? Pump the berm? What do you mean?" Then I kind of thought about it and I was like, "Oh, yeah, that makes sense." And then from then on, that kind of clicked for me. So, in this instance, like on a trail, I wouldn't say pump the berm. Like to think load the corner. So, what I mean by this, you don't want to be going through this turn passively. You want to actively be weighting the bike because you want to be putting pressure in through your tires to generate as much traction as possible. Now, it's a fine line. You don't want to go too much to then where you're getting excessive tire roll or your tire could step out, but you don't want to just be passively riding at the mercy of the turn. You need to be loading the bike. So, for me, I got one kind of slow-mo shot head-on in this corner, which I'll put on the screen right now, and you can kind of see how aggressive my body position is. And for me to feel confident in a corner, I need to be loading the bike so I can feel how I kind of the front wheel's turning, I can feel how much roll I have in the back tire, and I just know where I'm at. I don't want to have some vague feeling of just like randomly trusting what's going on. I like to load the bike so I am connected to the corner and totally feeling what's going on. Cuz if I feel something starting to slip, my body can kind of try to save it. Um I don't want to just be coming in and just riding all willy-nilly through the turn. So you need to load the corner or as the Claw told us me, pump the berm. But there's levels to it. If you do this too excessively, especially in your feet, which is my bad habit with cornering, I'm going to put a clip on the screen right now. It's one of the worst crashes I've ever had in my career. I was asking way too much out of a corner that just didn't have the support it needed. So it's a I was kind of hitting this rock gap in and it's a left turn at Trestle Bike Park in Colorado. And it this left turn I don't know if I can call it a berm. It's more of an embankment. So there's not much shape to it. It was kind of just there, like a wall. And I had so much entry speed similar to that situation at Highland I explained where I had to roost. I kind of like needed to roost this thing in order to save it. And I came in and I was just leaning so hard into this turn and trying to generate as much traction as possible. I was pushing in so hard with my feet that I bottomed out my shock or I didn't I wouldn't say fully bottomed out, but I got so deep in my rear shock's travel on a full downhill bike that my pedal, I think it was my outside pedal. I kind of forget if it was outside or inside which one clipped, but my cranks bottomed out and there was just a rock, perfect rock maybe, just sitting not even that high out of the ground, just enough to fully catch the front edge of my pedal and it just catapulted me and I had a major get-off. Um thankfully I was all good, but it was not fun. I had the worst dead leg of my life. Um so that is what can happen if you load a berm too aggressively, especially with your feet. You do not want your pedals bottoming out in a corner. That is bad news bears, been there, done that, speaking from experience. So, a nice equal load, not too much, not too little, but make sure you're loading or pumping the berm, however you want to think about it. And one sort of extra niche bonus tip on loading the corner that I just want to quickly mention, you're going to see me do this once again from kind of the head-on slow-mo shot in this left turn here, is when you're coming through, if you're struggling with front wheel grip and confidence, something that I generally tell people, and Jackson Goldstone talks about this a lot, is if you focus on your outside elbow being pretty steep, that's going to put additional pressure on your inside knob on your front tire. So, if you're putting pressure here, it's going down, and then on your contact point, it's getting that inside bit of the tire um as much pressure as it can get, and it's going to give you the most grip. So, you can see it really well on the front angle of this left turn. Then on the right turn afterwards, I can't quite get the exact setup I want for that because I'm hitting a left and then a right. So, there I'm kind of just riding more off of instinct in the right turn. So, I'm not what I would classify in like a perfect body position in that right, it's more survival mode, but that's just kind of the setup of the trail. I cannot hit this left enough to get me set up wide enough for the the next corner, but that's just kind of how the the trail is is is designed and built. Um but in a perfect situation, you can kind of ride in, just set up wide, and then get the elbow up. But, switchbacks and kind of technical cornering aspects are going to make you just corner off instinct, you're not going to be able to do this perfect setup every single time. So, that is um just kind of one extra little tidbit there, and now we're going to talk about the final thing, which is definitely the most important in my opinion. So, now last, but most certainly not least, is to look where you are going. This is key to all mountain biking, but it is especially true in cornering. So, you're going to be able to see it in the slow-mo clips on the screen right now as I am looking through the turn. So, when I'm here and I'm kind of entering this left turn, I am looking to the next right turn. In that right turn, I am looking toward the kind of drop-off that I'm going to ride off after. So, you need to look where you're going. You don't want to get stuck looking at your front tire. As the theme has been throughout today's video, you need to do what you can do to maintain that smooth arc. If you're just kind of here looking at the front tire, you're going to be twitchy, you're not going to be smooth. So, you need to be on the outside of the corner looking through to the next one. If it's a switchback, or just looking through toward the next portion of the trail. And yeah, you just look where you're going. That's kind of mountain biking 101, I feel like for most most people kind of learning the sport. So, yeah, just especially true of cornering, is just look where you're going. So, those are all my key points that I can share with you guys on how to corner to the best of your ability. There may be some small things that I missed, but I just wanted to kind of talk through the things that are really key to myself and my process, and specific cues that have helped my brain kind of elevate my cornering to that next level. So, if there's anything I missed or things that have helped you, please drop a comment below. Appreciate you guys for taking the time to watch the video if you made it this far. Thank you so much, really appreciate the support, and we'll see you next week for another upload. Peace. Exit code: 0
I've read the full transcript. Here's a summary of the video.
Channel: Peter Jamison | Length: 16:48 | Uploaded: May 18, 2026
Peter walks through the cornering cues and skills he developed (originally out of necessity to hit bigger gaps at bike parks). He breaks it into a setup phase and a riding phase with several key steps.
Brake before the corner — get braking done in a ~20 ft zone before initiation so that in the corner you can focus on vision, weighting, and traction rather than brakes. Consciously brake beforehand; any trailing braking in the turn should be subconscious. Entering with too much speed forces a panic save (e.g., grabbing front brake and losing the front wheel).
Enter wide — set up as wide as possible (without being excessive) to expand the arc of the corner. A wider entry = smoother arc, better traction, less need to sharply redirect, and more exit speed. He contrasts this with diving to the inside ("scrubbing"/squaring up), which roosts the berm, folds the tire, and kills speed. He notes there's a time and place for intentionally blowing up a corner (e.g., when the trail sets you up square, like a gap at Highland Bike Park's Meadow's End), but as a general rule, ride smooth arcs.
Load the corner ("pump the berm") — don't ride passively; actively weight the bike to generate traction and stay connected to what the tires are doing. Darren Berrecloth gave him this tip as a kid at Highland. But don't overdo it: pushing too hard with your feet can bottom out the shock and catch a pedal on a rock — he shares a major crash at Trestle Bike Park where exactly that happened (dead leg, but otherwise okay).
Look where you're going — the most important point. Look through the turn to the next corner/feature, not at your front tire. Looking down makes you twitchy and breaks the smooth arc. In his demo left turn he's already looking ahead to the next right turn and the drop-off beyond it.
Perfect setup isn't always possible — switchbacks and technical corners often force you to corner off instinct rather than the textbook wide-entry/body-position setup. The cues are goals to aim for when the trail allows.
He closes by inviting viewers to share anything he missed or cues that have helped them.
how can i push the limits of a flat sharp turn?
The user is asking a follow-up question about how to push the limits of a flat sharp turn (i.e., a flat corner with no berm support, sharp angle). This is a mountain biking technique question that builds on the cornering video context. I should answer based on my knowledge of MTB technique, informed by the video's principles but extended to flat/sharp turns specifically. Let me give a solid, practical answer. This isn't really a tool-use task — it's a knowledge question building on the video we just summarized.
Flat sharp turns are the hardest cornering scenario because you have zero berm support and a tight radius — so traction comes entirely from body position, tire setup, and how you manage load. Here's how to push the limits without just eating dirt:
On a flat corner there's no wall to catch you, so tire pressure and compound are your entire traction budget. Run slightly lower pressure than you would on berms (more contact patch, more grip), but not so low that the tire rolls off the rim or folds under lateral load. A grippy front tire (soft compound, tall side knobs like a Michelin e-Wild, Magic Mary, or Assegai) is the single biggest upgrade. Consider inserts (CushCore, Rimpact) so you can run lower pressure without flatting.
The video's "brake before the corner" rule is doubly true here. On a flat sharp turn, any braking mid-corner unloads the front tire and invites a washout. Get to your cornering speed well before initiation. If you must trail brake, use the rear only and lightly — a sliding rear is recoverable; a washed front is not.
On a sharp turn, the radius is already tiny. The only way to enlarge it is to use all available trail width: enter wide, let the bike drift toward the inside at the apex (late apex), then exit wide. This is the same "expand the arc" principle from the video, but on a flat turn it's the difference between making it and not. You're essentially turning the sharp corner into the shallowest possible arc the trail width allows.
Same "pump the berm" principle, but on flat ground you're loading against the tire's own grip rather than a wall. Modulate the load to the surface: on hardpack you can load aggressively; on loose-over-hard or dust you have to be smoother and more progressive, or the tire will break loose. If the surface is sketchy, a slight, controlled rear-wheel drift (breaking traction intentionally with a subtle rear brake pulse or hip flick) can scrub speed and rotate the bike without relying on grip that isn't there.
Even more than on berms, look where you want to go, not at the apex or the inside edge. On a sharp flat turn your instinct is to look at the thing you're afraid of (the edge / the tree). Fight that. Look at the exit and beyond — your body and bike will follow your eyes.
The short version: flat sharp turns reward setup (tires, pressure), line (wide/late apex), and commitment (hips in, outside pedal weighted, eyes on the exit). The limit is found by sessioning one turn and incrementally stepping over it — rear drift first, never front.
this seems counter intuitive • Drop the outside pedal, weight it hard — drives the tire's side knobs into the ground. This is your primary traction source on a flat turn., wouldnt that enncourage a flip out ?
The user is questioning the advice about dropping and weighting the outside pedal on a flat turn. They think it would cause the bike to flip out (i.e., flip away from the turn, over the high side). This is a really good question and a common misconception. Let me think carefully about the physics here. When you corner, there's a lateral (centrifugal) force pushing you outward. To counter this, you lean the bike into the turn. Now, the question is about pedal position and body weight distribution. **Why drop the outside pedal?** When you drop the outside pedal (put it at the bottom of the pedal stroke, 6 o'clock position) and stand on it, you're putting your body weight on the outside side of the bike. This does several things: 1. **It allows you to separate body lean from bike lean.** Your body stays more upright (or even leans slightly outward) while the bike leans into the turn. This is called "bike lean, body upright" or the "bar turn" technique. By keeping your body mass more centered/upright while the bike leans, you create a more favorable weight distribution. 2. **It counteracts the lateral force.** The centrifugal force wants to push you outward (flip you out of the turn = high-side). By weighting the outside pedal, you're essentially anchoring your body weight to the outside, which counteracts the tipping moment. Think of it like a keel on a sailboat — the weight on the outside keeps you from tipping outward. Wait, let me think about this more carefully. The user's intuition is: if I push down hard on the outside pedal, wouldn't that push the bike over / flip it outward? Actually, let me think about the mechanics more precisely. When cornering flat, you lean the bike into the turn. The contact patch is to the inside of your center of mass. The lateral (centrifugal) force acts outward through your center of mass, creating a moment that wants to tip you outward (high-side). Now, if you weight the outside pedal (which is at the bottom, on the outside of the bike), your body weight is pushing down on the outside side of the bike. This actually... hmm. Let me think about this differently. The key insight is about body position relative to the bike: - When you drop the outside pedal and weight it, you can keep your body more upright while leaning the bike beneath you. Your center of mass stays more centered over (or slightly outside of) the contact patch. - This means the lateral force has less leverage to tip you outward because your COM is closer to being over the contact patch. - Additionally, by being able to lean the bike more while keeping your body upright, you get more lean angle on the bike (more side knob engagement) without committing your entire body mass to the lean. The alternative — keeping pedals level and leaning body + bike together — means your whole system tilts, and the lateral force acts on your COM which is now leaning inward. This can actually make it easier to lose front traction because you can't independently control bike lean vs body position. Actually wait, I need to reconsider. Let me think about what "flip out" means. The user is worried about high-siding — flipping to the outside of the turn. The forces at play: - Centrifugal force (outward) acting at the center of mass - Gravity (downward) acting at the center of mass - Normal force and friction at the contact patch The tipping moment about the contact patch: centrifugal force × height of COM. This wants to tip you outward (high-side). If you weight the outside pedal with your body more upright: - Your COM is higher (standing on pedals rather than sitting), but... - Your COM is more centered/vertical rather than leaning inward - The bike can lean more independently Hmm, actually the height of COM matters too. A higher COM means the centrifugal force has more leverage. But the key point is about the horizontal offset of COM from the contact patch. Let me think about it as a simple model: **Case 1: Level pedals, body + bike lean together at angle θ** - COM is offset inward from contact patch by approximately h·sin(θ) where h is height of COM above contact patch - The centrifugal force Fc acts outward at height h·cos(θ) - Gravity acts downward at height h·cos(θ) and offset h·sin(θ) inward - Net tipping moment about contact patch (positive = outward tip): Fc·h·cos(θ) - mg·h·sin(θ) - For stability: Fc·cos(θ) ≤ mg·sin(θ), i.e., tan(θ) ≥ Fc/(mg) = v²/(rg) **Case 2: Outside pedal down, body upright, bike leaned at angle θ** - Body COM is roughly above the contact patch (or slightly outside), bike is leaned - The bike lean gives you side knob engagement - Your body weight is pushing down through the outside pedal, which is on the outside of the bike - The downward force through the outside pedal actually creates a moment that... let me think... the outside pedal is to the outside of the contact patch. Pushing down on it creates a moment that tends to tip the bike outward? No wait... Hmm, actually the outside pedal when down is at the bottom of the stroke. When the bike is leaned into a left turn, the right (outside) pedal is down. The right pedal is to the right of the bike's centerline. The contact patch is on the left side of the bike (because the bike is leaned left). So the outside (right) pedal is even further from the contact patch to the right. Pushing down on the outside pedal creates a clockwise moment (when viewed from behind, turning left) about the contact patch — which is the same direction as the centrifugal force tipping moment. So... wouldn't that make it worse? Wait, but that's not the whole picture. The point is that by weighting the outside pedal, you're keeping your BODY upright (or even leaning slightly outward), which means your body's center of mass is more centered over the contact patch, reducing the inward lean of your overall COM. Actually, I think the real answer is more nuanced and it's about a few things: 1. **It's not really about tipping moment — it's about traction and control.** The primary reason to weight the outside pedal is that it allows you to lean the bike independently of your body, getting more bike lean angle (and thus more side knob engagement) while keeping your body weight in a more controlled, centered position. 2. **The outside pedal weight acts as an anchor.** When you stand hard on the outside pedal, you're essentially creating a stable platform. Your body weight is driving down through the bike into the ground. This downward force increases the normal force on the tires, which increases friction (traction). More weight = more grip. 3. **Counteracting the flip:** The user's concern about flipping out is valid in principle — the centrifugal force does want to tip you outward. But the key is that by keeping your body more upright (less inward lean), you're actually reducing the tipping moment compared to leaning everything into the turn. When your body is upright and the bike is leaned, your COM is closer to being directly above the contact patch, which is the most stable position. 4. **The "flip out" (high-side) happens when traction is lost and then regained.** It's not caused by weighting the outside pedal — it's caused by the tire sliding out and then suddenly gripping. Weighting the outside pedal actually gives you MORE grip, making a slide less likely. Let me reconsider the user's specific concern. They think pushing down hard on the outside pedal would push the bike over to the outside (flip out). I think the confusion is: "I'm pushing down on the outside, so wouldn't that push the bike to the outside?" The answer is: no, because you're pushing DOWN, not OUT. The downward force goes through the bike's frame to the contact patch. It increases the normal force (weight on tires) which increases traction. The outside pedal being down also means your inside pedal is up, so you have ground clearance to lean the bike further. The reason it doesn't flip you out is that your body weight on the outside pedal, combined with keeping your body upright, actually keeps your center of mass positioned to counteract the outward tipping. Your body is essentially acting as ballast on the outside, which resists the outward flip. Think of it like a sailboat: the sail (centrifugal force) pushes you one way, and the keel (your body weight on the outside) keeps you from tipping. If you leaned everything INTO the turn (like moving the keel to the same side as the sail), you'd actually be more likely to tip. Actually, I think the sailboat analogy is perfect here: - Sail = centrifugal force pushing outward - Keel = your body weight on the outside pedal - Hull = the bike The keel counterbalances the sail's force. Without the keel (no outside pedal weighting, body leaned in with the bike), you're more likely to tip outward because there's nothing counterbalancing. Let me also think about the alternative — what happens if you DON'T drop the outside pedal? If pedals are level and you lean bike + body together: - Your whole mass leans inward - You can't lean the bike as far (because your body goes with it, and you'd fall over) - Less side knob engagement - Your COM is leaning inward, so the centrifugal force has more leverage to tip you outward - You have less ground clearance for the inside pedal If you drop the outside pedal and weight it: - Bike can lean more (your body stays upright, providing the counterbalance) - More side knob engagement = more grip - Your COM is more centered/upright = less tipping leverage for centrifugal force - More ground clearance for inside pedal - You can modulate the load dynamically So the answer to the user's question is: weighting the outside pedal doesn't flip you out — it's actually what PREVENTS the flip. It's counterintuitive but it works like a sailboat keel. Your body weight on the outside is the counterbalance to the centrifugal force trying to push you outward. The thing that WOULD flip you out is: too much speed with not enough grip, causing the tires to slide. Weighting the outside pedal gives you MORE grip, not less. Let me write a clear, concise response.
Great question — it's genuinely counterintuitive, and a lot of people have this exact reaction. But weighting the outside pedal is actually what prevents the flip, not what causes it. Here's why:
Think of a sailboat: the wind pushes the sail one way (outward), and the keel — the heavy weight on the opposite side — keeps it from tipping over. Remove the keel and the boat flips immediately.
In a flat corner:
Your body weight on the outside is the counterbalance. Without it, you're more likely to tip outward, not less.
When you drop the outside pedal and stand on it, two things happen:
Your body stays more upright while the bike leans beneath you. This keeps your center of mass closer to directly above the contact patch — the most stable position. The centrifugal force has less leverage to tip you outward, not more.
The downward force increases traction. You're pushing down through the frame into the tires, not out. More downward force = more normal force = more friction = more grip. That grip is what holds you in the turn.
The thing that launches you outward is losing and regaining traction suddenly — the tire slides, then catches, and the bike snaps upright and throws you. That's caused by:
Weighting the outside pedal increases grip, making the slide less likely in the first place.
If you keep pedals level and lean body + bike together as one unit:
If you weight the outside pedal and your tires are already sliding, then yes — you're loading a tire that has no grip, and the bike can go. But that's a grip problem, not a pedal-weighting problem. The fix is less speed / better tires / earlier braking, not unweighting the outside pedal.
TL;DR: Pushing down on the outside pedal is the keel, not the sail. It keeps you grounded and gives you grip. The flip comes from losing traction, and weighting the outside pedal is one of the main things preventing that.